Neue Zahlungsformate im Überblick: Pain.001 & Pain.008

pain.001.001.09: Was sich zum 15. November 2026 ändert

Am 15. November 2026 tritt Version 26.11 der Anlage 3 des DFÜ-Abkommens in Kraft. Ab diesem Zeitpunkt können deutsche Banken Zahlungsaufträge in alten Formaten nicht mehr ohne Weiteres verarbeiten. Betroffen sind Formate, die noch auf der ISO-Version von 2009 basieren.

Für SEPA-Überweisungen ist das neue Zielformat pain.001.001.09. Für SEPA-Lastschriften gilt pain.008.001.08. Das bisherige DTAZV-Format für Auslandszahlungen entfällt vollständig. Wer heute noch pain.001.001.03 erzeugt, hat nur noch elf Wochen Zeit.

Was pain.001.001.09 ist und wer den Termin festgelegt hat

pain.001 ist eine XML-Nachricht für Überweisungen. Unternehmen reichen damit Zahlungsaufträge bei ihrer Bank ein, zum Beispiel per EBICS aus einem ERP-System oder durch einen Datei-Upload im Online-Banking. Die letzten drei Ziffern zeigen die jeweilige Version: pain.001.001.03 basiert auf der ISO-20022-Version von 2009, pain.001.001.09 auf der Version von 2019.

Den Termin für Deutschland hat die Deutsche Kreditwirtschaft, kurz DK, festgelegt. International wird sie auch German Banking Industry Committee, kurz GBIC, genannt. Die DK definiert in Anlage 3 des DFÜ-Abkommens die Regeln für die Kommunikation zwischen Unternehmen und Banken. Über den sogenannten Format-Lifecycle legt sie außerdem fest, wie lange bestimmte Formatversionen unterstützt werden.

Ab 2026 ändert sich auch die Nummerierung dieser Versionen. Sie richtet sich jetzt nach Jahr und Monat des Inkrafttretens. Deshalb heißt die neue Version 26.11 und ersetzt die bisherige Version 3.9. Der eigentliche Grund für die Umstellung liegt allerdings nicht nur in Deutschland. Die DK setzt damit internationale und europäische Vorgaben für den deutschen Zahlungsverkehr um.

Drei Termine in einer Woche und drei verschiedene Absender

Der 15. November 2026 ist das deutsche Ende einer längeren Kette von Änderungen. Dahinter stehen Vorgaben auf weltweiter, europäischer und deutscher Ebene.

Weltweit gilt für SWIFT CBPR+ der 14. November 2026. Mit dem Standards Release 2026 erlaubt das SWIFT-Netz in CBPR+-Zahlungsnachrichten keine vollständig unstrukturierten Postanschriften mehr. Ort und Land müssen in eigenen Feldern stehen. Nachrichten, die diese Vorgabe nicht erfüllen, können abgewiesen werden. Die Vorgabe kommt von der Payments Market Practice Group und damit aus der internationalen Zahlungsverkehrs-Community.

Auf europäischer Ebene folgt der European Payments Council am 15. November 2026. Die Leitlinie EPC153-22 schreibt vor, dass SEPA-Überweisungen und SEPA-Lastschriften ab diesem Datum keine vollständig unstrukturierten Adressen von Zahler oder Zahlungsempfänger mehr enthalten dürfen. Das gilt auch für rein deutsche Euro-Zahlungen.

In Deutschland setzt die Deutsche Kreditwirtschaft diese Vorgaben ebenfalls zum 15. November 2026 in konkrete Regeln für die Kunde-Bank-Kommunikation und EBICS um. Gleichzeitig nimmt sie die alten Formate aus ihrem Standard. Der Hintergrund ist einfach: Banken müssen ihre Zahlungen untereinander in den neuen Formaten austauschen. Deshalb müssen auch die Zahlungsdateien ihrer Firmenkunden dazu passen.

Diese Reihenfolge ist wichtig. Der Termin ist keine rein deutsche Entscheidung, die einzelne Banken einfach verschieben können.

Welche Formate betroffen sind

Bei der SEPA-Überweisung wird pain.001.001.03 durch pain.001.001.09 ersetzt. Bei der SEPA-Lastschrift wechselt das Format von pain.008.001.02 auf pain.008.001.08. Die Lastschrift ist dabei oft der schwierigere Fall, weil die notwendigen Adressdaten häufig aus Kunden- und Mandatsdaten stammen. Diese Daten sind in vielen Unternehmen weniger gut gepflegt als beispielsweise Lieferantenstammdaten.

