ISO 20022 in cross-border payments: time for change!

Nearly all major payment systems are in the process of introducing standardised, XML-based data formats. They make both cross-border and individual payments significantly faster and less susceptible to errors. But the conversion will not happen on its own and there is not much time left. What needs to be considered?

Card payments on holiday and cross-border payments are now taken for granted in everyday life. However, every electronic transaction requires highly-complex processes since, for a fast and smooth money transfer, all IT systems involved must be able to handle the generated data equally well. For this, standards such as ISO 20022, which will be the benchmark for foreign and individual payments in the coming years, are needed.

Proven standard for the future

More and more payments areas are converting their systems according to the ISO standard because it brings huge advantages: it is future-proof, allows the significantly faster processing of payment data and enables a considerably increased efficiency. Any conversions from one data format into another will no longer be necessary. The straight-through processing (STP) of data records without interactions or media discontinuity will increase.

Don't underestimate the effort

All the advantages come at a cost – the conversion to ISO 20022 requires both personnel and financial resources. Many financial institutions are currently underestimating the effort involved. They not only have to automate any existing manual processes, but also need to make their own software fit for ISO. If their software is in the form of grown legacy systems, the preparations for the processing of XML data packets become quite demanding. In addition, time is of the essence: the go-live for converting TARGET2 to the XML standard is the 21st of November 2021. At the same time for SWIFT a four-year phase of coexistence begins.

False sense of preparedness

Already, European financial institutions are working with ISO-based standards because SEPA is based on them. However, this does not mean that they can sit idly. Depending on the type of implementation, ultimately adjustments will need to be made in all important areas of the payments IT, from master data to e-banking and back-end systems. Not to mention the impact on the future architecture of the core banking system.

Different implementations of the ISO standard

We should also remember that this is a generic standard that only lays down the basic principles for payment messages. It is adapted as appropriate for each individual implementation, i.e. it may well differ for TARGET2, SWIFT and SEPA. From limiting the permissible ISO codes and data types to removing optional elements of the basic message that are not required, a wide range of options is available. That is why for the migration a one-size-fits-all solution is not realistic.

Many individual projects

As a result, it is actually wrong to talk about the ISO 20022 conversion when in truth there are many different projects. This makes it all the more important to involve the IT department at an early stage in order to support the business side in pointing out pitfalls and problems on time and, not least, to obtain an early cost estimate. The conversion of cross-border or individual payments from TARGET2 to the XML standard is likely to cost a seven- to eight-figure sum. This sum includes the preliminary study, the implementation and the IT adjustments themselves. Additionally to be budgeted are the training of the involved employees and the timely development of the necessary know-how, alternatively the integration of external partners.

What is next?

If it does not already exist, financial institutions need a roadmap as soon as possible - with all the required measures and milestones for the conversion to the ISO standard. The basis for this is an honest assessment of one's own current situation. This is something that everyone has to consider. In the course of this process, the question may well be raised as to whether the provision of in-house cross-border payments will still be economically reasonable in the future and whether an increased cooperation with external service providers is the better solution.

Embracing change as an opportunity

The conversion to ISO 20022 undoubtedly puts financial service providers under pressure, especially when we consider the almost simultaneous consolidation of TARGET2 and TARGET2-Securities. However, the regulatory changes are also an opportunity to critically examine one's own systems and to explore how agile and flexible they can be modelled. In the end, this also helps to push forward the digital transformation on the whole - because standing still is not an option in today's digital world.

Guest authors: Sabine Aigner, Raija Wehrli

Read more

EBICS 3.0 – a set of parameters instead of the order type. What must be taken into account when identifying business transactions?

With EBICS 3.0, the different business transactions are no longer mapped via order types, but via the new BTF parameters.

In order to enable the use of customer contracts with EBICS clients of different EBICS versions in combination with EBICS 3.0, special mapping rules were developed by the national specification bodies. These rules are generally oriented toward the five BTF parameters Service Name, Service Scope, Service Option, Service Message Name and Service Container. The important thing is that the combination of these BTF parameters must be unique in the EBICS bank server. This ensures that an order type can be assigned to the business transaction via BTF and vice versa.

In practice, identical orders of a certain format can be created for an order type in different format versions and submitted to the bank server. Although format adjustments are made regularly by the specification bodies, the format version used by the client system also depends on the software version of the client solution. Since the format version should be transparent to them in the clients, users have no influence on the submission in a particular format version when compiling their order files. In addition, financial institutions generally accept different format versions of a business transaction. Finally, for bank-side processing, the respective format version can also be read out from the namespace of the XML file, at least for XML formats. So far, bank servers are flexibly designed for different format versions.

The other usable BTF parameters in EBICS 3.0 are Service Message Name Format, Service Message Name Variant, and Service Message Name Version. If a financial institution also includes these other parameters in the order type mappings and agreement details with the customer, a number of things should be taken into account. If not previously used more intensively via FileFormat parameters or necessary for processing reasons, these additional parameters should be considered in a more measured manner on the bank side for EBICS tests.

Ultimately, this additional parameter information is already part of the order file itself and can be read from it anyway. What to do with conflicting statements? The additional management in the bank server also means more time and effort in master data management. There would have to be a separate customer agreement for each format version of a business transaction. What's more, these format details are visible to the customer in the client software, and some of them cannot be controlled.

What would happen if, for example, the bank server supports versions 03 and 04 of an XML format for submissions, but the customer submits version 04 to the BTF instead of submitting a format in version 03? Taking into account the version, the order would be rejected, although the bank system could process the format version; the actual version is recognisable by the namespace.
It is even more complicated with provisions of download files. In this case, the provision would have to be generated synchronously in the requested version at the time of download and output as a file. The same applies to historical downloads.

Conclusion: financial institutions should not be too restrictive in their definitions of BTF agreements with the customer. This enables financial institutions to be more flexible and saves additional time and effort in contract and master data management.


Author: Michael Lembcke

Read more