Конструктор сценариев KYC без кода

Orchestrated Workflows от Didit — самый мощный и гибкий способ проектировать и запускать комплексные многошаговые сценарии верификации личности. Этот урок Didit Academy показывает, как создать сценарий верификации в реальной консоли: от шаблона до опубликованного сценария. Вы выбираете проверки на каждом узле, настраиваете правила и пороги, ветвление AML, узлы webhook и откат к предыдущей версии. Этот путь интеграции позволяет использовать все возможности платформы Didit V2 и создавать сложные последовательности верификации с помощью визуального конструктора без кода. Логику вы задаёте один раз в Business Console, а Didit берёт на себя весь пользовательский интерфейс, управление состояниями и условные шаги. Выбирайте этот путь, если вам нужно полное сквозное решение для онбординга пользователей (KYC), проверки возраста или повторной аутентификации, и вы хотите запуститься быстро с минимальной разработкой, сохранив максимальный контроль над процессом.

​

Методы подтверждения личности по странам

В разделе Верификация личности откройте Страны и разрешённые методы подтверждения личности, чтобы настроить съёмку документов, проверку без документа и цифровые кошельки удостоверений личности для каждой страны. В разделе Дополнительные настройки находятся подтипы документов, количество попыток проверки и резервные правила. Проверка без документа использует цены сервиса «Проверка по базам данных» вашей организации. Каждая завершённая попытка тарифицируется отдельно, включая частичные совпадения и случаи без совпадений: две завершённые попытки означают два списания. Ошибки формата и сбои провайдера, которые не возвращают ответ, не тарифицируются. Если в рамках одной попытки отвечают несколько сервисов баз данных, их применимые цены складываются. По умолчанию действует одна попытка до перехода к резервному варианту, это значение можно изменить от одного до пяти. Съёмка документа оплачивается дополнительно, если завершённая проверка переходит к документам. В приложениях в продакшне можно включать только те кошельки, которые доступны для продакшна. Кошельки, запуск которых ещё не состоялся, остаются отключёнными. В приложениях песочницы можно протестировать любой кошелёк из каталога с имитированными результатами. Доступность в песочнице не означает доступность в продакшне. Сценарии сбоев проверки и кошельков см. в разделе Тестирование в песочнице.

​

Версионирование сценариев

Сценарии поддерживают версионирование по схеме черновик/публикация. Это значит, что вы можете безопасно дорабатывать сценарий, не затрагивая активные сессии:

• Черновики можно полностью редактировать: добавлять, удалять и перестраивать узлы
• Публикация черновика создаёт неизменяемую версию, которую будут использовать новые сессии
• Предыдущие версии сохраняются, поэтому вы можете посмотреть точную конфигурацию, использованную в любой прошлой сессии
• Сессии всегда ссылаются на конкретную версию, с которой были созданы, что обеспечивает согласованность даже после публикации обновлений

Чтобы внести изменения в опубликованный сценарий, создайте новый черновик на основе опубликованной версии, отредактируйте его и опубликуйте, когда будете готовы. История версий доступна через Management API.

---

​

Два способа создания сценариев

Didit предлагает два разных подхода к созданию сценариев верификации, чтобы вы могли выбрать подходящий уровень сложности:

​

1. Простой режим: конструктор на основе шаблонов

Простой режим подходит для быстрого старта. Выберите готовый шаблон, включите или отключите нужные функции, и можно запускать. Подходит для:

• Быстрой настройки и развёртывания
• Стандартных сценариев верификации
• Команд, которые впервые работают с верификацией личности
• Задач, которые укладываются в типовые схемы

Как это работает:

1. Выберите шаблон сценария (KYC, проверка возраста и т. д.)
2. Включите или отключите функции (проверка живости, сравнение лиц, AML и т. д.)
3. Настройте базовые параметры каждой функции
4. Опубликуйте сценарий и начните верификацию

---

​

2. Расширенный режим: визуальный конструктор графа

Расширенный режим раскрывает всю мощь механизма оркестрации Didit. Создавайте сложные условные сценарии верификации в визуальном редакторе графа: перетаскивайте узлы, добавляйте ветвления и собственную логику. Подходит для:

