Правила KYT и скоринг: скорость и условия

Каждая транзакция, отправленная в Didit, проверяется по всем активным правилам вашего приложения. Правила задают условия, проверки частотности операций и действия, которые определяют итоговый статус и оценку транзакции. Этот раздел урока по движку правил Didit Academy начинается с создания правила. В уроке Academy по движку правил правило создаётся в видео на отметке 7:54: триггер, условия, действия и скоринг, затем бэктестинг перед развертыванием.

​

Встроенные наборы правил

Didit предоставляет готовую библиотеку правил, которая покрывает распространённые регуляторные типологии. Установите нужные предустановки или целые наборы из библиотеки: в консоли, через API установки или с помощью инструментов MCP. Для каждой установленной предустановки можно задать режим работы. Полный каталог всех предустановленных правил с пороговыми значениями и действиями см. в Библиотеке правил.

​

Источники правил

У каждого правила есть source, который показывает, кто им управляет:

​

Устройство правила

Каждое правило состоит из:

​

Действия

Когда правило срабатывает для транзакции, выполняется одно или несколько действий. Каждое правило может содержать несколько действий, которые применяются все вместе: Большинство готовых правил сочетают Добавить баллы с Изменить статус. Например, правило для санкционного контрагента добавляет к оценке 90 баллов и сразу отклоняет транзакцию.

​

Требование верификации пользователя (AWAITING_USER)

Действие Изменить статус → AWAITING_USER делает больше, чем просто задаёт статус. Как только правило срабатывает, Didit автоматически создаёт размещённую сессию верификации для субъекта транзакции (с тем же vendor_data). Сессия возвращается в блоке action_required транзакции (а также в объекте remediation) в ответе на создание и при каждом последующем чтении, а также в обоих событиях webhook транзакции. Поэтому можно сразу перенаправить пользователя. См. обязательные действия пользователя. Пользовательские правила должны указывать сценарий прямо в действии (workflow_id). Этого требуют и конструктор правил в консоли, и API правил. Готовые правила из библиотеки не содержат сценария. Для них сценарий сессии определяется в таком порядке:

1. Сценарий устранения последствий, настроенный в ваших настройках транзакций.
2. Сценарий «Биометрическая аутентификация» вашего приложения, если у субъекта уже есть сохранённое эталонное лицо из одобренной верификации.
3. Сценарий по умолчанию вашего приложения.

Таким образом, правила AWAITING_USER из библиотеки всегда создают действующую сессию без дополнительной настройки: биометрическую повторную проверку для пользователей, которых вы уже верифицировали, и полную верификацию для остальных. Транзакции Travel Rule исключены из этого автоматического резервного варианта. Их ожидание AWAITING_USER предназначено для подтверждения владения кошельком, и для этого есть отдельный процесс. Самый надёжный выбор для транзакций высокого риска это сценарий «Биометрическая аутентификация». Субъект является пользователем, которого вы уже верифицировали с помощью KYC, поэтому Didit использует подтверждённое эталонное лицо из его онбординга (одобренное селфи для проверки живости, фото из чипа паспорта или портрет из документа). Пользователю достаточно сделать одно живое селфи, а Didit выполняет проверку живости и сравнение лица 1:1 с лицом пользователя, открывшего аккаунт. Украденные учётные данные, одноразовые коды, полученные в результате фишинга, и подмена SIM-карты не пройдут эту проверку. Полное руководство: пошаговая биометрическая проверка для вывода крупной суммы. Когда сессия получает решение, транзакция автоматически следует за ним, и срабатывает webhook transaction.status.updated. Одобренная сессия одобряет транзакцию (decision_reason_code: user_action_approved), отклонённая сессия отклоняет её (user_action_declined), а сессия, которая завершается переводом на проверку, переводит транзакцию в IN_REVIEW (user_action_in_review). Если сессия истекла или прервана, транзакция остаётся в AWAITING_USER.

​

Скоринг

Когда транзакция совпадает с одним или несколькими правилами, их оценки суммируются:

1. Каждое совпадение правила вносит вклад в общую оценку риска транзакции через действие add_score.
2. Итоговая оценка определяет статус транзакции согласно порогам оценки вашего приложения.
3. Если какое-либо правило содержит действие change_status, этот статус применяется напрямую. DECLINED всегда имеет приоритет.

Пороги оценки по умолчанию (настраиваются в консоли):

​

Создание пользовательских правил

Пользовательские правила можно создать в Бизнес-консоли или через Management API (он также доступен через Didit MCP и любой ИИ-ассистент с подключением MCP). Правила в режиме Active применяются сразу ко всем новым транзакциям. Названия правил уникальны в рамках приложения.

