Standardisation of payment transactions is still a distant reality

In Europe we have now already introduced SEPA for the standardised payment transfer system. However, SEPA payments cannot be made electronically to just any European bank of one's choice. In Germany companies use the order type CCT for submitting SEPA transactions (SEPA Credit Transfer) to financial institutions. Why are SEPA transfers from any Euro country with this order type not automatically possible?

The XML-based SEPA data formats have now been comprehensively adopted in the European countries involved. The goal was, and remains, to standardise data formats and regulations surrounding payment transactions after the introduction of the single currency, thus allowing a simpler electronic payment medium for within Europe.


Based on ISO20022 XML formats and the guidelines of the European Payments Council (EPC), implementation in the Eurozone has alas been carried out separately according to regionally-specific payment transaction conventions. As a result, we now have differing, country-specific SEPA formats for the same business transactions.

They differ first and foremost in the namespace of the format. While, for example, Germany has introduced their own data format variant for SEPA transfers with "pain.001.002.03 ", other countries use the EPC's "pain.001.001.03". National differences are also prevalent in XML namespaces. Moreover, we are subject to assignment regulations which are different for each country.

In Germany, SEPA payments, via EBICS, are designated with the three-digit order types and then transferred (e.g. CCT for SEPA transactions). With format associated with order type, we have a system which is built according to the specifications of the German credit services sector. But what happens if a foreign client sends a SEPA transaction in their native format to a German bank? Neither the order type nor the XML namespace offer a reliable definition of the formatting characteristics. The bank must, however, respond to these irregularities if they wish to process payment transactions internationally. So how can banks recognise the differing formatting specifications and process them accordingly?

Possible solution: Issuer ID for EBICS

As long as no proper standardisation of SEPA formats, which are traded amongst companies and credit institutions, is in effect at a European level, the solution must be found elsewhere. There are various ways to achieve this. One approach challenges the software developer to create an intelligent format parser or specialised core data extensions in the bank's computers. Another more sensible solution in the long-term is to take advantage of the EBICS standard.

In France, the problem has already been solved by the usage of format parameters and the country codes transferred. From the country code, an EBICS-compliant bank computer can infer the country-specific formatting rules and consequently initialise specific processing workflows. In Germany, however, the application of format parameters is not generally common. So in Germany, the possibility of introducing the EBICS issuer ID is currently under debate. This would also equip the business transaction with the issuer of the format, and hence the associated formatting rules. A bank computer could then recognise whether, for example, there are agreements and/or regulations for the declared formatting configuration. If the French model of format parameters and country codes is not also introduced in Germany, at least the issuer ID to order type system should soon be implemented with EBICS. A solution of this kind makes sense and hopefully will be available soon with EBICS. Until then banks and their clients will have to settle for ad-hoc solutions.

I will discuss the features of three-digit EBICS order types in Germany and of format parameters in France in a follow-up article.

Michael Lembcke