Datenquellen & Provenienz

Jede Antwort sagt, wie viel sie wert ist (bank_code_check.authoritative, register, as_of). Diese Seite ist die Langfassung: welcher Referenzbestand für welches Land antwortet, was er veröffentlicht, wie frisch er ist — und, der wichtigste Teil, was ein Fehlen jeweils bedeutet.

Nationale Register — wo authoritative: true

In diesen Ländern ist der konsultierte Referenzbestand das nationale Register: not_in_register heißt, der Code ist nicht vergeben — ein starker Grund, eine Zahlung zu stoppen.

Was das Register über das Institut veröffentlicht, wird in bank_code_check.institution ausgeliefert: Name, Sitzadresse in der Tiefe des Registers, LEI wo vorhanden. Fehlende Felder sind null, nie geraten.

Ein Register zählt erst, wenn seine Zeilen in der Datenbank sind: bis dahin fällt das Land auf die zusammengesetzte Karte zurück und authoritative bleibt false — die Antwort behauptet nie ein Register, das sie nicht hält. Verlässlich ablesbar ist das an bank_code_check.register, das das Register erst nennt, wenn die Zeilen da sind.

Die bulgarischen Daten werden mit der schriftlichen Erlaubnis der Bulgarian National Bank (27.08.2026) nach den Nutzungsbedingungen ihrer Website wiedergegeben; deren Bedingungen sind, die Quelle zu nennen und die Daten nicht zu verändern oder zu verfälschen. Beides reist mit der Antwort: bank_code_check.register nennt die Bulgarian National Bank, as_of trägt das Gültigkeitsdatum des Registers selbst, und Institutsnamen werden wortgetreu kyrillisch ausgeliefert statt transliteriert. Die Weiterverwendung der bulgarischen Felder trägt dieselben Bedingungen weiter. Anders als die Bundesbank-Datei veröffentlicht dieses Register weder ein Löschkennzeichen noch einen Nachfolgecode — ein geschlossener Anbieter verschwindet einfach daraus; ein bulgarisches not_in_register kommt daher nie mit einem Hinweis zur Neuvertragung.

Die slowakischen Daten werden nach den Nutzungsbedingungen der NBS-Website wiedergegeben (Podmienky používania, gelesen am 06.09.2026). Sie erlauben, auf der NBS-Website veröffentlichte Informationen ohne vorherige Zustimmung zu speichern, zu vervielfältigen und weiterzuverwenden — unter zwei Bedingungen: die Národná banka Slovenska muss als Quelle genannt werden, und die elektronische Datei darf inhaltlich oder anderweitig nicht verändert werden. Beides reist mit der Antwort: bank_code_check.register und bic.source nennen die NBS und die Ausgabe, as_of trägt das Gültigkeitsdatum des Registers selbst, und Anbieternamen werden genau wie veröffentlicht ausgeliefert — Diakritika und innere Abstände eingeschlossen —, nicht transliteriert oder bereinigt. Die Weiterverwendung der slowakischen Felder trägt dieselben Bedingungen weiter.

Wir haben die NBS am 26.08.2026 gefragt, ob das Herauslösen einzelner Felder als Veränderung der Datei gilt; bis zum 06.09.2026 ohne Antwort. Die Tschechische Nationalbank, deren Bedingungen eine nahezu identische Klausel tragen, antwortete am 27.08.2026, dass dem nicht so ist. Antwortet die NBS anders, kommt dieses Register wieder heraus. Wie das bulgarische veröffentlicht es weder Löschkennzeichen noch Nachfolgecode — ein slowakisches not_in_register kommt daher nie mit einem Hinweis zur Neuvertragung.

Die tschechischen Daten werden nach den Nutzungsbedingungen der ČNB-Website wiedergegeben (Podmínky užívání internetových stránek ČNB, § 3, gelesen am 24.09.2026). Sie erlauben, die auf ihrer Website veröffentlichten Informationen zu speichern, weiterzugeben und zu vervielfältigen — unter der Bedingung, dass die ČNB stets als Quelle genannt wird, in ihren eigenen Worten Zdroj: ČNB, und dass ein Auszug weder die Fakten noch ihren Sinn verändert. Beides reist mit der Antwort: bank_code_check.register trägt „Zdroj: ČNB" in jeder Antwort, die das Register entscheidet, Ablehnungen eingeschlossen, bic.source nennt die Ausgabe („Zdroj: ČNB, Číselník kódů platebního styku v ČR, verze N"), as_of trägt ihr Gültigkeitsdatum, und Anbieternamen werden genau wie veröffentlicht ausgeliefert. Die Weiterverwendung der tschechischen Felder trägt dieselben Bedingungen weiter. Warum ein Fehlen hier eine Ablehnung ist: Die Verordnung Nr. 169/2011 Slg. (vyhláška č. 169/2011 Sb.) macht die IBAN-Positionen 5-8 zum Zahlungsverkehrscode (§ 4 c) und verpflichtet die ČNB, jeden von ihr vergebenen Code in diesem Verzeichnis zu veröffentlichen (§ 6 Abs. 2). Das Verzeichnis veröffentlicht keinen Nachfolgecode — ein tschechisches not_in_register kommt daher nie mit einem Hinweis zur Neuvertragung.

Ein Register, das Inhaber nennt, ohne den Raum abzudecken — San Marino

San Marino steht für sich, weil es die Regel bricht, auf der die Tabelle oben beruht. Die Zentralbank veröffentlicht die vier Banken, die sie beaufsichtigt; sie veröffentlicht nicht die Vergabe des ABI-Coderaums. San Marino lizenziert außerdem Zahlungs- und E-Geld-Institute, die keine Banken sind (eines hält einen san-marinesischen BIC und wickelt über EBA STEP2 ab), und die offizielle san-marinesische Beispiel-IBAN trägt einen ABI-Code, der nicht auf der Seite steht. Also:

• ein gelisteter Code antwortet verified mit dem Institut, das die Zentralbank nennt — und authoritative: false;
• ein Code, der nicht auf der Liste steht, antwortet genau das, was San Marino vor diesem Register antwortete: not_in_register mit dem Grund absent_from_reference_data. Nie not_allocated, und nie ein Grund, eine Zahlung zu stoppen.

Ein Flag geht in die andere Richtung: bic.basis ist national_register und bic.authoritative ist true, denn der BIC neben einem gelisteten Code ist die Zuordnung der Zentralbank selbst. San Marino ist die Stelle, an der die beiden Autoritäts-Flags auseinandergehen — umgekehrt zur Schweiz.

Die Zentralbank hat diese Nutzung schriftlich bestätigt (16. Oktober 2026). bcsm.sm veröffentlicht keine Nutzungsbedingungen (geprüft am 06.09.2026), also haben wir gefragt. Die Zentralbank antwortete, dass es akzeptabel ist, die Bank hinter einer san-marinesischen IBAN anhand ihrer Liste zu nennen, auch für zahlende Kunden, sofern die Informationen genau wiedergegeben, ihrer Quelle angemessen zugeschrieben und nicht irreführend dargestellt werden. Sie hat die Quellenangabe Source: Central Bank of the Republic of San Marino, Operating Banks zusammen mit dem Datum, an dem die Seite gelesen wurde, akzeptiert, und jede Antwort aus der Liste trägt beides. Ihre E-Mail wurde in gutem Glauben versandt und begründet keine Verpflichtung der Bank: eine schriftliche Bestätigung, dass diese Nutzung akzeptabel ist, keine Lizenz. Sie betrifft die beschriebene Nutzung in den Antworten der API; die Liste selbst bleibt außerhalb dieses Repositorys.

Finnland ist am 16. September 2026 aus der autoritativen Tabelle oben hierher gewandert: eine Ablehnung auf Basis einer elf Monate alten Abschrift ist kein Grund, eine Zahlung zu stoppen. Es kehrt zurück, sobald die Liste gegen eine aktuelle Veröffentlichung neu gelesen wurde.

Die zusammengesetzte BIC-Karte — wo authoritative: false

