The ISO 20022 Truncation Ledger: What Rich Data Actually Loses in Transit

ISO 20022 carries a 140 character debtor name, a structured postal address, ultimate parties, and structured remittance references. A legacy MT hop carries four lines of 35 characters. Every payment that crosses a non-native leg is degraded, the degradation is not reversible, and the message that emerges on the far side is structurally valid, which is exactly why nobody notices.

The business case for ISO 20022 is rich data. The delivery reality is that data is only as rich as the poorest hop it passes through, and during any migration period a meaningful share of traffic passes through at least one poor hop. Nobody publishes a ledger of what that costs, so each programme rediscovers it, usually when a compliance team asks why a screened name is missing its last eleven characters.

This is that ledger, and the requirement pattern that goes with it. It builds on the MT to ISO 20022 mapping: the mapping tells you which field becomes which, and this tells you what does not survive the trip. The domain grounding for the whole subject is in Break Into Banking.

What are the six ways data is lost?

Only one is simple truncation, and treating all six as “truncation” is why the problem gets underestimated in scoping.

Length truncation. The value is longer than the target field. A 90 character legal name into a 35 character line. Visible, measurable, and the easiest to catch.

Structure flattening. Discrete elements are concatenated into free text. StrtNm, BldgNb, PstCd, TwnNm, and Ctry become three lines of address text. No characters need to be lost for the meaning to be lost, because a downstream system can no longer ask “which country is the debtor in” without parsing prose.

Cardinality loss. The source permits more occurrences than the target. Seven address lines into four. Multiple remittance blocks into one. The overflow is dropped, and which occurrence gets dropped is an implementation choice nobody documented.

Party loss. An entire party has no home in the target format. Ultimate debtor and ultimate creditor are the standard example: they exist in ISO 20022 to identify the party on whose behalf a payment is made, and a legacy format has nowhere to put them, so they are appended to a remittance field or discarded.

Code mapping loss. A code list in the source is richer than the target’s. A purpose code that maps to a coarser category, or to nothing. The payment still settles; the reason it was made stops being machine readable.

Character folding. The target character set is narrower. Accented and non-Latin characters are folded or substituted, so Müller becomes Muller or MULLER. Harmless looking, and it changes what a screening engine matches on.

Six mechanisms, six different business consequences, and only the first shows up in a naive gap analysis that compares field lengths.

The ledger: what survives, what does not

The exact widths and rules come from the scheme usage guideline and the message version in play, so treat this as the shape of the analysis rather than as a substitute for reading yours.

ISO 20022 element	Native capacity	Legacy destination	Loss mechanism	Consequence
Dbtr/Nm, Cdtr/Nm	140 characters	One line of 35 in the party field	Length	Screening runs on a shortened name
PstlAdr structured components	Discrete street, building, postcode, town, country	Address lines of 35 characters	Flattening, length, cardinality	Country and town no longer machine readable
PstlAdr/AdrLine	Up to 7 lines of 70	3 lines of 35	Cardinality, length	Lines beyond the limit dropped
UltmtDbtr, UltmtCdtr	Full party structures	No equivalent field	Party loss	On-behalf-of relationship lost or pushed to free text
RmtInf/Ustrd	140 characters, repeatable in the base standard	4 lines of 35, so 140 total	Cardinality	Second and later occurrences dropped
RmtInf/Strd	Structured document references, amounts, dates	No equivalent	Party of structure loss	Automated invoice matching becomes text parsing
Purp, CtgyPurp	Full ISO code lists	Partial or no equivalent	Code mapping	Purpose of payment no longer structured
UETR	36 character UUID	Carried in the header	None	Survives, which is the point of it
IntrBkSttlmAmt with Ccy	Decimal with currency-driven precision	Amount field	Format normalisation	Usually clean, watch zero-decimal currencies
Non-Latin characters anywhere	Broad character repertoire	Restricted character set	Folding	Names change shape for matching purposes

Two rows deserve emphasis because they are the ones stakeholders find surprising.

The remittance row punctures the most common claim made in ISO 20022 business cases. People say the standard gives you far more room for remittance information than the legacy field did. In the base standard, with repeating occurrences, that is true. Under a typical cross-border usage guideline restricting unstructured remittance to a single occurrence of 140 characters, the effective capacity is the same 140 characters as before. The real gain is the structured block, which is genuinely better, and which is also the element most likely to be unsupported by a counterparty. Promise the structured block, not the character count.

The ultimate parties row is the one that reaches the business fastest. A payment factory or a collections agent moving money on behalf of named underlying parties is exactly the case ISO 20022 added those elements for, and it is exactly the case that breaks when a leg cannot carry them.

Why is the round trip the real problem?

Because translation is not reversible, and the second encoding hides the evidence.

Consider a payment that starts native, crosses one legacy leg, and is re-encoded into ISO 20022 by the next agent. The debtor address goes in as structured components, is flattened into address lines at the legacy hop, and comes out the far side as ISO 20022 address lines. The final message is schema valid. It satisfies its usage guideline, assuming the guideline still permits address lines. It looks like a normal ISO 20022 payment.

