Data Sources & Provenance

Every response says how much it is worth (bank_code_check.authoritative, register, as_of). This page is the long version: which reference set answers for which country, what it publishes, how fresh it is, and — the part that matters most — what an absence means in each.

National registers — where `authoritative: true`

In these countries, the reference set consulted is the national register: not_in_register means the code is not allocated, a strong reason to stop a payment.

Country	Register	Refresh	What it publishes beyond the code
CH / LI	SIX BankMaster (IID / BC-Nummer)	monthly	full seat address, BIC, payment-rail participation (SIC, euroSIC, CHF Instant), QR-IID
DE	Deutsche Bundesbank, Bankleitzahlendatei	monthly	name, postal code + town (the register has no street column), retirement + successor BLZ
AT	Oesterreichische Nationalbank, SEPA-Zahlungsverkehrs-Verzeichnis	monthly (source republishes daily)	full seat address, BIC, LEI
BE	Banque nationale de Belgique, bank identification codes	monthly	name in up to four languages — the file publishes no addresses; reserved slots (VRIJ, Onbeschikbaar) are treated as unallocated
FI	Finance Finland, monetary institution codes	on republication	codes are allocated to banking groups, not institutions — a hit confirms the group, so the positive claim is weaker and the response says so
BG	Bulgarian National Bank, BAE register	re-read monthly (the register itself is republished on request, not on a calendar — `as_of` carries its own effective date, not ours)	name only, in Cyrillic as published, plus the head-office BIC. The verdict is made on the four-letter bank code (IBAN positions 5-8): a BAE code also covers the branch digits in positions 9-12, but the register does not enumerate every bank's branches to one standard, so branch digits are never used to deny

What the register publishes about the allocated institution is served in bank_code_check.institution — name, seat address to the depth the register carries, LEI where available. Absent fields are null, never guessed.

Bulgaria is the newest of these and arrives with the monthly refresh: until the first run loads the register, the country degrades to the composite map and authoritative stays false — the answer never claims a register it is not holding. The dated way to tell is bank_code_check.register, which only names the Bulgarian National Bank once the rows are there.

Bulgarian data is reproduced with the Bulgarian National Bank's written permission (27/08/2026) under its site terms, whose conditions are that the source be cited and the data not be altered or distorted. Both travel with the answer: bank_code_check.register names the Bulgarian National Bank, as_of carries the register's own effective date, and institution names are served verbatim in Cyrillic rather than transliterated. Reuse of the Bulgarian fields carries the same conditions onward. Unlike the Bundesbank file, this register publishes no deletion flag and no successor code — a closed provider simply disappears from it, so a Bulgarian not_in_register never comes with a re-papering hint.

The composite BIC map — where `authoritative: false`

Everywhere else, bank codes resolve against our composite map: 121k+ BIC entries assembled from GLEIF (LEI-enriched), the public SWIFT directory, SIX, EBA STEP2 SCT, Bundesbank and NBP data. A hit names who holds the matching BIC — it does not prove the institution issues IBANs, and an absence proves nothing at all. In the ~30 countries whose bank codes are letters, a prefix fallback can return candidates > 1, and the response flags it as indicative.

The Netherlands additionally checks the Betaalvereniging list of IBAN-issuing providers (issuer.iban_issuer): a code whose holder is not on that list keeps its name but loses its bank type — naming the BIC holder is a fact, calling it your counterparty's bank would be a guess.

United Kingdom — PRA deposit-taking authorisation

Source: Bank of England (List of Banks, 2026-08), the monthly list of firms the Prudential Regulation Authority authorises to accept deposits. Used with the Bank of England's written permission, whose condition is attribution to the Bank together with the month of the list — which is why every pra_authorisation block carries list_month, read from the loaded data rather than written by hand.

This is deliberately not in the register table above. It is a list of authorised firms (name, FRN, LEI), not an allocation of bank codes, so it can never make a GB bank code authoritative: true. What it answers is a different question: is the institution behind this IBAN one the PRA lets take deposits?

Matched on LEI only, never on names. The list publishes an LEI per firm; the BIC directory carries one per entry. Name similarity is how one bank ends up wearing another's licence.
Scoped to the jurisdiction the authorisation covers. The branch section publishes the head office LEI — the parent abroad — which GLEIF maps to every BIC that parent owns worldwide. The block is therefore served only for GB BICs (and GI for the Gibraltar section); a bare LEI join would announce a UK deposit authorisation on a Frankfurt or Tokyo BIC.
Present on a match, absent otherwise — never authorised: false. The list covers deposit-taking alone and states in its own preamble that it does not supersede the Financial Services Register. A firm missing from it may be an investment firm, an e-money institution or a credit union.

Compliance signals

Signal	Source	Refresh
Bank-level sanctions	OFAC, EU, UN. OFAC SDN is the spine (its records carry BICs); the EU consolidated list and the UN Security Council list are best-effort and thin at bank-BIC level	weekly
Country lists	FATF grey/black lists (plenary-synced), EU high-risk third countries	on each plenary
SEPA reachability	EPC participant registers (SCT, SDD, SCT Inst)	weekly
VoP readiness	EPC Verification of Payee scheme register	weekly

FATF country-list data is used with the attribution its terms require: "FATF, High-Risk and Other Monitored Jurisdictions, www.fatf-gafi.org (accessed at each plenary sync)". The FATF permits commercial use of its data with credit; reuse of this API's FATF-derived fields carries the same attribution requirement onward.

Sanctions screening is bank-level (BIC8), not name-level — every compliance response repeats this in its own meta. It is not a regulated AML/CFT product.

The guard tests — why these claims stay true

Two failure modes broke this page's promises in the past: a served figure drifting above reality, and a coverage claim outliving its data. Both are now held by tests that run on every push and inside the weekly refresh workflow, before it may commit:

every dataset figure published on a served surface must be less than or equal to the live count;
no served surface may name a sanctions authority absent from the shipped database — the weekly refresh fails loudly rather than shipping a claim its own data no longer supports;
no served surface may promise account-level verification, in any of the three languages.

The month of the reference data consulted is returned in every response as bank_code_check.as_of.