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
