SEPA structured addresses: what changes on 15 November 2026?

Last updated: 27 July 2026

From 15 November 2026, payment files that use the legacy unstructured address format are no longer permitted under the EPC SEPA payment schemes. Where a postal address is provided in a SEPA payment message, it must be structured or hybrid from that date onward.

This applies to addresses carried in ISO 20022 payment messages — including pain.001 credit transfer files and pain.008 direct debit files — under the SEPA Credit Transfer, SEPA Instant Credit Transfer, SEPA Direct Debit Core and B2B, and One-Leg Out Instant Credit Transfer schemes. It does not mean that every payment must now include an address: whether an address is required at all still depends on the transaction context. What changes is the format that is allowed when an address is present.

This guide explains the three formats, what the European Payments Council (EPC) actually requires, and how to prepare CSV, Excel, and ERP data before the deadline.

What changes on 15 November 2026

The dates come from the EPC guidance document Provision of Addresses under the EPC Payment Schemes (EPC153-22, version 2.1, issued and effective 5 October 2025).

Period	Address formats allowed
Up to 5 October 2025	Unstructured, structured
5 October 2025 to 15 November 2026	Unstructured, structured, hybrid
From 15 November 2026	Structured, hybrid

Two details matter in practice:

• Instant schemes use a time, not just a date. For SEPA Instant Credit Transfer (SCT Inst) and One-Leg Out Instant Credit Transfer (OCT Inst), each boundary in the table applies from 03:30 CET on the date shown.
• The date changed. Earlier EPC material and many bank documents refer to 22 November 2026. Version 2.1 of EPC153-22 moved the deadline to 15 November 2026 to align with the November 2026 Swift Standards MX release. If you still see the older date somewhere, it has been superseded.

The settlement date decides, not the upload date

The relevant moment is the inter-bank (inter-PSP) settlement date of the transaction, not the day you created or uploaded the file. A file submitted in early November 2026 whose requested execution date or requested collection date (attribute AT-T013) falls on or after 15 November 2026 already needs structured or hybrid addresses. Plan your cut-over a few weeks before the deadline rather than on it.

The three address formats compared

• Unstructured (legacy): the address is written as one or two free-text address lines, optionally with a country code.
• Structured: every component sits in its own dedicated ISO 20022 element.
• Hybrid: the mandatory components are structured, and residual detail that is not available separately stays in address lines.

In ISO 20022 terms, address lines are <AdrLine>, town is <TwnNm>, and country is <Ctry>.

Requirement	Unstructured (legacy)	Structured	Hybrid
Address lines	Two lines	Not allowed	Two × 70 chars
Town required?	Not used	Yes	Yes
Country required?	Optional	Yes	Yes
Other fields	Not used	As relevant	Where data exists
Allowed from 15 Nov 2026	No	Yes	Yes (no end date)
Best for	—	Clean, split data	Legacy data

Here is the legacy format that stops being permitted. This example, and the two that follow, show only the postal-address block of a party — not a complete payment file.

<!-- Legacy unstructured address: not permitted from 15 November 2026 -->
<Cdtr>
  <Nm>ANNA NOVAK</Nm>
  <PstlAdr>
    <Ctry>DE</Ctry>
    <AdrLine>LINDENSTRASSE 12</AdrLine>
    <AdrLine>10115 BERLIN</AdrLine>
  </PstlAdr>
</Cdtr>

What a structured address requires

In a fully structured address:

• <AdrLine> cannot be used at all;
• <TwnNm> (Town Name) and <Ctry> (Country, as a two-letter ISO country code) must be used;
• the other postal-address elements — <StrtNm> street name, <BldgNb> building number, <BldgNm> building name, <PstCd> post code, <CtrySubDvsn> country subdivision and the rest — are used as relevant to the address. They are not universally mandatory.

<!-- Structured address -->
<Cdtr>
  <Nm>ANNA NOVAK</Nm>
  <PstlAdr>
    <StrtNm>LINDENSTRASSE</StrtNm>
    <BldgNb>12</BldgNb>
    <PstCd>10115</PstCd>
    <TwnNm>BERLIN</TwnNm>
    <Ctry>DE</Ctry>
  </PstlAdr>
</Cdtr>

The element order above follows the ISO 20022 postal-address definition used by pain.001.001.09 and pain.008.001.08, where address lines come last, after <Ctry>. The legacy pain.001.001.02 message uses an older postal-address definition in which address lines appear before the structured elements, so do not copy element order between message versions.

