DEV Community: OpenRegistry

Live UK director-change detection on Companies House: 4 real cases from this month

OpenRegistry — Mon, 11 May 2026 04:24:54 +0000

Most KYB pipelines I've seen treat the UK registry like a monthly snapshot. Aggregators such as OpenCorporates ingest the Companies House bulk feed once a day (or weekly, for some non-UK jurisdictions), build their own index, and resell. That's fine for company name search and stable fields. It breaks when a director leaves or a corporate restructuring triggers a PSC change, because the buyer of that snapshot is looking at last week's truth.

Here are four director changes that happened on Companies House over the past 30 days, with the actual filing-to-detection lag, queried live through an MCP server I run at openregistry.sophymarine.com/mcp.

Case 1: BP plc, director resignation, 5 days ago

On 6 May 2026, Thierry Dominique Gerard Garnier stepped down from the board of BP plc (Companies House number 00445790). The TM01 termination form was filed the next day, 7 May. Querying list_filings against the MCP server today (11 May) shows it as the most recent entry:

{
  "filing_date": "2026-05-07",
  "category": "officers",
  "description": "termination-director",
  "officer_name": "Thierry Dominique Gerard Garnier",
  "termination_date": "2026-05-06"
}

File-to-detect lag: zero. The data is the registry's response, returned in 80 ms. No nightly ingest. No snapshot cache.

Case 2: Unilever plc, three directors out on the same day

On 23 April 2026, three directors left the board of Unilever plc (00102498) on the same day: Karen Ann Richardson, Simon Peter Henry, and Melody Boone Meyer. Three separate TM01s were filed on 27 April, 4 days after the actual termination. Companies House had them by 27 April. Anyone querying live had access to all three within minutes of CH receiving the forms.

If you were holding a 30-day OpenCorporates snapshot from say 20 April, you would have shown those three as active directors of a FTSE 100 company for ~14 days after they had left. For a KYC desk approving counterparty risk on Unilever, that's a window where every report cites stale governance.

Case 3: Wise plc, capital change + new director appointment

Wise plc (13211214) had two events in March 2026:

2 March: Mr Scott Anthony Hill appointed director (AP01)
25 March: capital alteration / share redemption (SH02)

Filings dates were 12 March and 7 May respectively, so the appointment was visible within 10 days, and the capital change within 6 weeks. The gap between action date and filing date is the legal filing window, not the registry's delay. CH publishes within hours of receiving the form.

Case 4: Stripe Payments UK Ltd, corporate director change

Stripe Payments UK Ltd (08480771) had a corporate director change involving Stripe, Inc. on 3 January 2026, filed on 14 January. A natural-person appointment followed on 10 February (Ms Helen Claire McGrath), filed on 17 February. Both events were visible through live registry queries within a week, while many ingestion-based services were still serving December data.

How to run this yourself

The MCP server gives you 27 jurisdictions. For UK Companies House specifically, the relevant tool is list_filings with jurisdiction: "GB" and a company_id. The response carries everything Companies House returns: the TM01, AP01, SH01, SH02, CS01 form types, the officer or PSC names, the action date versus the filing date, and a document_id you can pass to fetch_document to retrieve the actual PDF.

Here's the discovery flow for Claude Desktop:

{
  "mcpServers": {
    "openregistry": {
      "url": "https://openregistry.sophymarine.com/mcp"
    }
  }
}

Paste that into Claude Desktop's developer config, restart, and prompt: "What's the most recent director change at Unilever plc?" The agent calls search_companies, then list_filings, then summarizes. Free anonymous tier; no API key.

For non-Claude clients (Cursor, Cline, Goose, Zed, Gemini CLI), point them at the same URL. The transport is MCP Streamable HTTP with OAuth 2.1 discovery at the standard /.well-known/oauth-authorization-server.

Where this sits in the KYB stack

If you currently run a Companies House data pipeline through a static-snapshot vendor, here are the trade-offs of swapping in a live-query model:

Freshness: every query goes to CH directly. Files appear when CH publishes, not on the vendor's ingest schedule.
Cost: the free tier is 30 requests per minute. Pro is $9/month at 180 rpm; Max is $29/month at 900 rpm. Enterprise is custom.
Coverage: 27 jurisdictions today including UK, Germany, France, Italy, Spain, Poland, Cyprus, Liechtenstein, Cayman, Korea OpenDART, plus 17 others. The UK jurisdiction reference and the docs index describe what each registry exposes.
Document access: fetch_document returns the upstream PDF or iXBRL bytes. The statutory record is the answer, not a parsed approximation.

A more detailed look at the UK API specifically, including post-ECCTA changes and what the API now returns versus what it withdrew, is in this earlier post on Companies House post-ECCTA reality.

For teams evaluating an OpenCorporates alternative that runs live against the source registries, the side-by-side comparison is at openregistry.sophymarine.com/vs/opencorporates. Same data sources, different freshness model.

What this doesn't replace

Live registry queries cover the registry. They don't cover sanctions lists, court records, beneficial-owner registries that require AML-gated access (the EU CJEU rulings on these are real), adverse-media screening, or proprietary subscription feeds. If your stack needs all of that bundled with one contract, you're still looking at Sayari, Kharon, or Castellum.AI.

For teams just looking for an OpenCorporates alternative that returns the registry's own response on every call, with the underlying document bytes available, the live MCP path covers it, and you can run it free.

If you've used live registry queries on other jurisdictions and seen edge cases where the public API doesn't cover something a commercial product does, I'd be interested. Comments below.

Three failure modes of AI agents on company-registry data

OpenRegistry — Thu, 07 May 2026 12:22:29 +0000

I've spent the last six weeks watching AI agents try to do KYB and corporate due-diligence work over MCP. The agents themselves are mostly fine. The data layer underneath them is the part that breaks. Three failure modes show up in almost every workflow, and most teams don't notice until a real review surfaces a bad result.

1. The aggregator-snapshot lag

