Strukturierte ISO-20022-Adressen: Regeln und Zeitpläne

Jeder Zahlungsweg bestimmt seinen Zeitplan. SIX nennt weiterhin den 14. November 2026 für Schweizer Zahlungsaufträge, wenn eine Adresse verwendet wird. EPC und Swift haben ihre Fristen verschoben. Diese Seite trennt die Termine von den Adressregeln, die die API prüft.

Geprüft am 10. September 2026. Die EPC-Entscheidung vom 9. September erlaubt unstrukturierte Adressen in allen fünf Zahlungsschemen über den 15. November 2026 hinaus; das neue Enddatum soll im Oktober festgelegt werden. Swift hat am 27. August die Zahlungsverkehrsänderungen ohne neues Adressdatum verschoben, mit einem Update spätestens im Dezember. SIX veröffentlicht weiterhin seinen getrennten Schweizer Zeitplan.

Die veröffentlichten Fristen

Diese Verschiebungen ändern für sich allein die Schweizer Regeln nicht. Sie ändern auch nicht die von /v1/address/check geprüften Felder: Das Ergebnis beschreibt die Übereinstimmung mit dem genannten Dokument, nicht das Datum, ab dem eine Bank die Regel anwenden muss. T2, Fedwire und CHAPS haben eigene Zeitpläne; die datierten Quellen stehen unter Welches Datum ist DAS Datum?.

Das frühere Datum 22. November 2026 stand tatsächlich im EPC-Leitfaden. Version 2.1 ersetzte es durch den 15. November 2026, der im September 2026 ebenfalls verschoben wurde. Es ist keine aktuelle Frist. Die Schweizer QR-Rechnungsänderung vom 22. November 2025 ist ein anderes Ereignis.

Für eine ganze Schweizer QR-Rechnung prüft POST /v1/ch/qr-bill/check die Nutzdaten, einschliesslich strukturierter (S) oder kombinierter (K) Adressen.

Was die Regeln von einer Agent-Adresse verlangen: einen Ort und ein Land

Die nützlichste Tatsache dieser Regeln, für jeden, der Zahlungssoftware baut, ist, wie wenig sie von der Adresse eines Finanzinstituts verlangen.

Die Schweizer Feldtabelle für die PostalAddress eines Creditor Agent bietet genau drei Elemente: TwnNm (Must be used), Ctry (Must be used) und AdrLine (max. 2). StrtNm, BldgNb und PstCd erscheinen in dieser Guideline nur unter Creditor und Ultimate Debtor — nie unter einem Agent. Die Federal Reserve sagt dasselbe in Prosa für ihre eigene Schiene: "require town name and country".

Also: eine Agent-Adresse ist ein Name, ein Ort und ein Land. Keine Strasse.

Und oft ist sie gar nicht verlangt

Zwei der drei Korpora knüpfen die Agent-Adresse an das Fehlen des BIC.

Die Schweiz zählt die Wege auf, einen Creditor Agent zu identifizieren; die vollständige Adresse ist dort eine Option unter mehreren — der BIC eine andere, und die für grenzüberschreitende Zahlungen empfohlene.

T2 / HVPS+ formuliert dieselbe Mechanik als Validierungsregel: fehlt BICFI, dann müssen Name und PostalAddress vorhanden sein. Sie gilt für DbtrAgt, CdtrAgt, die zwischengeschalteten Agenten und die vorherigen beauftragenden Agenten.

Die Federal Reserve formuliert diesen Auslöser nicht. Ihre Seite bestätigt, dass die Änderung die Agenten erreicht — "for all parties and agents across all message types" —, was mit der bedingten Mechanik vereinbar ist, sie aber nicht bezeugt. Zwei Schienen sagen es, eine nicht; diese Seite schreibt nicht, dass alle drei dasselbe sagen.

Die Umkehrung — und darum geht es auf dieser Seite wirklich

Lesen Sie die Schweizer Business Rules noch einmal: "depending on the payment type, it remains also possible to replace the address with another element like the BIC."

