MT to ISO 20022: The challenge of modernizing your payment messages (2024)

This article presents a use case to demonstrate that the migration from MT to ISO 20022 is not a simple task.

Payment messages have been used in the financial world for several decades, but nowadays the industry seems to be facing a turning point with the migration of these payment messages from the current MT format to ISO 20022. ISO 20022 provides a better structured, more granular, and easier to automate payment information.

The recent announcement from SWIFT delaying the migration deadline from MT to ISO 20022 payment messages has just been a temporary respite for financial institutions, but it hasn’t reduced the complexity nor the need for firms to start looking at the impact of such game changer.

What is MT?

The SWIFT Message Types (MT) standard is used for payments, cash management, trade finance and treasury business. The original message types were developed by SWIFT and a subset was published as an ISO standard, ISO 15022. The messages are widely used for making payments all over the world. They are used by all agents in the financial industry, from central banks to corporates.

MT messages consist of five blocks of data including three headers, message content, and a trailer. MT messages were conceived in the 1970s, designed to be small in size and carry minimal datasets for easier processing, with bandwidth and storage as high-priced commodities back then. However, the evolution of the financial markets has demanded more than what they were designed for, and most firms have been forced to customize in some degree the MT messages to cover their needs. A good example is the extension of field 72 in an MT103, to cater the relevant payment information that doesn’t fit in the standard fields of the message.

What is ISO 20022?

ISO 20022 is a financial standard in which messages are published from a UML-based repository. Currently the two generated ISO 20022 messaging formats are XML Schema and ASN.1. The XML Schema syntax defines the templates to validate the ISO 20022 XML messages. The messages are getting more adoption in the market recently, particularly in the payments space and as a reporting format.

ISO 20022 is richer, better defined and more granular than its predecessor SWIFT MT, and it improves the quality and consistency of data across messages and financial processes as well as the automation of its processing.

Messaging Fallacies

There are some common misunderstandings in the industry about MT and ISO 20022 messaging. The MT and ISO 20022 most common fallacies are:

• “MT messages are very simple” - MT messages have been in industry for a long time. That doesn’t mean the messages have been simplified. On the contrary, firms have customized the messages over many years. This increases the complexity of understanding the data they are carrying, since market participants may have extended the messages differently depending on the market infrastructure or payment system they participate.

• “ISO 20022 messages are very simple” – the ISO 20022 messaging architecture is based on the premise that each message is validated against a corresponding ISO 20022 Schema file that covers a specific functionality. For example, in the context of Payments Clearing and Settlement, there is one schema for Customer Credit Transfers (pacs.008), one for the Financial Institution Credit Transfers (pacs.009), or one for the Payment Returns (pacs.004) among others. This results in a proliferation of schemas being generated so the selection of the appropriate schemas for a particular project is important.
• “ISO 20022 messages are always consistent” – ISO 20022 payment messages cover a wider spectrum of possibilities than what is really used in the context of a specific payment system, which drives market infrastructures to define their own usage guidelines by restricting some features of the base ISO 20022 messages. This causes, for example, that a Customer Credit Transfer in the context of ESMIG Target2 Real-time Gross Settlement is in practice different than the same Customer Credit Transfer in the context of Cross Border Payments, even though both are based on the same pacs.008.001.08 message.
• “The conversion from MT to ISO 20022 is a straightforward one to one mapping” - the use case below is just an example showing how the conversion from MT to ISO 20022 is not simple and requires expertise on these financial standards.

A Use Case: The challenge of Returning a Payment for ESMIG T2 participants.

Most T2 participants such as banks and central banks currently manage their back-offices using MT messages.

Payment Returns using MT messages are handled, theoretically, with two messages: the MT103 RETN when returning a Customer Credit Transfer and the MT202 RETN when returning a Financial Institution Transfer. However, these two are not really messages defined in the SWIFT MT Standard, but just an adaptation of the original MT transfer messages (103 or 202 respectively) with some additional return information in the free text field 72. This absence of a specific standard message for payment returns proves the lack of standardization in these returning processes and evokes market participants to tailored implementations and bilateral agreements.

Moreover, the MT103 and MT202 are designed to represent only one transaction per message, so when returning a payment, there is not a standard way to distinguish the return flow versus the original one, which becomes especially problematic when additional charges are applied to the returned payment.

Given this situation, many payment systems and their participants agreed to only represent the returning flow in the MT103 RETN or MT202 RETN and include some references to the original transaction using field 72.

ESMIG T2 on the other hand is migrating its payment messages to ISO 20022 and it will require Payment Returns to be represented with a pacs.004.001.09 message, which by definition provides much richer and better structured information on the returned payment but also on the original transaction. Additionally, the T2 usage guidelines have applied their own restrictions to the base ISO 20022 message, making some fields related to original payment required. These fields are the original message Id, the original instruction Id, the original interbank settlement amount and the original interbank settlement date.

All these fields regarding the original transaction that is being returned do not exist in the MT103 RETN or MT202 RETN, but they will be required by ESMIG T2, which means a one-to-one mapping between both won’t be possible. Instead, firms will need to clearly identify the references to the original MT message, fetch their databases with these references, and recover the original amount, date and identifiers in order to create a valid ESMIG T2 return message.

Conclusion

We are in a turning point regarding the use of payment messaging standards in the financial industry. The conversion from MT to ISO 20022 is inevitable but it should not be underestimated. There is a lack of knowledge in the industry regarding payment formats and this generates many fallacies. SWIFT MT and ISO 20022 are complex standards and the customizations that firms have implemented to their MT formats introduced a higher level of difficulty. This use case we presented in this article only illustrates one of the issues regarding the conversion between MT and ISO 20022 messages but many more exist. It is important to first understand that it is not a simple one to one conversion and gather the expertise needed to undertake such transformation.