ISO 20022 Structured Addresses: Why Banks Should Fix Address Data in Master Data, Not in the Payment Message

TL;DR: ISO 20022 replaces free-text postal addresses in payment messages with structured or hybrid addresses. At a minimum, town name and country code must sit in their own fields. On 27 August 2026 Swift postponed the November 2026 cut-off for cross-border payments and said it will publish a new timeline by December 2026, but the direction has not changed. The mapping to XML is the easy part. The hard part is the customer master data behind it: addresses held as free text, split inconsistently, duplicated across core banking, CRM and payment systems. Address normalisation and entity resolution in the master data layer fix the problem once, at the source, for every payment channel.

See how Tilores structures and resolves address data on your own records. Book a Demo · Try Tilores Studio (Free).

On this page

1. What does ISO 20022 change for postal addresses?
2. What is the deadline after the Swift postponement?
3. Why is this a master data problem?
4. What goes wrong when addresses are parsed at payment time?
5. How does address normalisation work in Tilores?
6. Why does entity resolution matter for addresses?
7. What should a bank do before the new deadline?
8. Frequently asked questions

ISO 20022 is the global messaging standard that is replacing the old Swift MT formats for payments. Most of the public discussion has been about message formats, migration dates and coexistence. The address requirement is different, because no message format change can fix it on its own. It exposes the condition of the customer and counterparty data that banks and their corporate clients have stored for decades.

Deutsche Bank’s guidance to its business customers makes the point directly. The first action it lists is to check customer, supplier and company master data for completeness and make sure every address includes town and country. Only after that come payment templates, software updates and format versions such as pain.001 v09.

What does ISO 20022 change for postal addresses in payment messages?

ISO 20022 recognises three ways to send a postal address for the debtor, creditor and other parties in a payment:

In practice, a bank that today sends this:

<PstlAdr>
  <AdrLine>Musterstrasse 1</AdrLine>
  <AdrLine>20457 Hamburg</AdrLine>
</PstlAdr>

must instead send something like this:

<PstlAdr>
  <StrtNm>Musterstrasse</StrtNm>
  <BldgNb>1</BldgNb>
  <PstCd>20457</PstCd>
  <TwnNm>Hamburg</TwnNm>
  <Ctry>DE</Ctry>
</PstlAdr>

The first version carries no country. A machine has to guess where the town is. The second can be screened, routed and reconciled without guesswork. This is the reason regulators and payment infrastructures want it: structured addresses improve sanctions screening, reduce false positives, and support the FATF travel-rule expectation that payment data identifies originators and beneficiaries accurately.

What is the deadline for structured addresses after the Swift postponement?

The original plan was for Swift to stop accepting fully unstructured addresses in cross-border ISO 20022 payment messages with Standards Release 2026, in November 2026. On 27 August 2026, Swift postponed that change. It said progress across the industry “remained uneven, with institutions in all regions unable to meet the requirement”.

What we know as of late September 2026:

• All payment-related changes in Standards Release 2026 are deferred, including the CBPR+ package that contains the retirement of unstructured addresses. Swift will publish an update by December 2026 at the latest.
• Non-payment items (securities, trade and others) go live separately in a partial release in Q1 2027.
• The US Federal Reserve rescheduled its matching Fedwire release from November 2026 to November 2027, according to RedCompass Labs.
• Structured and hybrid addresses can already be used across the network by institutions that support them.

Deutsche Bank confirms the postponement in its customer guidance and says the final date is still to be confirmed.

The postponement changes the timetable. It does not change the requirement. Banks that treat the extra time as a reprieve will face the same data problem in 2027 with less room to fix it. Banks that use it to repair their master data will get something more valuable than compliance: one reliable address per customer, reusable for KYC, screening, correspondence and analytics.

Why is ISO 20022 address compliance a master data problem and not a formatting problem?

Mapping a clean, structured address to StrtNm, BldgNb, PstCd, TwnNm and Ctry is a small integration task. Most address data in a bank is not clean, which is why the task keeps slipping.

