Structured Addresses and the ISO 20022 Address Parser: Getting Ready for CBPR+ 2026

From November 2026, CBPR+ starts retiring fully unstructured postal addresses in cross-border payments. Here is a technical preview of an ISO 20022 address parser that turns free-text party addresses into structured PstlAdr output.

From November 2026, CBPR+ usage guidelines begin retiring fully unstructured postal addresses in cross-border payments, and that turns a quiet data-quality problem into a deadline.

I have been building an ISO 20022 Address Parser: a technical preview that turns free-text party-address data into structured ISO 20022 PstlAdr output. You can see the ISO 20022 Address Parser project page for the demo video and reference posture, and the public https://iso20022-address-parser.raafetchoukri.com/" target="_blank" rel="noopener noreferrer">landing page at iso20022-address-parser.raafetchoukri.com.

Why structured addresses, and why now

ISO 20022 migration has already reshaped how payment messages carry data. Party addresses are one of the last hard parts. Under CBPR+, fully unstructured address lines are being phased out in favour of structured and hybrid ISO 20022 addresses, where the town, post code, country, street name, and building number each sit in their own PstlAdr element instead of a single free-text blob. In practice, that means turning every ISO 20022 address format you hold into a structured address ISO 20022 layout, where each field is correct and not just tidy.

The standard is clear. The data is not. Most real address data still lives as free text in beneficiary files, customer master data, ERP payment records, and onboarding systems. Getting from that text to a correct structured address, at scale, is the actual work.

Why party addresses are hard to structure

Address text is messy in ways that defeat naive splitting:

- The same country writes addresses in several different orders.
- Building numbers, sub-buildings, floors, and PO boxes hide inside street lines.
- Town, region, and post code blur together, and post-code formats vary widely.
- Free-text lines mix language, punctuation, and abbreviations inconsistently.

Guess wrong and the cost is familiar: repairs, investigations, and payments that stall while someone reconciles a record by hand.

How the parser works

This is not a single model call or a generic extraction demo. The parser uses a hybrid workflow:

- Routing and cleanup normalise the raw input before anything else runs.
- libpostal hints add a strong statistical prior on how the address decomposes.
- A fine-tuned 4B model, served from a private, token-gated inference endpoint, does the structured parse.
- Post-model rules and strict PstlAdr validation catch what the model gets wrong and enforce the schema.
- Confidence bands and reason codes travel with every field, so a reviewer can see what the parser was sure about and what it was not.

The goal is a parse that is constrained, reviewable, and operationally useful, rather than a black box that quietly rewrites addresses.

What the evaluation shows, and what it does not

My own V3 qualification eval reached 85.87% micro field accuracy on 2,000 cases held out and hash-segregated from training, and every one of those cases produced well-formed final XML.

Those are my own evals, not an external benchmark and not a promise on anyone else's data. Official ISO 20022 XSD validation is not enabled yet. This is a technical preview, not a production or compliance system, and it is not affiliated with, approved, or endorsed by Swift.

What I am looking for

After about nine years at Swift, much of it on SwiftRef, the BIC directory, and bank reference data, the part I care about now is expert pressure on the hard cases.

If you work on beneficiary data, customer master data, ERP payment data, onboarding records, repair queues, or ISO 20022 migration, two questions are worth your time: which address formats cause you the most pain, and what signal would you need before trusting structured output?

There is no active customer yet, and two interested parties so far. The live demo runs as a small hosted mini platform rather than a public API, and both the interface and its processing are password-gated for now, so a cold click will not run the parser. If you want to pressure-test it, share public or fabricated address examples in the formats that break things. Please do not send personal data, customer or beneficiary records, account numbers, payment records, SSI records, or licensed reference-data extracts.

You can read more on the ISO 20022 Address Parser project page, or get in touch if structured-address readiness is on your roadmap.

#ISO20022 #CBPRPlus #StructuredAddress #Payments #DataQuality #ReferenceData #Migration

Topics: ISO 20022, CBPR+, Structured Address, Payments, Data Quality, Reference Data, SWIFT, Migration