ISO 20022 Adressstrukturierung — die nächste Pflicht für Banken

Die Deadline: November 2026

Nach der ISO 20022 Migration und der VoP-Pflicht steht der nächste regulatorische Meilenstein im Zahlungsverkehr vor der Tür: Ab November 2026 müssen Adressen in SWIFT-Nachrichten strukturiert vorliegen. Was bisher als Freitext durchging, muss dann in einzelne Felder zerlegt sein — Straße, Hausnummer, Postleitzahl, Ort, Land.

Das klingt nach einer Formalie. Ist es nicht.

Was „strukturiert” bedeutet

In der bisherigen Praxis sehen Adressen in Zahlungsnachrichten oft so aus:

Max Mustermann
Musterstraße 12
60325 Frankfurt am Main

Zwei Zeilen Freitext, keine Trennung zwischen Straße und Hausnummer, keine explizite Angabe des Landes. Das hat jahrzehntelang funktioniert — Menschen können das lesen und interpretieren.

Ab November 2026 verlangt SWIFT für Cross-Border-Zahlungen mindestens eine hybrid-strukturierte Adresse. Das bedeutet: Neben dem Freitext müssen zusätzlich die Felder Country (Länderkennzeichen) und TownName (Ortsname) strukturiert befüllt sein. Langfristig soll die Adresse vollständig strukturiert vorliegen:

<PstlAdr>
  <StrtNm>Musterstraße</StrtNm>
  <BldgNb>12</BldgNb>
  <PstCd>60325</PstCd>
  <TwnNm>Frankfurt am Main</TwnNm>
  <Ctry>DE</Ctry>
</PstlAdr>

Jedes Feld hat seinen Platz. Keine Interpretation nötig, keine Heuristik, keine Ambiguität.

Warum das schwieriger ist als gedacht

Bestandsdaten

Das eigentliche Problem sind nicht die neuen Nachrichten — die kann man ab sofort richtig befüllen. Das Problem sind die Bestandsdaten. Millionen von Kundenstammdaten bei Banken, Versicherungen und Unternehmen enthalten Adressen als Freitext. Diese Bestandsdaten müssen konvertiert werden.

Ein paar Beispiele, die in der Praxis vorkommen:

Freitext	Problem
Hauptstr. 5, 10115 Berlin	Abkürzung „Hauptstr.” auflösen?
Am Markt 3-5	Hausnummernbereich — was kommt in BldgNb?
c/o Schmidt, Bahnhofstr. 7	c/o-Zusatz — wohin damit?
Postfach 12 34 56	Kein Straßenname — Postfach in strukturierte Adresse?
Deutsche Bank AG, Taunusanlage 12	Name und Adresse gemischt
73-75 Mergenthalerallee	Hausnummer vor Straßenname (international üblich)

Jeder dieser Fälle braucht eine Regel. Und für jedes Land gelten andere Regeln. In Deutschland steht die Hausnummer hinter dem Straßennamen, in Frankreich und den Niederlanden davor. In Großbritannien gibt es „Flat 3, 42 High Street” — dreistufig. In Japan hat die Adressstruktur mit europäischen Formaten wenig gemein.

Parsing-Heuristiken

Das Zerlegen von Freitext-Adressen in strukturierte Felder ist ein NLP-Problem. Einfache Regex-basierte Parser scheitern an den Grenzfällen. Die Praxis zeigt, dass ein brauchbarer Parser mindestens diese Schritte braucht:

1. Ländererkennung: Aus PLZ-Format, Ortsnamen oder expliziten Angaben das Land ableiten
2. PLZ-Extraktion: Länderspezifische PLZ-Formate erkennen (DE: 5-stellig, AT: 4-stellig, UK: alphanumerisch)
3. Ort-Identifikation: Ort anhand der PLZ verifizieren — „60325” ist Frankfurt, nicht München
4. Straße und Hausnummer trennen: Länderspezifisch, der kniffligste Teil
5. Zusätze erkennen: c/o, Postfach, Apartmentnummer, Stockwerk

Für den DACH-Raum lässt sich das mit regelbasierten Ansätzen gut lösen. Für den internationalen Einsatz wird es schnell komplex — dann braucht man entweder eine umfangreiche Regeldatenbank oder ML-basierte Ansätze.

Datenqualität

Selbst wenn der Parser perfekt funktioniert — der Input ist es oft nicht. Tippfehler, veraltete Straßennamen (Umbenennungen), fehlende PLZ, abgekürzte Ortsnamen. „Ffm” statt „Frankfurt am Main”, „Muc” statt „München”. Ein Parser kann raten, aber Raten ist nicht das, was man bei Zahlungsverkehrsdaten will.

Die Konsequenz: Adressstrukturierung ist kein reines Softwareproblem. Sie erfordert auch Stammdatenbereinigung — und das ist ein organisatorisches Projekt, kein technisches.

Was SWIFT konkret verlangt

Die CBPR+ (Cross-Border Payments and Reporting Plus) Guidelines von SWIFT definieren die Anforderungen:

Phase 1: Hybrid-strukturiert (November 2026)

Mindestens Country und TownName müssen als strukturierte Felder vorhanden sein. Zusätzlich dürfen weiterhin Freitext-Adresszeilen (AdrLine) verwendet werden.

<PstlAdr>
  <AdrLine>Musterstraße 12</AdrLine>
  <AdrLine>60325 Frankfurt am Main</AdrLine>
  <TwnNm>Frankfurt am Main</TwnNm>
  <Ctry>DE</Ctry>
</PstlAdr>

Das ist die Mindestanforderung. Wer sie nicht erfüllt, dessen Nachrichten werden ab November 2026 von SWIFT mit Warnungen versehen — und perspektivisch abgelehnt.

Phase 2: Vollständig strukturiert (perspektivisch)

Langfristig sollen alle Adressfelder strukturiert vorliegen: StrtNm, BldgNb, PstCd, TwnNm, Ctry. Ein konkretes Datum für die vollständige Pflicht steht noch nicht fest, aber die Richtung ist klar.

Auswirkungen auf verschiedene Akteure

Banken mit Korrespondenzbankgeschäft

Am stärksten betroffen. Jede Cross-Border-Zahlung über SWIFT muss die Adressanforderungen erfüllen. Das betrifft sowohl die Auftraggeber- als auch die Begünstigten-Adresse. Banken müssen ihre Stammdaten prüfen und die Zahlungsverkehrssysteme anpassen.

ERP- und Treasury-Software

Software, die pain.001 (Überweisungsaufträge) erzeugt, muss strukturierte Adressen liefern können. Das betrifft alle ERP-Systeme, Treasury-Management-Systeme und Buchhaltungslösungen, die internationale Zahlungen initiieren.

Finanzdienstleister und Fintechs

Wer Zahlungsnachrichten im Auftrag von Kunden erzeugt oder weiterleitet, muss sicherstellen, dass die Adressen den Anforderungen entsprechen — auch wenn der Kunde die Daten als Freitext liefert. Das bedeutet: Konvertierung im eigenen System.

Was jetzt zu tun ist

November 2026 klingt noch weit weg. Neun Monate. Für ein reines Softwareprojekt wäre das komfortabel. Für Stammdatenbereinigung bei einer Bank ist es knapp.

Schritt 1: Bestandsaufnahme

Wie viele Adressen in den Stammdaten sind heute schon strukturiert? Wie viele sind reiner Freitext? Bei wie vielen fehlt das Land oder die PLZ? Die meisten Banken, die wir kennen, haben diese Analyse noch nicht gemacht. Es lohnt sich, früh damit anzufangen — die Ergebnisse sind oft ernüchternd.

Schritt 2: Parsing-Tool evaluieren

Für die Konvertierung von Freitext zu strukturierten Adressen braucht man ein Werkzeug. Die Optionen reichen von eigenentwickelten Parsern über kommerzielle Adressvalidierungs-Dienste bis hin zu spezialisierten ISO-20022-Tools. Entscheidend ist, dass das Tool die länderspezifischen Formate der eigenen Kundenbasis abdeckt.

Schritt 3: Zahlungsverkehrssysteme anpassen

Die Systeme, die ISO 20022-Nachrichten erzeugen, müssen die strukturierten Adressfelder befüllen können. Das kann eine Anpassung der Datenbank-Schemata, der Mapping-Logik und der Validierungsregeln erfordern.

Schritt 4: Testen

Valide strukturierte Adressen sind das eine. Korrekt strukturierte Adressen das andere. Testdaten, die die verschiedenen Grenzfälle abdecken (internationale Formate, Sonderzeichen, fehlende Felder), sind unverzichtbar. Idealerweise automatisiert und in die CI/CD-Pipeline integriert.

Fazit

Die Adressstrukturierung ist eine dieser Anforderungen, die auf dem Papier trivial aussehen und in der Umsetzung alles andere als das sind. Der technische Teil — ein Feld in Unterfelder zerlegen — ist lösbar. Der organisatorische Teil — Millionen von Bestandsdaten bereinigen, länderspezifische Regeln abbilden, Grenzfälle behandeln — ist der eigentliche Aufwand.

Wer sich jetzt damit beschäftigt, hat noch genug Vorlauf. Wer bis zum Sommer wartet, wird unter Zeitdruck arbeiten. Die Erfahrung aus der ISO-20022-Migration und der VoP-Einführung zeigt: Die letzten drei Monate vor einer Deadline sind nie genug.