If you run onboarding for a lender, a wallet or a marketplace, you have seen the pattern. A user signs up, gets through four screens, and then the verification step ends in “failed.” Most never come back.
The uncomfortable part is that many of these users are genuine. They have real PANs, real Aadhaar numbers and real faces. The check failed anyway, and the reason was often something small.
This article covers why KYC verifications fail in practice, which causes are the user’s fault, which are yours, and what to do about each.
First, separate real fraud from false rejections
Teams tend to lump every failed check into one bucket. That hides the problem. A rejection falls into one of three categories:
- Genuine mismatch or fraud: the data doesn’t belong to the person. Correct rejection.
- User error: typos, wrong document, bad photo. Recoverable with better guidance.
- System or source failure: an upstream database was down, a request timed out, a format wasn’t parsed. This one is on you, and it’s recoverable too.
If your logs only say “KYC failed,” you can’t tell these apart. The first fix is almost always better failure reason codes.
The most common reasons KYC verification fails
1. Name mismatch
This is the biggest one. The name on PAN says “RAJESH KUMAR SHARMA,” the Aadhaar says “Rajesh K Sharma,” and the user typed “Rajesh Sharma” into your form. A strict string comparison rejects all three combinations.
Initials, expanded middle names, reordered words, honorifics and spelling variations (Mohammed, Mohammad, Md.) are everywhere in Indian records. The answer is fuzzy matching with a tuned threshold and a manual review queue for borderline scores, instead of a hard pass/fail.
2. Inoperative or unlinked PAN
PANs that haven’t been linked with Aadhaar can be marked inoperative, and verification against such a PAN may fail or return a status you aren’t handling. Many teams only check whether a PAN is valid in format, not whether it is operative. Check the status field, and tell the user clearly what to do next. Confirm the current rules with the Income Tax Department before you build messaging around them.
3. Aadhaar OTP never arrives
Aadhaar-based OTP verification only works if the user’s mobile number is linked to their Aadhaar. A user with an old number, or one who never updated it, will wait for an SMS that is never coming. They blame your app. Offer an alternative route, such as DigiLocker or an offline method, before they give up.
4. Date of birth mismatches
Older records sometimes carry only a year of birth, or a placeholder date like 1 January. If the user enters their real birthday, the match fails. Where possible, compare against the source document instead of the user’s memory.
5. Poor image quality
Blurry photos, glare on laminated cards, cropped corners, shadows and dark rooms cause OCR errors. A model reading “8” as “B” in an ID number produces a failure that looks like a data problem. Add live capture guidance (frame outline, glare warnings, auto-capture when the image is sharp) instead of letting users upload whatever’s in their gallery.
6. Face match and liveness failures
Selfie checks fail for ordinary reasons: a decade-old ID photo, new glasses or a beard, low light, a cheap front camera. Strict thresholds catch spoofing but also reject real people. Tune per risk level, and give users two or three attempts with specific prompts before routing to video KYC or manual review.
7. Expired, invalid or mismatched documents
Expired driving licences, passports missing the address page, and documents that don’t match the type the user selected all lead to rejection. A short pre-check (“this looks like a PAN, but you selected Voter ID”) saves a failed API call and a frustrated user.
8. Address inconsistencies
Current address versus the address on Aadhaar or other proof is a frequent trigger, especially for migrants, renters and students. If your policy allows it, accept a separate current-address proof instead of forcing an exact match with the permanent one.
9. Source downtime and timeouts
Sometimes nothing is wrong with the user. A government or bank source is slow, a request times out, and your system records a failure. Without retry logic and an explicit “source unavailable” status, you end up rejecting valid users on a bad afternoon.
Rejection reasons at a glance
| Rejection reason | Typical cause | Whose problem? | Practical fix |
| Name mismatch | Initials, spelling variants, word order | Mostly system (matching logic) | Fuzzy match with threshold, manual review for borderline |
| Inoperative PAN | PAN not linked with Aadhaar | User | Check status, show clear next-step message |
| Aadhaar OTP failure | Mobile not linked to Aadhaar | User | Offer DigiLocker or offline alternative |
| DOB mismatch | Placeholder or year-only dates in records | Data | Compare against source document, not manual entry |
| Poor image quality | Blur, glare, cropping, low light | User, but preventable | Guided live capture, auto-capture on clarity |
| Face match failure | Old photo, lighting, appearance change | Mixed | Tune thresholds, allow retries, fallback to video KYC |
| Invalid or expired document | Wrong type, expired, missing pages | User | Document-type pre-check before submission |
| Address mismatch | Current vs permanent address | Policy | Accept alternate current-address proof |
| Source timeout | Upstream downtime or slow response | System | Retry logic, “unavailable” status, queue and re-run |
How to reduce failures without loosening your controls
Lower rejection should not mean weaker verification. A few changes cut failures without opening a hole.
Log reasons, not outcomes. Record the specific failure code for every rejected attempt. After two weeks you will probably find that two or three reasons account for most drop-offs.
Fix the form before the API. A large share of “failed KYC” is bad input. Validate PAN format, mask Aadhaar entry, auto-capitalise names and warn before submission.
Build a retry and fallback path. Primary method fails, secondary method tries. OTP fails, offer DigiLocker. Selfie fails, offer video KYC. Users who have a way forward keep going.
Review the borderline band. For cases that sit just below your match threshold, a human reviewer clearing them in minutes recovers real customers. Track how many of them turn out to be genuine. That number tells you if your threshold is too tight.
Watch your regulatory footing. KYC rules differ by sector. If you are an RBI-regulated entity, your KYC Master Direction obligations and your approved methods decide what you can accept. Data handling falls under the Digital Personal Data Protection Act, 2023 as well. When in doubt, ask your compliance team before changing a flow.
What to measure
You can’t improve what you only count as pass or fail. Track these weekly:
- Pass rate by verification method
- Failure rate by reason code
- Retry-to-success rate (how many users recover after a failure)
- Time to verify, and drop-off at each step
- Manual review volume and approval rate
The bottom line
KYC failures usually look like fraud prevention work. In reality, a big part is a mix of unforgiving matching logic, poor capture experience and unhandled edge cases. Fix those and your approval rate rises while your risk posture stays where it was.
Start by finding out why your users are failing, and then decide what to change.
Leave a Reply