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.

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.

Slovak data is reproduced under the NBS site terms (Podmienky používania, read 06/09/2026), which permit storing, reproducing and further using information published on the NBS website without prior consent, on two conditions: the Národná banka Slovenska must be named as the source, and the electronic file must not be altered in content or otherwise. Both travel with the answer — bank_code_check.register and bic.source name the NBS and the edition, as_of carries the register's own effective date, and provider names are served exactly as published, diacritics and inner spacing included, rather than transliterated or tidied. Reuse of the Slovak fields carries the same conditions onward.

We wrote to the NBS on 26/08/2026 to ask whether extracting fields from the file counts as altering it; there was no answer as of 06/09/2026. The Czech National Bank, whose terms carry a near-identical clause, answered on 27/08/2026 that it does not. If the NBS answers otherwise, this register comes back out. Like the Bulgarian one, it publishes no deletion flag and no successor code, so a Slovak not_in_register never comes with a re-papering hint.

A register that names holders without covering the space — San Marino

San Marino sits on its own because it breaks the rule the table above is built on. The Central Bank publishes the four banks it supervises; it does not publish the allocation of the ABI code space. San Marino also licenses payment and e-money institutions that are not banks (one holds a San Marino BIC and settles through EBA STEP2), and the official San Marino example IBAN carries an ABI absent from the page. So:

• a listed code answers verified with the institution the Central Bank names — and authoritative: false;
• a code absent from the list answers exactly what San Marino answered before this register existed: not_in_register with reason absent_from_reference_data. Never not_allocated, and never a reason to stop a payment.

One flag does go the other way: bic.basis is national_register and bic.authoritative is true, because the BIC printed beside a listed code is the Central Bank's own pairing. San Marino is where the two authority flags part company in the opposite direction from Switzerland.

The licence is unknown, and recorded as unknown. bcsm.sm publishes no terms of use — only a privacy policy and a copyright footer (checked 06/09/2026). Our position: four lines of routing data published by the supervisor to be used, served one record per request, credited Source: Central Bank of the Republic of San Marino, operating banks (read on …) by choice rather than by obligation. A letter to the Central Bank is queued; if it objects, the register is withdrawn. No clause is invented in the meantime.

Finland moved here on 16 September 2026, from the authoritative table above: a refusal built on an eleven-month-old transcription is not a reason to stop a payment. It goes back up once the list is re-read against a current publication.

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.

United Kingdom — the Financial Services Register, per firm

Source: FCA Financial Services Register, called one firm at a time through the FCA's Register API by GET /v1/gb/firm/:frn, under the Register Team's written acceptance of 7 September 2026 of exactly that usage. Nothing is imported: no list, no copy, no table of firms. Each answer names the source, carries its retrieval date and the FCA's own disclaimer, and is cached for one day at most — an expired copy is served only while the register itself is down, marked stale and never more than six hours past its day.

The four conditions the FCA attached are held in code: the published rate limits (one request in flight, a floor between calls, one honoured wait on a 429); no marketing use (a test fails the build if the CRM or the prospecting imports the register client); IBANforge as controller for what it receives (only the firm resource is called, never the register's individuals); and the FCA's exclusion of liability on every answer.

Compliance signals

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.

Related: What "verified" means · VoP readiness · Compliance check · Swiss QR-IBAN & QR-IID