Checks and verifications

During document verification, users will be guided through the following steps:

1. Information display: An introductory screen guides the user about the document scan process.

2. Country and document selection:

• Users select their country and the document type (e.g., passport, ID card, driver's license).
• If all document types are allowed, this step is skipped.
• Setting which document types are allowed

3. Document capture:

• The camera is activated, prompting the user to present the document.
• For documents for which both sides need verification (eg: ID card, driver’s license) the SDK captures images of both the front and back sides.
• For documents for which only a single side verification is needed (eg: passport), only the front side is scanned.
• Instructions such as "move the document closer" guide the user for optimal capture.

4. File upload and processing:

• Images are automatically uploaded to SEON's server.
• The server:
  • Verifies file integrity (e.g., checks for malicious files).
  • Processes document information.
  • Extracts the image of the face from the document which is used later during selfie verification

5. Error handling:

• If the wrong document type is scanned, the user repeats the step. If async capturing is turned on, the flow will continue and the final evaluation will indicate the invalid document type on the admin panel. The document check’s status will be failed.
• Exceeding the maximum retry limit or uploading malicious files results in session invalidation.
• Invalidated sessions are marked as "declined" and closed.

Identity document (ID) verification

Ensures high-quality ID verification through real-time, fully automated checks. It begins by analysing the image quality (blur, glare, lighting and resolution). Key features include:

• Information consistency: Ensures repeated information on the document matches.
• Data logic: Verifies logical coherence, e.g., expiration date follows issue date.
• Field format: Confirms fields conform to expected formats based on document type.
• Barcode authenticity: Validates the accuracy and authenticity of the barcode.
• Suspicious personal data: Detects placeholder or sample text in data fields.
• Data integrity: Checks for the presence of all required fields.
• Screen detection: Identifies photos taken from screens.

Date of birth (DOB) verification

This section defines how the system verifies a provided date of birth during a verification session. The date of birth is strictly validated against the reference input, ensuring accuracy in identity verification.

When the DOB field is defined, validation is always enforced. This validation is strict and should only be implemented when it is necessary to compare the input DOB against the DOB recorded on the card. While enabling this check ensures accurate data verification and prevents discrepancies, it may also lead to an increased false rejection rate.

Verification Process

When a date of birth is provided at the start of a verification session, it must be in the following structured format:

{ 
  year: number, 
  month: number, 
  day: number
}

If any of the required fields are missing or formatted incorrectly, the verification session will be rejected with a request validation error.

Verification Outcomes

The system evaluates the date of birth match, resulting in one of the following outcomes:

• PASS: The reference date of birth and the document date of birth match exactly.
• FAIL: The reference date of birth and the document date of birth do not match.
• REVIEW: The reference date of birth is provided in an invalid format (eg. the provided date is 2025.42.42.)
• NOT_PERFORMED: The document does not have a date of birth value on in or the extraction of the date of birth on the document was not successful, no reference date of birth was provided

Warning: If this check fails, the document check will also fail.

Usage recommendations

• Ensure that the reference date of birth follows the required structure to avoid session rejection.
• Use strict date of birth validation to maintain high accuracy in identity verifications.

Postal code validation

Postal code validation ensures accuracy in address verification by securely matching the reference postal code against the document’s extracted postal code.

Verification process

1. A reference postal code is provided at the start of the verification session.
2. If the document contains an address, a secure fuzzy search API retrieves the postal code from the extracted address. If the postal code could not be returned, the longest number substring (min 3 characters) will be considered as the postal code for fallback options
3. The retrieved postal code is matched against the reference postal code.

Verification Outcomes

• NOT_PERFORMED: The document does not contain an address, or a reference postal code was not provided; postal code verification is skipped.
• REVIEW: No postal code could be retrieved from the extracted address.
• PASS: The retrieved postal code matches the reference postal code based on the following rules:
  • If the extracted postal code contains a hyphen or dash, a strict match is performed.
  • If the extracted postal code does not contain a hyphen or dash, but the reference postal code does, only the part before the hyphen or dash is used from the reference postal code from comparison.
• FAIL: The extracted postal code does not match the reference postal code.

Warning: If this check fails the Document check will also fail

State/region validation

State/region validation ensures that documents issued from specific countries include acceptable regional data, based on the configured list in the verification template.

Verification Process

• A list of accepted states/regions is stored in the session’s template version.
• During document verification, if the document’s issuing country is supported and a region value is present, the region is compared to the accepted list.

Supported Countries with Regional Validation

• United States (US)
• Canada (CA)
• Australia (AU)
• Mexico (MX)
• India (IN)
• Pakistan (PK)
• Brazil (BR)

Verification Outcomes

• NOT_PERFORMED:
  • The issuing country is not in the supported list.
  • The accepted state list is null or an empty array ([]), indicating all states are accepted, the check is not run.
• REVIEW:
  • The document’s issuing country is missing.
  • The region value is missing or cannot be mapped
• PASS:
  • The extracted and mapped region matches one of the regions in the accepted list.
• FAIL:
  • The region is extracted and mapped, but not found in the accepted list.

Warning: If this check fails the Document check will also fail.

The Selfie Check is a two-part verification step designed to confirm that the user is a real person and matches the identity on their document.

Both steps can be enabled or disabled as needed. (in DEVELOPMENT)

Components

Liveness check: Verifies that the person in front of the camera is alive and not a photo, video, or object. This step is always performed.

Face match: Compares the face from the selfie video with the face extracted from the ID document or a reference image (standalone selfie with face match).

Configuration

Thresholds for both liveness and face match checks can be adjusted to change their strictness.

See the configuration page for more details.

User experience

The SDK guides the user to position their face within the frame. Once aligned, a 3-second video is recorded.

Results

The selfie check and its subchecks follow the standard outcome structure.

Accessing the video

The recorded selfie video is available in the SEON Admin Panel. It is not included in the webhook response and cannot be accessed via API or any external link at this time.

Standalone selfie with face match

This feature enhances the standalone selfie check by introducing support for face matching using a customer-provided or previously stored reference face image. It is designed to allow identity confirmation without requiring a full document verification flow.

A primary use case is re-authentication for high-value transactions, where customers may want to confirm that the user initiating the transaction is the same individual previously verified. The feature also supports customers who use only standalone selfie checks without document verification.

1. Initial identity verification (Optional):
A user completes a full IDV flow, including document and liveness checks. The customer stores the reference ID and status after receiving the webhook.

2. Transaction re-verification trigger:
The user initiates a transaction requiring re-verification using standalone selfie with face match.

3. Reference setup by customer:
The customer calls the /idv-api/v1/reference-image endpoint with:

• referenceId (required): A unique identifier used to track the transaction.
• baseReferenceId (optional): The session ID of a previously approved session containing a reference image.
• If a valid baseReferenceId is provided, it will be used for getting the reference face image.
• If baseReferenceId is not provided the system returns a presigned uploadUrl for you to upload a reference image.

Warning: This step requires backend integration on the customer's side to automatically call the endpoint and prepare the reference image for the standalone selfie check with face match.

4. Reference Image upload (if needed): The customer uploads the reference image file using the presigned URL.

5. SDK session initialization: The customer starts the standalone selfie session via the SDK, including the previously defined referenceId.

6. Liveness capture and face match:

• The user uploads the liveness capture file.
• The system retrieves the reference image (from file upload or from the referenced session) and performs face matching.
• If no reference image is available, the face match is marked as not_performed, and the session is declined.

7. Webhook delivery:

• Once processing is complete, a webhook is sent including the sessionId and referenceId.
• The customer can match this data to the transaction and act accordingly.

Purpose: Verify the user's residential address using a document or utility bill.

Address verification: To complete verification with a definite status (other than REVIEW), the host application has to pass the user’s address to the SDK through SEONCustomerData.address. This will be compared to the address extracted from the provided proof.

Name verification: The user’s name is verified based on the extracted name from the Document Verification step. If this is not available, the value passed as SEONCustomerData.name will be used (see also Name matching similarity threshold ).

1. Information screen:

• An introductory page explains the address verification process.
• Users click Provide a document to begin.

2. Proof file selection:

The SDK offers different ways to provide the proof document depending on the current platform.

Desktop

• Drag & drop (or browse for) a local file from the user’s computer.

iOS & Android

• Take a photo.
• Choose an existing photo from the user’s gallery.
• Upload a file from the device using the native file browser view.

File requirements:

• Supported formats: JPEG, PNG, PDF
• Maximum file size: 16 MB

3. Confirmation screen:

If the user provided a PDF document:

• The name of the file is shown for confirmation.
• The user clicks the Upload file button to proceed.

If the user provided an image:

• A preview of the image is shown to ensure selection and quality.
• The user clicks the Upload photo button to proceed.
• The selected media is uploaded to SEON’s servers for verification.

4. Validation and next steps:

• The server verifies the address and name of the user.
• Errors (e.g., failed file upload checks or otherwise invalid attempts) result in session invalidation.

This check ensures that the provided document belongs to the same user that our customer intends to verify. It acts as a critical link between document verification and proof of address validation.

Key considerations:

• Matching algorithm: The check relies on the Levenshtein distance algorithm to assess name similarity.
• Minimum name requirements: The provided name must contain at least two tokens (first name and family name(s)). If fewer than two tokens are supplied, the check will fail.
• Handling of additional tokens: If the extracted name from the document contains extra tokens (e.g., middle name), the verification will be placed in REVIEW status during evaluation.

Strict family name check

This is not a fully secure feature, and we recommend using the usual name fuzzy match. Additionally, if Proof of Address (PoA) verification is set up, enabling the strict name check may interfere with PoA validation since only the family name is available.

We offer an optional strict family name check for ID verification. While customers cannot enable this setting themselves, our company can configure it on their behalf. This feature can be activated for an entire customer account or applied to a specific IDV template.

When the strict name match is enabled, the standard name matching behavior is disabled, and a new validation logic is applied. The names remain case-insensitive, but even a single character discrepancy will result in a failed session.

At the start of a session, the usual name property can be used for name validation. However, if strict mode is enabled, only the last name should be provided. You can still provide the full name; in that case, each part of the name will be strictly checked against the document.

If the strict name match is turned on but a reference name is not provided at session start, or if the name cannot be extracted from the document, the session status will be set to "review."

The verification process involves splitting the user’s full name and comparing the provided reference name with each segment. If at least one segment exactly matches the reference name, the check is approved; otherwise, it fails. Partial matches are not permitted — the reference must include the entire family name.

While this implementation allows verification against any given name, we strongly recommend providing the family name at session start to ensure accuracy.

For the proof of address verification, the name match will be validated as follows:

• If a provided name is available, the check will be performed against it.
• If no provided name is available, the check will be conducted against the name extracted from the document.

This ensures consistency in name validation across different verification steps.

To detect possible fraud attempts, each session is inspected for duplicate data points in previous session (under the given customer, including all past sessions). Unlike other checks, this step is done automatically and requires no additional input from the users during the verification process.

Data points considered

Biometric data

• Face embedding: Only checked if the session contains a selfie check step

Document extraction data: Only checked if the session contains a document verification step.

• Document ID
• Date of birth
• Full name

Additional session properties: Only checked if provided by the customer

• Email address

Evaluation logic

Previous sessions are only considered if they are already finished (either approved, review or rejected). Individual data points are compared in the following logic:

Session duplication is a symmetrical connection, meaning the old session will have the new one considered as it’s duplicate, and vice-versa. The webhook will not be re-sent for the old session.

Data display and webhook structure

Flagged duplicates can be managed on the Admin interface (for details, see this overview). Additionally, the fact that there was at least one duplicate is reflected in the webhook structure under the duplicatesFound boolean property.