MT-to-MX translation and truncation

L0 Explain simply

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.

MT messageMX message

L1 Core concepts

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.

MT103pacs.008

L2 Practitioner view

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.

ScreeningFalse positiveSanctions list

L3 Technical details

Operational placements vary: some institutions translate at the gateway and keep MT internally; some run ISO-native cores and translate only for legacy interfaces; many run mixed estates where the same payment exists in both shapes and reconciliation depends on the UETR tying the pair together. Two disciplines matter. First, treat translated output as derived data — in an investigation, always pull the original message, because translation abbreviates and discards. Second, watch the address timeline: the cross-border guidelines are phasing out fully unstructured postal addresses, with structured or hybrid addresses required from November 2026, which shifts the burden from clever parsing to capturing clean data at source. Institutions that fix data capture in their channels avoid most translation pain; institutions that rely on repair queues pay for it on every payment.

UETRReconciliation

L4 Standards & sources

The reference points: SWIFT and the Payments Market Practice Group publish the MT–MX translation rules and accompanying market practice — field-by-field mapping tables, truncation conventions, and guidance for cases where no clean mapping exists. The CBPR+ usage guidelines define the target shape on the ISO side, including the address structuring timeline. Nothing in these documents removes an institution's responsibility for the data: supervisors and industry transparency standards expect originator and beneficiary information to survive format conversion, so "the translator dropped it" is not an accepted defence. Our account simplifies by treating translation as one generic process; in practice each institution combines central utilities, vendor translators, and in-house mappings, each with slightly different behaviour at the edges.