SEPA explainer General SEPA knowledge

SEPA structured addresses: EPC update and preparation

Last updated: 26 October 2026

The European Payments Council (EPC) previously planned to stop permitting the legacy unstructured address format in SEPA payment messages from 15 November 2026. In September 2026, version 2.2 of the EPC address guidance removed that date. The EPC will determine a new end date for the unstructured format in due course, based on market and payment-industry developments. No replacement date has been published yet.

The direction has not changed: structured and hybrid addresses are the formats the EPC is moving to, and both are already permitted today. Preparing your address data now is still the sensible course — it simply no longer has to be finished by a fixed date in November 2026.

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 the guidance governs is the format that is allowed when an address is present.

This guide explains the current EPC position, the three formats, and how to prepare CSV, Excel, and ERP data.

What the EPC changed in September 2026

The rules come from the EPC guidance document Provision of Addresses under the EPC Payment Schemes (EPC153-22). Version 2.2, released in September 2026, took the 15 November 2026 end date for unstructured addresses out of the document. At the same time the EPC published version 1.2 of the five 2025 EPC payment scheme rulebooks; the EPC states that version 1.2 has no impact on any other business or operational rules compared with version 1.1.

Period	Address formats allowed
Up to 5 October 2025	Unstructured, structured
From 5 October 2025	Unstructured, structured, hybrid
End of the unstructured format	Not set — the EPC will determine a new end date in due course

Two details matter in practice:

• Your bank’s own rules still apply. The EPC schemes set the minimum. A bank or upload channel can ask for structured or hybrid addresses on its own timetable, so check its implementation guidance rather than relying on the scheme position alone.
• Older dates are now out of date. Earlier EPC material and many bank documents refer to 22 November 2026, which was changed to 15 November 2026 in version 2.1 of EPC153-22. Version 2.2 then removed the 15 November 2026 end date as well. If you see either date presented as a current deadline, the document predates the September 2026 update.

Plan around settlement dates when a new date is announced

Under version 2.1, the decisive moment was the inter-bank (inter-PSP) settlement date of a transaction, not the day the file was created or uploaded, so a file with a requested execution or collection date (attribute AT-T013) after the cut-over would already have been affected. When the EPC announces a new end date, check how it applies to execution and collection dates before you plan your own cut-over.

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
EPC end date	To be set by the EPC	None	None set
Best for	—	Clean, split data	Legacy data

Here is the legacy format the EPC intends to phase out. This example, and the two that follow, show only the postal-address block of a party — not a complete payment file.

<!-- Legacy unstructured address: being phased out; the EPC will set an end date -->
<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: the EPC has set no end date for the hybrid format for the time being. The EPC nevertheless recommends switching from unstructured addresses directly to fully structured addresses where possible, because structured data reduces errors in processing, regulatory screening, and reconciliation.

Should you still prepare now?

Yes. Removing the date changes the timing, not the destination:

• structured and hybrid addresses are already permitted, so there is nothing to wait for before you switch;
• the EPC has said it will set a new end date for unstructured addresses, and cleaning up address data across ERP, payroll, and spreadsheet sources takes time;
• your bank or upload channel may ask for structured or hybrid addresses before the schemes do;
• structured data is easier to validate and to screen, whatever the deadline.

What you no longer need is an emergency cut-over planned around mid-November 2026.

Does every SEPA payment need an address?

No. The address guidance 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? Structured or hybrid, which are the long-term formats, or unstructured until the EPC sets its new end date — subject to your bank’s own requirements.

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 open end date for unstructured addresses, 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 before you change formats in production, using the channel you actually submit through.
• Watch the EPC announcements: when a new end date is set, check how it applies to requested execution and collection dates.

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. Switch production files once your bank confirms the format, and keep an eye on the EPC guidance for the new end date of the unstructured format.

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.
• Relying only on the scheme position when your bank or channel already applies stricter address rules.
• 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 you move to structured or hybrid addresses. 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.

If you are moving older files forward at the same time, Pro can also validate existing XML against its bundled official schemas and migrate supported pain.001.001.02/.03 files to .09 and pain.008.001.02 files to .08. Migration changes the message version; it does not restructure addresses for you. Some banks publish their own address rules on top of the EPC guidance; the Bank of Ireland guide is one example.

Official sources

• European Payments Council, Provision of Addresses under the EPC Payment Schemes — EPC153-22, version 2.2 (September 2026), which removed the 15 November 2026 end date for unstructured addresses: EPC guidance document
• European Payments Council, Important update about the 2025 EPC payment scheme rulebooks (7 October 2025, background to version 2.1)
• 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 unstructured address format still allowed?

Under the EPC schemes, yes for now. Version 2.2 of EPC153-22 removed the 15 November 2026 end date, and the EPC will determine a new end date in due course. Your bank may already apply stricter rules on its own channels, so check its guidance before relying on unstructured addresses.

Is the hybrid format still allowed?

Yes. Structured and hybrid are the long-term formats, 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 update apply to pain.008 direct debits?

Yes. SEPA Direct Debit Core and B2B collections follow the same three formats as credit transfers, and the same open end date for unstructured addresses.

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.

Why do some documents still show 15 or 22 November 2026?

They predate the latest EPC updates. The original 22 November 2026 date was changed to 15 November 2026 in version 2.1 of EPC153-22, published in October 2025, to align with the November 2026 Swift Standards MX release. Version 2.2, published in September 2026, then removed the 15 November 2026 end date altogether. Bank documentation written before those updates may still show either date.