Sources & provenance des données

Chaque réponse dit ce qu'elle vaut (bank_code_check.authoritative, register, as_of). Cette page est la version longue : quel jeu de référence répond pour quel pays, ce qu'il publie, sa fraîcheur, et — le point qui compte le plus — ce qu'une absence y signifie.

Registres nationaux — là où authoritative: true

Dans ces pays, le jeu de référence consulté est le registre national : not_in_register signifie que le code n'est pas attribué, une raison forte d'arrêter un paiement.

Ce que le registre publie sur l'établissement titulaire est servi dans bank_code_check.institution : nom, adresse du siège à la profondeur que le registre porte, LEI quand il existe. Les champs absents sont null, jamais devinés.

La Bulgarie est la plus récente de ces entrées et arrive avec le rafraîchissement mensuel : tant que la première exécution n'a pas chargé le registre, le pays retombe sur la carte composite et authoritative reste false — la réponse ne revendique jamais un registre qu'elle ne détient pas. Le repère fiable est bank_code_check.register, qui ne nomme la Bulgarian National Bank qu'une fois les lignes présentes.

Les données bulgares sont reproduites avec l'autorisation écrite de la Bulgarian National Bank (27/08/2026) au titre des conditions d'usage de son site, dont les conditions sont de citer la source et de ne pas altérer ni déformer les données. Les deux voyagent avec la réponse : bank_code_check.register nomme la Bulgarian National Bank, as_of porte la date d'effet du registre lui-même, et les noms d'établissements sont servis verbatim en cyrillique plutôt que translittérés. La réutilisation des champs bulgares emporte les mêmes conditions. Contrairement au fichier de la Bundesbank, ce registre ne publie ni marque de suppression ni code successeur — un prestataire fermé disparaît simplement, donc un not_in_register bulgare n'est jamais accompagné d'une piste de re-papérisation.

Les données slovaques sont reproduites au titre des conditions d'usage du site de la NBS (Podmienky používania, lues le 06/09/2026), qui autorisent à stocker, reproduire et réutiliser les informations publiées sur le site de la NBS sans accord préalable, à deux conditions : la Národná banka Slovenska doit être citée comme source, et le fichier électronique ne doit être modifié ni dans son contenu ni autrement. Les deux voyagent avec la réponse — bank_code_check.register et bic.source nomment la NBS et l'édition, as_of porte la date d'effet du registre lui-même, et les noms de prestataires sont servis exactement comme publiés, diacritiques et espacements internes compris, sans translittération ni nettoyage. La réutilisation des champs slovaques emporte les mêmes conditions.

Nous avons écrit à la NBS le 26/08/2026 pour demander si extraire des champs du fichier compte comme le modifier ; sans réponse au 06/09/2026. La Banque nationale tchèque, dont les conditions portent une clause quasi identique, a répondu le 27/08/2026 que non. Si la NBS répond l'inverse, ce registre est retiré. Comme le registre bulgare, il ne publie ni marque de suppression ni code successeur : un not_in_register slovaque n'est jamais accompagné d'une piste de re-papérisation.

Un registre qui nomme les titulaires sans couvrir l'espace — Saint-Marin

