ID document data extraction for onboarding

Opening a bank account, signing a mobile contract, hiring an employee (right-to-work check) or registering for a public service starts with copying data from an ID document. Document AI reads the document from a phone photo, scan or NFC chip, validates it internally (MRZ check digits, expiry, consistency between zones) and hands clean structured data to the onboarding process. This use case is about reading and validating the data; forgery and liveness detection (ANOM-014) and sanctions screening (ANOM-016) are neighbouring, separate steps.

Problem & value

• Today: staff retype data from copies, or applicants fill in forms by hand and upload a photo. This causes typos, abandoned sign-ups and media breaks. Regulated firms (banks, insurers, crypto-asset providers, notaries, estate agents) must identify customers under anti-money-laundering law and keep evidence.
• AI value: pre-filled forms from a photo, fewer abandoned onboardings, consistent data for downstream KYC/AML checks, less manual keying, auditable evidence of what was read.
• Sourced facts: Azure Document Intelligence's prebuilt ID model covers passports and ID documents from regions worldwide since API v4.0 (2024-11-30) [1]; Amazon Textract AnalyzeID normalises keys across different ID layouts, but is documented for US-issued documents [2]. Public benchmarks with measured onboarding conversion gains are mostly vendor-published; ask vendors for results on your document mix rather than relying on marketing figures.

Variants

• Banking / insurance / payments / crypto: KYC onboarding under AML law, often with video or selfie identification (see AGENT-015).
• Telecom, car sharing, hospitality: age and identity checks at sign-up or check-in (hotel registration forms).
• HR: right-to-work and identity checks for hiring; copy retention rules are strict.
• Public sector: online service registration, with the eID function of the German ID card or, from end of 2026, the EU Digital Identity Wallet as the preferred source of attested data [6].
• Private use: autofill of travel or visa forms from a locally processed passport photo.
• Out of scope: real-time identification of persons in public spaces (see "Risks").

How it works

1. capture (mobile SDK / web upload / NFC read / branch scanner)
2. quality check (glare, blur, crop, all four edges visible)
3. document classification (country, type, version/template year)
4. OCR + field extraction (VIZ) and MRZ / barcode parsing
5. NFC chip read (passive authentication of SOD signature) where available
6. plausibility checks (MRZ check digits, expiry, VIZ = MRZ = chip, age rules)
7. [optional] face match + liveness (ANOM-014), fraud/tamper checks, sanctions screening
8. human review for low confidence or mismatches
9. write to CRM / core system

• Extraction: specialised ID models or VLMs return JSON against a schema; the machine-readable zone (MRZ) is parsed deterministically with check digits, which is far more reliable than free OCR of the printed fields.
• Chip reading of eMRTDs (ICAO Doc 9303) provides cryptographically signed data and is the strongest data source; image extraction is the fallback.
• Human-in-the-loop: mismatch between visible zone, MRZ and chip, or low-confidence fields, goes to an agent with the source image highlighted. Identity decisions in regulated settings stay with accountable staff or a certified process.

Data preparation

Which data: images of identity cards, passports and residence permits (front, back, selfie for matching), the target fields, and the existing customer or employee master record to match against.

Where it lives: mobile app or web upload, e-mail attachments, customer systems (CRM, core banking), HR files, and paper copies at reception desks.

Typical gaps: poor photos, glare, cropped edges, many document types and countries, copies stored without need or deletion periods, and unclear legal basis for keeping the image.

Preparation steps: 1. Define which document types and countries are accepted. 2. Set capture guidance in the upload flow (frame guide, auto-capture) to improve quality at the source (PREP-008). 3. Map extracted fields to the master record and define matching rules (PREP-002, PREP-005). 4. Fix retention and deletion rules; store only needed fields (PREP-025). 5. Assemble a small test set with synthetic or specimen documents, not real customer IDs (PREP-018, PREP-022). 6. Classify ID data as highly sensitive and restrict access (PREP-024).

Tools: the provider's SDK for capture, test specimens, the CRM or core system interface.

Rough share of effort: low, about 10 to 20 percent; the main work is process, retention and legal clarity. See GUIDE-003.

Implementation paths

Which path for whom

• SMB — Path A: certified identity-verification services with EU hosting exist at per-check prices; building ID checks yourself is risky and rarely pays off.
• Enterprise — Path B: high onboarding volume and own KYC rules justify cloud APIs with own orchestration, while the liveness and fraud checks stay with a certified provider.
• Developer — Path B: extraction through EU-hosted APIs is the practical route; self-hosting ID checks without certification gives no regulatory value.
• Public — Path A: only certified products (e.g. eID, qualified identification services) are accepted for official identification, so buy them.

