The Problem
Social Security Numbers (SSNs), Federal Employer Identification Numbers (FEINs), and Individual Tax Identification Numbers (ITINs) all share some problems.
- They share the same number of digits so they are difficult to distinguish from one another.
- They don’t have a way to do sanity checking because they lack a checkdigit.
Without checking some external source, you cannot tell which number is which type. This is a data quality problem because these identifiers often get lumped into a single “Tax ID” column. This results in bad data hygiene.
The Solution
A checkdigit can help address these issues and result in better data quality and data hygiene when handling these sensitive numbers. In my personal opinion, I think it would be a good idea for the US government agencies who oversee these identifiers — the Social Security Administration (SSA) and the Internal Revenue Service (IRS) — to come up with a shared approach for adding a checkdigit to each of these identifiers.
How it Could Work
Use the Luhn Algorithm to add a checkdigit.
Each of these identifiers would get a 10th digit added to the end. The 10th checkdigit could be easily calculated by anyone with the first 9 digits.
Luhn and National Identifiers Backstory
You may have never heard of Luhn, but if you have a credit card you’ve almost certainly already used it. Let’s say that you are entering your credit card number into an online form for a purchase. You accidentally transpose a couple numbers or mistype a number. The form doesn’t even try to submit the payment. This happened in an “off-line” fashion, meaning in this context that the payment processing company was not yet contacted. The form already knows it is not a valid number, so it doesn’t let you continue. The last number in the credit card number is a Luhn check digit and makes that possible. This is Luhn in action!
The Luhn algorithm was invented in 1960. SSNs began in 1936, the FEIN in 1974, and the ITIN in 1996. With computational limitations being what they were at the time, it may have been a reasonable design choice to base the FEIN and ITIN off of SSN. Luhn couldn’t have been applied to SSN in the first place because it hadn’t been invented in 1936. The Luhn algorithm is widely deployed in other countries for national identifiers and in many other contexts.
The Luhn algorithm did find its way into another United States identifier scheme. National Provider Identifiers (NPIs) do contain a Luhn check digit. HHS released the NPI Final Rule in 2004. The NPI Final Rule specifies the use of the Luhn algorithm with a prefix value (“80840”). This prefix establishes some level of built-in provenance to the NPI.
I can have some confidence that the NPI is in fact an NPI. If this same idea was applied to SSNs, ITINs, and FEINs, the same could be said for those as well. What this means is that anyone with their own 9 digit SSN/ITIN/FEIN could calculate their own 10th digit (by reading the standard or Final Rule). Systems would do the same by adopting it as a best practice for storage. Adding an extra space for the 10th digit will not be without some work, but the technical barrier is low. This could be a particular pain point for legacy mainframe systems that rely on fixed-length flat files.
How Would it Get Implemented?
I’m proposing that the government should apply the same thing to SSNs, ITINs, and FEINs. Each of these identifier types (SSN, ITIN, FEIN) would use their own prefix.
I know getting this to happen on a federal level would quite literally require an act of congress. It has some key benefits for government and the people of the United States.
A Luhn checkdigit can:
- Help better protect SSNs, ITINs, and FEINs.
- Provide off-line sanity checks for SSNs, ITINs, FEINs.
- Establish provenance in well-formed identifiers. (e.g. “this number looks like an FEIN issued by the IRS”). This also occurs in an “offline” fashion.
Luhn is simple and easy. This approach has a low technical barrier to implement. The precedent to use Luhn already exists in the NPI Final Rule. We just need to update the legacy US identifiers!
Without top-level federal adoption, however, this method can still be applied within a system, organization or agency. It could simply be a best-practice for storage of SSN, ITIN and FEIN, enhancing an organization’s ability to identify and to safeguard these fields.
NOTE: Sensitive IDs should be encrypted and protected. There are many approaches. Unencrypted versions of IDs are often expressly required for certain processing needs. Special care should always be taken to safeguard personally identifiable information (PII).
A Simple Example
To further illustrate how this could work in practice, I’ve created the following Github repository with example code that generates and validates SSNs, ITINs, and FEINs with checkdigits.
https://github.com/TransparentHealth/us-identifier-w-checkdigitThese are written in Python, but the same could be done in virtually any computer language. As you see it is very little code, resulting in a low technological barrier to implementation. If you have ideas or improvements for this idea, please feel free to submit on Github.
— Alan Viars