# Passport MRZ Verification: The Actual Checksum Math

> Passport MRZ verification: the actual ICAO 9303 checksum algorithm, a fully computed worked example, and why it also catches OCR errors, not just fraud.

**Canonical URL:** https://docsapi.co/resources/blogs/mrz-passport-verification
**Author:** Nupura Ughade — Content Marketing Lead, DocsAPI
**Author LinkedIn:** https://www.linkedin.com/in/nupura-ughade/
**Published:** 2026-08-08T00:00:00.000Z
**Updated:** August 8, 2026
**Primary topic:** mrz passport verification
**Site:** https://docsapi.co (DocsAPI — Document AI & OCR API for SMB Lending)

---

KYC vendor content is consistent and confident on one point: the Machine Readable Zone on a passport contains checksums, and validating them catches document tampering. What that content almost never does is show the actual algorithm, the exact letter-to-number conversion, the weighting pattern, or a real, fully computed example proving the math genuinely works the way it is described. "The math is non-trivial" is a true statement that explains nothing.

This is the complete, real ICAO 9303 checksum algorithm, worked through carefully with real numbers from start to finish, the specific technical mechanics sitting underneath [automated identity proofing](/use-cases/id-proofing), and why it actually does more than just catch fraud. It sits alongside the broader document-verification pipeline covered in our [KYC document verification guide](/resources/blogs/kyc-document-verification).

## Why the MRZ is more reliable to extract than the printed page above it

The Machine Readable Zone, the two or three lines of dense, fixed-width text sitting at the bottom of a passport's data page, is printed in OCR-B, a typeface specifically designed for reliable machine reading, distinct from whatever font the document's visual header data uses. This is a genuine, structural reason MRZ extraction is more dependable than reading a passport's printed name or issuing-authority fields: the character shapes themselves were chosen to minimize ambiguity for automated recognition, not for human readability or design consistency with the rest of the page.

## The actual algorithm, step by step

Every numeric or alphanumeric field the MRZ checksums, document number, date of birth, expiry date, and an optional personal-number field, follows the exact same identical procedure every single time, with no field-specific variation in the underlying math itself. First, convert every character to a numeric value: digits 0 through 9 keep their own value, letters A through Z map to 10 through 35 in alphabetical order, and the filler character, a less-than sign used to pad short fields to their fixed length, maps to 0. Second, multiply each character's value by a weight that repeats in the sequence 7, 3, 1 across the field from left to right, position one gets weight 7, position two gets weight 3, position three gets weight 1, position four cycles back to weight 7, and so on. Third, sum every product. Fourth, divide that sum by 10 and take the remainder, that remainder is the check digit, printed as the single character immediately following the field it validates.

| Step | What happens |
| --- | --- |
| 1. Convert | 0-9 stay as-is, A-Z become 10-35, filler "<" becomes 0 |
| 2. Weight | Multiply each value by the repeating pattern 7, 3, 1, left to right |
| 3. Sum | Add every product together |
| 4. Mod 10 | The remainder after dividing the sum by 10 is the check digit |

## A fully worked example, computed field by field

Take a document number of AB1234567. Converting each character: A=10, B=11, then 1, 2, 3, 4, 5, 6, 7 as themselves. Applying weights 7, 3, 1 repeating across the nine positions gives products of 70, 33, 1, 14, 9, 4, 35, 18, and 7. Summing those: 191. The remainder after dividing by 10 is 1, so the check digit for this document number is 1, and the full field prints as AB12345671.

Take a date of birth of 850315 (March 15, 1985). Values 8, 5, 0, 3, 1, 5 with weights 7, 3, 1, 7, 3, 1 produce products of 56, 15, 0, 21, 3, and 5. Summing: 100. The remainder is 0, so the check digit is 0, and the field prints as 8503150.

Take an expiry date of 300420 (April 20, 2030). Values 3, 0, 0, 4, 2, 0 with the same repeating weights produce products of 21, 0, 0, 28, 6, and 0. Summing: 55. The remainder is 5, so the check digit is 5, printing as 3004205.

With no personal-number data, that 14-character field is entirely filler characters, each valued at 0 regardless of weight, producing a sum of 0 and a check digit of 0.

