In November 2022, a new “language” for cross-border payments will enter into force: the MX format. Which SWIFT XML broker to choose for smooth communication in the global banking world after the launch of ISO 20022?
The history of cross-border payments began with… cooperation with the media. From the 1970s until the beginning of digital banking, banks used long-distance telegraphs from the Reuters news agency for cross-border transfers. This solution has been adopted by the Society for Worldwide Interbank Financial Telecommunication (SWIFT) to settle payment orders on correspondent accounts of individual institutions.
In the times of fledgling digitalization, data used to identify the transfer was sent by telex, in the then accepted text format MT, which was organized like a telex form. One field represented one piece of information and was expressed with a number instead of a word. For example, 13C is a time stamp and 26T is a transaction type. One transfer required a total of several dozen “fields to be filled”, i.e., transfer information to be provided. As a result, the received message could be deciphered into all languages.
Goodbye SWIFT MT, welcome SWIFT MX
The main MT message format used for interbank clearing by SWIFT has not changed since the 1970s, however, the tools used to process it did as the message was expanded over time. One of such improvements was the introduction of an additional SWIFT code to identify the financial institution in the international banking pool. That’s how the bank’s ‘address’ was born, the BIC (Bank Identifier Code), which is the ID of the financial institution in the SWIFT system.
Over time, several fully digital standards for transferring transactions have emerged besides SWIFT: TARGET2, SEPA Credit Transfer, or TIPS. However, all of them have a smaller range than those based on the MT SWIFT message. Although banks today have the technical capacity to send large volumes of transactions instantaneously, one of the bottlenecks that prevents this is the legacy MT message type.
No wonder the banking world has decided to introduce a new and more universal language for international transactions. From November 2022, a new format for cross-border transfers enters into force, MX. It is the successor of the MT format, but adapted to the capabilities and expectations of Data-Driven Banking. Based on the XML structure, the MX messaging type enables easy data exchange in a common, flexible standard.
MT/MX conversion: the quest for context
By creating a common “language” and model for payment data, ISO 20022 significantly improves the transparency and efficiency of transactions. In addition, richer and structured data will open up new possibilities for personalization and improvement of the bank’s customer experience. However, the introduction of a new communication standard is fraught with considerable difficulties.
First of all, there is no common dictionary” that would allow direct translation between different message formats. While the conversion from “new” to “old” format (MX to MT) is relatively simpler, from “old” to “new” (MT to MX) it requires advanced knowledge of the relationships between individual message elements.
The “new” message (MX) has a multi-level, organized structure, which allows easily and unambiguously to aggregate its elements and assign them correctly to the “old” MT format. On the other hand, the data clusters in the “old” MT format do not always have clear rules for interpreting (“unpacking”). Meanwhile, the system that converts the message must “know” how to break down each incoming information into single components, and then properly recreate it in the default format so as not to lose any information and certainly not to generate an error.
Example:
Bank (BIC: EXABNL2U) from Utrecht, The Netherlands, received a transfer order from his client ACME NV (Amstel 344, Amsterdam) to transfer 12,500USD on October 29, 2019 from the account no. 8754219990.
In the “new” MX message (see below left), each value is contained in a separate element that has a unique label to identify and interpret its value. In the “old” MT format (right), the same values are much more difficult to interpret.
These translational difficulties are best seen in two elements:
1. Amount, currency, and date of the transaction:
The illegibility of the MT message is obvious. Two-way translation can only be done with clear conversion rules.
2. The address of the ordering party:
In the MT message, all customer data – the ordering party is under a single label (50F:) with the account number, whereas the address is divided into consecutive lines (1/, 2/, 3/) with no differentiation into the name of the city, street or country.
If the address is typical and the elements are not too long, the address will read as shown in the illustration (1/company name, 2/street and number, 3/country/city). However, if the company name is longer than 33 characters, then line 2/will not contain the street and number, but will continue the name of the company. On the other hand, if the address also includes the name of the state/province, address line 3 will not hold all the information, and perhaps an extra line 4 will be added.
As you can see, assembling the address in line 50F: is simple in the case of the MX message, but the reverse conversion requires knowledge of the context. For example, knowing that there are four lines and a European country (BIC address!), we can expect a “classic” address and a long customer name (lines 1 and 2). However, if the address is US-based, the last line must be interpreted as a country/state/city.
These examples show that the translation of MT/MX messages can be really complicated in some cases. It is like looking for an address in a foreign city. As long as the street names and numbering are standard, you will easily reach your destination. However, with a non-standard address, it is easy to get lost. Without a thorough understanding of the anatomy and context of the message, i.e., different naming and numbering methods, the banking system can also get lost in MT/MX translation.
When preparing to launch an ISO 20022 SWIFT MT to MX converter, it will be difficult for a developer to know how to relate the old and the new message formats for a glitch-free exchange. In-depth knowledge of the banking process and its intricacies is the area of expertise of the banking system analyst. Their domain knowledge allows scrupulously analyzing the scope of tasks ahead and preparing implementation guidelines for developers. My colleagues discuss the benefits of working with banking IT analysts in this article.
MT/MX converter: more than a temporary solution?
When the changes required in the new communication standard have been mapped, it is time to select the strategy for their implementation. The bank can add a ready-med ISO 20022-compliant interface to its core system, or develop its own solution. There is also a third approach: a SWIFT MT/MX format message converter. Some organizations choose it as a temporary solution because of limited time or budget. On the other hand, some choose a solution that solves the immediate problem, and at the same time is future-proof and meets the goals of their long-term development strategy.
Translators supporting data validation, enhancement, and conversion between different standards or formats are already becoming available. One of them is the native SWIFT MT/MX converter. This solution will certainly be used by large international organizations. However, its complexity, as well as the costs of implementation and maintenance, do not make it a good fit for every organization. Organizations that need an optimized MT/MX converter can use the independent MT/MX broker that is a business application integrated with the core system. A good example of such a solution is our proprietary system, Payres.
MT/MX converter: light solution, great possibilities
As a SWIFT MT/MX message translator, Payres enables the settlement of SWIFT XML ISO 20022-compliant international payments. As a “lightweight” MT/MX message broker, Payres eliminates the need to modernize core systems and maintain the efficiency and flexibility of the banking architecture. The solution is cost-effective and does not require a complicated implementation process. Payres works in Real-Time Transform (RTT) flow, and the support of the Drools rules engine minimizes the inevitable delay resulting from the serial position of the translator in the payment message path.
Payres wsupports back office applications that do not support the new format, or do so only partially. Our message broker automates transaction processing between back office applications and external networks.
However, unlike “classic” MT/MX converters, Payres processes data in real-time, automatically leveraging the data flowing between the bank’s core system and the integrated applications. Payres is suitable even for organizations that plan to ultimately implement MX messaging in the core system itself! When it is no longer needed as a MT/MX converter, it can support real-time data activation in line with Data-Driven Banking.
Breakthrough changes go well with long-term perspective
The temporary converter is a perfect solution to maintain communication in the global banking world after the launch of the “new” communication standard in November 2022. However, banks that make do with a temporary MT/MX translator and neglect to thoroughly modernize their IT architecture will have to make extra effort to catch up, as explained by the experts interviewed by the Red Compass consulting company. With the “banking Esperanto” of ISO 20022 at your disposal, you not only gain a universal language in which to communicate, but also new business opportunities. To use them, choose a Data-Driven Banking-ready solution that will generate added value, both now and in the future. Need support in migrating to ISO 20022? We look forward to hearing from you! We are a team of professionals with experience in advanced payment processing projects, e.g. card payment messages for international clients. Learn more about our proprietary MT/MX converter here.