Veriff is a certified IDSP under the UK Digital Identity and Attributes Trust Framework (UK DIATF), UK Government site[↗]
Within the framework of UK DIATF, we offer the following solutions:
UKDIATF Certified Identity Verification (M1A) - used with Veriff’s end-user flow (cannot be customized); no mandatory fields, 1 registry check: CIFAS
UKDIATF Certified Identity Verification (M1B) - used with Veriff’s end-user flow (cannot be customized), sending the address is mandatory; 3 registry checks: CIFAS, PEP and UK Electoral roll
UKDIATF Certified Identity Verification (L1B) - used with Veriff's end-user flow (can be customized); no mandatory fields, no registry checks
Contact your solutions engineer for info and configuration.
Prerequisites
You have a regular identity verification integration set up with Veriff
The check is configured for that integration by your Solutions Engineer
You have configured the decision webhook to get responses from Veriff (see the Webhooks section for info)
You are prepared to send the end-user to Veriff verification flow
Flow overview
UKDIATF Certified Identity Verification (M1A)
This is a solution that is completed using Veriff’s end-user flow (cannot be customized). Sending the address
on session creation is optional.
Step 1: create a session using the POST /sessions endpoint
See the POST /sessions[↗] section for a detailed overview of how to create a session
Sending the
verification.address.fullAddress
parameter is optional
Step 2: create a session using the POST /sessions endpoint
Open the response payload of the POST /sessions[↗] request you just made
Use the URL in the
verification.url
parameter in the payloadA web flow will start, which will guide you through the process
Step 3: wait for session decision and decision webhook response
As soon as the session is verified, the decision webhook will send the response with session status. It will be one of 9000-code statuses
In case the session is
declined
, the webhook contains relevant info about the reasonThe reason for decline is visible in:
verification.code
,verification.reason
andverification.reasonCode
parameters.
UKDIATF Certified Identity Verification (M1B)
This is a solution that requires that the end-user's address is provided to return info from registries, and that the flow must be completed using Veriff's verification flow (cannot be customized).
Step 1: create a session using the POST /sessions endpoint
See the POST /sessions[↗] section for a detailed overview of how to create a session
Sending the
verification.address.fullAddress
parameter is mandatory
Step 2: capture user pictures and videos via verification flow
Open the response payload of the POST /sessions[↗] request you just made
Use the URL in the
verification.url
parameter listed in the payloadA web flow will start, which will guide you through the process
Step 3: wait for session approval and decision webhook response
As soon as the session is
approved
, the decision webhook will send anapproved
responseThis response will include the session status, as well as all the data that was extracted from the UK DIATF checks
This info is visible in
verification.additionalVerifiedData.UKTFCheckResult
array
In case the session is
declined
, the webhook contains relevant info about the reasonThis info is visible in:
verification.code
,verification.reason
,verification.reasonCode
andverification.additionalVerifiedData.UKTFCheckResult
parameters
UKDIATF Certified Identity Verification (L1B)
The solution is a UK-certified version of Veriff’s standard identity verification. You must use Veriff’s end-user flow to capture the document & selfie, but you can customize the flow.
If you are not integrated with us yet, see the Getting started section for first steps. If you are, contact your Solutions Engineer for info and configuration.
Find decision and/or session related info
M1A webhook response
M1A Webhook response = decision webhook response
M1B webhook response
M1B Webhook response = decision webhook response with specific properties in the verification.additionalVerifiedData.UKTFCheckResult
array.
The relevant data is presented in strings, marking the result of its nominal check.
These checks are executed in succession and if the preceding check fails, the succeeding one is skipped.
The order of executing the checks is as shown below, but in the webhook payload the order may be random.
additionalVerifiedData.UKTFCheckResult.CIFAS
additionalVerifiedData.UKTFCheckResult.Electoral roll and Credit History UK
additionalVerifiedData.UKTFCheckResult.PEP
Approved session
Scenario: all the checks are successful.
The sample and explanation below contain only the UK DIATF-related part of the webhook.
The decision webhook is used for many purposes, to find more info about it, see the decision webhook documentarion.
Sample request
|
Request properties explained
status
:string
* Status of the responseverification
:object
* Verification request decision object…
additionalVerifiedData
:object
* Data which has been optionally verified for sessionUKTFCheckResult
:array
* Array of UK DIATF checks resultsCIFAS
:string
* CIFAS registry check resultElectoral roll and Credit History UK
:string
* UK Electoral Roll and Credit History check resultPEP
:string
* PEP check result
*Required parameter
Declined session due to failed CIFAS check
Scenario: there may be a possible match in the CIFAS database.
The webhook example below contains only UK DIATF-related part of the webhook. See decision webhook example and explanation for the full payload.
{
"status": "success",
"verification": {
...
"additionalVerifiedData": {
"UKTFCheckResult": {
"CIFAS": "CIFAS registry detected a potential match.",
"Electoral roll and Credit History UK": "Registry check did not result in a match"
"PEP": "Registry check was not executed",
}
}
}
}
Declined session due to UK Electoral Roll and Credit History check
Scenario: the end-user data may be incorrect or missing in the database.
The webhook example below contains only UK DIATF-related part of the webhook. See decision webhook example and explanation for the full payload.
{
"status": "success",
"verification": {
...
"additionalVerifiedData": {
"UKTFCheckResult": {
"CIFAS": "Registry validation was successful",
"Electoral roll and Credit History UK": "Registry check did not result in a match"
"PEP": "Registry check was not executed",
}
}
}
}
Declined session due to failed PEP check
Scenario: end-user detected as potential PEP.
The webhook example below contains only UK DIATF-related part of the webhook. See decision webhook example and explanation for the full payload.
{
"status": "success",
"verification": {
...
"additionalVerifiedData": {
"UKTFCheckResult": {
"CIFAS": "Registry validation was successful",
"Electoral roll and Credit History UK": "Registry validation was successful"
"PEP": "Person detected to be potentially a PEP",
}
}
}
}
L1B webhook response
L1B Webhook response = decision webhook response
Veriff Customer Portal
You can find the verification session related info in the Veriff Customer Portal, under the Webhooks tab.
→ See Review verification in Veriff Customer Portal about how to view the session info in the Veriff Customer portal
Status and reason codes
For an approved
session, see the verification.code
and verification.status
parameters.
If the session was declined
or resubmission_requested
, you can find additional information by checking the verification.status
, verification.code
, verification.reason
and verification.reasonCode
data objects.
For more info about the codes you are seeing, refer to: