MT-to-MX translation and truncation
What happens when rich ISO 20022 data must fit MT fields and back — truncation, address handling, and one-to-many mappings.
IN ONE LINE
Analogy: translating between MT and ISO 20022 is like moving between a detailed multi-page form and a telegram with fixed-size boxes.
Going from telegram to form, you must guess which parts of a run-together line are the name and which are the street — the information was never labelled, so the guessing can go wrong.
Going from form to telegram, there is simply not enough room: long names get cut short, separately labelled boxes get squashed into shared lines, and the labels themselves disappear.
Both directions can be done carefully, and rulebooks exist for how to do them, but neither direction is lossless — and someone downstream always has to work with whatever survived the squeeze.
WHAT IT ACTUALLY IS
Translation between MT and ISO 20022 exists because the world could not flip formats in one night.
During the migration, one leg of a payment often spoke MT while another spoke MX; and even now that the network coexistence period for cross-border payment instructions has ended, older interfaces inside banks — screening systems, archives, corporate channels — may still expect MT-shaped data.
Translation maps the MT103 to and from the pacs.008, and the MT202 and MT202 COV to and from the pacs.009.
The recurring problems are three: structured data collapsing into unstructured lines, field length differences forcing truncation, and one-to-many mappings, where a single MT field feeds several ISO elements or several ISO elements must share one MT field.
HOW IT WORKS
The address is the emblematic case.
ISO 20022 offers labelled elements — street name, building number, town, country.
The MT format offers a handful of fixed-length free-text lines.
MX-to-MT translation must flatten labelled data into those lines, truncating what does not fit and flagging that truncation occurred; MT-to-MX translation must either park the lines in unstructured elements or attempt risky parsing.
This is why screening teams care so much: a country code in a labelled element is reliably screenable, while the same code buried mid-line may be missed or may trigger a false positive.
Truncated party data is worse still — the tail of a name that would have matched a sanctions list entry may be exactly the part that was cut.
Sound practice is to screen the richest available format, before any lossy step.
THE WORDS
- Like-for-like translation
- Converting a message to another format carrying only what the target format can hold — accepting that some data is left behind rather than inventing a place for it.
READ FIRST
CONNECTED TO
SOURCES
- Payments Market Practice Group market practice documents — Payments Market Practice Group
- Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines — Swift (CBPR+ working group)
- Wolfsberg Group Payment Transparency Standards — The Wolfsberg Group
- Payments Signal editorial teaching models — Payments Signal
Derived from MT-to-MX translation and truncation. Every claim on this card is sourced on that page.