MT to MX: Mapping SWIFT Messages to ISO 20022

For decades, cross-border payments ran on SWIFT's MT (Message Type) format — compact, numbered messages like MT103 for a customer credit transfer and MT202 for a bank-to-bank transfer. The industry is now migrating these flows to ISO 20022, whose XML-based messages are often called MX. Understanding the MT-to-MX mapping is essential for anyone working on correspondent banking, and it reveals why the transition is genuinely difficult.

MT and MX: two very different shapes

MT messages are terse. An MT103 uses numbered, tagged fields — field 50 for the ordering customer, field 59 for the beneficiary, field 70 for remittance information — often with free-text lines and tight length limits. They are efficient but semantically thin: a lot of meaning is packed into unstructured text that humans and heuristics must interpret.

MX messages are the opposite. The ISO 20022 equivalent of an MT103 is pacs.008 (FIToFICustomerCreditTransfer). Instead of terse tags, it uses richly nested XML elements with explicit structure: separate elements for name, structured postal address, account identification, and structured remittance data. The MT202 bank-to-bank transfer maps to pacs.009, and other MT messages have their own MX counterparts across the pacs, pain, and camt families.

Why the mapping is not one-to-one

The temptation is to think of MT-to-MX as a simple field translation. It is not, and the reason is asymmetry. MX carries far more structured data than MT can express. When you translate MX to MT — which happens whenever a modern sender reaches a counterparty still on legacy MT — you must squeeze structured, richly detailed data back into narrow MT fields. That risks truncation: dropping or flattening data that will not fit.

Truncation is not a cosmetic problem. If a structured address or a party identifier is lost, downstream sanctions screening and reconciliation can degrade. This is why the industry treats data integrity across the boundary as the central risk of coexistence, and why market practice guidelines define exactly how fields should map to minimise loss.

The coexistence period

SWIFT set out a migration for cross-border payments and reporting in which MT and MX coexist for a transition window before MT is retired for these flows. During coexistence, the network relies on interoperability so that institutions on different formats can still transact. In practice, this means translation services convert between MT and MX, and the guiding principle is that data captured in richer MX form should be preserved and carried through even when a leg of the journey passes through an MT-capable party.

The mechanism that preserves this end-to-end richness is a transaction data store: the full ISO 20022 data is kept intact and made available so that even if an intermediate hop uses a leaner format, the complete structured data can be reunited with the payment. This protects against the truncation problem across multi-hop correspondent chains.

What builders gain from MX

• Structured parties. Names, addresses, and identifiers are discrete elements rather than free text, which dramatically improves automated screening and matching.
• Structured remittance. Invoice references and payment purpose travel in dedicated fields, improving straight-through reconciliation for corporates.
• Richer purpose and category codes. Standardised codes replace ambiguous free text, aiding compliance and analytics.
• Consistency with domestic rails. Because many domestic instant schemes also use ISO 20022, cross-border and domestic data models converge.

Practical advice

If you are building against these flows, model your data on the MX structure even if some counterparties still send MT. Treat MT-to-MX conversion as lossy and MX-to-MT as risky, and design so that structured data is never silently discarded. Follow published market practice mappings rather than inventing your own field logic, because sanctions and reconciliation systems downstream expect the standard placement of data. When you must generate an MT leg from richer MX data, log exactly what was truncated so that the loss is auditable rather than invisible, and prefer to carry the full structured record forward wherever the network allows it.

Key takeaways

• SWIFT's terse MT messages (MT103, MT202) are migrating to ISO 20022 MX messages (pacs.008, pacs.009).
• MX carries far more structured data — discrete party, address, and remittance elements — than MT can express.
• The mapping is asymmetric: MX-to-MT risks truncation, which can degrade sanctions screening and reconciliation.
• During coexistence, translation and a transaction data store preserve full ISO 20022 data across multi-hop correspondent chains.
• Build on the MX data model, treat conversions as lossy, and follow published market practice mappings.