Verification of identity and documents

1) Goals and place in the compliance loop

Identity verification confirms that the user is real, adult and acceptable by geo/jurisdiction, and the document is genuine and relevant. In iGaming, it is a mainstay for KYC/AML/sanctions, payments, and Responsible Gaming (age/limits).

• Confirm identity, age and residency.
• Detect forgeries/revision of documents and face spoofing.
• Agree the owner of the payment instrument with the profile.
• Reduce friction in onboarding without compromising quality.

2) Document types and channels

Documents: passport, ID card, driver's license, residence permit (where applicable), passport.
Input channels: mobile SDK (preferred), webcam, photo upload (fallback), NFC (if there is a chip), "thin" state checks (open-banking/credit files/KYC telco - by region).

• First of all, a mobile SDK (camera quality, gyroscope/focus).
• Step-by-step tips (angle, light, frames) and auto-capture the frame to reduce scrap.
• Validation of validity period and acceptable countries/formats for a specific market.

3) Technical process: what the check consists of

1. Dockscan (OCR): extraction of fields (name/DR/number/citizenship/address), structure control, comparison with additional sources.
2. MRZ (if any): checksum checking, matching with OCR.
3. NFC (ePassport/eID): reading the chip (DG1/DG2), comparing portraits and deadlines.
4. Selfie-liveness: passive/active, anti-spoof (replay/mask/paper/screen).
5. Face-match: comparison of selfies with a portrait on a document (or from NFC), match thresholds.
6. Quality: sharpness/glare/cropping/artifacts, manipulation detector.
7. Sanctions/PEP/Adverse Media (parallel).
8. Address: "soft" (bases/telco/bank-match) or "hard" (utility bill ≤3 months) by level.
9. Solution: auto-app, auto-fail by criteria, or manual clearing (L2/MLRO).

4) Liveness and face-match: thresholds and anti-spoof

• Passive is faster and better for UX; active is useful as a fallback in controversial cases.
• Antispuff: detection of masks/screen/printing, analysis of glare and micro-eye movements, frequency signs.

• ≥ 0. 90 - High confidence: auto-app with clean other signals.

0. 82–0. 89 - Review: manual review; request a second selfie/dock photo.

🚨 0. 82 - Auto-fail: in the presence of other negative features (qualitative defects, field inconsistencies).

5) Document quality control

• Geometry and margins: edges/borders, proportions, MRZ/barcode area.
• Light and sharpness: no clipping/overexposure; auto-prompts to the user.
• Manipulations: traces of editing, reassembly of layers, mismatch of fonts/guilloches.
• Validity and document type: valid? Does it belong to valid types?
• Mappings: OCR ↔ MRZ ↔ NFC; NFC photo ↔ selfie.

6) Geo, alphabets and transliteration

Cyrillic/Latin/diacritic support; tokenization of full name (first name/last name/patronymic).
Normalization of "de/van/bin/ibn," dual surnames, Arabic and Indian formats.
Comparison of alternative transliterations to a single canonical representation (for sanctions/PEP and payments).

7) Reason codes and actions

• DQ-01: poor image quality/blur/glare.
• DQ-02: disparate OCR↔MRZ/NFC.
• DQ-03 document has expired.
• DQ-04: liveness fail/suspected spoof.
• DQ-05: low face-match.
• DQ-06: non-compliance of DR/name with profile/payment data.
• DQ-07: unsupported document/jurisdiction.

• Guided retake with prompts.
• Switching to an alternative channel (NFC/webcam).
• Escalation to manual clearing with "four eyes."
• Request for additional documents (address/SOF) or video call.

8) Manual clearing (operational playbook)

Reconciliation of fields and photos, comparison of faces by control points.
Manipulation checklist (color/texture/microprinting), reconciliation with document standards.
Check sources (registers, if available), cross-check with payment data.
The 4-eyes principle: a second opinion is mandatory for controversial cases.
Full motivation of the solution in the case + artifacts (screenshots, file versions).

9) Architecture and integration

Mobile/Web SDK verification + opchestrator (solutions and follbacks).
Matching engine: name normalization, face-match thresholds, rules.
Feature store: quality/risk attributes (agreed online/offline).

Case system: queues, SLAs, letter templates, "reason codes."

Sanctions/POP: synchronous or asynchronous screening; rescreening by payments.
Security: transit/rest encryption, secret storage, image tokenization, DLP.

Reliability: quorum of providers, retrays/timeouts, degradation in "L0/L1 only."

10) UX and availability

Step-by-step wizard with "progress bar," frame preview and auto-capture.
Photo hints (example "what should look like") and "live hints" (tilt/zoom in).
Low light support (night mode), offline draft, one-handed adaptation.
Accessibility: contrast, voice prompts, large buttons, language/locale.

Ability to "save and continue later."

11) Metrics and SLO

TTV (Time-to-Verify): median/95th percentile.
FPY (First Pass Yield) on documents and selfies.
Auto-pass / Manual-review rate, Auto-fail rate.
Liveness pass-rate, Face-match distribution by locale/device.
Repeat-attempt rate and the proportion of "guided retake" successful.
Vendor SLA: uptime, mean latency, incident rate.

12) Privacy, storage and security

Minimization: Store only the right fields and biometrics hashes (where possible).
Dates: usually ≥5 years after the end of the relationship (specify locally).
Encryption: at-rest/in-transit; RBAC/ABAC access Audit uploads.
WORM storage for cases and solutions (regulatory audit).
DPIA/DTIA when adding new providers/transferring data abroad.

13) Solution matrix example

14) Checklists

• Valid document of supported type/country.
• Selfie-liveness (pass) and face-match ≥ threshold.
• OCR↔MRZ/NFC match; DR ≥ minimum age.
• Sanctions/PEP primary screening.
• Address (soft), geo/IP without conflicts.

• Repeated face-match (selfie check) by risk.
• Sanctions Rescreen/REP.
• Payment instrument owner match.
• SOF when the threshold is exceeded.

• Update document when name/address expires/changes.
• Geo/device reconciliation; repeated liveness in anomalies.
• Audit of failure history/retail.

15) Frequent risks and how to cover them

Synthetic personalities → multisignal: NFC + liveness + device graph.
Deepfake/mask → passive liveness with anti-spoof + active as fallback.
Poor camera quality → Hyde-retake, auto-exposure, "red zones" in UI.
Name/transliteration discrepancies → normalization/aliases, manual clearing.
VPN/proxy and geo conflict → time limits, repeat selfie check, BIN/address verification.
Mass retakes → monitoring by device/affiliate, limiting attempts.

16) Vendor management and test plan

Compare providers by pass-rate, latency, FP/TP by liveness/face.
Benchmarks on a "dirty" sample (shadows, glasses, different skin tones, masks/screens).
Canary launch, dual circuit (primary/secondary) and automatic feiler.
Regular red team checks (spoof sets, paper/screen attacks).

17) Implementation (roadmap)

1. Identify supported documents/countries and face/liveness thresholds.
2. Embed mobile SDK + NFC, prepare UI prompts and guided retake.
3. Launch the solution orchestrator, case system and reason codes.
4. Set up sanctions/POP and rescreening for payments.
5. Conduct a pilot, calibrate the thresholds by locales and devices.
6. Introduce regular audit sessions, metric control and team training.

Result

Reliable identity verification is the orchestration of several signals: high-quality docking (OCR/MRZ/NFC), liveness and face-match with correctly selected thresholds, plus the discipline of manual clearing and decision logging. Add strong UX, privacy, and metrics - and get a scalable process that simultaneously improves security, complies with regulatory requirements, and preserves conversion.