Aadhaar vs DigiLocker vs Offline KYC: Which to Use

Build for Indian users long enough and you hit the same fork every team hits: which verification rail do you actually use? Honest answer? It depends. On what you need to prove, on how much data you're willing to store, and on what you're legally allowed to do in the first place. So instead of picking for you, this guide lays the rails side by side and hands you a decision matrix to run against your own product.

We'll cover offline KYC versus eKYC, the privacy and cost trade-offs, who's eligible to use what, and how to put several rails behind a single login so you're not rebuilding from scratch every time a regulator or a product requirement shifts. This is the decision guide. For the nuts and bolts of any single rail, we'll link out as we go.

The rails compared at a glance

There is no single "India KYC" thing. There are a handful of rails, each backed by a different authority, each proving a slightly different fact about a person.

A quick mental model: phone and email OTP prove possession (you hold this number or inbox). Aadhaar and DigiLocker prove identity (you are this named person, per a government record). They are not substitutes. Most products need both a possession check at signup and an identity check before a sensitive action.

For a deeper walkthrough of the document flow, see our DigiLocker API integration guide and the Aadhaar offline e-KYC XML verification how-to.

Privacy and data-stored trade-offs

The single biggest difference between these rails is how much sensitive data you end up holding, and under the Digital Personal Data Protection Act 2023, what you hold is what you are liable for.

Online Aadhaar eKYC returns a full demographic record from UIDAI. It is the richest result and the heaviest to hold. If you store the full Aadhaar number, you are now custodian of one of the most sensitive identifiers in the country, with all the breach-notification and minimisation duties that come with it.

Aadhaar offline e-KYC is the privacy-forward option. The user downloads a UIDAI-signed XML (or scans a secure QR) from their own Aadhaar, and you verify the signature locally. No real-time call to UIDAI, and you choose to keep only what you need. The exact parse-and-verify mechanics are their own deep dive, so we won't repeat them here; our Aadhaar offline e-KYC XML verification how-to covers them step by step. The key design move for this comparison is simpler: store the verification result, not the source document.

That's exactly how NamoID is built. For the Aadhaar offline rail, only the last four digits, a name-hash, and the signature-verification result get stored. The full XML is processed in memory and never persisted. You stay on the right side of DPDP's minimisation principle without writing the crypto yourself.

DigiLocker sits in the middle. It is a consent-driven share of government documents, run by MeitY through the API Setu platform (apisetu.gov.in). The user explicitly authorises which document you receive, which is good for consent hygiene, but you can still end up holding a full document if you persist the response. Treat the pulled document the same way: verify, extract the fields you need, discard the rest.

OTP rails store the least identity data, just a phone number or email, which is also the least you can prove with them.

Whatever rail you pick, DPDP expects you to log who accessed what and when. NamoID writes every state change to an append-only events table, which gives you a regulator-grade trail without extra work. We go deeper on that in DPDP audit trail requirements for engineers. This section is general information, not legal advice.

Cost and user friction

Privacy is one axis. The other two that decide real-world adoption are cost per verification and how many users drop off during the flow.

A few practical notes:

• SMS OTP in India is not free-form. You must send through a DLT-registered template under the TRAI commercial-communication framework (trai.gov.in). NamoID is built to send OTP on a DLT-compliant template path so you are not improvising header and template registration.
• WhatsApp OTP often converts better than SMS because users already live in the app and the message lands reliably. We compare the two in detail in WhatsApp OTP vs SMS OTP in India.
• Truecaller can collapse "enter your number, wait for OTP, type it back" into a single tap for users who have the app, which meaningfully cuts drop-off. See Truecaller verification SDK integration.
• Document rails add a redirect or an upload step, which is where you lose people. Only ask for them when the action genuinely needs identity, not at the first signup screen.

The cost-friction rule of thumb: start with the cheapest rail that proves what you need, and escalate to a document rail only when the user reaches a step that requires it.

Regulatory eligibility

This is the part teams most often get wrong, because the rail you want may not be one you are allowed to use.

Online Aadhaar authentication and eKYC are gated. To call UIDAI's authentication or eKYC APIs you generally need to be (or work through) a licensed Authentication User Agency (AUA) or KYC User Agency (KUA), and the use case has to fit the Aadhaar Act and UIDAI's regulations. Read UIDAI's own ecosystem documentation before you assume you qualify (uidai.gov.in). If you are a typical SaaS or consumer app without that licensing, online eKYC is usually off the table.

Aadhaar offline e-KYC is far more broadly usable, because the user is the one fetching their own UIDAI-signed artifact and handing it to you. You are verifying a signature, not calling UIDAI as an agency. This is why offline KYC vs eKYC is not just a privacy question, it is often an eligibility question, and the offline path is what most non-licensed products can actually ship.

DigiLocker is designed for third-party document pulls with user consent through API Setu, which makes it accessible to a wide range of products without Aadhaar agency licensing (apisetu.gov.in).

OTP and Truecaller carry the lightest regulatory load on the identity side, though SMS still has the DLT obligations noted above.

Layered on all of this is the DPDP Act 2023 and its rules, which govern consent, purpose limitation, and your duties as a data fiduciary regardless of which rail you choose. If you are unsure whether you are a fiduciary or a processor, our explainer on data fiduciary vs data processor is a good starting point. This is general information and not legal advice; confirm your specific eligibility with counsel.

A decision matrix

Pulling it together, here is a way to choose a KYC method by matching the rail to what you actually need to prove.

And as a layered policy rather than a single pick:

• Tier 1, account creation: phone OTP (WhatsApp or SMS) or Truecaller. Cheap, fast, low drop-off.
• Tier 2, identity assurance: Aadhaar offline e-KYC or DigiLocker, triggered only when the user hits a regulated or high-value action.
• Tier 3, licensed flows: online Aadhaar eKYC, only if you are a licensed AUA/KUA and the use case justifies it.

Combining rails behind one login

Here is the design insight that saves the most engineering time: you should not integrate each of these rails separately. You should put them behind one OpenID Connect issuer so your app talks to a single login surface and the rail choice becomes a policy decision, not a code change.

That is the shape NamoID is built for. One OIDC issuer URL gives you discovery and a JWKS endpoint, the OAuth 2.1 authorization-code flow with PKCE enforced on every flow, and rotating refresh tokens. Behind that same issuer sit passkeys (WebAuthn), TOTP MFA, social login, and the India rails: DigiLocker, Aadhaar offline e-KYC, WhatsApp and SMS OTP, Truecaller, and email OTP.

Your application only ever sees standard OIDC. A typical authorization request looks like this, with PKCE:

curl -G "https://YOUR_ISSUER/v1/oauth/authorize" \
  --data-urlencode "response_type=code" \
  --data-urlencode "client_id=YOUR_CLIENT_ID" \
  --data-urlencode "redirect_uri=https://app.example.com/callback" \
  --data-urlencode "scope=openid profile" \
  --data-urlencode "code_challenge=BASE64URL_SHA256_OF_VERIFIER" \
  --data-urlencode "code_challenge_method=S256"

The verification rail that runs inside that flow, OTP today, DigiLocker tomorrow, is configuration, not a rewrite. PKCE is mandatory because OAuth 2.1 folds it in for all clients (oauth.net); if you want the background, see PKCE explained and OAuth 2.1 vs 2.0.

Because everything runs behind one issuer, the audit trail, consent records, and data-residency hint are uniform across rails. Provider tokens are encrypted at rest with AES-256-GCM, orgs are scoped by org_id, and each organization carries a residency hint so India data is built to stay in India. That last point matters under DPDP; we cover it in data localization under DPDP Rule 15. General information, not legal advice.

FAQ

Is offline Aadhaar KYC legal without a UIDAI licence?

Aadhaar offline e-KYC is designed for the user to download their own UIDAI-signed artifact and share it, so verifying that signature does not require AUA/KUA licensing the way live online eKYC does. Online Aadhaar authentication and eKYC are the licensed paths. Confirm your specific use case against UIDAI's regulations and with counsel.

What is the difference between offline KYC vs eKYC?

eKYC usually means a live, online verification against UIDAI that returns a demographic record, and it generally requires agency licensing. Offline KYC means the user supplies a pre-signed UIDAI XML or QR that you verify locally, with no real-time UIDAI call. Offline is more privacy-friendly and broadly usable.

Should I store the full Aadhaar number after verification?

Generally no. DPDP's data-minimisation principle pushes you to keep only what you need. NamoID is built to store just the last four digits, a name-hash, and the signature-verification result, processing the full XML in memory and never persisting it.

Can I use more than one verification rail in the same product?

Yes, and most products should. A common pattern is a cheap possession check (phone OTP or Truecaller) at signup, then an identity rail (DigiLocker or Aadhaar offline) only when a user reaches a regulated action. Putting them behind one OIDC issuer keeps your app code unchanged as the rail changes.

Talk to us

NamoID is built to give you all of these rails behind a single OIDC issuer, with DPDP-grade auditing and India-first data residency baked in. The product ships in a few weeks. If you want to walk through which rails fit your product, book a demo at https://calendly.com/polymindslabs/30min or reach the team at hello@namoid.in.