Strukturierte Adressen nach ISO 20022: Warum Banken Adressdaten in den Stammdaten bereinigen sollten, nicht in der Zahlungsnachricht

Kurzfassung: ISO 20022 ersetzt Freitext-Adressen in Zahlungsnachrichten durch strukturierte oder hybride Adressen. Mindestens Ort und Ländercode müssen in eigenen Feldern stehen. Am 27. August 2026 hat Swift den für November 2026 geplanten Stichtag für den grenzüberschreitenden Zahlungsverkehr verschoben und einen neuen Zeitplan bis spätestens Dezember 2026 angekündigt. An der Richtung ändert das nichts. Die Abbildung auf XML ist der einfache Teil. Schwierig sind die Kundenstammdaten dahinter: Adressen als Freitext, uneinheitlich aufgeteilt und mehrfach vorhanden in Kernbanksystem, CRM und Zahlungssystemen. Adressnormalisierung und Entity Resolution auf Ebene der Stammdaten lösen das Problem einmal an der Quelle – für jeden Zahlungskanal.

Sehen Sie, wie Tilores Adressdaten in Ihren eigenen Datensätzen strukturiert und auflöst. Demo buchen · Tilores Studio kostenlos testen.

Auf dieser Seite

1. Was ändert ISO 20022 bei Postadressen?
2. Welche Frist gilt nach der Verschiebung durch Swift?
3. Warum ist das ein Stammdatenproblem?
4. Was geht schief, wenn Adressen erst bei der Zahlung zerlegt werden?
5. Wie funktioniert die Adressnormalisierung in Tilores?
6. Warum ist Entity Resolution für Adressen wichtig?
7. Was sollte eine Bank vor der neuen Frist tun?
8. Häufig gestellte Fragen

ISO 20022 ist der globale Nachrichtenstandard, der die alten Swift-MT-Formate im Zahlungsverkehr ablöst. In der öffentlichen Diskussion ging es bisher vor allem um Nachrichtenformate, Migrationstermine und Koexistenz. Die Adressanforderung ist anders gelagert, denn kein Formatwechsel kann sie allein lösen. Sie legt offen, in welchem Zustand die Kunden- und Gegenparteidaten sind, die Banken und ihre Firmenkunden über Jahrzehnte gespeichert haben.

Die Deutsche Bank sagt das in ihren Hinweisen für Geschäftskunden sehr direkt. Als erste Maßnahme nennt sie, Kunden-, Lieferanten- und Unternehmensstammdaten auf Vollständigkeit zu prüfen und sicherzustellen, dass jede Adresse Ort und Land enthält. Erst danach folgen Zahlungsvorlagen, Software-Updates und Formatversionen wie pain.001 v09.

Was ändert ISO 20022 bei Postadressen in Zahlungsnachrichten?

ISO 20022 kennt drei Arten, die Postadresse von Auftraggeber, Begünstigtem und weiteren Beteiligten einer Zahlung zu übermitteln:

Konkret: Eine Bank, die heute Folgendes sendet,

<PstlAdr>
  <AdrLine>Musterstrasse 1</AdrLine>
  <AdrLine>20457 Hamburg</AdrLine>
</PstlAdr>

muss stattdessen etwa Folgendes senden:

<PstlAdr>
  <StrtNm>Musterstrasse</StrtNm>
  <BldgNb>1</BldgNb>
  <PstCd>20457</PstCd>
  <TwnNm>Hamburg</TwnNm>
  <Ctry>DE</Ctry>
</PstlAdr>

Die erste Variante enthält kein Land. Eine Maschine muss raten, wo der Ort steht. Die zweite lässt sich ohne Raten prüfen, routen und abstimmen. Genau deshalb wollen Aufsicht und Zahlungsverkehrsinfrastrukturen sie: Strukturierte Adressen verbessern das Sanktions-Screening, reduzieren False Positives und unterstützen die Erwartung der FATF-Travel-Rule, dass Zahlungsdaten Auftraggeber und Begünstigte eindeutig identifizieren.