Auch die Statusrückmeldung ändert sich. pain.002.001.03 wird durch pain.002.001.10 ersetzt. Diese Umstellung sollte nicht übersehen werden, denn ohne passende Statusrückmeldung kann ein Unternehmen möglicherweise nicht mehr zuverlässig erkennen, was mit einer eingereichten Zahlungsdatei passiert ist.

Bei Auslandszahlungen entfällt das DTAZV-Format vollständig. Künftig werden diese Zahlungen ebenfalls mit pain.001.001.09 eingereicht. Unter EBICS wird dafür die Auftragsart AXZ verwendet, die die bisherige AZV-Auftragsart ersetzt.

Bei den Kontoinformationen liegt die Umstellung bereits hinter uns. MT940 und MT942 gehören seit dem 23. November 2025 nicht mehr zum DK-Standard. Der verbleibende Standard sind camt.052 und camt.053 in der ISO-Version 08.

Auch die Einreichung über MT101 läuft aus. Hier unterscheiden sich die Banken allerdings deutlich voneinander. Einzelne Institute unterstützen MT101 noch bis November 2027.

Zusätzlich gibt es einige technische Detailänderungen, die besonders bei selbst entwickelten Schnittstellen Arbeit verursachen. Das Feld BIC heißt künftig BICFI, aus BICorBEI wird AnyBIC. Auch die Struktur des Ausführungsdatums ReqdExctnDt ändert sich, weil das Element jetzt je nach Verwendung ein Datum oder einen Zeitstempel enthalten kann.

Die Adressregel verursacht den größten Aufwand

Der Wechsel auf eine neue XML-Version ist vor allem Mapping-Arbeit. Deutlich schwieriger kann eine andere Vorgabe werden: die neue Adressstruktur. Wenn eine Postanschrift mitgegeben wird, muss sie künftig strukturiert oder hybrid aufgebaut sein. Ort und Land müssen in eigenen XML-Feldern stehen und dürfen nicht nur Teil einer freien Adresszeile sein.

Bei einer strukturierten Adresse stehen Straße, Hausnummer, Postleitzahl, Ort und Land jeweils in eigenen Feldern. Bei einer hybriden Adresse dürfen freie Adresszeilen teilweise erhalten bleiben, Ort und Land müssen aber zusätzlich in den dafür vorgesehenen Feldern stehen. Bei einer unstrukturierten Adresse steht dagegen die komplette Anschrift nur als Freitext in Adresszeilen. Genau diese Variante wird nach dem Stichtag problematisch und kann abgewiesen werden.

Dabei gibt es eine wichtige Ausnahme: Die Regel gilt nur, wenn überhaupt eine Postanschrift mitgegeben wird. Bei vielen SEPA-Zahlungen innerhalb des Europäischen Wirtschaftsraums ist eine Empfängeradresse nicht verpflichtend. Unternehmen sollten deshalb prüfen, warum ihre Systeme heute überhaupt Adressen mitsenden. In manchen Fällen lässt sich das Problem bereits lösen, indem nicht benötigte Adressdaten aus der Zahlungsdatei entfernt werden.

Bei Auslandszahlungen ist die Situation anders. Dort sind Ort und Land des Zahlungsempfängers im deutschen EBICS-Standard bereits heute verpflichtend.

Warum diese Adressregel in der Praxis trotzdem schwierig ist, welche Länder besonders häufig Probleme verursachen und warum eine erfolgreiche Schemaprüfung noch keine Annahme durch die Bank garantiert, steht im Detailbeitrag zur strukturierten Adresse.

[LINK-POST-STRUKTURIERTE-ADRESSE]

Der Stichtag richtet sich nach dem Ausführungsdatum

Dieser Punkt wird in vielen Bankinformationen nur kurz erwähnt, ist aber besonders wichtig. Entscheidend ist nicht nur, wann ein Auftrag bei der Bank eingereicht wird. Auch Aufträge, die vor dem 15. November eingereicht wurden, können betroffen sein, wenn ihr Ausführungs- oder Fälligkeitsdatum auf den 15. November 2026 oder später fällt.

Das Gleiche gilt für Aufträge, die zu diesem Zeitpunkt noch nicht vollständig freigegeben sind. Dazu gehören zum Beispiel Zahlungen, die in der VEU noch auf eine zweite Unterschrift warten. Der tatsächliche Umstellungstermin kann deshalb für ein Unternehmen deutlich vor dem 15. November liegen.

