UK DIATF

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:

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 payload

  • A 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 reason

    • The reason for decline is visible in:

      • verification.code ,

      • verification.reason and

      • verification.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 payload

  • A 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 an approved response

  • This 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 reason

    • This info is visible in:

      • verification.code,

      • verification.reason,

      • verification.reasonCode and

      • verification.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

{
    "status": "success",
    "verification": {
        ...
        "additionalVerifiedData": {
            "UKTFCheckResult": {
                "CIFAS": "Registry validation was successful",
                "Electoral roll and Credit History UK": "Registry validation was successful",
                "PEP": "Registry validation was successful",
            }
        }
    }
}

Request properties explained

  • status: string* Status of the response

  • verification: object* Verification request decision object

    • additionalVerifiedData: object* Data which has been optionally verified for session

      • UKTFCheckResult: array* Array of UK DIATF checks results

        • CIFAS: string* CIFAS registry check result

        • Electoral roll and Credit History UK: string* UK Electoral Roll and Credit History check result

        • PEP: 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: