SumSub: Verification process of profiles

Workflow

The basic verification flow for persons and companies is performed as follows:

1. Client Registration: Clients register on Crassula's platform by filling out a sign-up form. Key client data is shared with SumSub for further data exchange. See the Client data processing section for details.

2. Document Screening: After registration, clients are required to provide the necessary documents. SumSub performs automatic checks on these documents.

3. Screening Results: SumSub sends the verification results, including the verification level, verification status, and client-submitted data, to the Crassula encrypted server.

4. Profile Activation/Blocking: Crassula updates the verification details in its system, downloads documents from SumSub, and activates or blocks the client's profile based on the received results. By default, the client’s account is activated and fully functioning.

Advanced details

SumSub verification is configured and processed as follows:

1. A White Label creates custom verification levels to define what kind of personal information and documents must be provided by clients. Various levels allow to define extended limits for those clients who have provided additional verification details.

2. Once the levels are created, the White label shares their names with Crassula. A SumSub API key is required for connection.

3. Crassula adds the names to system config files for the following purposes:

   1. Updating default UI level names with the custom ones provided by the White label.

   2. Matching verification statuses provided by SumSub with clients of the exact White label.

4. A verification request is created when a client fills in the sign-up form.

5. SumSub receives the client’s personal details and creates an application for the first verification level. Once SumSub completes the verification the verification status is updated.

   

6. SumSub provides the following details to the Crassula encrypted server :

   1. Verification level

   2. Verification status

   3. Data submitted by clients.

   4. Client documents

7. The verification details are updated in the Crassula system according to the screening results. Verification data is available in the Identification requests section of the Admin Panel.

Client data processing

Crassula exchanges client data with SumSub via API and stores it on the secure server. See the following data exchange cases for details.

Client data sent to SumSub to initiate verification

• Persons

  • First name

  • Middle name

  • Last name

  • Phone number

  • User email

  • Country of residence

  • User ID

• Companies

  • Company info

  • Company name

  • Registration number

  • Tax ID

  • Country of registration

  • Legal address

  • Date of incorporation

Client data received from SumSub after verification is complete

The response details depend on the verification level requested by the end user.
Referer to https://developers.sumsub.com/api-reference/#creating-an-applicant for the full list of application fields that can be received. The data received is not stored on the Crassula server, except for the parameters mentioned in the Client data sent to SumSub to initiate verification section.

Sumsub can be configured to request additional details from the client depending on the verification level. Once the new data is verified by Sumsub, it is shared with Crassula and saved as corresponding fields in the client’s profile.

API methods used for data exchange

Navigate to the following SumSub Developer Hub pages for API details.

• https://developers.sumsub.com/api-reference/#creating-an-applicant

• https://developers.sumsub.com/api-reference/#getting-applicant-data

• https://developers.sumsub.com/api-reference/#changing-provided-info-fixedinfo

• https://developers.sumsub.com/api-reference/#getting-applicant-status-sdk

• https://developers.sumsub.com/api-reference/#getting-applicant-status-sdk

• https://developers.sumsub.com/api-reference/#getting-document-images

Secondary verification

In case of document expiry, the end user has to go through a secondary verification. The process is executed as follows:

1. Client data is two weeks away from expiry.

2. Crassula system notifies the White label of secondary verification to be done.

3. The White Label follows its internal Risk Based Approach to perform the secondary verification.

4. If SumSub takes part in the process, the new client data is collected as defined in the sections above.

Crassula server security

All client data received from SumSub is stored on the Crassula server according to the Payment Card Industry Data Security Standard (PCI DSS) and includes the following security approaches:

• Data in transit is received using TLS 1.2 encryption and is only decrypted as it is being imported into the data processing system.

• Data at rest is stored within a SQL database encrypted under a the 256-bit Advanced Encryption Standard (AES-256) at the storage device level.

• All data backups are stored in the multi-region (backups replication in Google Cloud region) that is geographically closest to the location of the Database instance.

• Internal and external scans are performed annually on our network or after any significant change. Additional checks are performed once a quarter of the year.

• Crassula implements security measures for accessing data online:

  • Multi-factor Authentication (MFA).

  • Hardened workstation equipped (such as firewall, antivirus, and drive encryption).

  • Every employee is appointed with the minimum necessary privileges.

  • Server system components have a logging system that tracks each access attempt and a warning system that notifies about any attempt to log in to the server.

Configuring SumSub

Configuring verification levels

SumSub provides a dashboard to configure custom verification levels and process applications received from clients. The functionality allows SumSub to verify clients on various custom levels defined by a White Label.

To configure a verification level

1. Sign in to the SumSub dashboard—https://cockpit.sumsub.com/.

2. Navigate to Integrations > Applicant Levels > Individuals.

3. Click Create Level.

   

4. Fill in the General details and define the Required steps for the level.

5. Select the SDK pack for Web and Mobile customization. At least one level of the BasicKYC type is required for SumSub to process sign-up applications from clients.

