Check digits: what Luhn, ISBN-13 and IBAN mod-97 catch and what they do not

What it is

A check digit is one or two characters appended to an identifier and computed from the rest, so that a receiver can recompute it and reject most mistyped or misread values. Hans Peter Luhn's 1960 patent "Computer for verifying numbers" (cited) describes the scheme now used for payment card numbers: digits in alternate positions are replaced by substitute digits (equivalent to doubling every second digit from the right and subtracting 9 from results above 9), the digits are summed, and the check digit brings the total to a multiple of ten; the patent presents it as detecting a transposition of the digits made while copying a number. The International ISBN Agency (cited) states that the final digit of a 13-digit ISBN is computed with a modulus 10 system with alternate weights of 1 and 3. For IBANs the two check digits after the country code are computed with the modulo 97-10 method of ISO/IEC 7064, as SIX states (cited); an IBAN has up to 34 letters and digits, and the national part determines the length. In MOD 97-10, letters become two-digit numbers and the rearranged string, read as one integer, must leave remainder 1 when divided by 97.

Why it matters

Identifiers are typed, dictated, scanned and transcribed by language models. Without a check, a single wrong digit usually yields another valid-looking identifier, and the error surfaces as a wrong payment or record far from its cause. With a check, it is rejected at entry.

How to apply

• Validate the check digit at every boundary where the identifier arrives as text (forms, imports, agent tool calls) and reject rather than "correct".
• Strip spaces and normalise case before computing; IBANs are printed in groups of four but transmitted without spaces.
• When designing identifiers that people or OCR will handle, add a check: a modulus with a prime such as 97 for stronger detection, or a Luhn-style mod 10 when the identifier must stay numeric with a single extra digit.
• Keep the check digit inside the stored identifier so that every copy carries it.

Pitfalls

A correct check digit proves only that the string was probably copied correctly, not that the account, book or card exists; SIX's own IBAN checker says it confirms formal structure, not validity. Luhn does not detect the transposition of an adjacent 0 and 9, since both orders contribute 9 to the sum. Weights 1 and 3 miss transpositions of adjacent digits that differ by 5, because swapping them changes the sum by twice their difference. Applying an algorithm to the wrong digit range validates nothing.