Tiered KYC

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 -

1. 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.
2. 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.

JSON

{
  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',
}

3. 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).