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"
    },
   // PRODUCTION ONLY
  "tinCollected":false
}

📘
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.
OnlyfirstName, 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.

❗️
DAC8 Compliance (Effective Jan 1 2026 00:00 EEST)
In order to comply with the new European Directive instructing all crypto-asset service providers to collect & validate the tax identification numbers and tax residence countries of users, the following changes are to be noted -

Necessary TIN info. will be collected in text fields as part of the regular KYC flow through SumSub for all new users and unverified users still going through the SumSub flow.

For existing users, AML regulations dictate periodic & ongoing monitoring of all customers. In such cases, an already verified user that undergoes an automated periodic screen may automatically fall into an unverified KYC status since TIN info. will be missing. In such cases, the users' primary KYC status will not be changed and will continue to stay APPROVED and a webhook with the following format will be sent to your application to parse. At this point, even though the user status is APPROVED, your application may initiate a new SumSub session via the Start KYC endpoint to retrieve a SumSub token such that the user will only be prompted to provide their TIN info. inside SumSub. The user status will continue to be APPROVED until 31 July 2026 as per regulatory requirements to prevent any impact to existing users that have already completed KYC.
{
  userId: '64990ad5-0ad8-433b-916d-ed057196a794',
  type: 'USER_ACCOUNT_ACTION_NEEDED',
  status: 'APPROVED',
  reason: 'TIN_INFORMATION_MISSING_DAC8',
  tinVerificationExpiryDate: '2026-03-01T19:12:48.811Z',
}
To help applications determine whether the required TIN information has been collected for DAC8 compliance, a new boolean field tinCollected is exposed:

The Get User Details API will return the tinCollected flag (true or false).

The KYC webhook payload will also include the tinCollected flag. This allows integrators to reliably identify whether TIN data has been collected for a user and take appropriate action (e.g., prompting the user to complete TIN collection).

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 hello@striga.com 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

Handling tiered KYC within your application

Starting Tier 1 Verification - missingFields

Transaction Limits

Existing Production Applications

DAC8 Compliance (Effective Jan 1 2026 00:00 EEST)

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

Purpose Of Account

Source Of Funds

Occupation

Starting Tier 1 Verification - `missingFields`