Address data in banks typically suffers from four problems at once:

1. Free text instead of fields. Older core banking and payment systems often store addresses as two to four lines of free text. Street, house number, postcode and town are mixed together, in an order that depends on the country and on whoever typed it.
2. Inconsistent formats. The same street appears as Hauptstraße 5, Hauptstr. 5, HAUPTSTRASSE 5 and Haupt Str. 5. Countries are written as Germany, Deutschland, DE, D or not at all.
3. Missing elements. Country is the element most often missing, because domestic systems assumed it. That is exactly the element ISO 20022 makes mandatory.
4. Duplicated customers with conflicting addresses. One corporate client can exist in the core banking system, the CRM, the trade finance platform and the payments hub, each with a slightly different address. When no single customer record exists, no single correct address exists either.

The first three problems call for address normalisation. The fourth calls for entity resolution. Both belong in the master data layer, where they are solved once and every downstream system benefits.

What goes wrong when banks parse addresses at payment time?

The quickest-looking fix is a parser in the payment channel that tries to split each outgoing free-text address into structured fields. It helps as a safety net. As the main strategy it has three weaknesses:

• It repeats the work on every payment. The same ambiguous address is parsed thousands of times, and each time it can be parsed differently depending on what else is in the line.
• It hides the root cause. The customer record stays unstructured, so the next channel, the next report and the next regulatory request meet the same problem.
• It cannot resolve conflicts. If the CRM says Munich and the core banking system says Hamburg, a payment-time parser has no way of knowing which is correct. It will structure the wrong address perfectly.

Fixing the address in master data reverses this. The address is parsed, normalised and validated once, linked to the right customer, and then published to every channel that needs it.

How does address normalisation work in Tilores?

Tilores is an entity resolution platform. Before it compares records, it normalises the values used for matching, and addresses are among the most important of them. The relevant building blocks are documented in the Tilores transformer reference:

Normalize Address takes street, house number, city, postal code and a country code, and returns a normalised street, house number, city and postal code. Along the way it:

