Changelog

Tiered KYC

Allow your users to pass a tiered verification process as they transact more

Until January 2024, the standard KYC flow as detailed in the previous page "Onboarding Flow" typically requires A Proof of Identity (POI), a Liveness Check and a Proof of Address (POA) in addition to collecting numerous fields prior to starting KYC, as required by law.

The Tiered KYC flow allows your users to get started with transacting by completing a substantially simpler KYC flow in most cases (for EEA citizens in the EEA) using the "Tiered" method, resulting in lower costs of verification for your business and a much higher pass rate. The basic Tiered KYC object returned on KYC status endpoints and sent in webhooks looks as follows, containing an eligibility parameter for each tier and a status on each tier, along with the applicable limits (in Euro cents) per tier. 

{
  "userId": "20ee2b7f-fd9b-4cc1-8dfe-695be722dd45",
  "currentTier": 2,
  "status": "APPROVED",
  "tier0": {
    "eligible": false,
    "status": "NOT_STARTED",
    "outboundLimitConsumed": "0",
    "outboundLimitAllowed": "1500000"
  },
  "tier1": {
    "eligible": false,
    "status": "APPROVED",
    "inboundLimitConsumed": {
      "all": "9722001",
      "va": "0"
    },
    "inboundLimitAllowed": {
      "all": "2500000",
      "va": "1500000"
    },
    "outboundLimitConsumed": "0",
    "outboundLimitAllowed": "750000"
  },
  "tier2": {
    "eligible": true,
    "status": "ON_HOLD",
    "outboundLimitConsumed": "0",
    "outboundLimitAllowed": "1500000"
  },
  "tier3": {
    "eligible": false,
    "status": "NOT_STARTED",
    "outboundLimitConsumed": "0"
  }
}

📘

Handling tiered KYC within your application

To ensure backwards compatibility, the Tiered KYC flow will not break any existing implementation and is a feature enabled for your application if you wish to use this.

However, the integration effort is straightforward in basically redirecting the user to the SumSub SDK for currentTier values of 1 and 2 using a new token obtained from the "Start KYC" API using the respective tier value.

We have configured the flow on our side internally to handle the data that needs to be collected, such that you simply need to render the SumSub SDK using the token received from "Start KYC" at that Tier.

Once a user has been APPROVED for the first time on Tier 1 and wishes to start Tier 2 (or is automatically moved to Tier 2), the <TieredKYCObject>.tier2.status will change from NOT_STARTED to INITIATED, indicating that the user must be redirected to the SumSub SDK. Users will have 30 days to complete Tier 2 KYC - During this time, they can continue using their account as normal within Tier 1 limits, but must be prompted by your application to complete Tier 2 within the 30 day timeframe.

Only for Tier 3, a web view or alternative should be used to display the page contained within the verificationLink parameter in the response of the "Start KYC" API for Tier 3, as this is handled internally at Striga and not via SumSub, keeping the costs of video call verification manageable

The Tiered KYC flow is structured as follows -

  • Tier 0 - Currently this equates to the Legacy tier, where the standard flow is conducted - POI + Liveness + POA. Users whose status in not APPROVED or REJECTED_FINAL may start Tier 1.
  • Tier 1 - For newer users, a user may begin their verification process at this tier, by simply passing in tier as 1 in the "Start KYC" API. In most normal cases, this Tier requests for a POI + Liveness check, with an additional POI or POA automatically requested in specific cases as per our internal AML policies. When the Tier 1 inbound limit is breached the user is automatically bumped to Tier 2. When on Tier 2, a user must complete verification within 30 days. Once APPROVED on Tier 1, the user can self opt to start Tier 2.

🚧

Starting Tier 1 Verification - missingFields

In the latest release, the "missingFields" parameter was added to the "Get User" endpoints, which are the fields required to be collected before a KYC session can be started. With Tier 1 verification, the fields occupation, sourceOfFunds, purposeOfAccount, selfPepDeclaration, expectedIncomingTxVolumeYearly, expectedOutgoingTxVolumeYearly, placeOfBirth are no longer required fields and your user interface does not need to collect this information any more.

Only firstName, lastName, address, dateOfBirth, email and mobile are required to start a Tier 1 KYC.

