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
End-User consent can be requested as part of your Web Integration configuration using the
consent_requiredconfiguration 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.
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)
The first approach starts with a single consent screen
On clicking the "Cancel" button, the user is then prompted to be sure they wish to cancel.
If they wish to cancel and click the "No, Cancel Verification" button, an event is published notifying that
SmileIdentity::ConsentDenied. This event triggers the
onErrorhandler set up when configuring the Web Integration, if it exists.
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 Identity software system is enhanced with information that we store in our records stating that we got end-user consent.
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_MFAid 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.
On submitting their ID number, the OTP Delivery Methods are queried.
Here, the user has the chance to select one of the contact methods to receive a TOTP.
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
This event is published along with some extra information in the shape:
id_number: <id_number provided by the user>,
This event object also triggers the
onErrorhandler 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.
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.
To use the End User Consent screens in your configuration, we use the
consent_requiredfield when instantiating the Web Integration. See an example below.
KE: ['ALIEN_CARD', 'NATIONAL_ID', 'PASSPORT'],
NG: ['BVN', 'BVN_MFA', 'DRIVERS_LICENSE', 'V_NIN', 'VOTER_ID']
name: "Demo Account",
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.