Create a sandbox account
API Reference
Try a production app

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. Further, in August 2024, the new law (currently only available in Estonian) absolves us of the requirement to perform Tier 3 verification. This effectively results in only two Tiers of KYC relevant for any application built on Striga -> Tier 1 (Limits as prescribed here) and Tier 2 (No limits).

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": "d054fd78-bda7-44e6-8037-f339aef65942",
    "emailVerified": true,
    "mobileVerified": true,
    "currentTier": 0,
    "status": "NOT_STARTED",
  	// IGNORE THIS TIER IF YOU DO NOT HAVE PRODUCTION ACCESS YET
    "tier0": {
        "eligible": true,
        "status": "NOT_STARTED",
        "outboundLimitConsumed": "0",
        "outboundLimitAllowed": "1500000"
    },
    "tier1": {
        "eligible": true,
        "status": "NOT_STARTED",
        "inboundLimitConsumed": {
            "all": "0",
            "va": "0"
        },
        "inboundLimitAllowed": {
            "all": "2500000",
            "va": "1500000"
        },
        "outboundLimitConsumed": "0",
        "outboundLimitAllowed": "1000000"
    },
    "tier2": {
        "eligible": false,
        "status": "NOT_STARTED",
        "outboundLimitConsumed": "0",
        "outboundLimitAllowed": "10000000"
    },
  	// IGNORE THIS TIER IF YOU DO NOT HAVE PRODUCTION ACCESS YET
    "tier3": {
        "eligible": false,
        "status": "NOT_STARTED",
        "outboundLimitConsumed": "0",
        "outboundLimitAllowed": "10000000"
    }
}

📘

Handling tiered KYC within your application

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.

The Tiered KYC flow is structured as follows -

  • 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.

📘

Transaction Limits

Information about Restricted Jurisdictions and Limits can be found here.


📘

Existing Production Applications

The sandbox environment reflects the latest state of possible KYC flows with limit checks mimicking the production environment. If you already have a live application, all Tier 2 users will automatically be upgraded to Tier 3 and all eligible Tier 0 users will be upgraded to Tier 3. All new and future Tier 2 users will enjoy the same limits as Tier 3 users and to ensure backwards compatibility, the Tier 3 data structure will continue to exist until otherwise communicated, however bears no relevance and is safe to remove completely from user interfaces, simplifying possible tiers for users to simply 1 and 2.

Legacy KYC Flow (Deprecated - Ignore if you are not on production)


  • 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 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.

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