Aadhaar-based onboarding is one of the genuine advantages of building fintech in India. Verifying a customer's identity in seconds, remotely, at near-zero marginal cost is something most markets simply don't have.
It's also the area where we see the most expensive architectural mistakes — and almost none of them are coding errors. They're decisions made in week one, before anyone checked which route the company was actually eligible to use, or what it's allowed to store.
The costly version goes like this: a team builds onboarding around Aadhaar OTP eKYC, launches, grows, and then discovers either that they were never eligible to call UIDAI directly, or that the accounts they opened carry limits nobody designed for, or that they've been storing Aadhaar numbers in a way that isn't permitted. Every one of those is a rebuild of the most sensitive part of the product.
Here's the map.
This is engineering guidance, not legal advice. Aadhaar and KYC rules are set by UIDAI, RBI and the DPDP framework, they change, and how they apply depends on your licence and business model. Everything below should be confirmed with counsel and your regulator before you build on it.
The one thing that decides everything: you probably can't call UIDAI directly
After the Supreme Court's 2018 judgment and the 2019 amendments to the Aadhaar Act, private companies cannot simply demand Aadhaar and call UIDAI's authentication APIs. Direct access is restricted to entities approved by UIDAI as an AUA (Authentication User Agency) or KUA (KYC User Agency), and approval is tied to being a regulated entity or serving a permitted purpose.
Most startups are not eligible directly. The common routes are:
- Through a licensed partner. You integrate as a sub-AUA under an existing AUA/KUA — typically a bank, or a KYC service provider that holds the licence. You get access; they hold the relationship and the compliance obligation, and they audit you.
- Offline verification, which needs no UIDAI licence at all — see below.
- Not using Aadhaar, which is more viable than people assume.
Establish which of these applies to you before designing onboarding. This single fact determines your architecture, your timeline, and your unit economics.
Route 1 — Offline Aadhaar verification (no licence required)
The user gives you the data themselves. Two mechanisms:
Paperless offline eKYC (XML). The user downloads a ZIP from the UIDAI portal, protected by a share phrase they choose, and gives it to you. Inside is a UIDAI-signed XML containing name, date of birth, gender, address and a photo.
Secure QR code. The QR on a downloaded e-Aadhaar or the physical card carries the same signed data, scannable directly.
You verify UIDAI's digital signature on the file. If the signature is valid, the data is authentic and hasn't been tampered with. No live call to UIDAI is involved.
What this gets you: genuine, cryptographically verifiable identity data. Enough for identity verification in a great many use cases.
What it doesn't get you: proof that the person handing you the file is the person it describes. It's a verified document, not a verified human. Pair it with a liveness check or document match if that gap matters.
The catch: UX friction. Asking a user to visit the UIDAI site, generate a file, set a share phrase, download it and upload it to you loses people. The QR route is far smoother when you can capture it in-app.
Verify the signature properly. This is the whole security model. Check the signature against UIDAI's published certificate, confirm the certificate chain, and check the timestamp so someone can't hand you a file generated years ago. A "validation" that parses the XML without verifying the signature is worthless — the file is trivially editable.
Route 2 — Online Aadhaar OTP eKYC
Through your AUA/KUA relationship, the user enters their Aadhaar or Virtual ID, UIDAI sends an OTP to their registered mobile, they enter it, and UIDAI returns their KYC record.
What this gets you: strong assurance. Possession of the registered mobile plus knowledge of the Aadhaar number is a meaningful authentication event, and the data comes straight from UIDAI.
The constraint that catches everyone: for banking, RBI's KYC framework treats OTP-based Aadhaar eKYC as a limited onboarding route. Accounts opened this way carry caps — on aggregate balance, on total annual credits — and must be converted to full KYC within a defined window or they stop working.
That last part is where products break. If you onboard a cohort via OTP eKYC and don't build the conversion journey, you get a cliff: a block of customers whose accounts freeze on a rolling deadline. Design the upgrade path at the same time as the onboarding path, not a year later when the first cohort is expiring.
Confirm the current limits and timelines with your regulator or partner bank. These are set by RBI direction and they change.
Encourage Virtual ID. VID is a revocable temporary number that maps to an Aadhaar number. Accepting VID means the actual Aadhaar number needn't enter your systems, which meaningfully reduces your obligations. Support it.
Route 3 — Video KYC (V-CIP)
RBI-permitted video-based customer identification: a live, recorded video call with a trained agent who verifies the customer's identity and documents in real time, with geotagging and liveness checks.
What this gets you: full KYC, without the account limits attached to OTP-based onboarding. For a bank, NBFC or full-service financial product, this is usually the destination.
The cost: it needs humans. Trained agents, scheduling, recorded-call storage, quality audit, and the operational load of a queue during business hours. Per-customer cost is orders of magnitude higher than either route above.
The pattern that works: a tiered funnel. Onboard fast with a low-friction route to get the customer transacting, then move them to video KYC when their usage justifies the cost — approaching a limit, requesting a product that requires full KYC, or crossing a value threshold. Most customers never need the expensive step; the ones who do are the ones worth spending on.
Two things you should use and probably aren't
CKYC (Central KYC Registry). Run by CERSAI. If a customer has completed KYC anywhere in the Indian financial system, their record may already exist, retrievable with a KYC Identifier. Checking CKYC first can skip the entire collection flow for a returning-to-the-system customer. Regulated entities are also required to upload records. Teams routinely build elaborate onboarding without ever checking whether the work was already done.
DigiLocker. Government-issued documents — including e-Aadhaar, PAN, driving licence, education certificates — fetched with the user's consent, issuer-signed and therefore verifiable. Excellent UX compared to document upload, and it sidesteps forged-document handling entirely. Underused outside large fintechs.
The storage rules that decide your data model
Get this wrong and remediation touches every table you have.
Never store biometrics. Fingerprint and iris data captured for authentication must not be retained. Not encrypted, not briefly, not "for debugging."
Aadhaar numbers are restricted. If you have a legitimate need to retain Aadhaar numbers, the required pattern is an Aadhaar Data Vault — a separate, access-controlled, encrypted store holding the numbers, with the rest of your systems using a reference key that maps to the vault. Aadhaar numbers must not sit in your main application database, your logs, your analytics pipeline, or your backups as plain values.
Mask on display and in transit through your own systems. Only the last four digits should be visible. This applies to admin panels and support tools too — that's where masking is most often forgotten and where the largest number of employees have visibility.
Prefer storing nothing. The best architecture for most products is to verify, extract only the fields you actually need — name, date of birth, address, a verification timestamp and reference — and never retain the Aadhaar number at all. If a regulator asks what Aadhaar numbers you hold, "none" is an excellent answer.
Keep it out of logs. The most common real-world leak isn't a breach — it's Aadhaar numbers in application logs, error traces, or an APM tool, because someone logged an entire request body. Add explicit redaction at the logging layer and test it. Assume any field that passes through a request body will end up in a log unless you actively prevent it.
Consent must be real and recorded. Under the DPDP framework, consent needs to be informed, specific, purpose-limited and revocable. Record what the user consented to, when, and in what wording — including the version of the consent text. "They ticked a box" is not a defensible record if you can't reproduce what the box said on that date.
The audit trail you'll be asked for
Every verification should leave an immutable record containing:
- Which route was used, and when
- The transaction or reference ID returned by UIDAI or your provider
- Which consent text and version the user accepted
- The outcome, and the reason for any failure
- Which internal user or system initiated it
Write these append-only. When an auditor asks how a specific customer was verified two years ago, you need a definitive answer, not an inference from your current database state.
A sequence that doesn't need rework
- Confirm your eligibility and route first. Are you an AUA/KUA, going through a partner, or offline-only? Nothing else can be designed until this is settled.
- Design the tiered funnel. Which route onboards a customer, what limits that imposes, and what triggers an upgrade to full KYC. Design the upgrade path now.
- Check CKYC before collecting anything. Cheapest possible onboarding is the one you don't have to run.
- Model consent as a first-class entity, versioned, with revocation.
- Decide storage before writing schema. Ideally: no Aadhaar number retained. If you must, vault it and reference it.
- Add redaction at the logging layer, and write a test that fails if an Aadhaar-shaped value reaches a log.
- Build the audit trail with the feature, not afterwards.
- Plan for UIDAI and provider downtime. These services have outages. A queued retry with a clear user-facing state beats a hard failure that loses the customer.
Four mistakes that cost the most
Building on a route you're not eligible for. Discovered at launch, this is a full rebuild of onboarding. Confirm eligibility in week one.
Ignoring the limits on OTP-based accounts. Creates a cohort of customers whose accounts hit a wall on a schedule you didn't plan. Build the conversion journey up front.
Storing Aadhaar numbers in the main database. Very common, and remediation means touching every table, backup and downstream consumer. Decide correctly before the first migration runs.
Treating Aadhaar as mandatory. It's voluntary in most private contexts, and forcing it excludes people and creates legal exposure. Always offer an alternative — PAN with another document, DigiLocker, video KYC. Build the alternative path from the start rather than bolting it on after a complaint.
The honest summary
Aadhaar eKYC is genuinely excellent infrastructure, and the technical integration is not hard. The difficulty is entirely in choosing the right route for what you're licensed to do, and in designing storage and consent so you're not remediating the most sensitive data in your business a year from now.
Decide eligibility, tiering and storage before you write schema. Everything after that is ordinary engineering.
If you're also integrating payments, our payment gateway comparison covers the same ground for money movement.
Building something that needs KYC?
We build compliant onboarding for Indian fintech — Aadhaar offline and OTP eKYC, video KYC funnels, CKYC and DigiLocker integration, consent management, and data architecture that keeps you out of trouble. We work alongside your compliance team and counsel rather than around them.
Bengaluru-based, working with clients across India and globally.
Get in touch · See our API integration work · WhatsApp: +91 9677749648