What a hybrid address requires

The hybrid format mixes both worlds, under firm conditions:

• <TwnNm> and <Ctry> are mandatory, exactly as in the structured format;
• address lines are limited to two occurrences of 70 characters each;
• any detail that is available in a structured form must be placed in its structured element;
• structured elements cannot be repeated inside <AdrLine>.

<!-- Hybrid address: structured essentials plus one residual line -->
<Cdtr>
  <Nm>ANNA NOVAK</Nm>
  <PstlAdr>
    <PstCd>10115</PstCd>
    <TwnNm>BERLIN</TwnNm>
    <Ctry>DE</Ctry>
    <AdrLine>LINDENSTRASSE 12</AdrLine>
  </PstlAdr>
</Cdtr>

In this example the source system stores post code, town, and country as separate fields, but keeps the street name and building number together in a single line it cannot split. That combined line — and only that — goes into <AdrLine>. Note that the town, post code, and country do not reappear in the address line: duplicating them there is exactly what the format forbids.

Hybrid is a valid long-term format, not a grace period that expires with unstructured addresses: the EPC has set no end date for it for the time being. The EPC nevertheless recommends using the time up to November 2026 to switch from unstructured addresses directly to fully structured addresses, because structured data reduces errors in processing, regulatory screening, and reconciliation.

Does every SEPA payment need an address?

No. The 2026 change is a rule about format, not a new obligation to carry an address in every transaction. Two questions have to be kept apart:

1. Is an address required at all here? This is contextual. In many euro-area transactions between parties whose payment service providers (PSPs) are both in the EEA, the debtor or creditor address is optional under the scheme rulebooks. In other cases it is required — for example, Regulation 2023/1113 (the third Funds Transfer Regulation) requires the full payer address when the payer’s or payee’s PSP is based in a SEPA country outside the EEA, and the payer’s <Ctry> becomes mandatory in that situation.
2. Which format is allowed if an address is supplied? From 15 November 2026, structured or hybrid only.

Address-presence requirements can therefore depend on the scheme, the parties involved, where their PSPs are located, applicable regulation, and each bank’s own implementation. Banks may also impose stricter channel-specific rules than the schemes do. Check your bank’s implementation guidance — and test a real file through your production channel — before you rely on either behaviour.

Impact on pain.001 credit transfers

pain.001 is the customer-to-bank credit transfer initiation message. The current SEPA version, pain.001.001.09, carries the full set of structured postal-address elements for the debtor, the creditor, and the ultimate parties, so no format workaround is needed: if your source data is separated, you can generate structured addresses today.

If you still submit pain.001.001.02 on a legacy channel, address handling is one more reason to plan the move to .09 with your bank — the older message has a different, looser address definition. Our pain.001.001.02 vs pain.001.001.09 guide compares the two versions.

Impact on pain.008 direct debits (Core and B2B)

The same three formats and the same deadline apply to pain.008 SEPA Direct Debit collections, for both the Core and B2B schemes.

Under the direct debit rulebooks, the debtor address and the creditor’s own address are optional in collections where the creditor’s PSP and the debtor’s PSP are both in an EEA SEPA country — but the debtor address must be provided when either PSP is based in a SEPA country outside the EEA. Where a creditor does supply addresses, the creditor PSP relies on the quality of that data: it generally passes the debtor address on unchanged into the inter-bank message, because it has no other source for it. In practice that means address quality in your pain.008 files is your responsibility, not something the bank cleans up for you.

If you generate those collections with SEPA Generator Pro, the SEPA Direct Debit XML generator page describes what the pain.008.001.08 files it produces contain.

Preparing CSV, Excel, and ERP data

Most of the work is in the source data, not in the XML. There is no universal, mandated column naming standard — the point is that the components exist separately somewhere before generation:

• Stop keeping the whole address in one free-text field. A single “address” column is what produces unstructured output.
• At minimum, separate town and a two-letter ISO country code wherever addresses are used.
• Preferably separate street name, building number, post code, town, and country into distinct columns. That gives you fully structured output.
• Decide honestly whether any residual detail really needs an address line. If everything splits, use the structured format and no address lines at all.
• Never duplicate. If street, post code, town, or country sit in structured fields, they must not be repeated in an address line.
• Normalize country codes to two-letter ISO codes (DE, FR, BE), not country names or free text.
• Validate partial records before generation. A row with a street but no town or country is the most common cause of an incomplete structured address.
• Review the records behind the exports, not only one file: saved debtors, creditors, customers, suppliers, employees, mandate records, ERP master data, payroll data, and your own import templates.
• Test with the receiving bank well before the deadline, using the channel you actually submit through.
• Watch the dates around the cut-over: requested execution and collection dates determine settlement, and settlement determines which rules apply.