Welche Frist gilt für strukturierte Adressen nach der Verschiebung durch Swift?

Ursprünglich sollte Swift mit dem Standards Release 2026 im November 2026 aufhören, vollständig unstrukturierte Adressen in grenzüberschreitenden ISO-20022-Zahlungsnachrichten zu akzeptieren. Am 27. August 2026 hat Swift diese Änderung verschoben. Begründung: Die Fortschritte in der Branche seien „uneinheitlich“ geblieben, und Institute in allen Regionen könnten die Anforderung nicht erfüllen.

Der Stand Ende September 2026:

• Alle zahlungsbezogenen Änderungen des Standards Release 2026 sind verschoben, einschließlich des CBPR+-Pakets, das die Abschaffung unstrukturierter Adressen enthält. Swift veröffentlicht spätestens im Dezember 2026 ein Update.
• Nicht zahlungsbezogene Themen (Wertpapiere, Handel und weitere) gehen separat live, in einem Teil-Release im ersten Quartal 2027.
• Die US Federal Reserve hat ihr entsprechendes Fedwire-Release von November 2026 auf November 2027 verlegt, laut RedCompass Labs.
• Strukturierte und hybride Adressen können bereits heute im gesamten Netzwerk genutzt werden – von Instituten, die sie unterstützen.

Die Deutsche Bank bestätigt die Verschiebung in ihren Kundenhinweisen; der endgültige Termin steht noch aus.

Die Verschiebung ändert den Zeitplan. Sie ändert nicht die Anforderung. Banken, die die zusätzliche Zeit als Aufschub betrachten, stehen 2027 vor demselben Datenproblem – mit weniger Spielraum, es zu lösen. Banken, die sie nutzen, um ihre Stammdaten zu bereinigen, gewinnen mehr als Compliance: eine verlässliche Adresse je Kunde, wiederverwendbar für KYC, Screening, Korrespondenz und Analytics.

Warum ist die Adress-Compliance nach ISO 20022 ein Stammdatenproblem und kein Formatproblem?

Eine saubere, strukturierte Adresse auf StrtNm, BldgNb, PstCd, TwnNm und Ctry abzubilden, ist eine kleine Integrationsaufgabe. Die meisten Adressdaten in einer Bank sind aber nicht sauber – deshalb verzögert sich die Aufgabe immer wieder.

Adressdaten in Banken haben typischerweise vier Probleme gleichzeitig:

1. Freitext statt Felder. Ältere Kernbank- und Zahlungssysteme speichern Adressen oft als zwei bis vier Freitextzeilen. Straße, Hausnummer, Postleitzahl und Ort stehen vermischt darin, in einer Reihenfolge, die vom Land und von der erfassenden Person abhängt.
2. Uneinheitliche Formate. Dieselbe Straße erscheint als Hauptstraße 5, Hauptstr. 5, HAUPTSTRASSE 5 und Haupt Str. 5. Länder werden als Germany, Deutschland, DE, D oder gar nicht angegeben.
3. Fehlende Angaben. Am häufigsten fehlt das Land, weil inländische Systeme es als gegeben vorausgesetzt haben. Genau diese Angabe macht ISO 20022 zur Pflicht.
4. Mehrfach vorhandene Kunden mit widersprüchlichen Adressen. Ein Firmenkunde kann im Kernbanksystem, im CRM, in der Trade-Finance-Plattform und im Payment Hub existieren, jeweils mit einer leicht abweichenden Adresse. Solange es keinen einheitlichen Kundendatensatz gibt, gibt es auch keine einheitlich richtige Adresse.

Die ersten drei Probleme erfordern Adressnormalisierung. Das vierte erfordert Entity Resolution. Beide gehören auf die Ebene der Stammdaten, wo sie einmal gelöst werden und alle nachgelagerten Systeme davon profitieren.

Was geht schief, wenn Banken Adressen erst bei der Zahlung zerlegen?

