DTAZV will be phased out in November 2026 – here’s what Corporates and SAP Customers need to prepare for now

Overview: What Changes Are Coming by November 2026?

The SEPA schemes are updated annually in November. As part of this process, new formats come into effect, while existing formats are phased out or no longer supported.

Formally, these changes primarily affect interbank transactions. In practice, however, banks also face the challenge of ensuring that customer orders can be migrated to the new interbank formats as smoothly as possible and without major adjustments.

An example of this is the update in November 2025: The account statement formats in the SWIFT MT standard (MT940/942) were discontinued. Nevertheless, there are still institutions that provide their customers with MT940 statements—which points to existing interim solutions or delayed migrations.

The annual format changes are more than just a technical update—they are a stress test for processes, systems, and data flows. This blog post highlights the specific implications that result from this.

DK Format Matrix: An Overview of Valid and Deprecated Formats

The German Banking Association (DK) has published an up-to-date overview of valid and deprecated formats on EBICS.de. This so-called format matrix clearly shows which formats will continue to be supported and where action is required.

It serves as a central guide for banks to identify necessary adjustments early on and to prepare for the transition in their systems and customer processes in a targeted manner.

The following information has been provided:

The individual versions of Appendix 3 can also be viewed on EBICS.de, in the archive if necessary.

Hybrid Addresses Become Mandatory

By the end of 2026, banks will require structured or hybrid address information; unstructured addresses will no longer be supported in interbank payment transactions. During the transition phase, hybrid addresses have been permitted since November 2025; in the future, banks will require at least the mandatory structured components (city/country) combined with permissible unstructured lines.

Banks anticipate the greatest challenges with the requirement for structured addresses: This is because it is difficult to correctly extract structured data from unstructured information and then pass it on in a structured format.

The following overview compares unstructured, structured, and hybrid addresses using examples:

The structured address allows for significantly more fields:

• Dept
• SubDept
• StrtNm
• BldgNb
• BldgNm
• Flr
• PstBx
• Room
• PstCd
• TwnNm
• TwnLctnNm
• DstrctNm
• CtrySubDvsn
• Ctry

While TwnNm and Ctry are the minimum requirements when using the structured and hybrid addresses. The hybrid address allows the AdrLine field to appear twice.

However, in the latest Annex 3 of the EDI Agreement (Version 3.9 dated March 12, 2025), the use of the postal address is also subject to notes and, in some cases, conditions:

Impact on SAP Customers

Format trees (SAP CGI) are not plug-and-play

SAP provides pain.001.001.09 (CT) and pain.008.001.08 (DD) very good, but “fully developed” standard format trees. They are prepared for all eventualities, but are somewhat oversized for SEPA payments, for example. Practical experience shows that it is necessary to reduce them in some places. Therefore, we recommend streamlining the format trees on a bank- and country-specific basis (e.g., required/optional fields, address variations, fee codes).

OSS Notes & Functions

If the current CGI-V09/V08 format templates are missing from the SAP system, OSS notes must be imported. Important related functions are sometimes included in the same notes—therefore, it is always important to check the version and scope of functions.

ECC and S/4HANA are affected

The new formats can be set up in both ECC and S/4HANA systems—in both environments, adjustments to the format tree and payment method Customizing are still required.

Tests: Plan for Bottlenecks – Not All Banks Have Portals

Whether it’s EBICS test accounts or web portals: Not every bank provides convenient test environments. Validation often takes place via file submission and email feedback—which takes time. Due to the widespread migration wave, response times and calendar slots at banks are also in short supply. Be sure to plan for Puffers accordingly.

Project Roadmap: A 6-Step Guide to a Seamless Migration

1. Clarify the scope and banking landscape
   Which payment methods/formats are in use (SEPA, EUR Express/CCU, INST, AZV/AXZ, manual payments, HCM/FSCD/non-SAP)? Which banks/countries? Which GBIC profiles? Also consider your HR payments, which may be generated in other SAP systems.
2. Compile bank requirements and deadlines
   Bank specifications (including hybrid address) for each country/bank; set the test window; finalize the go-live date. In specific cases, additional bank requirements must be reviewed. Check with your primary bank regarding special cases, such as payments to the U.S. without a BIC code or payments to China or India.
3. Set up SAP Basis
   Import OSS notes for CGI V09/V08 (if necessary). Clone format trees and streamline them according to bank and country-specific requirements.
4. Update Payment Method Customizing
   Perform regression tests for SEPA Classic/Express/Instant.
5. Organize end-to-end tests
   Validate the bank test (either by emailing your trusted consultant or through a testing portal provided by the bank), test status reports (pain.002.001.10) – if available – and consider CAMT implications. Allow buffers for bank responses.
6. Cutover & Hypercare
   Phased go-lives by country/bank; pilot payments (non-urgent/small amounts). Monitoring of rejections (+ plan for quick format fixes, including resources for go-live). If necessary, plan a fallback scenario in case insurmountable discrepancies with bank requirements necessitate postponing the formats.

Common Pitfalls from Projects

• “Full configuration” of SAP format trees: Banks often do not accept the file without simplification (e.g., duplicate address entries or ChargeBearer on multiple levels).
• US payments without BIC: Fill in ABA/Local Clearing correctly; apply name/address requirements only if BIC is empty.
• Unclear testing responsibilities: Missing portals → Plan for manual loops; establish bank contacts early on
• Setting up instruction keys for the use of standard, instant, or EUR-Eilig payments is not intuitive.

Why start now?

• Other major initiatives (EBICS 3.0, Instant Payments, VoP, MT→camt, or even an S4 migration) are competing for the same experts and bank testing slots. The later you start, the greater the risk of rejections and payment delays.
• On the banks’ side, patience is running out: Several institutions have indicated that they will no longer accept DTAZV after the deadline. Hybrid addresses and V2019 formats are required.

Conclusion

November 2026 is not a theoretical deadline, but the firm migration deadline: DTAZV will be phased out, and ISO 20022 V2019 will become mandatory—including the option for hybrid addresses and updated PAIN versions. Those who start now will be in control: less risk, thorough testing, and stable go-lives.

If you consider a timely transition to be critical, check with your bank early on to see if, and if so, for how long the legacy formats can still be supported.