Unstructured address data is being removed. Are you ready?
Prepare your organisation for the adoption of fully structured or hybrid postal addresses. Swift guidance is available to help you understand the requirements and take the necessary steps towards compliance.
Revised Implementation of Standards Release 2026 (SR2026)
On 27 August 2026, Swift announced a change to the SR2026 timeline. For the latest information on the timelines and scope, please visit our FAQs page in the customer area of swift.com.
A critical change you need to prepare for
Unstructured address data is being phased out in ISO 20022 payment messages. To be compliant, town name and country must be provided in unique tags at a minimum. This means that institutions relying on unstructured address data today will need to adapt their systems, data models and processes.
Failure to do so can lead to:
- Payment delays
- Increased rejections
- Higher operational and compliance risks
The usage guidelines for CBPR+ will enforce these rules across the network. Customers submitting payments not adhering to these formats may see their requests be rejected or delayed by their PSPs, potentially impacting processing timelines and increasing operational overhead.
Until November 2026, there are three valid formats for providing postal addresses in cross-border payment messages:
- Fully structured (already available and strongly recommended)
- Hybrid (already available)
- Fully unstructured (to be decommissioned by November 2026)
- From 14 November 2026, the fully unstructured messages may be rejected or delayed, in line with the deadline set by the payments community through the Payments Market Practice Group (PMPG).
This change is a community‑driven standards evolution, endorsed through the formal maintenance process and country vote, and directly supports the G20 objective of improving data quality and transparency in cross‑border payments. It supports future data requirements e.g. FATF rec. 16: Improved payment transparency and screening / monitoring of required debtor and creditor information.
This planned change has significant implications for financial institutions, corporates and market infrastructures.
From 14 November 2026, town and country information must be provided in designated fields, at a minimum, for all agents and parties in CBPR+ payment messages, except for ISO 20022 message identifiers admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060. For agents, use of the BIC only continues to be a valid option rather than providing name and address.
This requirement applies to all payments, including corporate, securities, trade, FX and funds.
Why it matters now
Moving away from free-text address fields ensures that payment data is consistent, standardised and fully machine-readable. This improves the ability to correctly identify parties across the payment chain.
Structured addresses significantly improve sanctions screening and AML controls. More precise data reduces false positives and helps institutions detect real risks more effectively.
Unstructured address data often leads to payment exceptions and investigations. Structured data enables higher straight-through processing (STP) rates and reduces costly manual handling.
Cleaner, more reliable data means fewer payment delays and greater transparency. This translates into faster, smoother payments for end customers.
Standardised address data supports end-to-end automation and unlocks advanced capabilities such as analytics, fraud detection and new value-added services.
How address data should be structured
From November 2026, postal addresses in cross-border payment messages must be provided in one of two valid formats; fully structured or hybrid.
A fully structured address must include the Country and Town Name elements a minimum. It cannot contain the Address Line element.
| <Nm>JOHN SMITH</Nm> | |
| <PstlAdr> | |
| <SrtNm> MARK LANE</StrNm> | |
| <BlgNb>55</BlgNb> | |
| <BlgNm>THE CORN EXCHANGE</BlgNm> | |
| <Flr>6</Flr> | |
| <PstCd>EC3R 7NE</PstCd> | |
| <TwnNm>LONDON<TwnNm> | |
| <Ctry>GB</Ctry> | |
| </PstlAdr> | |
A hybrid postal address must include the Country and Town Name elements, it will also allow the Address Line element to be included. 2 occurrences of the Address Line element with up to 70 characters are permitted.
Other structured elements in addition to Country and Town Name may also be included e.g. Post Code.
| <Nm>JOHN SMITH</Nm> | |
| <PstlAdr> | |
| <TwnNm>LONDON</TwnNm> | |
| <Ctry>GB</Ctry> | |
| <AdrLine>55 MARK LANE, THE CORN EXCHANGE, 6TH FLOOR, EC3R 7NE </AdrLine> | |
| </PstlAdr> | |
Frequently Asked Questions
We have compiled a list of questions frequently asked about ISO 20022 and the removal of unstructured address.
Where are we today?
Global adoption of hybrid and structured Postal Address - August 2026 - Scope: pacs.008 and CBPR+
Debtor | Creditor | ||||
| Fully structured or hybrid postal address | Unstructured postal address | No postal address | Fully structured or hybrid postal address | Unstructured postal address | No postal address |
| Debtor element with postal address supplied in either structured or hybrid format | Debtor element with unstructured Postal Address | Debtor element without postal address information | Creditor element with Postal Address supplied in either structured or hybrid format | Creditor element with unstructured Postal Address | Creditor element without Postal Address information |
| Structured: 24.1% Hybrid: 16.5% | Unstructured: 54.8% | No address: 4.7% | Structured: 20% Hybrid: 10.2% | Unstructured: 56.2% | No address: 13.5% |
Unstructured = 54.8 % | Unstructured = 56.2 % | ||||
Notes:
- Statistics are derived from the observations of xml elements used in CBPR+ traffic
- Where Structured, Hybrid and Unstructured Postal Address are used, the statistics do not provide information on the completeness of information supplied beyond the mandatory data elements
Resources
All you need to know
SR2026 statement – August 2026
Swift accepts community request to extend structured address migration for ISO 20022 payment messages.