Know your business verification: separate identity proof from entity proof

Know your business verification should now be designed as three related evidence decisions: the legal entity exists, the ownership or control picture is sufficiently understood, and the person acting for the company is allowed or required to be identity-verified. Recent registry guidance on in-person identity proofing makes that separation operational, not theoretical: an individual can have a valid personal code, a role can still need that code to be linked to a filing, and a company record can remain active while a role-holder’s verification window is still moving.

This matters for product, compliance, credit and data teams because many KYB flows still present a single result: approved, referred or rejected. That result may be useful for an onboarding queue, but it is too coarse for evidence. A company can be active on a register while its ownership chain is incomplete. A beneficial owner can be reported by an applicant but not independently corroborated. A director can have proved identity once, yet still need to associate that proof with each relevant company role.

The stronger implementation question is therefore: how should a KYB system record different proof states when official registers, applicant data and policy deadlines do not answer the same question? The answer is to store claim-level evidence states, not just a company-level pass. Retrieval says the system reached a source. Verification says a source supported a defined claim. A complete compliance decision may still require screening, risk scoring, reviewer judgement and controls outside the company-data record.

Know your business verification starts with a legal-entity claim: name, registration number, jurisdiction, entity type, status and sometimes registered address. Current KYB explainers usually describe this as checking official records, then mapping ownership and screening the entity and relevant people. That is a sensible overview, but it leaves a design gap for enterprise systems: the same word “verification” is being used for at least three different evidence tests.

The first test is existence and status. Here the object is the legal person: does the entity exist in the stated jurisdiction, under this identifier, and is it active, dissolved, struck off or otherwise restricted? The second test is ownership and control. Here the object is usually a natural person, but the evidence may pass through legal entities, trusts, exemptions, thresholds and self-reported filings. The third test is authority or role-holder identity. Here the object is not simply “the owner”; it may be a director, PSC, filer, agent, applicant or person authorised by the customer to act.

The top current pages for this search intent explain KYB stages and why business verification is harder than individual verification. Their unanswered enterprise question is more specific: when a source confirms one layer but not another, what should the data model do? A practical model must preserve the scope of the evidence. “Active company” should not imply “owners verified”. “Owner supplied” should not imply “natural person independently verified”. “Identity proved” should not imply “authorised for this company role” unless the role linkage is also evidenced.

This distinction also keeps markets separate. In the US, the federal beneficial-ownership reporting reset means many domestic-company workflows cannot rely on a broad central federal ownership filing as the default evidence source. In the UK, role-holder identity requirements are being phased through registry processes and deadlines. Both developments point to the same implementation lesson: KYB systems need field-level provenance, not just a country-level rule.

A useful know your business result should state what happened to each claim. The difference between missing and contradictory evidence is especially important. Missing evidence means a required source did not provide the value, the source was unavailable, the value was not public, or the obligation had not yet arisen. Contradictory evidence means two sources, or a source and applicant statement, assert different values about the same claim. Those cases should not share the same queue reason.

For implementation, treat each company fact as a small evidence record: claim, expected source, observed value, retrieval time, source-update time where available, verdict and next action. The verdict can be narrower than the business decision. A beneficial-owner name can be “unsupported” while the entity existence claim is “supported”. A role-holder identity claim can be “not yet due” while the confirmation-statement deadline is still in the future. A company registration number can be “matched” while the trading name remains “unresolved”.

A clean state model is also less brittle when rules change. If a later source removes, narrows or changes a reporting obligation, the system can reopen the affected ownership-evidence claims without invalidating unrelated facts such as incorporation date or registered status. That is the difference between stale-fact monitoring and re-running an entire onboarding file every time a register changes.

• Retrieved: a source was reached and a record, document or no-result response was captured. This is not verification by itself.
• Supported: the source backs the specific claim being used in the workflow, such as company number plus legal name.
• Unsupported: the expected source does not confirm the claim, but it does not positively contradict it.
• Contradictory: two relevant records give incompatible values, such as different legal names for the same identifier.
• Unavailable: the source cannot provide the data because it is not public, not collected, restricted, offline or outside the jurisdictional scheme. Unsupported and unavailable should not be treated as the same state.

Consider a hypothetical procurement onboarding on 2 October 2026. The buyer is a US-headquartered payments platform adding a UK software supplier called “Northstar Analytics Ltd”. The entity name is fictional. The jurisdiction is England and Wales. The evidence sources for the example are the UK registrar’s public company record, role-holder identity guidance, the supplier’s submitted director information and the buyer’s own procurement questionnaire. Retrieval is the act of collecting those records on 2 October 2026; verification is the narrower act of deciding whether a particular source supports a particular claim.

The supplier gives a company number, legal name, registered address, one director and one person with significant control. The registry profile supports the legal-entity claim: the number and name match and the company is active. That does not finish the KYB review. The beneficial-ownership claim still needs a control assessment, and the role-holder identity claim must be evaluated against the applicable verification timing. If the controller has a 14-day period that has not yet started, the right state is not “failed”. It is “not yet due”, with a scheduled recheck. If the controller’s date of birth does not match the personal-code record, the state is “exception”, not a generic rejection.