A prepared CSV export for credit transfers can be as simple as this:

name,iban,amount,street,building_number,postcode,town,country
ANNA NOVAK,DE02100100109307118603,125.00,LINDENSTRASSE,12,10115,BERLIN,DE

Migration checklist

1. Confirm which SEPA schemes and message versions you send, and through which channel.
2. Find every place addresses enter your payment files: ERP exports, payroll, spreadsheets, saved templates, custom scripts.
3. Decide per data source: fully structured, or hybrid where legacy data does not split.
4. Split the address columns and normalize country codes at the source.
5. Fill the gaps — missing towns and missing country codes first.
6. Regenerate a test file and inspect the <PstlAdr> blocks.
7. Submit a test file through your bank’s channel and read the response.
8. Complete the cut-over before mid-November 2026, allowing for execution and collection dates that settle after the deadline.

Common mistakes that lead to rejection

• Half-filled structured addresses — a street name with no town or country.
• Free-text country names (“Germany”) where a two-letter ISO code belongs.
• More than two address lines, or lines longer than 70 characters, in a hybrid address.
• Repeating structured data in <AdrLine>, which the hybrid rules forbid.
• Assuming the file-creation date decides whether the old format is still acceptable — the settlement date does.
• Copying element order between message versions, which produces schema errors rather than address errors.

More on this in common SEPA XML rejection errors.

How SEPA Generator handles addresses

SEPA Generator keeps address data structured from the start: separate street, building_number, postcode, town, and country columns map to the dedicated ISO 20022 elements when generating pain.001.001.09. Addresses are optional — when a row has no address, the postal-address element is simply omitted — and when any address component is present, the free Community Edition requires at least the town and a two-letter ISO country code, so you do not generate half-filled structured addresses. Community generates fully structured addresses; it does not produce hybrid address lines.

SEPA Generator Pro adds Address Readiness for existing XML files: it analyses pain.001 and pain.008 files, classifies each party’s address as structured, hybrid, incomplete, or unstructured, and reports which parties and fields need attention before 15 November 2026. It reports issues for you to fix — it does not rewrite or repair your address data, and it does not replace checking your own bank’s requirements.

Official sources

• European Payments Council, Provision of Addresses under the EPC Payment Schemes — EPC153-22, version 2.1 (issued and effective 5 October 2025): EPC guidance document
• European Payments Council, Important update about the 2025 EPC payment scheme rulebooks (7 October 2025)
• SEPA Credit Transfer Customer-to-PSP Implementation Guidelines (EPC132-08)
• SEPA Direct Debit Core Customer-to-PSP Implementation Guidelines (EPC130-08)
• SEPA Direct Debit B2B Customer-to-PSP Implementation Guidelines (EPC131-08)

Frequently asked questions

Is the hybrid format still allowed after 15 November 2026?

Yes. Structured and hybrid are the two permitted formats from that date, and the EPC has set no end date for the hybrid format for the time being. The EPC still recommends moving to fully structured addresses where that is practical.

Does the change apply to pain.008 direct debits?

Yes. SEPA Direct Debit Core and B2B collections follow the same three formats and the same deadline as credit transfers.

Does every payment now need an address?

No. This is a formatting rule for addresses that are present, not a new requirement to include one. Whether an address is required depends on the scheme, the parties, where their PSPs are located, and applicable regulation — for example, the full payer address is required when a PSP is based in a SEPA country outside the EEA. Your bank may also ask for more than the schemes do.

Can a file created before the deadline still be rejected?

Yes. The decisive date is the inter-bank settlement date. A file sent in early November 2026 with a requested execution or collection date on or after 15 November 2026 must already use a structured or hybrid address.

Why do some documents still show 22 November 2026?

15 November 2026. The earlier 22 November 2026 date was changed in version 2.1 of EPC153-22, published in October 2025, to align with the November 2026 Swift Standards MX release. Bank documentation written before that update may still show the old date.