How to enhance EBICS, Part 8 – Preventing double submissions using EBICS tools: What’s going on?

It happened in a blink. The payment orders were accidentally transferred to the bank twice via EBICS. Nobody noticed. A number of such error cases are possible:

1. A payment was entered and sent twice in the order input.
2. The file with the payment orders was transferred again - for the second time.
3. For technical reasons, the payment file was transferred twice because the transfer status of the first transfer was not clear.

A double submission is basically a case of a customer submitting a payment or file with identical data to the bank again within a defined period of time. However, is an identical submission always a double submission that generally must be rejected? No, because some payments are deliberately prepared and transferred multiple times by the submitter.


So how can the bank side reliably detect real double submissions and prevent any damage to the customer?

It is possible to detect and reject obvious double submissions in the EBICS bank server already at the point of submission.

In the case of technical double submissions (see 3.), the EBICS protocol up to EBICS version 2.4 detects when a customer re-uses an order ID assigned by the EBICS client within a defined time period. From EBICS V2.5 onwards, the EBICS bank server already assigns a unique order ID when the communication is being set up. Therefore, a duplicate effect cannot occur as with EBICS V2.4.
However, the case of a file or order being re-sent accidentally in a new transfer operation, and thus with a new order ID (see 2.), cannot be ruled out at present with the existing EBICS tools on the EBICS bank server. To enable an effective double-submission check on the file level for this scenario, the EBICS-CR EB-14-08 DoubleUploadControl is being implemented with the next EBICS version.

This CR obligates the EBICS client to transfer a hash value relating to the payment file to the EBICS bank server. The client creates this hash value in any event for the signature creation. The EBICS bank server must check whether the hash value has already occurred in the relevant time period and reject the order if there is a double submission.

A more advanced double-submission check, e.g. on the single transaction level (case 1.), is more complicated and must still be implemented outside EBICS. If applicable, a bank employee must contact the customer to determine whether the double submission is actually deliberate.

The planned EBICS-CR EB-14-08 DoubleUploadControl further improves EBICS by adding another useful function. This is also necessary. It enables accidental double submissions to be prevented early. However, it is not a cure-all. It is still the case that bank applications cannot forego more advanced duplication checks.

Michael Lembcke