ID Number Formats Worldwide: SSN, SIN, NINO & Check Digits

A national ID number is not a random string. It is a fixed-length code with a defined character set, reserved sub-ranges the issuing authority promises never to use, and often a check digit computed from the other characters so software can reject typos before they hit a database. This article documents the structure and validation rules for five widely encountered schemes (US SSN, Canadian SIN, UK NINO, French INSEE, German Steuer-ID) and explains why a number can pass every format check and still have belonged to no one.

Everything here is written for testing and validation. The example numbers, and the ranges our tools draw from, come from never-issued and reserved blocks, so they exercise a form without ever matching a living person.

What is the difference between a format-valid ID and an issued one?

A format-valid ID obeys its scheme's structural rules: correct length, an allowed character set, no forbidden sub-range, and a check digit that recomputes correctly. An issued ID is one a government actually assigned to a person. Every issued number is format-valid, but most format-valid numbers were never issued, and no offline validator can tell the two apart.

That gap is the foundation of safe test data. Many schemes set aside ranges the issuer guarantees it will never assign. A generator that draws only from those ranges produces output that satisfies a validator while staying guaranteed-fictional. The US Social Security Administration, for example, states it will never issue a number with an area number of 900 through 999 ^{[ssa-randomization]}, which is why those numbers are standard for documentation and QA.

How are the five national ID schemes structured?

Each of the five schemes is a fixed-length numeric or alphanumeric code with its own reserved ranges, and only three carry an arithmetic check digit. The table below lists length, check-digit method, and never-issued ranges for each. Lengths exclude separators (spaces, hyphens) that are added for display only.

Two patterns matter for implementers. Only the SIN, INSEE, and Steuer-ID carry a real check digit, so validation strength swings widely by country. And every scheme reserves something, whether an area range, a leading digit, or a letter prefix, which is exactly what makes principled test-data generation possible.

How does the US SSN work without a check digit?

The SSN is nine digits grouped as area (3), group (2), and serial (4), with no checksum at all. On June 25, 2011, the SSA switched to randomization, which dropped the old geographic meaning of the area number but kept the exclusions: area 000, 666, and 900-999 are never issued, the group cannot be 00, and the serial cannot be 0000 ^{[ssa-randomization]}. With no check digit, a validator can only apply those structural rules. Our SSN validator flags the reserved ranges rather than claiming any number is real.

How does the Canadian SIN use the Luhn check digit?

The SIN is nine digits, shown in three groups of three, and its ninth digit is a Luhn check digit computed from the first eight ^{[sin-wikipedia]}. A leading 0 is not assigned to any province, and a leading 9 marks temporary residents. The checksum makes SIN validation meaningfully stronger than SSN validation, because a single mistyped digit is almost always caught. The SIN generator and validator produces Luhn-valid samples and checks numbers you paste in.

What are the UK NINO prefix rules?

A NINO is two prefix letters, six digits, and a suffix letter from A to D, for example QQ 12 34 56 C. It has no arithmetic check digit; validity rests on prefix rules. HMRC excludes the combinations BG, GB, KN, NK, NT, TN, and ZZ from allocation, and treats TN as a temporary reference rather than a real prefix ^{[hmrc-nim39110]}. The letters D, F, I, Q, U, and V are barred in either position, and O is barred as the second letter. The NINO generator and validator encodes these rules and prefers reserved prefixes for generated samples.

The characters D, F, I, Q, U, and V are not used as either the first or second letter of a National Insurance number prefix.

How do the French INSEE and German Steuer-ID numbers compute their check digits?

The French INSEE number (NIR) is 13 digits encoding sex, year and month of birth, department, and a sequence, followed by a two-digit *cle de controle* computed with a mod-97 rule ^{[insee-wikipedia]}. The German Steuer-ID is 11 digits whose eleventh digit is a check digit from an ISO/IEC 7064 procedure, with a leading digit that is never 0 ^{[steuerid-wikipedia]}. The two show why no single universal checksum works: INSEE uses mod-97 while the Steuer-ID uses an ISO/IEC 7064 MOD 11,10 chain.

Which check-digit algorithms do these schemes use?

Three algorithm families cover the schemes above and most identifiers you will meet: Luhn (mod 10), mod-97 from ISO/IEC 7064, and the ISO/IEC 7064 MOD 11,10 chain, plus assorted weighted-modulus schemes for tax and VAT IDs. The table names each algorithm, where it is used, and the error classes it is designed to catch.

How do you validate a SIN with Luhn, step by step?

To validate a SIN with Luhn, work from the rightmost digit, double every second digit moving left, subtract 9 from any doubled value over 9, sum everything, and confirm the total is divisible by 10. Take the test number 046 454 286 and trace it through.

1. Number the digits from the right: 6(1), 8(2), 2(3), 4(4), 5(5), 4(6), 6(7), 4(8), 0(9).
2. Double the even-position digits (2, 4, 6, 8): 8 to 16, 4 to 8, 4 to 8, 4 to 8. Reduce any result over 9 by subtracting 9, so 16 becomes 7. These become 7, 8, 8, 8.
3. Leave the odd-position digits unchanged: 6, 2, 5, 6, 0.
4. Sum everything: (6 + 2 + 5 + 6 + 0) + (7 + 8 + 8 + 8) = 19 + 31 = 50.

Because 50 is divisible by 10, 046 454 286 is Luhn-valid ^{[luhn-wikipedia]}. A validator accepts its format. It stays fictional because it was generated, not issued.

How do reserved ranges give you safe test data?

Reserved ranges give you test data that clears format validators while being structurally incapable of matching an issued identifier. A generator that emits SSNs in the 900-999 area, Luhn-valid SINs on documentation patterns, and NINOs on excluded prefixes like TN produces fixtures that are safe for QA pipelines, form-fill testing, demo environments, and privacy-preserving sample datasets.

This is also where the ethical line sits. Generated identifiers exist for testing, QA, form-filling, and privacy. They must never pass a legally required identity or eligibility check, open accounts, claim benefits, or impersonate a real person. Each of those is fraud and is illegal in most jurisdictions, whether or not the number is format-valid. Start from the identity generator to pick a generator, and reach for the validators above to confirm your validation logic matches each specification.

The engineering takeaway is concrete. Build per-scheme validators that encode the real length, character set, reserved ranges, and the correct check-digit algorithm. Treat any pass as *format-valid only*. Source your test fixtures from never-issued ranges so your suite never embeds a real person's number.