Aadhaar, VID, Masked Copy or Offline e-KYC: What to Collect

There are four different things an Indian institution can hold in place of an Aadhaar number, and they are not interchangeable. Choosing the wrong one is the most common reason a KYC file contains more identity data than the organisation is entitled to keep.

Most KYC teams treat "collect Aadhaar" as a single instruction. It is not. Depending on what you are licensed to do and what you actually need the document for, the right artefact is one of a photocopy of the card, a masked copy, a Virtual ID, or UIDAI's offline e-KYC XML — and the gap between the best and worst choice for a given use case is substantial.

The four artefacts

Laid out plainly, because the differences matter more than the names suggest.

Artefact	What it contains	Verifiable by you?	Revocable by the holder?
Full Aadhaar copy	12-digit number, name, DOB, address, photo	Only if you are a registered authentication or KYC user agency	No
Masked Aadhaar copy	Last 4 digits only, plus name, DOB, address, photo	No, and it is not intended to be	No
Virtual ID (VID)	16-digit temporary identifier mapping to an Aadhaar number	Only via UIDAI, same authorisation required	Yes — the holder can regenerate it
Offline e-KYC XML	Digitally signed name, DOB, gender, address, photo, and a reference ID	Yes — the signature is checkable without UIDAI authorisation	n/a

The column that should change how you think about this is the third one. Three of the four artefacts cannot be verified by an organisation that is not registered with UIDAI. The fourth can, because it carries a digital signature you can validate yourself.

Virtual ID: the one most people misunderstand

A Virtual ID is a 16-digit number a resident generates from UIDAI's portal. It maps to their Aadhaar number, can be used in place of it for authentication, and can be regenerated at will — which invalidates the previous one.

That last property is what makes VID genuinely useful and also what makes it a poor thing to store as a customer identifier. If you file a VID against a customer record and they regenerate it next month, your stored value now maps to nothing. It is not a stable key. Teams that adopted VID as a "safer Aadhaar number" and wrote it into their customer master have generally discovered this the hard way, some months later, during a reconciliation.

VID is designed for the moment of authentication, not for the filing cabinet. If you are authorised to authenticate, use it and discard it. If you are not authorised to authenticate, VID buys you nothing over a masked copy — you cannot check it either way, and you are now storing a 16-digit number that maps to an Aadhaar number, which is not meaningfully less sensitive than storing the Aadhaar number.

Offline e-KYC XML: verified data without the number

This is the artefact most under-used relative to how well it fits the common case, and it deserves more attention than it gets in KYC design discussions.

A resident downloads a ZIP from UIDAI containing an XML document, protected by a share code they choose. The XML carries their name, date of birth, gender, address and photograph, and it is digitally signed by UIDAI. Crucially, it does not carry the Aadhaar number — it carries a reference identifier instead.

What that gives you is the thing most KYC processes are actually trying to obtain: demographic data whose accuracy you can prove, because you can validate UIDAI's signature yourself without being registered as an authentication agency. Compare that to the standard flow, where you accept a photocopy, cannot verify anything on it, and store a number you cannot use — the offline XML route gives you more assurance and less liability at the same time.

The catch is friction. The resident has to generate it, choose a share code, and hand you both. That is a real onboarding cost, and it is why plenty of institutions accept a document scan instead. But if the reason you are collecting Aadhaar is to establish name and address with confidence, the XML does that and the photocopy does not.

Masked Aadhaar: the filing default

For everything else — the large category of "we need a copy of an identity document on file" — the masked copy is the correct artefact, and UIDAI provides it directly as a download option alongside the full e-Aadhaar.

It shows the last four digits, which is enough to reconcile the document against a record you already hold, and it omits the eight digits that turn the number into a cross-database lookup key. If your process is filing rather than verifying, this is not a compromise. It is the right level of data for the purpose, which is what data minimisation means in practice rather than in policy documents.

Which to collect, by use case