Dieser Satz dreht das ganze Problem um. Wer eine Clearing-Nummer und keinen BIC hat, steckt in dem Zweig der Regel, der Name und vollständige Adresse verlangt. Wer den BIC hat, den betrifft diese Pflicht überhaupt nicht.

Das heisst: Die nützliche Frage im November 2026 lautet oft nicht "wie strukturiere ich die Adresse dieses Agenten?", sondern "wie komme ich an den BIC dieses Agenten, damit ich es nie muss?" — und eine nationale Clearing-Nummer in einen BIC aufzulösen, ist genau das, was diese API seit jeher tut:

• Schweizer IID / BC-Nummer → GET /v1/ch/clearing/:iid
• Deutsche Bankleitzahl → bank_code_check auf einer validierten IBAN
• Österreichische Bankleitzahl → derselbe Block
• Jede IBAN → POST /v1/iban/validate löst den BIC auf

Kein neuer Code, kein neuer Endpunkt, kein neues Abonnement. Löst sich der BIC auf, entfällt die Adresspflicht für diesen Agenten.

postal_address — der Sitz im Vokabular von ISO 20022

Jede Antwort, die bereits eine Institutsadresse trägt, trägt sie nun zusätzlich als ISO-20022-PostalAddress, in den Tag-Namen des Standards — damit Sie sie ohne Übersetzungstabelle in eine pain.001 oder eine pacs.008 übernehmen können.

Das ist additiv. Der bestehende address-Block bleibt unangetastet und weiterhin der vollständige, ungekürzte Datensatz.

Ein Schweizer Institut: structured

curl https://api.ibanforge.com/v1/bic/POFICHBE

{
  "postal_address": {
    "strt_nm": "Mingerstrasse",
    "bldg_nb": "20",
    "pst_cd": "3030",
    "twn_nm": "Bern",
    "ctry": "CH",
    "format": "structured",
    "source": "SIX BankMaster (Swiss IID register)",
    "as_of": "2026-08-03"
  }
}

StrtNm und BldgNb sind hier gefüllt, weil das SIX-BankMaster-Register sie als zwei getrennte Spalten veröffentlicht. Es ist die einzige Quelle dieser Datenbank, die das tut.

Ein aus GLEIF stammendes Institut: hybrid

curl https://api.ibanforge.com/v1/bic/BUKBGB22

{
  "postal_address": {
    "pst_cd": "E14 5HP",
    "twn_nm": "LONDON",
    "ctry": "GB",
    "adr_line": ["1 CHURCHILL PLACE"],
    "format": "hybrid",
    "source": "GLEIF",
    "as_of": "2026-04-13"
  }
}

Kein strt_nm — und das ist die Entwurfsentscheidung, die man verstehen sollte, bevor man das Feld auswertet.

GLEIF veröffentlicht eine Adresse als Liste von Zeilen, die wir zu einer einzigen Zeichenkette zusammengefügt speichern. Hausnummer, Stockwerk, Gebäudename und Stadtteil können darin gemeinsam stehen. Das in StrtNm und BldgNb zu zerlegen wäre geraten, und geraten ist genau das, was eine Zahlungsschiene zurückweist. Die Zeile geht deshalb als AdrLine hinaus — das hybride Format, das die Regeln ausdrücklich erlauben — und format sagt Ihnen, welches der beiden Sie erhalten haben.

Lesen Sie ein fehlendes strt_nm als "die Quelle hat eine einzige zusammengefügte Zeile veröffentlicht", niemals als "dieses Institut hat keine Strasse".

Nur Ort und Land: vollständig, nicht reduziert

{
  "postal_address": {
    "twn_nm": "ZURICH",
    "ctry": "CH",
    "format": "structured",
    "source": "Redistributed SWIFT BIC directory (PeterNotenboom/SwiftCodes, MIT)",
    "as_of": null
  }
}

Das ist die Form, die der grösste Teil des Verzeichnisses annimmt — und laut dem Abschnitt weiter oben genau das, was die Regeln von einer Agent-Adresse verlangen. Ort und Land sind hier keine Teilantwort. Sie sind die Antwort.