Saint-Marin est à part parce qu'il rompt la règle sur laquelle le tableau ci-dessus est bâti. La Banque centrale publie les quatre banques qu'elle supervise ; elle ne publie pas l'attribution de l'espace des codes ABI. Saint-Marin agrée aussi des prestataires de paiement et de monnaie électronique qui ne sont pas des banques (l'un détient un BIC saint-marinais et règle via EBA STEP2), et l'IBAN d'exemple officiel de Saint-Marin porte un code ABI absent de la page. Donc :

• un code listé répond verified avec l'établissement que la Banque centrale nomme — et authoritative: false ;
• un code absent de la liste répond exactement ce que Saint-Marin répondait avant ce registre : not_in_register avec la raison absent_from_reference_data. Jamais not_allocated, et jamais une raison d'arrêter un paiement.

Un drapeau va dans l'autre sens : bic.basis vaut national_register et bic.authoritative vaut true, car le BIC imprimé à côté d'un code listé est l'appariement de la Banque centrale elle-même. Saint-Marin est l'endroit où les deux drapeaux d'autorité se séparent, en sens inverse de la Suisse.

La licence est inconnue, et consignée comme inconnue. bcsm.sm ne publie aucune condition d'utilisation — seulement une politique de confidentialité et un copyright en pied de page (vérifié le 06/09/2026). Notre position : quatre lignes de données de routage publiées par le superviseur pour être utilisées, servies un enregistrement par requête, créditées Source: Central Bank of the Republic of San Marino, operating banks (read on …) par choix et non par obligation. Une lettre à la Banque centrale est en attente ; en cas d'objection, le registre est retiré. Aucune clause n'est inventée entre-temps.

La Finlande est descendue ici le 16 septembre 2026, depuis le tableau autoritatif ci-dessus : un refus fondé sur une transcription vieille de onze mois n'est pas une raison d'arrêter un paiement. Elle remontera quand la liste aura été relue sur une publication à jour.

La carte composite des BIC — là où authoritative: false

Partout ailleurs, les codes banque se résolvent contre notre carte composite : 121k+ entrées BIC assemblées depuis GLEIF (enrichi LEI), l'annuaire SWIFT public, SIX, EBA STEP2 SCT, la Bundesbank et la NBP. Un résultat nomme le détenteur du BIC correspondant — il ne prouve pas que l'établissement émet des IBAN, et une absence ne prouve rien du tout. Dans la trentaine de pays aux codes banque alphabétiques, un repli par préfixe peut renvoyer candidates > 1, et la réponse le signale comme indicatif.

Les Pays-Bas passent en plus par la liste des prestataires émetteurs d'IBAN de la Betaalvereniging (issuer.iban_issuer) : un code dont le détenteur n'y figure pas garde son nom mais perd son type bank — nommer le détenteur du BIC est un fait, en faire la banque de votre contrepartie serait une supposition.

Royaume-Uni — agrément PRA à recevoir des dépôts

Source : Bank of England (List of Banks, 2026-08), la liste mensuelle des établissements que la Prudential Regulation Authority agrée pour recevoir des dépôts. Utilisée avec la permission écrite de la Bank of England, dont la condition est l'attribution à la Bank et au mois de publication de la liste — c'est pourquoi chaque bloc pra_authorisation porte list_month, lu de la donnée chargée et jamais écrit à la main.

Elle ne figure délibérément pas dans le tableau des registres ci-dessus. C'est une liste d'établissements agréés (nom, FRN, LEI), pas une allocation de codes banque : elle ne peut donc jamais rendre un code banque GB authoritative: true. Elle répond à une autre question : l'établissement derrière cet IBAN est-il agréé par la PRA pour recevoir des dépôts ?

• Jointure par LEI uniquement, jamais par nom. La liste publie un LEI par établissement, l'annuaire BIC en porte un par entrée. La similarité de noms est exactement la façon dont une banque se retrouve à porter l'agrément d'une autre.
• Limitée à la juridiction que l'agrément couvre. La section des succursales publie le LEI du siège — la maison mère à l'étranger — que GLEIF rattache à tous les BIC détenus par cette entité dans le monde. Le bloc n'est donc servi que pour les BIC GB (et GI pour la section Gibraltar) ; une jointure LEI sans portée annoncerait un agrément britannique sur un BIC de Francfort ou de Tokyo.
• Présent en cas de correspondance, absent sinon — jamais authorised: false. La liste ne couvre que la réception de dépôts et dit elle-même en préambule qu'elle ne remplace pas le Financial Services Register. Un établissement qui n'y figure pas peut être une entreprise d'investissement, un établissement de monnaie électronique ou une credit union.

Royaume-Uni — le Financial Services Register, établissement par établissement

Source : FCA Financial Services Register, interrogé un établissement à la fois par l'API du registre de la FCA depuis GET /v1/gb/firm/:frn, sous l'acceptation écrite du Register Team du 7 septembre 2026 portant exactement sur cet usage. Rien n'est importé : ni liste, ni copie, ni table d'établissements. Chaque réponse nomme la source, porte sa date de récupération et l'exclusion de responsabilité de la FCA elle-même, et n'est mise en cache qu'un jour au plus — une copie expirée n'est servie que pendant une panne du registre, marquée stale et jamais plus de six heures après son jour.

Les quatre conditions posées par la FCA sont tenues dans le code : les limites de débit publiées (une requête en vol, un plancher entre deux appels, une seule attente honorée sur un 429) ; aucun usage marketing (un test fait échouer la suite si le CRM ou la prospection importe le client du registre) ; IBANforge responsable de traitement pour ce qu'il reçoit (seule la ressource « établissement » est appelée, jamais les individus du registre) ; et l'exclusion de responsabilité de la FCA sur chaque réponse.

Signaux de conformité

Les listes de pays du GAFI sont utilisées avec l'attribution que ses conditions exigent : « FATF, High-Risk and Other Monitored Jurisdictions, www.fatf-gafi.org (accessed at each plenary sync) ». Le GAFI permet l'usage commercial de ses données avec crédit ; toute réutilisation des champs GAFI de cette API doit porter la même exigence d'attribution.

Le screening sanctions est au niveau banque (BIC8), pas au niveau des noms — chaque réponse compliance le répète dans son propre meta. Ce n'est pas un produit AML/CFT réglementé.

Les tests-gardes — pourquoi ces affirmations restent vraies

Deux modes de défaillance ont cassé les promesses de cette page par le passé : un chiffre servi qui dérive au-dessus de la réalité, et une affirmation de couverture qui survit à sa donnée. Les deux sont désormais tenus par des tests qui tournent à chaque push et dans le workflow hebdomadaire de rafraîchissement, avant qu'il ait le droit de committer :

• tout chiffre de volumétrie publié sur une surface servie doit être inférieur ou égal au compte réel ;
• aucune surface servie ne peut nommer une autorité de sanctions absente de la base livrée — le rafraîchissement hebdomadaire échoue bruyamment plutôt que de servir une affirmation que sa propre donnée ne soutient plus ;
• aucune surface servie ne peut promettre une vérification au niveau du compte, dans aucune des trois langues.

Le mois des données de référence consultées est renvoyé dans chaque réponse via bank_code_check.as_of.

Voir aussi : Ce que « verified » veut dire · Préparation VoP · Contrôle conformité · QR-IBAN suisse & QR-IID