Identity document forgery & liveness detection

Banks, insurers, telcos, mobility and e-commerce firms increasingly onboard customers without meeting them. Fraudsters answer with forged or stolen IDs, printed or replayed selfies, masks and, increasingly, deepfakes fed directly into the camera stream. Modern identity verification (IDV) stacks check the document (visual security features, MRZ, NFC chip), the person (liveness, face match) and the channel (device and injection integrity), and send only ambiguous cases to a human.

Problem & value

• Today: remote onboarding relies on photographing an ID and a selfie, or on video-ident calls with an agent. Staff and simple OCR cannot reliably spot good forgeries, and agents are poor at spotting real-time face swaps. Strict checks cost conversion; weak checks enable mule accounts, synthetic identities and account takeover.
• AI value: automated document forensics, passive/active liveness and face matching decide most cases in seconds; agents are reserved for exceptions. Reading the NFC chip of an eID/e-passport (cryptographically signed) is much stronger than judging the printed card.
• Threat shift: the German BSI states that deepfakes can defeat remote biometric checks such as video identification, that some face-swap models run in real time, and that automated detectors often generalise poorly to new attack methods [6]. Defence therefore has to be layered rather than rely on one detector.
• Regulatory pull: EU Member States must offer EUDI wallets by the end of 2026, and providers obliged to identify customers will have to accept the wallet [7]. Wallet presentations will gradually replace document photos, but ID-document checks stay necessary for years (foreign documents, wallet recovery, non-regulated use cases).
• No generally valid fraud-reduction figure is quoted here; measure your own baseline with test attacks.

Variants

• KYC/AML onboarding (banking, payments, crypto, insurance): full document + chip + liveness + match, tied to AML identification duties (e.g. GwG in Germany); see ANOM-002, ANOM-016.
• Account recovery / step-up: selfie matched against the photo already verified at onboarding or in a credential (e.g. Microsoft Entra Verified ID Face Check [4]); see SEC-005.
• Age and eligibility checks: document-based age verification for gaming, alcohol, adult content.
• Workforce and gig platforms: onboarding drivers, couriers, freelancers, remote hires; fake-candidate defence.
• Telecom SIM registration, car sharing, rental, hotels: document + selfie at self-service points.
• Public sector: online services, eID-card (nPA) and wallet flows; border and law-enforcement uses are outside this file (see Risks).
• Private use: none directly; consumers meet it as the verifying subject. Privacy-friendly option: on-device check and selective disclosure via a wallet.

How it works

1. capture (SDK in app/web: document + selfie/video, guided)
2. channel integrity (app attestation, root/jailbreak, emulator, virtual camera, hooking detection)
3. document analysis (type classification
4. OCR/MRZ
5. security features
6. tamper/copy/print-screen detection)
7. chip read (NFC: passive/active/chip authentication, certificate chain) when available
8. liveness (passive or active; presentation-attack + injection-attack detection)
9. face match (selfie vs. chip/document photo; threshold per risk level)
10. consistency + risk (data vs. MRZ/chip, age, expiry, device/IP reputation, duplicate-identity check)
11. decision (accept / step-up / manual review / reject) + evidence archive

• Document checks: document-type classifier, OCR and MRZ checksum validation, detectors for holograms, fonts, microprint, photo substitution, screen replay and photocopy; forensic checks under UV/IR on dedicated readers (Regula lists a database of over 16,500 document types from 254 countries and territories and ICAO 9303 MRZ and chip authentication [3]).
• Liveness: presentation-attack detection (PAD) finds printed photos, replays, masks; injection-attack detection (IAD) finds synthetic video fed past the camera (virtual cameras, hooked SDKs, emulators). Defence needs both capture-side controls and server-side analysis. Challenge-response methods (AWS uses face movement plus a colour-light sequence for best accuracy) add resistance to replay [2].
• Face matching: embedding-based 1:1 comparison with tuned thresholds; vendors express confidence as a score (Microsoft documents a configurable 50–100 threshold) [4].
• Human-in-the-loop: borderline scores, document types without templates, and all rejections that can lock a person out of a service go to trained reviewers; users need an alternative route (branch, post-ident, eID).

