Strukturierte Adressdaten, neue pain-Versionen, CAMT V8 und teilweise auch neue EBICS-Anforderungen: Der November 2026 entwickelt sich für viele Unternehmen zu einem der anspruchsvollsten Termine im Zahlungsverkehr der vergangenen Jahre.
Die regulatorischen und technischen Zielbilder sind eigentlich klar definiert. Die praktische Umsetzung bei Banken und Unternehmen zeigt jedoch ein wesentlich heterogeneres Bild.
Während einige Banken ihre Kunden bereits konsequent auf die neuen ISO-20022-Formate umstellen, unterstützen andere Institute weiterhin Übergangsformate oder liefern Kontoinformationen noch in Formaten aus, die gemäß dem offiziellen Format-Lifecycle längst nicht mehr dem aktuellen DK-Standard entsprechen.
Für Unternehmen bedeutet das: Ein einheitlicher Migrationsplan über alle Banken hinweg ist häufig kaum möglich.
15. November 2026 wird zum nächsten entscheidenden Stichtag
Die Deutsche Kreditwirtschaft hat die ab 15. November 2026 gültige Version 26.11 der Anlage 3 des DFÜ-Abkommens bereits veröffentlicht. Sie weist ausdrücklich darauf hin, dass Kundenaufträge im SEPA-, Individual- und Auslandszahlungsverkehr in älteren Formaten auf Basis der ISO-Version 2009 ab diesem Zeitpunkt nicht mehr ohne Weiteres weitergeleitet werden können.
Damit rücken unter anderem die aktuellen ISO-20022-Formate wie
pain.001.001.09 für Überweisungen undpain.008.001.08 für Lastschriften
endgültig in den Mittelpunkt.
Besonders relevant ist dabei ein Detail, das auf den ersten Blick unspektakulär klingt: Adressdaten.
Adressdaten: Aus einem Stammdatenthema wird ein Zahlungsverkehrsthema
SWIFT hat für November 2026 einen weiteren zentralen ISO-20022-Meilenstein angekündigt: Rein unstrukturierte Postadressen werden im grenzüberschreitenden Zahlungsverkehr nicht mehr unterstützt.
Sofern Adressinformationen übermittelt werden, müssen die relevanten Informationen strukturiert beziehungsweise hybrid bereitgestellt werden. Als zentrale Mindestinformationen spielen dabei insbesondere Town Name (TwnNm) und Country (Ctry) eine Rolle. SWIFT begründet diese Entwicklung unter anderem mit höherer Datenqualität, besserem Compliance Screening und einem höheren Automatisierungsgrad im Zahlungsverkehr.
Die Deutsche Kreditwirtschaft weist in ihrer aktuellen Kommunikation ebenfalls ausdrücklich auf die strukturierte Adresse mit mindestens Stadt und Land als wesentliche Voraussetzung für die Weiterleitung von Zahlungsaufträgen ab November 2026 hin.
Damit wird aus einem vermeintlichen Formatprojekt sehr schnell auch ein Stammdatenprojekt.
In SAP bedeutet dies beispielsweise, dass geprüft werden muss, aus welchen Stammdaten Debitoren-, Kreditoren-, Mitarbeiter- und gegebenenfalls abweichende Zahlungsempfängeradressen in die Zahlungsdatei übernommen werden.
Besonders unangenehm: Unvollständig vorhandene Adressinformationen können zur Zurückweisung einer Zahlungsdatei führen.
Und was ist eigentlich mit MT940?
Hier lohnt sich ein genauer Blick auf den Format-Lifecycle.
Nach Vorgabe der Deutschen Kreditwirtschaft sind MT940 und MT942 bereits seit dem 23. November 2025 kein DK-Standard mehr. Gleichzeitig wurde auch die ISO-Version 02 von camt.052, camt.053 und camt.054 aus dem Lifecycle genommen.
Der von der DK vorgesehene Standard für elektronische Kontoinformationen ist damit bereits heute die ISO-Version V08, unter anderem:
camt.052.001.08camt.053.001.08camt.054.001.08
Die DK bezeichnet camt.052/camt.053 in ISO V08 ausdrücklich als den nach DFÜ-Abkommen verpflichtend anzubietenden Standard für elektronische Kontoinformationen.
Die Realität sieht allerdings teilweise anders aus.
Auch 2026 sehen wir in Projekten weiterhin Banken, die MT940 bereitstellen, während andere Institute bereits ausschließlich beziehungsweise bevorzugt CAMT V8 einsetzen. Noch komplexer wird es dort, wo heute bereits CAMT verwendet wird, jedoch eine ältere CAMT-Version im Einsatz ist. Dann besteht die Migration nicht aus einem einfachen Wechsel von MT940 auf CAMT, sondern beispielsweise aus:
MT940 → CAMT.053 V8
oder
CAMT.053 Altversion → CAMT.053.001.08
Und damit ändern sich nicht nur XML-Namespace und Schema. Auch Mapping, Bank Transaction Codes, Referenzen, Pagination und die SAP-seitige Verarbeitung müssen geprüft werden.
Ein Standard – aber leider kein einheitlicher Migrationsweg
Genau hier liegt aus unserer Sicht derzeit die größte Herausforderung.
Auf dem Papier gibt es einen klaren ISO-20022- und DK-Lifecycle. In unseren Projekten erleben wir auf Bankseite jedoch sehr unterschiedliche Migrationsstrategien.
Einige Banken akzeptieren ältere pain.001-Versionen nur noch für eine begrenzte Übergangszeit. Andere stellen ihre Kunden bereits frühzeitig auf pain.001.001.09 um. Wieder andere haben noch keine endgültigen Abschalttermine für bestimmte Vorgängerformate kommuniziert.
Auch bei CAMT zeigt sich ein vergleichbares Bild: Manche Banken stellen V8 bereits produktiv bereit, bei anderen fehlen noch vollständig nutzbare Testmöglichkeiten oder verbindliche Termine für die Abschaltung älterer Formate.
Die DK selbst macht deutlich, dass die Unterstützung der Formate einem definierten Lifecycle folgt. Für Auslandszahlungen ist beispielsweise der Wechsel auf pain.001 spätestens bis November 2026 sicherzustellen.
Testen – sofern eine Testmöglichkeit vorhanden ist
Eine besondere Herausforderung sehen wir derzeit bei den Testmöglichkeiten. Theoretisch sollten Unternehmen ihre neuen Formate frühzeitig implementieren, mit jeder Bank testen und erst anschließend produktiv umstellen. Praktisch stehen entsprechende Testzugänge jedoch nicht bei allen Banken rechtzeitig oder im erforderlichen Umfang zur Verfügung. Das führt zu einer problematischen Situation:
Die Deadline ist bekannt.
Die SAP-Anpassungen können vorbereitet werden.
Das neue Format kann technisch erzeugt werden.
Eine vollständige End-to-End-Verifikation mit der Bank ist aber teilweise erst sehr spät möglich.
SWIFT fordert Unternehmen deshalb ausdrücklich dazu auf, frühzeitig mit ihren Banken zu klären, welche Anforderungen gelten und welche Onboarding- und Testmöglichkeiten zur Verfügung stehen.
Und dann kommt noch EBICS hinzu
Auch die Übertragungsebene darf bei der Migration nicht vergessen werden. EBICS 2.5 und EBICS 3.0 existieren weiterhin nebeneinander. EBICS 3.0 verwendet das Business Transaction Format – BTF, während für EBICS 2.x klassische Auftragsarten verwendet werden. Die Deutsche Kreditwirtschaft veröffentlicht dafür sogar ein Mapping zwischen BTF-Parametern und den bisherigen EBICS-Auftragsarten.
In unseren Projekten erleben wir zunehmend bankindividuelle Abhängigkeiten zwischen Format, EBICS-Version und angebotener Auftragsart beziehungsweise BTF-Konfiguration.Damit kann aus einer vermeintlichen Formatumstellung plötzlich ein größeres Projekt werden:
ISO-20022-Format + SAP-Anpassung + Bankkonfiguration + EBICS-Migration + Berechtigungen + End-to-End-Test.
Genau diese Abhängigkeiten sollten Unternehmen frühzeitig mit ihren Banken klären.
November 2026 kommt schneller als gedacht
Wir erhalten mittlerweile nahezu täglich Anfragen von Unternehmen zu neuen pain-Versionen, strukturierten Adressdaten, CAMT V8, MT940-Ablösung oder den damit verbundenen EBICS-Anpassungen. Unsere Empfehlung ist daher eindeutig: Nicht bis Oktober oder November 2026 warten.
Unternehmen sollten jetzt ihre komplette Zahlungsverkehrslandschaft betrachten:
Welche Banken verwenden wir? Welche pain.001– und pain.008-Versionen werden heute erzeugt? Wo werden noch unstrukturierte Adressen verwendet? Welche CAMT-Versionen liefern unsere Banken? Wo erhalten wir noch MT940? Welche EBICS-Version ist im Einsatz? Welche Bank kann die neuen Formate bereits testen? Und welche Anpassungen sind in SAP tatsächlich erforderlich?
Denn eines zeichnet sich bereits heute ab:
Der Standard ist harmonisiert. Die Migration dorthin ist es nicht.
Und genau deshalb dürfte der November 2026 für viele Payment- und Treasury-Teams ein ausgesprochen spannender Monat werden.
payments.cc unterstützt Unternehmen bei der Analyse, Konzeption, SAP-Implementierung und beim End-to-End-Test der neuen ISO-20022-Formate – von pain.001 und pain.008 über CAMT.053 bis hin zu EBICS 3.0.