Home/Offers/Banking, Payments & Credit/Business Verification API

Banking, Payments & Credit

Business Verification API

Onboarding a business customer means answering the same four questions about a legal entity that exists in a dozen registries, none of which agree on how to spell its name.

Banks
Payment service providers
Fintechs
B2B marketplaces
Lending platforms

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

Verifying a company is nothing like verifying a person. There is no single authoritative record. A trading name differs from the registered name, the registered address is an accountant’s office, the filed officer list is eighteen months stale, and the ownership chain runs through two holding companies in other jurisdictions. Your compliance team resolves this manually, one entity at a time, and it takes days.

The registries themselves are mostly open, and most of them are machine-readable in some form. The difficulty is that each one models a company differently: different identifier schemes, different officer role taxonomies, different rules about what beneficial ownership even means. Reconciling a company across three of them is an entity-resolution problem dressed up as a data-access problem.

What makes this worth building rather than buying is the shape of the cost. Commercial business-verification vendors price per check, which is fine at a hundred checks a month and punitive at fifty thousand. If business onboarding is core to your product, the per-check line becomes one of your larger variable costs, and it grows exactly as you succeed.

Who buys this

Banks, Payment service providers, Fintechs, B2B marketplaces, Lending platforms

Category: Banking, Payments & Credit

What the API returns

What comes back

Canonical company record with registered name, trading names and status
Registry identifiers across every jurisdiction where the entity is found
Current and historical officer lists with appointment and resignation dates
Shareholding and beneficial ownership chains with percentage holdings
Ultimate beneficial owners resolved through intermediate holding entities
Filing history including accounts, confirmation statements and charges
Match confidence per field, so a partial match is never presented as a certainty
Data provenance: which registry each field came from and when it was read

Endpoints

Method	Path	Returns
POST	/v1/companies/search	Find candidate entities from a name, address or partial identifier
GET	/v1/companies/{id}	Canonical record for one resolved entity
GET	/v1/companies/{id}/officers	Current and historical officers with roles and dates
GET	/v1/companies/{id}/ownership	Shareholding chain and resolved beneficial owners
POST	/v1/verify	Verify a supplied company record against registry sources
POST	/v1/monitoring	Register entities for change alerts on status, officers or ownership

Request and response

illustrative

Request

{
  "name": "Northgate Logistics Ltd",
  "country": "GB",
  "address_hint": "Unit 4, Carlisle Road, Manchester",
  "checks": ["identity", "status", "officers", "ownership"],
  "ownership_depth": 4
}

Response

{
  "query_id": "ver_8812044",
  "match": { "confidence": 0.94, "basis": ["name_normalised", "postcode", "sic_code"] },
  "company": {
    "registered_name": "NORTHGATE LOGISTICS LIMITED",
    "trading_names": ["Northgate Freight"],
    "registry": { "jurisdiction": "GB", "number": "08412997" },
    "status": "active",
    "incorporated_on": "2013-02-19",
    "registered_address": "Unit 4, Carlisle Road, Manchester, M12 4RT"
  },
  "officers": [
    { "name": "A. J. Whitfield", "role": "director",
      "appointed_on": "2013-02-19", "resigned_on": null },
    { "name": "S. Okonkwo", "role": "director",
      "appointed_on": "2021-07-04", "resigned_on": null }
  ],
  "ownership": {
    "resolved_depth": 3,
    "beneficial_owners": [
      { "name": "A. J. Whitfield", "effective_pct": 61.0, "path_length": 1 },
      { "name": "Carrow Holdings BV", "effective_pct": 24.0, "path_length": 2,
        "note": "intermediate entity, NL registry" }
    ],
    "unresolved_share_pct": 15.0,
    "unresolved_reason": "nominee shareholder, no beneficial disclosure filed"
  },
  "sources_read_at": "2026-10-21T09:14:00Z"
}

Where the data comes from