Path A — Buy (recommended for SMBs and public bodies)

• Identity-verification (IDV/eKYC) platforms: IDnow (DE), WebID (DE), Nect (DE), Authada (DE), Veriff (EE), Signicat (NO), Ondato (LT), Onfido/Entrust, Jumio, Mitek, Sumsub. Prefer EU hosting, certified procedures and support for AML-compliant video or autoident flows, NFC reading and a documented document database.
• Extraction-only APIs: Mindee (FR), Klippa (NL), Azure Document Intelligence [1], Google Document AI identity processors.
• Choose A when: a regulated KYC process, mobile SDK integration, document coverage from many countries and a vendor-held conformity evidence matter more than customisation. Building document-template libraries and fraud tooling yourself rarely pays off.

Path B — Build on cloud APIs

• Azure AI Document Intelligence prebuilt-idDocument (JSON output with confidences) [1]; Amazon Textract AnalyzeID (front and back in one request) [2]; Mistral Document AI / OCR (EU provider, structured annotations via /v1/ocr) [4]; general multimodal LLMs with JSON-schema outputs for rare documents.
• Always combine with deterministic MRZ parsing and check-digit validation; use the model only for what the MRZ lacks (address, place of birth, driving-licence categories).
• Choose B when: you build your own onboarding flow, have moderate volume and no on-prem constraint. Check the EU region of the endpoint and the retention/zero-retention settings, because ID images are high-risk personal data.

Path C — Self-host (open source)

• Parsing: Docling (MIT licence, runs locally, supports air-gapped use; Granite-Docling VLM ~258M parameters) [5], PaddleOCR, and an open VLM of the Qwen-VL family for field extraction, served with vLLM. MRZ parsing with open libraries (e.g. PassportEye-style MRZ readers) and ICAO chip reading with open eMRTD libraries.
• Hardware: HW2 is enough for thousands of documents per day; HW1 (CPU) works for MRZ-only flows.
• Choose C when: data must not leave your network (public sector, banks with outsourcing limits). Note that open components give you extraction, not certified identity proofing; liveness and injection-attack detection are hard to self-build credibly (see [3]).

Path D — Custom training

Worth it only for unusual documents (regional permits, old national ID versions, non-Latin scripts) or very high volumes. Needs a few hundred real or licensed samples per template; synthetic specimens are safer than real customer IDs. Training on real ID images is a GDPR and security issue in itself.

State of the art (2026)

• MRZ + chip first: deterministic parsing and signed chip data are more trustworthy than OCR; image extraction is mainly for cards without chips and for the visual zone.
• Template-free VLM extraction handles unseen layouts and scripts better than classic template libraries, but still needs validation: it can hallucinate plausible dates or document numbers. Typical weak points are glare/holograms, curved or laminated cards, partial crops, transliteration of names, and documents of rare countries.
• Identity proofing is moving toward attested data: the EU Digital Identity Wallet (Regulation (EU) 2024/1183) is due to be offered by every member state from the end of 2026 [6]; once wallets are common, extraction from photos becomes a fallback rather than the primary source.
• Injection attacks and deepfakes are the main threat to remote onboarding. BSI TR-03147 defines normal/substantial/high assurance levels for identity proofing and states that detecting injection attacks is central; the BSI notes that current evaluation specifications leave gaps and is drafting evaluation guidance (consultation closed 30 Sept 2026) [3]. Treat vendor claims on this with caution.

Shared resources & combinations

• Same stack (ocr-docparse + vlm): DOC-001 invoices, DOC-003 forms, DOC-008 mailroom classification, DOC-014 document parsing; one self-hosted VLM server serves all of them.
• Downstream and neighbours: ANOM-014 (forgery, liveness), ANOM-017 (synthetic and tampered documents), ANOM-016 (sanctions, PEP, adverse media), AGENT-015 (end-to-end onboarding/KYC agent, workflow engine), VIS-016 (face-based access control, a different and more regulated use).
• Shared building blocks: face-biometrics module (1:1 match) with ANOM-014, workflow engine with AGENT-002, encrypted image store with short retention, review UI.

Effort, cost & KPIs

• Path A: days to weeks; pricing is typically per verification, with volume tiers.
• Path B: 1–3 months including SDK capture, review UI, audit trail and security review.
• Path C: 2–4 months for extraction; certified identity proofing is not achieved by this alone.
• KPIs: field-level accuracy per document type and country, straight-through rate, share of manual reviews, onboarding completion rate, time to verified customer, false rejects, retry rate, fraud caught downstream.

