On this page
Short answer. A good KYC flow is progressive. Define risk tiers, capture consent, verify the phone, validate the ID number, run liveness and face match, then decide with a review lane and a full audit record. Ask for more only when the action needs it.
Step 1: Decide your risk tiers first
Do not send every user through the heaviest check. Map what each action needs: browsing, a small transfer, a large withdrawal, a loan. Each higher tier unlocks more and demands stronger proof. This is called progressive KYC, and it protects conversion because most users only ever need the lightest tier.
Failure mode: one flat flow that is too heavy for casual users and too light for high-value actions.
Step 2: Capture consent and show the notice
Before touching any identity data, show what you collect, why, how long you keep it and who processes it. Record the timestamp, the notice version and the IP address. Under the NDPA this record is your evidence.
Failure mode: a pre-ticked box or a notice that does not match what the system really does.
Step 3: Verify the phone number
An SMS or call code ties the account to a reachable device and gives you a channel for security alerts. Normalise numbers to one format, rate-limit sends and block a number that is already linked to another account.
Failure mode: unlimited code sends that turn your signup into an SMS-bombing tool.
Step 4: Validate the identity number
For Nigerian users, a BVN or NIN lookup confirms the number exists and the details match. Remember it does not prove the user owns the number; see our BVN and NIN guide.
Failure mode: rejecting good users over name-order differences. Match names by token and send near-matches to review.
Step 5: Run the biometric check
Capture a selfie and the ID, then run quality, liveness, document read and face match in that order. Give live guidance (lighting, framing, glare) and cap retries.
Failure mode: treating a blurry photo as a failed identity, or allowing unlimited retries that let attackers probe your thresholds.
Step 6: Decide, review and record
| Result | Action |
|---|---|
| Liveness passed, document readable, match well above threshold | Accept and unlock the tier |
| Any score in the borderline band | Send to manual review |
| Liveness failed or match well below threshold | Reject, with a safe retry or support path |
| Capture quality too low | Ask for a better photo, do not count as a rejection |
Store the decision, scores, tier, model version, consent record and a keyed hash of the ID number. Do not keep the images unless a regulator requires it.
Common mistakes across the whole flow
- Doing the verdict in the browser instead of on the server.
- No review lane, so every edge case becomes a support ticket.
- Collecting documents you never use.
- Logging request bodies that contain faces.
- Forgetting that account recovery is also an identity check.
How IDNexus follows the same idea
Our own account journey is progressive: email at registration, then phone verification, then biometric verification with a government ID and utility bill, then an optional passkey. Reaching biometric verification unlocks API key generation. You can model your product on the same ladder, using the API for each rung.
Skip months of integration work
Create an account and test liveness, document and face-match checks against your own flow.
Create account