• Extracts house numbers from the street line when they are not in their own field. It recognises explicit markers (Nr., No., #, nº, civico) and positional conventions: leading house numbers for anglophone and French formats, trailing ones for most other European formats. Ranges and suffixes such as 12-14 or 19c are kept intact.
• Applies country-specific reference lists for preprocessing, token mapping and particles. For example, compound splitting turns Hauptstr. into Haupt str. so that it can be mapped consistently to the full street type.
• Handles block-addressing countries such as Japan, South Korea and China differently from street-based systems.
• Validates postal codes with built-in per-country rules, with an option to remove structurally invalid postal codes rather than passing them on.

Normalize Country converts free-form country values into ISO 3166-1 alpha-2 codes, the format the ISO 20022 Ctry element uses. When the country field is missing or unrecognised, it falls back through a cascade: first the country name list, then the city, then country-specific street tokens (for example, strasse points to Germany), and finally a configured default. This matters because missing country codes are the single most common reason an address fails the hybrid minimum.

Convert Text operations such as normalising diacritical characters and whitespace make sure that Müller Straße, Muller Strasse and MÜLLER STRASSE compare as the same value.

Tilores keeps the original values next to the normalised ones. Normalisation creates comparable, structured components without rewriting the historical evidence. That matters for audit, and for the data stewards who decide which address becomes authoritative.

Why does entity resolution matter for structured addresses?

Normalisation makes one address clean. Entity resolution makes sure it is the right address for the right customer.

Tilores links records that refer to the same real-world customer across source systems, using normalised names, addresses, identifiers, phone numbers and emails. The result is one resolved entity per customer, with all source records and their addresses attached. That gives the bank’s master data or golden-record process what it needs to choose a single structured address:

• Conflicts become visible. When the same client has three different addresses across systems, the bank sees them side by side, with their sources, instead of discovering the conflict in a rejected payment.
• Gaps are filled from other sources. A payments record without a country can be completed from a linked KYC record that has one, under survivorship rules the bank defines. Our post on survivorship rules for safe merges covers how to set those rules.
• Duplicates stop multiplying. New records are resolved at ingestion, in real time, so a new onboarding record with a slightly different spelling of an existing client is linked immediately rather than creating another unstructured copy.

Tilores does not need to own the golden record. It sits beside the bank’s core systems, MDM and payment platforms, and returns resolved entities through a GraphQL API. The bank keeps ownership of survivorship policy and of which values are written back to the authoritative master. For more on this split, see buying a matching engine while keeping the golden record.

For banks with strict data-residency needs, Tilores can run in the bank’s own AWS account, another cloud, its data centre or an air-gapped network. See the deployment options.

What should a bank do before the new structured-address deadline?

A practical sequence for the time Swift’s postponement has created:

1. Measure the gap. Profile the address data in every system that feeds outgoing payments. What share is fully structured, what share could meet the hybrid minimum (town plus country), and what share is free text only?
2. Normalise at the master data layer. Parse free-text addresses into components, standardise street types and spellings, derive missing country codes, and validate postal codes. Keep the original values.
3. Resolve customers across systems. Link duplicate customer and counterparty records so each real-world party has one resolved entity, with every source address attached.
4. Decide survivorship and route exceptions to stewards. Define which source wins for which address element. Send conflicts and incomplete addresses to data stewards, and fix the most-used counterparties first.
5. Publish structured addresses to payment channels. Feed the structured, resolved address to payment templates and channels. Keep a payment-time check as a safety net, not as the main fix.
6. Keep it current. Resolve new and changed records at ingestion so the address quality you reach before the deadline doesn’t decay after it.

The same work pays off outside payments. A structured, resolved address improves sanctions and PEP screening, KYC refresh, customer communications, and credit exposure aggregation.

Frequently asked questions

What is the minimum address data required under ISO 20022?

For hybrid addresses, town name (TwnNm) and country code (Ctry) must be in their own structured fields. Up to two free-text address lines can carry the rest. Fully structured addresses put street, building number, postal code, town and country each in its own field. Addresses made only of free-text lines are being retired from cross-border payments.

Has the ISO 20022 structured address deadline been postponed?

Yes. On 27 August 2026, Swift deferred all payment-related changes in Standards Release 2026, including the retirement of unstructured addresses in CBPR+, which was planned for November 2026. Swift will publish an updated timeline by December 2026 at the latest. The US Federal Reserve moved its related Fedwire release to November 2027.

Why does ISO 20022 require structured addresses?

Structured addresses allow payment data to be processed automatically and accurately. They improve sanctions screening, reduce false positives and manual investigations, and help banks meet requirements to identify originators and beneficiaries clearly.

Can address normalisation derive a missing country code?

Often, yes. Tilores’ Normalize Country transformer first looks up the country value, then falls back to the city and to country-specific street tokens, and finally to a configured default. Addresses that remain uncertain should go to data stewards rather than being guessed.

Does Tilores replace a bank’s MDM system?

No. Tilores provides address normalisation and entity resolution as a layer beside existing MDM, core banking and payment systems. The bank keeps ownership of golden-record and survivorship policy and decides which structured values are written back.

How can a bank test this on its own address data?

Take an extract of customer and counterparty addresses from two or three source systems, including the free-text records you expect to fail, and run it through normalisation and resolution. You will see how many addresses can be structured automatically, how many duplicates carry conflicting addresses, and how many need a steward.

Book a Demo or Try Tilores Studio (Free).

Sources

1. ISO 20022: Neue Anforderungen an Zahlungsdaten, Deutsche Bank.
2. Unstructured address data is being removed. Are you ready?, Swift.
3. Swift extends ISO 20022 structured address deadline, The Paypers.
4. Swift delays ISO 20022 structured address deadline, RedCompass Labs.
5. Transformer Reference, Tilores documentation.
6. Entity Resolution Infrastructure, Tilores.
7. Deployment Options, Tilores.
8. How to Merge Duplicate CRM Records Safely: 5 Survivorship Rules for 2026, Tilores.