The pain of MT to MX, from a corporate treasurer’s view

A corporate treasurer reached out to me in his frustration over the forced move from MT to MX messaging, saying it’s going to going to cost €500,000 or more for most corporates to comply with just one of the required changes not including the full development cost of a new file format. That may seem insignificant for a large multinational conglomerate, but that excludes the required partner bank testing, and the associated development status message update and the costs accumulate.

What is the MT to MX thing?

MTs are message types. It was created by SWIFT, the interbank system for messaging, back in 1977. Bear in mind that SWIFT is not a payments system but a messaging system, it is the core of what SWIFT does. Each message type represents an instruction. For example, Barclays might send JPMorgan an instruction to move $10,000 from one client account to another … that’s an MT101. They might send an MT111 to stop a cheque being processed or an MT300 for a foreign exchange transfer.

There are many message types, and this has allowed SWIFT to create and become the global messaging system for banks worldwide (well, Europe and America anyway).

I’ve rarely delved down into the depths of MTs, but did write a popular blog entry back in 2008 about how MT202 cover payments weren’t working.

It just goes to show that I can get deep and dirty sometimes, which is why this corporate treasurer reached out to me. The issue is that MTs have been around so long that they are coded into the core systems of corporations. Now, corporations are being told they have to recode and move on, and they don’t like it.

MTs are switching to MXs, and MX are XML message types:

An MX is an XML message definition for use on the SWIFT network. Most MX messages are also ISO 20022 messages.

ISO20022? What’s that? (get a free book about it here).

Well, ISO’s are International Standards. They allow global trade to happen, because they make sure that everyone can communicate in the same way for specific actions. ISO’s are standardising commerce. By way of example, when you buy a toy for a child built in China, how do you know your child’s toy is safe? There’s an ISO standard for that. In fact, ISO’s are for commerce a bit like w what SWIFT’s MT’s are for finance. Confused? It can be, but it’s all about global trade and commerce.

For international corporations, they need to comply with standards set by ISO’s and, when making payments and dealing with finance and currencies, they need to comply with standards set by SWIFT.

Phew.

The thing is that ISO and MX are nothing new. ISO20022 was introduced in 2004:

ISO 20022 is an international standard for relaying electronic messages between financial institutions. It was created to give the financial industry a common platform for sending payments messages and exchanging payments data, using a central dictionary, a standard modelling methodology, and a series of Extensible Markup Language (XML) and Abstract Syntax Notation (ASN.1 ) protocols.

The thing is that there is a major change to this international standard that starts in November 2022. This is that all financial messaging over SWIFT, and soon after other financial infrastructures, are also planning to adopt this messaging.

MTs are dead, long live MXs. By 2025, no MT1,2 or 9 series message types will be accepted over the SWIFT FIN network.

The industry has decided to replace the old MT standards entirely with MX messages because they are compliant with ISO 20022 standards. The adoption of the MX format will be progressive and depends on countries or regions. In the European Union, cross-border / high value payments across the regions going into the SWIFT Network, Target2 and a few others in scope will be transitioned first in November 2022. The U.S. Federal Reserve will transition in November 2023. Both formats will coexist until 2025 (the deadline set by SWIFT), and most of MT messages will then no longer be permitted. The following figure shows the timeline planned for the interbank space.

Source: The New Era of MX Messages - Redbridge (redbridgedta.com)

From November 2022, the banking industry through SWIFT will force corporations to switch to this new messaging system, but some corporations aren’t happy about it. In particular, Mark Sutton of Zanders reached out to me, asking the question about the logic of mandating corporates to de-merge data, only for banks to merge it again in the validation process.

Specifically, the issue is a thing called the structured address block.

What’s that?

Well, it’s your address obviously. The thing is that your address has been coded in a different way in the past. Let’s say you live at 123 Acacia Avenue. The old way of coding that would be:

<Building Number>:     123

<Street Name>:     Acacia Avenue

According to Mark, the issues arise that (a) there is no structured tag for the street number in the new standards; and (b) software vendors globally are not supporting a fully structured address.

This is why corporations will have to spend €500,000 or more per system to comply, not including the additional costs of testing.

As Mark puts it:

In summary, what is perceived by some as a minor or acceptable change, forcing the use of the full structured [address] will represent significant impact to a large number of corporates, globally. This potential friction can be significantly reduced by simply ‘fine tuning’ the current thinking and to allow the line 1 address to be provided in a single field – either street name or address line within the … messaging standard. This would minimise the system level changes as well as the impact on master data cleansing within the corporate community and would still allow for effective screening to be completed.

It just goes to show how a small change can have a massive impact. As they say, “if a butterfly flaps its wings in the Amazonian rain forest, it can change the weather half a world away”.

Postnote:

If this subject interests you, I recommend you read Mark’s thoughts:

• All Round the Houses
• Update on The Pain Points of the New Structured Address Block (Part 2)