People & change

Involve early: management and the department lead (onboarding, branch, HR), IT security for the integration and image storage, the DPO and legal/compliance before anything starts. ID images and biometric matching are sensitive: a DPIA is likely (Art. 35 GDPR), the legal basis and retention must be fixed, and an AVV with the provider is mandatory; biometric comparison needs particular care under Art. 9 GDPR (GUIDE-005, GUIDE-010).

Works council: depends. For customer onboarding alone, co-determination is often not triggered. It applies when the tool is used for employee onboarding or logs the handling by individual staff (§87(1) no. 6 BetrVG), and §90(1) no. 3 still requires information about AI-supported processes. Public bodies involve the Personalrat (GUIDE-004).

AI Act: remote biometric identification and some identity checks can fall under stricter rules; classify precisely (GUIDE-014).

AI literacy: Art. 4 AI Act requires measures that support staff's AI literacy; train staff on fraud signs, forged documents and manual fallback (GUIDE-006).

Communication and pilot: inform customers clearly about what is read and why; pilot with one channel or branch and track rejection rates, including for different nationalities and document types (GUIDE-008, GUIDE-009).

Typical concerns: privacy (store minimal data), fairness (checks must not fail more for certain groups), and customers without suitable documents (offer a manual route).

Humans in control: a person reviews every rejection or doubtful match.

Risks, regulation & compliance

• EU AI Act: extraction of text from an ID document is minimal risk. Annex III point 1 lists remote biometric identification, biometric categorisation and emotion recognition as high-risk, but excludes biometric verification whose sole purpose is to confirm that a person is who they claim to be (1:1 match) [7]. A pure document-reading flow with a 1:1 face match is therefore normally outside high-risk, whereas 1:N identification against a database is not. Hence depends; classify per deployment.
• Prohibited practices (Art. 5): building face databases by untargeted scraping, inferring sensitive traits from biometrics, and law-enforcement real-time remote biometric identification in public spaces are banned except for narrow, authorised exceptions [8]. Do not extend an onboarding system into any of these (for example, reusing collected ID photos to build a face-search index); that is not implementable lawfully in a business context.
• GDPR: ID images and numbers are personal data; face templates are biometric special-category data (Art. 9) when used for unique identification. Data minimisation (collect only needed fields), strict retention (deletion after the legal period), DPA with vendors, DPIA, and no training on customer IDs without a legal basis. In Germany, copies of ID cards may only be made under the conditions of the Personalausweisgesetz (PAuswG); ID numbers must not be used as identifiers.
• Sector law: AML identification duties (German GwG; EU AML Regulation 2024/1624, applicable from July 2027, with technical standards by AMLA on remote identification), eIDAS assurance levels, BSI TR-03147 [3]; DORA for ICT outsourcing at financial entities.
• Risks and mitigations: deepfake/injection fraud (use certified IDV vendors, chip reading); name transliteration errors (use MRZ as canonical Latin form); bias across skin tones in face match (test per group); data breaches of ID images (encryption, short retention, access logging).

Getting started

1. Define the legal need: which law requires which assurance level, and which documents must be accepted.
2. Collect 100–200 specimen documents (or legal specimen sets) across your real country/type mix and measure vendors on them.
3. Use MRZ and NFC chip reading wherever possible; add VLM extraction only for the remainder.
4. Design retention, DPIA and review workflow before go-live; log AI output vs. human correction.
5. Pilot with a regulated-grade vendor (Path A) before deciding on self-building (Path B/C).

Sources

1. Microsoft Learn — Azure AI Document Intelligence, Identity document (ID) model — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/id-document
2. AWS — Amazon Textract, Analyzing Identity Documents (AnalyzeID) — https://docs.aws.amazon.com/textract/latest/dg/how-it-works-identity.html
3. BSI — Technical Guideline TR-03147, assurance levels of identity verification procedures — https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03147/tr03147_node.html
4. Mistral AI — Document AI / OCR documentation — https://docs.mistral.ai/capabilities/document_ai/
5. Docling project (MIT licence, Granite-Docling) — https://github.com/docling-project/docling
6. European Commission — EU Digital Identity Wallet home — https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/694487738/EU+Digital+Identity+Wallet+Home
7. AI Act Annex III (high-risk systems), point 1 biometrics — https://artificialintelligenceact.eu/annex/3/
8. AI Act Article 5 (prohibited practices) — https://artificialintelligenceact.eu/article/5/
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
10. Regulation (EU) 2024/1624 (AML Regulation) — https://eur-lex.europa.eu/eli/reg/2024/1624/oj