Die scheinbar schnellste Lösung ist ein Parser im Zahlungskanal, der jede ausgehende Freitext-Adresse in strukturierte Felder zu zerlegen versucht. Als Sicherheitsnetz hilft das. Als Hauptstrategie hat es drei Schwächen:

• Die Arbeit wiederholt sich bei jeder Zahlung. Dieselbe mehrdeutige Adresse wird tausendfach zerlegt, und jedes Mal kann das Ergebnis anders ausfallen, je nachdem, was sonst noch in der Zeile steht.
• Die Ursache bleibt verborgen. Der Kundendatensatz bleibt unstrukturiert, sodass der nächste Kanal, der nächste Bericht und die nächste aufsichtsrechtliche Anfrage auf dasselbe Problem stoßen.
• Konflikte lassen sich nicht auflösen. Wenn das CRM München sagt und das Kernbanksystem Hamburg, kann ein Parser zum Zahlungszeitpunkt nicht wissen, was stimmt. Er strukturiert die falsche Adresse fehlerfrei.

Die Bereinigung in den Stammdaten dreht das um. Die Adresse wird einmal zerlegt, normalisiert und geprüft, dem richtigen Kunden zugeordnet und dann an jeden Kanal ausgeliefert, der sie braucht.

Wie funktioniert die Adressnormalisierung in Tilores?

Tilores ist eine Entity-Resolution-Plattform. Bevor Datensätze verglichen werden, normalisiert Tilores die Werte, die für das Matching genutzt werden – und Adressen gehören zu den wichtigsten davon. Die relevanten Bausteine sind in der Tilores-Transformer-Referenz dokumentiert:

Normalize Address nimmt Straße, Hausnummer, Ort, Postleitzahl und einen Ländercode entgegen und liefert normalisierte Werte für Straße, Hausnummer, Ort und Postleitzahl zurück. Dabei:

• extrahiert der Transformer Hausnummern aus der Straßenzeile, wenn sie nicht in einem eigenen Feld stehen. Er erkennt explizite Kennzeichen (Nr., No., #, nº, civico) und positionsbasierte Konventionen: vorangestellte Hausnummern bei englischsprachigen und französischen Formaten, nachgestellte bei den meisten anderen europäischen Formaten. Bereiche und Zusätze wie 12-14 oder 19c bleiben erhalten.
• wendet er länderspezifische Referenzlisten für Vorverarbeitung, Token-Mapping und Partikel an. So macht die Kompositazerlegung aus Hauptstr. zunächst Haupt str., damit der Straßentyp einheitlich auf die Vollform abgebildet werden kann.
• behandelt er Länder mit Blockadressierung wie Japan, Südkorea und China anders als straßenbasierte Systeme.
• prüft er Postleitzahlen anhand integrierter länderspezifischer Regeln, mit der Option, strukturell ungültige Postleitzahlen zu entfernen, statt sie weiterzugeben.

Normalize Country wandelt frei erfasste Länderangaben in ISO-3166-1-Alpha-2-Codes um – das Format, das auch das ISO-20022-Element Ctry verwendet. Fehlt die Länderangabe oder wird sie nicht erkannt, greift eine Fallback-Kaskade: zuerst die Liste der Ländernamen, dann der Ort, dann länderspezifische Straßen-Token (zum Beispiel verweist strasse auf Deutschland) und schließlich ein konfigurierter Standardwert. Das ist entscheidend, weil fehlende Ländercodes der häufigste Grund sind, warum eine Adresse das hybride Minimum verfehlt.

Convert Text-Operationen wie die Normalisierung diakritischer Zeichen und von Leerzeichen sorgen dafür, dass Müller Straße, Muller Strasse und MÜLLER STRASSE als derselbe Wert verglichen werden.

Tilores bewahrt die Originalwerte neben den normalisierten Werten auf. Die Normalisierung erzeugt vergleichbare, strukturierte Bestandteile, ohne die historischen Belege zu überschreiben. Das ist wichtig für Audits und für die Data Stewards, die entscheiden, welche Adresse maßgeblich wird.

Warum ist Entity Resolution für strukturierte Adressen wichtig?

Normalisierung macht eine Adresse sauber. Entity Resolution stellt sicher, dass es die richtige Adresse für den richtigen Kunden ist.

Tilores verknüpft Datensätze aus verschiedenen Quellsystemen, die sich auf denselben realen Kunden beziehen – anhand normalisierter Namen, Adressen, Identifikatoren, Telefonnummern und E-Mail-Adressen. Das Ergebnis ist eine aufgelöste Entität je Kunde, an der alle Quelldatensätze samt ihren Adressen hängen. Damit erhält der Master-Data- oder Golden-Record-Prozess der Bank, was er braucht, um eine einzige strukturierte Adresse auszuwählen:

• Konflikte werden sichtbar. Hat derselbe Kunde in drei Systemen drei verschiedene Adressen, sieht die Bank sie nebeneinander, mit ihren Quellen – statt den Konflikt erst bei einer abgelehnten Zahlung zu entdecken.
• Lücken werden aus anderen Quellen gefüllt. Einem Zahlungsdatensatz ohne Land kann das Land aus einem verknüpften KYC-Datensatz ergänzt werden, nach Survivorship-Regeln, die die Bank festlegt. Wie Sie diese Regeln aufstellen, beschreibt unser Beitrag zu Survivorship-Regeln für sichere Zusammenführungen.
• Duplikate vermehren sich nicht weiter. Neue Datensätze werden bei der Erfassung in Echtzeit aufgelöst. Ein neuer Onboarding-Datensatz mit leicht abweichender Schreibweise eines bestehenden Kunden wird sofort verknüpft, statt eine weitere unstrukturierte Kopie zu erzeugen.

Tilores muss den Golden Record nicht selbst führen. Es arbeitet neben Kernsystemen, MDM und Zahlungsplattformen der Bank und liefert aufgelöste Entitäten über eine GraphQL API. Die Bank behält die Hoheit über die Survivorship-Regeln und darüber, welche Werte in den maßgeblichen Stammdatenbestand zurückgeschrieben werden. Mehr zu dieser Aufteilung lesen Sie in Matching Engine kaufen und den Golden Record behalten.

Für Banken mit strengen Anforderungen an die Datenresidenz läuft Tilores im eigenen AWS-Konto der Bank, in einer anderen Cloud, im eigenen Rechenzentrum oder in einem Air-Gapped-Netzwerk. Siehe die Deployment-Optionen.

Was sollte eine Bank vor der neuen Frist für strukturierte Adressen tun?

Eine praktische Reihenfolge für die Zeit, die die Verschiebung durch Swift geschaffen hat:

1. Die Lücke messen. Profilieren Sie die Adressdaten in jedem System, das ausgehende Zahlungen speist. Welcher Anteil ist vollständig strukturiert, welcher könnte das hybride Minimum (Ort plus Land) erfüllen, und welcher besteht nur aus Freitext?
2. Auf Stammdatenebene normalisieren. Zerlegen Sie Freitext-Adressen in ihre Bestandteile, vereinheitlichen Sie Straßentypen und Schreibweisen, leiten Sie fehlende Ländercodes ab und prüfen Sie Postleitzahlen. Bewahren Sie die Originalwerte auf.
3. Kunden systemübergreifend auflösen. Verknüpfen Sie doppelte Kunden- und Gegenparteidatensätze, sodass jede reale Partei eine aufgelöste Entität mit allen Quelladressen hat.
4. Survivorship festlegen und Ausnahmen an Data Stewards leiten. Legen Sie fest, welche Quelle bei welchem Adressbestandteil Vorrang hat. Leiten Sie Konflikte und unvollständige Adressen an Data Stewards weiter und bereinigen Sie zuerst die am häufigsten genutzten Gegenparteien.
5. Strukturierte Adressen an die Zahlungskanäle ausliefern. Speisen Sie die strukturierte, aufgelöste Adresse in Zahlungsvorlagen und Kanäle ein. Behalten Sie eine Prüfung zum Zahlungszeitpunkt als Sicherheitsnetz, nicht als Hauptlösung.
6. Aktuell halten. Lösen Sie neue und geänderte Datensätze bei der Erfassung auf, damit die vor der Frist erreichte Adressqualität danach nicht wieder verfällt.

Dieselbe Arbeit zahlt sich auch außerhalb des Zahlungsverkehrs aus. Eine strukturierte, aufgelöste Adresse verbessert Sanktions- und PEP-Screening, KYC-Aktualisierungen, Kundenkommunikation und die Aggregation von Kreditrisiken.

Häufig gestellte Fragen

Welche Adressdaten sind nach ISO 20022 mindestens erforderlich?

Bei hybriden Adressen müssen Ort (TwnNm) und Ländercode (Ctry) in eigenen strukturierten Feldern stehen. Bis zu zwei Freitext-Adresszeilen können den Rest aufnehmen. Vollständig strukturierte Adressen führen Straße, Hausnummer, Postleitzahl, Ort und Land jeweils in einem eigenen Feld. Adressen, die nur aus Freitextzeilen bestehen, werden im grenzüberschreitenden Zahlungsverkehr abgeschafft.

Wurde die Frist für strukturierte Adressen nach ISO 20022 verschoben?

Ja. Am 27. August 2026 hat Swift alle zahlungsbezogenen Änderungen des Standards Release 2026 verschoben, darunter die für November 2026 geplante Abschaffung unstrukturierter Adressen in CBPR+. Swift veröffentlicht spätestens im Dezember 2026 einen aktualisierten Zeitplan. Die US Federal Reserve hat ihr zugehöriges Fedwire-Release auf November 2027 verlegt.

Warum verlangt ISO 20022 strukturierte Adressen?

Strukturierte Adressen ermöglichen eine automatische und genaue Verarbeitung von Zahlungsdaten. Sie verbessern das Sanktions-Screening, reduzieren False Positives und manuelle Prüfungen und helfen Banken, Auftraggeber und Begünstigte eindeutig zu identifizieren, wie es die Vorgaben verlangen.

Kann Adressnormalisierung einen fehlenden Ländercode ableiten?

Oft ja. Der Transformer Normalize Country von Tilores prüft zuerst die Länderangabe, greift dann auf den Ort und länderspezifische Straßen-Token zurück und zuletzt auf einen konfigurierten Standardwert. Adressen, die unsicher bleiben, sollten an Data Stewards gehen, statt geraten zu werden.

Ersetzt Tilores das MDM-System einer Bank?

Nein. Tilores stellt Adressnormalisierung und Entity Resolution als Ebene neben bestehenden MDM-, Kernbank- und Zahlungssystemen bereit. Die Bank behält die Hoheit über Golden-Record- und Survivorship-Regeln und entscheidet, welche strukturierten Werte zurückgeschrieben werden.

Wie kann eine Bank das mit ihren eigenen Adressdaten testen?

Nehmen Sie einen Auszug von Kunden- und Gegenparteiadressen aus zwei oder drei Quellsystemen – einschließlich der Freitext-Datensätze, von denen Sie erwarten, dass sie scheitern – und lassen Sie ihn durch Normalisierung und Auflösung laufen. Sie sehen dann, wie viele Adressen sich automatisch strukturieren lassen, wie viele Duplikate widersprüchliche Adressen tragen und wie viele einen Data Steward brauchen.

Demo buchen oder Tilores Studio kostenlos testen.

Quellen

1. ISO 20022: Neue Anforderungen an Zahlungsdaten, Deutsche Bank.
2. Unstructured address data is being removed. Are you ready?, Swift.
3. Swift extends ISO 20022 structured address deadline, The Paypers.
4. Swift delays ISO 20022 structured address deadline, RedCompass Labs.
5. Transformer Reference, Tilores-Dokumentation.
6. Entity-Resolution-Infrastruktur, Tilores.
7. Deployment-Optionen, Tilores.
8. Doppelte CRM-Datensätze sicher zusammenführen: 5 Survivorship-Regeln für 2026, Tilores.