Die Koexistenzphase von MT und ISO 20022 für grenzüberschreitende Zahlungsanweisungen endete am 22. November 2025. Die Adoption zog zum Stichtag stark an: RedCompass Labs bezifferte den Anteil ISO-basierter Zahlungsanweisungen im Dezember 2024 auf 32,9 % und im Juni 2025 auf 44,2 %, bevor der Umstieg die Frage für die betroffenen SWIFT-Flüsse ohnehin erledigte. Die meisten Unternehmen haben das als Formatprojekt erlebt, getrieben von ihren Banken und ihrem TMS-Anbieter, mit Erfolg definiert als: Zahlungen gehen weiterhin raus.
Diese Definition greift zu kurz. Die Migration hat dünne MT-Inhalte durch strukturierte Daten ersetzt: Purpose Codes, definierte Parteifelder, strukturierte Adressen und Remittance-Informationen, aufgelöst in maschinenlesbare Elemente statt eines Freitext-Blobs. Ein Zahlungsformat, das die Rechnungsnummer in einem definierten Feld trägt statt irgendwo in 140 Zeichen Text, verändert, was sich nachgelagert automatisieren lässt. Den Ertrag aus der Migration holen die Teams, die ISO 20022 als Datenschicht für Reconciliation, Exception Handling und Payment Analytics behandeln. Das Zeitfenster für den Aufbau dieser Schicht ist jetzt, solange die Nachrichteninhalte frisch sind und die interne Aufmerksamkeit noch existiert.
Die Migration für abgeschlossen zu erklären ist zudem unzutreffend. Der Format-Umstieg bei den Anweisungen hat stattgefunden, aber Reporting- und Exception-Nachrichten laufen deutlich darüber hinaus, die CBPR+-Adressanforderungen verschärfen sich im November 2026, und das CPMI hat die Branche aufgefordert, seine Harmonisierungsanforderungen bis Ende 2027 zu operationalisieren. Was im November 2025 endete, war die Koexistenz, nicht die Arbeit.
Welche Nachrichten den Wert tragen
Vier Nachrichtentypen leisten den Großteil der operativen Arbeit, und sie adressieren unterschiedliche Probleme.
- pain.001 ist die ausgehende Anweisung. Hier sitzt die eigene Datendisziplin: Befüllt der AP-Prozess an dieser Stelle strukturierte Remittance-Daten und eine stabile End-to-End-ID, wird alles Nachgelagerte leichter. Tut er das nicht, rettet auch noch so viel bankseitiges ISO 20022 die Reconciliation nicht.
- pacs.008 ist die Strecke zwischen den Finanzinstituten. Man berührt sie nie direkt, aber die in pain.001 gelieferten Daten reisen durch sie hindurch. Deshalb lohnt es sich, das Truncation- und Mapping-Verhalten der eigenen Banken zu testen statt zu unterstellen.
- camt.052 ist das Intraday-Reporting. Es macht aus dem Cash Positioning ein kontinuierliches Feed statt eines Morgenrituals und ist der Input, der taggleiche Exception-Erkennung überhaupt möglich macht.
- camt.053 ist der End-of-Day-Kontoauszug: das Rückgrat für Reconciliation, GL-Buchung und Offene-Posten-Ausgleich, jetzt mit strukturierten Referenzen, mit denen eine Matching-Engine tatsächlich arbeiten kann.
Die Asymmetrie ist wesentlich. Anweisungen hatten eine harte Frist; die camt-Reporting- und Exception-Nachrichten bleiben die operative Oberfläche, auf der Treasury tatsächlich lebt. Nach dem Umstieg gehört die Investition genau dorthin.
Reconciliation ist der erste Ertrag
Der in der Praxis am häufigsten genannte operative Nutzen, und der, den wir in Projekten bestätigt sehen, ist Auto-Matching. Strukturierte Remittance-Daten in pain.001, zurückgespiegelt in camt.053 und camt.052, erlauben es, Bankgutschriften deterministisch statt probabilistisch auf offene Rechnungen zu matchen. Jeder deterministische Match ist ein manueller Eingriff weniger und eine Exception, die nie entstanden ist.
Der Gewinn hängt an einer unglamourösen Sache: Referenzdisziplin über die gesamte Kette, von pain.001 über pacs.008 bis camt.053. Eine End-to-End-ID, die das ERP erzeugt, die Bank bewahrt und der Kontoauszug zurückliefert, ist das Rückgrat des automatisierten Matchings. Schwache Referenz-Governance, bei der verschiedene Systeme eigene Identifier prägen oder Banken das Gesendete kürzen, bricht den Auto-Match, egal wie strukturiert das Format ist. Bevor Sie in klügere Matching-Logik investieren, prüfen Sie das Überleben der Referenzen: Nehmen Sie eine Stichprobe von Zahlungen und verfolgen Sie, ob die gesendeten Identifier intakt zurückkamen. Das Ergebnis ist oft ernüchternd, und die Behebung ist billiger als jede Software.
Wo Referenzen überleben, wird das verbleibende Matching-Problem klein genug, dass Machine Learning auf den Restfällen sich lohnt, statt als Krücke für schlechte Daten herzuhalten.
Exceptions bekommen ein Daten-Upgrade
Zahlungen scheitern auch nach der Migration. Formatierungsprobleme, Adressvalidierung, fehlende oder fehlerhafte Parteidaten: Die Fehlermodi haben ihre Form verändert, nicht aufgehört zu existieren. Verändert hat sich die Qualität der Evidenz. Ein strukturierter Reject sagt, welches Element gescheitert ist und warum, und das macht zwei Dinge möglich.
Erstens Repair-Automatisierung. Ein großer Teil der Rejects sind Formatierungsprobleme, die eine Rules Engine ohne Menschen beheben und neu einreichen kann, und der strukturierte Fehlerkontext ist es, der diese Regeln sicher schreibbar macht. Zweitens besseres Routing: Exceptions, die eine Untersuchung brauchen, lassen sich klassifizieren und mit angehängtem Kontext in die richtige Queue schicken, statt dass ein Analyst Referenzen in ein Bankportal abtippt, um herauszufinden, was passiert ist. Die camt-basierten Exception- und Investigation-Nachrichten laufen genau deshalb über das Ende der Koexistenz hinaus, weil dieser Workflow dauerhaft ist.
Der praktische Aufbau ist eine kleine Taxonomie von Reject-Gründen, gemappt auf Aktionen: Auto-Repair, Routing an Team X oder Eskalation an die Bank. Messen Sie die Repair-Quote und die Bearbeitungszeit pro Exception, denn das sind die Zahlen, die die Arbeit rechtfertigen.
Die Nachrichten auswerten
Sobald die strukturierten Daten irgendwo Abfragbarem landen, wird eine Reihe von Fragen billig zu beantworten, die früher je ein eigenes Projekt erforderten: Straight-Through-Processing-Quoten je Bank und Zahlungsart, Reject- und Repair-Quoten im Zeitverlauf, welche Banken die Remittance-Daten kürzen, Gebühren für Investigations, Timing der Cash Concentration und die Invoice-Matching-Performance je Gegenpartei. Nichts davon ist exotische Analytik. Es ist gewöhnliches Reporting auf Daten, die endlich in nutzbarer Form existieren, und es gibt Treasury eine Evidenzbasis für Bankverhandlungen, die bisher Anekdote war.
Die Voraussetzung ist Speicherung: Behalten Sie den vollständigen Nachrichteninhalt, nicht den plattgedrückten Extrakt, den die ERP-Integration zufällig konsumiert. Schemata entwickeln sich weiter und Fragen ändern sich; die rohen camt- und pacs-Payloads sind billig aufzubewahren und teuer zu rekonstruieren.
Die operative Realität
Die Kosten sind real und verdienen es, benannt zu werden. Normalisierung ist der größte Posten: Banken implementieren camt- und pacs-Varianten unterschiedlich, und das Mapping jedes Bank-Dialekts auf konsistente interne Felder ist laufende Wartung, kein Einmalprojekt. Manche Gegenparteien und Institute betreiben weiterhin Konvertierungsschichten oder Contingency-Verarbeitung, was Truncation und Latenz genau dort wieder einführt, wo die Migration sie vermeintlich beseitigt hatte. Legacy-ERP-Schemata können die reicheren Inhalte oft nicht aufnehmen, weshalb die Landing-Schicht außerhalb des ERP gehört.
Zwei Termine gehören in den Plan. Unstrukturierte Adressen werden unter CBPR+ im November 2026 non-compliant, was die Bereinigung der Gegenpartei-Adressen zu einem finanzierten Projekt macht statt zu einem Hygiene-Vorsatz. Und der Harmonisierungshorizont des CPMI bis Ende 2027 signalisiert, dass die Regeln zur Nachrichtennutzung weiter anziehen werden; die Mapping-Schicht sollte also auf Veränderung ausgelegt sein.
Und schließlich: den Audit Trail pflegen. Jede automatisch gematchte Gutschrift und jede automatisch reparierte Zahlung ist eine Entscheidung, die das System getroffen hat; speichern Sie den Nachrichteninhalt und die Regelversion, die sie erzeugt haben. Wenn ein Prüfer oder eine Gegenpartei eine Buchung anzweifelt, sind die strukturierten Daten, die die Automatisierung ermöglicht haben, zugleich das, was ihre Verteidigung erlaubt.
Häufige Fragen
Müssen wir unser ERP umbauen, um von reicheren Remittance-Daten zu profitieren?
Meist nicht den ERP-Kern, aber es braucht einen Ort, an dem die vollständige strukturierte Payload landet, bevor sie in Legacy-Felder gestutzt wird. Das übliche Muster ist ein Payment Data Store, der den kompletten camt- und pacs-Inhalt vorhält, mit einer Mapping-Schicht, die dem ERP zuführt, was es aufnehmen kann. Der Fehler ist das Kürzen bei der Ingestion, denn Felder, die nie gespeichert wurden, lassen sich nicht wiederherstellen, und der Wert für Reconciliation und Analytics steckt genau in diesen Feldern.
Unsere Banken senden inzwischen alle camt.053. Warum bleibt unsere Auto-Match-Quote trotzdem flach?
Formatadoption und Datenqualität sind zwei verschiedene Dinge. Banken befüllen dasselbe Schema unterschiedlich, manche transportieren Remittance-Informationen weiterhin als unstrukturierten Text in einem strukturierten Umschlag, und die eigenen pain.001-Dateien tragen Rechnungsreferenzen womöglich gar nicht erst in den strukturierten Elementen. Prüfen Sie Ende zu Ende, was tatsächlich in den Nachrichten steht, bevor Sie die Matching-Engine verantwortlich machen; nach unserer Erfahrung liegt die Lücke meist in der Referenzdisziplin stromaufwärts, nicht im Parser.
Gibt es nach dem Umstieg im November 2025 eine weitere Frist?
Ja. Unter CBPR+ werden unstrukturierte Adressdaten im November 2026 non-compliant, strukturierte oder hybride Adressen sind also die nächste erzwungene Bereinigung. Das jetzt als Datenqualitätsprojekt auf den Gegenparteistammdaten anzugehen ist deutlich günstiger, als später abgewiesene Zahlungen zu reparieren, und dieselbe Bereinigung verbessert nebenbei die Präzision des Sanktionsscreenings.