> ## 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 model to use > How identity verification (KYC) works in the Ramps API and how to choose between the Ripio-hosted redirect and the partner-submitted API model. In production, every customer must complete **identity verification (KYC)** before they can operate. A customer's KYC status must be **`COMPLETED`** before you can create On-Ramp or Off-Ramp orders. In sandbox, Ripio can configure your account either to skip KYC for faster ramp validation, or to keep KYC enabled so you can simulate approval and rejection. See [KYC in sandbox](/ramps-api/sandbox/kyc-in-sandbox). There are two ways to run KYC. This page helps you pick the right one; each model has its own step-by-step page. ## The two models You send the user to Ripio's KYC platform via a redirect. Ripio collects the data and documents. Simplest to integrate. You collect the KYC fields in your own UI and submit them through the API. Document upload and liveness still happen in a Ripio-hosted step afterwards. Maximum control over the data-collection experience. ## Which model should you use? | | Ripio-hosted (redirect) | Partner-submitted (API) | | - | - | - | | **Who collects the data** | Ripio | You (the partner) | | **User experience** | User leaves your UI to Ripio's KYC page for the whole flow | Native in your UI for data entry, then redirected to Ripio's page for document upload and liveness | | **Integration effort** | Lower | Higher | | **Best for** | Getting live quickly | Custom, embedded onboarding | In **both** models the user is redirected to Ripio's own UI for document upload and liveness checks, which resolves that step with the identity provider inside a webview. The difference is **who collects the personal data beforehand** — not who runs the identity check itself. ## What Sumsub verifies, by country Whichever model you use, the document-upload and liveness step is run against Sumsub, and what it asks for depends on the customer's country: | Country | Identity document accepted | Selfie | | - | - | - | | Argentina | ID card, residence permit | Advanced liveness check | | Brazil | Driver's license, ID card, residence permit, passport | Advanced liveness check | | Mexico | ID card, residence permit, passport | Advanced liveness check | | Colombia | ID card, residence permit | Advanced liveness check | The selfie step is always an advanced liveness check in all four countries — there is no document-upload fallback for it. ## Email OTP verification If your account is configured for **Ripio KYC reuse via OTP**, every verification starts by confirming the customer owns their email with a one-time password (OTP) — this isn't an optional step reached for only in some cases, it's how starting a KYC always works for these accounts, for every customer. This step exists in **both** models — it's part of how KYC is opened, not something specific to one integration style. The difference is who calls it: * **Ripio-hosted (redirect)** — Ripio's own UI handles the OTP step for you. You don't call anything for it. * **Partner-submitted (API)** — you call it yourself: see [Start KYC](/ramps-api/kyc/start-kyc) and [Validate KYC OTP](/ramps-api/kyc/validate-kyc-otp) in [Partner-submitted KYC (API)](/ramps-api/kyc/kyc-via-api-overview). What happens after that confirmation depends on the customer: if they **already have an approved KYC with Ripio**, confirming the OTP approves them immediately — no document upload or liveness check needed. If they don't, you continue submitting their data as usual (directly, for the API model; inside Ripio's UI, for the redirect model). ## Shortcut: reuse a KYC from your own Sumsub account If your customers are **already verified in your own Sumsub account**, you can share that verification with Ripio instead of running a new one: you send a Sumsub share token when creating the KYC and, when both verifications are compatible, the customer skips the document upload and liveness check. Reuse isn't all-or-nothing, though — if something in that verification is outdated or fails Ripio's re-check (an expired document, for example), the customer is asked to redo just that part. It works on top of either model, and it needs setup on your Sumsub account plus an opt-in from the Ripio team before the first call. See [Reusable KYC (Sumsub share token)](/ramps-api/kyc/reusable-kyc). Ripio KYC reuse via OTP and Sumsub share-token reuse can both be enabled for the same account — they are not mutually exclusive. See [Reusable KYC (Sumsub share token)](/ramps-api/kyc/reusable-kyc) for how to combine them. ## Where KYC fits in the flow KYC happens **after** creating the customer and accepting the Terms & Conditions, and **before** creating any order: ``` Create customer → Accept T&C → KYC (must be COMPLETED) → [Brazilian accounts: investor profile] → quote → order ``` See the [On-Ramp](/ramps-api/guides/on-ramp-integration) and [Off-Ramp](/ramps-api/guides/off-ramp-integration) walkthroughs for the full sequence. The T\&C step gates the KYC submission itself, not only the orders: [Submit KYC Information](/ramps-api/kyc/submit-kyc-information) answers `20039` when the active Terms & Conditions have not been accepted. Since acceptance is per version, that also applies to a returning customer whose KYC you resubmit after a new version went live — see [Terms and Conditions](/ramps-api/terms-and-conditions/introduction). ## KYC statuses | Status | Meaning | | - | - | | `INCOMPLETE_USER_DATA` | Required information is still missing (or a pending step, such as OTP validation, hasn't been completed). Provide the missing data to continue. | | `IN_REVIEW` | Submitted and under review. | | `UPDATE_REQUIRED` | Some information must be corrected or updated before the KYC can be approved. | | `COMPLETED` | Approved — the customer can operate. | | `FAILED` | Rejected. | Instead of polling, you can subscribe to [KYC Events](/ramps-api/webhooks/kyc-events) to be notified when a customer's status changes. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.