National company registries	The authoritative record for incorporation, status, officers and filings; most are open, a few charge per document
Beneficial ownership registers	Where the jurisdiction maintains one and permits programmatic access — coverage is genuinely uneven and some have been restricted since 2022
Filed accounts and charge registers	Financial filings and secured-lending registrations, useful for both verification and credit context
Business identifier schemes	LEI, VAT and national tax identifiers, which give independent cross-checks on the same entity
Licensed commercial registry aggregators	For jurisdictions where direct access is impractical; licence terms decide whether you may cache or redistribute
Your own customer records	Existing verified entities, which materially improve matching because they are already ground truth

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.

Name normalisation that strips legal suffixes, transliterates consistently and handles the twelve common ways a company name is mistyped
Blocking and candidate generation before scoring, so a search does not compare the query to every record in a registry
Probabilistic record linkage across registries with per-field agreement weights rather than an all-or-nothing match rule
Ownership graph traversal with cycle detection, since circular shareholding structures are common and will hang a naive crawler
Effective-percentage arithmetic through intermediate entities, with unresolved share explicitly reported rather than rounded away
Match confidence calibrated against a labelled set of manually resolved entities, not an arbitrary similarity threshold
Change detection on each monitored entity by diffing successive registry reads, which is how status and officer alerts work
Coverage and freshness monitoring per jurisdiction, so a registry that silently stops responding is visible within hours

What it changes for the business

Faster business onboarding

An entity that would take a compliance analyst two days to resolve clears in one call, with the manual cases clearly marked.

Variable cost control

Per-check vendor pricing is replaced by infrastructure you own, which changes the economics as check volume grows.

Auditable decisions

Every field carries its source and read timestamp, which is the form an audit question actually arrives in.

Ongoing monitoring

Officer and status changes surface as events rather than being discovered at the next annual review.

How it fits into your product

How it embeds

Synchronous search and verify endpoints for live onboarding flows, with batch endpoints for portfolio re-verification
Webhooks into your case management system when a monitored entity changes status, officers or ownership
Match candidates returned with confidence so your UI can present a disambiguation step instead of guessing
Per-jurisdiction coverage flags in the response, so your flow can route uncovered jurisdictions to manual review automatically
Deployment inside your infrastructure where customer identifiers cannot leave your environment
Versioned verification records retained so a decision made eighteen months ago can be reproduced as it was made

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 12 weeks

Discovery and data review

Weeks 1–2

We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.

Architecture and prototype

Weeks 3–4

You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.

Production build

Weeks 5–10

Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.

Integration and handover

Weeks 11–12

We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.

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 resolve beneficial ownership everywhere?

No, and anyone who says otherwise is selling you something. Several jurisdictions have no public beneficial ownership register, some that had one have restricted access, and nominee arrangements are legal in many places. The API reports resolved ownership, unresolved percentage and the reason it is unresolved. Routing the remainder to manual review is the honest design.

Is this a KYB product we can rely on for compliance?

It gives your compliance team the evidence to make a decision; it does not make the decision. Whether registry-sourced verification satisfies your obligations depends on your regulator, your risk appetite and your banking partners. That question should be settled before the build, not after.

Can we cache and resell the registry data?

Partly. Most national registries permit reuse of open data with attribution; some restrict bulk redistribution, and commercial aggregators almost always prohibit resale. We check the terms of every source during discovery and design around the ones that do not permit your intended use — which sometimes means a field is fetched live rather than cached.

How accurate is the matching?

On well-structured jurisdictions with a name and postcode, high. On a trading name alone with no address, considerably lower, and the API returns multiple candidates rather than picking one. We measure match accuracy against a manually resolved set during the prototype and report it to you before the full build.

How stale is registry data?

More than people expect. Officer changes must be filed but often are not filed promptly, and annual accounts can be nine months behind the period they describe. Every field carries a read timestamp and, where the registry publishes one, a filing date, so staleness is visible rather than assumed away.

All Banking, Payments & Credit 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