KYC documentation
KYC: architecture and components
Scenario steps, the checks behind them and the final result.
The KYC module verifies the identity of a user from photos of a document and a face. This page describes the steps a scenario is built from, the checks the module performs and how the final session result is formed.
Scenario steps
A verification scenario is built from steps in the dashboard. Steps can be combined:
- Document. The user takes a photo of a passport, an ID card or another identity document.
- Selfie. A photo of the face of the user.
- Selfie with document. The user holds the document, and the system compares the face with the photo in the document.
- Liveness. Confirms that a live person is in front of the camera.
- Questionnaire. A form for the first stage of a two-stage flow.
Typical combinations are a document with a selfie, and a document with a selfie with the document and liveness.
What is checked
Document
- Image quality: format, size, lighting, and the whole document in the frame.
- Document type: the system detects the kind of document and the issuing country.
- Text recognition: the system extracts the fields, such as name, dates, number and place of birth, and validates the checksums of the machine readable zone.
- Signs of forgery: a photo of a screen, a photocopy or printout, editing in a graphics editor, pasted-in or corrected fields, damage to the document, and logical inconsistencies in dates and numbers.
Face
- Face match: the face on the selfie is compared with the photo in the document and with faces from other steps of the session.
- Age and gender consistency with the document data.
- Signs of a forged selfie: a photo of a screen, a photocopy, a deepfake, an image generated by a neural network.
Liveness
The step is active: the person moves the face closer through two ovals. Photos, screen recordings and paper printouts are rejected.
External database checks
The document data can additionally be checked against external databases, such as AML screening. The set of checks is configured in the scenario. The verdicts of external database checks are not part of the body of a session. Get them with database check results or from the DATABASE_CHECKS_COMPLETE webhook. See AML screening.
The session result
After all steps the session gets a status:
| Status | Meaning |
|---|---|
success | The check passed. |
failed | The check did not pass. |
suspicious | The session is marked as suspicious. |
exception | Processing ended with an error. |
expired | The user did not complete the check within the lifetime of the session. |
While the check runs, the session is idle (created, processing not started) or processing. If the check fails, the answer lists the error codes with the reason, for example [document] text fields not visible or [fraud] mobile device. The codes are explained on the errors page.
The session status call returns the status and the details of each step. The platform can also notify you of the completion of a session with a webhook. See the session object and session statuses.