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

# KYC-сценарий без кода в Didit: пошаговое видео

> Видеоурок Didit: как визуально собрать KYC-сценарий верификации с проверками, ветвлением, правилами риска, тестированием и публикацией в продакшн.

[Создайте сценарий верификации KYC без кода (полное руководство)](https://www.youtube.com/embed/7-nJ3JE20i4)

Полная расшифровка видео **Создайте сценарий верификации KYC без кода (полное руководство)** - видеоурок Didit Academy 3 из 10, 18:54. [Смотреть на YouTube](https://www.youtube.com/watch?v=7-nJ3JE20i4). Каждый абзац ведёт к точному моменту в видео.

> [!NOTE]
>
> Цены изменились 1 ноября 2026 года: 500 бесплатных проверок в месяц заменили на \$10 кредита в месяц для организаций, которые зарегистрировались с рабочим адресом электронной почты. В видео показаны прежние цены.

## Что такое сценарий

[00:03](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=3s) В этом видео мы с нуля создадим полный сценарий верификации, и не придётся писать ни одной строки кода. Сценарий по сути является рецептом верификации: какие проверки выполнить и в каком порядке. Обычно такими вещами занимаются ваши инженеры. Но в Didit вы строите сценарий сами, визуально. Вы видите, как меняется цена по мере работы, и публикуете сценарий, когда будете готовы.

[00:28](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=28s) Если хотите создать свой, зайдите на didit.me, зарегистрируйтесь бесплатно и соберите первый сценарий всего за несколько минут. Итак, начнём с того места, где живёт любой сценарий верификации, а именно с

## Список сценариев и их ID

[00:39](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=39s) списка сценариев под вкладкой Configure. Здесь находятся все сценарии, которые есть в этом аккаунте. Вы видите тип: KYC или KYB, simple или graph. Также видны все проверки и функции внутри каждого сценария. Можно увидеть и разброс цен: это показывает, сколько стоит пользователю, который прошёл только одну проверку и не завершил процесс, и сколько стоит тому, кто проходит весь сценарий целиком. У каждого сценария есть ссылка.

[01:09](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=69s) Можно добавить новую сессию вручную. Можно скопировать ID сценария. Можно дублировать, переименовать, архивировать, всё, что обычно нужно. А вот ваш ID сценария. Несколько версий одного сценария используют один и тот же ID. Поэтому, если вы обновите сценарий, ничего не нужно менять в коде или приложении. Проще всего думать о сценарии как о рецепте верификации: какие проверки выполнять, в каком порядке и какие правила соблюдать. Итак, есть два разных

## Простые и графовые сценарии

[01:40](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=100s) типа структуры, как я уже упоминал: simple и graph. Простой сценарий представляет собой одну проверку или несколько проверок без какого-либо ветвления. Никакой условной логики. Его быстро настроить, и он покрывает большинство случаев. Вы выбираете модули, и на этом всё. Если посмотреть на этот пример сценария, видно, что модули выбираются здесь, слева, и система расставит их по порядку. Теперь о

## Графовый сценарий с ветвлением

[02:05](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=125s) графовом сценарии: если открыть его, видно, что в конце есть ветвление. Так можно точнее направлять пользователя через процесс верификации. В этом сценарии, например, несколько точек ветвления. Можно добавлять вызовы webhook. В целом, при необходимости можно добавить сложности.

[02:30](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=150s) Также отмечу: KYB-сценарии выглядят точно так же, только проверки другие. Чтобы добавить проверку, заходим сюда. Можно взять одно из пользовательских действий или настроить фоновые проверки. Это те, которые пользователь не видит на фронтенде.

## Создание нового сценария из шаблона

[02:51](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=171s) нужно нажать кнопку создания нового сценария. Здесь есть несколько вариантов: KYC и KYB. Выберем KYC. Дальше вы видите simple и advanced, как я показывал раньше. Покажу оба варианта. Если выбрать simple, здесь множество шаблонов для самых разных отраслей, и для каждого видна стоимость. Есть возрастные ограничения, есть проверка электронной почты.

[03:19](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=199s) Есть биометрическая аутентификация, страхование, здравоохранение и многое другое. Теперь, например, если взять верификацию бизнеса и выбрать advanced, то есть графовую версию, здесь тоже много шаблонов, или рецептов, как их ещё можно назвать. Можно сразу настроить KYB для стран повышенного риска. Ничего не нужно перетаскивать: сценарий уже собран.

## Выбор проверки в каждом узле

[03:48](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=228s) каждый узел здесь содержит выпадающий список. Можно просто выбрать нужную проверку. Можно поменять её, как здесь, или выбрать проверку по реестру. Что угодно. Верификация личности, проверка живости, сравнение лиц, AML, подтверждение адреса. Все проверки, которые Didit предлагает для KYB и KYC, доступны внутри этих узлов. Если я хочу добавить ещё одну проверку, например AML-скрининг, добавляю её сюда. К вкладкам и правилам перейдём через минуту, но здесь видно, что я уже добавил AML-скрининг в этот сценарий. Если открыть графовый KYC-сценарий, большинство из них начинается с верификации личности. Это самая частая

## Внутри узла верификации личности

[04:33](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=273s) проверка. Вот узел верификации личности. Здесь 500 бесплатных проверок в месяц, то же самое для проверки живости и сравнения лиц. Эта верификация делает гораздо больше, чем просто считывает текст с карты. Она доказывает, что документ подлинный: проверяет элементы защиты, ищет признаки подделки, анализирует шрифты и макеты. Затем извлекает каждое поле: имя, дату рождения, номер документа, срок действия. Всё это делается с помощью OCR на любом языке для всех 14,000 с лишним поддерживаемых типов документов. Поэтому это никогда не просто текст. Сначала проверяется подлинность, а затем извлекаются данные. Итак, настроим один из этих модулей.

## Режимы проверки живости и их стоимость

[05:15](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=315s) Давайте я покажу: если перейти в модуль проверки живости, здесь есть несколько режимов. Пассивный режим определяет живость по селфи. Режим flashing подтверждает живость с помощью динамических световых паттернов для определения настоящих лиц пользователей. Режим 3D action подтверждает живость через действие: например, моргание или поворот головы. Для пассивной проверки живости в месяц предоставляется 500 бесплатных кредитов, после чего стоимость составляет 10 центов за проверку. Режимы flashing и 3D action стоят 15 центов за проверку. В бесплатном аккаунте бесплатных проверок нет. Теперь перейдём во вкладку «Правила».

## Правила: пороговые значения, дубликаты лиц, несколько лиц

[05:56](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=356s) Здесь определяется, является ли модуль обязательным или необязательным. Если открыть вкладку «Правила», там есть несколько вариантов настройки. Они позволяют настроить чувствительность проверки. Можно задать допустимый уровень: если оценка живости человека меньше 70, его отправят на проверку, и это значение можно изменить. То же самое относится к отклонению. Есть также настройка обнаружения дубликатов лиц: когда лицо пользователя совпадает с лицом из ранее одобренной сессии, нужно решить, что делать дальше. Можно одобрить, отправить на проверку или отклонить. Далее можно задать порог сходства для каждой этнической группы, то есть настроить чувствительность обнаружения дубликатов в зависимости от этнической принадлежности. Наконец, можно задать действие, которое выполняется, если на изображении для проверки живости найдено несколько лиц. Для оценки живости всегда используется самое крупное лицо. Эту настройку тоже можно задать здесь. Если перейти во вкладку

## Расширенные настройки и пороги качества

[06:56](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=416s) «Расширенные настройки», там есть несколько параметров. Здесь находятся режим конфиденциальности лица, максимальное количество попыток проверки живости (сколько раз пользователь может повторить проверку живости в рамках одной сессии верификации), порог качества лица. Если вы не уверены, что делает та или иная настройка, наведите курсор на кнопку с информацией. Качество лица определяется по чёткости изображения, разрешению и резкости.

[07:20](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=440s) Изображения низкого качества могут получиться из-за размытия, пикселизации или плохого освещения. Порог можно задать по оценке качества лица. Есть также порог яркости: можно задать допустимый диапазон яркости. Если яркость ниже нижней границы этого диапазона, пользователя можно отправить на проверку или отклонить. Наконец, если ни одно из этих правил не подходит под нужные настройки, можно создать собственные правила.

## Возвращаемые данные и GDPR

[07:47](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=467s) Во вкладке «Возвращаемые данные» можно выбрать точки данных, которые нужно исключить из результатов верификации, например для соответствия GDPR. Для каждого из этих модулей видна цена проверки, а вверху

## Как складывается стоимость сценария

[08:00](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=480s) отображается общая стоимость. Сейчас объясню подробнее, потому что каждый узел имеет свою цену, и общая стоимость каждого сценария, скорее всего, будет немного отличаться. Вы платите только за шаги, которые были фактически выполнены, и каждый шаг тарифицируется отдельно. Если заявитель прерывает проверку на полпути, оплачиваются только пройденные им шаги. Поэтому внизу видно диапазон от 20 до 43 центов. Это и есть диапазон стоимости: если заявитель проходит первый шаг и выходит, это будет стоить 20 центов. Если он полностью проходит сценарий верификации, это будет стоить 43 цента. Посередине показаны все модули, входящие в этот сценарий. Здесь видно, сколько кредитов доступно в месяц. Когда бесплатные кредиты закончатся, то есть когда будет выполнено 500 проверок, вы начнёте платить. Один из самых мощных модулей, которые можно добавить, вовсе не проверка с камерой. Это

## Проверка по базам данных государственных реестров

[09:05](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=545s) проверка по базам данных. Давайте добавим её. Это фоновая проверка, и сейчас посмотрим, что она делает. Проверка по базам данных подключается к официальным государственным реестрам и базам данных по всему миру. Она сверяет данные пользователя с этими официальными источниками и дополняет эти данные полями, которые хранятся в реестре. Можно выбрать, по каким реестрам и источникам выполнять проверку, и для каждой страны это настраивается здесь. У каждого сервиса своя цена. Например, внизу видны разные сервисы в Канаде, и у разных реестров цены, конечно, разные. Если нужно посмотреть конкретную страну, например Германию, можно увидеть доступные там проверки и выбрать нужные.

[09:59](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=599s) Проверку по базам данных можно запустить не только здесь, в панели управления: её можно вызвать напрямую через API Didit из вашего бэкенда. Как и для всех этих модулей, здесь есть «Правила», «Расширенные настройки» и «Возвращаемые данные». Правила тоже настраиваются здесь. Если нажать на частичное совпадение, будет видно, как выглядит полное совпадение, например когда полное имя и идентификационный номер совпадают с данными в реестре, а частичное совпадение может быть только по идентификационному номеру. Затем вы решаете, что означает частичное совпадение в вашем сценарии: отправить на проверку, отклонить или одобрить. Поэтому в этом сценарии есть ветвление. Мы

## AML-ветвление и условная логика

[10:36](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=636s) Можно сделать ветвление в зависимости от оценки AML-риска. AML означает противодействие отмыванию денег. Внизу мы видим, что ветвление для этой оценки уже настроено. Если оценка риска выше 70, можно просто отклонить. Нажмём сюда и увидим условную логику. Верно? Её можно настроить как угодно. У нас есть первая ветвь, вторая ветвь и все остальные случаи, а это значит, что сессия будет одобрена. Например, если кто-то попадает в эту группу, его направляют во вторую ветвь. Мы можем запросить у него дополнительную информацию, верно? Например, подтверждение адреса. Так, если пользователь представляет некоторый риск, мы можем запросить больше информации, которая поможет решить, одобрить этого человека или отклонить. Ещё один узел здесь называется статус. Он уже добавлен, но статусы можно добавить в конце сценария, чтобы определить итоговый результат. Итак, ещё один из

## Узел webhook

[11:40](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=700s) узлов, который можно включить в сценарий, это узел webhook. Сценарий может также обращаться к вашим собственным системам посреди верификации, для этого и нужен этот узел. Он может вызвать endpoint и получить данные обратно. Поэтому он ждёт ответа от webhook. Здесь вы видите POST-webhook. Есть payload в JSON, его можно изменить. Кроме того, можно отправлять разные payload. Это пары ключ-значение, которые сопоставляют поля вашей сессии с запросом, который вы отправляете. Возвращаемые поля становятся переменными для проверки в следующей ветви. Так вы объединяете проверки Didit с собственными данными о рисках в одном сценарии. И последнее: внизу можно добавить заголовки. Ещё пары ключ-значение. Здесь есть базовая аутентификация. Всё то, что вы ожидаете от вызова webhook. Didit проверяет

## Валидация графа и ошибки

[12:28](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=748s) граф на протяжении всей работы. Если узел настроен неправильно или путь сломан, система точно укажет, где проблема. Нажмём внизу. Видим, что в сценарии две ошибки. Также видим, что в первой ветви неполные правила. Система подскажет, что нужно исправить в сценарии. Пока ошибки не исправлены, опубликовать сценарий не получится. Например, если у меня новый сценарий и в нём есть ошибка, я не смогу его опубликовать. Так что помимо отдельных узлов

## Настройки сценария: повторные попытки, срок действия и URL обратного вызова

[12:58](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=778s) в сценарии есть вкладка «Настройки» вверху. Эти настройки применяются ко всему сценарию, а не к одной проверке. Здесь задаётся название сценария. Есть URL обратного вызова, это адрес, на который Didit перенаправляет пользователя после завершения сценария. Можно разрешить доступ с компьютера, если хотите, чтобы пользователи могли продолжить работу на компьютере. Можно изменить количество повторных попыток. Это число раз, которое пользователь может повторно пройти захват документа в рамках одной сессии верификации. Если предыдущая попытка не удалась, есть срок действия сессии: сколько времени незавершённая сессия остаётся действительной, прежде чем истечёт автоматически. Это применяется к вновь созданным сессиям. И есть окно повторных попыток: количество дней, в течение которых повторные попытки разрешены. Итак, с

## White label для сценария

[13:43](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=823s) внутри этого сценария можно перейти на вкладку Customizations, нажав кнопку вверху. White label встроен прямо в сценарий. На этой вкладке можно менять внешний вид верификации: цвета, брендинг, письмо, домен и всё остальное. На макете видно, как это будет выглядеть на мобильном устройстве и на компьютере.

[14:13](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=853s) Также можно проверить сценарий на разных языках. Если переключить его на французский, каждая проверка будет на французском. Если хотите, включите свой брендинг. Вот так. Можно выбрать тот, что мы настроили во вкладке Customizations, или отключить его. Можно посмотреть, что будет, если выбрать другой путь, и увидеть, что получит пользователь. Пользователь, конечно, не увидит модуль выбора пути, это просто чтобы представить следующий шаг, верно? Если пользователь получил отказ, мы увидим «верификация отклонена», «верификация на проверке» или что он верифицирован. Есть кнопка копирования ссылки

## Ссылка для общего доступа и когда её не использовать

[14:58](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=898s) вверху. Если скопировать её, открыть новую вкладку и перейти по ссылке, можно увидеть, что увидит пользователь. Иногда нужно просто передать кому-то сценарий, не написав ни строчки кода. Эта кнопка делает именно это. Она копирует готовый к отправке URL размещённой страницы этого сценария. Это удобно для быстрой проверки или ручной отправки, но это не рекомендуемый способ интеграции. Для продакшна создавайте сессию для каждого пользователя через SDK или API, передавая данные вашего вендора. Так вы получаете результаты в реальном времени через webhook и SDK. Ссылка подходит для тестов и мероприятий, а в продакшн вы отправляете именно сессию. Так

## История версий и откат

[15:41](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=941s) Вверху здесь находится история версий. Вы видите все версии сценария и можете восстановить предыдущие версии или просмотреть их. Если бы мы редактировали этот сценарий, изменения сохранялись бы как черновик над списком опубликованных версий. Важно то, что каждая новая опубликованная версия сохраняет тот же ID сценария. Ваш бэкенд продолжает обращаться к этому ID, а запросы автоматически перенаправляются на самую новую версию сценария, потому что история отслеживается. Так вы можете вносить изменения уверенно и при необходимости откатиться к предыдущим версиям. Например, этот сценарий только что создан. Вы видите, что он в режиме черновика. Если вы внесёте в сценарий любые изменения, сценарий перейдёт в режим черновика, и его нужно будет опубликовать. Итак, можно

## Публикация сценария

[16:24](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=984s) нажать «Опубликовать». Сценарий начинает работать только после публикации. Система проверит граф на наличие ошибок. Затем вы можете скопировать ссылку, и сценарий готов к работе. Теперь посмотрим на интеграцию.

## Интеграция: SDK, API-ключ и промпт для настройки

[16:37](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=997s) Интегрировать сценарий можно несколькими способами. Выберите нужный SDK, например React Native, iOS или React / Next.js, затем выберите сценарий. В данном случае это проверка страны высокого риска. Выберите API-ключ. Для разных сценариев или интеграций можно использовать разные API-ключи, как вам удобно. Также можно выбрать webhook. Если вы хотите получать уведомления о решениях, укажите его здесь. Проще всего интегрировать сценарий, скопировав промпт и вставив его в claw code или codeex.

[17:12](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=1032s) Этот промпт интегрирует сценарий в ваше приложение. Даже если Didit ещё не подключён к вашему приложению, промпт даст всё необходимое, чтобы этот сценарий заработал в вашем приложении. Более того, можно обойтись и без этого. Достаточно

## Создание сценариев с помощью MCP-сервера

[17:27](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=1047s) установить MCP-сервер Didit. Просто опишите процесс обычным языком, и он создаст сценарий и автоматически интегрирует его в ваше приложение. Скажите, что нужно сделать, и он выполнит задачу. Настройку MCP мы разберём в отдельном видео. Если коротко, MCP (Model Context Protocol) позволяет создавать сценарии с помощью Didit на естественном языке в таких инструментах, как Claude Code, Cursor, Codex и других. Теперь быстро перейдём к настройке внешнего вида.

[17:57](https://www.youtube.com/watch?v=7-nJ3JE20i4\&t=1077s) Здесь указываются публичное название и URL политики конфиденциальности. Далее идёт брендинг, где можно изменить цвета. Также можно автоматически загрузить логотипы и цвета с вашего сайта, это может быть очень удобно и просто. Ниже можно загрузить логотипы. Вы видите, что цвета я уже настроил. Чтобы посмотреть, как всё будет выглядеть с этими цветами, достаточно переключить этот тумблер, и брендинг White label будет применён в сценарии верификации. Сейчас я его выключу. Можно настроить персонализированное письмо. Для этого нужно заполнить эти данные. Затем, когда вы перейдёте к верификации, можно получить DNS-записи и подключить их к вашему домену. То же самое можно сделать, если вы хотите использовать поддомен. Благодаря этому весь сценарий полностью размещается под вашим брендом и на вашем домене. Таким образом, пользователи проходят верификацию без лишних шагов.


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