What identity verification actually checks, and what it doesn't
A KYC check proves three narrow things at one moment: the identity exists, the evidence for it is genuine, and the person in front of the camera is its owner. It says nothing about intent, and it starts ageing the day it passes.
Charles Archibong, Co-founder
· 6 min read
Key takeaways
- A KYC pass proves an identity exists, the evidence is genuine and the applicant matches it, at one point in time.
- It does not prove intent: a real person with a real ID can still be a money mule or a fraudster.
- How strongly a check passed matters as much as whether it passed. Store the assurance level, not only the verdict.
- Screening, device signals and monitoring cover the gaps a verification leaves by design.
A KYC check proves three narrow things about a new customer, at one moment: that the identity they claim exists, that the evidence they presented for it is genuine, and that the person in front of the camera is the owner of that identity. That is a useful, specific result. It is also where most onboarding teams overestimate what they bought.
It does not prove the person's intentions, that they will still control the account next month, that they are not acting for someone else, or that their circumstances have not changed since the check ran. Knowing exactly where the check stops is what lets you design the controls that start where it stops.
What does a KYC check actually establish?
The clearest public description of the job comes from the US National Institute of Standards and Technology. Its identity proofing guideline, NIST SP 800-63A-4 (opens in a new tab) (published July 2025), splits the work into three steps, intended to ensure "that the claimed identity exists in the real world and that the applicant is the individual associated with that identity". It is a US federal standard, not a rule in African markets, but its vocabulary maps cleanly onto any onboarding flow.
Step | The question it answers | What it looks like in practice |
|---|---|---|
Resolution | Which single person is being claimed? | Capturing a name, date of birth and an ID number that points at one record |
Validation | Is the evidence real and are the details correct? | Reading the document, checking it against the issuing authority's record, or verifying a passport chip's signature |
Verification | Is the applicant the person the evidence describes? | Matching a live selfie against the photo on the record, the chip or the document |
Liveness sits inside the third step. A face match against a photograph of a face proves little; the match matters only if the face was a real person, present during the session.
Why does it matter how a check passed?
Two checks can both return "verified" and carry very different weight. The difference is the source of the evidence.
NIST calls the issuing body, or a service with direct access to its data, an authoritative source. Checking a Nigerian NIN against the government record is validation against the issuer's own data. Reading a driving licence from a country with no database behind it tells you the document looks consistent and its printed details read cleanly; it cannot tell you the licence was ever issued. A passport chip sits at the other end: its data is digitally signed by the issuing state, so a genuine signature proves the data has not been altered since issue.
This is why Myaza Trust Identity Verification attaches an assurance level to every passing verification: chip, gov_db or document, in that order of strength. Government database verification runs in five markets (Nigeria, Ghana, Kenya, South Africa and Côte d'Ivoire). Passports, driving licences and national IDs from other countries verify by document capture and reach the document tier. The Countries and ID types documentation lists the ID types and tiers.
Treat the assurance level as part of the answer. A pass at document tier and a pass at chip tier should not lead to the same limits.
What does a pass not tell you?
Here are the limits that show up in real onboarding decisions. The examples are illustrative.
Intent
A student in Ibadan is paid to open a wallet in her own name and hand over the login. Her NIN is real, her face matches the record, her liveness is genuine. Every check passes because every check is true. A verification answers "is this the person?", never "why are they here?". Mule accounts, first-party fraud and authorised push payment scams all involve real people passing real checks.
Continued control
A pass says who was present when the account was opened. It does not follow the account. If the credentials are sold or taken over a month later, the original verification stays valid and irrelevant. That is a job for login and device signals, and for step-up re-verification when behaviour changes.
Freshness
Evidence ages. Documents expire, people move, and a person who was not on a sanctions list at onboarding can be added later. A verification is a photograph, not a feed.
Existence, outside database markets
At the document tier, a well-made forgery of a real format can read cleanly, because there is no record to contradict it. Document checks catch many forgeries, but they do not turn a document into an authoritative source.
Certainty
Face comparison is probabilistic. Every face-matching system trades false matches against false non-matches at the threshold you choose, and a score a few points either side of the pass mark says more about the photo than the person. NIST's own performance requirements for remote proofing are expressed as error rates, not guarantees.
How should a team read a result?
A verification result carries more than a verdict, and the extra fields are where the limits above become visible.
In Myaza Trust, a submitted verification has two status fields. status is the outcome you act on (for example approved, declined or in_review). checkStatus records what the automated checks found (verified, failed, not_found, error), and neither a workflow rule nor a reviewer ever changes it. When a reviewer approves someone whose selfie narrowly failed, the record shows both facts: approved, and approved despite a failed check. The verification lifecycle documentation explains why that pairing matters to an auditor.
Every non-passing check also carries a reasonCode. identity_not_found (the number is not in the government database) is a different problem from selfie_mismatch, and very different from document_blurry. Route them differently: the first may be a typo or a fabricated number, the second may be an impostor or bad lighting, the third is almost always a retake.
A simple reading order for any result:
Did the checks run? An
erroris a fault on the provider's side and says nothing about the person.What did they find?
checkStatusandreasonCode.How strong was the evidence? The assurance level.
What do your rules say? The workflow's outcome, or a reviewer's decision.
Which controls cover what verification cannot?
Each gap above has a control designed for it. None of them replaces verification; each assumes it has already happened.
Gap | Control that addresses it |
|---|---|
The person is sanctioned, politically exposed or in adverse media | Watchlist screening at onboarding and on a re-screening schedule |
The same person or device is behind many accounts | Duplicate face search within your own customers, and device and IP signals |
The account is taken over after onboarding | Login and session monitoring, and step-up re-verification |
The account is used to move illicit funds | Transaction monitoring rules and case management |
The evidence has aged | Document expiry tracking and periodic re-verification |
The evidence was weak to begin with | Routing lower assurance tiers to review or lower limits |
In a Myaza Trust workflow, these checks can sit in one decision graph that branches on the verification result, the assurance level and the screening outcome, and lands on approve, review or decline.
What should you do with this?
Write down, for your own product, what a pass allows a customer to do and what it does not. A practical starting rule:
A verification pass establishes who the customer is. Use it to open the account.
The assurance level sets how far you trust it. Tie limits or review to the tier, and decide in advance what a
document-tier pass may do.Screening, device signals and monitoring decide what the customer may do next. Do not ask the verification to answer questions about behaviour it was never designed to answer.
Store the evidence as well as the verdict. Keep
checkStatus,reasonCodeand the assurance level alongside the outcome, so you can explain every decision later.
Requirements for customer due diligence differ by jurisdiction, and this article is general information rather than legal advice. The design principle holds everywhere: know exactly what your verification proved, and build the rest of your controls on that line.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
