All goes ISO 20022

The title refers to the general migration to ISO 20022 in all payment transactions and the associated reporting. In this context, my colleague René Keller wrote about the plans of TARGET2 and SWIFT to now also implement the ISO 20022 standard, which is already familiar from SEPA, in individual and cross-border payments. The changes described there, especially in interbank payments, now also affect the customer-bank interface.

Just as the Corona pandemic has negative effects in many other places, consequences are also found by way of postponed migration schedules. The changes are coming – just a little later. The time should be used well, as the aspects are not purely IT-related. With the new standard, many processes in payments and associated fields will see fundamental changes and the impact must be considered for the architecture as a whole. This applies for both financial institutions and corporate customers, who will have to deal with a number of changes in the coming releases. The information in the announcements is now available in Appendix 3 of the DFÜ agreement and extends several years into the future – which is completely necessary.

Some make a point of saying that "the forthcoming changes are not that massive; after all, we are familiar with the XML format from SEPA". If the format used in SEPA is "well known", then that is indeed a very good starting point for preparing for the changes. However, there is much more to be considered. On the one hand, SEPA is about to make a release leap. On the other hand, especially in individual and cross-border payments, there is a whole range of special features that do not occur at all in mass payments. Moreover, for regulatory reasons, there will be a switch to structured address information. The challenge lies in the sheer sum of the changes.

camt.053 – version change

With the introduction of SEPA and the Europe-wide uniform format based on ISO 20022, the camt.053 account statement was also introduced alongside the previously common MT940. It was the ideal format for SEPA payments, as data from a uniform data dictionary could now also be transported as account statements via the formats pain (customer-bank) and pacs (interbank). But in addition to bookings in mass payments, there were also individual and cross-border payments. For this reason (and various others), quite a few companies stuck with the old familiar format.

However, the introduction of ISO 20022 in all interbank payments is now taking place on a current ISO release, the one from 2019. SEPA is still using the ISO release from 2009. As with any standard, there are of course various reasons for the further development of the ISO 20022 format, and there will continue to be. New fields will be introduced or code words will be extended. The account statement, which is to pass on all the new information to the end customer without any loss of data, must therefore also comply with the new standard, and so the conversion from camt.053.001.02 to the new release camt.053.001.08 is unavoidable (similarly for camt.052 and camt.054). As corporate customers have been informed at an early stage, sufficient time is now available for often lengthy ERP release cycles. Particularly as it is to be expected that a postponement of the TARGET2 migration to ISO 20022 will also delay the migration here.

MT940 discontinuation

SWIFT will discontinue the MT messages of categories 1, 2 and 9 in interbank communication as of November 2025. At the customer-bank interface (especially with SCORE), this restriction should not apply; in this respect, financial institutions worldwide are not forced to switch off MT101 or even MT940 in their service. However, the German Banking Industry Committee (DK) has decided this is necessary for our "multi-bank standard" – and that is a good thing. Financial institutions may still offer MT940 if they wish, but the advantages of the new standard are already obvious: entire XML structures can be transported from pain via pacs to camt without conversions. It is no big leap to the analogy of containers in logistics. And all corporate customers should be "pushed" towards these advantages.

DTAZV becomes pain.001

With the introduction of pain.001 as a customer order for a SEPA credit transfer, the question was quickly raised: why can't this format also be used for currency payments? The CGI-MP (Common Global Implementation - Market Practice) initiative of corporates, banks and manufacturers soon came together to harmonise the use of this global standard in order to establish a standardised mapping. But the CGI version of pain.001 is based, like the SEPA version, on the ISO release from 2009 – meaning pain.001.001.03. The CGI-MP is working on a new version (ISO release 2019) of the harmonised mapping. The new cross-border payment upload in Annex 3 will also be based on ISO 2019 – meaning pain.001.001.09.

And, as is so often the case, "all goes ISO 20022" also presents a great opportunity. An opportunity for continuous processes on the same data basis which can be handled without conversions. The basis for further digitisation remains standardisation. With "all goes ISO 20022", a continuous standard is available which can also be used for adjacent processes such as "exception & investigation" (queries), notifications, bank fee messages (camt.086 bank service billing) as well as for BAM (bank account management) as eBAM messages. This in turn means that payments (including account statements) are only a small part of the entire ISO universe.


