PSD2: securing bulk payments via EBICS

The security of bulk payments has always been an issue. The early attempts to establish a simple protection against manipulation for this were rather half-hearted and therefore never led to reliable security. For example, the total of all recipient account numbers was formed to prevent criminals from subsequently changing the payments. But when the IBAN came along, even this extremely simple method was no longer useful – the financial institutions eventually abandoned it altogether simply because of the mathematical challenges involved.

All that remains to this day is the number of included payments and the total amount. Nobody claims that such values offer an effective protection.

More promising was the use of the PSD2 and RTS to provide more security for payments. However, they did not lead to a breakthrough for the bulk payments which are particularly common among corporate customers. The reason: displaying the recipient, account and amount and having the client check all the data contained, for example via dynamic linking, is hardly feasible for salary payments in a company with more than 10,000 employees. This is impossible from an organisational point of view alone and can hardly be realised using the established channels on the technical side.

So how do you make sure that the payment file, once created, is executed unchanged by the financial institution?

EBICS!

EBICS has been the standard in European corporate customer payments for years – available in all major countries with high transaction volumes, such as Germany, France, Austria and Switzerland. More countries will follow.

So why does the EBICS company not define a general and mandatory auditing standard based on international hash value procedures (e.g. SHA-256) and establish the corresponding set of rules? The principle: all applications which generate payment bulk files always generate the matching hash value and pass it to the financial institution together with the payment file. There, this check value can be recalculated as soon as the payment file arrives and presented to the customer for checking before release. That's it.

Simple and very effective, because the identical hash value guarantees that no manipulation has taken place between the creation of the bulk file and the processing of the bulk by the financial institution.

If, for the definition of the hash value procedure by the EBICS company, we then also consider the end customer, instead of the 32-double-value comparison an algorithm could be found which turns the hash value into a number consisting of 8-10 digits – similar to a TAN. Customers and users are already using these types of values today. A comparison of the check values only requires a minimal amount of time and is easy to do.

By the way, simply leaving the establishment of this definition to the market is not a good idea. If all of the players involved do their own thing, a multitude of different procedures are created, which confuse customers rather than provide additional security.

Therefore, it is one of the tasks of the EBICS company to provide a binding solution at this point and to, that way, also meet the demands of the PSD2 for bulk payments.

Author: Michael Schunk