SEPA 2.0: the ISO 20022 update could lead to a triple migration

SEPA and the ISO 20022 standard it's based on can well be considered a pioneer amongst the global ISO 20022 initiatives. Very early on, they presented themselves as the rulebook for many different payment formats in the Euro zone, using a common format standard to enable cross-border and cross-system interoperability. Despite some local dialects, SEPA has enabled continuous end-to-end processing without media discontinuities and conversions over the past years - not least by harmonising national characteristics with a uniform EPC specification. End-to-end, in this case, refers not only to the interbank relationship but also to the relationship between ordering party and recipient. This is made possible by the consistent use of the uniform data dictionary in the ISO 20022 format standard, which provides a uniform basis for data exchange by transporting data elements from customer-bank messages (pain) to interbank messages (pacs) and all the way to bank-customer messages (camt) without conversions.

Where SEPA is evolving (for example, due to the introduction of instant payments), the ISO 20022 standard used for SEPA still needs to catch up: namely regarding the 2009 basis defined by the EPC. As this ISO standard is also constantly evolving to reflect current developments, the EPC working group responsible for further development of the SEPA scheme plans to migrate all schemes (SCT, SCT Inst, SDD Core, SDD B2B) to version 2019 of the ISO 20022 standard. The transition is to be announced in 2020 and will come into final effect in November 2022 within the scope of a big bang migration (of the interbank formats). This change, amongst others, is currently subject to public consultation as a major change request. During this phase, remarks are requested from the circle of parties participating in the consultation.

One of the reasons for deeming this CR important is the future support of Request to Pay, which cannot be provided with the current ISO version as future required elements are not available in its format. However, an up-to-date version of the ISO standard is also required for other future developments, especially in light of the TARGET2 and SWIFT MX migrations, which are also based on the 2019 version of the ISO standard.

The good news is: the ISO 20022 standard is already well established in the world of SEPA. Unlike with the SEPA introduction, there is no need to introduce a new format and no need to replace old formats on a large scale. Existing systems must "only" be adjusted and learn to process changes such as new data elements. Nevertheless, the challenge is to master a big bang migration with effects on interbank payments and formats at the customer-bank interface.

The bad news: due to current developments, the SEPA migration date now coincides with the beginning of the SWIFT transition phase from MT to MX. The original approach of setting the date for the SEPA migration to 2022 had been chosen in order to avoid having to carry out the three major migrations – TARGET2, SWIFT MX and SEPA ISO 20022 version 2019 – almost simultaneously and to distribute the necessary efforts onto different time frames. Should TARGET2 now also postpone the planned big bang migration by one year, as first demands from the market suggest, all migrations will once again coincide in time. This will pose immense challenges for the financial service providers involved and wreck the original approach of distribution. The blame for this is easily placed on the global coronavirus pandemic, which is currently putting a severe strain on our lives and the economy.

In this situation, financial institutions must keep an eye on further developments and adapt to the forthcoming changes. We will also closely monitor ongoing events and will continue to report on the SEPA ISO changes after the market consultation is completed.

Author: René Keller

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 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