Data preparation

The data are mostly generated at the point of capture: photos or videos of ID documents and selfies from customers, usually through a mobile app or web onboarding. Reference data (document templates, security features, issuing-country specimens) comes from the vendor. In an SMB the surrounding records live in the CRM, the onboarding mailbox, paper copies and file shares. Typical gaps are poor image quality (glare, blur), photos of screens, missing consent records, scattered copies of IDs without deletion deadlines and no labelled history of confirmed fraud cases.

Preparation steps: (1) define the capture flow and quality guidance for users; (2) clean up existing ID copies, set retention and deletion rules and restrict access rights (PREP-023, PREP-025); (3) classify the data as high-risk biometric data (PREP-024); (4) collect confirmed fraud cases and false rejections as a test set with the compliance team (PREP-018, PREP-020); (5) pseudonymise data used for tuning (PREP-022). Little training-data preparation is needed with Path A; the effort is dominated by process, consent and retention clean-up, roughly 20-30 percent of the total.

Implementation paths

Which path for whom

• SMB: Path A - mature, certified EU-hosted ID verification services (eIDAS/AML-ready) exist at per-check prices; building forgery and liveness detection yourself is not realistic.
• Enterprise: Path A - ID verification is a commodity function with certified vendors; B only for special document types or deep integration.
• Developer: Path B - assemble OCR, document-check and liveness APIs into your own onboarding flow for your customers.
• Public: Path A - authorities should prefer certified products (e.g. eID-based or BSI-evaluated) over home-grown biometric checks.

Path A — Buy (recommended for most organisations)

• IDV platforms (EU/German marked): IDnow (DE, Munich: document, biometric, eID, EUDI wallet and qualified signature services) [5], Nect (DE), WebID Solutions (DE), Authada (DE), Signicat (NO), Veriff (EE), Onfido (now part of Entrust), Sumsub, Jumio, Incode, Yoti (UK), iProov (UK, liveness). Check: EU data residency, ISO/IEC 30107-3 PAD test letters, injection-attack testing, certification for your sector (e.g. recognised for GwG/BaFin identification, ETSI TS 119 461 for trust services), conversion rates.
• Test evidence: iBeta publishes ISO 30107-3 PAD confirmation letters; Level 2 allows at most 1 % attack penetration and requires a bona-fide error rate of at most 15 %, Level 1 allows 0 % penetration [9]. These letters cover presentation attacks, not injection attacks, so ask separately about the latter.
• Document readers: Regula (document SDK/readers, forensic devices) for staffed counters and kiosks [3].
• Choose A when: regulated onboarding, no in-house biometric team. Almost always the right default.

Path B — Build on cloud APIs

• Cloud liveness + match components: Amazon Rekognition Face Liveness with CompareFaces (returns a 0–100 score, reference image and audit images; AWS stresses that it must be combined with other factors and with device-side controls) [2]; Azure AI Vision Face with liveness (iBeta Level 2 conformant according to Microsoft [4]). Use EU regions; both vendors state that results are probabilistic.
• Document parsing: Azure Document Intelligence ID document model, Google Document AI identity processors, Textract AnalyzeID, Mistral OCR (EU); a VLM can add reasoning over inconsistencies but must not be the sole forgery detector.
• Orchestration: your own decision service (rules + gradient-boosted risk model), workflow engine for manual review.
• Choose B when: you have a developer team, need UX control, and accept a managed biometric API. Mind that you then own the injection-attack and decision-logic risk.

Path C — Self-host (open source)

