Extraction and Validation Documentation
This page outlines the documents supported by ID360, as well as the data extracted and the checks performed for each document type.
🪪 Identity Documents
When creating a custom online process with ID360, you can select up to four types of identity documents:
- National Identity Card
- Passport
- Residence Permit
- Driver's License *(credit card format)*
Each document undergoes structured data extraction and authenticity checks.
📂 Path in the proof file: `extracted_data.identity`
| 🧾 Accepted Documents | 📋 Extracted Data | 🔍 Authenticity Checks |
|---|---|---|
| National ID / Passport | - Document type, - Birth name, - Used name, - List of first names, - Date and place of birth, - Gender, - Identity number, - Expiry date, - Place of issue, - MRZ band. - If 2D-DOC is detected, we extract: document type, ID type, first names, last name, document number, nationality, gender, country of birth, issuing country. | - Department field consistency, - Validity duration, - Future issue date not allowed, - MRZ auto-correction based on expected characters, - MRZ checksum, - Photo conformity (wavy lines, RF, collage), - Detection of title presented via screen (presentation attack detection) |
| Residence Permits | - Same as ID card, - Country of birth | - Expiry date validity, - Future issue date not allowed, - MRZ auto-correction, - MRZ checksum, - Detection of title presented via screen (presentation attack detection) |
| Driver’s License (credit card format) | - Same as ID card, - License type | — |
✅ On-Demand Authenticity Checks
- Detection of monochrome documents
- Presence of both sides (except for passports)
- VIZ ↔ MRZ consistency
- 2DDoc ↔ MRZ consistency
- Automatic blocking of specimen documents
- Detection of documents issued on a Sunday
📎 Supporting Documents
In addition to identity documents, ID360 supports a range of supporting documents to enrich identity analysis, validate address, income, or professional activity. Each document is subject to specific extraction rules and controls tailored to its type.
📂 Path in the proof file: depending on the type, in `extracted_data.[document_type]`
| 📄 Document Type | 📋 Extracted Data | 🔍 Authenticity Checks |
|---|---|---|
| Tax Notice (FR) | From the 2DDoc, we extract: - Document type - Number of shares - Reference number - Declarant 1: last name, first name, tax ID - Declarant 2 (if applicable): last name, first name, tax ID - Reference year - Reference taxable income | - Expiration date check against expectations. Example: document issued less than 2 years ago. - Verified 2DDoc signature - Option: Possibility to retrieve the information directly from the source to guarantee authenticity with our partner Mi-Trust |
| Payslip *(starting from September 2025)* | - Last name, first name - SIRET number - Hire date - Period concerned - Full address - APE code - Gross, net, taxable income - NIR | - Expiration date check against expectations. Example: document issued less than 3 months ago. - RCS check: status, APE consistency, company creation date, validity of SIREN |
| Bank Details (RIB - FR) | - IBAN - Last name - First name | - IBAN checksum validation - Country code validation (ISO_3166-1_alpha-2) - Option: RIB authenticity via SEPAmail Diamonds |
| Property Tax Notice (FR) | - Full name - Tax year - Date and place of birth - Tax address - Issue date | - Option: Possibility to retrieve the information directly from the source to guarantee authenticity with our partner Mi-Trust |
| Kbis (French Business Registration) | Company identification: - First and last name - RCS registration number - Registration date - Company name - Legal form - Share capital - Registered office address - Fiscal year duration and closing For all members: - First and last name - Date and place of birth - Nationality - Personal address | - Expiration date check against expectations. Example: document issued less than X months ago. - Document not created in the future - Verification against RCS data: Deactivation status Address consistency Registration date Read company name Validity of SIREN SIREN present in RCS |
| Proof of Address | - Full name - Address - Postal code - City - Document date *If 2DDoc detected, extracted fields:* name, first name, address, postal code, city, country, issue date, issuing country | - Validity (issue date < 3 months) - Issue date not in the future - Option: Possibility to retrieve the information directly from the source to guarantee authenticity with our partner Mi-Trust |
| Vehicle Registration Certificate *(carte grise)* | - Document format (CG FR V1) - Issuing country - Document type - Document number - Vehicle ID number - Registration date - Vehicle category - Vehicle body type - Brand - Model | Coherence between MRZ and VIZ data: - Validity - Vehicle registration (A) - Correct format for vehicle registration - Presence of address - Registration date (I) not in the future - Presence of first registration date (B) - First registration date not in the future - Brand (D1) - Model (D3) - Vehicle ID number (E) - Vehicle national category (J1) |
| Health Insurance Card (Carte Vitale) | - Full name - Social security number - Issue date | - Issue date must be valid - Valid format of the social security number |
| Mutual Insurance Card | - First and last name of the insured (main AMC member) - AMC number - Membership number - Contract - CSR (Secondary Routing Criteria) - Validity start and end date | - Check date must be between issuance and expiration date - Valid format of membership number |
🧩 Cross-Document Validation
Beyond individual verifications, ID360 implements cross-check mechanisms between documents to strengthen the consistency of the analyzed identity. These controls are applied depending on your process configuration, when it includes multiple documents, or when some data is pushed via business APIs.
The identity of a user will be built using information from either an identity document or from data provided by eID sources (e.g. La Poste Digital Identity, France Connect, etc.).
The address displayed in the Identity section will be confirmed using a proof of address if this document has been submitted. Alternatively, it may come from manually entered data, and as a last resort, from the identity document if this has been enabled in the process configuration.
🔗 Matching Links Between Documents
| Compared Sources | Fields Checked |
|---|---|
| Identity ↔ Proof of Address / Bank Statement (RIB) / Property Tax / Company Registration Document (Kbis) / Health Insurance Card / Social Security Card / Tax Notice | - Last name - First name |
| Identity ↔ Company Registration Document (Kbis) | - Last name - First name - Date of birth - Address |
| Identity ↔ Vehicle Registration Document / Payslip | - Last name - First name - Address |
⚙️ Comparison of User-Provided Data
It is possible to check the consistency between the data pushed by the business service (via API) and the data extracted from the collected documents.
The data that can be compared include, for example:
- Last name
- First name
- Address
These checks help identify discrepancies between the declared information and the supporting documents provided.
🧍♂️ Holder Verification
The holder verification step ensures that the person presenting the documents is physically present and matches the identity document holder. It relies on two main types of checks: liveness detection and biometric comparison (facial match with the document photo).
🧬 Liveness Detection
Two types of liveness checks are offered by ID360:
| Type of Liveness Detection | Description |
|---|---|
| Active | The user must perform two random gestures (e.g. turn head, open mouth) prompted on screen. These gestures are guided by the ID360 UI and verified server-side. |
| Passive | A simple facial photo is captured and analyzed by algorithms to detect: - Presentation attacks (e.g. photo or video of a face on screen) - Injection attacks (digital image injected into the video stream) - Presence of filters, masks, or objects obstructing the face |
🧠 Facial Comparison (Holder Legitimacy)
One of the images captured during liveness detection is compared to the photo on the submitted ID document. This biometric comparison is used to validate or reject the link between the user and the document.
- If the resemblance is too weak, the check is marked as KO.
- The matching algorithm has been evaluated on various facial datasets to ensure robustness.
All checks are performed server-side as part of a fully automated journey.