Home/Offers/Legal, Compliance & GovTech/Corporate Ownership Intelligence API

Legal, Compliance & GovTech

Corporate Ownership Intelligence API

The question is simple and the answer takes three days: who ultimately owns this company, and who else do they own?

KYB and onboarding platforms
Banks and payment firms
Compliance software vendors
Procurement teams
Diligence and investigation firms

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Beneficial ownership is the bottleneck in nearly every onboarding and diligence process. A corporate customer presents a trading entity; the obligation is to know who ultimately controls it. In a straightforward case that is two registry lookups. In a normal case it is a holding company in another jurisdiction, a nominee shareholder, a trust, and a filing that is eighteen months stale.

Registries themselves are the limiting factor and they differ enormously. Some publish full shareholder and officer data as open bulk downloads. Some publish a company name and a status and nothing more. Some have a beneficial ownership register that is accurate, some have one that is self-declared and unverified, and several that were public have been restricted following court rulings on privacy. Any product here is a patchwork, and pretending otherwise is the main way these tools mislead.

The engineering value is in resolution and traversal: matching the same company and the same person across registries with different identifiers and transliterations, walking the ownership chain until control is established or the trail genuinely ends, and computing effective ownership through multi-layer and circular structures. Done honestly, the output includes where the trail stopped and why — which is often the most important field in the response.

Who buys this

KYB and onboarding platforms, Banks and payment firms, Compliance software vendors, Procurement teams, Diligence and investigation firms

Category: Legal, Compliance & GovTech

What the API returns

What comes back

Resolved company records with registry identifiers across jurisdictions
Ownership graph with direct and effective percentages through multiple layers
Identified beneficial owners above a configurable control threshold
Officer and director records with cross-company appearances
Group structure including subsidiaries, branches and dormant entities
Relationship paths between two entities or persons, with the evidence for each edge
Provenance per edge — which registry, which filing, which date
Explicit trail-end records stating where resolution stopped and for what reason

Endpoints

Method	Path	Returns
GET	/v1/companies/{id}	Resolved company record with registry provenance
GET	/v1/companies/{id}/ownership	Ownership graph with effective percentages
GET	/v1/companies/{id}/ubo	Beneficial owners above a control threshold
GET	/v1/officers/{id}/appointments	An officer's appointments across companies
POST	/v1/paths	Find relationship paths between two entities
GET	/v1/coverage	Registry coverage, data depth and refresh cadence by jurisdiction

Request and response

illustrative

Request

{
  "company": { "jurisdiction": "GB", "registration_number": "09421188" },
  "traverse": { "max_depth": 6, "control_threshold_pct": 25.0 },
  "include": ["ownership", "ubo", "officers", "provenance"]
}

Response

{
  "company": { "name": "Kelmore Trading Ltd", "jurisdiction": "GB",
               "number": "09421188", "status": "active" },
  "ownership": {
    "layers_traversed": 4,
    "edges": [
      { "from": "Kelmore Holdings BV (NL)", "to": "Kelmore Trading Ltd",
        "pct": 100.0, "source": { "registry": "NL-KVK", "filed": "2026-03-14" } },
      { "from": "Arden Nominees Ltd (JE)", "to": "Kelmore Holdings BV",
        "pct": 62.0, "source": { "registry": "NL-KVK", "filed": "2026-03-14" } },
      { "from": "unresolved", "to": "Arden Nominees Ltd",
        "pct": null, "source": { "registry": "JE", "access": "restricted" } }
    ]
  },
  "beneficial_owners": [
    { "name": "R. Vasiliev", "effective_pct": 38.0, "basis": "shareholding",
      "confidence": "medium", "verified_by_registry": false }
  ],
  "trail_ends": [
    { "entity": "Arden Nominees Ltd", "jurisdiction": "JE",
      "reason": "ownership_data_not_public",
      "effect": "effective ownership below this node cannot be computed" }
  ],
  "officers_shared_with_other_entities": 3,
  "as_of": "2026-10-21"
}

Where the data comes from

