Why your redaction tool thinks every invoice number is an SSN

Every team that adopts automatic redaction goes through the same phase. The first batch comes back and the tool has blacked out invoice numbers, order IDs, policy references and half of a phone bill. Someone decides it is "too aggressive", turns it down or off, and real identifiers start getting through again.

The cause is nearly always the same. The tool is matching shapes. A US Social Security number is nine digits, often written 123-45-6789. So is a lot of other text. A tool that redacts anything with that shape cannot tell an SSN from a case number, and it was never going to.

Most identifiers can check themselves

Many national and financial identifiers carry a check digit: one or two characters computed from the rest, so that a typo or a random number is very unlikely to pass. Banks and governments added them to catch keying errors, but they work just as well to tell a real identifier from something that happens to look like one.

Identifier	Check	What a random look-alike does
Payment card (Visa, Mastercard, Amex…)	Luhn	Fails 9 times in 10
IBAN	ISO 7064 mod-97, plus a fixed length per country	Fails about 99 times in 100
UK NHS number	mod-11	Fails about 10 times in 11
Canadian SIN	Luhn	Fails 9 times in 10
Brazilian CPF	Two mod-11 check digits	Fails about 99 times in 100
Australian TFN / ABN	Weighted mod-11 / mod-89	Fails most of the time
South African ID	Luhn, plus a valid birth date in the first six digits	Fails almost always
US ABA routing number	3-7-1 weighted mod-10	Fails 9 times in 10
Passport MRZ	ICAO 9303, five check digits	Essentially never passes

A detector that requires the check to pass before redacting gets rid of most false positives at no cost. Real identifiers always pass, by definition, except when they were mistyped at the source.

The SSN has no check digit, but it has rules

The Social Security number is the awkward one: there is no checksum. There are still structural rules from the Social Security Administration. The first three digits, the area, are never 000, never 666 and never in the 900–999 range, which is used for ITINs instead. The middle two digits are never 00, and the last four are never 0000.

Those rules remove a meaningful share of random nine-digit strings, but not all of them. So an SSN match should also be read in context: is it next to the words "SSN" or "Social Security", or in a field labelled that way? A UK National Insurance number is similar. It has no checksum, but some letter prefixes are never issued (D, F, I, Q, U and V never appear first, and O never appears second), and building that into the pattern removes most of the noise.

Not everything can be validated, and that is fine

Some things that need redacting have no structure to check: email addresses, phone numbers, crypto wallet addresses, IP addresses. They are distinctive enough in shape that pattern matching works, because an email address does not look like an invoice number.

The hard cases are the ones that are neither distinctive nor validatable. A bare bank account number in most countries is just eight to eighteen digits. A date could be a birth date or an invoice date. Turning these on by default against unknown documents destroys more good data than it protects, and a wrong redaction cannot be undone the way a missed one can be fixed. The sensible default is to leave them off and turn them on where you know what you are processing, which is how MaskAadhaar's global endpoints ship: SWIFT_BIC and DATE_OF_BIRTH are available but off by default.

Narrow by country when you can

A nine-digit Canadian SIN and a nine-digit US SSN look similar. An eleven-digit Brazilian CPF overlaps with plenty of other things. If your documents come from known markets, tell the detector. Restricting to US,GB stops Australian and Brazilian patterns from firing on a London bank statement, while universal types like cards, IBANs and emails still apply everywhere.