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: , ,

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.

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 onError handler 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 ID 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_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:

{
  "id_number": "<id_number provided by the user>",
  "message": "SmileIdentity::ConsentDenied::TOTP::ContactMethodsOutdated"
}

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.

window.SmileIdentity({
  token,
  product,
  callback_url,
  environment,
  consent_required: {
    KE: ["ALIEN_CARD", "NATIONAL_ID", "PASSPORT"],
    NG: ["BVN", "BVN_MFA", "DRIVERS_LICENSE", "V_NIN", "VOTER_ID"],
  },
  partner_details: {
    partner_id,
    signature,
    timestamp,
    name: "Demo Account",
    logo_url: "https://via.placeholder.com/50/000000/FFFFFF?text=DA",
    policy_url: "https://usesmileid.com/privacy-privacy",
    theme_color: "#000",
  },
});

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.