Gemessen an der ausgelieferten Datenbank am 26. August 2026: 99,3 % der Verzeichniszeilen tragen einen Ort, aber nur rund 30 % überhaupt eine Strasse. Messen Sie nach, bevor Sie die Zahl zitieren — die Datenbank wird monatlich aufgefrischt, und der Wert wandert.

Zwei Herkunftsregeln, die sich nicht ändern werden

source benennt den Datensatz, aus dem die Adresse stammt, und darf berechtigt von address.source abweichen: Ein Schweizer Institut wird aus dem SIX-Register bedient, während der bisherige Block bei GLEIF bleibt. Wenn die beiden Register auseinandergehen — beide können einen echten, unterschiedlichen Sitz desselben Instituts veröffentlichen —, sehen Sie beides und entscheiden selbst.

as_of ist das Datum, an dem die Quelle diese Adresse zuletzt festgehalten hat. Es ist null, wenn der Datensatz keines veröffentlicht. Es ist nie das Datum, an dem unsere Datenbank aufgefrischt wurde, und nie eine Uhrzeitabfrage: Eine heute datierte Adresse aus einer im Vorjahr eingereichten Datei wäre eine falsche Aussage über das Register.

Derselbe Block erscheint am bic-Objekt von POST /v1/iban/validate, gebaut vom selben Code — die beiden Endpunkte können sich über dieselbe Zeile also nicht widersprechen.

POST /v1/address/check — kostenlose Konformitätsprüfung

Die andere Hälfte. Sie haben eine Adresse strukturiert; dies sagt Ihnen, ob sie die Regeln einer bestimmten Schiene erfüllt — Regel für Regel, mit dem Dokument, aus dem jede Regel stammt.

Es liest keine unserer Datenbanken. Deshalb ist es kostenlos.

curl -X POST https://api.ibanforge.com/v1/address/check \
  -H "Content-Type: application/json" \
  -d '{
    "scheme": "sps",
    "address": {
      "twn_nm": "Zurich",
      "ctry": "ch",
      "pst_cd": "8001",
      "adr_tp": "ADDR",
      "adr_line": ["Bahnhofstrasse 45", "8001 Zurich"]
    }
  }'

{
  "scheme": "sps",
  "conforms": false,
  "findings": [
    { "rule": "twn_nm_required", "verdict": "pass", "detail": "TwnNm is present (\"Zurich\")." },
    { "rule": "ctry_required", "verdict": "pass", "detail": "Ctry is present (\"ch\")." },
    { "rule": "ctry_iso3166", "verdict": "fail", "detail": "Ctry \"ch\" is not two uppercase letters." },
    { "rule": "adr_tp_forbidden", "verdict": "fail", "detail": "AdrTp \"ADDR\" was supplied. SPS marks Address Type \"N — Must not be sent\"." },
    { "rule": "adr_line_max_2", "verdict": "pass", "detail": "2 AdrLine supplied, within the maximum of 2." },
    { "rule": "adr_line_max_length_70", "verdict": "pass", "detail": "Every AdrLine is at most 70 characters." },
    { "rule": "adr_line_no_repeat", "verdict": "fail", "detail": "\"8001 Zurich\" repeats PstCd + TwnNm. SPS: \"Data already provided in another element must not be repeated.\"" }
  ]
}

Jedes Finding trägt zusätzlich ein Feld source, oben aus Platzgründen weggelassen — es benennt das Dokument und sein Datum, damit Sie das Urteil an denjenigen weiterreichen können, der die Adresse erzeugt hat.

Die Regeln, und zu welcher Schiene jede gehört

Ein Strich bedeutet, dass das für diese Schiene abgerufene Dokument dazu nichts sagt. Er bedeutet nicht, dass die Regel umgekehrt gilt, und wir übernehmen keine Regel einer Nachbarschiene, um die Lücke zu füllen — Schweigen wird als Schweigen berichtet.