• Сложных сценариев с несколькими путями прохождения
• Условной логики на основе данных пользователя или результатов верификации
• Собственных бизнес-правил и ветвлений
• Требований к комплаенсу корпоративного уровня

Ключевые возможности:

• Визуальный редактор узлов: перетаскивайте, соединяйте и располагайте узлы на бесконечном холсте
• Умные соединения: потяните от точки узла в пустое место, чтобы сразу создать и соединить новый узел
• Условные ветви: направляйте пользователей по извлечённым данным, статусу верификации, стране, типу документа, подтипу документа, дате выдачи, возрасту, путям в JSON-ответе webhook или по собственным правилам
• Автоматизация действий: добавляйте теги, задавайте метаданные или направляйте на ручную проверку в зависимости от результатов сценария
• Сочетания клавиш: отмена (Ctrl/Cmd+Z), повтор (Ctrl/Cmd+Shift+Z), удаление (Delete/Backspace)
• Масштабирование и перемещение: прокручивайте колесо мыши для масштабирования и перетаскивайте холст для перемещения по сложным сценариям

​

Типы узлов конструктора графа

​

Категории функций узлов

Функции с взаимодействием пользователя (могут запускать сценарий):

• Верификация личности (OCR)
• Проверка живости
• Сравнение лиц
• Оценка возраста
• Проверка телефона
• Проверка электронной почты
• Анкета
• Подтверждение адреса
• Document AI
• NFC / ePassport

Функции только на бэкенде (выполняются автоматически, без участия пользователя):

• AML-скрининг (перед ним нужен шаг Верификация личности, реестр KYB или Document AI; см. Проверяемый субъект)
• Проверка по базам данных (требует сначала OCR)
• Анализ устройства и IP

Примечание: функции только на бэкенде отмечены специальным индикатором в конструкторе и выполняются автоматически, без участия пользователя, как только их зависимости выполнены.

Первая вкладка настроек каждого узла функции начинается с элемента управления Движок верификации: выполнить проверку собственным движком Didit или переключить её на стороннего провайдера, которого вы подключили в Маркетплейсе. Если провайдер недоступен, проверка автоматически переходит к Didit.

​

Проверяемый субъект

AML-скрининг обычно определяет проверяемое лицо по предыдущему шагу: человека, данные которого шаг Верификация личности извлёк из документа, или компанию, данные о которой вернул шаг KYB Registry. В некоторых сценариях нет ни того, ни другого. Сценарий, построенный полностью на Document AI (нестандартизированные документы, например налоговая справка или нотариально заверенный учредительный документ), уже содержит имя, дату рождения, номер документа и страну, но под вашими собственными ключами полей. На вкладке Дополнительно узла AML вы указываете источники данных для скрининга с помощью этих ключей:

• Тип субъекта: проверить физическое лицо или компанию, указанную в загруженном документе. Узел компании ищет записи о компаниях, а не о людях.
• Источники полей: сопоставьте каждый из четырёх входных данных скрининга (имя, дата рождения, страна, номер документа) с полем Document AI, ответом на анкету или значением, которое вы передаёте при создании сессии (expected_details / metadata). Поле Document AI, которое вы уже назвали full_name, подхватывается автоматически.
• Неполные данные проверки: что произойдёт, если скрининг выполняется на основе неполных идентификационных данных. По умолчанию выполняется ручная проверка. Выбирайте Без действий только тогда, когда сценарий намеренно содержит только имя.

Два момента стоит знать, прежде чем на это полагаться. Если в сценарии нет шага Верификация личности или KYB Registry, имя обязательно: сценарий нельзя опубликовать, пока оно не заполнено, потому что поиска без имени не существует. Точность AML напрямую зависит от того, сколько идентификаторов вы передаёте. Проверка только по имени и даёт большое число ложных срабатываний, на которые жалуются проверяющие, поэтому передавайте дату рождения и страну всякий раз, когда они указаны в документе.

​

Как условия ветвей считывают данные сессии

