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
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 - defaultfalse
Whether the verifying process should be attempted, and the result will be included in the overall verified status. - attempts
number - defaultnull
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 - defaulttrue
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.
Updated almost 2 years ago