On 24 September 2026, the Deutsche Kreditwirtschaft (DK), the joint committee of the German banking associations, suspended the retirement of the legacy formats planned for November 2026 — foreign payments included. No new end date has been set; it will follow SWIFT and the EPC. The migration itself does not go away: your bank still sets its own day, and as of 25 September 2026 GLS Bank is keeping 14 November 2026. Once your bank's own cut-off has passed, foreign payments to it are submitted only as XML files in the pain.001.001.09 format, over EBICS with the order type AXZ. This guide covers the dates, what the AXZ variant actually requires, how to create and check your first file, and what to clarify with your bank beforehand. Last updated: 25 September 2026.
What changes in November 2026
The DK rule: from 15 November 2026, version 26.11 of Appendix 3 to the DFÜ agreement applies (final version of 9 April 2026). Its change log states (our translation from the German, p. ii) that the coexistence phase of MT and MX for credit transfers will end in November 2026 and that, as a result, the DTAZV format will also be phased out as the DK standard. The DTAZV chapter 3.3 is deleted, and from November 2026 foreign payments can only be submitted on the basis of the ISO 20022 standard (German version, p. 258). On ebics.de, the DK added that the DTAZV format may no longer be used from November 2026 and that the switch to pain.001 must be completed by then (as of 22 September 2026 — see the suspension of 24 September below).
Your bank sets the exact day. The DK format lifecycle gave only the month for DTAZV, 11/2026, and left the exact day to each payment service provider; since 24 September 2026 the lifecycle page carries the notice „Vorübergehend weiter verwendbar“ (temporarily still usable), with no new end date named. GLS Bank has not followed so far: from 00:01 on 14 November 2026, it no longer accepts DTAZV files — unchanged as of 25 September 2026, with no mention of the suspension. We have no information on other institutions. From the same moment it no longer accepts versions older than pain.001.001.09 (credit transfers) and pain.008.001.08 (direct debits), so neither pain.001.001.03 nor pain.008.001.02. According to GLS, DTAZV support “in the DK” ends on 1 December 2026. That date does not appear in the DK's own documents, which give November 2026 (format lifecycle: 11/2026) and 15 November 2026 (Appendix 3 V26.11 and the notice on ebics.de).
Orders submitted earlier count too. As long as your bank keeps its cut-off date, a DK notice on ebics.de says the change also affects orders submitted before the deadline whose execution date falls on 15 November 2026 or later, and orders that are not fully authorised by then (distributed electronic signature, VEU). Re-create scheduled DTAZV orders in the new format in good time.
What about the address postponement? Swift (27 August 2026) and the European Payments Council (10 September 2026) postponed the end of unstructured addresses. On 24 September 2026 the DK followed: because SWIFT and the EPC keep tolerating unstructured address data between banks beyond November, it suspended the planned retirement of the legacy formats for SEPA payments, foreign payments and same-day euro payments, and keeps operating them temporarily; it will name the new end dates only once SWIFT and the EPC have set their own. What moved is the date, not the work: Appendix 3 V26.11 still applies from 15 November 2026, and your bank may keep its own cut-off. Ask there before you change your plan. For all 2026 deadlines at a glance, see our ISO 20022 migration guide.
Your bank sets the exact day. The DK format lifecycle gave only the month for DTAZV, 11/2026, and left the exact day to each payment service provider; since 24 September 2026 the lifecycle page carries the notice „Vorübergehend weiter verwendbar“ (temporarily still usable), with no new end date named. GLS Bank has not followed so far: from 00:01 on 14 November 2026, it no longer accepts DTAZV files — unchanged as of 25 September 2026, with no mention of the suspension. We have no information on other institutions. From the same moment it no longer accepts versions older than pain.001.001.09 (credit transfers) and pain.008.001.08 (direct debits), so neither pain.001.001.03 nor pain.008.001.02. According to GLS, DTAZV support “in the DK” ends on 1 December 2026. That date does not appear in the DK's own documents, which give November 2026 (format lifecycle: 11/2026) and 15 November 2026 (Appendix 3 V26.11 and the notice on ebics.de).
Orders submitted earlier count too. As long as your bank keeps its cut-off date, a DK notice on ebics.de says the change also affects orders submitted before the deadline whose execution date falls on 15 November 2026 or later, and orders that are not fully authorised by then (distributed electronic signature, VEU). Re-create scheduled DTAZV orders in the new format in good time.
What about the address postponement? Swift (27 August 2026) and the European Payments Council (10 September 2026) postponed the end of unstructured addresses. On 24 September 2026 the DK followed: because SWIFT and the EPC keep tolerating unstructured address data between banks beyond November, it suspended the planned retirement of the legacy formats for SEPA payments, foreign payments and same-day euro payments, and keeps operating them temporarily; it will name the new end dates only once SWIFT and the EPC have set their own. What moved is the date, not the work: Appendix 3 V26.11 still applies from 15 November 2026, and your bank may keep its own cut-off. Ask there before you change your plan. For all 2026 deadlines at a glance, see our ISO 20022 migration guide.
Which pain.001 variant for which payment?
The DK distinguishes four business transactions that customers can submit as pain.001 (Appendix 3, p. 257). Besides the SEPA instant credit transfer, these are:
What used to go through DTAZV, such as US dollars to the United States or Swiss francs to Switzerland, is a foreign payment (AXZ). The DK lists it as a DK standard, optional since 11/2022 and mandatory from 11/2026, and exclusively in the pain.001.001.09 format (p. 258). There is no AXZ variant in pain.001.001.03.
• EBICS: order type AXZ, BTF parameters XCT/DE//pain.001/ (p. 260). The bank provides the status report (pain.002) via AXS, that is REP/DE/XCT/pain.002/ZIP (p. 314).
• FinTS/HBCI: business transaction HKAUP. The former DTAZV order, HKAUB, is rejected, according to a HypoVereinsbank letter to its customers.
• Do not submit it as a SEPA credit transfer (CCT): the DK schema for SEPA accepts euro only.
• Do not submit it as a euro urgent transfer (CCU): euro only, same day only, by agreement only.
• Euro to an IBAN in the EEA is, as a rule, a SEPA credit transfer. GLS Bank advises that the pain.001.001.09 format for foreign payments should generally not be used for SEPA-capable transactions.
| Variant | Used for | EBICS (BTF or order type) | Service level |
|---|---|---|---|
| SEPA credit transfer | euro payments to an IBAN in the SEPA area | SCT///pain.001/ or CCT | SEPA |
| Euro urgent transfer (Euro-Eilüberweisung) | same-day payments in euro, only by agreement with the bank | XCT/DE/URG/pain.001/ or CCU | URGP |
| Foreign payment (Auslandsüberweisung) | payments to countries outside the EEA, and payments in foreign currencies within the EEA | XCT/DE//pain.001/ or AXZ | NURG (or URGP, SDVA) |
What used to go through DTAZV, such as US dollars to the United States or Swiss francs to Switzerland, is a foreign payment (AXZ). The DK lists it as a DK standard, optional since 11/2022 and mandatory from 11/2026, and exclusively in the pain.001.001.09 format (p. 258). There is no AXZ variant in pain.001.001.03.
• EBICS: order type AXZ, BTF parameters XCT/DE//pain.001/ (p. 260). The bank provides the status report (pain.002) via AXS, that is REP/DE/XCT/pain.002/ZIP (p. 314).
• FinTS/HBCI: business transaction HKAUP. The former DTAZV order, HKAUB, is rejected, according to a HypoVereinsbank letter to its customers.
• Do not submit it as a SEPA credit transfer (CCT): the DK schema for SEPA accepts euro only.
• Do not submit it as a euro urgent transfer (CCU): euro only, same day only, by agreement only.
• Euro to an IBAN in the EEA is, as a rule, a SEPA credit transfer. GLS Bank advises that the pain.001.001.09 format for foreign payments should generally not be used for SEPA-capable transactions.
What an AXZ file actually requires
The skeleton of the file is the one you know from SEPA: group header (GrpHdr), payment information block (PmtInf), individual transfers (CdtTrfTxInf). The DK rules for AXZ (Appendix 3, chapter 3.1) differ, however, on points where files from older tools typically fail:
• Payment type per transfer: PmtTpInf is mandatory on every individual transfer and is not used at batch level (p. 268, 276). Only NURG, URGP and SDVA are allowed as service level (p. 277); a standard foreign payment is NURG.
• Charges per transfer: ChrgBr is mandatory on every transfer and is not used at batch level (p. 271, 279). Allowed values are DEBT, CRED and SHAR (p. 311).
• Account currency: DbtrAcct/Ccy is mandatory (p. 269), so EUR for a euro account.
• Creditor address: Appendix 3 recommends it for every credit transfer and requires it for payments to countries outside the EU/EEA, in non-EU/EEA currencies or in CHF (p. 293), unless the creditor is identified by its own BIC in the AnyBIC field. When an address is given, town (TwnNm) and country (Ctry) are mandatory (p. 309); street, building number and postcode are optional. Since 23 November 2025, the hybrid form with at most two AdrLine lines is also allowed (pp. 308–309).
• Character set: letters, digits and a few special characters. Umlauts and ß are not allowed: Ä, Ö and Ü must be written AE, OE and UE, and ß as ss. Text fields must not consist of spaces only (p. 259 f.).
• Execution date: banks are not obliged to process orders submitted more than 15 calendar days before the execution date (p. 268).
The structure is checked by the DK schema pain.001.001.09_AXZ_GBIC_5 (TVS). The address and character set rules, however, exist only in the text of Appendix 3: a file can pass the schema and still break them.
• Payment type per transfer: PmtTpInf is mandatory on every individual transfer and is not used at batch level (p. 268, 276). Only NURG, URGP and SDVA are allowed as service level (p. 277); a standard foreign payment is NURG.
• Charges per transfer: ChrgBr is mandatory on every transfer and is not used at batch level (p. 271, 279). Allowed values are DEBT, CRED and SHAR (p. 311).
• Account currency: DbtrAcct/Ccy is mandatory (p. 269), so EUR for a euro account.
• Creditor address: Appendix 3 recommends it for every credit transfer and requires it for payments to countries outside the EU/EEA, in non-EU/EEA currencies or in CHF (p. 293), unless the creditor is identified by its own BIC in the AnyBIC field. When an address is given, town (TwnNm) and country (Ctry) are mandatory (p. 309); street, building number and postcode are optional. Since 23 November 2025, the hybrid form with at most two AdrLine lines is also allowed (pp. 308–309).
• Character set: letters, digits and a few special characters. Umlauts and ß are not allowed: Ä, Ö and Ü must be written AE, OE and UE, and ß as ss. Text fields must not consist of spaces only (p. 259 f.).
• Execution date: banks are not obliged to process orders submitted more than 15 calendar days before the execution date (p. 268).
The structure is checked by the DK schema pain.001.001.09_AXZ_GBIC_5 (TVS). The address and character set rules, however, exist only in the text of Appendix 3: a file can pass the schema and still break them.
Charges: OUR, SHA, BEN and the DTAZV codes
In DTAZV, the charges rule was the code 00, 01 or 02 in field T21; in SWIFT messages it is SHA, OUR or BEN. In pain.001 the element is called ChrgBr:
The definitions are in Appendix 3 V26.11 on p. 311, the DTAZV codes in the last DTAZV specification (Appendix 3 V3.9, p. 356). The mapping follows from these definitions. What you are actually charged depends on your bank's price list.
| Who bears the charges? | DTAZV (T21) | SWIFT | pain.001 (ChrgBr) |
|---|---|---|---|
| Payer pays its own bank, beneficiary pays the rest (shared) | 00 | SHA | SHAR |
| Payer pays all charges | 01 | OUR | DEBT |
| Beneficiary pays all charges | 02 | BEN | CRED |
The definitions are in Appendix 3 V26.11 on p. 311, the DTAZV codes in the last DTAZV specification (Appendix 3 V3.9, p. 356). The mapping follows from these definitions. What you are actually charged depends on your bank's price list.
AWV reporting: not part of the file
For cross-border payments above 50,000 euros (or the equivalent), a reporting obligation under section 67 of the German Foreign Trade and Payments Ordinance (AWV) may apply. As the payer, you file that report yourself with the Deutsche Bundesbank. GLS Bank says so explicitly: the report must always be made by the payer directly to the Bundesbank.
The pain.001 file does not carry this report, and our generator does not file it either: for a German account it only reminds you of it.
The pain.001 file does not carry this report, and our generator does not file it either: for a German account it only reminds you of it.
Checklist before your first AXZ file
1. Bank: is the AXZ order type (EBICS) or the HKAUP business transaction (FinTS) enabled for your account, and until which day does your bank still accept DTAZV? The DK recommends switching only once your bank has informed you.
2. Software: does your banking software support pain.001.001.09 for foreign payments, and from which version?
3. Version: the namespace in the file header must be pain.001.001.09, not pain.001.001.03.
4. Account currency: fill DbtrAcct/Ccy with your account's currency, usually EUR.
5. Creditor address: at least town and country (ISO country code such as US, CH or GB); mandatory for payments outside the EU/EEA, in non-EU/EEA currencies and in CHF.
6. Creditor bank: give the BIC. Without a BIC, the DK requires the bank's name and address, with at least town and country (p. 284).
7. Charges: set SHAR, DEBT or CRED for every transfer.
8. Character set: no umlauts and no ß: Müller becomes Mueller, Straße becomes Strasse.
9. Keep SEPA separate: euro payments to an IBAN in the EEA still belong in a SEPA file, not in the AXZ file.
10. Test: submit your first file with a small payment and read the status report (AXS, pain.002): ACTC means technically accepted, RJCT rejected. Create scheduled orders executing on or after your bank's cut-off date directly in the new format.
2. Software: does your banking software support pain.001.001.09 for foreign payments, and from which version?
3. Version: the namespace in the file header must be pain.001.001.09, not pain.001.001.03.
4. Account currency: fill DbtrAcct/Ccy with your account's currency, usually EUR.
5. Creditor address: at least town and country (ISO country code such as US, CH or GB); mandatory for payments outside the EU/EEA, in non-EU/EEA currencies and in CHF.
6. Creditor bank: give the BIC. Without a BIC, the DK requires the bank's name and address, with at least town and country (p. 284).
7. Charges: set SHAR, DEBT or CRED for every transfer.
8. Character set: no umlauts and no ß: Müller becomes Mueller, Straße becomes Strasse.
9. Keep SEPA separate: euro payments to an IBAN in the EEA still belong in a SEPA file, not in the AXZ file.
10. Test: submit your first file with a small payment and read the status report (AXS, pain.002): ACTC means technically accepted, RJCT rejected. Create scheduled orders executing on or after your bank's cut-off date directly in the new format.
Create and check the file with ISO 20022 Generator
Create: the international transfer generator starts on pain.001.001.09. You set up your originator profile once (name, IBAN, BIC), then enter for each payment the beneficiary, IBAN or account number, BIC, amount, currency and charges, plus the beneficiary's town and country. The generator puts the service level (NURG) and the charges code on every individual transfer and rewrites umlauts according to the DK rule (Ä, Ö, Ü as AE, OE, UE).
If your IBAN starts with DE, the following applies as well:
• DbtrAcct/Ccy is filled, with EUR by default.
• The form checks Appendix 3 rules the schema cannot see: a missing beneficiary address where one is required, characters outside the allowed set, euro payments into the EEA (that is what the SEPA credit transfer is for), and the choice of pain.001.001.03. You must explicitly confirm any such deviation before downloading.
• A notice gives the filing route: EBICS order type AXZ (BTF XCT/DE//pain.001/) or FinTS HKAUP, not as a SEPA credit transfer (CCT) and not as an urgent transfer (CCU). Check with your bank that AXZ is enabled. The notice also reminds you of the AWV report.
Check: the free validator checks pain.001 files against the generic ISO 20022 schema (XSD), including files from other software. It does not check the DK AXZ profile: “valid” there means valid against the ISO schema, not “checked by the DK”.
Banking data is processed in memory and never stored on our servers. You can try the form without signing in, in demo mode with up to two rows; multi-currency files are generated on the “International & SWIFT” plan (30 euros a month, with a free 2-day trial).
If your IBAN starts with DE, the following applies as well:
• DbtrAcct/Ccy is filled, with EUR by default.
• The form checks Appendix 3 rules the schema cannot see: a missing beneficiary address where one is required, characters outside the allowed set, euro payments into the EEA (that is what the SEPA credit transfer is for), and the choice of pain.001.001.03. You must explicitly confirm any such deviation before downloading.
• A notice gives the filing route: EBICS order type AXZ (BTF XCT/DE//pain.001/) or FinTS HKAUP, not as a SEPA credit transfer (CCT) and not as an urgent transfer (CCU). Check with your bank that AXZ is enabled. The notice also reminds you of the AWV report.
Check: the free validator checks pain.001 files against the generic ISO 20022 schema (XSD), including files from other software. It does not check the DK AXZ profile: “valid” there means valid against the ISO schema, not “checked by the DK”.
Banking data is processed in memory and never stored on our servers. You can try the form without signing in, in demo mode with up to two rows; multi-currency files are generated on the “International & SWIFT” plan (30 euros a month, with a free 2-day trial).
What we claim, and what we do not
For a German account (IBAN DE…) in the pain.001.001.09 format, the multi-currency file is built to pass the DK validation schema (TVS) for foreign payments, pain.001.001.09_AXZ_GBIC_5. We verify this automatically on every change in CI, using typical cases, with a strict validation that also catches the elements the schema forbids. The form also checks rules of Appendix 3 V26.11 that the schema cannot see (beneficiary address, character set) and flags deviations before you download; it fills in the account currency (DbtrAcct/Ccy) with EUR by default.
What we explicitly do not claim:
• that your bank will accept the file: each bank can add its own rules, and a real test with a German bank is still pending;
• any review or certification by the DK: there is none for our generator;
• that the validator checks your file against the DK profile: it checks the ISO schema;
• anything for files in pain.001.001.03, for accounts outside Germany, or for deviations you have confirmed;
• anything about your bank's cut-off dates or a postponement.
So submit your first file with a small amount and read the status report.
What we explicitly do not claim:
• that your bank will accept the file: each bank can add its own rules, and a real test with a German bank is still pending;
• any review or certification by the DK: there is none for our generator;
• that the validator checks your file against the DK profile: it checks the ISO schema;
• anything for files in pain.001.001.03, for accounts outside Germany, or for deviations you have confirmed;
• anything about your bank's cut-off dates or a postponement.
So submit your first file with a small amount and read the status report.
Sources
• GLS Bank, change of pain formats and DTAZV (German): gls.de/pain, accessed 25 September 2026
• GLS Bank, foreign payments and AWV reporting (German): gls.de
• DK, Appendix 3 to the DFÜ agreement, version 26.11 of 9 April 2026, valid from 15 November 2026: ebics.de/de/datenformate. Page numbers refer to the German version (Anlage 3).
• DK, supplementary documents (TVS AXZ GBIC_5, note on DTAZV): ebics.de
• DK, format lifecycle: ebics.de
• DK, „Verschiebung der Abkündigung von Datenformatversionen“ of 24 September 2026: ebics.de/de/aktuelles, accessed 25 September 2026
• DK, Appendix 3 version 3.9 with the last DTAZV specification: archive on ebics.de
• HypoVereinsbank, customer letter on HKAUP, quoted on the ALF-BanCo forum (10 June 2026)
• Swift, 27 August 2026: Structured address deadline extended
• European Payments Council, 10 September 2026: EPC delays address format migration timeline
• GLS Bank, foreign payments and AWV reporting (German): gls.de
• DK, Appendix 3 to the DFÜ agreement, version 26.11 of 9 April 2026, valid from 15 November 2026: ebics.de/de/datenformate. Page numbers refer to the German version (Anlage 3).
• DK, supplementary documents (TVS AXZ GBIC_5, note on DTAZV): ebics.de
• DK, format lifecycle: ebics.de
• DK, „Verschiebung der Abkündigung von Datenformatversionen“ of 24 September 2026: ebics.de/de/aktuelles, accessed 25 September 2026
• DK, Appendix 3 version 3.9 with the last DTAZV specification: archive on ebics.de
• HypoVereinsbank, customer letter on HKAUP, quoted on the ALF-BanCo forum (10 June 2026)
• Swift, 27 August 2026: Structured address deadline extended
• European Payments Council, 10 September 2026: EPC delays address format migration timeline