A housing finance company collects more Aadhaar copies per customer than almost any other kind of lender. Not one, but several: the applicant, the co-applicant, sometimes a guarantor, and often the same documents again at disbursement because the branch could not find the originals.
Each of those copies lands somewhere. A loan origination system, a document management system, a shared drive, an email thread with the credit team, a WhatsApp message from a field officer who was trying to be helpful. Most of them are unmasked, and most of them will still be there in seven years.
This is a note on why that is a problem specific to HFCs, and what a proportionate fix looks like.
Why housing finance accumulates more exposure than other lending
Three structural reasons, none of which apply as strongly to, say, a consumer durable loan.
Long tenure. A home loan runs fifteen to twenty years. Retention obligations mean the KYC file stays live for the life of the loan and for years after closure. A document collected in 2026 is still sitting in your systems in 2050. Whatever you decide about masking today, you are deciding it for a very long time.
Multiple parties per file. Joint applications are the norm rather than the exception. A single housing loan file routinely contains identity documents for two or three people who are not all your customer in the contractual sense, but whose Aadhaar numbers you are nonetheless holding.
Physical-to-digital handoff. Much of the collection still happens at a branch or through a field officer with a phone camera. That produces photographs, not clean scans — glare, angles, folded printouts, occasionally a picture of a picture. Any masking process has to work on those, not just on a pristine PDF downloaded from the UIDAI portal.
What UIDAI actually asks for
The core expectation is straightforward: where a copy of an Aadhaar card is retained, the first eight digits should be redacted, leaving only the last four visible. The last four are enough to reference the document; the full number is not needed once identity has been established.
The practical reading for a lender is that the unmasked number should exist in your environment for as little time as possible — ideally only for the moment of verification — and the retained copy should be masked.
Two clarifications that come up repeatedly in vendor conversations:
Masking is not the same as offline verification. If you are verifying identity through the QR code or an offline XML, that is a separate mechanism with its own rules. Masking is about the image or PDF you keep afterwards.
The Virtual ID is not a substitute. A VID is a temporary sixteen-digit number that maps to an Aadhaar number. It reduces exposure in some flows, but if you are storing a scanned card that prints both the Aadhaar number and the VID, masking the Aadhaar number is still what is required.
The three ways HFCs get this wrong
Masking at the wrong point in the flow
The common pattern is to upload the document first and mask it later, often in a nightly batch. This feels safe because everything ends up masked. It is not, because between upload and batch there is a window during which the unmasked file sits in object storage, replicated to your backups, possibly indexed by a search service.
Backups are the part people forget. If your masking runs at midnight and your backup runs at eleven, you have a permanent archive of unmasked documents that no amount of subsequent masking touches.
Mask before the document reaches durable storage. The unmasked bytes should exist in memory and in transit, and nowhere else.
Assuming success because nothing errored
This is the failure mode that most often survives all the way to an audit, and it is worth being precise about.
Optical character recognition is probabilistic. A masking service given a photograph it cannot read has two options: fail the request, or return the document unchanged. Failing the request breaks onboarding for a customer whose only mistake was a shaky hand, so most services return the document.
Which means a successful HTTP response does not tell you the document was masked. It tells you the request was processed. If your integration writes every 200 response into the masked-documents bucket, then every unreadable photograph in your portfolio is now an unmasked Aadhaar number filed under a name that says otherwise.
Any competent masking API reports how many regions it redacted. Read that count. If it is zero, the document is not masked, and it needs a human.
Testing on clean documents only
Vendor evaluations tend to use a neat PDF downloaded from the UIDAI portal. That is the easiest possible input and tells you almost nothing.
The documents that break masking systems are the ones your field officers actually produce. In particular, the standard printout that carries both sides of the card on one page — and where, on a scan of a physical printout, one card often ends up rotated ninety degrees relative to the other.
A detector that stops as soon as it finds one Aadhaar number will mask the upright card, never look at the rotated one, and report success. The second card keeps the number in the largest print on the page.
When you evaluate a masking vendor, hand them a scan like that and look at the output image with your own eyes.
Over-masking is a real cost too
The opposite error gets less attention because it is visible rather than dangerous, but it generates work.
An e-Aadhaar page is full of digits that are not the Aadhaar number: a sixteen-digit VID directly below it, the date of birth, an enrolment number, a PIN code, the UIDAI helpline number. A detector that simply looks for twelve consecutive digits will find several candidates — a sixteen-digit VID contains multiple twelve-digit windows.
The result is documents where the date of birth or the VID has been blacked out. Your credit team then cannot read a field they need, and the file goes back for re-collection.
Aadhaar numbers carry a Verhoeff checksum, and a random twelve-digit slice of a VID fails it about nine times out of ten. A masking system that validates the checksum leaves those fields alone. When you review sample output, check that the date of birth and VID are still legible — it is a quick proxy for whether the vendor's detection is principled or just pattern-matching.
A proportionate implementation
For a mid-sized HFC, this does not need to be a large programme. In outline:
| Step | What it involves |
|---|---|
| 1. Find the ingress points | List every route by which an Aadhaar copy enters: branch upload, field app, customer portal, email, partner API. There are usually more than expected. |
| 2. Mask in the upload path | Call the masking service before the file is written anywhere durable. One API call, synchronous. |
| 3. Handle the failures explicitly | Zero regions masked means manual review, not storage. Make this a hard branch in code. |
| 4. Deal with the back catalogue | Existing unmasked documents need a one-off pass, including whatever is in backups. This is usually the largest piece of work. |
| 5. Keep an access trail | Record who retrieved which document and when. Useful operationally, and the first thing asked for in a review. |
Step four is the one that gets deferred, and it is the one that carries the accumulated risk. New documents being masked correctly does nothing about the fifteen thousand already in the system.
Questions worth asking a vendor
- Does the service handle a two-sided printout where the cards are at different orientations? Ask to see output, not a claim.
- How does it report that it could not find a number, and does it return the original document when that happens?
- Does it validate the Aadhaar checksum, or does it mask any twelve digits it sees?
- Are documents persisted anywhere during processing, and if so for how long?
- Where does processing physically happen? For an Indian lender, in-country processing is usually the expected answer.
- Can an API key be revoked immediately if it leaks?
- What throughput can be sustained, as opposed to peak burst?
That last question matters more than it sounds. Masking is CPU-bound OCR work. A vendor quoting a high requests-per-minute figure should be able to say whether that is sustained throughput or a short burst before a queue forms.
Starting small
The cheapest way to find out whether this is a problem in your organisation is to pull ten Aadhaar copies at random from your document store and look at them. If more than one is unmasked, you have an answer.
To see how masking behaves on your own documents without sending them anywhere, the browser-based tool processes files entirely on your machine — nothing is uploaded. Try it with your most awkward scan, not your cleanest one.
For integrating masking into an origination or document management flow, the API documentation covers the endpoints and error handling, and we can provide a test quota so your team can validate output against a real sample before committing. Tell us your monthly volume and we will size it.
Frequently asked questions
Do housing finance companies have to mask Aadhaar copies they store?
Where a copy of an Aadhaar card is retained, UIDAI's expectation is that the first eight digits are redacted and only the last four remain visible. For an HFC this applies to every retained copy across applicants, co-applicants and guarantors, and for the full retention period of the loan file.
When in the process should masking happen?
Before the document is written to durable storage. Masking in a nightly batch leaves a window in which unmasked files exist in object storage and, more importantly, get captured by backups that later masking never touches.
What should happen when the masking service cannot read a document?
It should be routed to manual review, never stored as if masked. A masking API typically returns the original document with a count of zero regions redacted when OCR fails, and a successful HTTP status in that case does not mean the document is safe to store.
Why do some masking tools black out the date of birth or Virtual ID?
Because they match any twelve consecutive digits rather than validating the Aadhaar checksum. A sixteen-digit VID contains several twelve-digit windows. Verhoeff checksum validation rejects almost all of them, which is why checking that the VID and date of birth remain legible is a useful test of a vendor's detection quality.
What about Aadhaar copies collected before masking was implemented?
Those need a one-off remediation pass, including copies held in backups and archives. This is usually the largest part of the work and the part most often deferred, and it is where the accumulated exposure sits.