What you are actually doing	Collect	Why
Filing an ID document against an existing customer record	Masked copy	Last four digits reconcile; the rest is unusable by you
Establishing name and address with provable accuracy	Offline e-KYC XML	Signature is verifiable without UIDAI registration; no Aadhaar number retained
Performing authentication, and you are a registered agency	VID at the point of use	Revocable by the resident, and there is no reason to retain it afterwards
Subsidy or benefit delivery under Section 7 of the Aadhaar Act	As the statute specifies	This is the narrow case where the full number has a mandated role
"Because the form has always asked for it"	Nothing	Worth confirming a lawful basis exists before collecting at all

The last row is not a joke. A meaningful share of Aadhaar collection in Indian financial services traces to a form field added years ago whose justification nobody has revisited since the 2018 Puttaswamy judgment struck down Section 57 of the Aadhaar Act, which had been read as letting private bodies require Aadhaar under contract.

The VID trap in automated masking

There is a technical failure mode here that catches masking implementations, and it is worth knowing whether you build your own or buy one.

An Aadhaar number is twelve digits. A Virtual ID is sixteen. A naive detector looks for runs of digits and masks them, which means it will happily black out a VID printed on a document — or, worse, mask the first eight digits of a sixteen-digit VID and leave eight visible, producing a document that looks redacted and is not.

The defence is that Aadhaar numbers carry a Verhoeff check digit. Validating the checksum distinguishes a real Aadhaar number from any other twelve-digit run — an enrolment number, a date sequence, an account number that happens to be the right length — and distinguishes it from a VID. A masking implementation that pattern-matches on digit count without checksum validation will both over-redact and under-redact, and neither error is visible in the output.

# A quick way to find out what your current tool does:
# feed it a document containing a 16-digit VID and check
# whether anything was redacted, then feed it one containing
# a 12-digit enrolment ID and check the same.

We wrote about the wider set of these failures separately, including rotated cards and PDF text layers that survive a drawn rectangle, in why Aadhaar masking fails.

Getting this wrong quietly

The reason to be deliberate about which artefact you collect is that the cost of the wrong choice is invisible for a long time. A full Aadhaar photocopy in a KYC file works perfectly well as a business process. Nothing breaks. The onboarding completes, the auditor sees a document, the customer is happy.

What has actually happened is that you have taken on custody of a cross-database identifier for every customer, for the life of your retention policy, in exchange for a matching capability that four digits would have provided. That trade only becomes visible in two circumstances: a breach, or a regulator asking why you hold a field you are not authorised to verify.

Neither is a good moment to be having the conversation for the first time. The better moment is now, and the question is narrow enough to answer in an afternoon: for each place we collect Aadhaar, what are we doing with it, and which of the four artefacts does that actually require?

This is a description of how the artefacts differ, not legal advice. Which one your entity may or must collect depends on your licence and your regulator, and is worth confirming with counsel against your own registration rather than reading off a vendor's page, ours included.

What to do about what you already collected

Choosing the right artefact fixes new onboarding. It does nothing about the archive, and for most institutions the archive is where the volume is — years of full Aadhaar photocopies collected under the old form field, sitting in a document management system nobody has audited since it was commissioned.

That backlog is a bounded problem, which is worth saying because it often gets treated as an unbounded one and therefore deferred indefinitely. Three questions scope it.

How many documents, and where exactly? Not the architecture diagram — the real inventory. Count the document management system, the loan origination system's own copies, the staging buckets nobody cleaned up, the analytics extracts, the vendor systems, and the shared drives. The number is usually larger than the DMS count by a factor that surprises people, and the locations outside the DMS are the ones that matter most because they are outside the retention policy too.

Which of them do you still need at all? A document held past its retention period is not a masking problem, it is a deletion problem, and deleting is cheaper and more complete than redacting. Run the retention question first: the set that should simply be destroyed is often a large fraction of the total, and destroying it removes the exposure entirely rather than reducing it.

What proves the pass actually worked? A bulk masking run over a historical archive produces two failure modes, and neither announces itself. Documents where no number was found come back unchanged — still fully readable — and a run that reports "48,000 documents processed" without separating those out has told you almost nothing. Documents that were already masked get processed again harmlessly. The count that matters is how many came back with zero regions redacted, and those need to be looked at rather than filed.

A run of that size is a provisioning conversation rather than a scheduling one, because the monthly quota rather than the per-minute rate is what stops a backlog. We set out the arithmetic in bulk Aadhaar masking for document archives.