Какую запись читает условие. Условие ветви привязано к узлу функции, из которого оно было построено, и читает результат этого узла. Если один узел создал больше одной записи, условие читает самую последнюю. Это особенно важно для Анализ устройства и IP: Didit записывает одно наблюдение на каждое устройство и IP-адрес, с которых открывается сессия. Поэтому пользователь, который сменил телефон или сеть в ходе сессии, оставляет на одном узле несколько записей. Правило вида IP COUNTRY is in [...] тогда вычисляется по последнему наблюдению, то есть по той же записи, которая показана первой на панели Анализ устройства и IP в сессии и в массиве ip_analyses в payload решения. Сессии с более чем одним наблюдением также получают предупреждение MULTIPLE_DEVICES_IN_SESSION. Это сигнал проверить полный список, а не только результат ветви. Значения стран. Условия по стране сопоставляются по самой стране, а не по её обозначению. Выбирайте страны с помощью средства выбора полей, и Didit нормализует обе стороны сравнения. Поэтому правило, записанное в ISO 3166-1 alpha-3 (UKR), всё равно совпадает со значением, полученным в alpha-2 (UA). Отсутствующие значения, пустые значения и отрицательные сравнения. Поле без значения вовсе (документ его не содержит, ключ метаданных не был передан, функция не выполнялась) совпадает только с is empty и equals not_defined. Любое другое сравнение (equals, contains, greater than, а также not equals и not in) не совпадает, и узел ветвления переходит к следующей ветви. Поле, содержащее пустую строку, является значением, а не отсутствующим полем. Сессия, созданная с "metadata": {"credential_state": ""}, не проходит metadata.credential_state equals IL, но проходит not equals IL, not in [IL, MA, NJ] и equals "" (is empty совпадает в обоих случаях). Поэтому ветвь, которая одобряет по отрицательному сравнению, одобрит сессию, у которой состояние было передано пустым, тогда как та же сессия без ключа пойдёт по запасной ветви. Если вы строите маршрутизацию по not equals или not in, добавьте metadata.<key> is not empty в ту же ветвь (логика И), чтобы оба случая заканчивались там, где должно заканчиваться отсутствующее значение. Ветви проверяются по порядку, и побеждает первое совпадение. Запасная ветвь (ветвь без условий) выбирается только тогда, когда ни одна другая ветвь не совпала, поэтому дайте каждому узлу ветвления запасную ветвь, которая завершается там, где вы хотите, чтобы заканчивалось неожиданное значение. Сессия, которая попадает на На проверке без предупреждения по какой-либо функции, была направлена туда узлом статуса в графе, а не проверкой. Обычная причина такого поведения в том, что сработала запасная ветвь узла ветвления. Метаданные сессии. Значения, которые вы передаёте в metadata при создании сессии, доступны каждой ветви как metadata.<key> и могут сравниваться с фиксированным значением или с другим полем сессии (например, metadata.min_age <= Age). Числа сравниваются как числа, поэтому 18 и "18" ведут себя одинаково. Песочница / тестовый режим. Условия ветвей, метаданные и узлы статуса работают в песочнице точно так же, как в продакшне. Песочница никогда сама по себе не переводит сессию на проверку. Разница в документе: сессия в песочнице несёт выдуманный документ без штата или региона США, поэтому условия Region там не могут совпасть. Как тестировать потоки, зависящие от штата, см. в что не содержит выдуманный документ. Повторные отправки. Узлы ветвления оцениваются при каждой попытке, включая повторную отправку. Когда вы возвращаете сессию на определённые шаги, ветви и действия, расположенные между этими шагами, выполняются снова по мере того, как пользователь их повторно проходит, на данных новой попытки. Пользователь, который переехал в ограниченную юрисдикцию между попытками, направляется той ветвью, которая её покрывает. Ветвь, которая завершается результатом «Отклонена», завершает повторно отправленную сессию именно там. Как понять, какую ветвь выбрала сессия. Каждое решение о ветвлении, которое сценарий принимает во время выполнения сессии, и каждый узел результата, до которого она доходит, записываются в журнал событий сессии (детали сессии в консоли > Events и GET /v3/session/{id}/decision/?include=events). Строка Маршрутизация сценария называет узел ветвления, совпавшее условие и узел, до которого продолжилась сессия. Либо она сообщает, что ни одно условие не совпало, и тогда была выбрана запасная связь узла. Строка Результат сценария называет узел статуса, который установил статус сессии. Когда сценарий отправляет сессию на На проверке без какой-либо функции с предупреждением, эти строки показывают путь, по которому она прошла, включая любую запасную связь и узел результата, к которому та привела. Последующие ручные решения не переписывают эти события сценария. Одна из возможных причин: отсутствующие входные данные. Условия, требующие наличия значения metadata.*, не совпадают, если ключ не был передан при создании сессии. Условия, которые явно проверяют отсутствие входных данных, например is_empty или equals с not_defined, могут совпасть с тем же отсутствующим ключом. Запасная связь выбирается только тогда, когда ни одна ветвь не совпала, включая любую else-ветвь, и ведёт к узлу, подключённому к выходу по умолчанию. Payload событий см. в событиях сессии.

