Перейти к основному содержанию
Настройте параметры мониторинга транзакций на уровне приложения в Business Console, чтобы управлять порогами скоринга и предпочтениями провайдеров.

​
Общие настройки

​
Пороги скоринга

Пороги скоринга определяют, как совокупная оценка риска от сработавших правил соотносится со статусом транзакции: Транзакции с оценкой ниже порога проверки автоматически получают статус APPROVED. Если в правиле задано явное действие change_status, этот статус имеет приоритет над пороговыми значениями скоринга, но DECLINED всегда имеет приоритет.
Снижение порога проверки увеличивает количество транзакций, помеченных для проверки аналитиками. Настраивайте его с учетом возможностей вашей команды и допустимого уровня риска.

​
Криптомониторинг

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

​
Предпочтения провайдеров

Выберите и настройте предпочитаемого провайдера блокчейн-аналитики: Когда вы подключаете собственный ключ провайдера, вы используете существующее соглашение с провайдером и оплачиваете указанную комиссию за инфраструктуру за каждую проверку через Didit. Мониторинг Lightning Network доступен только при наличии подключения BYOK к Elliptic или Chainalysis, добавленного через Marketplace. Если LIGHTNING передается, пока активен другой провайдер, или до добавления одного из поддерживаемых подключений, запрос на скрининг возвращает 400 с инструкциями по настройке в Marketplace.

​
Сценарий устранения

Сценарий устранения (remediation_workflow_id в API настроек) задаёт общий для приложения сценарий по умолчанию для действий правил AWAITING_USER, которые не указывают собственный сценарий. На практике это встроенные правила из библиотеки: пользовательские правила всегда содержат собственный выбор сценария, и он имеет приоритет. Поле принимает идентификатор сценария (или UUID конкретной версии) при записи и всегда возвращает стабильный идентификатор сценария при чтении. Сессии создаются с последней опубликованной версией. Когда такое правило переводит транзакцию в статус AWAITING_USER, Didit создает связанную сессию верификации с первым найденным сценарием в следующем порядке:
  1. Сценарий устранения, настроенный здесь.
  2. Сценарий Биометрическая аутентификация вашего приложения, если у субъекта уже есть сохраненное эталонное лицо.
  3. Сценарий по умолчанию вашего приложения.
URL и токен сессии возвращаются в полях action_required и remediation транзакции и в обоих webhook транзакций, чтобы вы могли перенаправить пользователя для прохождения необходимой верификации. Когда по сессии принимается решение, статус транзакции автоматически соответствует ему (одобрен, отклонён или находится на проверке), и срабатывает webhook transaction.status.updated. Сценарий Биометрическая аутентификация является рекомендуемым выбором: пользователь повторно подтверждает личность одним селфи, сделанным в реальном времени, которое сравнивается с лицом из первоначального онбординга. Для этого субъект должен иметь сохраненное эталонное лицо из одобренной верификации. Пользователям без такого лица вместо него предлагается пройти сценарий по умолчанию вашего приложения, а в транзакции фиксируется примечание о замене.

​
Где найти

Перейдите в Транзакции > Настройки в Business Console, чтобы настроить эти параметры. Настройки сразу применяются ко всем новым транзакциям.

​
Следующие шаги

Оценка риска

Как пороги скоринга соотносятся со статусами.

Криптоскрининг

Скрининг кошельков и сведения о провайдерах.

IP-обогащение

Какие данные об IP доступны правилам.
Последнее изменение 7 ноября 2026 г.