Previous:   SWIFT MT to MX Migration: Unleashing Data Quality and Flexibility in Financial Messaging

Swift MT to MX Messages - What are the changes?

We have understood why the migration from MT to MX messages is necessary in this previous blog.

In this blog let us understand what exactly are the changes that are going to happen when payment messages are migrated from MT to MX standards.

Terminology changes in message specification components

Though the whole transition from MT to MX is happening on the backend, there are some changes which you must be aware of. The first change is the terminology of the message specification components. Fields will be called Elements, the format will be called DataType, the Network Validated Rule will be called CrossElementComplexRule.

Terminology changes in parties in a message

Next change is the terminologies of the parties in the message. Banks are called Agents, the ordering customer - the debtor, beneficiary customer - creditor, the message sender is the instructing agent and the message receiver the instructed agent. 

There are also some new parties added like Ultimate debtor, ultimate creditor, initiating party etc.

Change in naming convention of messages

Unlike the three digit codes in MT messages, MX message names have four sections separated by dots. 

The first section consisting of four alphabets denotes the broader business area. Here pacs means ‘Payments Clearing and Settlement’ which is equivalent to Cat 1 of MTs. 

The next 3 characters denote the message functionality, here 008 denotes ‘FI To FI Customer Credit Transfer’. 

The next three numbers denote the variant. The role of the variant is to accommodate variations of the message to address specific market or business requirements. 

The last two digits denotes the version of the message. 

Change in message structure

The structure of the swift message is also changed. The heart of the change is the business message that remains capsuled inside an envelope layer in a MX message.
The business message consists of two parts - the Business Application Header and the main message itself.
The business application header gathers together, in one place, data about the message, such as which organization has sent the business message, which organization should be receiving it, the identity of the message itself, a reference for the message and so on.

Change in the message length and character sets permitted

Lastly, the character sets permitted in MX are also broader than that permitted in MT.

All these changes put together ultimately give access to more structured data to both banks and the end customers.

WANT TO READ MORE?

Sign Up to get notifications of future blog posts 

Sign up/ Login

Already signed up/ logged in? Then you are all set!

Next:    Agent and Party Roles in Swift MX Messages