Solaris EMI KYC Guide

Solaris EMI provides a partner journey offering anti-money laundering (AML) and Know Your Customer (KYC) services, to support you in your user onboarding and ongoing compliance. This journey is offered in partnership with W2 Global to facilitate the onboarding of UK applicants on GBP programs. You can use this journey to:

• Check whether the applicant's email has been used for fraudulent purposes.
• Check the address provided by the applicant is valid.
• Check for registration on the electoral register.
• Check the applicant details against PEPs and sanctions lists.
• Capture an image of a government issued document and check its validity.
• Capture a selfie of the applicant and run a comparison against the image on the government issued document using Document Verification Facial Comparison (DVFC) checks.

High level overview of the KYC journey

The journey is comprised of a number of stages, each of which return a KYC status for the user. The KYC statuses that you will encounter during the journey are outlined below:

KYC stages and journey flow

The KYC journey and stages are outlined below. Please note that not all stages will be required for each user - the journey flow is determined by the KYC status returned at each stage:

• User signup and Fraud checks . All relevant user data is captured in app and user details are run against a fraud database. Fraud checks are a mandatory requirement for all users added on the platform.
• Database checks . If no fraud risk is raised, user details are then run through a series of email validation, KYC, PEPs and sanction screening checks.
• DVFC checks . If the Database checks return a status of "Refer", Document Verification and Facial Comparison (DVFC) checks are run, whereby the user provides an image capture of the required document(s) and a selfie, both captured in-app.
• Manual Checks . If the DVFC checks return a status of "Refer", manual verification of the application is required. This stage requires the user to provide the relevant documentation for manual verification by the partner.

Partner integration notes and prerequisites

User and account statuses during the KYC journey

The Consumer/AddConsumers method is called to simultaneously create the user and account on the Solaris platform, and invoke the Solaris EMI KYC journey:

• Following invocation, the user and the respective account created will both have a status of Limited .
• For KYC journeys concluding in a "Pass" result:
  • The user status is set to Active .
  • The account status is set to Live .
• For KYC journeys concluding in a "Fail" result:
  • The user and account statuses remain as Limited for a period of 30 days.
  • After this period, the user status is set to Locked Out and the account status terminates in Closed .

The following integration points can provide updates during each stage of the KYC journey:

• The Account status change notification provides notification when the status of an account changes.
• The User status change notification provide notification when the status of a user changes.
• The Fraud check notification notifies you when a potential fraud match is found.
• The Consumer/GetSpecificConsumer method can be called to provide information on the given user. A status of Active means they have passed KYC, their respective account is opened and all functionality available.

App requirements and SDK integration for the DVFC stage

• You are responsible for building out the relevant UI screens in your app to permit the entry of all required user data, support all relevant flows and to adequately notify the user regarding the status of their application.
• For purposes of DVFC checks (where the user is required to provide a selfie and image captures of relevant documentation), you will need to integrate with the relevant W2 SDK .
• Partner registration with W2 Global is managed on your behalf by Solaris, who will provide you with the relevant environment specific license keys and access credentials.
• The workflows detailed below show the key interactions between the end user, your app and the Solaris API. They exclude additional dialogs, messages, popups etc. that may need to be presented to the user to ensure a clear and unambiguous onboarding journey.

Collection of address data

• You are responsible for the collection of accurate and consistently formatted address data. Solaris' recommendation is that where appropriate partners utilize a third party address validation service that returns accurate and consistently formatted address data.
• Solaris does not control the user input of data nor the data captured, neither does Solaris perform any validation or verification on the address data passed to us.
• An address listing service (provided by W2) is available, accessible via the Consumer/GetAddressLookUP method. If using this, it is recommended that the user's postcode is captured early in the application process and used to retrieve an address listing from which the user can select their address. Please note, you should also allow the user to provide their address manually if their expected address is not returned in the listing.

An example address collection flow using an address lookup service is shown below:

KYC journey in detail

User sign up and invoking the KYC journey

Calling Consumer/AddConsumers creates the user and their associated account on the Solaris platform. By default this call will also initiate the Solaris EMI KYC journey. The response from this method will include two KYC related fields:

• KYCStatusID - the KYC Status of the user. For users on GBP programs, this is the status following the completion of the Database Checks stage.
• KYCClientReferenceID - identifier required to invoke the DVFC stage, should this be required.

Database Checks stage

At this stage the user's data is run against a set of database checks, including email validation, KYC, PEPs and sanction screening checks. This will be run automatically for users on GBP card programs.

DVFC checks stage

The Document Verification and Facial Comparison (DVFC) stage requires image captures of an identity document and selfie. To facilitate this, you will need to build out a number of UI screens and integrate directly with the W2 SDK. The flow for this stage is shown below:

Notes for this stage

• The W2 SDK will automatically discern how many image captures need to be taken of the chosen form of ID (one or two captures) and prompt the user accordingly.
• All image captures must be encoded into Base64, with the resultant individual filesize not exceeding 1.5MB.
• To commence the DVFC stage, the identity document capture(s) must firstly be sent to the Consumer/DocumentVerificationProcess method. The response will include a DocumentVerificationStatus parameter which will contain either a "Refer" or "Fail" status.
• If a "Refer" status is received from the proceeding step, the selfie capture should next be sent to the Consumer/FacialComparisonProcess method. The response will include a FacialComparisonStatus parameter, which will contain the combined result (Pass, Refer or Fail) of the DVFC stage.
• Please note the methods listed above can each only be called once for a given KYCClientReferenceID . If for whatever reason subsequent calls are required, the application process (initiated via the call to Consumer/AddConsumers ) must be invoked again to generate a new KYCClientReferenceID .

Manual Checks stage

If following DVFC checks the application returns a status of "Refer", the user will need to provide the relevant documents to be manually verified. As partner specific processes and requirements may differ, this process will need to be agreed and tested with Solaris prior to program roll out.

Testing your integration in the sandbox

You can test your KYC integration and workflows in the Solaris sandbox environment, using the pre-defined test data below to return specific pre-determined KYC results.

For example using the specific data set for "Taylor Giles" should result in a KYC result of "Pass", the data for "Ellis Austin" a KYC result of "Refer" etc.