---
title: KYC
description: A challenge that proves a real person is behind an account, with a live selfie or a government ID matched to a live selfie. How the levels differ, what Rupt keeps, and how policies use the result.
---

# KYC

KYC is a [challenge](/docs/v3/concepts/challenges) type. Where the other challenges prove that someone controls an email address or a phone number, KYC proves that a real, present person is behind the account, and optionally that they match the photo on a government ID.

It runs like every other challenge: a [policy](/docs/v3/concepts/policies) returns the `challenge` verdict with a KYC config, the user is sent to the hosted challenge page, and completion is recorded server-side. Passing stamps `identity_verified_at` on the user, so later policies can branch on the `is_identity_verified` check.

## Levels

Each KYC config picks one level.

- **Selfie liveness**: the user takes a short selfie in the page. A liveness check confirms a live human is in front of the camera, not a photo, a screen or a mask. Nothing else is asked for. This is the light step-up for trial abuse, seat sharing and bot signups.
- **ID document and selfie**: the user photographs a government-issued photo ID, then takes the same selfie. The face from the selfie is matched against the portrait on the document. For US driver's licenses and passports, Rupt also reads the expiration date and refuses expired documents.

On a desktop browser, the document level shows a QR code so the user can finish on their phone, where the camera is better suited to photographing an ID. The desktop page follows along and moves on once the phone is done.

## What Rupt keeps

Rupt records the decision and, at the document level, the fields it read.

- Consent: when it was accepted, which text version, and from which IP.
- The scores that decided the outcome, the document type when it could be read, and the reason for any rejection.
- On success, `identity_verified_at` and the level on the user.
- At the document level, the fields read off the document, each encrypted at rest, keyed by the document number. The user page in the dashboard shows them, together with every other account in your project that verified with the same document.

Rupt stores no image and no face template. It holds the document photo only long enough to complete the selfie step, then deletes it, and the comparison consumes the selfie in the same request that reads it. There is no face search across users.

## Attempts and outcomes

A user gets three attempts per challenge. A rejected document, a weak liveness result or a face that does not match the document each spend one. A lapsed camera session or an expired document upload does not. After the third rejection the challenge is `failed`, and a `challenge.failed` webhook fires with the reason.

While the user is inside the flow the challenge status is `in_progress`. See the [status lifecycle](/docs/v3/concepts/challenges#status-lifecycle).

## Where it fits

KYC is the strongest step-up Rupt offers and the most friction, so it belongs behind conditions that already point at a problem: a high [linked accounts](/docs/v3/concepts/linked-accounts) risk, a suspicious signup, a payout or a sensitive action on a custom event. Use `is_identity_verified` to skip it for users who already passed.

Rupt's KYC verifies presence and a document match. It is not sanctions or PEP screening, and it does not monitor transactions.