Überall sonst lösen Bankcodes gegen unsere zusammengesetzte Karte auf: 121k+ BIC-Einträge aus GLEIF (LEI-angereichert), dem öffentlichen SWIFT-Verzeichnis, SIX, EBA STEP2 SCT, Bundesbank und NBP. Ein Treffer benennt den Inhaber des passenden BIC — er beweist nicht, dass das Institut IBANs ausgibt, und ein Fehlen beweist gar nichts. In den rund 30 Ländern mit Buchstaben-Bankcodes kann ein Präfix-Rückfall candidates > 1 liefern; die Antwort kennzeichnet das als Hinweis.

Seit dem 29. September 2026 deckt die Karte die Vereinigten Arabischen Emirate, Bosnien und Herzegowina, Estland, Georgien, Kasachstan, Moldau, Serbien und die Türkei nicht mehr ab: Jede Zuordnung, die wir für sie hatten, stammte aus einer Quelle, die keine Weiterverwendung gestattet (eine kommerzielle IBAN-Website oder ein Bankenverband, der die kommerzielle Nutzung vorbehält). Eine IBAN dieser Länder wird weiterhin validiert, und ihr Bankcode antwortet unavailable (no_reference_data_for_country) ohne bic-Block, nie mit einer Vermutung; die Ausnahmen sind Estland, für die Codes, die seine Aufsichtsbehörde, die Finantsinspektsioon, führt, und Serbien, für die Banken, die die Serbische Nationalbank als Teilnehmer ihrer Zahlungssysteme führt: Sie antworten aus diesen Listen und nicht aus der Karte. Aus demselben Grund haben ein Teil der spanischen und italienischen Schlüssel und die rumänischen die Karte verlassen; wo offene Daten einen einzigen BIC nennen, wurden sie daraus neu aufgebaut (für Italien der LEI der Banca d'Italia, dann GLEIF; für Rumänien der BIC bei GLEIF, der mit dem Bankcode beginnt), und die übrigen Schlüssel dieser Länder bleiben unverändert.

Die Niederlande werden zusätzlich gegen die Liste IBAN-ausgebender Zahlungsdienstleister der Betaalvereniging geprüft (issuer.iban_issuer): Ein Code, dessen Inhaber dort fehlt, behält seinen Namen, verliert aber den Typ bank — den BIC-Inhaber zu nennen ist ein Fakt; ihn zur Bank Ihrer Gegenpartei zu erklären wäre eine Vermutung.

Vereinigtes Königreich — PRA-Erlaubnis zum Einlagengeschäft

Quelle: Bank of England (List of Banks, 2026-09), die monatliche Liste der Institute, denen die Prudential Regulation Authority das Einlagengeschäft erlaubt. Genutzt mit der schriftlichen Erlaubnis der Bank of England, deren Bedingung die Nennung der Bank zusammen mit dem Monat der Liste ist — deshalb trägt jeder pra_authorisation-Block ein list_month, gelesen aus den geladenen Daten und nie von Hand geschrieben.

Sie steht bewusst nicht in der Registertabelle oben. Sie ist eine Liste zugelassener Institute (Name, FRN, LEI), keine Zuteilung von Bankcodes: Sie kann einen GB-Bankcode also niemals authoritative: true machen. Sie beantwortet eine andere Frage: Darf das Institut hinter dieser IBAN nach PRA-Erlaubnis Einlagen entgegennehmen?

• Verknüpft allein über die LEI, nie über Namen. Die Liste veröffentlicht je Institut eine LEI, das BIC-Verzeichnis je Eintrag ebenfalls. Namensähnlichkeit ist genau der Weg, auf dem eine Bank die Erlaubnis einer anderen trägt.
• Begrenzt auf die Rechtsordnung, die die Erlaubnis abdeckt. Der Zweigstellen-Abschnitt veröffentlicht die LEI der Hauptniederlassung — der Mutter im Ausland —, die GLEIF jedem BIC dieser Einheit weltweit zuordnet. Der Block wird deshalb nur für GB-BICs ausgeliefert (und GI für den Gibraltar-Abschnitt); eine LEI-Verknüpfung ohne Geltungsbereich würde eine britische Einlagenerlaubnis auf einem BIC aus Frankfurt oder Tokio verkünden.
• Vorhanden bei Treffer, sonst abwesend — nie authorised: false. Die Liste deckt nur das Einlagengeschäft ab und sagt in ihrer eigenen Präambel, dass sie das Financial Services Register nicht ersetzt. Ein fehlendes Institut kann eine Wertpapierfirma, ein E-Geld-Institut oder eine Credit Union sein.

Vereinigtes Königreich — das Financial Services Register, Institut für Institut

Quelle: FCA Financial Services Register, je ein Institut auf einmal über die Register-API der FCA abgefragt durch GET /v1/gb/firm/:frn, unter der schriftlichen Zustimmung des Register Team vom 7. September 2026 zu genau dieser Nutzung. Nichts wird importiert: keine Liste, keine Kopie, keine Tabelle von Instituten. Jede Antwort nennt die Quelle, trägt ihr Abrufdatum und den Haftungsausschluss der FCA selbst und wird höchstens einen Tag zwischengespeichert — eine abgelaufene Kopie wird nur bedient, solange das Register selbst ausfällt, als stale markiert und nie mehr als sechs Stunden nach ihrem Tag.

Die vier Bedingungen der FCA werden im Code gehalten: die veröffentlichten Ratenlimits (eine Anfrage in Bearbeitung, ein Mindestabstand zwischen Aufrufen, eine beachtete Wartezeit nach einem 429); keine Nutzung für Marketing (ein Test lässt den Build scheitern, sobald CRM oder Akquise den Register-Client importieren); IBANforge als Verantwortlicher für die empfangenen Daten (nur die Ressource „Institut“ wird aufgerufen, nie die Personen des Registers); und der Haftungsausschluss der FCA auf jeder Antwort.

Compliance-Signale

Die FATF-Länderlisten werden mit der von ihren Bedingungen verlangten Quellenangabe genutzt, im Zitierformat der FATF selbst (Jahr und Abrufdatum ändern sich mit jeder Aktualisierung nach einer Plenarsitzung):

FATF (2026), High-Risk and Other Monitored Jurisdictions, FATF public statements of the October 2026 plenary, https://www.fatf-gafi.org (accessed on 3 November 2026).

Die FATF erlaubt die kommerzielle Nutzung ihrer Daten mit Quellenangabe; jede Weiterverwendung der FATF-Felder dieser API trägt dieselbe Attributionspflicht weiter.

Sanktions-Screening erfolgt auf Bankebene (BIC8), nicht auf Namensebene — jede Compliance-Antwort wiederholt das in ihrem eigenen meta. Es ist kein reguliertes AML/CFT-Produkt.

Die Wächter-Tests — warum diese Aussagen wahr bleiben

Zwei Fehlerarten haben die Versprechen dieser Seite früher gebrochen: eine ausgelieferte Zahl, die über die Realität hinauswächst, und eine Abdeckungsaussage, die ihre Daten überlebt. Beide werden jetzt von Tests gehalten, die bei jedem Push laufen und im wöchentlichen Refresh-Workflow, bevor er committen darf:

• jede auf einer ausgelieferten Oberfläche veröffentlichte Datensatzzahl muss kleiner oder gleich dem Live-Bestand sein;
• keine ausgelieferte Oberfläche darf eine Sanktionsbehörde nennen, die in der gelieferten Datenbank fehlt — der wöchentliche Refresh schlägt laut fehl, statt eine Aussage auszuliefern, die seine eigenen Daten nicht mehr tragen;
• keine ausgelieferte Oberfläche darf eine Prüfung auf Kontoebene versprechen, in keiner der drei Sprachen.

Der Monat der konsultierten Referenzdaten wird in jeder Antwort als bank_code_check.as_of zurückgegeben.

Siehe auch: Was „verified" bedeutet · VoP-Bereitschaft · Compliance-Check · Schweizer QR-IBAN & QR-IID