Every identity pipeline that reads passports eventually learns to love the machine readable zone. The two lines of angle brackets at the bottom of the data page are printed in a fixed typeface, in fixed positions, with a fixed alphabet, and they carry their own arithmetic. Parse them, recompute the check digits, and when every digit agrees the record feels finished. Many integrations stop there, and many vendor pages, ours included, list MRZ checksum validation among the structural checks an ID extraction should run.
That check is worth running. It is also routinely asked to prove more than it can. A check digit that agrees tells you one narrow thing: the characters you read in one field are consistent with the digit printed next to them. It does not tell you the characters are the ones the issuer printed, it does not cover every field, and it says nothing at all about whether the document is genuine.
The check that closes most of that gap is already on the document. The visual inspection zone above the MRZ states the same facts a second time, in a different typeface, sometimes on a different side of the card. Reading both and comparing them field by field catches misreads the arithmetic cannot see. And when the two zones disagree, the kind of disagreement tells you what to do next.
What the check digit was designed to prove
The rules live in ICAO Doc 9303, the specification behind machine readable travel documents, currently in its eighth edition (2021). Part 3, section 4.9, is plain about the purpose: check digits “permit readers to verify that data in the MRZ is correctly interpreted.” They are a reading aid. The same part describes the calculation. Multiply each character by a repeating weight of 7, 3, 1, add the products, divide by 10, and keep the remainder. Letters count as 10 to 35 in alphabetical order, and the filler character < counts as zero.
Then comes the detail most integrations never read: which characters are covered. For a passport, the TD3 format described in Part 4 section 4.2.4, the lower MRZ line carries five check digits, and the upper line carries none.
| MRZ data element (TD3) | Check digit | What a misread there costs |
|---|---|---|
| Passport number, lower line positions 1–9 | Own digit at position 10, and in the composite | A record keyed to a document that does not exist |
| Date of birth, positions 14–19 | Own digit at position 20, and in the composite | Wrong age gate, failed watch-list matches |
| Date of expiry, positions 22–27 | Own digit at position 28, and in the composite | An expired document accepted, or a valid one refused |
| Personal number, positions 29–42 | Own digit at position 43, and in the composite | A national identifier attached to the wrong person |
| Nationality (positions 11–13) and sex (position 21) | None: excluded from the composite | Silent; no arithmetic ever looks at them |
| Document code, issuing state and name (upper line) | None | Silent; the whole name field is unprotected |
The name is the field most matching logic leans on, and no check digit covers it. A pipeline that reports “MRZ valid” for a record whose surname was misread is reporting on four other fields.
The misreads a check digit cannot see
Even inside the fields it covers, the arithmetic has blind spots, and they sit exactly where optical reading fails. Because the check works modulo 10, any two characters whose values differ by a multiple of 10 produce the same contribution at every weight. In the Doc 9303 value table, Z is 35 and 5 is 5. S is 28 and 8 is 8. G is 16 and 6 is 6. L is 21 and 1 is 1. And the filler < is worth exactly what 0 is worth.
Those are not exotic pairs. They are the shapes a worn, glared or low-resolution OCR-B line most often confuses. Take a passport number printed as Z58041736. Weighted, its characters sum to 345, and its check digit is 5. Now read the first character as a five: 558041736 sums to 135, and its check digit is also 5. Both readings pass. So does the composite, since it contains the same characters with the same weights shifted.
| Confusable pair | Values | Caught by the check digit? |
|---|---|---|
Z / 5 | 35 / 5 | Never, at any position |
S / 8 | 28 / 8 | Never, at any position |
G / 6 | 16 / 6 | Never, at any position |
L / 1 | 21 / 1 | Never, at any position |
< / 0 | 0 / 0 | Never; a dropped trailing zero looks like padding |
O / 0, B / 8, I / 1 | 24 / 0, 11 / 8, 18 / 1 | Yes, at every position |
Swapping two neighbouring characters has a similar hole: the digit only notices when their values do not differ by a multiple of five, so 05 read as 50 goes through. None of this is a flaw in the standard. A single decimal check digit was never meant to catch every error, and the specification never claims it does. The flaw is in a pipeline that treats a passing check as proof of a correct read.
A passing checksum is not an authenticity signal
The second over-reach is worse, because it turns a reading aid into a security control. The weights, the value table and the field positions are published in a document anyone can download. Whoever produces a document, legitimately or not, computes the same digits. The generative fraud article puts the current version of this in one line about fully generated identities: “The MRZ checks out because the model learned the checksum.” An image model does not need to understand the arithmetic to reproduce it; it only needs to have seen enough real passports.
So a failing check digit is a useful signal, of a misread, a damaged print or a careless forgery, and a passing one is close to no signal about authenticity. Evidence that a passport is genuine comes from elsewhere: the signed data on the chip, which Doc 9303 treats separately under its security mechanisms, and the physical and forensic checks the fraud article describes. This article stays on the other question, the one the check digit was built for: did we read what the issuer printed?
The visual zone is a second reading of the same facts
Doc 9303 says it directly in Part 3: “The MRZ is a different representation of the data than is found in the VIZ.” The visual inspection zone holds the same holder name, document number, dates and nationality, set in the issuer’s own typography, often with diacritics and national script. It is printed at a different size, in a different font, in a different place, which means its reading errors are largely independent of the MRZ’s.
That independence is what makes the comparison valuable. A glare patch that turns the first character of the MRZ number into a 5 rarely lands on the same character in the visual zone as well. When the two readings of the passport number agree, you have a confirmation the check digit could not give you. When they disagree and the MRZ passes its own arithmetic, you have found exactly the case the arithmetic misses. And the name, which no check digit protects, becomes checkable only this way.
Differences the standard requires
Comparing the two zones naively produces a flood of false disagreements, because the specification obliges the issuer to write several fields differently in each. The MRZ allows only upper-case Latin letters, digits and the filler, so Part 3 sets out how names change on the way down.
- Transliteration — national characters and diacritics in the visual zone are converted to OCR-B letters in the MRZ, using the tables in Part 3 section 6, so an accented surname loses its accent below.
- Punctuation — an apostrophe is dropped (
D’ARTAGNANbecomesDARTAGNAN), a hyphen becomes a filler (MARIE-ELISEbecomesMARIE<ELISE), and a separating comma becomes the double filler between surname and given names. - Truncation — a passport name field holds 39 characters; a longer name is cut, and an alphabetic character in the last position signals that truncation may have happened.
- Titles and suffixes — prefixes such as Dr. or suffixes such as Jr. are left out of the MRZ unless the issuing state treats them as part of the legal name.
- Encodings — dates are six digits, year first, in the MRZ and in the issuer’s own format above; nationality is a three-letter code below and often a word above.
The comparison has to apply the same rules the issuer applied, in the same direction: take the visual reading, transliterate, strip and truncate it as Doc 9303 prescribes, and compare the result with the MRZ reading. Record which rule turned one into the other. A reviewer who sees “matched after transliteration” knows why two different-looking strings were accepted as one name.
Three divergences, three different actions
Once the legitimate differences are normalised away, what remains is a real disagreement between two readings of what should be one document. It tends to come in three shapes, and the shape, more than the disagreement itself, decides what happens next.
| Divergence | What it looks like | Likely cause | Action |
|---|---|---|---|
| Transcription | One field differs by one or two characters, usually a confusable pair; everything else agrees | A misread in one zone, or a damaged print | Re-read both crops; if still split, recapture or send to review with both values. Never keep the value simply because it passes the check digit |
| Reissue | Name and date of birth agree; document number, issue and expiry dates differ | Images from two issuances of the same person’s document, typically the front of a renewed card with the back of the old one | Request both sides again in one session; do not assemble a record from two documents |
| Swapped document | Name or date of birth differ; each zone is internally consistent and the MRZ passes every check digit | Two different people’s documents in one submission, often members of one household | Refuse the pairing and send it to review; do not choose the zone that looks better |
The transcription case is the one the check digit was meant to help with, and the trap is to let the digit arbitrate. If the visual zone says Z58041736 and the MRZ reading says 558041736, both pass the MRZ arithmetic, and the check digit has no vote. A second, sharper read of both crops usually settles it. When it does not, the record goes forward with both candidate values and their locations, not with a guess.
The swapped case deserves emphasis because it defeats every per-zone control at once. Each side is a real, valid, internally consistent document. Only the comparison reveals that they are two documents. It is not automatically fraud, since people upload a spouse’s card by mistake more often than anyone likes to admit, but it is never something the pipeline should resolve by itself.
When the two zones live on two sides of a card
On a passport data page the visual zone and the MRZ are printed together, so a mismatch between them in a single image is rare and serious. Identity cards are different. For the TD1 card size, Doc 9303 Part 5 places the MRZ in Zone VII on the reverse side, as three lines of 30 characters, while most of the visual zone sits on the front. The two readings arrive as two images, possibly minutes apart, possibly from two uploads.
That is where the reissue and swap cases concentrate. A customer with a renewed card photographs the new front and, from the same drawer, the old back. The front shows one expiry, the back another, and both are right about the card they belong to. The pipeline that extracts each side into the same record without comparing them ends up storing a document that was never issued.
So for two-sided documents, the pairing is itself a fact to extract and check: which image supplied each field, captured when, and whether the document number and dates agree across sides before any field from one side is trusted to describe the other. Pairing at capture, in a single guided session that asks for the front and then the back, prevents most of these cases before extraction runs.
What the extraction has to deliver
The contract between reading an identity document and deciding what to do with it is a set of facts with evidence, including the disagreements.
- Both readings, per field — the visual zone value and the MRZ value, side by side, rather than one merged value that hides where it came from.
- The raw MRZ lines — exactly as read, fillers included, so any check can be recomputed later without re-running extraction.
- Check digit results, labelled as consistency — the printed digit and the computed one for each covered field, with the uncovered fields named as uncovered.
- The normalisation applied — which transliteration, punctuation or truncation rule made two strings comparable.
- The divergence class — none, transcription, reissue or swapped, with the fields that support it.
- A citable origin for each value — image, side, page and region under the same coordinate contract any reviewable extraction owes, so a reviewer can go from a flagged field to the characters on both zones in one step.
That is the shape of output the ID card OCR page describes in general terms: MRZ data when present, and sensitive fields carrying page evidence, bounding-box location, confidence and validation status. The acceptance decision stays with the business: which divergences block onboarding, which go to review, and how many recaptures a customer is asked for.
Not fraud detection, not face matching, not capture quality
Three neighbouring problems touch the same document and should stay separate from this one.
Whether a document is genuine is the subject of the generative fraud article, and this piece deliberately does not answer it. A document can pass every comparison here and still be fabricated, because a forger who prints consistent zones has not been inconvenienced. Agreement between zones is evidence of a correct read, and only that.
Whether the person holding the document is the person on it is a biometric question, covered in the face match article, including what to do when two documents in one case disagree about the face. The zone comparison runs before that and answers a narrower question: is this one document, read correctly?
Whether the image is usable at all, sharp enough, uncropped and free of glare, belongs at capture, as the capture-time validation article argues. A blurred MRZ should be sent back before either zone is read, rather than being rescued by comparison afterwards.
Agreement, not arithmetic
The machine readable zone is one of the best-engineered pieces of text in everyday life, and its check digits do their job well. They catch most single-character misreads in four fields. The mistake is in asking them to do other jobs: protect the name, catch a Z read as a 5, or vouch for the document.
So run the arithmetic, and report it as what it is. Then read the visual zone as a second witness, normalise it by the rules the issuer followed, and compare field by field. Treat a mismatch as information with a shape: a misread to re-read, a reissue to recapture, a swap to refuse. The record that comes out is one you can defend, because every field in it was read twice and agreed with itself.