## The composite check digit that ties every field together

A final composite check digit runs the identical algorithm over a concatenation of specific character ranges pulled from across the line: the document number and its own check digit, the date of birth and its check digit, and the expiry date, its check digit, the personal-number field, and that field's check digit, all strung together into one 39-character string. Running our four computed fields through that concatenation, "AB12345671" plus "8503150" plus "3004205" plus fourteen filler characters plus a final "0", and applying the same weight-multiply-sum-mod-10 procedure across all 39 positions produces a sum of 298. The remainder after dividing by 10 is 8, the composite check digit, a single character validating that every other checksummed field on the line is internally consistent with every other one, not just individually correct on its own.

## What a single-digit tampering attempt actually looks like under this math

Suppose a forger, working from a genuine document as a template, alters the printed date of birth from 850315 to 850305, changing the day from 15 to 05, without recalculating the field's check digit, which remains the original 0. Recomputing the checksum on the altered value: 8, 5, 0, 3, 0, 5 with weights 7, 3, 1, 7, 3, 1 gives products of 56, 15, 0, 21, 0, and 5, summing to 97. The remainder is 7. The document now shows a printed check digit of 0 sitting next to a field whose actual, recalculated check digit is 7, an immediate, unambiguous mismatch. This is the entire mechanism by which the checksum catches tampering: altering the visible data without correctly recalculating and re-printing the corresponding check digit, a step a forger working from a template or a doctored image frequently gets wrong or skips entirely.

## Why the check digit is also a free OCR-error detector, not only a fraud check

This same mechanism catches something with nothing to do with fraud at all: an OCR misread. If an extraction pipeline reads a single character of the MRZ incorrectly, a smudge turning a 3 into an 8, a scan artifact turning an O into a 0, the recalculated check digit will almost certainly no longer match the printed one, exactly the same signature a tampered document produces. This means checksum validation should run on every genuine, unaltered document too, not only as a fraud screen, since a checksum failure on a document that is actually legitimate is frequently telling you the extraction step itself made an error, not that the document is fake, a distinction worth building explicit routing for rather than treating every checksum failure as an automatic fraud flag.

## Why document-type classification has to happen before checksum validation can even run

ICAO 9303 defines multiple machine-readable document formats, TD1 for ID cards, TD2 for certain official travel documents, TD3 for standard passports, each with a different field layout, length, and line count. The specific character ranges the composite check digit concatenates differ by format. A pipeline that tries to apply TD3 field-position logic to a TD1 document, or vice versa, will compute checksums against the wrong character ranges entirely and fail validation on genuinely correct documents, an error that looks identical to a tampering flag unless the document type was correctly classified first, before any checksum math runs at all.

## The filler-character rule that trips up short document numbers and personal numbers

Document number fields and the personal-number field are fixed-length, nine and fourteen characters respectively on a TD3 passport, but the actual values they hold are frequently shorter, since not every country issues document numbers or national identifiers that fill the entire allotted width. The remaining, unused positions are padded with the filler character, which the algorithm treats as a value of 0 regardless of position or weight. An extraction pipeline that fails to correctly identify filler characters, misreading a faint or partially obscured "<" as some other character, or, conversely, treating genuine leading or trailing data as filler by mistake, corrupts the checksum calculation before it even runs, producing a validation failure on a document whose actual data was extracted correctly everywhere except the filler boundary itself.

## Why this deserves more scrutiny than a document type with fewer checksummed fields

A passport MRZ checksums four separate fields plus a composite, five distinct opportunities for the algorithm to catch either tampering or an extraction error, compared to simpler machine-readable formats that checksum only one or two fields. This makes a passport's MRZ a genuinely richer verification signal than many other machine-readable document types, but only if a pipeline actually implements and checks all five, not just the composite alone. A pipeline that only validates the composite check digit and skips the four individual field checksums still catches most tampering, since tampering with any field breaks the composite too, but it loses the more specific diagnostic value of knowing exactly which individual field failed, information that matters directly for deciding whether a failure looks like an OCR error concentrated in one field or a deliberate alteration.

## What I would check in your current MRZ verification pipeline

