Am 15. November 2026 werden SEPA-Dateien abgelehnt. So bist du bereit.
Am 15. November 2026 akzeptiert der EPC keine unstrukturierten Adressen mehr in SEPA-Zahlungsdateien. Wenn du pain.001- oder pain.008-XML erzeugst: Das ändert sich, und es gibt eine getestete, typsichere TypeScript-Bibliothek, die das neue Format schon heute trifft.
Im SEPA-Regelwerk steht ein Datum, von dem der meiste Anwendungscode noch nie gehört hat.
Am 15. November 2026 nehmen der European Payments Council und SWIFT keine vollständig unstrukturierten Postadressen mehr in Zahlungsnachrichten an. Nach diesem Wochenende ist eine Zahlungsdatei, die die Adresse des Schuldners in Freitextzeilen quetscht, nicht mehr „unerwünscht” oder „veraltet”. Sie wird abgelehnt, mit Gebühren belegt oder scheitert still in der automatisierten Verarbeitung (STP) bei der Bank. Die Adresse muss strukturiert sein: getrennte Felder für Ort, Postleitzahl und Land.
Das Datum hat sich übrigens verschoben. Früher war es der 22. November. Der EPC hat es um eine Woche vorgezogen, damit es mit dem Wochenende des SWIFT-Standards-MX-Release zusammenfällt. Wer sich auf das alte Datum verlassen hat, hat jetzt eine Woche weniger als geplant.
Wenn dein System SEPA-Dateien schreibt, ist das eine Formatmigration mit hartem Stichtag. Und ich vermute, die meisten Teams merken das erst in der Woche, in der eine Bank einen ganzen Stapel ablehnt.
Was sich konkret ändert
Zwei Dinge, und sie gehören zusammen.
Die Nachrichtenversionen. SEPA wechselt auf den ISO-20022-Nachrichtensatz von 2019. Für die Formate, die die meisten Anwendungen betreffen, heißt das: pain.001.001.09 für Überweisungen und pain.008.001.08 für Lastschriften. Die älteren Versionen, die du heute vielleicht noch erzeugst, sind auf dem Weg nach draußen.
Die Adresse. Das ist der Teil mit den Zähnen. Die modernen Nachrichten tragen einen strukturierten PstlAdr-Block. Die unstrukturierte Variante, bei der du einen Namen und zwei Adresszeilen hineinkippst und hoffst, wird am 15. November 2026 verboten. Viele Banken lehnen sie schon vor dem Stichtag ab.
Die Arbeit ist also nicht kosmetisch. Du änderst das Schema, das du erzeugst, und du änderst, wie eines der fehleranfälligsten Felder im ganzen Dokument aufgebaut ist. Unter Zeitdruck. Gegen eine Bank, die dir nicht sagt, was falsch ist. Sie sagt einfach nein.
Warum Selberbauen die Falle ist
Ich kenne den Reflex, weil ich ihn selbst hatte. SEPA-XML sieht aus wie „nur XML”. Du öffnest die Spezifikation, siehst spitze Klammern und denkst, du templatest dich an einem Nachmittag da durch.
Dann triffst du auf die Details. IBAN-Prüfziffern (mod 97). Der EPC-Zeichensatz, der schmaler ist als UTF-8 und Dateien still beschädigt, sobald du einen Namen mit Umlaut durchlässt. Die Kontrollsumme, die exakt der Ganzzahl-Summe jeder einzelnen Transaktion entsprechen muss, ohne einen einzigen Fließkomma-Rundungsfehler. Identifier-Regeln, die einen führenden oder abschließenden Schrägstrich verbieten. Betragsobergrenzen pro Transaktion. Und jetzt ein strukturierter Adresstyp mit Regeln je Variante, bei dem die deutschen DK-Schemata nur eine Teilmenge akzeptieren und den Rest ablehnen.
Hier ist die Tatsache, die diese Domäne von den meisten unterscheidet: Eine subtil falsche Zahlungsdatei ist schlimmer als gar keine. Eine Datei, die laut scheitert, kostet dich einen Nachmittag. Eine Datei, die deine Tests besteht, die erste Prüfung der Bank besteht und dann Geld an die falsche Stelle überweist oder eine Lastschrift doppelt einzieht, kostet dich etwas, das du nicht so leicht zurückholst.
Das ist ein schlechter Ort, um unter Zeitdruck zu improvisieren.
Also habe ich die Bibliothek gebaut, die ich wollte
Sie heißt sepa-xml-ts. Eine TypeScript-Bibliothek, die ISO-20022-SEPA-Dateien parst, schreibt und validiert, hinter einem typisierten Modell, das das XML verbirgt. Sie steht unter MIT-Lizenz, liegt auf npm und ist seit heute bei 1.0. Die Doku, mit jedem Feld und jeder Variante, liegt unter sepa.codewithagents.de.
Die Leitregel ist die von oben: Korrektheit ist kein Feature, sie ist das ganze Produkt. Also wird sie erzwungen, nicht erhofft.
Jede Datei, die die Bibliothek erzeugt, wird gegen das offizielle EPC-/ISO-20022-XSD validiert, in der CI, bei jedem Commit. Nicht gegen meine Vorstellung vom Schema. Gegen das echte. Dass ich dieser Aussage traue, liegt an einem Property-Test: irgendein gültiges Modell erzeugen, es nach XML schreiben und prüfen, dass die Ausgabe gegen das tatsächliche XSD validiert. Zweihundert zufällige Modelle pro Lauf für Überweisungen, zweihundert weitere für Lastschriften, dazu jeweils zweihundert Round-Trip-Prüfungen (Modell zu XML zu Parsen, deep-equal zurück zum Original). Diese Suite ist der Grund, warum ich bei der Gültigkeit der Ausgabe ruhig schlafe, und sie ist der Grund, warum die Testzahl bei 671 bestandenen liegt und nicht bei einem Dutzend Happy-Path-Beispielen.
Dieser Test-Oracle hat sich schon bewährt. Ein Referenzfeld im strukturierten Verwendungszweck ist im XSD als Enum typisiert, nicht als Freitext. Ein plausibel aussehendes String-Modell hätte eine Datei erzeugt, die das Schema der Bank ablehnt. Kein noch so gründliches Lesen der Spezifikation hätte das gefangen. Der Property-Test scheiterte in den ersten paar Läufen, reichte mir das exakte Gegenbeispiel, und der Fix folgte in Minuten. Das ist der Unterschied zwischen „sieht richtig aus” und „gegen den Standard geprüft”.
Und der Teil, der für den Stichtag zählt: Strukturierte Adressen sind eingebaut. Das optionale address-Feld an jeder Partei wird für jede Schreibvariante als strukturierter PstlAdr ausgegeben. Die modernen Nachrichten pain.001.001.09 und pain.008.001.08 tragen den vollen Feldsatz. Das Format, in das der Stichtag alle drängt, ist genau das Format, das die Bibliothek schon heute anvisiert.
Eine Überweisung zu schreiben sieht so aus:
import { writeCreditTransfer, validateCreditTransfer } from "sepa-xml-ts";
// validateCreditTransfer() returns a typed result instead of throwing
const result = validateCreditTransfer(doc);
if (!result.ok) {
console.error(result.errors);
} else {
const xml = writeCreditTransfer(result.data);
console.log(xml); // <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09">...
}Du baust ein typisiertes Modell. Die Bibliothek validiert die fachlichen Regeln, berechnet NbOfTxs und CtrlSum mit exakter Ganzzahl-Arithmetik und gibt einen pain.001.001.09-String zurück. Sie kann keine strukturell ungültige Datei erzeugen. Das Parsen geht den umgekehrten Weg und erkennt den Nachrichtentyp automatisch.
NOTE
Die Anforderung an strukturierte Adressen oben kommt vom EPC und ist real, aber die rechtlichen und betrieblichen Details deiner Migration hängen von deinen Banken und deinem Land ab. Validiere deine eigene Ausgabe rechtzeitig vor November gegen die Testumgebung deiner Bank. Diese Bibliothek liefert dir eine korrekte, schema-gültige Datei. Sie ersetzt nicht die Abnahmetests deiner Bank.
Was sie nicht tut
Werbliche Beiträge lassen diesen Teil gern weg. Mir ist lieber, du kennst die Kanten, bevor du sie installierst.
sepa-xml-ts ist eine Bibliothek für Zahlungsdateien. Sie erzeugt, liest und validiert ISO-20022-SEPA-XML. Sie spricht nicht mit Banken. Kein EBICS, kein FinTS, keine Übertragung. Sie macht keine pain.002-Statusberichte und keine camt-Auszüge. Sie ist bewusst auf EUR und SEPA beschränkt.
Nationale Schreibvarianten kommen absichtlich nach Bedarf. Eine Variante erscheint nur zusammen mit dem offiziellen XSD dieses Schemas und echten Golden Samples, weil, noch einmal, eine falsche Variante schlimmer ist als keine. Heute deckt sie die modernen Überweisungs- und Lastschriftnachrichten ab, das alte pain.001.001.03 und die deutschen DK-Varianten, mit Lese-Unterstützung für eine ältere Koexistenz-Lastschrift. Wenn du Schweizer .ch oder eine andere nationale Variante brauchst, ist das ein Issue, keine Überraschung.
Fünfeinhalb Monate
Der Stichtag ist real, die Formatänderung ist konkret, und die Adressregel ist genau die Art von Sache, die nicht in deinen Tests auftaucht, sondern in einem abgelehnten Stapel.
Wenn du SEPA-Dateien in einer TypeScript- oder Node-Codebasis schreibst, ist der Schritt, den ich jetzt machen würde, klein: Erzeuge deine Ausgabe mit einer Bibliothek, die schon pain.001.001.09 und pain.008.001.08 anvisiert, strukturierte Adressen ausgibt und jede Datei gegen das offizielle XSD beweist. Validiere diese Ausgabe dann gegen die Sandbox deiner Bank, solange noch Zeit auf der Uhr ist.
Die Bibliothek liegt auf npm als sepa-xml-ts, der Quellcode auf GitHub, und die vollständige Doku, mit jedem Feld und jeder Variante, lebt unter sepa.codewithagents.de.
Sie ist Open Source und MIT-lizenziert. Probier sie aus, und wenn etwas fehlt oder für deine Bank falsch ist, öffne ein Issue. Genau dieses Feedback entscheidet, was als Nächstes kommt.