Ask an Indian institution what it redacts and the answer is almost always "Aadhaar". Ask a thorough one and you get "Aadhaar and PAN". Then open an actual KYC folder and count the document types in it.
A typical loan or policy file holds an identity proof, an address proof, an income proof and a bank proof. UIDAI-issued Aadhaar covers two of those, which is why it dominates the conversation. But customers routinely submit a driving licence as address proof, a voter EPIC as identity proof, and a passport for both — and each of those carries a government identifier of its own that is every bit as re-usable as the number everyone is worried about.
Four identifiers, four shapes
| Identifier | Shape | Why it is missed |
|---|---|---|
| Driving licence | Two-letter state code, two-digit RTO code, then eleven digits — frequently printed with a four-digit year in the middle and a dozen different separator conventions. | No canonical format. Written as MH12 20110012345, MH-12-2011-0012345 and half a dozen other ways, so naive matching finds nothing. |
| Voter EPIC | Three letters followed by seven digits. | Short and letter-prefixed, so it does not look like "an identifier" to a rule written with Aadhaar in mind. |
| Passport | One letter then seven digits. | Eight characters. Almost every custom rule set has a minimum length that excludes it. |
| GSTIN | Fifteen characters, and it embeds a PAN. | Treated as business data rather than personal data — but for a proprietor it is both, and the embedded PAN survives any PAN-only redaction. |
The GSTIN case is the one worth pausing on. A team that carefully redacts every PAN on a document and leaves the GSTIN untouched has left the PAN readable, because characters three to twelve of a GSTIN are the PAN. This is a common and entirely invisible failure.
Why in-house rules miss them
Almost every in-house redaction effort follows the same arc. Someone writes a twelve-digit rule for Aadhaar. It fires on phone numbers, so they add the Verhoeff checksum. Then a PAN rule, which is easy because the shape is fixed. And then the project is declared done, because those are the two documents the requirement named.
The other identifiers are not missed through carelessness. They are missed because nobody wrote a requirement for them, and because each one needs its own pattern, its own separator handling and its own decision about what else in the world shares that shape. That is four more small projects, and they never get prioritised against a roadmap.
The ones that need care
Not every identifier should be matched aggressively. Two deserve specific mention:
Passport numbers
One letter and seven digits is a short, common shape. On a document containing part numbers, reference codes or serial numbers, it will produce false positives. It is distinctive enough to enable by default on identity documents; it is worth reviewing output the first time you run it across an unfamiliar document set.
Driving licence numbers
The permissiveness that makes them detectable — accepting many separator styles — is also what makes them risky. The mitigation is to be strict about the shape while permissive about the punctuation: a valid state code and RTO code prefix, then the right number of digits. A rule that accepts "roughly fifteen alphanumerics" will eat things it should not.
Where these documents actually turn up
- Motor insurance claims — the licence and the registration certificate are the core of the file, and the licence number is almost never redacted before it goes to a surveyor.
- Rental and tenant verification — a voter EPIC is one of the most commonly submitted address proofs in India.
- Employment onboarding — a passport copy is standard for anyone who has travelled for work, and it sits in the HRIS for the length of employment.
- Business lending — GSTIN on every proprietorship file, carrying an embedded PAN.
- Any address proof — customers submit whatever they have, which is precisely why a document-type-specific approach fails here.
The structural answer
The reason these get missed is that most redaction is built around documents: this is an Aadhaar card, so look for an Aadhaar number. A KYC folder is not a set of known documents. It is a set of unknown documents that happen to carry known identifiers.
Inverting that — matching identifiers regardless of what the document is — is what makes a voter EPIC on an unexpected page findable at all. It also means the same pass handles the utility bill, the rent agreement and the affidavit that nobody wrote a parser for.
The trade-off is that identifier-driven matching has to be conservative, because it is running against documents it knows nothing about. That is the reason every type worth enabling by default is either checksum-validated or structurally distinctive, and why the genuinely ambiguous ones — a bare nine-to-eighteen-digit account number, for instance — stay off until you tell the system what it is looking at.
MaskAadhaar detects eleven identifier types on any document, without needing to know what the document is. See the PII redaction API, or read how the detection works.