ISO 20022 structured addresses

Updated 17 September 2026

Free-text addresses are being removed from payment messages. The principle has been settled for years, but 2026 brought two deferrals in three weeks, and confusion followed: Swift and SEPA do not share a calendar, Germany keeps a date that France no longer has, and few sources say plainly which fields to fill. This guide sets out the state of play as of 17 September 2026.

The short version

• A payment address must move from free text (the AdrLine tags) to discrete fields: street, number, post code, town, country.
• Two separate calendars: Swift for cross-border payments, the EPC for SEPA. Both were deferred in the summer of 2026, on different dates and for different reasons.
• No firm new date is known. Swift will consult the community and decide by December 2026; the EPC was due to settle its own date at its October meeting.
• Some communities deferred nothing: German and Luxembourg banks still announce 15 November 2026 for the end of the legacy file versions.
• The deferral changes nothing about the real work: the quality of your counterparty data. An address with no town stays an address with no town, whatever the deadline.

Structured, hybrid, unstructured

ISO 20022 carries a postal address in a PstlAdr block. Three ways of filling it coexist, and mixing them up is the first source of error.

Unstructured. Everything sits in free-text AdrLine tags. This is the format being removed.

<PstlAdr>
  <AdrLine>12 RUE DU FAUBOURG SAINT-HONORE</AdrLine>
  <AdrLine>75008 PARIS</AdrLine>
</PstlAdr>

Hybrid. Town and country move into their own tags, the rest stays free text. Swift and the SEPA rulebooks accept it, and many banks treat it as the acceptable minimum.

<PstlAdr>
  <TwnNm>PARIS</TwnNm>
  <Ctry>FR</Ctry>
  <AdrLine>12 RUE DU FAUBOURG SAINT-HONORE</AdrLine>
</PstlAdr>

Fully structured. Every element has its tag. This is the target, and the EPC recommends reaching it directly rather than stopping at hybrid.

<PstlAdr>
  <StrtNm>12 RUE DU FAUBOURG SAINT-HONORE</StrtNm>
  <PstCd>75008</PstCd>
  <TwnNm>PARIS</TwnNm>
  <Ctry>FR</Ctry>
</PstlAdr>

One detail in that last example often surprises readers: the house number stays attached to the street. That is not sloppiness, it is the rule in the French CFONB mapping guide, covered below.

The fields and their lengths

These are the tags you will meet inside PstlAdr, with their maximum length. Exceeding a length means a file rejected on submission, before it ever reaches the beneficiary bank.

The minimum required everywhere, hybrid included, is TwnNm and Ctry. An address with no town or no country is the most common rejection case, and the easiest to catch before sending.

Two calendars, not one

This is where most teams go wrong. Swift's deferral does not cover SEPA credit transfers, and the EPC decision does not cover cross-border payments.

In short: if you only send SEPA, the Swift date is not yours. If you pay suppliers through a German or Luxembourg bank, the European deferral does not shield you from a format change in November. If you do both, you are running two projects, not one.

What the deferral changes, and what it does not

Two deferrals in three weeks had a predictable effect: projects paused, budgets moved elsewhere, teams reassigned. That is the real risk of this period.

What it genuinely changes: the time pressure, and therefore the ability to do the work properly. Cleaning a counterparty database during a quiet window, with tests, is a different job from doing it three weeks before a hard date.

What it does not change: the direction of travel, and the state of your data. Adapting a payment gateway takes months; adapting the data model behind your ledgers takes years. The second is the one that matters, and the first to be dropped when the deadline disappears.

Who is affected, and when the address is actually required

One distinction saves months of unnecessary work: the beneficiary address is not a mandatory field of a SEPA credit transfer. Many companies send none at all, and their files go through. The question only arises in three cases.

• You already send an address. Once it is in the message, it must follow the format in force. A partial address can be worse than none.
• Your bank requires it for certain operations, or its portal rejects files without it.
• You pay outside the European Economic Area: cross-border payments, one-leg operations, sanctions screening. There the address is the rule, and Swift's calendar applies.

