> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ripio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview & which flow applies

> How identity verification (KYC) works in the CaaS API: the flow for regulated entities and the flow with a liveness check.

Before your users can operate, Ripio needs their identity data. In the API integration you always collect that data in your own UI and submit it with [Create KYC Submission](/crypto-as-a-service/kyc-submissions/create-kyc-submission.md). What Ripio does with it depends on your company:

* **If you are a regulated entity** — a company obligated to verify its customers' identity under anti-money laundering (AML) regulations — you have already verified your users. Ripio stores the data you submit and the KYC is approved right away.
* **If you are not a regulated entity**, Ripio processes the data and asks the user to complete an ID document upload and a liveness check with the identity provider.

Ripio sets the flow up when it configures your account, based on your company. You don't choose it per request.

> [!NOTE]
>
> This page covers the API integration. In the [Crypto Widget](/crypto-as-a-service/widget/overview.md), you send the user's data when opening the widget — see [User verification (KYC)](/crypto-as-a-service/widget/get-started/kyc.md).

## The two flows

> **[KYC for regulated entities](/crypto-as-a-service/kyc/kyc-for-regulated-entities.md)**
>
> You submit the data of users you already verified. The KYC is approved in the same request.

> **[KYC with liveness check](/crypto-as-a-service/kyc/kyc-with-liveness-check.md)**
>
> You submit the data, and the user completes a document upload and liveness check on Ripio's KYC platform.

## How they compare

| | Regulated entity | Not a regulated entity |
| - | - | - |
| **Who verifies the user** | You, before submitting the data | The identity provider, through Ripio's KYC platform |
| **Response of Create KYC Submission** | `status: COMPLETED`, `provider_url: null` | `status: IN_REVIEW`, with a `provider_url` |
| **What the user does** | Nothing else | Opens `provider_url` and completes the ID document upload and liveness check |
| **How you get the result** | In the same response | `KYC.COMPLETED` / `KYC.FAILED` webhook, or polling [Retrieve KYC Submission](/crypto-as-a-service/kyc-submissions/retrieve-kyc-submission.md) |
| **Integration effort** | Lower | Higher: redirect and asynchronous result |

You can always tell which flow ran from the response: a `provider_url` means the user still has to verify their identity.

## Where KYC fits in the flow

```
Create end user → KYC (approved) → trade, withdraw, open fiat accounts
```

1. [Create the end user](/crypto-as-a-service/end-user/create-end-user.md).
2. Get the fields required for your account's country with [KYC Requirements](/crypto-as-a-service/kyc-requirements/kyc-requirements.md).
3. Submit the KYC with [Create KYC Submission](/crypto-as-a-service/kyc-submissions/create-kyc-submission.md).
4. Once the KYC is approved, the user can [trade](/crypto-as-a-service/guides/trading-integration.md), [withdraw](/crypto-as-a-service/guides/deposits-and-withdrawals.md) and use [Banking as a Service](/crypto-as-a-service/guides/banking-as-a-service.md). An operation for a user whose KYC is not approved answers `20030`.

> [!WARNING]
>
> A user can have only one approved KYC. Submitting a new one for a user that is already approved answers `400` with code `20031`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.