MRZ Code Philippines: Reading Passport Data for KYC
The MRZ (Machine Readable Zone) is the block of fixed-width characters at the bottom of a passport data page that encodes identity data for automated reading, standardised by ICAO Doc 9303. Philippine passports use the TD3 format: two lines of 44 characters. One change matters urgently for anyone running a Philippine KYC pipeline.
According to the Philippine News Agency (March 2026), the DFA adopted the two-letter document type code “PP” for regular Philippine ePassports issued from 1 March 2026. Parsers built to expect the single letter “P” will misread these documents.
What Is an MRZ Code?
Look at the bottom of any passport data page and you will find two lines of evenly spaced capital letters, numbers, and chevron characters. That block is the Machine Readable Zone.
Its purpose is reliability. Passport designs vary enormously across 193 issuing states: different layouts, fonts, languages, and security features. The MRZ sidesteps all of that by encoding the same core identity fields in the same positions, in a fixed-width OCR-B typeface, on every compliant document in the world. A reader does not need to understand a passport’s design to extract its data. It only needs to know the character positions.
The standard behind it is ICAO Doc 9303, now in its eighth edition (2021). ICAO has required member states to issue only machine-readable passports since 1 April 2010.
One point that gets misunderstood: the MRZ encodes data, it does not encrypt it. Anyone who can read the character positions can read the holder’s details. Confidentiality is not what the MRZ provides. Machine readability is.
The Three MRZ Formats: TD1, TD2, TD3
ICAO defines three formats matched to ISO/IEC 7810 document sizes.
| Format | Layout | Typical document |
|---|---|---|
| TD1 | 3 lines x 30 characters | Credit-card sized ID documents |
| TD2 | 2 lines x 36 characters | Relatively rare official travel documents |
| TD3 | 2 lines x 44 characters | Passport booklets, including Philippine passports |
Philippine passports are TD3. If you are building for the Philippine market specifically, TD3 is the format your parser has to handle correctly, though a system that also accepts foreign documents will encounter all three.
Philippine Passport MRZ: What Each Line Carries
Both lines run exactly 44 characters. Unused space is padded with the chevron filler character, which is why the lines end in long runs of it.
Line 1 carries the document type code, the issuing state, and the holder’s name. The issuing state for a Philippine passport is PHL, the ISO 3166-1 alpha-3 code. The name field separates surname from given names with a double chevron, and pads the remainder.
Line 2 carries the structured data: passport number in the first nine positions, then a check digit, then nationality, date of birth in YYMMDD, another check digit, sex, expiry date in YYMMDD, another check digit, an optional data field, a check digit for that field, and finally a composite check digit covering the whole line.
Dates are the field that causes the most integration pain. YYMMDD has no century, so a date of birth reading 51 could be 1951 or 2051. Parsers need a windowing rule, and the rule has to differ between the birth date field and the expiry field, because an expiry date is always in the future while a birth date never is.
The “PP” Change: What Happened on 1 March 2026
This is the section to read if you operate a Philippine KYC flow today.
According to the Philippine News Agency (March 2026), the Department of Foreign Affairs adopted the two-letter document type code “PP” for regular Philippine ePassports starting 1 March 2026. The code appears in both the Visual Inspection Zone and the Machine Readable Zone of all newly issued regular ePassports. The DFA stated the move aligns with ICAO Doc 9303, which requires member states to adopt harmonised secondary document type indicators.
Crucially, the change is not retroactive. The DFA confirmed that regular Philippine ePassports issued before 1 March 2026 carrying the single-letter code “P” remain valid until their expiration dates.
Put those two facts together and the operational consequence becomes clear: for roughly the next ten years, Philippine passports in circulation will carry either “P” or “PP”, and a compliant system has to accept both.
What this breaks in practice: any parser with a hardcoded assumption that position 2 of line 1 is a filler character rather than a second type letter. A system expecting “P<PHL” and receiving “PPPHL” can misalign the name field, fail a format validation, or reject a genuine passport outright. Rejection of valid documents at onboarding is the expensive failure mode here, because it looks like fraud prevention working when it is actually conversion loss.
How Check Digits Validate MRZ Data
The MRZ carries its own error detection, which is what makes it more reliable than reading the printed data page.
Each check digit is computed over a specific field using a repeating weight pattern of 7, 3, 1 applied across the characters. Digits use their face value, letters map to numeric values from A as 10 through Z as 35, and the filler chevron counts as zero. Multiply, sum, take modulo 10, and the result is the check digit.
The final composite check digit on line 2 covers the passport number, date of birth, expiry date, and optional data fields together. A single OCR misread anywhere in those fields will fail the composite check.
Here is where teams leave value on the table. A verification flow that extracts MRZ data without validating the check digits is treating the MRZ as plain OCR output, and discarding the built-in integrity mechanism. Check digit validation catches OCR errors, and it also catches crudely altered documents where a fraudster changed a printed digit without recomputing the checksum.
MRZ vs QR Code vs Barcode: What Philippine IDs Actually Use
A common integration mistake is assuming MRZ is the universal machine-readable layer for Philippine documents. It is not. Different Philippine IDs encode data differently, and each demands a different extraction path.
| Document | Machine-readable layer | Extraction method |
|---|---|---|
| Philippine passport | MRZ (TD3), plus NFC chip on ePassports | OCR of the MRZ, or chip read |
| PhilID / ePhilID | QR code | QR decode and PhilSys Check |
| UMID | Card-based encoding, no MRZ | OCR of printed fields |
| Driver’s licence | No MRZ | OCR of printed fields |
The PhilSys route works differently from MRZ in an important way, and we cover it in the guide to PhilSys formats and the QR code verification path. MRZ validates internally through check digits. PhilSys QR validates externally against a government service. Neither approach substitutes for the other, and a Philippine KYC stack that accepts multiple ID types needs both.
For a fuller picture of which Philippine documents a verification flow should handle, see our overview of Philippine ID verification.
MRZ in an eKYC Pipeline
Reading an MRZ in production is harder than reading the specification suggests, because real submissions are photographs rather than scans.
The recurring failure conditions: glare across the MRZ from a phone flash, curvature from a passport that will not lie flat near the spine, low resolution that blurs the distinction between characters like 0 and O or 1 and I, and cropping that clips the final characters of line 2, taking the composite check digit with it.
A production-grade flow handles these by capturing at sufficient resolution, correcting perspective and curvature before OCR, validating every check digit rather than only the composite, and cross-checking MRZ output against the printed Visual Inspection Zone on the same page. That last check is the one that catches document tampering, because an altered VIZ paired with an untouched MRZ produces a mismatch.
Verihubs eKYC API handles MRZ extraction alongside 15+ Philippine document types, with check digit validation and VIZ cross-matching built into the flow.
Frequently Asked Questions About MRZ
What does MRZ stand for?
MRZ stands for Machine Readable Zone. It is the block of fixed-width characters at the bottom of a passport data page, or on the back of some ID cards, that encodes identity data in a standard format defined by ICAO Doc 9303.
What MRZ format does the Philippine passport use?
TD3, the standard passport booklet format: two lines of 44 characters each. TD1 (three lines of 30 characters) is used for card-sized documents and TD2 (two lines of 36 characters) is relatively rare.
What is the “PP” code on Philippine passports?
According to the Philippine News Agency (March 2026), the DFA adopted “PP” as the two-letter document type code for regular Philippine ePassports issued from 1 March 2026, appearing in both the Visual Inspection Zone and the MRZ. Passports issued before that date with the single letter “P” remain valid until they expire, so both codes will be in circulation for years.
Does the Philippine national ID have an MRZ?
No. The PhilID and ePhilID use a QR code rather than an MRZ. Verification runs through PhilSys Check against the government service, not through MRZ check digits.
How do MRZ check digits work?
Each check digit is calculated over a field using a repeating weight pattern of 7, 3, 1. Digits take their face value, letters map from A as 10 through Z as 35, and the filler chevron counts as zero. The weighted sum modulo 10 gives the check digit. A composite check digit on line 2 covers several fields together, so any single OCR error will fail validation.
Is MRZ data encrypted?
No. The MRZ encodes data in a standard readable format but does not encrypt it. Anyone able to read the character positions can read the holder’s details. Its purpose is machine readability and error detection, not confidentiality.
The MRZ Is Only Useful If You Validate It
Plenty of systems extract MRZ data and stop there, treating those 88 characters as a convenient shortcut for filling form fields. Doing that throws away the two things the MRZ is actually good for: check digits that catch both OCR errors and crude tampering, and a fixed structure that can be cross-matched against the printed data page.
The Philippine market adds a live example of why parsing discipline matters. A system that assumed “P” would always be the document type code now encounters “PP” passports every day, and the failure is silent: valid customers rejected at onboarding, recorded as fraud prevention rather than as a parsing bug.
Verihubs eKYC API reads and validates MRZ for Philippine and foreign passports, cross-checks against the visual inspection zone, and handles the QR-based PhilSys formats in the same flow. For a broader comparison of what to look for, see our review of KYC solutions in the Philippine market.
Talk to the Verihubs team about MRZ and document verification for your onboarding flow.
