ISO 20022 Structured Address (PstlAdr): 14 Elements & 6 Rules

I sat in a Tier-1 bank's payments architecture review last month. The lead architect could draw their sanctions-screening topology from memory. He could name every clearing connector, every channel adapter, every middleware engine. When I asked him which XML element his customer channel mandates as structured today, he paused. Then he asked his colleague. His colleague checked the wiki.

Six months from the November 2026 cutover, and the team running one of Europe's busiest correspondent-banking corridors could not name the field <TwnNm>.

That conversation is the rule, not the exception. The November 2026 deadline is no longer the constraint on a clean migration. The vocabulary is. After thirty years inside payments infrastructure programmes, I've learned that every migration of this size eventually reduces to a small set of fields nobody bothered to name out loud. Address structuring is that set of fields.

What follows is the field-level reference I wish had existed when we started building ioNova: the 14 <PstlAdr> elements the deadline regulates, the three address modes you may legitimately ship, the three failure patterns that fail post-cutover validation, and the six validation rules every pipeline must enforce. Nine minutes of reading. Years of expensive remediation avoided.

The 14 Elements the Deadline Regulates

The ISO 20022 <PstlAdr> container holds 14 operationally-used structured elements, plus the free-text <AdrLine> element that sits alongside them. The native schema defines 17 child elements in total; three — <AdrTp>, <CareOf>, <UnitNb> — sit outside the November 2026 operational profile.

Two of the 14 are mandatory under CBPR+ and HVPS+ from 15 November 2026: <TwnNm> and <Ctry>. The other twelve are optional. Get the two mandatory ones right and your payment is, at minimum, a valid hybrid address. Get them wrong and the message is rejected at the channel ingestion layer post-cutover — with no downstream repair.

Table 1. The 14 operational <PstlAdr> elements plus <AdrLine>. Source: BIS-021 §0.31 / Table 1.1; PMPG-2025.

Two takeaways most teams miss

<AdrLine> is not one of the 14. It is the free-text companion that exists alongside them. Its native cardinality in the ISO 20022 XSD is [0..7]. The BIS-021 §0.31 cap for CBPR+ and HVPS+ is [0..2]. That gap — between what the XSD permits and what the usage guideline enforces — is where most validation failures happen. Pipelines that validate against the bare XSD pass this and fail in production.

<CtrySubDvsn> must now be in ISO 3166-2 format. BIS-021 §4 footnote requires US-CA for California, GB-ENG for England, DE-BY for Bayern. The string "California" passes the XSD and degrades automated routing. This is a 2026 change worth flagging to the team responsible for static-data maintenance.

The Three Modes, Side by Side

ISO 20022 permits three address modes. From 15 November 2026, fully unstructured is decommissioned for CBPR+ and HVPS+. The two compliant options are structured and hybrid.

Below: the same worked address — Mohammed Ali Trading Co, 169 Cuba Street, Wellington 6011, New Zealand — in all three modes, so the differences are visible side by side.

<Cdtr>
  <Nm>MOHAMMED ALI TRADING CO</Nm>
  <PstlAdr>
    <StrtNm>CUBA STREET</StrtNm>
    <BldgNb>169</BldgNb>
    <PstCd>6011</PstCd>
    <TwnNm>WELLINGTON</TwnNm>
    <Ctry>NZ</Ctry>
  </PstlAdr>
</Cdtr>

<Cdtr>
  <Nm>MOHAMMED ALI TRADING CO</Nm>
  <PstlAdr>
    <PstCd>6011</PstCd>
    <TwnNm>WELLINGTON</TwnNm>
    <Ctry>NZ</Ctry>
    <AdrLine>169 CUBA STREET</AdrLine>
  </PstlAdr>
</Cdtr>

<PstlAdr>
  <AdrLine>MOHAMMED ALI TRADING CO</AdrLine>
  <AdrLine>169 CUBA STREET</AdrLine>
  <AdrLine>WELLINGTON 6011</AdrLine>
  <AdrLine>NEW ZEALAND</AdrLine>
</PstlAdr>

The Three Failure Patterns That Fail Post-Cutover Validation

If only one section of this piece is forwarded internally, it should be this one. These are the three patterns the post-cutover validation layer catches.

<PstlAdr>
  <TwnNm>WELLINGTON</TwnNm>
  <Ctry>NZ</Ctry>
  <AdrLine>MOHAMMED ALI TRADING CO</AdrLine>
  <AdrLine>169 CUBA STREET</AdrLine>
  <AdrLine>WELLINGTON 6011</AdrLine>     <-- third line: fails
</PstlAdr>

<PstlAdr>
  <Ctry>NZ</Ctry>
  <AdrLine>MOHAMMED ALI TRADING CO</AdrLine>
  <AdrLine>169 CUBA STREET, WELLINGTON 6011</AdrLine>
</PstlAdr>

<PstlAdr>
  <PstCd>6011</PstCd>
  <TwnNm>WELLINGTON</TwnNm>
  <Ctry>NZ</Ctry>
  <AdrLine>169 CUBA STREET, WELLINGTON 6011, NEW ZEALAND</AdrLine>
</PstlAdr>

Two Rulebooks, One Effective Date

Two regulatory frameworks govern structured-address requirements at the November 2026 cutover. They are aligned in intent but not identical in detail.

Table 2. The three regulator positions at a glance.

The EPC and CBPR+ rules align on the two mandatory fields. Both rulebooks treat <TwnNm> and <Ctry> as the structural minimum. The EPC's published rationale (EPC-2025 p.8) is direct: those are the two fields the sanctions engines actually read. Everything else is structurally optional from the EPC's perspective — though omitting structured detail still degrades the data-quality profile.

The CBPR+ Phase 5 [0..2] cap on <AdrLine> is the constraint XSD-only validation misses. The native ISO 20022 XSD allows up to seven occurrences. The CBPR+/HVPS+ usage guideline allows two. If your CI pipeline validates only against the XSD, you have a gap — and pattern 1 in §3 above is the failure that gap produces.

The Six Validation Rules Every Pipeline Must Enforce

For the next architecture-team review meeting. Six rules every validation pipeline must enforce — and the one line that matters most about them, at the end.

Sources

• EPC-2025 — EPC Guidance Document: Provision of Addresses under the EPC Payment Schemes, 2025.
• BIS-020 / BIS-021 — Harmonised ISO 20022 Data Requirements and Technical Annex, BIS / CPMI, February 2026.
• PMPG-020 — Hybrid Postal Address — Grace Period Guide for Banks, PMPG, December 2025.
• PMPG-040 v1.12 — Hybrid Postal Address White Paper, PMPG, 5 March 2026.
• PMPG-050 — Farewell to Unstructured Postal Addresses (Point-of-Entry Validation), PMPG, April 2026.
• PMPG-060 — Mission Possible — From Here to Data Quality, PMPG, May 2026.

Parth Desai is Founder & Chairman of ioNova AI and has spent thirty years inside payments infrastructure programmes at correspondent banks, RTGS operators, and market-infrastructure vendors. Ishan Joshi leads the technical architecture team at ioNova and signs off all XML examples and validation rules in this piece. Together they are building ioNova's Address Intelligence engine for the November 2026 cutover.

Frequently Asked Questions