Supported documents. The document types Verify's backend actually reads

What follows is the exact document list the documents.type database constraint and the capture UI enforce today, checked against that source for this page, not copied from an older draft.

Document type	Physical format	Machine-readable feature	How Verify resolves it
Passport, any country	Booklet	ICAO 9303 MRZ (TD3, data page) + contactless chip on most modern passports	MRZ read, checksum-validated, passes with no human in the loop
National ID card	Card	ICAO 9303 MRZ (TD1, back) + contactless chip	Same as passport: MRZ pass, no human needed
Residence permit	Card	EU/EEA/CH format: MRZ on the back (Reg. (EC) 1030/2002). Turkish ikamet: no MRZ, no chip	Turkish permits: OCR, always human-reviewed. EU/EEA/CH format: see the gap flagged below
Driving licence	Card	No MRZ, no chip, anywhere. US/CA additionally carry an AAMVA PDF417 barcode, error-corrected	US/CA barcode passes with no human in the loop. Every other licence, Turkish included, is OCR-only and always human-reviewed

documents.type CHECK (Postgres): passport | driving_license | national_id | residence_permit
                                  | selfie | voice | nfc

Only the first four are document types a user picks. selfie, voice, and nfc are capture artifacts of the liveness, voice, and chip-read steps, not alternative document types.

"OCR-only, always reviewed" is a real limit. OCR has no checksum on name, date of birth, or expiry, only the document number self-validates, and only where a national check-digit scheme exists, so a misread can look identical to a correct read. The pipeline sends every OCR-only result to a four-eyes reviewer before it can pass. Fine if your users mostly present passports or national ID cards; expect a reviewer on nearly every case if your traffic is driving licences outside the US/CA.

Not ISO 18013-5 mDL/mDoc. This list is the ICAO Doc 9303 machine-readable-document family, MRZ, AAMVA barcode, chip, the same standard the Lexicon's IDV entry documents. It is not the digital mobile driving licence held in a wallet app; Solidus doesn't issue or read one today.

A chip read adds confidence, it doesn't decide alone. Passport and national ID captures get an NFC read attempted where the phone supports it, checked against a server-held trust-anchor store (ICAO 9303 passive authentication), validated so far against synthetic certificates, not yet real passports in production, so today it strengthens a passing MRZ rather than deciding by itself. See Level of Assurance for how a stronger read maps onto Solidus's scale.

Two things you may have seen elsewhere aren't here, deliberately. Which countries you accept per document type is a policy your org sets in the dashboard, not a fixed list any engine enforces globally, sanctioned countries are blocked by default, passport/national ID/driving licence are accepted by default everywhere else, residence permits are opt-in, and any of that is overridable per org. And "bank statement" is an unused policy placeholder with no OCR, MRZ, or checksum path anywhere in the code, not readable today, so not listed above.

This table is checked by hand against the documents.type constraint and the capture UI before every release, last done 2026-07-30. No self-serve endpoint exists yet for a reader to run that check independently; that's the author's pre-publish step today, not a live feed.

One coverage caveat for residence permits specifically. The capture flow asks for a front photo only. That's a complete read for Turkey's ikamet, which has no MRZ by design. It also means a residence permit whose MRZ sits on the back, the EU/EEA/CH format, isn't read today: the flow has no back-image step for this document type yet. If most of your residence-permit volume is Turkish, this doesn't affect you; if it's EU/EEA/CH, confirm directly before you commit to it.

This list is what the document-capture step in how Verify's flow works actually governs.