Articles / Learning brief
Translating MT to MX
Your notes
In simple terms / 01
What this means in plain language
Message translation converts between legacy MT and ISO 20022 (MX) formats. It preserves core payment data but can truncate the richer structured detail that MX carries, so a full round trip does not always survive intact.
Translation converts a payment message between the legacy MT (Message Type) format and the newer ISO 20022 (International Organization for Standardization standard 20022) format, often called MX. It is useful during a transition, when one bank has moved to the new format and another has not. Translation works well for the core facts of a payment, who pays, who is paid, how much, and in what currency, because both formats can hold them. The difficulty is that MX carries richer, more structured detail than MT was designed to hold. The older format uses short, fixed-length text lines, so when a structured MX message is translated into MT, longer names, full structured addresses, and detailed remittance information may be shortened or dropped to fit. Once that detail is lost, translating back to MX cannot recover it, because the original structure is gone. This is why a message that makes a full round trip from MX to MT and back can arrive thinner than it started.
Complete lesson / 02
Understand the full idea, step by step
Imagine copying a long, carefully structured address — house number, street, district, city, postal code, country, each on its own labelled line — onto a delivery slip that gives you just four short blank lines. You can still get most of it across. But the neat separations are gone, and anything that would not fit was left off. That is the quiet problem at the heart of message translation.
Message translation — converting a payment between MT and MX formats
Translation maps the fields of one message format onto another so processing can continue when the two ends have not upgraded together. MT (Message Type) is the legacy SWIFT format built from short, fixed-length text lines; MX is the common shorthand for ISO 20022, which breaks the same information into many labelled elements. A translator moves what both formats can hold — it can only ever carry what the target format has room for.
What maps cleanly
The essential content of a payment crosses over without loss, because both formats have a clear home for it: the paying party, the party to be paid, the amount, the currency, the value date, and the main reference numbers. For these, translation is a fair bridge — a payment created in one format can be read in the other and still be the same payment. The trouble is never with the fields the two formats share. It is with the fields only the newer, richer format can express fully.
| Information | Legacy MT | ISO 20022 (MX) |
|---|---|---|
| Creditor address | A few short free-text lines | Separate street, town, postal code, country elements |
| Remittance detail | Limited fixed-length lines | Structured or longer unstructured detail |
| Party identification | Name-and-address text | Structured name plus coded identifiers |
| Purpose of payment | Often only free text, if present | A dedicated purpose-code element |
Where truncation happens
When a message is translated from the richer format into the older one, that abundance has to fit into a smaller, flatter space. Longer names are shortened, structured addresses are flattened into free-text lines, and detailed remittance may be cut to length or dropped. This is truncation — not a fault in the translation software, but a consequence of pouring structured data into a container that was never designed to hold it. The fields most at risk are exactly the ones that improve automated screening and reconciliation, because those depend on data being separated and complete.
So a translated message can be technically correct and still leave the receiver worse off?
Yes — and that is the subtle part. The translated message is valid; it just carries less than the sender intended to provide. A screening engine that expected a structured country element now sees a name and address mashed into one line; a reconciliation system that matched on structured remittance now has a truncated reference. Nothing errored. The receiving bank simply has less to work with, which means more manual review and weaker automated matching.
WHAT IF — A message is translated MX to MT and then back to MX (a round trip)
What happens: The message returns in the newer format but carries less than the original. The first step collapsed structure into text and dropped whatever would not fit; the second step cannot rebuild a structured address from a single free-text line or restore remittance characters that were cut.
How it is handled: Institutions avoid unnecessary round trips and, where possible, process ISO 20022 natively from initiation to posting so the structured data is captured once and carried unbroken. Maya's operations team treats a stalled or thin payment traced to a round trip as a data-quality break, not a routing fault.
REMEMBER IT
Hold onto one line: translation preserves syntax, but not always richness. A translated message is still a valid message — it just may say less than the one it came from. What a format cannot hold, a translation cannot carry; and what it could not carry, it can never later return.
FOR NOW, REMEMBER
- Translation bridges MT and MX so payments flow while institutions upgrade at different speeds.
- Core fields — payer, payee, amount, currency, value date, references — map cleanly.
- Rich structured data (structured addresses, long remittance, coded identifiers, purpose codes) can be truncated when it is squeezed into the flatter MT format.
- A round trip cannot restore what the first crossing dropped, so native ISO 20022 processing is safest for the richer data.
TRY IT YOURSELF
A payment starts as a structured ISO 20022 message with a full four-part creditor address and detailed remittance. It is translated to MT for one leg, then translated back to ISO 20022 for the final bank. What should the final bank expect?
Now that the message can carry rich, structured parties end to end, we can look at how cross-border payments actually route through correspondents in ISO 20022 — the serial path versus the cover path — and why the cover repeats the customer.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Translation preserves the core payment facts that both MT and ISO 20022 formats can hold.
- 02
The legacy MT format's short, fixed-length lines can truncate the richer structured data an MX message carries.
- 03
Detail lost in an MX-to-MT step cannot be rebuilt by translating back, so a round trip can lose information permanently.
Practical use cases / 04
Where you would use this
A bank mid-transition translates incoming MX messages to MT so its legacy processing systems can still book the payment.
An operations analyst investigates why remittance detail is missing and traces it to a truncating MX-to-MT translation upstream.
A standards team decides to process ISO 20022 natively end to end rather than translate, to preserve structured data for screening.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Meridian Trust, receives an ISO 20022 pacs.008 message carrying a structured remittance of 140 characters and a creditor address split into 5 separate elements. It translates the message into a legacy MT103 for an older internal system. The MT103 remittance field allows only 4 lines of 35 characters, so 140 characters must be compressed and the structured address collapses into free text. A downstream bank, a fictional institution called Kestrel Union Bank, later translates the MT103 back into ISO 20022, but the 5 address elements cannot be rebuilt from one text block, so the payment of GBP 22,400.00 settles with poorer data than it began with.
Evidence & review / 07
Evidence & review
Interbank payment messaging translated between legacy SWIFT MT and ISO 20022 (MX) during and after the cross-border migration.
What this brief simplifies: Field-length and truncation behaviour is described at a teaching level; exact element maps and character limits are set by the standards and the translation rules in force. Named parties are fictional teaching cast.
Sources for this brief4
- Market practice
Payments Market Practice Group market practice documents ↗ — Payments Market Practice Group · MT and ISO 20022 translation and coexistence guidance
The PMPG publishes individual papers via the Swift website; its recommendations are market practice, not binding scheme rules, and adoption varies between institutions.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT message structure and field lengths
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · Structured party, address, and remittance elements
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.