COMPANYPROOF / IMPLEMENTATION BLUEPRINTS

A clearer KYB process. Five verification workflows.

See how company identity, claim checks and source records fit into real business processes. Use these implementation blueprints to plan the integration, handle exceptions and define what a successful evaluation must show.

Explore five workflows Discuss your implementation

Registry evidence REST API & MCP Claim monitoring

IMPLEMENTATION LIBRARYIllustrative workflows

01 / 05

AI underwriting

Inspect the implementation

01 / YOUR INPUTGenerated company summary
02 / COMPANY EVIDENCESupported identity claims
03 / YOUR WORKFLOWEvidence for the underwriting review

THE BUSINESS QUESTION

Build the company-evidence part of your workflow.

A KYB process connects business identification, relevant company checks, review decisions and ongoing maintenance. The precise checks depend on the organisation, relationship and applicable requirements. The company-verification component establishes which legal entity was reviewed and what the available evidence supports.

The five blueprints below cover AI underwriting, KYB onboarding, credit risk, enterprise research and company-intelligence products. Each describes the input, the integration steps and the record to keep. They are implementation guidance rather than reported customer results.

Use the same four stages across the designs: resolve the company, obtain and check the relevant information, handle exceptions and retain the evidence. Then adapt the decision rules and additional controls to the team that owns the process.

IMPLEMENTATION LIBRARY

Five blueprints. Clear integration steps.

Choose the workflow closest to your use case. Confirm the required countries and fields before automating the decision that follows a company check.

01AI UNDERWRITING

Check the applicant summary before decisioning.

An AI-generated applicant summary contains a legal name, status, incorporation date, parent relationship and revenue figure. The underwriting system needs to know which parts are supported before using that summary in a recommendation.

Implementation

Resolve the applicant in the correct jurisdiction. Submit the supported identity assertions to claim verification, then request available group and financial records for the extended review. Attach the evidence to the application record rather than only retaining the model’s narrative.

Input: original applicant summary and company identifiers.
Review: stop an ambiguous company match; inspect conflicts and missing records.
Output: checked identity claims, extended evidence and a separate underwriting decision.
Measure: correct entity matches, material corrections and analyst review workload.

Explore AI claim checking

02KYB ONBOARDING

Connect business identity to the onboarding case.

An onboarding form contains company details that need verification before the relationship proceeds. Compliance or procurement reviewers also need a consistent place to find the company records and any unresolved questions.

Implementation

Collect the registration number and jurisdiction, resolve the legal entity and compare supported claims with available evidence. Request officer or shareholder records when the review needs them. Pass the resulting record into your existing screening, ownership investigation and approval process.

Input: legal company details and the onboarding case reference.
Review: distinguish identity mismatch, unavailable data and an actual contradiction.
Output: evidence attached to the case, with an owner for each exception.
Measure: identity-match rate, evidence completeness and time spent resolving cases.

Apply the supplier due diligence checklist

03CREDIT RISK

Match a financial assertion to the right period.

A credit review cites revenue or profitability without retaining the financial year, currency or source. The risk team needs to reconstruct the figure and determine whether it describes the applicant, a parent or the consolidated group.

Implementation

Resolve the company and retrieve the available financial module. Compare the assertion with the reporting entity, dates, units and accounting scope. Keep the source context with the value used by the risk model, and record where a required filing or period is unavailable.

Input: company identity, claimed metric, period and expected scope.
Review: separate missing statements from conflicting figures and forecast values.
Output: a financial evidence record connected to the assessment.
Measure: comparable-period coverage, source completeness and corrections requiring review.

Inspect financial data and reporting context

04ENTERPRISE RESEARCH

Preserve the evidence behind a company report.

An analyst or agent prepares a company profile for internal research or a customer deliverable. The material statements need to remain understandable when another analyst revisits the report or the source later changes.

Implementation

Retain the original answer, resolve the company and review supported assertions before publication. Keep the relevant company records and source context alongside the approved answer version. Monitor eligible live claims that remain important after delivery.

Input: company profile, research question and publication scope.
Review: inspect source support for compound claims and historical statements.
Output: an answer linked to its evidence and verification time.
Measure: reproducibility, unresolved-claim rate and handling of monitored changes.

Explore the evidence ledger

