Structured addresses and ISO 20022: what corporates need to prepare before November 2026

Payments & Cash Management expert Sebastian Schuldt explains that from November 2026, unstructured addresses die. Corporates must structure ISO 20022 data or risk payment failure.

There is still considerable confusion around what exactly changes when structured addresses become mandatory, with a key deadline in mid-/late November 2026 (scheme specific dates apply).

ISO 20022 makes address data more explicit and more structured than before. That puts pressure on master data quality, long before a payment is even sent. Being able to clearly distinguish between town, country, and (in a perfect world) the street and building number is no longer optional.

From November 2026 onward, fully unstructured addresses are no longer permitted. Any address provided must be semi-structured (hybrid) or fully structured. ERPs and electronic banking systems must be ready. Master data needs to be reviewed and corrected. This usually takes some time within different departments of an organisation. It is therefore no last-minute exercise.

This article focuses on corporate-to-bank communication. While most information is general. it focuses on SEPA, the German GBIC standard (Deutsche Kreditwirtschaft), and EBICS, an increasingly adopted communication standard in Europe.

Understanding structured addresses

With the November 2026 deadline for unstructured addresses, it is crucial to prepare master-data in ERP, Treasury, and HR-systems to use structured addresses (or at least semi-structured/hybrid addresses). 

unstructured 

While easy for humans to read, machine interpretation is more difficult because of mingled address elements. That can lead to false positives in compliance checks, yet it is still commonly used (for example, in the German DTAZV format).

<Cdtr>
  <Nm>JOHN DOE</Nm>
  <PstlAdr>
    <AdrLine>KAISERPLATZ 1, 49th floor</AdrLine>
    <AdrLine>60311 Frankfurt</AdrLine>
    <AdrLine>DE</AdrLine>
  </PstlAdr>
</Cdtr>

semi-structured (hybrid)

Structured elements – "Town" and "Country" – are mandatory, with up to two tags each, allowing a maximum of 70 characters in “AdrLine. The semi-structured address has been available since November 2025 and is not merely as a bridge variant; it has no end-date. It was introduced to slightly ease the implementation of fully structured addresses. Nevertheless, to gain full benefits, a completely structured address is always my recommendation.

<Cdtr>
  <Nm>JOHN DOE</Nm>
  <PstlAdr>
    <PstCd>60311</PstCd>
    <TwnNm>FRANKFURT</TwnNm>
    <Ctry>DE</Ctry>
    <AdrLine>KAISERPLATZ 1, 18th floor</AdrLine>
  </PstlAdr>
</Cdtr>

structured

The address is fully structured. Under most market practice guidelines, combining it with the “AdrLine” tag is not allowed. But what if the building number is accidentally mentioned in the "StrtNm" field? In most cases, it has no impact. For the technical format, the "Country" and "Town" fields are mandatory. For foreign payments a full address is often a prerequisite, so precise mapping should always be ensured.

<Cdtr>
  <Nm>JOHN DOE</Nm>
  <PstlAdr>
    <StrtNm>Kaiserplatz</StrtNm>
    <BldgNb>1</BldgNb>
    <Flr>49</Flr>
    <PstCd>60311</PstCd>
    <TwnNm>FRANKFURT</TwnNm>
    <Ctry>DE</Ctry>
  </PstlAdr>
</Cdtr>

The reason behind the structured addresses

With ISO 20022, the data you provide when you initiate a payment stays exactly where it belongs: in dedicated, structured fields. This information remains consistent from customer instruction, through banks and clearing systems, all the way to the beneficiary’s account statement and reporting. It improves fraud and compliance checks and helps maintain a high straight-through-processing rate, even even during periods of stricter regulatory scrutiny.

 
Figure 1: Structured fields persist end-to-end

SEPA and foreign payments

The address mapping highlights that this is not simply an update in a corporate electronic banking or ERP software. If a company relies on master-data when crafting the payments file, the foundation for structured address needs to be available. 

The following information focuses more specifically on the communication channel of EBICS, which is broadly used, especially in Germany. Mentioned abbreviations like CCT (Sepa Credit Transfer), AXZ (Foreign Payment), and CIP (Instant Payment) refer to upload order types in EBICS communication.

Structured addresses in SEPA file formats (DK/GBIC) e.g. CCT/CIP order types

For SEPA clearing, addresses are typically not required and are often best left unused unless there is a clear need.

Keep in mind that the most recent payment formats like the pain.001.001.09 (used in DK/GBIC for Germany) already requires a structured or semi-structured address if you choose to add one.

The exception:

Some corridors (most notably Switzerland (CH) and Great Britain (GB) for direct debits) may require the counterparty`s address even when using a SEPA transfers/direct debit.

Skipping the address is no option; it must be delivered accurately and completely (and in the new formats –  structured / semi-structured – with at least the mandatory fields "Country" and "Town".

Foreign payments (DK/GBIC e.g. via AXZ)

For payments routed outside the SEPA-area or the EEA, there is often an operational expectation (though not always strictly enforced by technical validation today): as soon as a payment leaves the EEA, banks commonly require a complete counterparty address. 

This is commonly treated as default practice across many institutions.

“Leaving the EEA” can occur either because of the counterparty accounts country, or due to currency routing (example: sending USD from DE → AT can trigger a cover message routed outside Europe, such as to the US).

Affected parties typically include creditor, debtors, and ultimate parties. The debtor` address in credit transfers is usually less of a problem, as it is often sourced from bank master data. The real risk lies in missing or poor creditor (and ultimate) data.

What happens in November 2026 in Germany (format lifecycle)

Older SEPA/ GBIC format versions below 3.7 reach end of lifecycle (link: Format Lifecycle - EBICS). The text-based DTAZV is replaced by pain.001.001.09 within the GBIC format version 3.7 and higher (AXZ). 

Therefore, if corporates still run older versions or legacy formats, the November 2026 deadline will force the transition and, with it, the “if you send addresses, do it properly” rule becomes unavoidable.

 Figure 2: Overview of expected changes - focus Germany; please check individually with your banking partners

What happens in November 2026 in Europe and beyond 

From a global perspective, November 2026 is a convergence point for address data rules across major payment rails. In Europe, EPC scheme guidance aligns the phase-out of fully unstructured postal addresses with mid-November 2026, requiring that addresses (when provided) be either hybrid (semi-structured) or fully structured. Worldwide, SWIFT CBPR+ enforces the same direction for cross-border interbank payments: fully unstructured addresses will no longer be accepted from November 2026. This requirement is message-content driven, not transport-driven, meaning it applies regardless of the channels used.

The pain.001.001.03 (cgi)

If a corporate is using pain.001.001.03 based on CGI-MP, no industry-wide hard stop has been announced yet. While work on version "09" is still mostly ongoing within banks, pain.001.001.03 with structured or semi-structured addresses is expected to remain operational in many environments, subject to bilateral agreement with banking partners.

How to prepare

Corporates should start preparing early to avoid operational disruptions and last-minute remediation efforts. A structured approach can help ensure a smooth transition.

1.    Establish a solid foundation

•    Review master data. Assess the quality and completeness of address data across suppliers, customers, and internal records, including HR master data where relevant.
•    Assess system readiness. Confirm that ERP, treasury, and banking systems support the required ISO 20022 formats and structured or hybrid address fields.
•    Test end-to-end processes. Where possible, run test payments or low-risk payment batches to validate setup before moving to production. Early engagement with banking partners is strongly recommended.

As a general principle, addresses should only be included where required. The requirement is specified in format descriptions or rulebooks issued. However, when provided, the addresses need to be structured and complete. Conducting small-value test transactions can help confirm stability and prevent downstream repair processes.

2.    Consider payment scenarios

•    Domestic SEPA payments within the EEA (IBAN-only). Omitting address data is often the simplest and most robust approach, supporting high straight-through processing rates where addresses are not needed.
•    SEPA transactions involving specific corridors (for example Switzerland or the United Kingdom) or scenarios where payments may effectively leave the EEA. Assume address data may be required, particularly for direct debits, and ensure it can be provided in a structured or hybrid format.
•    Cross-border payments. Complete address information should be treated as mandatory from both a regulatory and operational perspective. While minimal fields may allow a payment to pass technical validation, incomplete data often leads to delays, investigations, and manual handling.

Reporting vs. payment initiation - avoiding a false sense of security

Continuing to receive legacy account reporting formats such as MT940 after key migration milestones can create a false sense of security when assessing overall readiness for ISO 20022.

The transition to richer reporting formats, such as camt.053, may appear less time-critical right now. Reporting represents information provided by banks, and legacy outputs can often be maintained during a transitional period. However, corporates should not assume this flexibility extends indefinitely, as there may be cost implications – and, most importantly, it does not apply to payment initiation.

Payment initiation follows a different dynamic. Clearing and scheme requirements increasingly mandate structured data, including structured or hybrid address information, as part of the processing chain. As a result, delaying customer-to-bank migration milestones is generally not a sustainable strategy.

Corporates are therefore strongly advised to engage proactively with their banking partners to confirm timelines, dependencies, and readiness expectations across both reporting and payment channels.

Preparing for structured addresses goes beyond format changes; it represents a core data governance exercise with tangible implications for risk management and payment continuity.

The information provided reflects the author’s understanding of current market practices and publicly available guidance at the time of writing. Timelines and requirements may vary by bank, scheme, and jurisdiction. Corporates should confirm details with their banking partners and relevant authorities before taking action.

About Sebastian Schuldt

With nearly 26 years of experience in banking, Sebastian Schuldt provides practitioner insights into payments transformation and the operational challenges corporates face, including the transition to ISO 20022. At Commerzbank AG, he works with multinational clients navigating the complexities of global payments and regulatory change. His focus includes developments in blockchain (DLT) and digital currencies, and their implications for corporate treasury. The views expressed are personal and do not necessarily reflect those of Commerzbank AG.