MT to MX: What Retail Banks Need to Know About the ISO 20022 Migration

If you work in payments at a retail bank, you have heard about the ISO 20022 migration. You have probably seen the slide decks. You may have attended a webinar where someone from SWIFT explained the timeline with the quiet confidence of someone who has never had to explain to a production support manager why a message format change broke the entire payment flow at 4pm on a Friday.

This article is not that webinar. It is a practical look at what the MT to MX migration actually means for retail banks running Temenos Transact — what changes, what breaks, what you need to configure, and what you can safely ignore until the deadline is closer than anyone is comfortable with. Which, if you are reading this in 2026, is now.

What is actually changing

For the last fifty years, SWIFT messages have used the MT (Message Type) format. MT messages are compact, field-numbered, and about as readable as a telegram written by someone who is being paid by the character. An MT103 looks like this:

{1:F01BANKGB2LAXXX0000000000}{2:O1031530050227BANKUS33XXXX000000000015300527050227U}{4:
:20:REF123456
:23B:CRED
:32A:050227USD50000,
:50K:/12345678
JOHN SMITH
:59:/87654321
JANE DOE
:71A:SHA
-}

It works. It has worked for decades. But it carries very little information beyond the bare minimum — who sent it, who receives it, how much, and a short reference. If you want to include structured remittance data, regulatory reporting codes, or detailed address information, you are out of luck. There is simply nowhere to put it. It is like trying to fit a novel into a tweet.

MX messages (ISO 20022) solve this by using XML. Instead of numbered fields, you get a structured document with named elements, optional fields, and the ability to carry as much data as the banks involved agree to support. The same payment in MX format (pacs.008) looks like this:

<?xml version="1.0" encoding="UTF-8"?><Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.12">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>REF123456</MsgId>
      <CreDtTm>2027-02-27T15:30:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>CLRG</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    ...
  </FIToFICstmrCdtTrf>
</Document>

It is longer. It is more verbose. It takes up more space on the wire and more space in your log files. But it is also infinitely more flexible. And that flexibility comes with a cost — every bank in the chain has to agree on which optional fields to use, how to populate them, and what to do when a field they do not recognise shows up in an incoming message. This is where the fun begins.

The timeline — when this actually hits you

SWIFT has been talking about the MT to MX migration for years. The original deadline was 2025. Then it moved. Then it moved again. The current plan is that MT messages will be phased out between 2027 and 2029, with different timelines for different message types and different regions. If this sounds like a deadline that will move again, you have been paying attention.

What this means in practice:

• CBPR+ (Cross-Border Payments and Reporting Plus) — This is the SWIFT initiative driving the migration for cross-border payments. Banks that have already adopted CBPR+ are sending and receiving MX messages today. Banks that have not are still on MT, and the gap between them is growing. If you are the bank that has not migrated and your main correspondent has, you are about to find out what "incompatible message format" looks like in a production incident.
• High-value payments (MT103, MT202) — These are the priority. SWIFT wants these migrated first because they represent the bulk of cross-border payment volume. They are also the ones that cause the most interesting production incidents when something goes wrong.
• Statements and reporting (MT940, MT950) — These are on a slower timeline, but they are coming. Banks that have not updated their statement processing by 2028 will start receiving camt.053 messages that their systems cannot parse. The statements will sit in a queue. Someone will notice three weeks later. That someone will be your manager.
• Securities and trade finance — These are on separate timelines and are generally further behind. If your retail bank does not do securities, you can ignore these for now. If you do, you already know how complicated it is and you do not need me to tell you.

The honest answer is that the deadline is not a single date. It is a rolling set of deadlines that depend on which correspondent banks you deal with, which countries you operate in, and how aggressively your clearing partners are pushing the migration. If your bank's main correspondent has already switched to MX, your deadline is effectively now. If they have not, you have more time — but not as much as you think. The phrase "we will deal with it next year" has been the epitaph of many failed migration projects.

What this means for T24

Temenos Transact R24 supports both MT and MX messages. The DE (Delivery) module handles message formatting, and the PP (Payments) module handles payment processing. Both modules have been updated to support ISO 20022, but support is not the same as configuration. "It supports it" is what the sales team says. "It is configured correctly" is what you need to be able to say.

Here is what actually needs to happen in T24:

Message format configuration

T24 uses DE.FORMAT.SWIFT for MT messages and DE.FORMAT.XML for MX messages. If your bank has never configured MX formats, these records may not exist, or they may exist with default values that do not match what your correspondent banks expect. The default values are what Temenos shipped. They are not what your correspondent bank uses. They are a starting point, not a finish line.

Each MX message type (pacs.008, pacs.009, camt.053, etc.) needs its own format definition. The format definition specifies which XML schema to use, which namespace to apply, and how T24 fields map to XML elements. If the mapping is wrong, the message will be rejected by the receiving bank with an error that looks like a technical failure but is actually a configuration gap. The error message will say something unhelpful like "invalid XML structure," and both sides will blame each other until someone checks the schema versions.

Translation rules

T24 has a DE.TRANSLATION application that handles MT-to-MX and MX-to-MT translation. This is critical during the migration period because your bank may receive an MX message from a correspondent that has migrated, but need to forward it as an MT message to a correspondent that has not. You are now a translator between two formats that were designed by committees that did not talk to each other.

The translation rules define how fields in one format map to fields in the other. Some fields map directly — the amount in an MT103 field 32A maps to the amount in a pacs.008 InterbankSettlementAmount. Other fields have no equivalent — MT messages do not have structured remittance information, so that data is lost in the translation. Your bank needs to decide what to do with that lost data, and the answer is usually "put it in a free-text field and hope the receiving bank reads it." This is not a strategy. It is a coping mechanism.

