KYC checks

Settings in this section are relevant for KYC functionality only. You can skip this part if you're not going to switch on feature "KYC checks"

Go to "Advanced config management" in order to configure settings for KYC checks using json editor.

Step 1. Decide how many tiers are necessary for your business case and describe them

You are welcome to set as many tiers as you need.

All users automatically get tier 0 when they register

Each tier must have following parameters:

• number - will be used for processing and also will be displayed to user and admin

• name - will be displayed to user under KYC description page

• description - optional, but we highly recommend to provide it, you can briefly explain your end-users the purpose of this tier and documents which they will need to submit to get it

• KYC providers configuration (starting from tier 1) You can set one of the following options for name: "Manual" or "ShuftiPro" (note that register is important here). "config" value depends on the way you're going to handle the KYC checks. ‼️Note that all tiers must have the same provider name.

Manual KYC checks (no integration with 3rd party services)

If you are NOT interested in the Shufti Pro integration for KYC process, you can use "Manual" as a provider's "name" and leave "config" parameter empty ("") which means that you're taking the responsibility for:

• instructing users of how they can go through KYC checks (you can send emails for this purpose),

• collecting all necessary data from users (by email or via phone calls or any other method which you prefer),

• verifying the validity of the provided data.

You can use portal for receiving the tier requests in the form of KYC cases and managing the results of the verification by approving or declining the requested KYC tier.

ShuftiPro KYC provider integration

If you are interested in setting up the Shufti Pro integration, you are supposed to use "ShuftiPro" as a provider's "name" and define the "config" parameter for each tier. ShuftiPro config settings are described in the next step.

 "kycTiersDescription": [
    {
      "number": 0,
      "name": "basic",
      "description": "It's a basic basic tier, you don't have to pass KYC checks, you already have it."
    },
    {
      "number": 1,
      "name": "advanced",
      "description": "You will have to provide the scan of the passport, id or driving license to get this tier.",
      "providers": [
        {
          "name": "ShuftiPro",
          "config": "{\"language\":\"EN\", \"redirect_url\":\"https://wlp-uat.onteos.net\",\"verification_mode\":\"any\",\"document\":{\"supported_types\":[\"id_card\",\"driving_license\",\"passport\"],\"dob\":\"\",\"name\":{\"first_name\":\"\",\"middle_name\":\"\",\"last_name\":\"\",\"full_name\":\"\"},\"gender\":\"\",\"fetch_enhanced_data\":\"1\"}}"
        }
      ]
    },
    {
      "number": 2,
      "name": "professional",
      "description": "It's tier for professional traders",
      "providers": [
        {
          "name": "ShuftiPro",
          "config": "{\"language\":\"EN\", \"redirect_url\":\"http://wlp-uat.onteos.net\",\"verification_mode\":\"any\",\"document\":{\"supported_types\":[\"id_card\",\"driving_license\",\"passport\"],\"dob\":\"\",\"name\":{\"first_name\":\"\",\"middle_name\":\"\",\"last_name\":\"\",\"full_name\":\"\"},\"gender\":\"\",\"fetch_enhanced_data\":\"1\"}}"
        }
      ]
    }
  ],

Step 2. Define KYC provider settings for each tier > 0

Manual KYC checks (no integration with 3rd party services)

"config" parameter can be empty (set as ""), it will be ignored anyway

ShuftiPro KYC provider integration

If you use Active Sandbox product and run pilot project you are welcome to use CoreLedger test account for KYC provider, no need in any additional configuration.

In order to use KYC functionality with Shufti Pro integration productively you will need to create your own productive account with Shufti Pro and follow the steps described below.

Make sure that all integration parameters (API keys and redirect URL) are configured for productive account if you expect productive account to be used in WLP or test account if you expect test account to be used in WLP. Productive and test account have different integration settings

1. Generate API keys for integration and send them to your CoreLedger project manager. Check how to get them here.

2. Configure redirect URL which will be used in integration parameters. This is the page to which user should be redirected after he or she completes the KYC checks in Shufti. Make a screenshot of the configured URL in Shufti Pro's account and send it to your CoreLedger project manager. How to configure redirect URL after user completes the KYC checks

3. Configure integration parameters. We use Onsite verification with OCR for integration with Shufti Pro. All parameters which can be set are described in Shufti Pro's documentation in Verification Request section. You will need to configure it by yourself or send screenshots described in How to define KYC configuration and test the KYC flow in Shufti Pro and send them to your CoreLedger project manager together with all previous parameters.

You can configure and define settings by yourself if you're familiar enough with json structure and integration parameters. If you have some problems, we can help you to configure Shufti Pro integration. You will have to provide screenshots with the selected parameters for your desired KYC flows for each tier > 0 (please note that we will need screenshots of each step: enabled services, each service parameters and common parameters) to your CoreLedger manager. Check info in How to define KYC configuration and test the KYC flow in Shufti Pro to get necessary screenshots

Please, note that you have to decide based on your business case which checks are necessary and define configuration settings of these checks.

Example which we use in our CoreLedger Active Sandbox (you can find it in KYC tier 1 settings in the example above) looks like this:

"config": "{
--language of Shufti Pro interface--
\"language\":\"EN\", 

--URL to which user will be redirected after KYC process in Shufti is over. You can put here any WLP page--
\"redirect_url\":\"https://wlp-uat.onteos.net\",

--required verification mode: online, offline or any--
\"verification_mode\":\"any\",

--settings of the required services, here service "document" is configured--
\"document\":
{\"supported_types\":[\"id_card\",\"driving_license\",\"passport\"],
\"dob\":\"\",
\"name\":{\"first_name\":\"\",\"middle_name\":\"\",\"last_name\":\"\",\"full_name\":\"\"},
\"gender\":\"\",
\"fetch_enhanced_data\":\"1\"}
}"

"Config" parameter is a string made of json for technical reasons. Please, don't forget to use \ sign inside "config" parameter before each quotation sign "

In our example following parameters are set:

• language

• redirect_url

• verification_mode

• Document Service parameters: supported_types, dob, name, gender, fetch_enhanced_data

You can use our example parameters for tests or even pilot projects with Active Sandbox but for productive usage you have to enable and configure necessary Shufti Pro services. In Shufti Pro's documentation you can find additional parameters for each service:

• Face Service

• Document Service

• Document Two Service

• Address Service

• Consent Service

• Phone Service

• Background Checks Service

Please, don't set "reference" and "callback_url" parameters and don't specify the values of "email" or any other end user's data described in Shufti Pro's documentation. They will be set automatically

How to configure redirect URL after user completes the KYC checks

After user submits all necessary data for KYC checks or after he cancels this procedure, user should be redirected back to the portal.

1. Go to your Shufti Pro backoffice, login to your account and go to "Settings" -> "Callback&Redirects URLs".

2. Click "Add Domain", select type "Redirect" and enter the URL of the portal page into the field domain. It can be any page of the WLP but we recommend to use home page. https://wlp-sandbox-pilot.onteos.net/ - this is an example for CoreLedger's Sandbox portal home page

Add redirect URL

Add redirect URL

How to define KYC configuration and test the KYC flow in Shufti Pro

In order to define all configuration settings correctly and check how the user flow for KYC will look like, you can use "Product demo" functionality with a very user friendly UI in Shufti Pro's backoffice.

1. Go to your Shufti Pro backoffice, login to your account and go to Integration tab, select "KYC journey builder" to start configuration process

   

   Select "KYC Journey Builder" in Integration tab
2. Click "Create new" and enter the name for this KYC journey. For example, "KYC tier 1 journey", "KYC tier 2 journey", etc. Select the necessary KYC services from the list of available services by dragging them and dropping to the right area. Click "Start" and follow the configuration wizard. Make a screenshot of each step after you've filled the desired parameters (before clicking "Next" or "Save").

   

   

   
3. After you configure the flow you will see the button "Save". After you click it there are three available options what to do next. We recommend you to check the flow which you've built from user's perspective by clicking "Start Demo". If you realize that there should be some changes, you can always edit the KYC journey by selecting it in the list of journeys and clicking "Edit" icon. After you make sure that the flow totally fits your needs, gather all the screenshots characterizing the flows built for each KYC tier and at the last step click "Code". Copy the code which will be displayed right after your click for each flow and forward it together with the screenshots to your CoreLedger manager or use it to configure KYC integration for each tier in the Advanced configuration tab of WLP.

   

   End of the KYC journey configuration flow

   

   Code characterizing some of the selected configuration parameters

Step 3. Define which functionality should be available for each tier

Common rule for these settings is that you define the minimum KYC tier from which this specific functionality is available.

Following functionality can be made unavailable for specific tiers:

• visibility of Shop functionality, Redemption functionality - set minimum KYC tier from which corresponding menu items and all functionality on this pages will be visible to users

• availability of Shop functionality, Redemption functionality - set minimum KYC tier from which all assets will be available for purchasing (if other tiers are not specified for some assets) and all redemption methods will be available (if other tiers are not specified for some redemption methods)

  "kycTierFunctionalRestrictions": {
    "visibility": {
      "purchase": 0,
      "redemption": 0
    },
    "availability": {
      "purchase": 1,
      "redemption": 1
    }
  },

In our example Shop and Redemption menu items are always displayed, but all assets and redemption methods will be closed by "Get tier 1" button for users with current tier = 0.

• specific assets for purchasing - set minimum KYC tier from which this asset can be purchased, you can find parameter "kycTier" in config file in "asset" object (check how assets are configured for purchasing)

• specific payment methods - set minimum KYC tier from which this payment method can be used, you can find parameter "kycTier" in config file in "payment method" object (check how payment methods are configured for purchasing)

• specific redemption methods - set minimum KYC tier from which this payment method can be used, you can find parameter "kycTier" in config file in "redemption method" object (check how redemption methods are configured)

All configurations are reflected in the page representing description of KYC process for your end-users

Page with description of KYC process

Step 4. Don't forget to switch on KYC checks for your portal after configuration is finished

Step 5. Let portal close KYC cases automatically if verification is made by third party KYC service

This setting can be changed even when KYC checks functionality is already switched on. This setting is valid only for integration with KYC provider, if "Manual" provider is used, all KYC cases must be closed manually.

Admin can adjust KYC settings and define whether you want KYC cases to be automatically closed (approved/declined) based on the verification status received from KYC provider:

• approved if verification result is "Accepted"

• declined if verification result is "Declined"