---

​

Шаблоны сценариев: отправная точка

Рассматривайте шаблоны не как жёсткие типы, а как готовые к использованию отправные точки, созданные для типовых задач. В простом режиме они готовы к работе сразу. В расширенном режиме они служат основой, которую можно глубоко настроить.

​

Доступные шаблоны

​

1. Сценарий KYC

Комплексное решение для онбординга новых пользователей и соблюдения полного соответствия требованиям KYC.

• Начинается с: базовой верификации документа, удостоверяющего личность.
• Часто добавляемые функции:
  • [+] Проверка живости: убедитесь, что пользователь физически присутствует, и предотвратите спуфинг.
  • [+] Сравнение лиц 1:1: биометрически сравните селфи пользователя с фотографией в документе.
  • [+] AML-скрининг: проверяйте пользователей по глобальным санкционным спискам, спискам PEP и спискам негативных публикаций в СМИ.
  • [+] NFC-верификация: добавьте уровень безопасности, сопоставимый с государственными стандартами, считывая чипы электронных паспортов и электронных удостоверений личности.
  • [+] Подтверждение адреса (PoA): проверьте адрес проживания пользователя.
  • [+] Проверка телефона: подтвердите принадлежность номера телефона как дополнительный фактор.
  • [+] Проверка электронной почты: подтвердите принадлежность адреса электронной почты как дополнительный фактор.
  • [+] Проверка по базам данных: сверяйте данные с официальными государственными и кредитными базами данных.
  • [+] Анкета: собирайте структурированные аттестации и подтверждающие документы через настраиваемые формы.
  • [+] Анализ устройства и IP: анализируйте риск, связанный с местоположением и подключением.

---

​

2. Сценарий адаптивной верификации возраста

Сценарий с минимумом действий и защитой конфиденциальности для сервисов с возрастными ограничениями.

• Начинается с: оценки возраста по селфи.
• Ключевая логика:
  • Если оценочный возраст явно выше вашего порога (например, оценка 25+ для сервиса 18+), пользователь проходит проверку мгновенно.
  • Если оценка ниже порога или находится в «буферной зоне» (например, оценка 16-20), вы можете настроить сценарий так, чтобы он автоматически переходил к полной верификации личности для подтверждения точной даты рождения.
• Часто добавляемые функции:
  • [+] Анализ устройства и IP: ограничивайте доступ по географическому местоположению.

---

​

3. Сценарий биометрической аутентификации

Быстрый и безопасный способ повторной верификации возвращающихся пользователей без повторного запроса документов.

• Начинается с: проверки живости, чтобы подтвердить присутствие пользователя.
• Основная логика:
  • Система сравнивает новое селфи, сделанное в рамках проверки живости, с доверенным биометрическим шаблоном из первоначальной одобренной верификации KYC пользователя.
  • Если у пользователя уже есть сохранённое лицо в рамках того же vendor_data (одобренное лицо из проверки живости, фотография из электронного паспорта, портрет из документа, удостоверяющего личность, или лицо из зарегистрированного профиля), вы можете не передавать portrait_image при создании сессии: Didit автоматически использует сохранённое лицо. В противном случае передайте portrait_image (изображение в кодировке Base64, максимум 2 МБ). Если не передать ни одного из них, создание сессии завершится ошибкой с кодом 400.
