End User Consent
The Web Integration has prebuilt screens to request consent from a user before running a job which may return personal identifiable information. This gives the user control and also ensures compliance
Scope: Basic KYC, Biometric KYC, Enhanced KYC
End-User consent can be requested as part of your Web Integration configuration using the consent_required
configuration documented in the Usage Page, or required by the ID Authority.
Where required by the ID Authority, the Consent Screens will be added as part of the user KYC process. Where not required by the ID Authority, we only show the Consent Screens when provided as part of the Web Integrations configuration.
The Consent Approaches
Depending on the id type you are accessing, there are two different approaches users will be required to grant consent. They are:
UI / visual consent
UI / visual consent + Time-based One-Time Password (TOTP)
UI / Visual Consent
The first approach starts with a single consent screen
End-User Consent Request
On clicking the "Cancel" button, the user is then prompted to be sure they wish to cancel.
End-User Consent Denied
If they wish to cancel and click the "No, Cancel Verification" button, an event is published notifying that SmileIdentity::ConsentDenied
.
This event triggers the onError
handler set up when configuring the Web Integration, if it exists.
End-User Consent Granted
If the end-user clicks the "Allow" button, they proceed to provide accompanying user information like the ID Number, and some PII information in the case of Basic and Biometric KYC. The final request to the Smile ID software system is enhanced with information that we store in our records stating that we got end-user consent.
UI / Visual Consent + Time-based One-Time Password
This approach starts with the visual consent flow, but requires the user to verify they have the right to grant consent by providing an OTP sent to the registered contact methods for the ID Type.
Currently, only Bank Verification Number (BVN), BVN_MFA
id type, in Nigeria requires this consent approach.
In this flow, the user gets prompted for their ID number after clicking "Allow" in the Visual Consent phase.
ID Number Request
On submitting their ID number, the OTP Delivery Methods are queried.
Select Contact Method
Here, the user has the chance to select one of the contact methods to receive a TOTP.
Contact Methods Outdated
If the contact methods presented are outdated, and the user clicks the "I am no longer using any of these options" button, an event is published notifying that SmileIdentity::ConsentDenied::TOTP::ContactMethodsOutdated
This event is published along with some extra information in the shape:
This event object also triggers the onError
handler set up when configuring the Web Integration, if it exists. We advise that our integrating partners use this to provide an off-ramp approach for their users.
OTP Verification Screen
When a user selects one of the contact methods and clicks "Continue", they are then directed to the OTP Verification screen
On provision of a valid OTP, the user is directed to the PII or Biometric Data collection screens for Basic KYC and Biometric KYC, or the request is submitted for Enhanced KYC.
Usage
To use the End User Consent screens in your configuration, we use the consent_required
field when instantiating the Web Integration. See an example below.
N.B.: This configuration is subject to the ID Authority's requirements. If the ID Authority requires End User Consent, the Web Integration displays the screen regardless of the configuration options.
Last updated