Wer Terminüberweisungen mit 14 Tagen Vorlauf einreicht, muss möglicherweise schon Anfang November mit den neuen Formaten arbeiten. Bei Lastschriften muss vom Fälligkeitsdatum zurückgerechnet werden. Auch offene Freigaben sollten berücksichtigt werden. Unternehmen mit mehreren Freigabestufen sollten ihre offenen VEU-Mappen vor dem Stichtag gezielt prüfen und möglichst leeren.

Daraus ergeben sich drei wichtige Fragen: Welche Terminaufträge liegen am 10. November bereits bei den Banken und haben ein Ausführungsdatum ab dem 15. November? Wer prüft und leert offene Freigabemappen? Und wer kontrolliert in dieser Zeit tatsächlich die Statusrückmeldungen der Banken?

Warum Banken trotzdem unterschiedliche Termine nennen

Wenn der 15. November feststeht, stellt sich eine naheliegende Frage: Warum nennt dann nicht jede Bank denselben Umstellungstermin? Der Grund liegt im Format-Lifecycle der Deutschen Kreditwirtschaft. Das Ende einer Formatversion wird dort teilweise nur auf Monatsebene angegeben. Den genauen technischen Abschalttermin legt dann der jeweilige Zahlungsdienstleister oder die jeweilige Bank fest.

Deshalb gibt es in der Praxis unterschiedliche Termine. Ein Rechenzentrum kann alte Formate bereits ab dem 14. November ablehnen. Eine andere Bank empfiehlt ihren Kunden, die Umstellung spätestens am 11. November abzuschließen. Andere Institute nennen nur den Monat November. Zusätzlich können einzelne Banken alte Versionen auf Basis individueller Vereinbarungen länger unterstützen, andere nicht.

Für ein Unternehmen mit nur einer Bankverbindung lässt sich das relativ einfach klären. Bei sieben Banken wird daraus schnell ein eigenes Projekt. In der Praxis bestimmt meistens der früheste Termin im Bankenkreis den Zeitplan für die gesamte Migration. Auch die Testmöglichkeiten unterscheiden sich von Bank zu Bank, weshalb ein einheitlicher Migrationsplan über alle Bankverbindungen hinweg nicht immer möglich ist.

Der Termin ist also verbindlich. Die konkrete technische Abschaltung kann sich trotzdem je Bank unterscheiden. Unternehmen sollten deshalb mit dem frühesten bestätigten Termin planen.

Was Unternehmen jetzt klären sollten

Für die weitere Planung sind vor allem fünf Fragen wichtig: Welche Formatversion erzeugt jedes System heute für jede Bank und jede Zahlungsart? Bis zu welchem konkreten Datum akzeptiert jede Bank die alten Formate? Welche Schema-Variante erwartet die jeweilige Bank? Wo senden die eigenen Systeme heute Adressen mit, obwohl sie für die jeweilige Zahlung gar nicht erforderlich sind? Und wer kontrolliert die Statusrückmeldungen, wenn eine Datei im November vollständig oder teilweise abgewiesen wird?

Gerade die Frage nach der Schema-Variante ist wichtig. Für die ISO-Version von 2019 gibt es unter anderem die Varianten GBIC_4 und GBIC_5. Nur GBIC_5 unterstützt hybride Adressen. Deshalb reicht es nicht, lediglich zu wissen, dass eine Bank pain.001.001.09 erwartet. Entscheidend ist auch, in welcher konkreten Ausprägung.

Im Banking Connector prüft der Format-Checker Zahlungsdateien bereits vor der Übergabe an die Bank. Dabei berücksichtigt er unter anderem die erwartete Formatversion und die notwendigen Adressregeln für die jeweilige Bankverbindung.

Kein reines Formatprojekt, sondern ein Datenprojekt mit Frist

pain.001.001.09 bringt einen neuen Namespace, einige umbenannte Felder und eine geänderte Datumsstruktur. Technisch ist das grundsätzlich überschaubar. Wer eine gepflegte Standardsoftware verwendet, wird viele dieser Änderungen über ein Software-Update erhalten.

Was kein Software-Update automatisch korrigiert, sind die Stammdaten. In vielen Kunden- und Lieferantenstämmen wurden Adressen über Jahre oder Jahrzehnte als Freitext gepflegt. Genau diese Daten können jetzt zum Problem werden.

Ab dem 15. November 2026 kann schlechte Adressqualität dazu führen, dass eine Zahlung nicht mehr verarbeitet wird. Die Frist kommt aus dem Zahlungsformat. Die eigentliche Arbeit liegt in den Daten.