• Часто добавляемые функции:
  • [+] Проверка телефона: привяжите адрес к подтверждённому номеру телефона.
  • [+] Проверка электронной почты: подтвердите принадлежность адреса электронной почты как дополнительный фактор.
  • [+] Анализ устройства и IP: отмечайте подозрительные попытки входа с новых местоположений.

---

​

4. Сценарий верификации адреса

Отдельный сценарий для случаев, когда основным требованием является подтверждение адреса (PoA).

• Начинается с: отправки пользователем документа, подтверждающего адрес (например, счёта за коммунальные услуги или выписки из банка).
• Основная логика: наш ИИ извлекает имя и адрес из документа и проверяет их.
• Часто добавляемые функции:
  • [+] Проверка телефона: привяжите адрес к подтверждённому номеру телефона.
  • [+] Проверка электронной почты: подтвердите принадлежность адреса электронной почты как дополнительный фактор.
  • [+] Анализ устройства и IP: сравните адрес из документа с текущим местоположением пользователя для дополнительной уверенности.

---

​

5. Сценарий верификации через анкету

Сфокусированный сценарий, когда основная цель заключается в сборе структурированных аттестаций и подтверждающих документов через настраиваемые формы.

• Начинается с: анкеты.
• Основная логика: система показывает настроенную вами анкету (разделы, переведённое содержимое, обязательные поля и загружаемые файлы).
• Часто добавляемые функции:
  • [+] Анализ устройства и IP: добавляйте к отправкам анкет контекст местоположения и подключения.

Полная настройка Каждую функцию в сценарии можно дополнительно настроить с помощью конкретных параметров, чтобы они соответствовали вашим требованиям. Изучите настройки каждой проверки в конструкторе.

---

​

Правила на основе семейного положения

В расширенном режиме вы можете использовать поле OCR kyc.marital_status в условных ветвях и пользовательских правилах статуса. Выберите значение в селекторе полей, чтобы правило использовало поддерживаемое перечисление, а не текст, введённый вручную. Если документ не содержит сведений о семейном положении, значение будет пустым, и применится ваша резервная ветвь. Помощник по сценариям также может создавать и настраивать шаги Проверка по базам данных одним действием. Когда вы просите его добавить эту проверку, укажите нужные страны: консоль сама подбирает поддерживаемый сервис для каждой страны и показывает сохранённую конфигурацию на холсте.

---

​

Сравнение режимов Simple и Advanced

---

​

Процесс интеграции

Интеграция Orchestrated Workflow проста. Ваш сервер создаёт сессию в Didit, получает уникальный URL и перенаправляет пользователя по этому адресу. Дальше всё обрабатывает Didit, а о результатах он уведомляет ваш сервер через webhook.

---

​

Типичные сценарии использования

Вариант использования	Рекомендуемый шаблон	Рекомендуемый режим	Предлагаемые функции
Базовая верификация личности	KYC	Simple	Проверка живости, Сравнение лиц
Онбординг с повышенными требованиями безопасности	KYC	Advanced	NFC-верификация, Проверка живости, Сравнение лиц, AML, Проверка телефона
Ограничение контента и услуг по возрасту	Adaptive Age Verification	Simple	Верификация личности как резервный вариант
Аутентификация вернувшихся пользователей	Биометрическая аутентификация	Simple	Анализ устройства и IP
Проверка адреса	Подтверждение адреса	Simple	Проверка телефона
Онбординг в сфере финансовых услуг	KYC	Advanced	Проверка живости, Сравнение лиц, Подтверждение адреса, AML, Проверка по базам данных
Соблюдение региональных требований	KYC	Advanced	Условная маршрутизация по стране, разные проверки для разных регионов
Верификация на основе риска	KYC	Advanced	Условные ветви на основе оценок риска, пути эскалации

---

​

Начало работы

1. Впервые в Didit? Начните с Simple Mode и готового шаблона
2. Нужна настройка? Переключитесь на Advanced Mode, чтобы добавить условную логику

Свяжитесь с нашим отделом продаж, чтобы обсудить индивидуальные конфигурации сценариев или получить рекомендации по оптимальной настройке под ваши требования.