Verification configuration

How to customize the verification flow.

Initial data

When an end user is being verified, the system compares the gathered data with data that is already given upon submission. This way, you can request to verify a specific person by name, citizen ID or other information you might already have.

Example:

{
  "citizenId": "1112223334445",
  "firstName": "เจมส์",
  "middleName": "เฮนรี่",
  "lastName": "โด",
  "dateOfBirth": "2006-06-06",
  "laserCode": "AB1-1234567-12",
  ...
}

Notifications and expiration

Our KYC Core module supports notifying the user by SMS or email. You can add the notifyType (none, sms or email) for a notification in the Verification input body.

The SMS type requires a phoneNumber and email type requires an email property alongside the input.

You can also add a notifyInterval which is in ISO 8601 duration format reference. The interval, if set, will send a reminder if the Verification has not been completed before the duration has passed.

Optionally, you can also add an expiresAt property to the verification input, once the date specified has passed, the end user can no longer attempt verifying themselves.

Example:

{
  "notifyType": "sms",
  "phoneNumber": "0987654321",
  "email": "john.doe@mail.com",
  "notifyInterval": "P2D",
  "expiresAt": "2023-12-21T22:18:23.773Z",
  ...
}

Process configuration

A complete verification consists of several verifying processes. They may or may not be connected to other processes by forming a dependency.

An example is that ID-face-recognition cannot be verified without an ID card mugshot (hence "ID"-face-recognition), therefore the process front-ID-card has to be completed before it is possible to get a verified face-recognition result on this mugshot. If the front-ID-card is not verified, we cannot be sure that the face we have matched is actually the person we are trying to verify.

In order to be completely verified, all of the requested verifying processes need to be verified. This leaves us a few possibilities when it comes to the user flow. Should we let the user complete a process if there is no possibility of getting the verification verified? And, should we let the user complete a process if there is not even the possibility of having this single process verified?

The configuration for each process is defined in an immutable field upon creation of the verification object. The field name is ${processName}Config (example: frontIdCardConfig).

Common configuration keys

There are a few shared configuration keys between all processes:

  • required
    boolean - default false
    Whether the verifying process should be attempted, and the result will be included in the overall verified status.
  • attempts
    number - default null
    Optional parameter to limit the amount of times the verifying process can be attempted.
    If the parameter is undefined, the user has to retry until verified.
  • endFlowOnFailure
    boolean - default true
    In the case this or previous verifying processes cannot be verified within the configured attempts, block other verifying processes of being attempted. The verification status will be "completed" and the user flow ends.

    🚧

    Replaces V1.3 field "dependenciesRequired"

In the next steps you can find examples and details for each process specific configuration.