​

Бэктестинг

Перед активацией правила его можно проверить на исторических данных:

• Установите правило в режим Test: правило оценивается для каждой новой транзакции, но результаты не влияют на статус или оценку транзакции. Статистика выполнения (количество совпадений, затронутые сущности) накапливается, чтобы вы могли оценить влияние до перевода в продакшн.
• Используйте функцию бэктеста в консоли или через POST /v3/transactions/rules/backtest/, чтобы задним числом оценить условия и агрегацию правила на транзакциях за указанный период. Бэктест возвращает количество оценённых и совпавших транзакций, а также затронутые сущности, и не изменяет никакие исторические данные. Передавайте те же conditions, aggregation, evaluation_mode и scope, что и у правила, которое вы планируете активировать. Если область применения не указана, ограничений нет, и бэктест посчитает транзакции, которые сохранённое правило пропускает.

​

Окна скоростных проверок (агрегация)

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

• Временное окно: <N>m (минуты), <N>h (часы) или <N>d (дни), например 30m, 6h, 7d, 30d. Внимание: m означает минуты, а не месяцы.
• Фильтры, которые сужают набор исторических транзакций. Ключи являются путями полей из каталога полей. Специальное значение "__current__" подставляет значение того же поля из оцениваемой транзакции (например, "subject_vendor_data": "__current__" ограничивает окно тем же субъектом). Список значений означает принадлежность к списку. Фильтры сравнивают только по равенству или принадлежности: оператора lt/gte для фильтров нет, поэтому диапазон вроде транзакции меньше 10 000 фильтром задать нельзя. Задавайте диапазон в метрике (max меньше 10 000, min больше 1 000). Помните, что условие ограничивает оцениваемую транзакцию, но никогда не окно.
• Оператор и порог (eq, ne, gt, gte, lt, lte относительно value, например количество >= 20)

​

Примеры шаблонов

​

Каталог полей

Условия и фильтры агрегации обращаются к полям транзакции по пути:

​

Операторы условий

Правила поддерживают следующие операторы сравнения для условий: Для каждого другого оператора требуется непустое value, без него API возвращает 400. contains, not_contains и regex принимают одну строку, но не список или объект; contains_any принимает список строк.

​

Типы значений условий

Необязательный параметр value_type в условии меняет способ интерпретации value:

​

Группированные условия

Плоский список условий объединяется в соответствии с evaluation_mode правила (ALL / ANY). Для смешанной логики задайте условиям group_index: условия с одинаковым индексом образуют группу, group_logic (AND / OR, по умолчанию AND) объединяет условия внутри группы, а groups_logic в первом условии (AND / OR, по умолчанию OR) объединяет результаты групп. Если хотя бы у одного условия есть group_index, группированная оценка заменяет evaluation_mode.

​

Обращение к пользовательским свойствам

Каждый ключ, переданный в объекте custom_properties запроса POST /v3/transactions/, сохраняется в транзакции как custom_values и может использоваться в условиях с путём поля custom_values.<key>. Например, транзакция, отправленная с "custom_properties": {"channel": "mobile_app"}, соответствует условию custom_values.channel eq "mobile_app". Все перечисленные выше операторы работают с пользовательскими свойствами, их также можно сравнивать с другими полями или использовать в фильтрах окон скорости. В конструкторе правил консоли ключи, встречавшиеся в недавно полученных транзакциях, автоматически появляются в селекторе полей условия в разделе Пользовательские свойства. Вы также можете указать ключ до того, как он появится в какой-либо транзакции: выберите Ввести пользовательское свойство в той же группе и введите ключ точно так, как его отправляет ваша интеграция (ключи чувствительны к регистру). Пока транзакции с этим ключом не поступят, правило просто не будет срабатывать.

​

Автоматический отказ по списку блокировки

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

• Статус транзакции устанавливается в DECLINED
• Причина решения устанавливается в blocklisted
• Создаётся запись активности для аудита

​

Скрининг транзакций

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

• Проверять контрагентов по глобальным базам данных о санкциях и списках наблюдения
• Оценивать адреса кошельков (для криптотранзакций) по данным блокчейн-аналитики, включая использование миксеров или подверженность миксерам, связи с субъектами, находящимися под санкциями, и взаимодействия с высокорисковыми сервисами
• Проверять статус AML заявителя, сопоставляя связанного с транзакцией пользователя с результатами его последнего AML-скрининга

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

​

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