Introduction
Postal address data has long been one of the weakest links in cross-border payments. While names and accounts are often well-defined, addresses historically traveled as free text, limiting automation, weakening sanctions screening, and increasing repair rates.
ISO 20022 introduced rich, structured postal address elements to solve this problem. However, real-world data realities slowed adoption. To bridge the gap between legacy practices and the target state, the industry—through the Payments Market Practice Group (PMPG)—introduced a Hybrid Postal Address model.
This article explains:
- What Unstructured, Structured, and Hybrid addresses are
- Why each exists
- What is mandatory in each model
- Character limits and formatting rules
- The evolution timeline and regulatory drivers
- What banks must do during the transition period
ISO20022 Schema Postal Address Elements
Important Points to Note:
- Total of 17 Structured Elements including Town Name and Country plus Address Line Element.
- The Max Occurrence of Address Line Element is 7 with max length of 70. This is schema-level capability, not usage guidance.
- All the Elements are Optional. They become Conditionally Mandatory based on the Address Format that is used.
- Each Scheme may have their own restrictions or usage guidelines on top of this base ISO Structure. For Example, CBPR does not allow Elements like CareOf, UnitNb, AdrTp, etc. Also, the Address Line Occurrences is limited to 2 or 3 based on Address Format.
Impacted ISO20022 Elements:
Important Points to Note:
- New Elements introduced in ISO like Ultimate Debtor, Ultimate Creditor and Initiating Party does not allow the fully unstructured address.
- Whether its party type or agent type, postal address rules apply.
- Typically, Agent is identified by the standard identifiers like BIC and Clearing codes. These codes can be referred to Standard Reference Files to fetch more data like complete information including address from SWIF Ref Files or Bankers Almanac Files etc.
- For Banks, the most crucial type is Party, where retail customers information is placed. Banks should enhance their channels to fetch the proper address information on customers.
Fully Unstructured Postal Address
What Is an Unstructured Address?
A fully unstructured address uses only free-text address lines (AdrLine) without any structured elements such as town or country.
This mirrors legacy SWIFT MT usage, where address information was embedded in:
- MT103 Party fields 50 / 59 and also Agent Fields 52 / 57
- Free-format, human-readable text
Example (ISO 20022 – Fully Unstructured):
<AdrLine>HOOGSTRAAT 6, PREMIUM TOWER</AdrLine>
<AdrLine>18TH FLOOR</AdrLine>
<AdrLine>1000 BRUSSELS, BELGIUM</AdrLine>
Key Characteristics and Limits
| Attribute | Rule |
| Address elements | Only AdrLine |
| Maximum occurrences | 3 lines |
| Maximum length | 35 characters per line |
| Structured elements | Not allowed |
| Machine readability | Low |
Why It Exists
- Legacy MT compatibility
- Ease of client onboarding
- No need for address parsing or cleansing
Limitations
According to PMPG, unstructured addresses:
- Impair sanctions and AML screening
- Increase false positives
- Lead to truncation and misrouting
- Require manual repair and investigation
Timeline Status
| Period | Status |
| Before Nov 2025 | Allowed |
| Nov 2025 – Nov 2026 | Grace period |
| After Nov 2026 | Not allowed |
Fully unstructured addresses will be rejected by SWIFT CBPR+ and aligned RTGS systems after November 2026
Note: ISO 20022 schema capability (pure schema) allows many AdrLine occurrences and 70-character lines — but market usage rules (CBPR+, PMPG, HVPS+) restrict AdrLine usage for interbank payments. Don’t conflate schema capability with market usage rules.
Fully Structured Postal Address
What Is a Structured Address?
A fully structured address uses dedicated ISO 20022 elements for each address component, such as:
- StrtNm (Street Name)
- BldgNb (Building Number)
- PstCd (Post Code)
- TwnNm (Town Name)
- Ctry (Country)
Example:
<StrtNm>Hoogstraat</StrtNm>
<BldgNb>6</BldgNb>
<PstCd>1000</PstCd>
<TwnNm>Brussels</TwnNm>
<Ctry>BE</Ctry>
Characteristics and Limits
| Attribute | Rule |
| Address elements | Structured fields only |
| AdrLine | Not allowed |
| TownName | Optional (but strongly recommended) |
| Country | Optional (but strongly recommended) |
| Data quality | High |
| Machine readability | High |
Why Structured Addresses Are the Target State
Structured addresses:
- Enable precise sanctions filtering
- Reduce AML false hits
- Improve straight-through processing (STP)
- Align with FATF Recommendation 16
- Support CPMI / G20 cross-border payment goals
Practical Challenge
The PMPG identified a major industry problem:
Most banks and corporates do not store addresses fully structured in their systems.
Forcing full structure too early risks:
- Data loss
- Data pollution
- Incorrect field usage
- Reduced information quality
Hybrid Postal Address
Why Hybrid Was Introduced
The Hybrid Postal Address is an industry compromise:
- Enables structured data where feasible
- Preserves free-text flexibility for the “last mile”
- Avoids an all-or-nothing migration
The PMPG Change Request introducing hybrid addresses was approved for November 2025 (SR2025)
What Is a Hybrid Address?
A hybrid address combines:
- Mandatory structured elements
- Optional structured elements
- Limited unstructured address lines
Example:
<PstCd>1000</PstCd>
<TwnNm>Brussels</TwnNm>
<Ctry>BE</Ctry>
<AdrLine>Hoogstraat 6, 18th Floor</AdrLine>
Mandatory vs Optional Elements
Mandatory (Non-Negotiable)
| Element | Rule |
| TownName (TwnNm) | Mandatory |
| Country (Ctry) | Mandatory (ISO 3166 code) |
Permitted Unstructured
| Element | Rule |
| AdrLine | Max 2 occurrences |
| Length | Max 70 characters per line |
These rules are explicitly mentioned in the Grace Period Guide of PMPG.
Key Rules for Hybrid Address (Very Important)
Structured data takes precedence.
If data fits a structured field, it must not be placed in AdrLine.
Do NOT:
- Duplicate Town or Country in AdrLine
- Use placeholders like NOTPROVIDED
- Populate 3 AdrLines in a hybrid address
- Use 35-character logic in hybrid mode
- Assume infrastructure validation will fix errors
Common Market Errors Observed
According to PMPG:
- Using 3 × 70 characters in hybrid (invalid)
- Missing TownName or Country
- Embedding TownName inside AdrLine
- Relying on downstream correction
- Silent acceptance due to weak network validation
Practical Rationale for these Choices
- Town & Country are the minimum valuable geography for sanctions screening and FATF compliance. FATF revised R.16 to emphasize country and town as key elements for beneficiary identification. Requiring Town & Country balances privacy concerns and AML/screening needs.
- 2 × 70 in hybrid is deliberate: 70*2 gives flexibility for addresses held as single strings in corporate systems while keeping a limit to reduce truncation risk and mapping complexity. PMPG designed hybrid to be pragmatic for real-world data.
- 3 × 35 for fully unstructured maps to legacy MT field sizes to maintain backward compatibility for systems that map MX→MT and avoid silent truncation in MT carriage. This is why the PMPG mapping guidance explicitly sets the 3×35 rule for downgrading to fully unstructured formats.
Timelines and Evolution
Address Model Timeline
| Period | Allowed Models |
| Before Nov 2025 | Structured + Unstructured |
| Nov 2025 | Hybrid introduced |
| Nov 2025 – Nov 2026 | Grace period |
| After Nov 2026 | Structured + Hybrid only |
Hybrid has no end date and becomes a permanent option alongside fully structured address
Network Validation Reality
A critical insight from the Grace Period Guide of PMPG:
- Infrastructure acceptance does not guarantee correctness.
Many RTGS systems deliberately:
- Defer strict hybrid validation
- Allow invalid messages to pass
- Rely on banks’ internal controls
Responsibility remains with the originating bank.
What This Means for Banks
Banks must:
- Enforce Town & Country at channel level
- Validate AdrLine counts and lengths
- Detect duplication between structured and unstructured fields
- Treat hybrid validation like sanctions screening:
- If it is not valid, it should not go out
Failure results in:
- Repairs and investigations
- Delays and returns
- Regulatory exposure
- Loss of correspondent confidence
Practical controls banks and integrators must implement
(From PMPG operational guidance and general market practice.)
At client channels (front-end/API):
- Enforce Town & Country for hybrid/structured paths.
- Provide structured input fields and address lookups where possible.
- Limit AdrLine counts/lengths according to selected model (hybrid vs unstructured).
In payment engines / back-office:
- Validate presence of mandatory structured elements before sending.
- Detect duplication between structured fields and AdrLine and reject or flag.
- Implement deterministic truncation rules (avoid silent truncation).
- Maintain mapping rules for MX→MT and downgrade logic where needed.
At network boundary:
- Treat hybrid validation like sanctions screening: if invalid, don’t send. Do not assume infra will fix issues.
Summary Comparison Table
| Feature | Unstructured | Structured | Hybrid |
| AdrLine allowed | YES (CBPR -> 3 × 35) | NO | YES (max 2 × 70) |
| TownName mandatory | NO | Market Expectation – Yes | YES |
| Country mandatory | NO | Market Expectation – Yes | YES |
| Automation | Low | High | Medium–High |
| Allowed after Nov 2026 | NO | YES | YES |
Important Comparison on Address Line (Very Useful in Practice)
| Address Type | AdrLine Occurrences | Characters per line |
| Fully Unstructured (CBPR+) | 3 | 35 |
| Hybrid | 2 | 70 |
| Fully Structured | 0 | N/A |
Conclusion
- Unstructured addresses enabled reach, but not reliability
- Structured addresses are the end goal, but difficult to achieve immediately
- Hybrid addresses provide a pragmatic, enforceable transition path
Banks that treat hybrid as a temporary workaround risk operational and regulatory pain. Banks that treat it as a permanent, high-quality data model will gain:
- Better STP
- Stronger AML controls
- Lower costs
- Higher customer trust
Hybrid done right is not a compromise—it is an enabler.
