---
title: KYC verification
---

# KYC verification

Some accounts need a real person behind them: a seller before their first payout, an account that keeps tripping the multi-accounting checks, or anyone about to take a sensitive action. This guide puts a KYC challenge in front of them and lets everyone else through.

## Step 1: Set up login and signup protection

Before anything else here, set up [Signup protection](/docs/v3/fundamentals/signup-protection) and [Login protection](/docs/v3/fundamentals/login-protection). They're the basis this builds on, and without them the policies below can be bypassed. With those in place, the rest of this guide covers the policies that ask for an identity check only when it is worth the friction.

## Step 2: Create the KYC challenge

In your [challenge configs](https://app.rupt.dev/settings/challenge-configs), create a config of type **KYC** and pick a level:

- **Selfie liveness** when you want proof of a live person and nothing more.
- **ID document and selfie** when the person has to match a government ID.

Review the consent text on the start screen. It names you as the party the check is for, and your users must accept it before the camera opens.

## Step 3: Add the policies

A policy has a trigger (the event it runs on) and a verdict. Add these in your [policies dashboard](https://app.rupt.dev/policies):

| Policy                   | Trigger             | Conditions                                                      | Verdict                    |
| ------------------------ | ------------------- | --------------------------------------------------------------- | -------------------------- |
| Verify before payout     | your `payout` event | `is_identity_verified` is false                                 | Challenge (KYC config)     |
| Verify repeat offenders  | `signup`            | `fingerprint_user_count` is over your limit and `is_identity_verified` is false | Challenge (KYC config) |

The first policy runs on a [custom event](/docs/v3/concepts/actions) you evaluate right before the sensitive action. The second reuses the linked accounts signal from [Multi-accounting prevention](/docs/v3/guides/multi-accounting-prevention), so a person who has already opened several accounts on one device has to prove who they are before opening another.

Both policies include `is_identity_verified` is false, so a user who passed once is not asked again. Keep KYC out of the plain login and signup paths for everyone else: it is the strongest step-up Rupt has and the most friction.

## Step 4: Honor the result

Hold the action until the challenge status is `completed`, the same way you would for any challenge. Read it with [Retrieve a challenge](/api/v3/challenges/retrieve-a-challenge) or wait for the [challenge completed](/api/v3/webhooks/challenge-completed) webhook. A `challenge.failed` webhook means the user ran out of attempts, and the `kyc.reasons` on it says why.

## Related

- [KYC](/docs/v3/concepts/kyc): the levels, what Rupt keeps, and what it does not.
- [Challenges](/docs/v3/concepts/challenges): the status lifecycle every challenge follows.
- [Multi-accounting prevention](/docs/v3/guides/multi-accounting-prevention): the device and phone limits this builds on.