UETR generation

Every MX payment message requires a UETR (Unique End-to-End Transaction Reference). This is a 36-character UUID that tracks the payment from end to end. T24 generates UETRs automatically through DE.UETR.CATALOG, but if the UETR configuration is missing or incorrect, the message will be rejected. The error message will not say "UETR is missing." It will say something vague and unhelpful, and you will spend an hour tracing through logs before you realise the UUID was not generated.

The R24AMR release includes an enhancement for generating a unique UETR even when the same transaction reference is used multiple times. This matters more than it sounds like it matters, because retry logic in payment systems frequently resubmits the same transaction with the same reference, and without a unique UETR each time, the second submission looks like a duplicate. And then you get to explain to a business user why a payment that was sent twice only arrived once, and why that is actually correct behaviour.

What retail banks should do now

If your retail bank is still on MT messages and has not started the MX migration, here is what you should be doing today — not next year, not when the deadline is announced, today. Yes, today. Finish this article first, then do these things.

1. Find out which of your correspondent banks have already migrated.

This is the single most important piece of information. If your main USD correspondent has switched to MX, you need to be able to send and receive pacs.008 and pacs.009 messages. If they have not, you have more time, but you should still be testing. Call your correspondent banking team. Ask them. The answer will probably be "some have, some have not," which is the most stressful answer because it means you need to support both. It also means you get to maintain two sets of configuration, two sets of tests, and two sets of documentation. You did not sign up for this, but here you are.

2. Configure MX message formats in T24.

Set up DE.FORMAT.XML records for the message types you need. Start with pacs.008 (customer credit transfer) and pacs.009 (financial institution transfer). Test them in your non-production environment. Send test messages to SWIFT's testing environment. Fix the errors. Send them again. Repeat until the errors stop. This is the part of the project that looks simple on the project plan and takes three times longer than estimated.

3. Set up translation rules.

Configure DE.TRANSLATION for the MT-to-MX mappings you will need during the transition period. Test both directions — sending an MT message that gets translated to MX, and receiving an MX message that gets translated to MT. The translation will not be perfect, but it needs to be good enough that payments do not fail. "Good enough" is a technical term that means "the business accepts the limitations because the alternative is worse."

4. Update your RMA records.

RMA (Relationship Management Application) records need to be updated to allow MX message types. If your RMA only allows MT103 and MT202, incoming pacs.008 messages will be rejected even if everything else is configured correctly. This is the most common migration mistake — banks spend months configuring message formats and forget to update the one record that controls whether messages are accepted. It is the IT equivalent of installing a new front door and forgetting to unlock it.

5. Test with your correspondents.

Once your internal configuration is working, test end-to-end with your correspondent banks. Send a test MX message. Ask them to confirm they received it and could process it. Then ask them to send one back. If either direction fails, debug it together. This is the step that everyone skips because it requires coordination with another bank, and it is the step that causes the most production incidents when the migration goes live. The phrase "we tested internally and it worked" has been the opening line of many post-incident reviews.

What usually goes wrong

Having watched several banks go through this migration, the failures follow a predictable pattern. If you know what they are, you can avoid them. Or at least you can look like you knew what was coming when they happen anyway.

The RMA that was never updated.

The bank configures everything perfectly — message formats, translation rules, UETR generation — and then the first live MX message is rejected because the RMA record for that correspondent only allows MT message types. The fix takes five minutes. Finding the cause takes three days. Those three days will involve multiple bridge calls, several escalations, and at least one person saying "have you checked the RMA?" on the first day and being ignored.

The schema version mismatch.

SWIFT releases new versions of the ISO 20022 schemas every year. If your T24 system is using the 2023 schema and your correspondent is using the 2025 schema, the message will fail validation even though both sides are technically using ISO 20022. The error message will say something unhelpful like "invalid XML structure," and both sides will blame each other until someone checks the schema versions. That someone will be you, because it is always you.

The field that does not translate.

An MT103 has a field for "remittance information" (field 70). It is a free-text field with a 140-character limit. A pacs.008 has a structured remittance element with unlimited length and sub-fields for different types of remittance data. When you translate from MT to MX, the 140 characters go into the structured field. When you translate from MX to MT, the structured data gets truncated to 140 characters. Someone will lose information, and someone will complain about it. That someone will be a business user who does not care about message format limitations and just wants their data to arrive intact.

The testing that was never done.

The bank tests internally. Everything works. They go live. The first real payment fails because the correspondent bank's system handles MX messages differently from the test environment. The bank blames the correspondent. The correspondent blames the bank. The payment sits in a repair queue for three days while both sides insist the problem is on the other end. The repair queue, as always, is where payments go to contemplate their existence.

The big picture

The MT to MX migration is not optional. SWIFT is retiring the MT format, and every bank on the network will need to support ISO 20022 messages. The only question is when — and the answer is "sooner than your project plan says."

For retail banks running Temenos Transact, the migration is manageable. T24 supports both formats. The configuration is well-documented. The translation rules exist. But none of it works automatically — someone has to configure it, test it, and fix it when it breaks. That someone is probably you. The good news is that if you have read this far, you already know more about the migration than most of the people who will be on the bridge call when it goes wrong.

The banks that start now will have a smooth migration. The banks that start six months before the deadline will have production incidents, late-night calls, and a lot of explaining to do. You know which bank you work for. You know which one you want it to be. The choice is yours, but the deadline is not.