ID document verification
A document verification API that reads the ID, not just the type on the front.
ShieldID reads a government photo ID front and back on the applicant's own phone, decodes the barcode and the passport machine-readable zone, cross-checks every field against every source, and reports a verdict per field, not one pass or fail for the whole card.
Document coverage
Canadian and US documents, read in depth.
Driver's licences, passports, permanent-resident cards and provincial photo ID, identified by issuer wherever the barcode carries one.
- Canadian driver's licences, all 13 provinces and territories
- US driver's licences, all US states and territories, plus DC
- Passports, read through the machine-readable zone with checksum validation
- Permanent-resident cards
- Provincial and state photo ID cards
- Emerging coverage of two Mexican states.
Where we draw the line, honestly
Health cards are not listed by name among recognised document types today. An unfamiliar or unlisted card is still read under the same principle as everything else: extract what the page shows, and report each field's own verdict, rather than refuse the document at the door.
How a document is read
Four ways in. One priority order when they overlap.
The applicant photographs the front and back of the ID on their own phone. ShieldID reads whichever sources that document actually carries, and lets the most reliable source win where two sources disagree.
PDF417 barcode
The back of a North American driver's licence or ID card carries a PDF417 barcode. ShieldID decodes it into structured AAMVA fields: name, date of birth, address, licence number, expiry and more.Passport MRZ
A passport's machine-readable zone is read by a dedicated detector and reader, then validated against the ICAO check-digit formulas built into the zone itself. A minimum validity score gates whether a field extracted this way is trusted.Structured front reading
The printed face of the document is read field by field, using the layout of the document type where one is recognised.Full-page OCR fallback
When nothing more specific applies, the whole front is read as text. This is what keeps an unfamiliar document from being refused outright.
Priority when sources overlap
Where the same field appears on more than one source, the priority order is barcode, then a passport MRZ that has passed its checksum, then structured front reading, then the OCR fallback. Sources that disagree are flagged for review, never silently averaged.
Cross-checks
Every field is checked against the others, not taken on faith.
A document that reads cleanly on its own can still hide a mismatch between what the front says and what the barcode or the MRZ says. ShieldID checks for that on every verification.
Front vs barcode vs MRZ
Name, date of birth, document number and address are compared across every source the document actually carries. A disagreement is reported, not resolved by picking one and hiding the rest.
Licence-number encoding
Where a province encodes structure into the licence number itself, that structure is checked against the rest of the record.
Three-way identity comparison
The name and identity details read from the document are compared against each other and against what the party requesting the verification asserted about the applicant, so a substitution shows up as a mismatch rather than a clean pass.
The house rule
We never gate on document type.
An unrecognised or unfamiliar document is not rejected because we have not seen it before. ShieldID reads what it can and reports each field's own verdict, so a card from an issuer we have never catalogued can still yield a correct date of birth and a genuine face match, reported as good.
Verdicts are per field, not per document
Name, date of birth, address, document number and photo each stand on their own evidence. One weak field does not drag down a field that checked out cleanly, and a strong field does not paper over one that did not.
Whether to accept the document is your decision
ShieldID reports evidence and a verdict per check. What a business does with an unfamiliar or partially verified document, downstream, is that business's call, with the report in front of them.
Tamper scoring is advisory
Advisory onlyDocument tamper scoring runs on every verification and is reported on the result, but it is advisory today: it does not decide the field verdicts or the overall outcome, and its threshold has not been independently measured against real captures. Treat it as one more piece of evidence, not a gate.
Document presentation-attack detection
Coming soonDetecting that a document is a physical, real object rather than a photo of a printed or screen-displayed document does not exist yet. Today's checks defend the selfie side of the verification; the document side of presentation-attack detection is on the roadmap.
Guided retake
When something fails, we tell you which side to blame.
A failed verification does not always mean the applicant did anything wrong. It might mean the document photo was blurry, or the selfie was underlit, and asking for the wrong one back wastes the applicant's time twice.
ShieldID's retake logic reads the evidence, not the label on the failing check, to decide whether the document or the selfie needs another try, and offers only that side's camera again. It exists because a real case showed a clean selfie and an unreadable, steeply angled passport photo both being told to retake the selfie.
What you get back
Per-field values, each with its source and its verdict.
The result is not a single pass or fail. Every field ShieldID could read comes back with the value, where it came from, and whether it checked out.
- Full name
- Compared across front, barcode and MRZ where present, and against the name asserted by the requester.
- Date of birth
- Cross-checked against the barcode and the MRZ.
- Address
- Read from the front and the barcode where the document carries one; compared against an uploaded address document when required.
- Document number
- Checked for internal consistency and, where applicable, against the encoding rules of the issuing jurisdiction.
- Expiry date
- Read from the front and the barcode or MRZ, flagged if the sources disagree.
- Issuing jurisdiction
- Identified from the barcode issuer code where the document carries a recognised one.
- Document tamper signal
- Reported as advisory evidence on every verification, never as the verdict itself.
Worked example
An Ontario driver's licence, field by field.
A fictional applicant, a fictional licence. The field set, the sourcing and the cross-checks are the real pipeline.
| Field | Value | Source | Verdict |
|---|---|---|---|
| Full name | Jordan Alexander Reyes | Front + barcode (agree) | Match |
| Date of birth | 14 Mar 1994 | Barcode | Match |
| Address | 482 King St W, Toronto ON | Barcode | Match |
| Licence number | R1234-56789-01234 | Barcode; front reads the same string | Match |
| Expiry date | 14 Mar 2029 | Front + barcode (agree) | Match |
| Photo | Present, legible | Front image | Face match: pending selfie |
| Document tamper signal | No indication | Advisory model, cropped document image | Advisory — not gating |
How we compare
Depth on the documents we cover, honesty about the ones we don't.
Categories, not names. The enterprise column describes patterns we found reviewing enterprise IDV vendor sites.
| Capability | ShieldID | Typical enterprise IDV | Manual checks |
|---|---|---|---|
| Reads front and back, barcode and MRZ cross-checked field by field | Yes | Usually | Front only, eyeballed |
| Continues on an unfamiliar or unlisted document instead of rejecting it | Yes | Often refuses | Depends on staff training |
| Per-field verdicts, not one document-level pass or fail | Yes | Rarely | n/a |
| Three-way name and identity comparison against what the requester asserted | Yes | Sometimes | Manual, if at all |
| Guided retake that blames the document or the selfie, based on evidence | Yes | Rarely | n/a |
| Document tamper scoring reported honestly as advisory, not a hidden gate | Yes | Rarely disclosed | No signal |
Questions
Straight answers about document verification.
See it on your own document
Run a sandbox verification with a real driver's licence or passport.
Create a sandbox session, read the front and back on your own phone, and see the per-field result. Sandbox sessions are never billed.