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.

Bulgarien ist der jüngste dieser Einträge und kommt mit der monatlichen Aktualisierung: solange der erste Lauf das Register nicht geladen hat, 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 die Bulgarian National Bank 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.

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 Lizenz ist unbekannt und wird als unbekannt geführt. bcsm.sm veröffentlicht keine Nutzungsbedingungen — nur eine Datenschutzerklärung und einen Copyright-Hinweis im Fuß (geprüft am 06.09.2026). Unsere Position: vier Zeilen Routing-Daten, von der Aufsicht zur Nutzung veröffentlicht, pro Anfrage als ein Datensatz ausgeliefert, mit Source: Central Bank of the Republic of San Marino, operating banks (read on …) aus eigenem Entschluss und nicht aus Pflicht angegeben. Ein Brief an die Zentralbank liegt bereit; bei Widerspruch wird das Register zurückgezogen. Bis dahin wird keine Klausel erfunden.

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.

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-08), 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: „FATF, High-Risk and Other Monitored Jurisdictions, www.fatf-gafi.org (accessed at each plenary sync)“. 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