The default architecture for a "company data API" is: a vendor (OpenCorporates, Sayari, Bureau van Dijk / Moody's Orbis, Kyckr, Refinitiv, Middesk) ingests the upstream registry on a refresh cycle, normalises everything into their schema, and resells the snapshot. Most snapshots refresh every 6–24 hours.

For a static dossier, that's fine. For an agent making a real-time decision, it's a hidden time bomb. UK Companies House publishes administration filings the same day they're submitted. A counterparty that filed Notice of Appointment of Administrators yesterday afternoon will not appear as dissolved in BvD's snapshot until tomorrow morning at the earliest, and often longer. If your agent's KYB step looks "active" because it's reading a snapshot that was correct twelve hours ago, the audit trail will record an active counterparty even though the counterparty was insolvent at the time of the call.

The fix isn't faster snapshots. It's calling the upstream registry directly. The trade-off is real: upstream APIs are slower, less normalised, sometimes flaky. But for any decision the agent might be cited on later, the upstream call is the only defensible source.

2. Schema normalisation that hides jurisdictional truth

Every registry has its own concept of who controls a company. UK Companies House publishes Persons of Significant Control (PSC), a binary "yes / no" flag with statutory thresholds. Germany's Handelsregister lists Geschäftsführer (managing directors) and shareholders separately, with shareholding written in the deed of incorporation. Korea's OpenDART exposes major shareholders with quarterly disclosure cadence. Cayman's CIMA and Companies Registry expose controlling parties only via TCSP-mediated requests for licensed entities.

Aggregators flatten all of this into a single "Beneficial Owners" table. The flattening is what kills you. A 25.1% shareholder in a German GmbH is not a PSC under UK rules but is reportable under German rules; if your agent receives a normalised "is_beneficial_owner = false" because the aggregator picked one jurisdiction's threshold, you've lost the actual answer. Worse, aggregators rarely flag which registry they decided not to surface.

The pattern that works: keep the upstream field names, return the upstream values unchanged, and let the agent reason about jurisdiction. If your tool exposes psc_data for UK and gesellschafter_data for DE, the agent figures out the difference. If you exposed beneficial_owner and lost the qualifier, the agent can't recover it.

3. Cross-border fan-out that doesn't fan out

The hardest problem in real KYB is following an ownership chain across registries. Iceland Foods Ltd is owned by WD FF MIDCO LIMITED is owned by ICELAND VLNCO LIMITED is owned by LANNIS LIMITED, which finally lists eight named individuals as PSCs. Three of those layers are UK Companies House, but the same shape appears with German GmbH owners of UK Ltd subsidiaries, Cayman holdcos owning Hong Kong opcos, Polish KRS spółka z o.o. owners of Czech ARES s.r.o.

If your data layer is one country at a time, the agent has to do registry routing itself. That means it has to know that "WD FF MIDCO LIMITED" is a UK company name, parse the company number into a jurisdiction code, switch which API to call, and stitch results across calls. Every one of those steps is a place where the LLM hallucinates a jurisdiction or fabricates a company number.

The solution is to expose a single tool surface that takes (jurisdiction, company_id) as parameters, and to make the agent's job purely sequential: read PSC, find a corporate PSC, recurse. The cross-border step then becomes "swap the jurisdiction parameter," not "change the entire vendor API."

What this points to

If you're building anything that uses live company data through an LLM, the data layer questions to ask are:

Are tool responses byte-identical to the upstream registry, or is your vendor normalising fields you can't recover?
Is the freshness real-time, or is your tool reading an N-hour-old snapshot?
Can the same tool handle a UK PSC walk and a German Handelsregister walk and a Korean DART walk without rewriting the agent prompt?

We've been building OpenRegistry as a Streamable-HTTP MCP server that makes all three default behaviours: live calls to 27 government registries, raw upstream field names, single tool surface for cross-border fan-out. The free anonymous tier works in Claude Desktop, Cursor, Cline, Goose, Zed and the Gemini CLI with one config line. But the underlying point isn't the tool. It's that aggregator-shaped APIs are the wrong architecture for agentic workflows on regulated data, and the failure modes show up in production, not in benchmarks.

Spain BORME — post-RETIR / post-CJEU API guide

OpenRegistry — Wed, 06 May 2026 15:01:24 +0000

Spain BORME — post-RETIR / post-CJEU API guide

Spain is a useful registry case because the free surface is not a company-of-record database at all; it is the BORME publications gazette. That matters right now because the country’s open surface is still shaped by the post-RETIR world on the one hand and by the CJEU’s post-C-37/20 ownership-visibility limits on the other. The concrete fact readers can verify in seconds is simple: there is no free public company ID like a CIF/NIF on the BORME surface. The registry indexes by exact denominación social instead.

What the registry actually exposes

OpenRegistry’s ES adapter is built around the publication stream, not a canonical company profile. The live surface covers:

search_companies — title/full-text search over BORME announcements, deduped by denominación social.
list_filings — the strongest free endpoint; returns one filing row per Section II publication for a given exact company name.
get_document_metadata — format/size/page metadata for a specific publication.
fetch_document — raw PDF by default, or source XML when available.
list_actos_inscritos — a Section II/acts view for companies.
get_officers — a delta stream of officer-related acto paragraphs.
get_shareholders — a delta stream of shareholder-related acto paragraphs.

The support matrix from the live list_jurisdictions call shows Spain as real_time=true, with no caching beyond a short search-result / XML dedupe window. Every call still hits boe.es live. The public surface is intentionally thin: get_company_profile, get_persons_with_significant_control, get_charges, get_officer_appointments, and search_officers are blocked on the free path.

Auth is simple: there is none on the free tier. The response format is unified, but the jurisdiction-specific payload is where the useful data lives. For filings you get PDF/XML/HTML URLs plus the announcement text fields; for officer/shareholder deltas you get raw acto text, page numbers, and publication metadata.

What's paywalled, gated, or restricted

Spain is unusually strict about where the useful company data lives:

No free company-of-record profile endpoint.
No free PSC / beneficial ownership REST API; this surface is AML-gated.
No free cross-company officer-name index.
No free charges endpoint on the company surface; those rights sit in separate registries.
The registry’s status is often unknown because BORME is a gazette, not a live status feed.

The practical consequence is that the free path is publication-first. If you want the authoritative document trail, you query filings and then read the PDF/XML yourself.

Which OpenRegistry tools cover which surface

Tool	Status	Notes
search_companies	✅ live	title match on BORME announcements
list_filings	✅ live	exact denominación, Section II rows
get_document_metadata	✅ live	PDF/XML metadata for a publication
fetch_document	✅ live	raw PDF or source XML
list_actos_inscritos	✅ live	Section II acts stream
get_officers	✅ live	officer-related delta paragraphs
get_shareholders	✅ live	shareholder-related delta paragraphs
get_company_profile	⛔ 501	no free profile API
get_persons_with_significant_control	⛔ 501	AML-gated BO register
get_charges	⛔ 501	separate paid registries
get_officer_appointments	⛔ 501	no free cross-company index
search_officers	⛔ 501	no free cross-company index

Country-specific quirks

Use the exact denominación social. INDITEX, S.A. is the identifier shape here, not the fiscal number. Matching is tolerant, but the company name still matters.
Most statuses are unknown. If you are used to Companies House or KVK, do not expect a clean active/inactive profile. On BORME, the filing trail is the source of truth.
Actos are not the same as person directories. get_officers returns the relevant paragraphs, but the person names and roles are embedded in raw text and must be parsed.
Shareholder visibility is partial. You can see delta events, not a complete shareholder book for most companies.
get_company_profile will not save you. The free surface intentionally pushes you back to filings.

A complete worked example

Take INDITEX, S.A.. A typical workflow is:

Search the company name.
Pull the filing list.
Fetch the publication document for the announcement you care about.

Example shape:

{
  "tool": "list_filings",
  "jurisdiction": "ES",
  "company_id": "INDITEX, S.A.",
  "limit": 1
}

That returns a filing envelope with a BORME publication code, publication date, and direct document URLs. If you need the underlying notice:

{
  "tool": "fetch_document",
  "jurisdiction": "ES",
  "document_id": "BORME-C-2026-1234",
  "format": "pdf"
}

The key point is that the registry gives you the source document, not a synthetic summary. For Spanish workflows, that is usually enough: read the notice, confirm the act, then use the same denominación for the next query.

Connecting an MCP client

Claude Desktop / Cursor / Cline can all point at the same server:

mcp endpoint: https://openregistry.sophymarine.com/mcp
Claude Desktop: add custom connector with that URL
Cursor / Cline: add the endpoint in MCP settings
No API key required on the free tier

CTA

If you want to test this without signing up, use the free anonymous tier and query the example company profile path for the same name you saw above. The public web profile path for INDITEX, S.A. is /company/es/INDITEX%2C%20S.A. and the live MCP endpoint is enough to get you from search to filing without a login.

OpenRegistry's full coverage

OpenRegistry is a free remote MCP server giving AI agents real-time access to company-registry data from 30 national governments. This article focused on Spain; the same toolkit covers:

🇬🇧 UK Companies House · 🇫🇷 INSEE Sirene + INPI RNE · 🇩🇪 Handelsregister · 🇮🇹 Registro Imprese (BRIS) · 🇪🇸 BORME · 🇳🇱 KVK · 🇧🇪 KBO · 🇨🇭 Zefix · 🇳🇴 Brreg · 🇫🇮 PRH · 🇮🇪 CRO · 🇵🇱 KRS · 🇨🇿 ARES · 🇮🇸 RSK · 🇮🇲 IoM Registry · 🇨🇾 DRCOR · 🇲🇨 RCI · 🇱🇮 Liechtenstein HR · 🇰🇷 OPENDART · 🇭🇰 Companies Registry · 🇹🇼 GCIS · 🇲🇾 SSM · 🇮🇩 Ditjen AHU · 🇦🇺 ABR · 🇳🇿 Companies Office · 🇨🇦 Corporations Canada (+ BC + NWT) · 🇮🇳 MCA · 🇺🇸 NY State · 🇺🇸 California · 🇲🇽 PSM · 🇰🇾 CIMA · 🇷🇺 ЕГРЮЛ

→ Hosted MCP endpoint: https://openregistry.sophymarine.com/mcp
→ Docs: https://openregistry.sophymarine.com/docs/
→ Free anonymous tier: 20 req/min, all tools, every jurisdiction.

Made by Sophymarine.

Italy Registro delle imprese — post-Consiglio di Stato 2024 API guide

OpenRegistry — Wed, 06 May 2026 03:56:39 +0000

$(sed '1,2d' /home/richard/.openclaw/workspace/it_article.md)

OpenCorporates alternatives compared

OpenRegistry — Thu, 30 Apr 2026 04:34:59 +0000

OpenCorporates alternatives compared

Anyone evaluating OpenCorporates as a company-data source tends to hit the same handful of limits within a couple of weeks: data freshness, missing share register data, and patchy coverage of non-Anglophone registries. The table below compares the alternatives that come up most often in due diligence and KYC work.

All facts checked against the products' own pricing pages, API docs, and platform pages. Where the source is unclear, the cell says so.

Feature comparison

	OpenCorporates	OpenRegistry	Sayari	BvD / Orbis	D&B Direct+	GLEIF	National registry sites
Refresh model	ingested, varies per registry	live call to gov registry on every query	full rebuild every 2 weeks + daily delta	ingested from 170+ providers	configurable INTRA_DAY → MONTHLY, ~5M updates/day	3× daily Golden Copy + delta	live
Directors / officers	✓	✓	✓	✓	✓	✗ (entity only, no people)	✓
Shareholders (as a separate filing from directors)	✗	✓ (`get_shareholders`)	✓ (ownership graph)	✓	partial	✗	varies by country
Persons with significant control / UBO	partial (UK PSC mostly)	✓ (`get_persons_with_significant_control`)	✓	✓	partial	parent / ultimate parent only	varies
Mortgages and charges	✗	✓ (`get_charges`)	✗	✗	✗	✗	varies
Raw statutory filings as bytes (PDF / XBRL / iXBRL)	filings list only	✓ (`fetch_document` returns upstream bytes)	✗	✗	✗	✗	✓ on most
Native XBRL / iXBRL financials surfaced	✗	✓ on FI, KR (XBRL) and GB (iXBRL)	✗	✗ (extracted to proprietary schema)	✗	✗	varies
Cross-jurisdiction name search in one call	✓	✓ (with per-tier fan-out cap)	✓	✓	✓	✓	✗ (one country at a time)
Direct gov registry URL preserved on every record	partial	✓	✗	✗	✗	✓ (RA link)	n/a (is the source)
MCP server for AI agents	✗	✓ (public, free)	beta (enterprise contract required)	✗	✗	✗	✗
Free anonymous access (no signup)	✓ (web only, rate-limited)	✓ (API + web, 20 req/min)	✗ (demo request only)	✗	✗	✓	usually
Self-serve API for individuals	✗ (paid tier from £2,250/yr)	✓ (anonymous tier free)	✗ (enterprise only)	✗ (enterprise only)	✗ (contracted)	✓ (free)	varies
Entry-tier price	£2,250 / yr (Essentials)	$0 anon, $9 / mo Pro	enterprise (no published price)	enterprise	enterprise	free	mostly free
Pricing published on website	✓	✓	✗	✗	✗	✓	n/a
Jurisdictions covered	140+	27	250+	global (no number published)	220+	232 (LEI registrants only)	1 each
Entity count	~200M	live proxy (no ingested count)	~1.5B	~380M (Orbis)	~500M	~3M active LEIs	varies

What the table says about OpenRegistry

The OpenRegistry column is the only one that combines all of the following:

A live call to the underlying government registry on every single query, so a director, shareholder, charge, or filing recorded today is visible the same day.
Directors, shareholders, persons with significant control, and charges as four separate, machine-readable tools, because in most jurisdictions these correspond to four different filings and collapsing them loses information.
Document-level access: fetch_document returns the upstream PDF, iXBRL, or XBRL bytes, so audit and compliance work can cite the statutory record directly.
Native XBRL financials on Finland (PRH), Korea (DART), and the UK (iXBRL), without re-rendering or re-encoding.
A free public MCP transport. Sayari has an MCP product as well, but it is in beta and gated behind an enterprise contract; OpenRegistry's MCP endpoint is open at /mcp with no signup.
Self-serve API on a free anonymous tier (20 req/min). Every other paid product on this list starts at four-figure annual contracts or enterprise pricing.

The trade-off is breadth. OpenRegistry covers 27 national registries today, against the ~145 of OpenCorporates and the larger ingest piles inside the commercial analyst suites. For workflows where the binding constraint is freshness, share-register / UBO access, or document-level provenance rather than coverage of every jurisdiction on Earth, that trade-off usually goes the other way.

UK Companies House — post-ECCTA reality / API guide

OpenRegistry — Wed, 29 Apr 2026 15:01:20 +0000

UK Companies House — post-ECCTA reality / API guide

The UK matters because Companies House is still the cleanest high-volume live registry surface in OpenRegistry, and it is now changing under the post-ECCTA regime rather than the old “just a lookup page” model. For integrators, the concrete fact to anchor on is simple: company numbers are still 8 characters, and the adapter auto-pads short England/Wales numbers like 6 to 00000006.

What the registry actually exposes

OpenRegistry’s UK adapter is the reference implementation and the most complete surface in the server. The live coverage currently includes:

search_companies
get_company_profile
list_filings
get_financials
get_shareholders
get_officers
get_persons_with_significant_control
get_charges
get_officer_appointments
search_officers
get_document_metadata
fetch_document

Auth-wise, this is the public hosted MCP endpoint and does not require a registry account. The upstream adapter is live, and the server notes a 600 requests / 5 minutes / operator key ceiling. There is also a small in-adapter dedup cache for 10 seconds inside one AI turn; if you need absolute freshness, pass fresh=true.

Response formats are close to upstream Companies House data: structured JSON for profiles, officers, PSCs, filings, charges, and financials; documents are fetched through metadata then download. The key thing for builders is that the data comes through unmodified and source-linked, rather than being normalized into a synthetic company graph.

What is paywalled, gated, or restricted

The public surface is broad, but it is not everything.

Some identity and privacy-sensitive fields are redacted or only partially exposed. Officer dates of birth are month/year only. Home addresses are not surfaced; only service or correspondence-style addresses appear. The public adapter also does not expose identity-verification status.

For UK users, the registry itself is still subject to the usual Companies House product boundaries: some document flows are slower than the metadata surface, and document retrieval should be treated as a separate step from profile lookup. The adapter does not invent missing fields when upstream omits them.

Which OpenRegistry tools cover which surface

For the UK, the coverage matrix is unusually complete:

Tool	Status	Notes
search_companies	✅ live	name search and company-number search
get_company_profile	✅ live	statutory profile, status, addresses, accounts, confirmation
list_filings	✅ live	filing history with category, description, date
get_financials	✅ live	filed accounts surface
get_shareholders	✅ live	shareholding surface where available
get_officers	✅ live	current and historic officers
get_persons_with_significant_control	✅ live	PSC entries and control types
get_charges	✅ live	registered charges and satisfaction status
get_officer_appointments	✅ live	cross-company appointment history
search_officers	✅ live	officer-name discovery
get_document_metadata	✅ live	metadata before document fetch
fetch_document	✅ live	document download

This matters because the UK is the baseline where “production-grade” means the whole workflow, not just lookup-by-name.

Country-specific quirks

Three UK quirks matter in practice:

ID shape is not uniform across the four legal geographies. England/Wales use 8 digits; Scotland uses SC plus 6 digits; Northern Ireland uses NI plus 6 digits; LLPs use OC plus 6 digits. The adapter accepts short England/Wales forms and pads them.
Company status is not a single business-friendly value. Native states include active, dissolved, liquidation, receivership, administration, voluntary-arrangement, insolvency-proceedings, open, closed, removed, and converted-closed. Treat mapping carefully.
Officers and PSCs are intentionally incomplete compared with private databases. The public dataset is still useful, but it is not a full-person dossier. That is a feature, not a bug.

Complete worked example

Take Monzo Bank Limited, company number 09446231.

A profile lookup returns the live statutory record:

company name: MONZO BANK LIMITED
status: active
incorporation date: 2015-02-18
registered office: Broadwalk House, 5 Appold Street, London, EC2A 2AG
previous name: FOCUS FS LIMITED
SIC codes: 64191, 64999
last accounts made up to: 2025-03-31
next accounts due: 2026-12-31

That is enough for a downstream workflow to decide whether to inspect officers, charges, filings, or financial statements next. For a live agent, the same sequence can be chained in one turn: search, profile, filings, PSCs, then document fetch if the filing text is needed.

Connecting an MCP client

Add the server URL to your client as a remote MCP endpoint:

{
  "mcpServers": {
    "openregistry": {
      "url": "https://openregistry.sophymarine.com/mcp"
    }
  }
}

That works in Claude Desktop, Cursor, and Cline with the usual remote-MCP flow.

CTA

If you need an anonymous first pass, this is a good place to start: search Monzo as a public profile, verify the company number, then branch into filings or officers without signing up anywhere. The live profile for the example company is at /company/GB/09446231 on the OpenRegistry site.

OpenRegistry's full coverage

OpenRegistry is a free remote MCP server giving AI agents real-time access to company-registry data from 29 national governments. This article focused on the UK; the same toolkit covers:

🇬🇧 UK Companies House · 🇮🇪 CRO · 🇦🇺 ABR · 🇨🇭 Zefix · 🇳🇴 Brreg · 🇫🇷 INSEE Sirene + RNE · 🇫🇮 PRH · 🇨🇿 ARES · 🇵🇱 KRS · 🇹🇼 GCIS · 🇨🇦 Corporations Canada · 🇨🇦 BC · 🇨🇦 NWT · 🇧🇪 KBO · 🇮🇲 IoM Registry · 🇮🇸 RSK · 🇱🇮 Liechtenstein HR · 🇩🇪 Handelsregister · 🇳🇿 Companies Office · 🇲🇨 RCI · 🇮🇹 Registro Imprese (BRIS) · 🇭🇰 Companies Registry · 🇲🇾 SSM · 🇰🇷 OPENDART · 🇨🇾 DRCOR · 🇰🇾 CIMA · 🇲🇽 PSM · 🇷🇺 ЕГРЮЛ

→ Hosted MCP endpoint: https://openregistry.sophymarine.com/mcp
→ Docs: https://openregistry.sophymarine.com/docs/
→ Free anonymous tier: 20 req/min, all tools, every jurisdiction.

Made by Sophymarine.

The five-call cross-border KYB workflow — walking a UBO chain across jurisdictions in a single prompt

OpenRegistry — Wed, 29 Apr 2026 09:04:39 +0000

The five-call cross-border KYB workflow — walking a UBO chain across jurisdictions in a single prompt

KYB ("Know Your Business") used to mean "pull a company report and check the directors." That stopped being enough around the time the FATF revised Recommendation 24 in March 2022 and AMLD5 transposition deadlines started biting. A modern KYB review for a counterparty of any meaningful size has to:

Identify the legal entity in the jurisdiction it claims to be incorporated in,
Identify everyone who owns more than 25 % (or controls via voting / appointment / contract),
Walk through any corporate layer above that — because step 2 will almost always return another company rather than a human,
Repeat until you reach a natural person, a listed issuer, a state, or a bona-fide statutory exception,
Cite the registry of record at every hop so the audit trail survives a regulatory review.

That last point is what breaks every "we have a company-data API" SaaS: the moment the counterparty is in a different jurisdiction from your aggregator's strongest coverage, you start joining records the aggregator opined about rather than records the government asserted. When the FCA / FinCEN / BaFin auditor asks "where did this PSC entry come from?" the answer needs to be a registry URL, not "BvD says".

The rest of this post walks through the canonical five-call cross-border KYB workflow, what it looks like in practice on a real UK→Holdco chain, and the eight EU registers that will currently — post-CJEU C-37/20 — return a structured 501 regardless of which vendor you query.

This is the workflow OpenRegistry was built to serve: 27 national company registries behind one MCP endpoint, byte-identical responses, source-linked, no aggregator layer between the AI agent and the statutory record.

Why "look up the company in country X" doesn't generalize

Every KYB SaaS does step 1 reasonably well in its strongest jurisdictions. Steps 2 → 5 are where the wheels come off:

Step 2 (PSC / UBO layer) — Every member state of the EU plus the UK has its own legal definition of "beneficial owner," its own threshold (25 % is most common but Cyprus uses 10 %, Estonia uses "any control"), its own filing window, and its own access regime. Post CJEU C-37/20 (2022), eight EU UBO registers became AML-obliged-only — meaning no commercial vendor can legally republish them.
Step 3 (corporate-layer recursion) — When the PSC of a UK Ltd is a Luxembourg SARL, you have left the British Companies House schema and entered the Luxembourg RCS schema. These have different identifier formats, different officer-role enumerations, different statuses. Aggregators paper over this with their own canonical schema; that paper covers the gap that gets you in trouble at audit.
Step 4 (terminating in a natural person) — In the UK 80 %+ of PSC chains terminate in 1-2 hops. In Luxembourg, Cayman, BVI, Jersey, Liechtenstein it's routinely 4-6 hops, sometimes through a trust that legally has no UBO at all.
Step 5 (citing the registry) — Aggregators almost universally strip the upstream URL because it's how they justify their licensing. If you can't link to https://find-and-update.company-information.service.gov.uk/company/01107406/persons-with-significant-control on your KYB report, your audit trail is "we trust our vendor."

The five-call workflow below assumes you have direct, byte-identical access to the registry of record at every step. With that assumption, the workflow becomes mechanical and the AI agent can run it without supervision.

The canonical five-call workflow

This is the prompt-time tool sequence an AI agent runs against the OpenRegistry MCP endpoint for every cross-border KYB:

1. search_companies({ jurisdiction, query, limit: 5 })
   → resolve the legal name to a registry-issued company_id
2. get_company_profile({ jurisdiction, company_id })
   → registered office, status, incorporation date, officers (where included)
3. get_persons_with_significant_control({ jurisdiction, company_id })
   → the PSC / UBO / beneficial-owner layer, with type=individual|corporate|trust
4. for each PSC of type 'corporate' or 'trust':
   → recurse from step 1 with the PSC's jurisdiction + name (or registry id if printed)
5. fetch_document({ document_id })
   → the statutory filing that backs the assertion (Confirmation Statement,
     Comptes annuels, Jahresabschluss, opinion of independent registrar, etc.)

That's the full agent loop. Five calls, recursing on step 4 until the chain terminates in a natural person, a state actor, a listed issuer, or a structured 501 (the statutory wall — more on those below).

The cross-border part is what eats most KYB SaaS implementations: each recursion of step 4 hops to a different national registry with a different schema, different identifier format, different language. Hand-stitching this in a SaaS UI takes an analyst 30-90 minutes per counterparty. With a unified MCP gateway and a halfway-decent AI client, the same chain runs in ~30 seconds.

Worked example — Iceland Foods Ltd → Iceland Topco Limited → individuals

Let's run it on a real, public, legally-trivial UK chain. Iceland Foods Ltd is a UK private company; its PSCs trace through three corporate layers before reaching individuals. The full walked example with raw JSON is on the OpenRegistry Iceland Foods cross-border chain walk — what follows is the abridged structural view.

Step 1 — resolve the legal name

{
  "tool": "search_companies",
  "args": { "jurisdiction": "GB", "query": "Iceland Foods Ltd", "limit": 3 }
}

The first hit returns company_id: "01107406", status active, incorporated 1973-04-26. We have a stable identifier.

Step 2 — pull the profile

{
  "tool": "get_company_profile",
  "args": { "jurisdiction": "GB", "company_id": "01107406" }
}

This returns the full Companies House profile — registered office, accounts category (group, full), confirmation-statement date, SIC codes, and the officers array. The schema is exactly Companies House's; nothing is renamed or merged.

Step 3 — pull the PSC layer

{
  "tool": "get_persons_with_significant_control",
  "args": { "jurisdiction": "GB", "company_id": "01107406" }
}

The response gives us the registered PSCs. For Iceland Foods Ltd this is one corporate PSC: Iceland Topco Limited, Companies House 08723490, "ownership of shares 75 % or more, voting rights 75 % or more." That's a corporate PSC — we recurse.

Step 4 — recurse on the corporate PSC

{
  "tool": "get_persons_with_significant_control",
  "args": { "jurisdiction": "GB", "company_id": "08723490" }
}

Iceland Topco's PSCs are themselves four individuals — Sir Malcolm Walker, Tarsem Dhaliwal, Andrew Pritchard, Nigel Broadhurst — each declaring "ownership of shares more than 25 % but not more than 50 %" or similar. We've terminated in natural persons after one recursion.

Step 5 — fetch the statutory backing document

{
  "tool": "list_filings",
  "args": { "jurisdiction": "GB", "company_id": "08723490", "category": "confirmation-statement" }
}

Pick the most recent confirmation-statement filing, then:

{
  "tool": "fetch_document",
  "args": { "document_id": "<from list_filings>", "max_bytes": 5000000 }
}

This returns the literal XHTML iXBRL bytes of the filing — not a vendor's parsed extract. Your AI agent can quote the actual filed text in the audit-trail report, and the report links to https://find-and-update.company-information.service.gov.uk/company/08723490/filing-history/<id> so the auditor can verify independently.

Five calls, three of them recursive on step 4. This is the entire KYB workflow for that chain.

A real-world chain that crosses borders — say a UK Ltd whose PSC is a Luxembourg SARL whose PSC is a Cayman LP whose ultimate beneficial owner is an individual in a third country — runs the same loop, just more iterations, with each recursion hitting a different national registry through the same MCP interface.

The eight EU UBO registers that will return 501

Post CJEU C-37/20 (Luxembourg Business Registers, November 2022), public access to UBO registers in the EU was found to violate Article 7 and 8 of the Charter of Fundamental Rights. The court did not abolish UBO transparency — it required a "legitimate-interest" gating layer for non-AML-obliged requesters. Implementation has been jurisdiction-by-jurisdiction and the result is that as of today the following UBO registers are not publicly queryable, and no company-data vendor can legally proxy them:

Germany — Transparenzregister, AML-obliged-only since 2022-11-22, BMF guidance updates ongoing
Spain — Registro de Titulares Reales (RETIR), Ley 6/2023 transposition gates access at the AML-obliged level
Italy — Registro dei titolari effettivi, Consiglio di Stato 2024-10 referred C-37/20 + C-601/20 back to CJEU; currently frozen
Netherlands — UBO-register, post-2022 access scheme limited to obliged entities
Luxembourg — RBE, the register at the centre of C-37/20 itself
Austria — WiEReG, AML-obliged-only since 2023
Malta — BORM, restricted access regime
Portugal — RCBE, AML-obliged-only since 2023

Plus, outside the EU but on the same trajectory:

Cayman Islands — Beneficial Ownership Transparency Act 2023; "legitimate-interest access" only (CI$250/year application fee + CI$75/search; reaffirmed 2026 against UK pressure)
Hong Kong — SCR (Significant Controllers Register) is filed at the company's registered office, not centrally queryable
Malaysia — Section 56 Companies Act 2016 BO register is reporting-institution-only

When an AI agent calls get_persons_with_significant_control for one of these jurisdictions, OpenRegistry returns a structured 501 Not Implemented with alternative_url pointing at the legitimate-interest application page (where one exists) and reason carrying the legal citation. That structured response is the right answer — pretending to have the data when you legally cannot is the wrong answer.

PSC / shareholder layers that are publicly queryable (and thus walkable end-to-end through OpenRegistry today): UK, Ireland, Iceland, Norway, France (RNE / RBE since 2024 partial reopen), Belgium, Cyprus, Isle of Man, Liechtenstein (Vollauszug, paid tier), Monaco, plus the non-UBO shareholder layers in Czechia, Switzerland, Taiwan, South Korea (top shareholder + 5 %+ disclosure).

The split matters because a KYB workflow that cannot tell apart "no UBO record found" from "UBO record exists but is statutorily gated" is a workflow that will silently approve every counterparty operating out of one of those eight EU jurisdictions.

Why MCP-native delivery matters for KYB-as-an-LLM-task

The five-call workflow above is a recursive graph traversal with conditional document fetches. That class of task is what LLMs are now reliably good at — with one caveat: the LLM has to be able to invoke the tools without leaving the conversation.

Pre-MCP, plugging a company-registry API into an AI agent meant either (a) writing a custom tool wrapper for every framework (LangChain, CrewAI, AutoGen, the assistant-builder du jour), or (b) putting the LLM in front of a UI and letting it click. Both add a 200-2000 ms latency floor per call and a maintenance burden per framework.

MCP (Model Context Protocol, the spec Anthropic, OpenAI and Google CLIs all consume natively) collapses that — a single endpoint URL drops into a Claude Desktop / Cursor / Claude Code / Gemini CLI config and the agent has all 14 tools available. No SDK install, no API key (for anonymous tier), no per-framework adapter.

For KYB specifically that means:

The search_companies → get_company_profile → get_persons_with_significant_control → recurse → fetch_document loop runs as a single agent prompt rather than five UI button-clicks.
The audit log is the MCP transcript — every tool call with its arguments and the registry's actual response — which is structurally what auditors want anyway.
Cross-jurisdictional recursion is a parameter swap (jurisdiction: "GB" → jurisdiction: "LU") rather than a vendor swap. The loop body is identical.

If you're building KYB tooling that bills itself as "AI-native," this is the integration shape that delivers what that phrase implies. See the full KYB & UBO solution page for the productised version, including pricing tiers, fan-out caps, and source-provenance fields on the enterprise tier.

Plugging it into a real KYB pipeline

A few patterns we've seen work in production deployments:

Async pre-fetch on counterparty intake. When the sales / onboarding system creates a "potential customer" record with a legal name + jurisdiction, fire the five-call workflow asynchronously. By the time the human reviewer opens the case, the PSC chain is already walked, the documents are already cached, and the analyst is reviewing rather than fetching. Median analyst time per case drops from 45 minutes to 8 minutes in our walked benchmarks.
Periodic re-walks for high-risk counterparties. PSC entries change. UK Companies House's confirmation-statement filing is annual but PSC notifications are real-time; Brønnøysundregistrene pushes daily deltas. Schedule a weekly re-walk for any counterparty above your AML risk threshold and diff against the previous walk; surface only the deltas to the analyst.
Hard 501 handling. When the workflow hits an AML-gated UBO register, the only correct programmatic response is to flag the case for human review with the structured alternative_url from the response. Soft-failing (e.g., assuming "no UBO" because the register is gated) is the auditor's first finding.
Document fetch is the last call, not the first. A surprising amount of KYB tooling fetches every filing of a company "just in case." It's a waste — list_filings returns metadata cheaply, you fetch the one document the PSC trace actually needs, and you stay well below the upstream-registry rate-limit ceilings.

Coverage today

27 national registries live: GB, IE, NO, FI, FR, BE, IS, IM, CH, CY, MC, LI, DE, NL (KVK), CZ, PL, LU (search-only), AU, NZ, TW, KR (OpenDART), HK, MY, ID, IN, ES (BORME), IT (BRIS), CA (federal + BC + NT), US (NY + CA), MX, RU, KY (CIMA + general register).
Free anonymous tier (20 req/min/IP), free signed-in tier, paid tiers for higher fan-out and source-provenance fields.
Connect from Claude Desktop / Cursor / Claude Code / Gemini CLI with a single line of config:

{
  "mcpServers": {
    "openregistry": {
      "url": "https://openregistry.sophymarine.com/mcp"
    }
  }
}

Or via Claude Code:

claude mcp add --transport http openregistry https://openregistry.sophymarine.com/mcp

The KYB-specific landing page with the full source-provenance matrix, jurisdiction-by-jurisdiction PSC availability, and the productised five-call workflow is at openregistry.sophymarine.com/solutions/kyb. Free to evaluate, no signup required for the anonymous tier.

If you're building cross-border KYB tooling on top of LLMs, the five-call loop is the bit you want to get right first. The rest — data quality, jurisdiction coverage, statutory gating — is what the gateway is for.

France Sirene + RNE — post-canonicalisation API guide

OpenRegistry — Wed, 29 Apr 2026 08:01:12 +0000

Until 2023, the canonical French company register was a four-way fragmented mess: INSEE Sirene held the identification layer (SIREN, SIRET, name, address, headcount, NAF activity code), the regional Greffes held statutory acts (incorporation deeds, capital changes, director appointments), the Tribunaux de Commerce shared partial data through Infogreffe (paid), and the Bodacc was the gazette. Starting 1 January 2023 the Registre National des Entreprises (RNE) at INPI became the single canonical source for French commercial information — consolidating the old Registre du Commerce et des Sociétés (RCS), Registre des Métiers (RM), Registre Spécial des Agents Commerciaux (RSAC) and the Registre Spécial des EIRL (RSEIRL).

The post-RNE world isn't fully tidy yet — Sirene and RNE are still two distinct API surfaces, and the integration between them has rough edges — but it's the cleanest French registry has ever been for programmatic access. Here's what's actually queryable in 2026 and where the seams are.

What's free and programmatic

INSEE Sirene (api.insee.fr/entreprises/sirene/V3) — free, open, cumulatively the world's most comprehensive company database with ~30M active records.

Search by SIREN (9-digit identifier of the legal person), SIRET (14-digit identifier of an establishment = SIREN + 5 digits), name, NAF code, postal code, denomination
Returns establishment-level data: legal name, NIC, etablissement principal, dateCreationEtablissement, NAF activity code (APE), tranche d'effectif (headcount band), workforce date
30 requests/minute on the free tier. Higher tiers available with a signed convention.
Updated daily from the regional URSSAF feed.

INPI RNE (data.inpi.fr) — free, requires account registration with email + Cloudflare Turnstile.

Returns the statutory dossier: directors, beneficial owners (where not gated), share capital, statuts, recent acts, annual accounts where filed
Bulk download "RNE complet" for ~7M French entities published quarterly + delta files daily
Per-record API queries return RNE structured records keyed on SIREN

French Annuaire des Entreprises (annuaire-entreprises.data.gouv.fr) — Etalab's public-facing aggregator merging Sirene + RNE + Bodacc — same data, lowest-friction free API, no auth.

What's paywalled or AML-gated

K-bis extracts (the official certificate of incorporation) — €3.96 per certificate at infogreffe.fr. The data inside is public via RNE; the certified extract is the paid product.
Bilans (annual accounts) older than 5 years — Greffes Tribunaux de Commerce charge for archive retrieval; RNE keeps the most-recent only.
Beneficial-ownership register for non-AML-obliged third parties — France implemented CJEU C-37/20 by gating the public RNE UBO search behind a justification of legitimate interest form. AML-obliged entities (banks, lawyers, notaires) keep direct access.

OpenRegistry's coverage of the French surface

OpenRegistry routes French queries through Sirene first (for SIREN/name lookup) and falls back to RNE for the statutory dossier. The jurisdiction='FR' calls return both.

Tool	Status	Notes
`search_companies`	✅ live	Sirene full-text + SIREN exact match. Supports `query` for name, `siren`/`siret` for direct lookup
`get_company_profile`	✅ live	Merged Sirene establishment data + RNE legal dossier where available
`get_officers`	✅ live	RNE-sourced; current and historical officer roles
`get_persons_with_significant_control`	⛔ 501	RNE UBO is access-restricted post-CJEU C-37/20; tool returns `alternative_url` to the legitimate-interest application portal
`get_shareholders`	⛔ 501	French RCS does not publish a structured shareholder list outside the SAS/SARL acts; tool returns alternative paths
`list_filings`	✅ live	RNE acts + Bodacc publication index
`get_financials`	✅ live	Annual accounts for the last 5 years where filed
`fetch_document`	✅ live	Returns acts and accounts as PDF bytes verbatim from RNE
`get_charges`	⛔ 501	French registry doesn't expose a structured charges register equivalent to the UK one; security interests are filed at the Greffes individually

Quirks an integrator hits the hard way

1. SIREN vs SIRET. SIREN is the 9-digit identifier of the legal person (the entreprise). SIRET is 14 digits — the SIREN concatenated with a 5-digit NIC identifying a specific établissement (place of business). A company with five offices has one SIREN and five SIRETs. Search and profile by SIREN; logistics by SIRET. search_companies accepts either; the result always carries both.

2. NAF codes are not industry codes. France uses NAF (Nomenclature d'Activités Française), revised in 2008 to align with NACE. Codes look like 47.91A or 62.01Z. They are activity codes for the establishment, not the legal person. The headquarters' NAF and a branch's NAF can differ.

3. Sirene's etat_administratif has only two values: A (actif) or F (fermé / cessé). It does not capture liquidation-in-progress or insolvency state — for that, query the Bodacc publications or the RNE acts.

4. Hashed names in some Sirene records. Where a sole-trader entrepreneur has opted for the non-diffusion protection, Sirene returns the company name partially obscured ("*** ***") and the SIREN remains queryable. RNE may still have the name in the legal dossier.

5. Annual accounts are opt-in to keep secret for SAS/SARL. Since 2014, certain small companies can request that their annual accounts not be made public. The accounts are still filed with the Greffes but the public copy is suppressed. The filing record exists in list_filings with the correct date and category, but fetch_document returns a structured "non communicable" notice rather than the document body. Don't treat this as a bug — it's the law.

A complete worked example — Renault

// Request
{
  "name": "search_companies",
  "arguments": { "jurisdiction": "FR", "query": "Renault SA", "limit": 1 }
}

// Response (truncated)
{
  "jurisdiction": "FR",
  "count": 1,
  "results": [{
    "company_id": "441639465",
    "company_name": "RENAULT",
    "status": "active",
    "incorporation_date": "1998-01-15",
    "registered_address": "122 Avenue du Général Leclerc, 92100 Boulogne-Billancourt",
    "jurisdiction_data": {
      "siren": "441639465",
      "siret_siege": "44163946500035",
      "denomination": "RENAULT",
      "naf": "70.10Z",
      "categorie_juridique": "5710",
      "etat_administratif": "A",
      "tranche_effectif": "53",
      "date_creation": "1998-01-15"
    }
  }]
}

Then get_company_profile("FR", "441639465") merges in the RNE acts; get_officers("FR", "441639465") returns the directors and statutory representatives; list_filings("FR", "441639465") returns annual accounts going back 5 years. The 11-digit categorie_juridique (5710) tells you it's an SA — Société Anonyme; if it were 5499 it'd be an SARL — different statutory disclosure obligations apply.

Connecting an MCP client

Add this to your MCP-compliant client (Claude Desktop / Cursor / Cline / Goose / Zed):

{
  "mcpServers": {
    "openregistry": {
      "url": "https://openregistry.sophymarine.com/mcp"
    }
  }
}

Free anonymous tier — 20 requests per minute per IP, every tool, every jurisdiction. No signup, no API key, no convention to sign.

Or skip the MCP layer and search on the web at openregistry.sophymarine.com/search?jurisdiction=FR, or jump straight to a known SIREN at openregistry.sophymarine.com/company/fr/441639465 for Renault's full profile.

What's still moving

The Sirene–RNE integration has rough edges — INSEE and INPI didn't fully merge their schemas at canonicalisation, so a few records exist in one and not the other. INPI publishes corrections weekly; the cumulative gap is shrinking. The DRCBE (Dispositif Rénové de Collecte des Bénéficiaires Effectifs) is the back-office workflow consolidating UBO across the registries, and once it's fully online it should make get_persons_with_significant_control queryable for AML-obliged callers via a structured access flow rather than the current legitimate-interest form.

OpenRegistry's full coverage

OpenRegistry is a free remote MCP server giving AI agents real-time access to company-registry data from 30 national governments. This article focused on France; the same toolkit covers:

🇬🇧 UK Companies House · 🇫🇷 INSEE Sirene + INPI RNE · 🇩🇪 Handelsregister · 🇮🇹 Registro Imprese (BRIS) · 🇪🇸 BORME · 🇳🇱 KVK · 🇧🇪 KBO · 🇨🇭 Zefix · 🇳🇴 Brreg · 🇫🇮 PRH · 🇮🇪 CRO · 🇵🇱 KRS · 🇨🇿 ARES · 🇮🇸 RSK · 🇮🇲 IoM Registry · 🇨🇾 DRCOR · 🇲🇨 RCI · 🇱🇮 Liechtenstein HR · 🇰🇷 OPENDART · 🇭🇰 Companies Registry · 🇹🇼 GCIS · 🇲🇾 SSM · 🇦🇺 ABR · 🇳🇿 Companies Office · 🇨🇦 Corporations Canada (+ BC + NWT) · 🇲🇽 PSM · 🇰🇾 CIMA · 🇷🇺 ЕГРЮЛ

→ Hosted MCP endpoint: https://openregistry.sophymarine.com/mcp
→ Docs: https://openregistry.sophymarine.com/docs/
→ Free anonymous tier: 20 req/min, every tool, every jurisdiction.

Made by Sophymarine.

UK Companies House — post-ECCTA reality and the actual API surface

OpenRegistry — Wed, 29 Apr 2026 07:59:10 +0000

The UK's Economic Crime and Corporate Transparency Act 2023 ("ECCTA") changed Companies House from a passive filing repository into a verification authority. Identity verification for directors and PSCs is being rolled out in phases through 2026, suspended-name powers expanded, and there's a new "abbreviated information" mode for small filers. None of that broke the public REST API — but it changed what's in the data. If you're integrating Companies House in 2026, here's what the surface actually looks like, what's free, what's paywalled, and the quirks that bite if you don't know them.

What's free and programmatic

Companies House publishes one of the cleanest open registry APIs in the world. You sign up at developer.company-information.service.gov.uk, get an API key, and you're off. The API covers:

Search — /search/companies returns up to 50 hits per call, paginated. There's a separate /search/officers and /search/disqualified-officers.
Profile — /company/{number} returns the full statutory record: status, type, incorporation date, registered office, SIC codes, accounts schedule, confirmation-statement schedule, previous names, jurisdiction (England and Wales, Scotland, NI), insolvency-history flag.
Officers — /company/{number}/officers returns directors + secretaries + auditors with appointment dates, roles, dates of birth (month + year only — day is suppressed under the residential-address protections of the Companies Act 2006 s.243), and country of residence.
Persons with Significant Control — /company/{number}/persons-with-significant-control returns the structured PSC register: name (or notification of supersession), kind, nature of control, notification dates.
Filings — /company/{number}/filing-history returns every filing with category, type code, date, document ID. Documents themselves are at /company/{number}/filing-history/{transaction_id}/document and come back as PDF or XHTML iXBRL bytes.
Charges — /company/{number}/charges returns registered fixed/floating charges with persons entitled, status (outstanding / satisfied / part-satisfied), creation date.

Rate limit is 600 requests per 5 minutes per key — generous enough for a serious workflow but not unlimited. Hit it and you get an HTTP 429 with a Retry-After header in seconds.

What's paywalled or AML-gated

Two things only:

Bulk product downloads (annual all-data dumps) cost a fee — but the per-request API has the same data anyway.
The PSC nominee register and the names-by-residential-address feed are Companies House internal tools, not public.

Notably the PSC register itself is fully public. The UK never went the route of restricting beneficial-ownership data to AML-obliged entities — unlike the EU post-CJEU C-37/20.

OpenRegistry's coverage of the UK surface

OpenRegistry proxies Companies House one-to-one with these tools:

Tool	Status	Notes
`search_companies`	✅ live	by name + by exact 8-character company number
`get_company_profile`	✅ live	full statutory record incl. `previous_company_names`, `accounts.next_due`
`get_officers`	✅ live	merges current + resigned, paginated
`get_persons_with_significant_control`	✅ live	structured PSC register; corporate PSCs appear here distinctly from individuals
`get_shareholders`	✅ live (via filing pointer)	UK CH does not expose a structured shareholders endpoint — the statutory members register is published as part of the Confirmation Statement (CS01). Tool returns the latest `CS01` + `IN01` filing IDs; pass to `fetch_document` and parse the iXBRL
`list_filings`	✅ live	every filing from incorporation forward
`get_financials`	✅ live	annual accounts subset of `list_filings`
`fetch_document`	✅ live	iXBRL / PDF / XHTML bytes returned raw, no re-rendering
`get_charges`	✅ live	full charge register
`get_officer_appointments`	✅ live	given an officer ID, every UK company that officer sits / sat on
`search_officers`	✅ live	by name; useful for adverse-media + PEP screening

Quirks an integrator hits the hard way

1. Company numbers are not all 8-digit numerics. UK CH issues numbers from a structured space:

8 digits → standard England & Wales / Wales-only company
SC + 6 digits → Scottish company
NI + 6 digits → Northern Ireland
OC + 6 digits → LLP (Limited Liability Partnership)
LP + 6 digits → Limited Partnership
RC + 6 digits → Registered Society
FC + 6 digits → Foreign company branch (UK establishment of an overseas firm — no UK accounts filed; statutory dossier is at the home jurisdiction)
NF + 6 digits → Northern Ireland LLP

If your code assumes all-numeric you'll silently exclude Scotland and every LLP in the country. OC404063 is a real LLP; SC456789 is a real Scottish company. Both work in OpenRegistry's search_companies and get_company_profile.

2. PSC ≠ shareholders. UK CH publishes a structured PSC register and a separate (filing-only) statement of capital. They disagree: a 10% direct shareholder appears in the statement of capital but not in PSC; a corporate trustee with appointment rights appears in PSC without being a shareholder. Treat get_persons_with_significant_control as the controlling-influence register, not the equity register. For full equity, fetch the latest CS01 PDF/iXBRL via fetch_document and parse it yourself — that's exactly the workflow we walked in Iceland Foods 4-layer chain.

3. Status is more granular than active/dissolved. CH's company_status field has eight values — active, dissolved, liquidation, receivership, administration, voluntary-arrangement, converted-closed, removed — plus a free-text company_status_detail for the "in-flight" cases. A company shown as active - proposal to strike off is materially riskier than a plain active one. OpenRegistry's unified status field collapses to active/inactive for cross-country comparison; the upstream nuance is preserved verbatim in jurisdiction_data.company_status_detail.

4. Dates of birth are partial. Director DoB returns { month, year } only. The day is suppressed under the residential-address-protection rules introduced in 2018. Don't try to match against a full DD-MM-YYYY DoB from another source — match on year + month or on full name + DoB-year.

A complete worked example — Monzo Bank Ltd

// Request
{
  "name": "search_companies",
  "arguments": { "jurisdiction": "GB", "query": "Monzo Bank", "limit": 1 }
}

// Response (truncated)
{
  "jurisdiction": "GB",
  "count": 1,
  "results": [{
    "company_id": "09446231",
    "company_name": "MONZO BANK LIMITED",
    "status": "active",
    "incorporation_date": "2015-02-06",
    "registered_address": "Broadwalk House, 5 Appold Street, London, England, EC2A 2AG"
  }]
}

Then get_company_profile("GB", "09446231") returns the full record; get_officers("GB", "09446231") returns 17 directors + secretaries; get_persons_with_significant_control("GB", "09446231") returns the PSCs; list_filings("GB", "09446231", { limit: 25 }) returns the most-recent filings; get_charges("GB", "09446231") returns every registered charge against the company. Five tool calls. Sub-second total latency. Replaces a manual workflow that would otherwise span five separate Companies House screens.

Connecting an MCP client

Add this to your client (Claude Desktop / Cursor / Cline / Goose / Zed — any MCP 2025-06-18 compliant agent):

{
  "mcpServers": {
    "openregistry": {
      "url": "https://openregistry.sophymarine.com/mcp"
    }
  }
}

Free anonymous tier — 20 requests per minute per IP, every tool, every jurisdiction. No signup, no API key.

Or skip the MCP layer entirely and search on the web at openregistry.sophymarine.com/search?jurisdiction=GB, or jump straight to a known company at openregistry.sophymarine.com/company/gb/09446231 for Monzo's full profile, directors, filings, and charges.

Where ECCTA goes from here

The director-and-PSC identity-verification regime is rolling out in phases through 2026. The data shape returned by the public API hasn't changed — but starting late 2025, records show whether each director / PSC has completed Companies House identity verification (identity_verification_status). Untrusted records may eventually be hidden from search; the current behaviour is they remain visible with the verification flag missing. Watch the field as it appears.

OpenRegistry's full coverage

OpenRegistry is a free remote MCP server giving AI agents real-time access to company-registry data from 30 national governments. This article focused on the UK; the same toolkit covers:

🇬🇧 UK Companies House · 🇫🇷 INSEE Sirene + INPI RNE · 🇩🇪 Handelsregister · 🇮🇹 Registro Imprese (BRIS) · 🇪🇸 BORME · 🇳🇱 KVK · 🇧🇪 KBO · 🇨🇭 Zefix · 🇳🇴 Brreg · 🇫🇮 PRH · 🇮🇪 CRO · 🇵🇱 KRS · 🇨🇿 ARES · 🇮🇸 RSK · 🇮🇲 IoM Registry · 🇨🇾 DRCOR · 🇲🇨 RCI · 🇱🇮 Liechtenstein HR · 🇰🇷 OPENDART · 🇭🇰 Companies Registry · 🇹🇼 GCIS · 🇲🇾 SSM · 🇦🇺 ABR · 🇳🇿 Companies Office · 🇨🇦 Corporations Canada (+ BC + NWT) · 🇲🇽 PSM · 🇰🇾 CIMA · 🇷🇺 ЕГРЮЛ

Made by Sophymarine.

Tracing a Cypriot holding company across 4 registries

OpenRegistry — Tue, 28 Apr 2026 15:00:46 +0000

Tracing a Cypriot holding company across 4 registries

If you are a journalist or OSINT researcher, the hard part is not finding a company name. It is proving that the name on the brochure page is the same legal entity that sits behind the money, the contracts, and the dissolved shells.

This is the kind of trail I would use for a Cypriot holding company with links that appear to run from Nicosia to the Gulf. The problem is familiar: one registry gives you the local entity, another gives you the parent, a third shows an officer appointment, and a fourth is where the ownership chain finally becomes legible. The work is slow when you have to juggle four websites and three spelling variants. It gets much faster when each step is an official registry query with a source link attached.

For a researcher, the first pass is simple: search the company by name, capture the registration number, then pull the officer and filing history. In OpenRegistry, that is a small sequence of live calls rather than a paste-and-pray exercise. You can start with the company search, then inspect officers, then ask for filings or shareholder records where the registry exposes them. The important part is that every field comes back with an upstream source, so you can cite what you saw instead of describing what a third-party database thinks it saw.

A useful pattern is to stop thinking in terms of “one company” and start thinking in terms of “one chain”. A shell structure usually reveals itself through a few signals:

a newly formed holding company that owns an older operating entity
directors who appear across several related companies
a burst of appointments and resignations in a short window
address reuse across multiple jurisdictions
a foreign parent whose legal form changes as you cross borders

Those are not proofs by themselves. They are prompts for the next registry call.

Here is the workflow I would use on Monday morning:

Search the Cypriot entity and capture the exact legal name.
Pull officers and check whether any names repeat in UK, Irish, or Dutch filings.
Follow the parent or shareholder record into the next jurisdiction.
Compare appointment dates, filing dates, and address changes to see whether the structure moved around a transaction.

That last step matters more than people expect. Journalists often look for the loud event, but the real story can be in the quiet timing gap: a director change two weeks before a sale, a new holding vehicle after an incorporation burst, or a dormant intermediary that only exists to bridge two filing systems.

If you want to reproduce the process in your own notes, keep the output boring and portable. Capture the registry URLs, the registration numbers, the officer names, and the filing dates in a plain table. Do not trust a rendered summary as your evidence file. The evidence is the upstream record.

example shape: a company search returns the legal name, registry identifier, incorporation date, and a source URL for each field. That is enough to anchor the rest of the investigation without inventing a structure chart from memory.

For this kind of work, the most useful capability is a cross-border UBO chain walker. That lets you hop from one official record to the next without retyping the same entity name in every system. It is not magic. It just removes the friction that makes real investigative work feel impossible after the third registry tab.

If you are using Claude Desktop or another agent interface, the value is even clearer. You can ask the model to keep the chain narrow, move jurisdiction by jurisdiction, and stop when a filing looks like a true control point instead of a cosmetic parent. That keeps the investigation honest. The model is not guessing ownership; it is only following official records that already exist.

One practical tip: save the path, not just the result. A useful research note is not “Company A is owned by Company B.” It is “Company A appeared in Cyprus on this date, Company B appears in the UK filing history, and the same director name recurs in both records.” That format lets another person verify the trail without trusting your interpretation.

When the chain gets messy, ask three questions in order. First, which entity is the earliest live record? Second, which officer or shareholder connects two records with the least ambiguity? Third, which filing date explains the timing of the move? Those questions are enough to separate a real ownership trail from a pile of related companies that only look connected because they share an address.

If you are trying to verify whether a holding company is real, dormant, or just a staging layer, start with live registry data and keep the chain visible. OpenRegistry does that against 27 national registries, including Cyprus and the jurisdictions that usually sit downstream of it: https://openregistry.sophymarine.com/mcp

Bureau van Dijk alternative for KYB teams that need live data

OpenRegistry — Mon, 27 Apr 2026 15:00:45 +0000

🎬 60-second demo: OpenRegistry walks a real 4-layer UK shareholder chain — Iceland Foods Ltd through three holding companies (WD FF MIDCO → ICELAND VLNCO → LANNIS), ending at the 8 individual owners with exact percentages (CEO Tarsem Dhaliwal 41.35%, Walker family 51.31% combined), all live from Companies House CS01 PDFs.

KYC / KYB teams at fintechs and onboarding vendors usually know exactly why they keep paying for Bureau van Dijk: one place to look up corporate entities, some ownership context, and a familiar workflow for analysts. The part that hurts is the price, the lag between source filings and the vendor copy, and the way cross-border work still ends up in browser tabs and spreadsheets.

If you are building for that persona, the useful question is not whether BvD has coverage. It is whether you still need a paid aggregation layer when your job is to answer a live corporate-data question from the source record. That is where OpenRegistry becomes a practical alternative: official registries, source-linked results, and a workflow that keeps the filing trail visible instead of flattening it into a vendor summary.

Here is the comparison I would put in front of a KYB team before a renewal:

Feature	Bureau van Dijk	OpenRegistry
Coverage model	Aggregated database	Live official registries
Freshness	Periodic refreshes	Query the source directly
Ownership trail	Good for analyst review	Better for source-linked verification
Pricing	Enterprise contract	Developer-friendly access
Best use	Broad screening and research	Live due diligence workflows
Source links	Usually indirect	Direct links back to filings

That does not mean BvD is bad. It is still useful if you want a managed research environment and you do not care about tracing every step back to the government record. But if your product promise is “show me what the registry says now,” the aggregation layer becomes friction.

A typical KYB workflow has three recurring pain points. First, an onboarding analyst wants to confirm that a company really exists in the jurisdiction it claims. Second, they want to see whether the director and ownership history support the story the customer gave them. Third, they want to resolve edge cases across jurisdictions without re-keying the same entity ten times. Those are source-record problems, not summary-report problems.

What changes when you move the workflow to live registries? You can make the analyst path shorter. Search the entity once, pull the filing chain once, and keep the provenance visible. When the case is simple, the result is a quick pass. When it is messy, the mess is easier to explain to compliance because you can point at the record instead of the vendor snapshot.

The other benefit is product design. A KYB app built on live registries can expose the uncertainty instead of hiding it. Maybe the entity name is transliterated differently. Maybe the officer list is incomplete in one jurisdiction and complete in another. Maybe the company is active in one registry and dormant in another. Those are not bugs to paper over; they are exactly the details an analyst needs to see.

If you are evaluating an alternative today, I would use this rule of thumb: choose Bureau van Dijk if your team wants a broad commercial research layer and pays for convenience. Choose OpenRegistry if you want official source-linked data, lower latency to the filing record, and a product surface you can explain to auditors without hand-waving.

The easiest way to test the fit is to take one real onboarding case and run it both ways. If the vendor layer answers the question faster and with enough provenance, keep it. If you keep hitting the source-record gap, the registry-first approach will save time every week, not just on renewal day.

To try the registry-first path, start with https://openregistry.sophymarine.com and compare one live company lookup against your current KYB flow.

For due diligence consultants: 30-minute workflows become 3-minute

OpenRegistry — Sun, 26 Apr 2026 15:00:40 +0000

🎬 60-second demo: OpenRegistry walks a real 4-layer UK shareholder chain — Iceland Foods Ltd through three holding companies (WD FF MIDCO → ICELAND VLNCO → LANNIS), ending at the 8 individual owners with exact percentages (CEO Tarsem Dhaliwal 41.35%, Walker family 51.31% combined), all live from Companies House CS01 PDFs.

For due diligence consultants, the time sink is rarely the memo itself. It is the back-and-forth to verify directors, officers, filings, and ownership across more than one country before you can say whether a company is worth a closer look. If your workflow still means tab-hopping through registry sites, you know how fast a 30-minute check turns into a half-day.

I have seen the same pattern across small advisory teams: one person finds the UK record, another checks a parent entity in the Netherlands, then someone else tries to confirm whether the same people show up in a second jurisdiction under a slightly different spelling. The result is not a lack of judgment. It is a lack of a single query layer that can pull the official record, keep the source links attached, and let you move from name to ownership chain without rebuilding the path each time.

That is where a registry MCP server changes the shape of the work. Instead of asking consultants to be part researcher, part copy-paste operator, you give them one place to ask for the company profile, officers, filings, PSC data, and shareholder trail. The difference is not abstract. It shows up in the first ten minutes of a case: fewer browser tabs, fewer dead ends, and fewer “I think this is the right entity” moments.

A useful way to think about it is the Monday-morning version of a due diligence brief.

Start with the company name the client gave you.
Pull the live profile and officers.
Check whether the name appears in more than one jurisdiction.
Walk the ownership chain only as far as the public record allows.
Save the source URLs before you write a word of narrative.

example shape: profile, officers, filings, and PSC records all come back as raw upstream fields with source links attached. That matters because a consultant’s report is only as defensible as the evidence trail behind it. If a director name is normalised in one place and spelled differently in another, you want to see both forms rather than a tidy summary that hides the discrepancy.

The other gain is consistency. In a manual process, the second analyst often repeats the same checks differently and ends up with a slightly different conclusion. In a live registry workflow, the team can standardise the same questions: Who is on the record now? What filings exist? Which control statements are public? Is there a shareholder chain worth chasing further? That makes review meetings shorter, because everyone is looking at the same source-backed answer.

For smaller firms, the biggest payoff is not scale for its own sake. It is that a senior consultant can delegate more of the checking without losing confidence in the result. The junior staff member does not need to learn every registry quirk on day one. They need a tool that surfaces the record, keeps the upstream link visible, and makes it harder to confuse a similar name with the actual entity.

There are still limits. Public registries do not tell you everything, and they do not replace judgment. They also do not solve source-language quirks, filing gaps, or the fact that some jurisdictions publish more than others. But they do remove a large chunk of repetitive work that used to sit between the question and the answer.

If you spend your week turning company names into evidence packs, the practical test is simple: can you get from first lookup to source-linked trail without building your own scraper stack? If not, start with the registry endpoint at https://openregistry.sophymarine.com/mcp and see how far one live query gets you.

DEV Community: OpenRegistry

Live UK director-change detection on Companies House: 4 real cases from this month

Case 1: BP plc, director resignation, 5 days ago

Case 2: Unilever plc, three directors out on the same day

Case 3: Wise plc, capital change + new director appointment

Case 4: Stripe Payments UK Ltd, corporate director change

How to run this yourself

Where this sits in the KYB stack

What this doesn't replace

Three failure modes of AI agents on company-registry data

1. The aggregator-snapshot lag

2. Schema normalisation that hides jurisdictional truth

3. Cross-border fan-out that doesn't fan out

What this points to

Spain BORME — post-RETIR / post-CJEU API guide

Spain BORME — post-RETIR / post-CJEU API guide

What the registry actually exposes

What's paywalled, gated, or restricted

Which OpenRegistry tools cover which surface

Country-specific quirks

A complete worked example

Connecting an MCP client

CTA

OpenRegistry's full coverage

Italy Registro delle imprese — post-Consiglio di Stato 2024 API guide

OpenCorporates alternatives compared

OpenCorporates alternatives compared

Feature comparison

What the table says about OpenRegistry

Links

UK Companies House — post-ECCTA reality / API guide

UK Companies House — post-ECCTA reality / API guide

What the registry actually exposes

What is paywalled, gated, or restricted

Which OpenRegistry tools cover which surface

Country-specific quirks

Complete worked example

Connecting an MCP client

CTA

OpenRegistry's full coverage

The five-call cross-border KYB workflow — walking a UBO chain across jurisdictions in a single prompt

The five-call cross-border KYB workflow — walking a UBO chain across jurisdictions in a single prompt

Why "look up the company in country X" doesn't generalize

The canonical five-call workflow

Worked example — Iceland Foods Ltd → Iceland Topco Limited → individuals

The eight EU UBO registers that will return 501

Why MCP-native delivery matters for KYB-as-an-LLM-task

Plugging it into a real KYB pipeline

Coverage today

France Sirene + RNE — post-canonicalisation API guide

What's free and programmatic

What's paywalled or AML-gated

OpenRegistry's coverage of the French surface

Quirks an integrator hits the hard way

A complete worked example — Renault

Connecting an MCP client

What's still moving

OpenRegistry's full coverage

UK Companies House — post-ECCTA reality and the actual API surface

What's free and programmatic

What's paywalled or AML-gated

OpenRegistry's coverage of the UK surface

Quirks an integrator hits the hard way

A complete worked example — Monzo Bank Ltd

Connecting an MCP client

Where ECCTA goes from here

OpenRegistry's full coverage

Tracing a Cypriot holding company across 4 registries

Tracing a Cypriot holding company across 4 registries

Bureau van Dijk alternative for KYB teams that need live data

For due diligence consultants: 30-minute workflows become 3-minute