6. Save the changes.

   

7. Create additional levels if needed.

8. Provide the level names to Crassula managers.

9. The level names will be added to Crassula config files.

10. White Label's Admin Panel and Web Interface will be updated to contain the custom names provided. For example, Level 3 will be changed to the name set for a level of the GoldKYCCustomization SDK type.

Configuring Crassula Admin Panel

It is recommended that each verification level is provided with upgrade/downgrade fees and limit configuration.

To create upgrade/downgrade fees

1. Navigate to the Price lists tab in the Banking sidebar.

2. Select a Price list for configuration and click Edit.

3. Navigate to Change verification level fees in the top sidebar.

4. Click Add New in the top-right corner.

5. Fill in the fee rule details.

6. Refer to Price lists for additional details on the parameters.

To create a limit pack for the verification level

1. Navigate to the Limits tab in the Banking sidebar.

2. Click Add New in the top-right corner.

3. Select a Client Verification Level to set the Limit for. It is strongly recommended to configure the limit pack for each verification level for advanced testing purposes.

4. Define threshold details.

5. Refer to Limits for additional details on the parameters

The created Limit is assigned to clients automatically depending on their verification level.

Configuring callback

The callback functionality allows SumSub to provide verification results to Crassula. The verification results are required to syncronize verification statuses between the provider’s system and Crassula UI.

To enable the callback

1. Request a callback link from a Crassula manager.

2. Provide SumSub with the link to callback after provider verification.

Testing the integration

Once the configuration is complete, it is recommended to perform manual testing before promoting the functionality. The following example describes KYC checks for a person’s profile.

To test the verification process

1. Create a personal profile.

2. Validate the profile email and phone number.

3. The SumSub validation will start for the BasicKYC level.

4. Confirm the profile validation manually.

   1. Navigate to SumSub Dashboard > Applicants.

   2. Click the new record in the list to open the details.

   3. Click Start manual check.

   4. Click Approve.

      

5. Once SumSub sends a callback to the back-end, make sure the following is fulfilled:

   1. The client verification level will be changed to Level 2 (Silver for client Web Interface).

   2. Client verification status is changed to Identified.

To test the verification level upgrade from Silver to Gold

1. Navigate to the banking Web Interface and sign in as the test client.

2. Go to Settings.

3. Make sure the following requirements are fulfilled in the Tiers section:

   1. The active verification level must be marked as Current.

   2. There has to be a possibility to upgrade only to the next verification level—meaning that Tiers must be changed only step-by-step—Level 2 to Level 3.

   3. A dialog window must be opened once you click Upgrade. The window contents must include the following:

      1. The window must contain the list of limit thresholds that will be applied after the upgrade.

      2. The window must contain the drop-down list for account selection to charge the fee from. The functionality will be available if a price list is configured previously.

      3. The drop-down list must show only accounts in the currency corresponding to the fee currency. The functionality will be available if a price list is configured previously.

      4. The fee amount must be shown in the action button name. The functionality will be available if a price list is configured previously.

      5. The upgrade must not be performed when the client’s account balance is not sufficient to charge a fee from. The functionality will be available if a price list is configured previously.

4. Approve the documents from the SumSub dashboard.

   1. Navigate to SumSub Dashboard > Applicants.

   2. Click the client record in the list to open the details.

   3. Click Start manual check.

   4. Click Approve.

5. Once the documents are sent to Sumsub, the upgrade fee (if present) is charged to the selected account. The fee is charged synchronously.

Integrating Sumsub with a Custom Frontend

For customers who have their own frontend, here’s how you can configure your interaction with Sumsub:

1. Find Active Identification Request:

   • Use the API to find an active Sumsub identification request:

     CSS

     GET: /api/clients/{client_id}/identification-requests?provider=sumsub&state[0]=0&state[1]=1&state[2]=4&limit=1

   • If none exists, create one:

     CSS

     POST: /api/clients/{client_id}/identification-requests
     PAYLOAD:
     {
       provider: "sumsub"
     }

2. Retrieve Provider Details:

   • Obtain token and state information:

     CSS

     GET: /api/clients/{client_id}/identification-requests/{identification_request_id}/provider-details

3. Initialize Sumsub SDK:

   • Display the Sumsub SDK widget when idCheck.onInitialized is triggered.

4. Handle Document Submission:

   • Upon document submission (idCheck.onApplicantSubmitted or idCheck.onApplicantResubmitted), record this via the API:

     CODE

     PUT: /api/clients/{client_id}/identification-requests/{identification_request_id}/submit

5. Monitor Status Changes:

   • Use idCheck.onApplicantStatusChanged to check reviewStatus and reviewResult. Re-fetch client info and redirect as needed.

6. Error Handling:

   • Handle and display errors using idCheck.onError.

Reference

SumSub Guides: https://sumsub.com/guides-reports/

In case of urgent questions, create an internal request. See How to create a request for details.