Passport KYC: Automating Identity Verification in the US

If your business has to identify its customers, the passport is the document that gives you the least friction: it's accepted everywhere, both citizens and foreign nationals carry one, and — unlike almost any other document — it comes with verification built into the document itself.

This article covers the operational part: getting from a photo to a solid, auditable file.

This is an implementation guide, not legal advice. Your specific obligations depend on the regime your business falls under; confirm them with your legal or compliance team.

Why the passport is the best document to automate

Compared with the other IDs you receive:

	Passport	Driver's license	National ID card
Standardised format	International (ICAO 9303)	Per state	Per country
Verification inside the document	Yes, 4 check digits	No	Sometimes
Works for foreign nationals	Yes	Limited	Limited
Design variants to support	Few per country	Dozens	Several per country

That "yes" in row two is the structural difference. On a driver's license, if the OCR misreads a character, you only find out by checking against an external registry. On a passport, the MRZ verifies itself: four check digits confirm the passport number and dates were read correctly, using arithmetic, without leaving your server. The algorithm is in ICAO 9303 check digits.

What a reading produces

From the data page you get, structured:

{
  "passportNumber": "G12345678",
  "surname": "GOMEZ VELAZQUEZ",
  "givenNames": "MARGARITA",
  "nationality": "MEX",
  "issuingCountry": "MEX",
  "dateOfBirth": "05/07/1980",
  "dateOfIssue": "10/03/2023",
  "dateOfExpiry": "05/07/2033",
  "sex": "F",
  "placeOfBirth": "CIUDAD DE MEXICO",
  "issuingAuthority": "SRE",
  "mrzLine1": "P<MEXGOMEZ<VELAZQUEZ<<MARGARITA<<<<<<<<<<<<<",
  "mrzLine2": "G123456786MEX8007050F3307054<<<<<<<<<<<<<<08"
}

That covers full name, date and place of birth, nationality, sex, and the document's number and validity — the core of any identification file.

Store the MRZ, not just the fields

The least obvious and most valuable recommendation here: keep mrzLine1 and mrzLine2 verbatim, alongside the extracted fields.

It's 88 characters. And it gives you something the parsed fields don't:

Auditable evidence. Two years from now, when someone asks where that date of birth came from, the stored MRZ lets you recompute the check digits and demonstrate the reading was self-consistent at capture time. That's reproducible proof, not an assertion.

Reprocessing without re-contacting the customer. If you change your mind about how to parse names, you can reprocess the stored MRZ without bothering anyone.

Duplicate detection. Passport number plus issuing country identifies the document uniquely and stably.

A complete identification flow

1. Capture — photo of the data page, both lines at the foot visible. Failure causes and fixes are in Common passport scanning errors.
2. Extraction — one API call returns structured fields and a validated MRZ.
3. Validity check — the document must not be expired; depending on the case, with margin. See How to check passport validity.
4. Consistency — the extracted name matches the declared one; dates agree with each other.
5. Watchlist screening — a separate step with its own sources.
6. The file — data, MRZ, image and timestamps, retained for whatever period applies to you.
7. Human review on exceptions — not on every case, only the ones the system flags.

Steps 2 and 3 automate completely. Step 4 automates with a threshold. Step 5 depends on your sources. Step 7 is where human judgement goes — which is why it matters that the system is explicit about when it isn't sure, rather than always producing an answer.

The design that prevents the worst failure

The worst outcome in an identification flow isn't a visible error: it's plausible, wrong data entering the file unnoticed. A passport number with one character changed has exactly the right shape and passes any format validation.

So it's worth demanding two behaviours from your extraction vendor:

• That it fails explicitly when it can't read confidently, instead of returning its best guess. Our API responds 422 LOW_IMAGE_QUALITY with the list of unreadable fields, and refunds the token.
• That it exposes the evidence — the complete MRZ — so you can re-validate independently rather than trusting.

Privacy: less data, less risk

An identification file is among the most sensitive personal datasets your business will handle. Two architectural decisions cut the exposure considerably:

Don't keep the image longer than necessary. Once the data is extracted and validated, the passport photograph is usually the highest-risk and lowest-utility asset you hold. If your compliance framework requires retaining it, encrypt it at rest and narrow who can view it.

Choose a vendor that doesn't retain. In our case, a successful extraction leaves no document data stored: it's processed, returned, and not kept. What remains is the billing record, with no document contents. An exposure surface that doesn't exist can't leak.

Get started

The free demo processes a passport with no signup, and creating an account gives you 20 extractions to test the full flow against your own documents. Step-by-step integration is in How to integrate a passport OCR API, and the complete reference is in the documentation.