The evidence ledger should therefore store three rows, not one. Row one: entity existence, supported by the registry profile, retrieved on 2 October 2026. Row two: ownership and control, partly supported by public PSC data and applicant-supplied confirmation, with reviewer follow-up for any corporate shareholder or threshold ambiguity. Row three: role-holder identity, deadline-aware, with the next action driven by the individual’s role and due date. CompanyProof can support this pattern by keeping the evidence beside the individual company facts rather than reducing the file to a bare approval label.

The same example shows why official evidence is necessary but not sufficient. A public register can show a filed role; it may not prove commercial authority to sign a contract. A personal code can show an identity-verification event; it does not prove that the person approved the purchase order. A questionnaire can explain the supplier’s structure; it is not independent proof unless matched to records. The review should state what each source establishes and what remains a business or compliance judgement.

• Entity claim: legal name, company number, jurisdiction and status are checked against the official company record.
• Ownership claim: controllers are mapped from public records and applicant evidence, with corporate layers escalated rather than treated as natural-person owners.
• Role-holder identity claim: director or controller identity status is recorded with the relevant deadline, not converted into a permanent pass.
• Authority claim: signing authority is treated as a separate commercial-control question unless the evidence specifically supports it.

The main implementation decision is where to draw the boundary between the data layer and the approval layer. The data layer should not decide that a company is safe. It should say which facts are supported, which facts are stale, which facts conflict and which facts remain unknown. The approval layer can then apply policy: low-risk supplier, regulated customer, high-risk jurisdiction, credit exposure, sanctions screening result or enhanced due diligence trigger.

For engineering teams, the minimum viable design is a claim table connected to sources and events. Each claim needs an owner in the product domain: onboarding, credit, compliance, procurement or data quality. Each source needs a retrieval timestamp and, where possible, a source-publication or source-update timestamp. Each exception needs a reason code that a reviewer can understand without reading raw filings.

For compliance teams, the most important control is evidence freshness. A fact can be correct at onboarding and stale after a filing, ownership change, strike-off, merger, identity-verification deadline or rule change. Refresh cadence should therefore be tied to claim risk. Entity status may need frequent monitoring for active suppliers and borrowers. Ownership may need refresh at renewal, transaction thresholds or control-change signals. Role-holder identity may need deadline-based rechecks during a transition period.

• Define claim families before choosing data fields: entity identity, registration status, ownership, control, role-holder identity, authority, financial filings and risk-screening inputs.
• Record source scope: official register, applicant statement, document image, screening list, financial filing, agent confirmation or internal reviewer note.
• Separate time fields: retrieval time, source effective date, filing date, review date and next scheduled refresh.
• Use exception codes that explain action: no match, multiple matches, source unavailable, not yet due, missing document, contradictory owner, stale filing or reviewer override.
• Keep reviewer decisions auditable: a manual approval should not erase the unsupported evidence state that made review necessary.

A KYB decision table should not try to turn every issue into high risk. It should route the next action. A typo in a trading name is different from a dissolved legal entity. A corporate shareholder is different from a missing natural-person controller. A filing deadline that has not arrived is different from a missed filing. The table below is deliberately operational: it tells the system what to do next rather than pretending the source has answered the entire compliance question.

This approach also reduces false certainty in automated KYB. If an API returns a matched entity but no public ownership, the product should not silently infer that no owners exist. If a source says a role-holder has proved identity once, the product should not infer authority across every company role. If a filed account is old but still the latest statutory account available, the product should mark freshness separately from contradiction. That makes exceptions reviewable and prevents a stale-data problem from becoming an unexplained rejection.

• Exact identifier match, active status, no ownership data available: approve only the entity-existence claim; route ownership to applicant evidence or enhanced review.
• Name match but registration number mismatch: do not merge records automatically; require jurisdiction, address, officer or document corroboration before resolving.
• Natural-person owner supplied by applicant but not visible in public filings: record applicant-supplied ownership, mark independent corroboration as unavailable or unsupported, and apply the relevant policy threshold.
• Role-holder identity deadline not yet reached: schedule a recheck and avoid treating the company as non-compliant solely because the future checkpoint has not arrived.
• Latest financial filing is old but not overdue under the jurisdiction’s rules: mark it as latest available and assess freshness separately from filing default.

Evidence-led KYB still has limits. A public register may be accurate for statutory purposes but incomplete for the question a lender, marketplace or procurement team is asking. Beneficial ownership can be held through layers, thresholds and control rights that are not visible in a simple company profile. Filed accounts can be comparable only after checking period length, currency, consolidation and restatements. Identity proof for a role-holder does not answer sanctions, creditworthiness, authority or performance risk.

The safest wording in a product is therefore precise. Say “company registration supported by official record retrieved on this date”, not “company verified” if the user might infer ownership, authority and compliance approval. Say “ownership evidence incomplete”, not “owner failed verification” when the public source does not collect the relevant field. Say “contradictory address evidence” when two sources disagree. Those distinctions help users take the right action and help auditors understand what the system knew at the time.

Monitoring should follow the claims that can change. Entity status and filing defaults can change when a registry updates. Ownership and control can change when shares move or new control rights appear. Role-holder identity can change when a deadline passes, a code is linked to a role, or a rejected identity process is corrected. In long-running customer and supplier relationships, the review plan should be event-driven as well as periodic.

The editorial conclusion is simple: a good KYB workflow is not a single search box and a green tick. It is an evidence model that says what was checked, what was supported, what remains unknown and what will reopen the decision. That model is more resilient across the US, UK and other markets because it can absorb different registry rules without pretending they all publish the same facts.