• Realistic for components, hard for end-to-end assurance. Building blocks: InsightFace (code MIT; pretrained models restricted to non-commercial research use, commercial licence needed) [8], Silent-Face-Anti-Spoofing (Apache-2.0, RGB passive liveness; the authors note camera dependence and that their stronger model is not released) [10], Tesseract/PaddleOCR/Docling for text, open ICAO 9303 MRZ and eMRTD libraries (e.g. JMRTD) for chip reading.
• Hardware: HW1–HW2; face and liveness models are small, and a single 24 GB GPU or CPU/edge devices handle thousands of checks per hour. Sovereign on-prem is possible (public sector, high-security) but you must run your own PAD/IAD evaluation; open models rarely come with ISO 30107-3 certificates.
• Choose C when: strict data-sovereignty requirements, kiosk/offline use, or as a pre-filter in front of a bought service.

Path D — Custom training

Worth it for vendors, large banks or governments with unusual documents (national IDs not covered by vendors) or special attack profiles. Needs thousands of genuine and attack samples with consent, synthetic-attack generation and a red-team programme; data collection of biometrics is the main legal and ethical effort (GDPR Art. 9). Expect periodic retraining as attack tools change.

State of the art (2026)

• Layered assurance is standard: NFC chip authentication (strongest document evidence), certified PAD, injection defence, risk signals. ISO/IEC 30107-3 (PAD testing) and iBeta confirmation levels are the common baseline [9]; recent iBeta lists include both established and new vendors at Level 1–3 [9].
• Injection attacks are the main gap. Virtual cameras, emulators and real-time face swapping bypass camera-facing PAD. Mitigations: trusted-device attestation (Microsoft's Face Check rejects Android devices without the MEETS_STRONG_INTEGRITY Play Integrity verdict and runs only in Authenticator to prevent injection) [4], hardened SDKs, server-side artefact analysis.
• Passive liveness (no user action) reduces friction, but RGB-only models are sensitive to camera and scenario [10].
• Wallet shift: EUDI wallets by end of 2026 [7] move trust from image analysis towards signed attestations, with face check against a credential photo.
• Limits: fairness (error rates differ by skin tone, age, disability, camera quality), documents not in vendor databases, low-end phones, and an arms race against generative models. Detectors trained on today's fakes often fail on new generators [6].

Shared resources & combinations

• Shared building blocks: face-biometrics, ocr-docparse, image-classification and VLM pipelines are also used by ANOM-017 (tampered bank statements, payslips), DOC-003 (forms and ID capture) and SEC-011 (deepfake detection in calls). One GPU server (HW2) can host document parsing, face embedding and liveness models together.
• Downstream and neighbours: ANOM-004 (fake accounts and bots; share device and risk signals), ANOM-001 (payment fraud), ANOM-002 and ANOM-016 (AML monitoring, sanctions/PEP screening on the verified identity), ANOM-022 (money-mule detection), AGENT-015 (customer onboarding/KYC agent that orchestrates this check), ANOM-015 (provenance and AI-generated media).
• Boundary: ANOM-017 covers tampering of financial documents; this file covers identity documents and the person at the camera.
• Data pipeline: one evidence store (images, scores, decision, consent) with short retention serves audit, appeals and model monitoring.

Effort, cost & KPIs

• Path A: days to a few weeks (SDK integration, UX tuning); priced per verification.
• Path B: 2–4 months incl. UX, decision logic, security testing of the capture channel; cloud API cost per session.
• Path C: 4–9 months for a pre-filter or sovereign kiosk; ongoing red-teaming effort.
• Path D: 9–18 months, specialised team; only for niche needs.
• KPIs: attack acceptance rate (from red-team tests), bona-fide rejection rate (BPCER), completion/conversion rate, manual-review share, average handling time, fraud losses attributed to onboarding, fairness metrics per demographic group, appeal outcomes.

People & change

Involve management and the compliance or money-laundering officer first, because they own the legal duty to identify customers. IT security and the DPO are needed early: biometric processing is sensitive, so check the legal basis, the data processing agreement with the vendor and whether a DPIA is required (Art. 35 GDPR; GUIDE-005). Legal reviews the vendor contract and liability (GUIDE-010). Onboarding staff who handle escalations are the end users and need training on reviewing flagged cases.

Works council: no in the typical case, as customers rather than employees are checked. Co-determination can arise if employee ID checks are included or staff handling results are monitored individually; then section 87(1) no. 6 BetrVG applies. Inform the council in good time of the workflow change under section 90 (1) no. 3 (GUIDE-004).

AI literacy: support the review staff with training on typical deepfake and forgery patterns, error rates and bias across skin tones and ages (AI Act Art. 4, GUIDE-006). Typical customer concerns are privacy and discrimination; offer an alternative manual verification route and clear information. Keep humans in control: borderline and rejected cases always go to a trained person, never an automatic final refusal. Pilot with one onboarding channel first (GUIDE-009).

Risks, regulation & compliance

• EU AI Act: biometric verification whose sole purpose is to confirm that a person is who they claim to be is excluded from the Annex III high-risk category for remote biometric identification [1]. A typical 1:1 selfie-to-ID flow is therefore not Annex III high-risk, but classification depends on context: 1:N searches (e.g. watchlists across customers), biometric categorisation by sensitive attributes or emotion recognition fall into Annex III or Art. 5 and must be avoided. Real-time remote biometric identification in public spaces for law enforcement is prohibited in principle (Art. 5(1)(h)) and not part of this use case. Verify with counsel; other Annex III uses (e.g. access to essential services/credit) may apply to the downstream decision.
• GDPR: face templates used for unique identification are special-category data (Art. 9). Needs a legal basis (explicit consent or statutory identification duty such as GwG), DPIA, data minimisation, short retention, and a non-biometric fallback so that consent is freely given. Art. 22 safeguards apply to solely automated rejections: offer human review.
• Sector law: AML identification rules (GwG, BaFin guidance, EU AMLR from 2027), eIDAS and ETSI TS 119 461 for trust services, DORA for ICT third-party risk with IDV vendors, PSD2 for strong customer authentication.
• Risks and mitigations: injection attacks (attested devices, hardened SDK, server-side analysis), bias (per-group testing, thresholds), vendor lock-in and biometric data breaches (EU hosting, encryption, deletion), lock-out of legitimate users (alternative channels), over-collection (store scores, not raw video, where allowed).

Getting started

1. Define the assurance level and legal basis (AML, eIDAS, age) per journey; decide whether NFC chip reading is possible.
2. Shortlist 2–3 IDV vendors; request ISO 30107-3 evidence, injection-attack test results and EU data-residency terms.
3. Pilot with your real customer mix (document types, devices) and measure conversion and review rate.
4. Run an internal red-team test with printed, replayed and injected attacks, and measure fairness by group.
5. Prepare the DPIA, retention rules, fallback channel and a path to accept EUDI wallets.

Sources

1. EU AI Act Service Desk — Annex III (biometrics, verification exclusion) — https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
2. AWS — Amazon Rekognition Face Liveness — https://docs.aws.amazon.com/rekognition/latest/dg/face-liveness.html
3. Regula — Document Reader SDK — https://www.regulaforensics.com/products/document-reader-sdk/
4. Microsoft — Face Check with Microsoft Entra Verified ID — https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck
5. IDnow — product overview — https://www.idnow.io/
6. BSI — Deepfakes: threats and countermeasures — https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/Deepfakes/deepfakes_node.html
7. European Commission — European Digital Identity Regulation — https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation
8. InsightFace — https://github.com/deepinsight/insightface
9. iBeta — ISO 30107-3 PAD confirmation letters — https://www.ibeta.com/iso-30107-3-presentation-attack-detection-confirmation-letters/
10. Minivision — Silent-Face-Anti-Spoofing — https://github.com/minivision-ai/Silent-Face-Anti-Spoofing