Ask whether your pipeline actually recomputes every field checksum, including the composite, or only extracts the MRZ text and trusts it without validation, since extraction accuracy and checksum validity are two different claims and only the second one actually catches tampering or misreads. Then ask whether a checksum failure routes differently depending on likely cause, a probable OCR misread on an otherwise-consistent document versus a genuine tampering signal, or whether every failure gets treated identically regardless of context. Confirm document-type classification, TD1, TD2, or TD3, runs before checksum logic, using the correct field-position rules for that specific format rather than a single hardcoded layout. And check specifically how filler characters are handled during extraction, since a misread filler boundary corrupts the checksum before the algorithm itself ever gets a chance to run correctly.

### Frequently asked questions

**What is the ICAO 9303 MRZ checksum algorithm?**
 Convert each character to a number (digits as themselves, A-Z as 10-35, filler as 0), multiply by a repeating 7-3-1 weight pattern left to right, sum the products, and take the remainder after dividing by 10. That remainder is the check digit.

**What does the composite check digit on a passport MRZ actually validate?**
 It runs the same algorithm over a concatenation of the document number, date of birth, and expiry date fields along with their individual check digits, confirming every field is internally consistent with every other one, not just individually correct.

**Does a failed MRZ checksum always mean the document is fraudulent?**
 No. A checksum failure can also indicate an OCR misread during extraction rather than actual tampering. Both produce the identical signature, a mismatch between the printed check digit and the recalculated one, and need different handling.

**Why is the MRZ more reliable to extract than the rest of a passport's data page?**
 It is printed in OCR-B, a typeface specifically designed for reliable machine reading, unlike the fonts used for the document's other printed fields.

**Why does document type need to be classified before checksum validation runs?**
 ICAO 9303 defines different formats, TD1, TD2, TD3, with different field layouts and lengths. Applying the wrong format's field-position rules produces checksum failures on genuinely valid documents.

**What happens to a checksum if a forger changes a digit but doesn't update the check digit?**
 The recalculated check digit no longer matches the printed one. A worked example altering a date of birth by one digit shows the check digit shifting from 0 to 7, an immediate, detectable mismatch.

Explaining that MRZ checksums catch tampering is true and, on its own, not particularly useful to anyone building or evaluating a verification pipeline. The actual algorithm is simple enough to compute by hand, as the worked example above shows, arithmetic a person could genuinely check with pencil and paper in a couple of minutes, and understanding it is the difference between trusting a vendor's claim and actually knowing what your own pipeline is, or is not, checking. Written by [Nupura Ughade](/author/nupura-ughade).

## Frequently Asked Questions

### What is the ICAO 9303 MRZ checksum algorithm?

Convert each character to a number (digits as themselves, A-Z as 10-35, filler as 0), multiply by a repeating 7-3-1 weight pattern left to right, sum the products, and take the remainder after dividing by 10. That remainder is the check digit.

### What does the composite check digit on a passport MRZ actually validate?

It runs the same algorithm over a concatenation of the document number, date of birth, and expiry date fields along with their individual check digits, confirming every field is internally consistent with every other one.

### Does a failed MRZ checksum always mean the document is fraudulent?

No. A checksum failure can also indicate an OCR misread during extraction rather than actual tampering. Both produce the identical mismatch signature and need different handling.

### Why is the MRZ more reliable to extract than the rest of a passport's data page?

It is printed in OCR-B, a typeface specifically designed for reliable machine reading, unlike the fonts used for the document's other printed fields.

### Why does document type need to be classified before checksum validation runs?

ICAO 9303 defines different formats, TD1, TD2, TD3, with different field layouts and lengths. Applying the wrong format's field-position rules produces checksum failures on genuinely valid documents.

### What happens to a checksum if a forger changes a digit but doesn't update the check digit?

The recalculated check digit no longer matches the printed one. A worked example altering a date of birth by one digit shows the check digit shifting from 0 to 7, an immediate, detectable mismatch.


---

**Source URL (cite this):** https://docsapi.co/resources/blogs/mrz-passport-verification
**Author profile:** https://docsapi.co/author/nupura-ughade
**Published by:** DocsAPI (https://docsapi.co)