Official company registries	The authoritative source, with data depth varying from full shareholder filings to name-and-status only
Beneficial ownership registers	Where they exist and remain accessible — several have been restricted following privacy rulings, and many entries are self-declared rather than verified
Open company data initiatives	Aggregated open registry data, useful for breadth and for identifier cross-walking, with licence terms that must be respected on redistribution
Filed accounts and annual returns	Shareholder lists and group structures are often only in the filings rather than in structured registry fields
Securities disclosure filings	Major shareholding notifications for listed entities, which are a stronger source than registries for public companies
Sanctions and PEP reference data	Not ownership data, but the usual downstream consumer — the ownership graph is what makes ownership-based sanctions exposure computable

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Entity resolution across registries using identifiers, addresses, incorporation dates and officer overlap, with the match basis recorded on every link rather than hidden in a score
Transliteration and name-variant handling for persons and companies, which is where naive matching fails hardest and most silently
Graph traversal with cycle detection and effective-ownership computation through multi-layer and circular structures
Explicit trail-end modelling — unresolved nodes, restricted registries and nominee arrangements are recorded as first-class results with reasons, not quietly dropped
Confidence per edge and per beneficial owner, distinguishing registry-verified from self-declared from inferred
Change detection against prior snapshots, since a change of control is usually the event a compliance team needs to act on
Freshness tracking per registry, because annual-filing jurisdictions are stale by design and a current-looking response would be misleading
Validation against known complex structures and against client-verified cases, with accuracy reported per jurisdiction rather than as one figure

What it changes for the business

Faster onboarding

Resolved ownership chains turn a multi-day manual exercise into a reviewable graph with provenance.

Real sanctions exposure

Ownership-based exposure can only be computed if the ownership chain exists in structured form.

Documented diligence

Per-edge registry provenance and explicit trail ends are what an auditor or examiner wants to see.

Monitoring rather than snapshots

Change detection turns a one-off check at onboarding into an ongoing control.

How it fits into your product

How it embeds

REST lookups at onboarding and review time, with the graph returned in a form your UI can render directly
Webhooks on ownership or officer change for entities you have placed under monitoring
Batch resolution for portfolio-wide refresh across an existing customer or supplier book
Provenance fields exposed to the end user, so a reviewer can click through to the registry filing
Screening hand-off so resolved owners can be passed to your sanctions and PEP checks
Deployment inside your infrastructure where customer identity data cannot leave the jurisdiction

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Can you always identify the beneficial owner?

No, and the honest answer is that the gaps are structural rather than technical. Some jurisdictions do not publish ownership at all, some beneficial ownership registers have been restricted following privacy rulings, and nominee and trust arrangements are designed to interrupt the trail. The API returns explicit trail-end records naming the entity, the jurisdiction and the reason. A product that silently returns a partial chain as if it were complete is worse than one that stops and says so.

How current is registry data?

As current as the registry, which in annual-filing jurisdictions means a structure can be a year out of date and still be the official record. Every edge carries a filing date and every response a per-registry freshness note. We would resist presenting a reconstructed graph as a live picture of control.

Is self-declared ownership data trustworthy?

Treat it as a claim, not a verification. Several beneficial ownership registers accept declarations without checking them, and known inaccuracies are common. The API marks whether an owner is registry-verified, self-declared or inferred from filings, because those are materially different levels of evidence and collapsing them would overstate what you know.

Can we redistribute registry data to our customers?

It depends on the registry, and the variation is wide. Some permit commercial reuse under an open licence, some allow display but not bulk redistribution, and some restrict derived products. We establish the position per jurisdiction during discovery and design the output so that permitted and non-permitted fields are handled differently rather than mixed.

Does this do sanctions screening?

Not itself, and it should not pretend to. What it provides is the ownership chain that makes ownership-based sanctions exposure computable — the 50% rule and control tests need a graph. Screening resolved owners against sanctions and PEP lists is a separate step, and we would integrate your existing provider rather than rebuild a list you already license.

All Legal, Compliance & GovTech offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers