Where do I find the scenario identifier?

In the general options of the scenario, as Scenario ID. It is the value that you pass to the API and the Web SDK.

Can I create a scenario through the API?

No. Scenarios are created and edited in the dashboard. The API works with the identifier of a scenario that already exists.

What do I need before the Web SDK settings are available?

At least one allowed domain. Until a domain is added, the Web SDK settings in the scenario are unavailable.

Configure a KYC scenario

A scenario is the recipe of a verification: the steps a user goes through, the checks that run, and the rules that decide the result. This page follows the editor in the order in which you meet it. For the reference of every tab, see KYC and AML in the dashboard.

Before you start

The right to edit scenarios. The KYC Editor tab is visible to users who may edit scenarios. The permissions are in the KYC schemes group of the role. See access rights.
An allowed domain, if you will use the widget on your own site. See allowed domains.
A decision on what the flow is for. A sign-up check, a check before a payout and a form at registration need different scenarios. Keep one scenario for each flow that differs in steps, documents or rules.

Create the scenario

Open KYC/AML, then the KYC Editor tab.
Click the button that creates a scenario, and choose a template or start from scratch. The templates are the passport, the passport with a selfie holding the passport, and the passport with liveness.
Work through the tabs below: Verification steps, General options, Callback options, Web SDK Settings and Integration Docs.
Save. A scenario needs a name and at least one step to be saved.

If there are no scenarios yet, the lists in the dashboard contain only the entry that leads to creating one.

Tab one: Verification steps

Steps run in the order set. For each step, choose what the user uploads and switch on the checks you need.

Step	What you choose
Document	The document type and the allowed countries. The checks you can switch on depend on the document type. They include whether the document is fully visible, the machine readable zone, a photo taken from a screen, a photocopy or a printout, a graphical editor, corrected fields, logical mismatches, a pasted-in photo, a damaged document, and signatures and stamps. Database checks are listed here if they are available to your account.
Selfie	A selfie, or a selfie with the document from the previous step. Checks: the image is not edited or taken from a screen, the age and gender of the user by face, a deepfake check, and blocking sessions with other faces in the frame.
Liveness	Checks that a live person is in front of the camera. Recording a video of the check is enabled separately.
Questionnaire	The fields of a form. The questionnaire step is a separate scenario. See two-stage questionnaire, then KYC.

Add only the steps the flow needs. An extra step is extra friction for the user and extra personal data in your records.

Tab two: General options

Option	What it does	When to change it
Scenario ID	The identifier that you pass to the API and the Web SDK.	Copy it; do not change it.
Secret key	Encrypts notifications to your server and the client key. The Check button opens a window where a client key can be encrypted or decrypted.	Keep it on your server. Use Check to test before your code is ready.
Mobile redirect addresses	Where the widget goes on success and on error, for a check that was opened with a direct link on a phone.	When the check starts from an app. See mobile apps and WebView.
Client faces list	A list, from your person lists, that verified customers are added to for later search.	When you search for returning customers.
Faces black list	If the face of the user matches the list, the session is blocked.	When you keep a blocklist.
Critical errors before blocking	The number of critical errors before the session is blocked. It protects against brute-forcing forged images. Zero means no limit.	For flows exposed to repeated attempts.
Session data retention in days	How long session data is kept. Zero means indefinitely.	Set it on purpose, with your counsel.
Session TTL	The time the user has to complete the session, from minutes up to a year.	Short for a check that protects one action, longer for an invitation link.
Allowed age	A range taken from the date of birth in the document.	For age-restricted services.
Document step flags	For example, blocking the session when two different documents are detected in one step.	For flows where one person must present one document.

Tab three: Callback options

Enter the callback URL of your backend and use the test request to check that the address is reachable. The flags are: encrypt the POST body with the secret key, omit identity fields, notify only when the session is finalized, and send database checks. What the option that omits identity fields leaves out differs per event. See webhooks and receiving webhooks.

Tab four: Web SDK Settings

The look of the widget for this scenario: the color theme, a preview in mobile and desktop modes, the logo for the dark and the light theme, links to your terms of use and privacy policy, the permission to use a desktop camera, the colors, the texts of the screens and the languages. See Web SDK parameters.

Tab five: Integration Docs

Ready-made examples of connecting the widget for this scenario, and examples of client key encryption. See also the integration guides.

Test the scenario

Test before any user sees it.

Check the key. Open the Check window in the general options, enter a test raw client key and confirm that you get an encrypted value.
Send the test callback. Use the test request in the callback options. If it does not arrive, fix the address first.
Create a session by hand. On the logs or reports tab, click +, choose the scenario and a new session of it appears.
Go through it yourself. Click KYC SDK to open the widget in the dashboard for the selected scenario.
Read the card. Look at each tab of the session card: the document fields and checks, the selfie, the faces result, the liveness result, and the JSON of the full result.

Three worked set-ups

These use only the options above.

A sign-up check. Document step for the countries you serve, selfie step with the checks you want, liveness step. A session lifetime long enough for the user to finish in one sitting. A callback to your server with identity fields omitted, so that your backend fetches the result by the session identifier. Retention set to your policy.

A check before a payout. The same steps, with the faces black list selected, and a short session lifetime. Keep it apart from the sign-up scenario, so that you can tighten one without touching the other. See re-authentication before payments and withdrawals.

A form at registration. A scenario whose only step is the questionnaire, with one-time links on the KYC Links tab. The full check is a second scenario. See two-stage questionnaire, then KYC.

Change a scenario that is in use

A scenario can be edited, duplicated, copied to the clipboard, have its identifier copied, or be deleted. Deleted scenarios are shown in a separate list. Before a large change, duplicate the scenario and test the copy, then switch your integration to the new identifier when you are satisfied.

Common mistakes

Putting the secret key in browser code. It lives on your server only.
Passing the raw client key to the widget. The widget needs the encrypted value.
Reusing the sign-up scenario for every flow. Rules that suit a sign-up can be wrong for a payout.
Leaving retention at zero without meaning to. Zero means indefinitely.