Why is the composite check digit in a machine readable zone of a modern passport not taking into account all of the data?

Question

Modern passports and ID cards have a machine-readable zone (MRZ) at their bottom, which contains the basic identification information in what presumably is an OCR-friendly format.

The format for the MRZ specifies a number of check digits, which serve to help detect recognition errors. For example, there is a check digit computed over the number of the document, a check digit covering the birth date, etc.

At the end there is also a "composite check digit", which is computed over the lower row of the record, thus providing a more general overall integrity check.

The "upper row" of the record, which contains the name and surname is, however, not covered by any check digits, which means there is no way at all to catch errors there or verify the correctness of the scan.

My question is the following: is there any reasonable explanation for why this choice was made in the specification? Why wouldn't the specification provide at least a single check digit covering the whole of the data in the record, facilitating the very same "machine-readability" it is aimed at? The standard is mature and widely used, hence this cannot be just a mistake, right?

I understand this question is somewhat unconventional, yet I have no idea where could I go to find the answer - suggestions welcome alongside actual answers.

Answer 1

I got curious and went (cursorily) though the actual ICAO 9303 documents which define how the machine-readable zone works, and found no rationale. The most interesting thing is that, though there is discussion about different document formats where a MRZ could appear (like a credit card), the name line seems to always be check-digit-free – if at all present!

So I would venture that one possible reason is that the mapping from "real name" to machine-readable name is lossy, AND seems to not be really standardized, so it depends on the transliteration rules in each country. Meaning that a "real name" converted to machine-readable in country A and then read back in country B might legally get something different than the original "real name". That makes the machine-readable name advisory at best; doesn't sound like it makes much sense to give it a check digit anyway. Meanwhile, the checksummed data can be contrasted visually, since it seems to be standardized to use arabic digits.

Add to that the typical problems when trying to canonicalize names, and maybe you'd also end up deciding that it's better to allow for some leeway.

As a side note, I just realized that each of the 3 debit cards I have (from the same country!) has my name slightly differently. If I had to check programmatically that those names are all the same, I would certainly make the thing fuzzy, and then I don't think I'd care (much?) about a check digit.

A further side note: my obviously alien name in the country where I live always makes for "interesting" situations when dealing with official paperwork. I don't think I have ever managed to have it properly written down in here; but luckily it doesn't matter. The moment that any official, nurse, doctor, HR, whoever hears that I have an official ID number, they just sigh with relief and stop caring about getting the name right. (It's also a relief for me!)

So, in summary: the number is needed, and you better get it right. The name is a convenience.