What Is Checksum Validation (Luhn, Mod-97)?

Why do identifiers carry a checksum?

Numbers get mistyped. A cashier hits a wrong key, a customer swaps two digits on a form. Standards bodies and card networks add a check digit (or two) so a machine can reject the typo before it reaches a bank. The check digit is computed from the other digits, so a number with one wrong digit usually stops adding up.

That same property helps detection. Of all 16-digit strings, only about one in ten passes the Luhn test. If a prompt contains a 16-digit order number, the checksum is a cheap way to tell that it is probably not a card.

How does the Luhn algorithm work?

Luhn is used for payment card numbers and several other identifiers. Walk the digits from the right. Leave the last digit as it is, double every second digit after it, and if a doubled digit is above 9 subtract 9. Add everything up. The number is valid if the total ends in 0. The algorithm catches every single-digit error and nearly all swaps of neighbouring digits (it misses 09 and 90). More background is on Wikipedia.

Here it is on 4111 1111 1111 1111, a well-known synthetic test number used in payment documentation:

digits:            4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
after doubling:    8 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1
sum = 30, 30 mod 10 = 0  -> valid

change the last digit to 2 (4111111111111112):
after doubling:    8 1 2 1 2 1 2 1 2 1 2 1 2 1 2 2
sum = 31, 31 mod 10 = 1  -> invalid

The leading 4 sits in a doubled position and becomes 8, a single digit, so nothing is subtracted. Every other doubled digit is a 1 that becomes 2. The totals (30 and 31) were checked by running the algorithm.

How does mod-97 work for an IBAN?

An IBAN (international bank account number, defined in ISO 13616) has two check digits in positions 3 and 4. To validate: move the first four characters to the end, turn each letter into a number (A is 10, B is 11, up to Z at 35), read the result as one big integer and divide by 97. A valid IBAN leaves a remainder of 1. The method is MOD 97-10 from ISO/IEC 7064; see the IBAN overview.

For the British example IBAN GB82 WEST 1234 5698 7654 32, a widely published test value:

rearranged:  WEST12345698765432GB82
as digits:   3214282912345698765432161182
3214282912345698765432161182 mod 97 = 1  -> valid

change the check digits to 83:
3214282912345698765432161183 mod 97 = 2  -> invalid

Each country also fixes the IBAN's total length. A detector should test the length first, because a string with the right remainder but the wrong length isn't an IBAN.

What does a valid checksum prove, and what doesn't it?

Only one thing: the number is internally consistent. The test number above passes Luhn, and no bank issued it to anyone. The reverse holds too. A real card can fail if a digit was mistyped in the prompt, and a validator would then ignore a value that a human would recognise.

• It doesn't prove the number exists. Anyone can generate numbers that pass.
• It doesn't prove the number belongs to a person. That needs a lookup or Exact Data Match against your own records.
• It isn't a secret check. About one number in ten passes Luhn by chance, so a checksum cuts noise but doesn't remove it. Format rules and context words matter too.
• Not every identifier has one. Names, addresses and many phone numbers have no check digit. For those, see NER for PII.

How does Maskflare use checksums?

The detection engine has 108 validators (checksums and format rules), and 260 of its 574 detectors use some form of validation (a checksum, a structure check or a list of allowed values). They cover cards (Luhn plus an issuer-range check and a length check), IBANs with the per-country length table, and national identifiers from many countries, using each scheme's own rule: weighted sums, mod 11, Verhoeff and others.

The effect is visible in practice. A 16-digit number in a log line that fails Luhn isn't masked as a card. A 16-digit number that passes and sits next to the words "card number" is. Validation is also why you can leave a detector set to mask without swamping people with false alarms. The detection engine page lists what is covered, and PII vs PHI vs PCI explains why card data gets its own rules.

What are the limits in practice?

• Typos hide values. A card with one wrong digit fails and may go unmasked. If missing a near-miss is costly, add a looser rule in alert mode.
• Test values pass. Documentation numbers such as the ones above are valid on purpose, so they will be detected like real ones.
• Spaces and dashes vary. Validators have to strip separators first, and a number split across lines or written in words needs extra handling.