"Checksum-validated" does a lot of work in a sentence and most readers skim past it. It's worth stopping on, because it's the difference between a detector that's actually useful in production and one that generates enough false positives that a security team turns it off within a week.
Why a regex alone isn't enough
An Aadhaar number is 12 digits. A PAN is five letters, four digits, one letter. Both have a recognisable shape, and it's tempting to stop there — write a regex, call it detection, ship it.
The problem shows up immediately in real traffic: a 12-digit string appears constantly in text that has nothing to do with Aadhaar — order numbers, phone numbers with a country code, invoice references, randomly generated IDs. A shape-only match on Aadhaar's format flags a large fraction of these as sensitive data. Every one is a false positive, and false positives are what get a security control disabled, not evaded.
What a checksum actually buys you
Aadhaar numbers are generated with a check digit computed using the Verhoeff algorithm — a checksum scheme designed specifically to catch transcription errors (a swapped digit, a fat-fingered keystroke) that simpler check digits miss. That check digit isn't decorative: a real Aadhaar number's last digit is mathematically derived from the eleven before it, according to a fixed set of permutation and multiplication tables.
That means a detector can do more than match a shape. It can compute what the check digit should be for a given 12-digit string and compare it against what's actually there. A random 12-digit number — an order ID, a padded phone number — will fail that check the overwhelming majority of the time, because there's no reason a random string would happen to satisfy Verhoeff's arithmetic. A real Aadhaar number will pass it, every time, by construction.
PAN numbers follow a related but different principle: the ten-character structure isn't arbitrary either. The fourth character encodes the holder type (an individual, a company, a Hindu Undivided Family, and so on), and the number is validated against its own structural and check-character rules rather than a free-form string. A detector that checks structure and check-character validity, not just "five letters, four digits, one letter," throws out most of the noise a shape-only match would flag.
What this means in practice
The gap between the two approaches is the gap between a detector a security team can leave running in block mode and one they have to babysit. Checksum validation doesn't eliminate false positives entirely — a random string can still coincidentally satisfy the arithmetic, though it's rare — but it moves detection from "looks like it might be an Aadhaar number" to "mathematically is one, with very high confidence."
This is also why detection has to run somewhere that can afford the computation per keystroke without adding latency the person typing would notice. On-device, in-browser detection means the checksum check happens in milliseconds, before the prompt is even sent — not as a batch job on stored logs after the fact, by which point the data has already left.
The detail matters because the alternative — a detector that just pattern-matches on digit count — is worse than no detector in a specific way: it trains the security team to ignore its alerts. A control that cries wolf on invoice numbers gets muted, and a muted control is a control that isn't running the day it actually matters.
Both Aadhaar and PAN checksum validation are shipped and running in PromptSec's detection engine today — see what else is detected, and what isn't yet for the full, honestly-labelled list.