verdict hat drei Werte, nicht zwei. not_applicable kennzeichnet eine Regel, deren Voraussetzung nicht erfüllt ist — eine AdrLine-Regel bei einer Adresse ohne AdrLine. Das ist eine echte Antwort, kein höfliches pass, und conforms lässt sie unberücksichtigt.

Warum es einen scheme-Parameter gibt und keinen „konform"-Boolean

Weil die drei Schienen tatsächlich auseinandergehen und ein einzelner Boolean sich für eine entscheiden und das verschweigen müsste:

• TwnNm + Ctry sind unbedingt bei SPS und Fedwire und bedingt bei T2 / HVPS+ — nur verlangt, wenn AddressLine fehlt.
• AdrLine ist bei SPS und Fedwire auf 2 gedeckelt, im T2-Validierungsanhang auf nichts, und im Basis-ISO-20022 bis 7 erlaubt.
• AdrTp ist bei SPS verboten und bei den beiden anderen nicht erwähnt.

Und cbpr+ gehört bewusst nicht zu den Schemata. Seine Regeln liessen sich aus keiner öffentlichen Quelle lesen. "scheme": "cbpr+" liefert einen 400, der das sagt, statt eines Urteils, das man hätte erfinden müssen.

Was dies nicht leistet

Drei Grenzen, hier genannt, damit sie niemand erst im November entdeckt.

Dies löst keine Migration von Kundenadressen. Der Grossteil der Änderung von November 2026 betrifft die Adressen der Parteien einer Zahlung — Dbtr, Cdtr, UltmtDbtr, UltmtCdtr. Das ist Ihr eigenes Kundenadressbuch; diese API hält dazu keine Daten und stellt dazu keine Behauptung auf. Wer Ihnen sagt, eine IBAN- und BIC-API erledige diese Migration für Sie, verkauft Ihnen etwas, das er nicht hat.

Dies verwandelt keine Freitextadresse in eine strukturierte. Aus „ul. Sokolska 34, 40-086 Katowice" ein StrtNm / BldgNb / PstCd / TwnNm zu machen, erfordert nationale Postreferenzdaten für rund 250 Länder. Das ist das Geschäft von Loqate, Smarty und Googles Address Validation API. Wir halten davon nichts, und eine ungeprüfte Vermutung über einen Strassennamen ist weniger wert als keine Antwort.

Dies bescheinigt keine CBPR+-Konformität. Keine öffentliche Quelle erlaubt es heute irgendjemandem, das ehrlich zu tun. Der Prüfer benennt die Schiene, gegen die er urteilt, und jedes Finding benennt sein Dokument.

Was nach diesen drei Abzügen bleibt, ist klein und echt: die ISO-20022-Form eines Institutssitzes, den wir ohnehin halten, eine Regelprüfung, die Sie kostenlos laufen lassen können, und — der wertvollste Teil — die Erinnerung daran, dass das Auflösen einer Clearing-Nummer in einen BIC die Adresspflicht oft schlicht beseitigt.

Die Papierspur der Marktpraxis

Die PMPG (Payments Market Practice Group, das unabhängige Gremium zur Begleitung der ISO-20022-Einführung) veröffentlicht den monatlichen Newsletter Payment Insights; die Ausgabe vom August 2026 behandelt genau diese Frist — und erlaubt, anders als die CBPR+-Usage-Guidelines, die Wiedergabe unter Quellenangabe, sodass wir sie zitieren können. Drei Punkte verdienen Ihre Aufmerksamkeit: Sie beschrieb die damals für November 2026 geplante Entfernung; dieser Zeitplan ist durch die oben genannten Verschiebungen von Swift und EPC überholt; sie benennt die hybride Postadresse — dasselbe format: "hybrid", das diese API ausliefert — als die von der PMPG getragene Form für nicht vollständig strukturierbare Adressen; und ihre Impact-Tabelle stuft «Einmalzahlung mit unvollständigen Kreditor-Adressdaten» als begrenzt ein, gegenüber hoch für fehlende Ländercodes in Dateien mit hohem Volumen. Quelle: PMPG, Payment Insights, August 2026.