KYB & UBO verification — 27 official registries, one MCP endpoint

AI agents and compliance teams that need Know-Your-Business and Ultimate-Beneficial-Owner data, sourced from the government's own register rather than a normalised aggregator. Live queries, verbatim upstream payload, identifiers that round-trip back to the statutory portal — and the cross-border fan-out built in, so an LLM can walk a multi-jurisdiction ownership chain in a single prompt.

What this gives you

The 5-call KYB / UBO workflow

A complete cross-border UBO trace fits into five MCP tool calls. The same shape works whether the target is a UK Ltd with a UK PSC chain, a French SAS owned by a Luxembourg holding, or a Cayman fund vehicle with statutory gating. The agent decides where to recurse and where to stop.

// 1. Resolve the company by name → canonical company_id
Step 1. search_companies({ jurisdiction: "GB", query: "Iceland Foods Ltd", limit: 5 })

// 2. Pull the registered profile (legal name, status, address, officers ref)
Step 2. get_company_profile({ jurisdiction: "GB", company_id: "01107406" })

// 3. Statutory beneficial-owner / PSC layer for this company
Step 3. get_persons_with_significant_control({ jurisdiction: "GB", company_id: "01107406" })

// 4. For every corporate PSC, recurse into the parent's home jurisdiction
Step 4. search_companies({ jurisdiction: "GB", query: "Iceland Topco Limited" })
        // → repeat steps 2–4 until you reach individuals or a statutorily restricted register

// 5. Pull the latest filed accounts as raw iXBRL — verifiable evidence layer
Step 5. fetch_document({ document_id: "<from get_financials>", max_bytes: 5000000 })

A worked walkthrough of this exact pattern (real public company, verbatim responses) lives at /docs/case-studies/iceland-foods-chain-walk.

Coverage for KYB / UBO data

OpenRegistry wires 27 national registries. UBO availability is registry-dependent — some jurisdictions publish a public PSC-style register, some sit behind a CJEU-imposed gate, some use shareholder filings as the de facto UBO surface.

How OpenRegistry compares for KYB / UBO use

Three categories of incumbent solve the KYB problem today: aggregators, KYB SaaS, and single-country APIs (or single-country MCP servers). OpenRegistry sits in a fourth category: the live MCP gateway between an AI agent and the original government registers.

A more detailed teardown — including verbatim-vs-normalised audit examples — lives at /docs/comparison.

Why "verbatim upstream data" matters for KYB

A KYB or UBO finding eventually has to survive a regulator's review. Aggregators reshape the upstream payload into their own schema; that reshape is one tool's interpretation of a statutory field, not the field itself. Silent normalisation errors — a "dissolved" status mapped to "inactive", a corporate trustee dropped from the PSC list, a registered-office address swapped for a service address — break in production and are hard to attribute.

OpenRegistry's contract is the opposite: every response carries the verbatim upstream object under jurisdiction_data, with a thin unified envelope on top. The agent reads the raw field; the audit log shows the raw field. No vendor-side transformation to defend in a review.

Connect from any AI client

Anonymous tier requires no signup, no API key, no contract — paste the MCP URL into your client's settings and the first tool call works.

Claude Desktop / Claude Code / Cursor / Cline

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

Or via Claude Code CLI: claude mcp add --transport http OpenRegistry https://openregistry.sophymarine.com/mcp. Per-framework guides (LangChain, CrewAI, LlamaIndex, etc.) are at /docs/integrations.

FAQ