Changes to payment transactions as of November 2026
The requirements for payment transactions are constantly evolving. With the updates outlined in Annex 3 of the German Banking Industry Committee’s (Deutsche Kreditwirtschaft – DK) Electronic Data Interchange (EDI) Agreement, significant changes will take effect starting in 2026, and companies should prepare for them well in advance.
Overview of changes
As of November 16, 2026, significant changes to payment transactions will take effect with the new Annex 3 of the EDI-Agreement. The “Specification of Data Formats” established by the German Banking Industry Committee (DK) defines the technical standards for the exchange of payment data between businesses and banks and is based on the ISO 20022 XML formats.
- Further development of ISO 20022 data formats, for international payments, SEPA payments, and account information
- Mandatory use of structured addresses – unstructured address information will no longer be supported in future
For companies, this primarily means a need to adapt payment systems, interfaces, and master data. It is therefore advisable to review existing processes and data formats at an early stage and align them with the new requirements.
The versioning of Annex 3 will also be based on the date of coming into effect (year, month) in the future. The new version is therefore designated “26.11”.
Format LifeCycle
The current DTAZV submission format will no longer be the standard of the German Banking Industry Committee (DK) as of November 2026 and will no longer be supported in future.
Starting November 16, 2026, please submit international payments in the ISO 20022 format pain.001.001.09 (EBICS order type AXZ).
What does this mean for you?
- TRAVIC Port (manual entry):
No adjustments required - TRAVIC Port (file upload via third-party system):
Your used system must be converted to the new formats - Own EBICS client:
Please ensure that only the current format versions are used
Starting November 16, 2026, only the updated data formats specified in Annex 3 (“Specification of Data Formats”) will be supported:
- pain.001.001.09 (credit transfers)
- pain.008.001.08 (direct debits)
in the currently valid DK version 3.7 and higher
Older formats can no longer be processed after that date.
What does this mean for you?
- TRAVIC Port (manual entry):
No adjustments required - TRAVIC Port (file upload via third-party system):
Your used system must be converted to the new formats - Own EBICS client:
Please ensure that only the current format versions are used
Starting November 16, 2026, we will provide you with account and transaction information in the ISO 20022 format:
- camt.053.001.08 (daily statement)
- camt.052.001.08 (intraday transactions)
- camt.054.001.08 (collective entried)
Older MT formats (e.g., MT940/MT942) and earlier camt versions will no longer be supported.
We will continue to provide MT940 and MT942 for a transitional period until 2027. However, please plan for a timely transition to the ISO 20022 formats and note that no further development is taking place for the MT formats.
Important note
If you are currently still using MT940 or MT942, we are already providing you with these data in the modern camt formats.
To switch from camt.052.001.02 or camt.053.001.02 to camt.052.001.08 or camt.053.001.08, simply send us an informal email.
Our recommendation:
- Start using the camt.053 und camt.052 formats now
- Plan well in advance for a full transition to the current ISO 20022 formats
Structured addresses
Structured addresses consist of clearly defined and formatted information. Each component of a postal address has a dedicated sub-element (e.g. street, house number and postal code). In comparison, unstructured address data is less clearly defined and uses the unstructured XML element “address line” (<AdrLine>), in which various components of an address are entered.
In contrast to the old ISO version, new formats require the transmission of address data in a structured form. When entering addresses, the address data must be entered in the 14 predefined fields of ISO 20022. The data may not be interchanged. The use of the unstructured XML element “address line” is not permitted for structured addresses.
For structured addresses, “city” and “country” are also mandatory fields.
Example: structured address vs. unstructured address
The hybrid address display (or semi-structured address display) contains both structured and unstructured data.
This means that in addition to the mandatory information “city” and “country,” additional information may be entered in the open text lines (<AdrLine>).
It is possible to use structured ISO 20022 address elements in combination with an unstructured “address line” consisting of up to two lines of up to 70 characters each.
Elements present in the structured format must be entered in the respective structured ISO 20022 element. It is important here that at least “city” and “country” are entered in the respective structured element. The predefined fields (structured elements) must be completed for hybrid addresses. Information that has already been
entered as a structured element may not be entered again in the “address line”.
Example: hybrid / semi-structured address
This type of formatting makes it possible to provide address information more flexibly. Due to the predefined structure, however, automated processing is still possible. Hybrid addresses make it possible to supply information in a format that can be read both by humans and in part by machines.
Starting November 16, 2026, unstructured addresses will no longer be supported. If an unstructured address is used, payment orders will be rejected. If an address is required for payment processing, addresses must be specified in a (semi-)structured format starting in November 2026.
Updating your master data:
To ensure you can use structured addresses in future, it is important that the relevant address data for your payment partners is stored in your master data. High-quality, structured master data is essential to ensure that payments continue to be processed successfully (for example, the post code and city must be stored in separate data fields).
System and data adjustments:
Early preparation helps prevent operational disruptions and ensure compliance with regulations:
- Check the formats currently used in your software
- Contact your software provider to activate DK version 3.7+
- Plan internal testing (IT/accounting) to ensure a smooth migration
- Ensure that only valid formats are submitted from 16 November 2026 onwards
Please feel free to contact our payment transaction experts:
Our guide provides a clear overview of all key information, background details, and requirements related to the ISO 20022 migration.