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? It depends on three things: what you need to prove, how much data you're willing to store, and what you're legally allowed to do. 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.

NamoID's current Aadhaar offline-XML adapter verifies and returns parsed data without creating a persistent verification record. That minimizes storage in this flow, but customers still need to review response handling, logs, purpose, and retention end to end.

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, keep enough evidence to explain access and processing. NamoID emits scoped audit events for security-sensitive lifecycle actions, but customers still need application, provider, and infrastructure evidence. 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 environment issuer gives you OIDC discovery, JWKS, authorization code with PKCE S256, and rotating refresh tokens. Passkeys, TOTP MFA, social login, and selected India-provider adapters share the same control plane, with provider-specific rollout and approval boundaries.

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.

Putting selected adapters behind one environment issuer can reduce application integration work, but it does not make every provider's consent, evidence, or data path identical. Provider tokens are encrypted at rest with AES-256-GCM and data is tenant-scoped. Primary production infrastructure runs in AWS Mumbai; optional providers and subprocessors may process data elsewhere. We cover that distinction 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. Keep only what your stated purpose requires. NamoID's current endpoint validates and returns parsed data without writing a verification record; the calling application must also prevent unnecessary persistence and logging.

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 has selected India-provider adapters alongside Hosted Auth and OIDC. Availability, credentials, approval, persistence, and audit coverage vary by rail; review those boundaries before production rollout.