Structured address requirements in ISO 20022: what moved, and what a payments team should fix now

The structured address requirements in ISO 20022 are the part of the migration with the widest reach and the least glamour. They do not change what a payment costs or where it goes. They change how the parties to it are written down. A fully structured address puts the street, the building number, the post code, the town and the country in their own named elements, where software can read each one. An unstructured address puts the same facts into lines of free text and leaves every later reader to guess.

On 27 August 2026 Swift deferred the date on which unstructured addresses stop being accepted in cross-border messages. The date moved. The work did not. This article sets out what the requirement says, what the deferral changed, what it did not, and the order in which a bank, credit union or money service business should do the data work.

What does a structured address mean in ISO 20022?

ISO 20022 models a postal address as a set of named elements rather than a block of text. The main ones are street name, building number, building name, floor, post box, room, post code, town name, town location name, district name, country sub division and country. The country element takes a two letter code from ISO 3166, not a spelled out country name. Department and sub department exist for parties inside large organisations.

The same address can be presented three ways. Unstructured uses address lines only. Fully structured uses the named elements and no address lines. Hybrid puts town name and country in their own elements and allows the rest of the detail on address lines. The CBPR+ usage guidelines decide which presentations a cross-border message may carry. The rule reaches the debtor, the creditor and their agents in a pacs.008, and the institutions in a pacs.009.

Hybrid is the practical landing point for most institutions. It demands the two fields that carry the most control value, town and country, without forcing a full parse of every historic record on day one.

What did Swift defer in August 2026, and what still stands?

Swift announced a controlled extension of Standards Release 2026 and deferred its payments content. That includes the removal of unstructured postal addresses from cross-border messages. No replacement date has been published. Swift said it would give an update by December 2026 at the latest. The Bank of England deferred its November 2026 RTGS release in full on the same day, and Federal Reserve Financial Services moved its planned Fedwire release to November 2027.

Three things did not move. The migration itself is done, because coexistence between MT and ISO 20022 for cross-border payment instructions ended on 22 November 2025. Structured and hybrid addresses are fully supported today, so nothing stops an institution sending them now. And the obligations that make structured party data valuable are statutory, not a standards release.

Read the deferral as a schedule change rather than a reprieve. The reason for it is the reason not to stop. Swift readiness data from April 2026 showed roughly six in ten cross-border payments still carrying unstructured addresses, which is why the community asked for more time.

What actually breaks when an address arrives as free text?

Screening is the first casualty. A name hit against a sanctions list is confirmed or discounted on secondary identifiers, and the address is the most common one. When the town sits in the middle of a line of text, that comparison becomes a string match against a guess.

Repair is the second. A payment that fails a receiving institution's validation is held and worked by hand. That adds a day and a cost to a payment that was otherwise sound.

Reporting is the third. The country of a counterparty drives sanctions policy, balance of payments statistics and tax reporting. A country read out of free text is a country that is sometimes wrong, and nobody downstream can tell which times.

Regulatory data is the fourth, and it is the one no deferral touched. FATF Recommendation 16 requires originator information that includes an address or an acceptable alternative identifier. In the United States the recordkeeping and travel rules at 31 CFR 1010.410 require the originator address for transmittals of funds of 3,000 dollars or more. In the European Union, Regulation 2023/1113 requires the payer address or one of a short list of alternatives.

How do structured address requirements improve sanctions screening?

A screening engine compares each party to a payment against list entries. The OFAC list of Specially Designated Nationals carries addresses for many entries, and so do the EU and UK lists. An engine can only use an address if it can find one in a field.

Two gains follow from structure. The first is precision. When town and country sit in their own elements, a common name in the wrong country stops producing an alert. The second is policy. A jurisdiction rule can be applied to a coded country value as a rule, which is a different thing from inferring a country from the last line of an address.

The limit is worth stating plainly. Structure improves the evidence a screening decision rests on. It does not replace fuzzy name matching, and it does not answer ownership and control, which stay a separate analysis on their own facts.

An address is not a sentence. It is a set of fields, and each one is a control that something downstream depends on.

How should a bank or MSB clean up its address data?

The record is the hard part, not the message. Most institutions can emit a structured address as soon as the data behind it exists. The sequence that works starts at the intake form and moves backwards through the file.

• Fix capture first. Collect street, building number, post code, town, country sub division and country as separate fields on the onboarding and beneficiary forms, so the problem stops growing.
• Profile what you hold. Count the records with no parseable town, no country code, or a country spelled out rather than coded. That count is the size of the project.
• Parse in bulk against a postal reference file, country by country, and keep a confidence score for each parsed record instead of overwriting the original.
• Decide the rule for failures in advance. Use hybrid with town and country where the rest will not parse, and a review queue where even those are missing.
• Repair at the next client touchpoint. A periodic review, a new beneficiary or a change of bank details is a natural moment to confirm an address.
• Map the outbound message once the data is clean, then validate before release rather than learning about the gap from a rejection.
• Record the policy, the parse rules and the exception handling, because a reviewer reading a screening decision will ask where the address came from.

One sequencing note matters. Fixing capture before cleaning history is deliberate. A file that is still taking in free text cannot be cleaned, only chased.

What do structured address requirements mean for an on-chain settlement leg?

A public blockchain carries wallet addresses, an amount and a timestamp. It carries no party names and no postal addresses, and nothing identifying belongs on it. The party data lives in the message beside the transfer, which makes the quality of that message the whole record.

Two consequences follow. The first is reuse. The Travel Rule payload and the payment message want the same clean data. IVMS101, the data standard behind Travel Rule exchanges, models a geographic address in named elements of the same kind, so an address parsed once can serve the pacs.008, the Travel Rule message and the screening engine.

The second is timing. A settlement leg that is final in minutes cannot be held open while someone repairs an address by hand. The address has to be right before release, not good enough to fix afterwards. That is the practical case for doing the work now, with no deadline forcing it.

Where StableNet fits

StableNet, built by SpendTheBits, settles cross-border B2B payments in regulated stablecoins while keeping the message layer institutions already run on. Every transfer produces ISO 20022 messages, a pacs.008 for the customer credit transfer and a pacs.009 for the interbank leg, inside a head.001 envelope and tracked end to end by UETR, so party data travels in named elements rather than free text. KYB and KYC onboarding, sanctions and PEP screening, Travel Rule data in IVMS101 and a tamper-evident audit trail sit in the same flow, which means the address captured once is the address screened, sent and evidenced.