Sent by the originator, structured:
  StrtNm     Rue de la Loi
  BldgNb     16
  PstCd      1000
  TwnNm      Brussels
  Ctry       BE

After the legacy leg and re-encoding, flattened:
  AdrLine    RUE DE LA LOI 16
  AdrLine    1000 BRUSSELS BE

Nothing downstream can tell that this address was once structured, and nothing can reliably restore it: 1000 BRUSSELS BE is parseable by a human and a guess for a machine. This is why the structured address mandate is enforced by deadline rather than by encouragement. A rule that says addresses must be structured only works if every party is native, which is the actual reason the coexistence period had to end.

The analyst point is sharper than the technical one. Because the degraded message is valid, the loss is invisible to every system that receives it, and therefore invisible to every report about data quality built on those systems. If you want to know how much of your traffic is degraded, you have to measure it at the hop where it happens, not downstream. That means logging truncation events at the point of translation, which almost nobody specifies until after the first compliance question.

What do you specify? A truncation policy per field

The instinct is to prevent all loss. That is not achievable while any counterparty is non-native, so the deliverable is not prevention, it is an explicit, signed decision per field. Three policies cover it.

Truncate and log. Acceptable where the shortened value remains fit for its purpose. Log the field, the original length, and the payment identifier so the volume is measurable.

Reject at submission. Correct where the shortened value would be wrong rather than short. Reject early, in your own channel, with a clear message to the originator, rather than letting a scheme reject it later. The difference in customer experience between a validation error in two seconds and a rejection three hours later is the whole argument.

Route to repair. Correct where a human can complete or correct the value, typically for a low volume, high value flow where rejecting is worse than a short delay.

Written as a requirement, one field looks like this:

REQ-208. Where Dbtr/Nm exceeds the capacity of the outbound format, the payment shall be routed to the repair queue and shall not be truncated automatically. A truncation candidate event shall be raised carrying the payment UETR, the field name, the original length, and the target length. Rationale: the debtor name is an input to sanctions screening, so an automatic shortening changes the effectiveness of a regulatory control.

The rationale sentence is what gets this requirement approved rather than optimised away, because it moves the decision out of engineering convenience and into control effectiveness, which is where it belongs. Everything downstream of a truncated name is a blast radius question.

The equivalent decision has to be made for inbound messages too, and it is usually forgotten. When you receive a payment whose remittance information is clearly the wreckage of a structured block, do you store the text, attempt to parse it, or flag it? Answering that in analysis prevents a well meant parser from inventing structure that was never there. The full method for turning constraints like these into buildable specifications is in From Vague BR to Functional Requirements.

How do you test for loss?

With a maximum fill message and an assertion at every hop. This is the technique that turns an abstract risk into a defect report.

Build a maximum fill message. Every element populated to its maximum permitted length, with distinctive content so truncation is obvious at a glance. Use a marker at the end of each long value, so a name ending ...ZZEND tells you instantly whether it survived.

Dbtr/Nm            140 chars ending "ZZEND"
StrtNm             70 chars ending "STEND"
TwnNm              35 chars ending "TWEND"
AdrLine            7 occurrences, each 70 chars, numbered 1 to 7
RmtInf/Ustrd       140 chars ending "RMEND"
UltmtDbtr/Nm       140 chars ending "ULEND"
Purp/Cd            a valid code

Assert at every hop, not just at the destination. Capture the message as sent, as it leaves each translation point, and as received. The diff between captures is the ledger, measured rather than assumed.

Build a minimum fill message too. Everything optional omitted, everything mandatory at its shortest legal value. It catches the opposite defect: systems that assume optional elements are always present and fail on a legitimately sparse message.

Test the non-Latin case explicitly. A debtor named with accented or non-Latin characters, asserted through the chain. Character folding is the loss mechanism most likely to be absent from a test pack, because test data is usually generated in ASCII by people who write in ASCII.

Make the truncation event a test assertion. If the requirement says truncation raises a logged event, then a test that truncates and produces no event is a failing test. Otherwise the logging is implemented, deployed, and quietly broken six months later, and the first person to notice is a regulator.

Each of these is negative test design applied to data fidelity rather than to error handling, and the maximum fill message belongs in the regression pack permanently, because truncation behaviour regresses whenever anyone touches a mapping.

The takeaway

ISO 20022 data is only rich end to end if every hop is native and every usage guideline permits it, and during any migration window that is not the case. Loss arrives through six distinct mechanisms: length truncation, structure flattening, cardinality loss, party loss, code mapping loss, and character folding, and only the first is caught by comparing field widths.

Translation is not reversible, so a payment that crosses a legacy leg and is re-encoded emerges structurally valid and permanently poorer, with no downstream signal that anything happened. Measure at the hop where loss occurs, not after it. Then specify a policy per field, truncate and log, reject at submission, or route to repair, with a rationale that names the business consequence, because a shortened debtor name is a control effectiveness question rather than a formatting one. Prove all of it with a maximum fill message asserted at every hop, and keep that message in the regression pack forever.

Start with Break Into Banking for the payments domain and Real-World BA Deliverables for the mapping and specification templates, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, Payments, Data Quality, Systems Analysis, Migration