Author: Mario Reichel

Don't fear standard software in the payments industry

Those who want to distinguish themselves from the competition develop their own software. This rule is becoming increasingly widespread among companies – and more and more "experts" advise financial institutions to increase in-house development of their own applications, or even to become tech companies. This philosophy starts to falter no later than when it comes to the payments platform.

For example, the supervisory authorities stipulate uninterrupted operation if the financial institution wants to process instant payments. We have experienced the resulting architectural challenges first-hand in our TRAVIC-Payment Hub. Add to this the numerous surrounding systems such as anti-money laundering or embargo and sanction lists, not to mention routing. Doing all of that in-house results in such high costs that many financial institutions would rather prefer not to do any payment processing at all and instead to have it done by a central institution within a large association. However, that is not an option if payments are to become a strategically important line of business.

Roundabout for payments

We have thus asked ourselves: what exactly is the "special ingredient" that financial institutions need to add to their payments systems in order to distinguish themselves from other competitors and be able to offer payment processing as their own product? This question is especially relevant if an institution applies as a service provider for corporate customers to process their payments in a specific region of the world. And lo and behold: in their core, many processes are quite similar from one financial institution to another. They mostly only differ with regard to the order the financial institutions perform them in. Following this insight, we have designed a payments platform that works like a roundabout. For each special function, there is an opportunity to "hop on" the platform in a different place, just like children on a fairground may hop on the roundabout anywhere they like (see Fig. 1).




TRAVIC-Payment Hub enables a financial institution to define any conceivable configuration. This applies both to the routing administration (which allows for almost any complexity of rule sets) and to the connected surrounding systems. But how does TRAVIC-Payment Hub know what is supposed to happen if, for example, the compliance system returns a certain status? Usually it is the surrounding systems that have to follow what the main system commands – so why should a financial institution, after possibly getting rid of one monolith in core processing, now acquire another in payments processing? The answer to this is an integrated workflow engine that has its own script language to connect the other systems comparatively easily – while also being independent of the manufacturer, i.e. of us.

The "Hub" in TRAVIC-Payment Hub is thus both a product name and a performance promise.

Software development inside out

In terms of technicality, we turn what would otherwise develop into "legacy" outwards. The implemented script language enables a financial institution to add its own business processes to TRAVIC-Payment Hub without having to open up the source code of the software. As technology and business aspects are separated, a significant part of software development thus moves from the sphere of the manufacturer into the sphere of the user. This means that the payments platform stays fit for release even though TRAVIC-Payment Hub may have to coordinate a complex network of surrounding systems. Additionally, the IT departments are not even tempted to develop too closely to the core payments processing and to run the risk of trying to modify something in one place and, in doing so, provoking a problem in another.

In practice, the procedure is as follows: TRAVIC-Payment Hub receives various statuses by the surrounding systems. The script language is used by in-house IT employees or the integration partner to define how payments with the respective statuses shall be handled. As soon as the workflow is fully defined, the system compiles the code so that TRAVIC-Payment Hub can start working. To this end, the workflow engine generates tasks which are then processed by an internal task engine. Here is a very simple example of how the script language developed by PPI for TRAVIC-Payment Hub handles OUR charges, i.e. determines whether the charges due may be enclosed with a payment and retained or whether a payment request must be created.  

Status CHECKINBOUNDCHRGS {
    if payment is inbound and (payment is ourCharges) then {
        if payment is ourChargesReceived then {
            just set status VALIDATERECEIVCHGS and leave step
        }
        if payment is correspondentChargeExpected then {
            if payment is debitAuthorized then {
                just set status CREATEADVICEOFCHGS and leave step
            }
            just set status CREATECHARGEREQ and leave step
        }
    }
    just set status DONE and leave step



Introducing TRAVIC-Payment Hub

With the TRAVIC product suite, PPI covers the entire payments process of a financial institution, from incoming payments over interbank communication up to clearing. TRAVIC-Payment Hub handles the core processing of payments. Our solution works as customer bank and as clearing bank – even in parallel operation – and can process instant payments. Moreover, the solution can be operated on site and as outsourced high-availability software in cooperation with our infrastructure partners.

Author: Thomas Riedel


Further information: