Enriched Data and the End of Truncation

If you have ever received a payment with a reference like "INV0012 PARTIAL PA" cut off mid-word, you have met truncation. Legacy payment formats were built when bandwidth and storage were scarce, so they imposed tight character limits on almost every field. Anything longer was chopped to fit. The result was payments arriving with mangled names, incomplete addresses and useless references. ISO 20022 enriched data is the industry's answer: fields large enough and structured enough that information no longer has to be destroyed to travel.

Why legacy formats truncated

The dominant cross-border format, SWIFT MT, was defined in an era of expensive telecommunications. Fields were fixed and short — remittance information in a customer credit transfer was famously limited to four lines of thirty-five characters. Party fields were similarly cramped. When a real-world name, address or invoice list exceeded the allowance, the sending system simply cut it. There was no room to carry a full structured address, multiple invoice references, or a complete legal entity name. Truncation was not a bug; it was the format working as designed under old constraints.

What truncation actually costs

Clipped data is not a cosmetic annoyance — it breaks downstream processes:

• Reconciliation fails. If the remittance reference that ties a payment to an invoice is cut, the receiver cannot automatically match cash to invoices and must investigate manually.
• Compliance suffers. Sanctions and AML screening need complete names and addresses; truncated party data causes both missed hits and false positives.
• Repairs and delays multiply. Incomplete information triggers manual repair, exception handling and inquiries between banks, each adding cost and time.

The hidden expense of truncation is enormous operational friction, all to save characters that modern systems no longer need to ration.

How ISO 20022 ends it

ISO 20022 attacks truncation on two fronts: size and structure. Fields are far more generous — remittance information can carry substantially more characters and multiple structured entries — and, more importantly, data is broken into discrete labelled elements rather than a single blob. A structured remittance block can carry each referenced document type, number and amount as its own field, so a payment settling ten invoices can name all ten in a machine-readable way. Party details separate name, structured address and identifiers. Nothing has to be squeezed into a line that was never big enough.

Structured versus unstructured remittance

ISO 20022 supports both unstructured remittance (free text, useful for human-readable notes) and structured remittance (discrete fields for referenced documents, amounts and creditor references). The structured form is what enables straight-through reconciliation: a receiver's system can read the referenced invoice numbers and amounts directly and match them without a human. Carrying a standardised creditor reference lets the payer echo back exactly the identifier the biller expects, closing the loop automatically.

The migration is not automatic

There is a catch that trips up many firms. Simply moving to an ISO 20022 pipe does not end truncation if institutions keep behaving as though they are still on legacy formats. During migration, messages often pass through translation between MT and MX, and a naive translation can copy old truncated free text into the new rich fields — preserving the disease while adopting the cure. Realising the benefit requires banks to actually populate structured fields at origination and to avoid lossy round-trips. This is why market infrastructures have set deadlines requiring fully structured data rather than allowing indefinite coexistence.

The payoff

When enriched data flows end to end, the benefits compound. Corporates get automatic reconciliation and cleaner cash application. Banks get lower repair rates and better screening. Regulators get the transparency they demand. And end users stop seeing cryptic clipped references, because the reference finally fits. The end of truncation is less a single feature than the precondition for every other data-driven improvement in modern payments.

Key takeaways

• Legacy formats truncated names, addresses and references because their fields were short by design.
• Truncation breaks reconciliation, weakens compliance screening, and drives costly manual repairs.
• ISO 20022 ends truncation with larger, structured fields that carry full party and remittance detail.
• Structured remittance lets receivers match multiple invoices automatically without human intervention.
• The benefit is only realised if firms populate structured fields at source rather than copying old free text.