Registry Data Provenance & Coverage
This page is the honest, audit-facing companion to Multi-Country Registry Services. That page describes how each connector works; this page answers the question a supervised MLRO or a buyer's auditor actually asks:
For each country, is the data coming from the official register, and how solid is the access path?
"We integrate 14 registries" is true as a count of connectors. It is not a statement that all 14 are official-API integrations of equal strength. Conflating those overstates coverage. This page states the difference explicitly, per country, and records which connectors were verified live against real companies.
:::info Governing principle In AML, provenance is the product. A registered address from a scraped aggregator is not the same evidence as one from the official register, and the difference is exactly what an auditor tests. This page never labels a source "official" when it is not. :::
Provenance tiers
| Tier | Meaning | Trust for a compliance decision |
|---|---|---|
| Tier 1 — Official API | The official national register or authority, accessed via a structured/JSON/dataset API. | Strongest. Primary-source, defensible under audit. |
| Tier 2 — Official, scraped | The official register, but with no API — accessed by HTML scraping. | Real primary source, but brittle: breaks when the site changes; needs monitoring. |
| Tier 3 — Third-party / aggregator | A commercial aggregator, mirror, or scraped commercial site — not the official register. | Weakest provenance. Acceptable as corroboration or fallback; disclose it, never present it as official. |
Coverage matrix
| Country | Source(s) | Tier | Auth | Data |
|---|---|---|---|---|
| 🇨🇭 CH | Zefix (zefix.admin.ch) | 1 | — | Identity, legal form |
| 🇨🇿 CZ | ARES (ares.gov.cz) | 1 | — | Identity, legal form |
| 🇨🇿 CZ | ISIR (isir.justice.cz) | 1 | — | Insolvency |
| 🇨🇿 CZ | CNB JERRS (jerrs.cnb.cz) | 2 | — | Regulated/licensed-entity status |
| 🇨🇿 CZ | Commercial Register (or.justice.cz) | 2 scrape | — | Financial-statement documents |
| 🇨🇿 CZ | UBO register (esm/issm.justice.cz) | 2 scrape | — | Beneficial owners |
| 🇩🇰 DK | cvrapi.dk (3rd-party mirror of CVR) | 3 | — | Identity |
| 🇪🇪 EE | Ariregister + avaandmed (rik.ee) | 1 | — | Identity + financials |
| 🇪🇪 EE | Inforegister (inforegister.ee) | 3 | — | Financials — fallback/corroboration only |
| 🇫🇮 FI | PRH / YTJ (avoindata.prh.fi) | 1 | — | Identity |
| 🇫🇷 FR | BODACC (bodacc-datadila) | 1 | — | Insolvency, filings, legal events |
| 🇫🇷 FR | INPI RNE (registre-national-entreprises.inpi.fr) | 1 | key | Identity, accounts |
| 🇫🇷 FR | INSEE SIRENE (api.insee.fr) | 1 | key | Identity |
| 🇬🇧 GB | Companies House (api.company-information.service.gov.uk) | 1 | key | Identity, officers, UBO (PSC) |
| 🇱🇹 LT | JAR / Registrų centras (get.data.gov.lt) | 1 | — | Identity |
| 🇳🇱 NL | KVK API (api.kvk.nl) + opendata | 1 | key | Identity |
| 🇳🇴 NO | Brønnøysund (data.brreg.no) + accounts | 1 | — | Identity + financials |
| 🇵🇱 PL | KRS (api-krs.ms.gov.pl) | 1 | — | Identity, officers |
| 🇷🇴 RO | ANAF (webservicesp.anaf.ro) | 1 | — | Identity, VAT, fiscal status, financials |
| 🇷🇴 RO | Directors — ListaFirme via BrightData | 3 scrape | token | Directors (no official ONRC connection) |
| 🇸🇰 SK | ORSR (orsr.sk) | 2 scrape | — | Identity, directors |
| 🇸🇰 SK | RUZ (registeruz.sk) | 1 | — | Financial statements |
Live verification
The following connectors were exercised against real companies on 2026-07-21, end-to-end
through the connector code (not just the raw endpoint), unless noted. The registry
integration test suite (test_country_registry*) reported 100 passed.
| Country | Connector | Test entity | Result |
|---|---|---|---|
| 🇷🇴 RO | ro_anaf_company_service.fetch_company | OMV Petrom SA (CUI 1590082) | ✅ Parsed model: name, reg-com J1997008302407, status active, CAEN, VAT-registered, address |
| 🇨🇿 CZ | ARES endpoint | Škoda Auto a.s. (IČO 00177041) | ✅ Name, IČO, legal form, seat |
| 🇬🇧 GB | Companies House (provisioned key) | Tesco PLC (00445790) | ✅ HTTP 200 — TESCO PLC, active, incorporated 1947-11-27 |
| 🇫🇷 FR | INSEE SIRENE (provisioned key) | Danone (SIREN 552032534) | ✅ success, statut 200 |
| 🇫🇷 FR | INPI RNE (provisioned user/pass) | Danone (SIREN 552032534) | ✅ success, no error |
| 🇳🇱 NL | KVK | — | ⚠️ Not runnable — kvk_api_key not provisioned |
API-key provisioning status
Four connectors are key-gated. A connector without its key exists in code but returns nothing at runtime — coverage claims must reflect the provisioned set, not the coded set.
| Connector | Key configured? | Live today? |
|---|---|---|
| 🇬🇧 Companies House | ✅ | ✅ |
| 🇫🇷 INSEE | ✅ | ✅ |
| 🇫🇷 INPI | ✅ (user/pass) | ✅ |
| 🇳🇱 KVK | ❌ empty | ❌ — provision the key to activate NL |
Honest limitations
:::warning Disclose these; do not claim around them
- Romania — no official ONRC/RECOM connection. Company identity, VAT, fiscal status and
financials come from ANAF (official), but directors come from ListaFirme.ro
scraped via BrightData — a commercial aggregator, gated behind a token. The file is named
ro_onrc_service.py, but it does not connect to ONRC. For the home market, this is the top gap to close. - Beneficial ownership (UBO) is thin. Dedicated UBO sources exist for GB (PSC register, Tier 1) and CZ (official UBO register, Tier 2 scraped) only. Elsewhere the system has directors/officers — which are not the same as beneficial owners.
- Denmark is third-party. DK identity comes from
cvrapi.dk, a private mirror of the official CVR — not the official Virk/CVR distribution API. - Czech register documents and Slovak ORSR are scraped (Tier 2). Real official sources, but brittle; they will break when those sites change and need active monitoring.
- Netherlands is coded but inactive until the KVK API key is provisioned. :::
Roadmap to all-Tier-1
- RO — connect official ONRC/RECOM for directors and beneficial owners; retire the
ListaFirme/BrightData director path (or demote it to explicit corroboration). Rename
ro_onrc_service.pyso it stops implying coverage it does not have. - NL — provision the KVK API key (connector is ready; this is a configuration task).
- DK — migrate to the official Virk/CVR distribution API and away from
cvrapi.dk. - CZ / SK — de-scrape
or.justice.czandorsr.skin favour of stable data feeds where they exist; add change-detection monitoring where they do not. - UBO expansion beyond GB and CZ, prioritised by the jurisdictions in the active pipeline.
:::note Where the resolution engine helps Tier 2 and Tier 3 sources are exactly the case a trust-scoring / provenance-resolution layer is built for — flag a non-official source, weight it below official ones, and require corroboration before it feeds a decision. See Atlas Adoption and Entity Resolution. :::
Related
- Multi-Country Registry Services — how each connector works
- Known Gaps & Roadmap — the product-wide honest register
- Belgian Data Layer — the KBO/NBB home-jurisdiction layer