KYB testing is the work of making sure a business-verification flow behaves correctly before it meets a real applicant. KYB stands for Know Your Business, and the name points at the difference that matters: the subject being verified is an organisation, not a person, and an organisation has layers — owners, controllers, registrations, documents — that a personal identity check never has to cope with.
This article sets out what a KYB flow actually verifies, why business verification is harder than personal verification, how rejection and review should behave, and how to test the whole thing without weakening the controls you are testing.
What is a KYB flow actually verifying?
It is verifying that the organisation is real, that it is what it claims to be, and that the people behind it are who they say they are. A personal identity check answers “is this person who they claim”; a business check answers the same question about an entity and then adds a second question about the humans who control it.
A typical flow therefore gathers several kinds of evidence, and the specific requirements depend on the jurisdiction and on the regulator the onboarding business answers to. In broad terms:
- Existence — evidence that the entity is registered, taken from the register of its country of incorporation.
- Identification — the registration number and any tax or VAT identifier the entity holds.
- Location — evidence of the registered address, and sometimes of an operating address as well.
- Ownership and control — the individuals who ultimately own or control the entity.
- Activity — what the business actually does, and any licence or permit that activity requires.
- Representation — confirmation that the person submitting is entitled to act for the entity.
None of these is a formality, and none of them can be inferred from another. A registered company can have opaque ownership, a licence can be held but expired, and the person filling in the form is frequently not a director.
Why is verifying a business harder than verifying a person?
Three structural reasons, all of which show up as defects in testing.
The first is layering. A person is one subject with one identity. A business may be owned by another company, which is owned by a trust, which is administered in a third country. The flow has to follow that chain far enough to identify the humans at the end of it, and “far enough” is a judgement rather than a fixed number of hops.
The second is that the evidence is distributed. Personal identity documents come from one authority in one country. Business evidence comes from a register here, a tax authority there, and a bank elsewhere, in several languages, with different validity periods and different degrees of public accessibility.
The third is that the verification is not a single event. Ownership changes, addresses change, licences lapse, entities are renamed or restructured. A business that passed verification in one year may present a materially different picture in the next.
What does the applicant have to submit?
That depends on the jurisdiction and on the risk profile the verifying institution applies, but a representative set of requirements looks like this.
| Requirement | What it establishes | Notes for testers |
|---|---|---|
| Certificate of incorporation or equivalent | The entity exists and its name and number are as claimed | Often paired with a recent extract from the register |
| Tax or VAT registration evidence | The entity’s tax identity | May not exist for every legitimate business |
| Registered address evidence | Where the entity is officially located | A utility bill or register extract, depending on the country |
| Ownership or control information | Who ultimately owns or controls the entity | The hardest part to model and to test |
| Identity documents for controllers | That the individuals are real | Triggers a separate personal check |
| Licence or permit | That a regulated activity is authorised | Absent for most unregulated businesses |
The crucial engineering observation is in the last column of the middle rows: several of these items are optional in a way that is legitimate rather than incomplete. A business with no VAT registration is not a defective applicant, and a flow that treats absence as failure will reject a large slice of the real market.
How should rejection and review behave?
As ordinary, expected states rather than as terminal errors. A verification flow that can only end in approval or in a dead end is a flow that will be worked around by the people running it, and working around a control is how control is lost.
Design the outcomes separately. A rejection on documented grounds — a document that does not match the register, for instance — is reviewable and appealable. A request for more information is a resumable state that keeps everything already submitted. A manual review queue is a legitimate outcome, not a failure of automation. And every rejection should carry a reason specific enough to be actionable, because “verification failed” gives the applicant nothing to correct and the support team nothing to explain.
Two properties turn these states from theory into a workable flow. Rejection reasons should be a controlled vocabulary, so that they can be counted, routed and answered consistently. And a rejected application should be resumable: the applicant fixes one document, not the whole submission.
What must not happen is a testing shortcut that disables the checks. Turning off the sanctions, ownership or document checks to make a test pass produces a system whose failures are invisible until they are expensive.
For developers: states, evidence and retention
Model the flow as an explicit state machine — not started, submitted, in review, awaiting information, approved, rejected — with recorded transitions, timestamps and the actor responsible for each. A status field that is a free-text string will drift within a month, and the drift is invisible until somebody tries to report on it.
Evidence needs its own model. Each submitted document should carry a type, an issuer or country, the date it was issued, and an expiry where one applies, because a licence that has lapsed is not evidence even though the file is still there. Separate the document’s metadata from the file itself so that retention rules can act on the metadata without touching the content.
Ultimate beneficial ownership is the part teams underestimate. Model it as a graph — entities and individuals as nodes, ownership and control as edges — even if the interface only ever shows two levels. Flattening it into a few name fields makes the data unusable the first time an ownership structure needs to be re-checked.
Retention and isolation are the other non-negotiables. Verification evidence is among the most sensitive material a business holds, so keep test environments free of real documents and real applicants, and keep production data out of test databases entirely. The synthetic entities produced by the company data generator are the right input for rehearsing this flow: they describe no real business, and the boundaries of synthetic company data article explains why that matters when a screenshot or an export escapes its environment. The wider machinery of synthetic business records is covered in test company data.
Next steps
Write down every state your verification flow can be in, then check whether each one is reachable in a test environment and whether each carries an actionable message for the applicant. Any state that cannot be entered in testing is a state that will first be entered in production. Then rehearse the flow end to end with a generated company from the company data generator and confirm that no step requires you to switch off a control to get through.