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.
UPDATE 09.09.2026: Neue Zeitpläne für November 2026
Seit Veröffentlichung dieses Beitrags hat sich der Zeitplan für die für November 2026 geplanten ISO-20022-Änderungen wesentlich verändert. SWIFT, EPC und das Eurosystem haben ihre ursprünglichen Planungen angepasst – während der Schweizer Finanzplatz nach aktuellem Stand am bestehenden Termin festhält.
Damit zeigt sich noch deutlicher: Es gibt keinen einheitlichen ISO-20022-Stichtag für alle Märkte und Zahlungsverkehrsverfahren.
SWIFT verschiebt Standards Release 2026
SWIFT hat auf die weltweit unterschiedliche Readiness der Marktteilnehmer reagiert und die ursprünglich für Mitte November 2026 vorgesehenen Änderungen im Zahlungsverkehr zunächst verschoben.
Davon betroffen ist insbesondere der bisher für November vorgesehene verpflichtende Wegfall vollständig unstrukturierter Adressdaten. Ein neuer verbindlicher Termin steht derzeit noch nicht fest. SWIFT will die weitere Vorgehensweise mit Banken, Zentralbanken, Marktinfrastrukturen und Unternehmen abstimmen und einen aktualisierten Fahrplan kommunizieren.
Wichtig dabei: Die Verschiebung bedeutet nicht, dass die Umstellung auf strukturierte bzw. hybride Adressen gestoppt werden sollte. Die bereits begonnenen Migrationen behalten ihre Relevanz und sollten weitergeführt werden.
EPC verschiebt SEPA-Deadline für unstrukturierte Adressen
Das Payment Scheme Management Board (PSMB) des EPC hat in seiner Sitzung am 9. September 2026 beschlossen, die ursprünglich für den 15. November 2026 vorgesehene Deadline für die Verwendung unstrukturierter Adressen in den SEPA-Zahlungsverfahren zu verschieben.
Damit können vollständig unstrukturierte Adressen auch über den 15. November 2026 hinaus verwendet werden. Ein neues verbindliches Enddatum wurde bislang noch nicht festgelegt. Über den weiteren Zeitplan soll im Oktober 2026 entschieden werden. Die Entscheidung ist insbesondere vor dem Hintergrund der zuvor kommunizierten SWIFT-Verschiebung vom 27. August 2026 zu sehen und soll eine bessere Abstimmung der unterschiedlichen Migrationszeitpläne ermöglichen.
Auch der EPC stellt jedoch ausdrücklich klar, dass die Verschiebung nicht als Anlass verstanden werden sollte, laufende Migrationsprojekte zu stoppen. Zahlungsdienstleister und Unternehmen sollen ihre Vorbereitungen fortsetzen und möglichst auf vollständig strukturierte Adressdaten umstellen.
Für SEPA bedeutet dies somit:
- Die bisherige Deadline 15. November 2026 für unstrukturierte Adressen ist nicht mehr verbindlich.
- Ein neues Enddatum steht derzeit noch nicht fest.
- Eine Entscheidung über den neuen Zeitplan wird im Oktober 2026 erwartet.
- Laufende Umstellungen auf strukturierte bzw. hybride Adressdaten sollten unverändert fortgeführt werden.
Damit folgt nun auch SEPA grundsätzlich der internationalen Entwicklung – allerdings wiederum mit einem eigenen Entscheidungs- und Zeitplan.
Eurosystem verschiebt TARGET-Release auf 28. November 2026
Das Eurosystem hält an den geplanten November-Releases für T2, T2S, TIPS und ECMS fest, verschiebt deren produktive Einführung jedoch um zwei Wochen:
14. November 2026 → 28. November 2026
Teilnehmer, die über ISO-20022-basierte A2A-Kommunikation an die TARGET Services angebunden sind, sollen ihre Vorbereitungen unverändert fortsetzen. Der Start der entsprechenden User Tests ist weiterhin für den 9. Oktober 2026 vorgesehen.
Als temporäre Übergangsmaßnahme wird T2 vollständig unstrukturierte Adressen in RTGS-Nachrichten noch für einen begrenzten Zeitraum akzeptieren. Gleichzeitig erwartet das Eurosystem ausdrücklich, dass die Marktteilnehmer die Einführung strukturierter bzw. hybrider Adressen weiter vorantreiben.
Schweiz hält am 14. November 2026 fest
Anders stellt sich die Situation derzeit für den Schweizer Zahlungsverkehr dar. Der Schweizer Finanzplatz hält nach aktuellem Stand an seinem bestehenden Zeitplan fest.
Die Swiss Payment Standards 2026 (SPS 2026) werden am 14. November 2026 gültig. Gleichzeitig endet die verlängerte Parallelphase für ältere ISO-20022-Meldungsversionen.
Besonders relevant sind dabei:
- pain.001.001.09 für Zahlungsaufträge
- camt.05x.001.08 für elektronische Kontoinformationen
- strukturierte bzw. hybride Adressdaten für alle Zahlungsarten
Die bisher weiterhin unterstützten Versionen pain.001.001.03, pain.002.001.03 sowie sinngemäß camt.05x.001.04 befinden sich damit am Ende ihrer verlängerten Übergangsphase.
Besonders wichtig für die Adressdaten: Bei Verwendung einer unstrukturierten Adresse muss das gewünschte Ausführungsdatum vor dem 14. November 2026 liegen. Ab November 2026 wird die Verwendung strukturierter bzw. hybrider Adressen für alle Parteien und Zahlungsarten verpflichtend.
Für Unternehmen mit Schweizer Bankverbindungen ergibt sich aus der SWIFT-Verschiebung daher nach aktuellem Stand kein entsprechender Aufschub.
Was bedeutet das für SAP-Anwender?
Die unterschiedlichen Zeitpläne von SWIFT, TARGET, dem Schweizer Finanzplatz und den jeweiligen Banken erhöhen kurzfristig sogar die Komplexität der Migration.
Eine generelle Verschiebung der ISO-20022-Umstellung auf 2027 lässt sich daraus nicht ableiten.
Unsere Empfehlung bleibt deshalb unverändert:
Bereits laufende Umstellungen auf pain.001.001.09, pain.008.001.08, camt.05x.001.08 sowie strukturierte bzw. hybride Adressdaten sollten nicht gestoppt oder verschoben werden.
Unternehmen sollten vielmehr mit ihren jeweiligen Hausbanken abstimmen, welche Formate ab welchem Termin angenommen bzw. bereitgestellt werden. Dies gilt insbesondere bei international aufgestellten Unternehmen, da sich die konkreten Vorgaben zwischen Ländern, Marktinfrastrukturen und Banken inzwischen deutlich unterscheiden.
Die aktuelle Entwicklung bestätigt damit umso mehr unsere ursprüngliche Einschätzung:
Der Standard ist harmonisiert. Die Migration dorthin ist es nicht.
UPDATE 20.08.2026
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.