Know Your Business programmes tend to grow by accretion. A document gets added after an incident, nobody removes anything, and after two years the checklist is long without being strong. These are the gaps that show up most often, and what closes each one.
1. Verifying the entity but never the person
This is the most common and the most consequential. Teams confirm the company exists, the GSTIN is active and the PAN is valid, and never establish who is actually submitting the application or whether they are authorised to.
A company is not a person. When something goes wrong, enforcement, recovery and reporting all need an individual. If the file contains only entity records, you have documentation without accountability.
Three distinct questions people conflate
- Does this entity exist and is it active? Answered by registry and tax lookups.
- Who is authorised to act for it? Answered by the register of directors or partners, or a board resolution.
- Is the person in front of me one of those people? Answered by verifying the individual and matching them to the authorised list.
Programmes routinely answer the first, sometimes answer the second, and rarely answer the third. The third is the one that stops someone opening an account in a real company's name.
2. Treating a collected document as a completed check
Uploading a certificate of incorporation proves a file was uploaded. It does not confirm the certificate is genuine, current, or related to the applicant. A checklist that tracks collection rather than verification will look complete while establishing very little.
- Verify against the source register where one exists, rather than reading the document the applicant supplied.
- Record the verification result, not just the file reference.
- Make the completion state 'verified' rather than 'received'.
- Where only a document exists, say so explicitly in the record — 'document on file, not independently verified' is a different assurance level and should read as one.
3. Running every check on every applicant
Applying the heaviest check set uniformly feels rigorous and is usually counterproductive. It slows every applicant down, costs the same for a low-risk sole trader as for a complex structure, and trains reviewers to click through.
Tiering is not a loophole. It concentrates scrutiny where the risk sits rather than spreading it evenly over cases that do not need it.
| Tier | Typical profile | Check depth |
|---|---|---|
| Low | Small sole proprietor, low expected volume | Entity and tax identity, account verification |
| Standard | Established private company, moderate volume | Adds signatory identification and sanctions screening |
| Enhanced | Complex ownership, high volume, higher-risk sector | Adds beneficial ownership tracing and source-of-funds review |
What the tiering criteria should be
The criteria matter more than the number of tiers. Written down, applied consistently and reviewed, three tiers work. Undocumented, any number of tiers is just inconsistency with a label.
- Expected transaction volume and value, which is the most predictive single input.
- Ownership complexity — layered or cross-border structures warrant more work.
- Sector, where your own policy identifies higher-risk activities.
- Geography, both of the entity and of its expected counterparties.
- Whether any single check already returned something that did not reconcile.
Build in an escalation path in both directions. A low-tier applicant who trips a screening hit should move up; a high-tier one who clears everything cleanly over time can move down at review.
4. Stopping at the first layer of ownership
Where a company is owned by another company, recording the immediate parent and stopping there leaves the actual controlling party unidentified. Layered ownership is ordinary in legitimate structures and is also the standard way to obscure control.
Trace through to the natural persons who ultimately own or control the entity, and record the chain you followed. If you cannot complete the chain, that itself is the finding — note it rather than leaving the field blank.
5. Verifying once and never again
Onboarding checks capture a moment. Directors change, registrations lapse, businesses are sold, and sanctions lists are updated continuously. A file verified three years ago describes a business that may no longer exist in that form.
- Set a refresh cycle proportional to the risk tier rather than reviewing everything annually.
- Trigger a review on material events: a new signatory, a change of registered name, a new payout account, or a sharp change in volume.
- Re-screen against sanctions and PEP lists on a schedule, since those lists change even when your customer does not.
- Treat a long dormancy followed by sudden activity as its own trigger.
The specific events worth re-checking a GST registration on are set out in the GST verification workflow.
6. Making the decision unexplainable
The question that eventually arrives is not 'did you check?' but 'why did you approve this one?'. Answering it needs the inputs, the results, the thresholds in force at the time, and who decided.
What a defensible record contains
- Which checks ran, when, and against which identifiers.
- What each returned, stored as received rather than summarised.
- The thresholds and policy version in force at that moment.
- The decision, the decider, and their stated reason.
- Any override, with who authorised it and on what grounds.
The policy version matters more than people expect. Without it, a decision that was correct under last year's thresholds looks like an error under this year's, and you have no way to show otherwise.
7. Designing for rejection rather than resolution
Most failed checks are data problems: a trade name typed instead of a legal name, an old address, a transposed digit. A flow that treats every failure as a decline loses legitimate customers at the exact moment they were ready to start.
- Separate 'did not match' from 'is not acceptable'These are different outcomes and should take different paths through your system.
- Show the applicant what to fixWhere it is safe to do so, naming the field that did not reconcile turns a dead end into a correction.
- Give reviewers both values side by sideMost mismatches are obvious in a second to a person who can see what was submitted and what was returned.
- Keep the application openA pending state that can be resolved beats a rejection that has to be restarted.
- Measure the recovery rateTrack how many queued applications eventually complete. If that number is low, the queue is a rejection mechanism wearing a different name.
Making the programme operable
A KYB policy that is correct on paper and impossible to run produces exactly the failures it was written to prevent, because the people operating it will find shortcuts. These are the operational details that decide whether the policy survives contact with a queue.
- Name an owner for every check. 'The team reviews it' means nobody does when the team is busy.
- Set a target turnaround and measure against it. A review queue with no service level becomes a holding pen.
- Give reviewers the authority to approve, not only to escalate. A queue where everything escalates has moved the bottleneck rather than removed it.
- Make the policy document shorter than people expect. A forty-page policy is not read; a four-page one with a decision table is.
- Review the overturn rate, both ways. Reviewers rubber-stamping and reviewers rejecting everything are both failures of calibration rather than of individuals.
What to report, and to whom
| Measure | Who needs it | What it reveals |
|---|---|---|
| Applications by outcome | Product and compliance | Whether the funnel is losing legitimate customers |
| Time in review | Operations | Whether the queue is staffed for the volume |
| Overturn rate | Compliance | Whether the thresholds are calibrated |
| Checks per tier | Finance | Whether the risk tiering is controlling cost |
| Post-onboarding incidents | Everyone | Whether any of this is actually working |
The last row is the only one that measures the programme's purpose rather than its activity, and it is the one most rarely tracked. Everything above it describes how hard you are working; only incidents after onboarding tell you whether the work was effective.
Frequently asked questions
What is the single most important KYB check?
Identifying and verifying the individual who controls the entity. Entity checks are easier and cheaper, but without a person attached you have documentation rather than accountability.
Is risk-tiering compliant, or does everything need the same checks?
A risk-based approach is the normal foundation of AML programmes: scrutiny should be proportionate to assessed risk. What matters is that the tiering criteria are documented, applied consistently, and reviewed — not that every applicant receives identical treatment.
How far should beneficial ownership be traced?
Through to the natural persons who ultimately own or control the entity, recording the chain. Where the chain cannot be completed, record that as a finding rather than leaving it blank.
Is control the same as shareholding?
No. Control can come from board appointment rights, a shareholders' agreement, or simply being the person who directs the entity. A purely percentage-based trace misses all of those.
How often should existing customers be re-verified?
On a cycle set by risk tier, plus on material events — a new signatory, a changed payout account, a sharp volume change. Sanctions and PEP screening should run on its own schedule, because those lists change independently of your customer.
What should an audit record contain?
Which checks ran and when, what each returned as received, the thresholds and policy version in force at the time, the decision and decider with their reason, and any override with its authorisation.
How do I know whether my review queue is working?
Measure how many queued applications eventually complete. A low recovery rate means the queue is functioning as a rejection mechanism rather than a resolution path.