If your application is collecting fields as a part of the legacy "Tier 0" flow, please remove them from your user interface, for a friendlier user experience as these are automatically collected through the KYC SDK at various points of the tiered flow, as needed. But, if you intend on enabling the new KYC flow and at the same time continue using the Tier 0 flow, the occupation, sourceOfFunds, purposeOfAccount, selfPepDeclaration, expectedIncomingTxVolumeYearly, expectedOutgoingTxVolumeYearly and placeOfBirth must still be populated before starting KYC.

  • Tier 2 - Once a user is APPROVED on Tier 1 and their Tier 1 inbound limit is breached (Currently 15,000 EUR equivalent in crypto or 25,000 EUR equivalent overall), the user is automatically elevated to Tier 2 and must complete the Tier 2 verification within 30 days to continue transacting. This Tier in most common cases contains a questionnaire about the source of funds and a POA if it has already not been collected. Once APPROVED on Tier 2, the user can opt to start Tier 3.
  • Tier 3 - This process involves a video call with a compliance officer at Striga (required under Striga's license) and incurs a separate charge. Please contact us on [email protected] or email your AM at Striga to have this feature enabled. The "Start KYC" API with a tier value of 3 will return a link that may be displayed inside a web view as a calendar link to book a time for verification.

📘

Transaction Limits

Information about Restricted Jurisdictions and Limits can be found here.

If you are an application already with production access, please contact us to include this feature in your contract and enable it for you.

If you are an application moving to production, please let us know that you would like to have this enabled.

Changes when moving from Tier 0 KYC

If your application has been using Tier 0 KYC, please note the following changes to the user object enum values. These values no longer need to be collected in your application and we don't expect them to change from our side, but below are the updated list of possible values for extra fields in the user object which are extracted as the user completes various Tiers of verification -

🚧

Purpose Of Account

During Tier 1 of the KYC process, users are required to select the purpose of their account. The following values are available for selection within the KYC SDK -

CARD_INSIDE_EEA,
CARD_OUTSIDE_EEA,
CRYPTO_PAYMENTS,
FIAT_PAYMENTS,
CUSTODY,
RECEIVING_PAYMENTS,
SPENDING ,
TRADING,
INVESTMENT/SPECULATION,
OTHER

Note: Once the user selects the purpose of their account, the corresponding value will be mapped in the user response under the key purposeOfAccount

🚧

Source Of Funds

During Tier 2 of the KYC process, users are required to select the source of funds. The following values are available for selection within the KYC SDK -

PERSONAL_SAVINGS,
FAMILY_SAVINGS,
LABOUR_CONTRACT,
CIVIL_CONTRACT,
RENT,
FUNDS_FROM_OTHER_AUXILIARY_SOURCES,
SALE_OF_MOVABLE_ASSETS,
SALE_OF_REAL_ESTATE,
ORDINARY_BUSINESS_ACTIVITY,
DIVIDENDS,
LOAN_FROM_FINANCIAL_INSTITUTIONS_CREDIT_UNIONS,
LOAN_FROM_THIRD_PARTIES,
INHERITANCE,
SALE_OF_COMPANY_SHARES_BUSINESS,
OTHER

Note: Once the user selects the source of funds, the corresponding value will be mapped in the user response under the key sourceOfFunds

🚧

Occupation

During Tier 2 of the KYC process, users are required to select the occupation. The following values are available for selection within the KYC SDK -

SELF_EMPLOYED,
AUDIT,
FINANCE,
PUBLIC_SECTOR_ADMINISTRATION,
ART_ENTERTAINMENT,
AUTO_AVIATION,
BANKING_LENDING,
BUSINESS_CONSULTANCY_LEGAL,
CONSTRUCTION_REPAIR,
EDUCATION_PROFESSIONAL_SERVICES,
INFORMATIONAL_TECHNOLOGIES,
TOBACCO_ALCOHOL,
GAMING_GAMBLING,
MEDICAL_SERVICES,
MANUFACTURING,
PR_MARKETING,
PRECIOUS_GOODS_JEWELRY,
NON_GOVERNMENTAL_ORGANIZATION,
INSURANCE_SECURITY,
RETAIL_WHOLESALE,
TRAVEL_TOURISM,
FREELANCER,
STUDENT,
UNEMPLOYED,
RETIRED,
PROFESSIONAL_SERVICES,
EDUCATION,
OTHER

Note: Once the user selects the occupation, the corresponding value will be mapped in the user response under the key occupation