05DATA PRODUCTS

Embed company verification in a software feature.

A product team wants company search, profiles and claim-level evidence inside its own application. It needs clear response handling, a consistent entity model and a way to update facts used across several customer workflows.

Implementation

Use company search to select the entity and reuse its identifier for profile requests. Integrate the supported claim-verification contract where the feature evaluates assertions. Model returned, empty, unavailable and restricted data sections separately, then connect relevant proof and change references to your application record.

Input: user-selected entity, requested modules and supported assertions.
Review: respect module status, access requirements and licensed data use.
Output: a source-aware product record with predictable exception handling.
Measure: supported-field completion, integration effort and cost per completed workflow.

Review the API contracts

CONNECT THE STEPS

The verification process in four stages.

Use this sequence as the company-data component of your KYB or enterprise workflow. Keep the business decision in the system that owns it.

01
Resolve the legal entity
Search using the company and jurisdiction, then confirm the intended record. Preserve the identifiers needed to avoid repeating an ambiguous name match.
OUTPUTOne company identity
02
Retrieve and verify
Request the relevant profile data and check supported assertions. Preserve field availability, observed values and source context with the response.
OUTPUTEvidence for the material facts
03
Route the exceptions
Apply your review policy to conflicting claims and incomplete information. Record the additional check or clarification used to resolve each case.
OUTPUTA controlled decision path
04
Retain and monitor
Connect the proof to the case or answer. Enable eligible monitoring where needed and define how your system responds to a change.
OUTPUTEvidence after the first request

THE INTEGRATION CONTRACT

Choose a record request or a claim check.

GET /v2/companies/search resolves company candidates. GET /v2/companies/{id}/profile requests a consolidated company profile and its available modules. Those record interfaces provide observed information for a review or an AI context.

POST /v2/claims/verify evaluates supported assertions. Its deterministic fields are registered name, registration number, company status, incorporation date, VAT or tax ID and legal form. Use the returned verdict and evidence to decide whether your application needs a correction or a reviewer.

MCP exposes documented tools to compatible clients at /v2/mcp. Select the entry point that fits your application, but keep the evidence model consistent across REST, agent and manual workflows. Authentication, parameters and credit rules are described in the API documentation.

Explore the exact API reference ↗Connect an MCP client ↗

EXCEPTIONS & CHANGE EVENTS

Design what happens when the check is incomplete.

Plan the exception paths before enabling an automated next step. An unresolved company needs clarification. A contradicted assertion needs correction or review. An unavailable ownership or financial module needs a visible data-gap state. None of these should silently become a successful assessment.

Separate the verification result from the decision taken with it. Retain the original claim, observed value and evidence reference, then store your review outcome in the application that owns the case. This lets a later reviewer understand why the system proceeded or paused.

Where eligible monitoring is active, a change event can return the affected company fact to review. Secure the webhook receiver, verify signatures, handle retries and duplicate delivery, and assign responsibility for reopening the record. Delivery of an event is the start of your follow-up workflow.

View source evidence and monitoring ↗Review security controls ↗

EVALUATION DESIGN

Compare the same cases before and after integration.

Choose the companies, countries and material questions before reviewing results. Keep a baseline of the existing process, including the cases it cannot resolve and the analyst effort involved. A successful response alone does not establish that the verification improved a business decision.

Review a representative sample of disagreements with an analyst. Measure evidence completeness and exception handling alongside response success. Keep the sample size, exclusions and time window with any outcome you calculate.

Use the results to decide which parts can be automated, which need more source coverage and which should remain with a reviewer. The aim is a repeatable workflow with understood operating costs and decision rules.

MAKE THE RESULT REVIEWABLE

A practical evidence model for implementation.

Keep the result linked to the business object your system already uses: an application, supplier, onboarding case, research answer or product record.

Evidence layer	Information to retain	Why the workflow needs it
Identity	Selected company ID, registered name, registration number and jurisdiction.	Makes every check refer to the intended entity.
Assertion	The original claim, field, context and relevant date or reporting period.	Shows the exact statement being evaluated.
Observed record	Returned value or module, source details and availability state.	Distinguishes a factual comparison from missing or restricted data.
Verification result	Documented verdict, correction, proof reference and check time.	Connects the answer to a reproducible check.
Your decision	Case owner, review outcome, exception reason and linked operational record.	Keeps the business policy separate from the source fact.
Ongoing change	Monitored claim, delivery identifier and follow-up review reference.	Connects a later update to the decision it may affect.

