The payments industry is approaching another important milestone in the ISO 20022 transformation. From 16 November 2026, fully unstructured postal addresses will no longer be accepted in CBPR+ payment messages. Where postal addresses are required, organizations will need to provide them using either a fully structured or hybrid format. Swift states that non-compliant CBPR+ messages using unstructured addresses will be rejected/NAK’ed at the network level.

This may look like a relatively small formatting change, but its impact extends well beyond the payment message itself. Banks, corporates, fintechs, payment processors, ERP/TMS providers, payment gateways, customer onboarding platforms, sanctions-screening solutions, and downstream payment systems all need to examine how address information is captured, stored, validated, transformed, and transmitted.

Why Address Structure Matters

Historically, payment systems have frequently stored customer and beneficiary addresses as free-text fields:

John Smith
55 Mark Ave
Newyork 10001
United States

A human can easily interpret this information. Automated systems, however, cannot always reliably determine which portion represents the street, building number, postal code, town, or country.

ISO 20022 addresses this problem by making payment information more machine-readable. Structured address information can improve straight-through processing, analytics, compliance processes, screening, fraud controls, and automation.

The industry is therefore moving from:

Free-text address ==> Hybrid address ==> Fully structured address

Key Address Format Types

1. Structured Address

A fully structured address stores individual address components in dedicated fields rather than combining them into free text.

Typical elements include:

Street Name
Building Number
Building Name
Postal Code
Town Name
Country

For CBPR+, Town Name and Country Code are the minimum required structured elements when a postal address is provided. A fully structured address cannot contain the AdrLine element.

Example – ISO 20022 XML

<TwnNm>Newyork</TwnNm>

</PstlAdr>

From a data architecture perspective, this means organizations should avoid treating an address as a single database column.

Instead:

Address = Street + Building + Postal Code + Town + Country + other structured components

This significantly improves the ability of systems to validate, screen, route, reconcile, and process payment information automatically.

2. Hybrid Address

The hybrid address provides a practical transition between legacy free-text addresses and fully structured data.

At minimum, the following must be supplied as structured elements:

Town Name (TwnNm)
Country Code (Ctry)

Additional address information can remain within AdrLine. Swift currently permits up to two Address Line occurrences of up to 70 characters each in a hybrid postal address.

Example

<PstlAdr>
    <TwnNm>NewYork</TwnNm>
    <Ctry>US</Ctry>
    <AdrLine>55 Mark Ave, 6th Floor</AdrLine>
</PstlAdr>

This approach is particularly valuable for organizations with large volumes of legacy customer and beneficiary records that cannot immediately be converted into completely structured addresses.

However, organizations should treat hybrid addressing as a migration mechanism rather than an excuse to preserve poor-quality address data indefinitely. Swift encourages institutions to provide structured information such as postal code, street name, and building number whenever that information is available.

3. Unstructured Address

An unstructured address places most or all postal information into free-text address lines.

For example:

<PstlAdr>
    <AdrLine>55 Mark Ave</AdrLine>
    <AdrLine>NewYork 10001 UNited States</AdrLine>
</PstlAdr>

This format depends heavily on humans or downstream technology interpreting the contents of each line.

After 14 November 2026, this fully unstructured approach will no longer be permitted for CBPR+ payment messages in scope. Messages containing unstructured postal addresses can be rejected before network submission through schema validation or NAK’ed at network level.

There are limited message exceptions; Swift identifies admi.024, camt.025, camt.052, camt.053, camt.054, and camt.060 as exceptions to the CBPR+ requirement.

The key technical requirement is straightforward:

Town Name + Country must become identifiable structured data—not information buried somewhere inside a free-text address line.

The Impact Is Bigger Than SWIFT

One of the biggest implementation mistakes would be treating this purely as a SWIFT messaging change.

The address originates much earlier in the payment lifecycle:

Customer / Beneficiary
||
Onboarding & Customer Master
||
ERP / Treasury / Payment Portal
||
Payment Hub
||
Validation & Enrichment
||
Compliance / Sanctions Screening
||
Payment Rail

Receiving Bank

If the source system stores:

"55 Mark Ave, NewYork 10001 US"

but the payment rail requires:

Street = Mark Ave
Building = 55
Postal Code = 10001

Town = London
Country = GB

then somebody—or some system—must reliably perform that transformation.

That is why the November 2026 program should begin with data readiness, not merely message-format development.

Swift specifically advises institutions to structure existing customer address data, ensure channel applications can capture structured information, and engage customers early.

Impact Across Payment Channels

Organizations should assess every channel through which payment instructions enter the bank.

ISO 20022 / MX Channels

For native ISO 20022 flows such as pain.001 and applicable pacs messages, applications need to populate the appropriate PstlAdr structured elements.

The preferred target should be:

Fully Structured Address

with hybrid addressing used where complete structured data is not yet available.

SWIFT MT / MT101

Legacy initiation channels cannot simply be ignored.

Swift explicitly states that the requirement applies regardless of whether customers initiate through MT101 SCORE, pain.001 SCORE+, or proprietary bank channels because the bank ultimately needs the required address information to execute the payment.

For MT101, organizations therefore need to review how party information is populated and mapped. Swift guidance shows use of the F-option structure, such as Field 59F, where country and town information can be represented in a structured/semi-structured manner.

Bank Portals and Proprietary Channels

A payment portal may currently provide customers with:

Address Line 1
Address Line 2
Address Line 3

That user interface may need to change to capture:

Street Name
Building Number
Postal Code
Town/City
Country
Additional Address Information**

with mandatory-field and country-code validation.

File-Based / Host-to-Host Channels

Banks should examine:

File uploads
Host-to-host connections
SFTP payment files
ERP integrations
Treasury Management Systems
APIs
Legacy proprietary formats

Even if the external format is not ISO 20022, the bank must ensure sufficient address information exists to construct a compliant downstream payment instruction.

Customer Impact

This change cannot be solved entirely inside the bank.

Many institutions have already begun communicating address requirements to customers and warning about the possibility of payment rejection when invalid or insufficient address information is transmitted.

Corporate customers may therefore need to clean up:

Vendor master data
Beneficiary records
Customer master data
ERP address structures
Treasury templates
Standing payment instructions
Recurring payments

Swift specifically notes that corporates need to source creditor address information, maintain it in ERP or treasury applications, and provide at least Town Name and Country when required at payment initiation.

Compliance and Screening Impact

Structured addresses are not simply a technical requirement.

Better address data can strengthen:

AML controls
Sanctions screening
Fraud detection
Customer identification
Payment transparency
Transaction monitoring

For example, screening the free-text value:

"123 Main St NY USA"

provides considerably less deterministic information than receiving:

Town = New York
Country = US

as independently identifiable fields.

This allows compliance engines to make better use of the information and reduces reliance on parsing inconsistent free-text strings. Swift connects structured data with more accurate compliance processes and improved automation.

What Banks and Payment Organizations Should Do Now

The November 2026 program should therefore cover more than an XML schema update.

1. Discover
Identify every system containing debtor, creditor, ultimate-party, agent, customer, and beneficiary addresses.

2. Assess
Determine where addresses are fully structured, partially structured, or completely free text.

3. Cleanse
Correct missing towns, invalid country codes, incomplete postal information, duplicates, and inconsistent address records.

4. Enhance Channels
Modify payment portals, APIs, file specifications, ERP integrations, and payment initiation channels to capture the required structured information.

5. Build Validation Early
Do not wait until the payment reaches SWIFT. Validate address requirements as close to payment initiation as possible.

6. Define Repair Processes
Determine what happens when an address is incomplete: reject it, return it to the customer, route it for repair, or use an approved validation/enrichment capability.

7. Test End-to-End
Testing should cover:

Channel ==> Payment Hub ==> Compliance ==>Transformation ==> SWIFT/Payment Rail ==> Receiving Institution

and include positive, negative, boundary, mapping, truncation, and rejection scenarios.

8. Engage Customers
Communicate requirements early, particularly to high-volume corporate customers using ERP, treasury, host-to-host, MT101, or proprietary payment channels.

The Strategic Opportunity

The November 2026 requirement should not be viewed only as another ISO 20022 compliance deadline.

It provides an opportunity to address a much broader problem:

Poor-quality payment-party data.

Organizations that simply transform free text at the last moment may technically solve one interface problem while retaining the underlying data-quality problem.

A stronger strategy is:

Capture structured ==> Store structured ==>Validate structured ==> Screen structured ==> Transmit structured

That approach supports better automation, stronger compliance controls, improved straight-through processing, fewer payment repairs, and ultimately fewer avoidable payment failures.

November 2026 is not simply an address-format change. It is a payment-data-quality transformation.

ISO 20022 Address Changes: Preparing for the November 2026