Skip to content
IBANforge
← Back to blog

We asked the Bank of England before shipping their list. They said yes.

·4 min read

The United Kingdom has been the odd one out in our data sources inventory: the country with the heaviest real usage of this API, and the only major one where we served no authoritative institution data at all. The obvious source existed the whole time — the Bank of England publishes a monthly List of PRA-regulated Banks, a clean CSV with firm names, FRNs and LEIs. What did not exist was the right to use it: the Bank's website terms default to personal or internal, non-commercial use, and the list itself carries no licence.

Our rule for cases like this is written in the inventory: a supposed licence is worse than an unknown one. So we wrote to the Bank and described exactly what we wanted to do — use the monthly list as a reference source inside a commercial API, with attribution. The Engagement and Enquiries team answered within a day: no objection to the use we described, provided attribution to the Bank of England is maintained, together with the month of the list.

That condition is now part of the product.

What a GB lookup answers now

Every GET /v1/bic/:code on a UK BIC — and every validated GB IBAN whose bank resolves — carries a pra_authorisation block when the institution is on the current list. Captured from the shipped database:

"pra_authorisation": {
  "authorised": true,
  "firm_name": "HSBC UK Bank Plc",
  "frn": "765112",
  "section": "uk_incorporated",
  "basis": "lei",
  "source": "Bank of England, List of Banks",
  "list_month": "2026-08"
}

Four design decisions worth stating plainly:

  • The join is by LEI, never by name similarity. The list publishes each firm's Legal Entity Identifier, and so does our GLEIF data. Name matching across registers is how phantom matches are born; an identifier join either holds or it does not.
  • The block is bounded to GB and GI BICs. The list gives branch entries their head office LEI, and a head office LEI is attached to that group's BICs worldwide. Unbounded, the join would have claimed UK authorisation on more than a thousand non-UK BICs — we measured it on the real data before shipping, then bounded it.
  • It never answers authorised: false. The list's own preamble says it does not supersede the Financial Services Register. A firm's absence from our copy of a monthly snapshot is the absence of a claim, not a finding.
  • The attribution carries the month, and a test enforces it. "Bank of England (List of Banks, 2026-08)" appears in the footer, the docs and the machine-readable surfaces, with the month read from the loaded data. If a future refresh loads a new list and any surface still shows the old month, the build fails. The permission came with a condition; the condition is now infrastructure.

The list refreshes monthly through the same workflow as our other registers.

Also shipped this week

  • Swiss QR-IBAN and QR-IID, the reference page (EN/FR/DE). Switzerland runs a dedicated QR-IID range for QR-bill IBANs, and confusing it with the ordinary clearing number makes payments fail. The page covers both directions — including the question nobody else answers by API: which QR-IID does the bank behind this ordinary IBAN hold?
  • The 402 now shows the way in. Every payment-required response carries wallet_setup, a link to paying as an agent — the three-step path from no wallet to a first paid call. The response that says "payment required" should not leave to a search engine the question of how.
  • A new landing page. The pipeline told as a forge — heat, strike, quench, stamp, ship — in a scroll-driven film. Fully readable without JavaScript, because a good share of our readers are not humans.

One date to keep in view: the EPC Verification of Payee scheme rulebook v1.1 and its API specifications take effect on 20 September 2026 — the regulatory background is on /docs/vop.