Official company information

Over a decade collecting and structuring official company information. Assess the source and available fields for the companies you actually use.

Explore countries & sources ↗

AN ENTERPRISE EVALUATION

Use a scorecard that reflects the real work.

Choose the measures that match the blueprint. Record denominators and exclusions so a favourable subset of examples does not hide unresolved cases.

Resolution quality

Correct matches divided by the relevant company sample, with ambiguous entities reported separately.

Evidence completion

Material claims or required fields with useful source support, separated by country and module.

Review effort

Time and interventions needed to resolve conflicting claims or missing data.

Workflow economics

Total request, retry, monitoring and analyst costs per completed review.

YOUR COUNTRIES. YOUR COMPANY FACTS.

Turn a blueprint into your integration plan.

Share one workflow, the countries and fields it needs, and representative company records. We’ll help you define the data contract and evaluation criteria.

Discuss an enterprise implementation ↗Compare plans and usage

FREQUENTLY ASKED QUESTIONS

Implementation blueprints: frequently asked questions

What are the stages of a KYB process?

A KYB process generally connects identification of the legal business, relevant company and ownership checks, additional screening or investigation, a review decision and ongoing maintenance. The required scope depends on the organisation and relationship. These blueprints focus on the company-data and evidence component.

Are these customer case studies?

They are implementation blueprints for five enterprise workflows. They describe integration steps and evaluation measures rather than named customer deployments, measured ROI or testimonials. Use them to plan and test your own application.

Which workflow should we evaluate first?

Start with one decision that relies on material company facts and occurs repeatedly in your organisation. Choose a representative sample and define required evidence, exception handling and success measures before broadening the integration.

How do we automate business verification?

Resolve the entity, request relevant company records and submit supported claims through the documented API. Your application handles verdicts, corrections and missing data according to its policy, then retains the evidence and any subsequent review outcome.

What is the difference between company lookup and claim verification?

A lookup identifies a company or returns observed records. Claim verification compares a supported assertion with available evidence and produces a documented result. A successful lookup alone does not verify every statement in an onboarding or research summary.

How should a KYB workflow handle an ambiguous company match?

Pause the dependent checks and obtain enough information to identify the intended legal entity. A registration number and jurisdiction can help distinguish similar names. Do not combine candidate records into a single assessment.

Can the same workflow use ownership and financial data?

Yes, when the required profile modules and source coverage are available. Preserve relationship context, financial periods and availability states. Extended record retrieval is separate from the deterministic identity-claim verification contract.

How do monitoring webhooks fit into the process?

An eligible monitored claim can generate a change event that your receiver routes to the affected case or answer. Verify signatures, handle retries and duplicate deliveries, and define who reviews the change. Your system controls the follow-up decision.

Which metrics should we use in a verification pilot?

Measure correct identity resolution, required-field coverage, evidence completeness, material corrections and review effort. Include request, retry and monitoring usage when calculating cost per completed workflow. Report the sample size and exclusions with each measure.

Where can engineers find the implementation details?

The API documentation describes authentication, company search, profile modules, supported claim requests, usage rules and MCP connection steps. Start with the documented sandbox and representative live records appropriate to your account access and evaluation scope.

CONTINUE YOUR REVIEW

A clearer KYB process. Five verification workflows.

AI underwriting

Build the company-evidence part of your workflow.

Five blueprints. Clear integration steps.

Check the applicant summary before decisioning.

Connect business identity to the onboarding case.

Match a financial assertion to the right period.

Preserve the evidence behind a company report.

Embed company verification in a software feature.

The verification process in four stages.

Resolve the legal entity

Retrieve and verify

Route the exceptions

Retain and monitor

Choose a record request or a claim check.

Design what happens when the check is incomplete.

Compare the same cases before and after integration.

A practical evidence model for implementation.

Use a scorecard that reflects the real work.

Resolution quality

Evidence completion

Review effort

Workflow economics

Turn a blueprint into your integration plan.

Implementation blueprints: frequently asked questions

Enterprise use cases

Claim Verification API

Country and source coverage