Guide · SEPA formats · Germany
Migrating pain.001.001.03 to pain.001.001.09 before November 2026.
From 15 November 2026 a free-text <AdrLine> address is rejected across SEPA credit transfers, direct debits and instant payments. <TwnNm> and <Ctry> become mandatory. German banks withdraw pain.001.001.03 the day before. Individual banks set their own dates and they are not all the same. Verify yours before you plan.
What changes
| Credit transfer | pain.001.001.03 | pain.001.001.09 |
| Direct debit | pain.008.001.02 | pain.008.001.08 |
| Status report | pain.002.001.03 | pain.002.001.10 |
| Foreign payment | DTAZV fixed-record file | pain.001 under the AXZ order type |
| Postal address | Free text accepted | Structured, or hybrid with limits |
The address block, three ways
The same address, written as most ERPs emit it today, as the rules require from 15 November 2026, and in the hybrid form the rules also permit. The element names are what change; the data is identical.
Rejected
unstructured<PstlAdr> <AdrLine>Königsallee 60</AdrLine> <AdrLine>40212 Düsseldorf</AdrLine> <AdrLine>Deutschland</AdrLine> </PstlAdr>
No town element and no country code, so a bank cannot screen it reliably.
Structured
no AdrLine<PstlAdr> <StrtNm>Königsallee</StrtNm> <BldgNb>60</BldgNb> <PstCd>40212</PstCd> <TwnNm>Düsseldorf</TwnNm> <Ctry>DE</Ctry> </PstlAdr>
Every component in its own element. Ctry is an ISO 3166-1 alpha-2 code.
Hybrid
max 2 AdrLine<PstlAdr> <TwnNm>Düsseldorf</TwnNm> <Ctry>DE</Ctry> <AdrLine>Königsallee 60</AdrLine> </PstlAdr>
Town and country as elements, the street left as a line, with no duplication.
Why the hybrid form matters
Splitting Königsallee 60 into a street and a building number is the part most ERPs cannot do, because the master data was never captured that way. The hybrid form removes that requirement: at most two <AdrLine> elements of up to 70 characters, with <TwnNm> and <Ctry> as their own elements.
The one rule to observe
No duplication. Anything placed in a structured element must not appear again in a free-text line. In practice the minimum change is smaller than it first appears: the town and the country have to become fields, and the street may stay as text.
The date, bank by bank
Each row is taken from that bank’s own published notice, read on 10 September 2026. Where a bank names only a month, the table says so rather than filling in the industry date on its behalf.
| Bank | Date | What the bank published | |
|---|---|---|---|
| apoBank | 1 Oct 2026 | Older forms switched off on every channel, six weeks early | Read more → |
| Berliner Volksbank | 13–14 Nov 2026 | Last cut-off the 13th, hard cutover the 14th | Read more → |
| Warburg Bank | 14 Nov 2026 | The industry date, stated as 00:01 | Read more → |
| SozialBank | 14 Nov 2026 | The industry date, stated as 00:01 | Read more → |
| Berliner Sparkasse | Nov 2026 | Format versions 3.0 to 3.6 withdrawn; submit in 3.7+ | Read more → |
| BayernLB | Nov 2026 | DTAZV ends; urgent transfers move off .03 | Read more → |
| Haspa | Nov 2026 | Announced, exact day not published | Read more → |
| Sparkasse Bremen | Nov 2026 | Announced, exact day not published | Read more → |
| Naspa | Nov 2026 | Announced, exact day not published | Read more → |
| NORD/LB | Nov 2026 | Month only; DTAZV replaced by AXZ | Read more → |
| OLB | Nov 2026 | Formats to version 3.6 withdrawn; MT940 ends too | Read more → |
| Aareal Bank | 15 Nov 2026 | AZV retires, replaced by AXZ | Read more → |
| Helaba | Not published | No pain.001.001.09 or DTAZV date published | Read more → |
| Berenberg | Not published | The bank publishes no format notice | Read more → |
What this means for a BankConnector connection
Your ERP never has to emit .09
You send the payment as data. We produce the version each bank requires, on the day that bank requires it, with the address elements in the right shape. The XML migration is ours, and it is already done: pain.001.001.09 is one of the two versions our engine emits and banks run on it today.
One date per connection, not one date for you
The version sits on each bank’s profile. So a bank moving on 1 October and a bank moving on 14 November are two settings, not two projects, and nothing changes in what you send us on either date.
Structured addresses since canonical input 1.1
Our input has taken street, building number, post code, town and country as separate fields since version 1.1. Give us those and we emit the structured form; give us a town and a country with the street as a line and we emit the hybrid form.
If your data cannot produce the fields, talk to us
The hybrid form needs only a town and a country, and many payloads already carry the country. Where the remaining fields sit inside a block of text, we have options for deriving them at conversion. Which option applies depends on the country and on what your data contains, so it is worth a conversation before anyone schedules an ERP release. Send us a sample file and we will tell you what is possible.
We never produced DTAZV
Foreign payments have always gone out as ISO 20022 through AXZ, so the DTAZV retirement removes nothing we do.
One integration, and the format dates stop being your problem.
You send canonical JSON. We produce whatever version each bank requires on the day it requires it, and read the statements back in one shape.
Related reading: ISO 20022 payment automation for ERPs, host-to-host bank connectivity and open banking versus host-to-host.
Sources — each bank’s own published format notice, linked from the bank guides above, and the EBICS specifications and data-format appendices published by Die Deutsche Kreditwirtschaft. This page describes what banks have published; it is not legal or compliance advice, and your own bank’s current notice governs.