So before rebuilding your entire counterparty base, check what you actually send today. An export of your recent payment files answers that in minutes.

Mapping a French address: the CFONB rules

The CFONB published a guide mapping the French postal standard NF Z10-011 to ISO 20022. It is the reference in France, and it holds several counter-intuitive rules that projects discover late.

The house number is not split from the street

The number feeds BldgNb only when it arrives in a dedicated field of your source file. When it sits inside the address line, the guide explicitly asks not to split: the whole string goes to StrtNm and BldgNb stays empty. The guide's own examples are unambiguous.

The practical reason is obvious once you try the opposite: French street names such as "Rue du 8 Mai 1945" defeat any position-based number detection. Splitting at all costs manufactures wrong addresses.

Building name is not to be used

The guide rules out BldgNm for both companies and individuals. A residence, a building, an entrance or an industrial estate goes to Flr. The reason is arithmetic: BldgNm caps at 35 characters where an NF Z10-011 line holds 38. Flr takes 70.

PO boxes and CEDEX

"BP 40122" goes to PstBx. The French CEDEX marker stays attached to the town: "75008 PARIS CEDEX 08" gives PstCd 75008 and TwnNm PARIS CEDEX 08. It is delivery information, not a separate address line.

Character set

The guide describes three levels, and this is a quiet source of rejections: the basic Latin set is always accepted; accented characters and @ are allowed under a bilateral agreement with your bank, which means usually but not always; everything else is forbidden, including two characters word processors insert by themselves, the typographic apostrophe and the em dash.

The pitfalls that cost time

• Country inferred from the post code. Four digits could be Belgium, Luxembourg or Switzerland; five could be France or Germany. Inference without a declared country code produces silent errors.
• Addresses that are consistent but wrong. One audit reported in the trade press found 92% of towns populated but only 64% of addresses internally coherent. Format says nothing about accuracy.
• Lengths. A town over 35 characters, a long foreign post code, and the message is refused.
• Treating hybrid as the destination. It is accepted, but the EPC recommends going straight to fully structured. Doing the work twice costs more than doing it once.
• Applying French rules to foreign addresses. NF Z10-011 covers French addresses only.
• Inventing data. A missing address is easier to fix later than a fabricated one.

Sizing and running the project

The cost of an address migration does not come from the rules, which fit in a few pages. It comes from the share of your addresses the rules do not cover, and that number lives in your own database.

Export your address column and ask it four questions.

1. How many lines start with a number followed by a space? Those are your simple cases.
2. How many have no street number? Not faulty, but they need their own rule.
3. How many contain building, flat, residence, floor, PO box or CEDEX markers? Those are your complements, and they do not all go to the same field.
4. How many have no usable town or country? Those are the ones that will actually block.

The last two categories, as a share of your volume, are your manual rework. That figure sets the budget, and it belongs to you before you consult any vendor.

Then the method is simple: fix at source in the ERP rather than on the way out, test a real file on your bank's portal before rolling out, and add an input control so the database does not degrade again.

Six questions for your bank

Market rules set a framework, but each bank applies it its own way and dates differ between institutions. Get these confirmed in writing where you can.

1. Which date do you apply for the end of unstructured addresses, in SEPA and cross-border, after the summer 2026 deferrals?
2. Do you accept the hybrid format, and until when?
3. Which message versions do you accept, and until when: pain.001.001.03 or .09, pain.008.001.02 or .08, MT101?
4. What happens to an incomplete address: whole file rejected, single transaction rejected, or accepted with a warning?
5. Is there a test environment where I can upload a real file without signing it?
6. Do your foreign branches apply the same rules? This is where the surprises hide, Germany and Luxembourg in particular.

Frequently asked questions

This guide tracks the deadlines: dates are re-checked at every update. If Swift or the EPC announces a new date, this page is corrected.