SEPA structured address: what changes on 15 November 2026

ARLing s. r. o. · 6 September 2026

This applies to SEPA Credit Transfer, SEPA Instant Credit Transfer and SEPA Direct Debit (Core and B2B) across the whole SEPA area, because it is a scheme rule set by the European Payments Council, not a rule of one bank or country. If you send batch payments as a pain.001 XML file, this is worth checking now rather than on 16 November.

What the rule actually says

In ISO 20022 messages, a postal address (PstlAdr) can be written two ways. Unstructured: one or more free-text lines in AdrLine, the way you would type an address on an envelope. Structured: separate fields such as StrtNm (street), BldgNb (building number), PstCd (postcode), TwnNm (town) and Ctry (country).

From 15 November 2026, a fully unstructured address is no longer accepted in SEPA schemes. When an address is present, it must be either fully structured or hybrid, and in both cases it must include at least TwnNm and Ctry. Every other structured field stays optional. Note what this does not say: it does not make the address itself mandatory. A payment with no PstlAdr at all is unaffected and keeps working the same way after the deadline as before it.

Hybrid address: at most two free-text lines

A hybrid address keeps some free text alongside the structured fields, often for a street that does not fit cleanly into StrtNm and BldgNb. The rule allows at most two AdrLine rows here. A third line, or an address that is all AdrLine and nothing else, is treated as unstructured and rejected the same way.

Three examples

1. Fails from 15 November 2026, unstructured only.

<PstlAdr>
  <AdrLine>Ivanská cesta 32E</AdrLine>
  <AdrLine>821 04 Bratislava, Slovakia</AdrLine>
</PstlAdr>

Everything about the address is in free text. No TwnNm, no Ctry. This is the shape that stops working.

2. Passes, fully structured.

<PstlAdr>
  <StrtNm>Ivanská cesta</StrtNm>
  <BldgNb>32E</BldgNb>
  <PstCd>821 04</PstCd>
  <TwnNm>Bratislava</TwnNm>
  <Ctry>SK</Ctry>
</PstlAdr>

Every part of the address has its own field. Ctry is the two-letter code, not the full country name.

3. Passes, hybrid with two free-text lines.

<PstlAdr>
  <AdrLine>Ivanská cesta 32E</AdrLine>
  <AdrLine>821 04 Bratislava</AdrLine>
  <TwnNm>Bratislava</TwnNm>
  <Ctry>SK</Ctry>
</PstlAdr>

The street and postcode stay as free text, at most two lines, while TwnNm and Ctry are filled in separately. This is the shape a lot of accounting software will produce during the transition, because it needs less rework than pulling every field apart.

Two dates were circulating, and that is not a typo

If you have seen both 22 November 2026 and 15 November 2026 mentioned for this deadline, that is a real discrepancy, not a mistake on one side. Version 1.0 of the 2025 SEPA Credit Transfer rulebook, published by the European Payments Council, gave 22 November 2026 as the date. Version 1.1 corrected it to 15 November 2026. The 15th is the date that stands. Some bank pages online still quote the earlier version, which is why the two numbers keep circulating together. If a source you are reading gives 22 November, check whether it is citing version 1.0 or 1.1 of the rulebook.

The broader 2025 rule set that this correction belongs to, hybrid addresses included, has applied since 5 October 2025. The 15 November 2026 date is specifically when the unstructured-only option is withdrawn.

Does this force a move to pain.001.001.09?

No, not by itself. The structured address requirement is a scheme rule, not a message-version rule. The older message version, pain.001.001.03, already carries a structured address type (PostalAddress6) with StrtNm, BldgNb, PstCd, TwnNm and Ctry, so all three examples above are valid in a pain.001.001.03 file. The newer PostalAddress24 used in pain.001.001.09 mainly adds finer fields (building name, floor, post box, room) and caps AdrLine at two rows, which is where the hybrid limit above comes from in the schema itself.

Separately from the address rule, some banks are also moving their own SEPA import formats from .03 to .09 around the same period, each on its own schedule. Check with your own bank which version it accepts before and after 15 November 2026; we have not verified this for every SEPA country.

What this means if you send batch payments

• If your accounting software already fills in a structured address with at least town and country whenever it has one, this rule needs no action from you.
• If it exports address lines as free text only, ask your vendor when a structured-address export is planned, and test a file against your bank's import before the deadline, not after.
• If you build or edit pain.001 files by hand or by script, add TwnNm and Ctry next to the free text you already have; you do not need to remove the free text, as example 3 shows.

A word on scope: this article covers the SEPA scheme rule and the ISO 20022 message standard, which apply the same way across the euro area regardless of country. It does not cover any single bank's internal import rules, which can add requirements of their own on top of this. Where a Slovak bank's documentation is cited below as an example, it is marked as a Slovak-bank source, not a general SEPA rule. We have not independently verified how every SEPA-area bank is enforcing this deadline; where we could not confirm a claim from a document, we left it out rather than guess.

ARLing is not a bank and this is not legal or accounting advice. A file that meets the structured-address rule is not a guarantee that a bank will accept the payment: banks can add their own requirements and change them at any time. If you want to check a batch file against this rule yourself, our free SEPA pain.001 Doctor flags unstructured and incomplete addresses, runs entirely in your browser, and does not upload your file anywhere.