> ## 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.

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

> Правила KYT в Didit: условия, окна скорости и автоматические действия, из готовых наборов или с нуля. 1,000 в месяц включено, далее $0.001 за каждое.

Каждая транзакция, отправленная в Didit, проверяется по всем активным правилам вашего приложения. Правила задают условия, проверки частотности операций и действия, которые определяют итоговый статус и оценку транзакции.

Этот раздел урока по движку правил Didit Academy начинается с создания правила.

В уроке Academy по движку правил правило создаётся в видео на отметке 7:54: триггер, условия, действия и скоринг, затем бэктестинг перед развертыванием.

[Создание правила - Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> Правилами можно управлять в **Бизнес-консоли**, через **Management API** и в **Didit MCP**. Используйте консоль, если каждое изменение должен просматривать человек из вашей команды комплаенса. Используйте API или MCP, если правила создаются и настраиваются программно, например при переносе набора правил от другого провайдера. См. [справочник API](https://docs.didit.me/ru/management-api/transactions/rules-list.md) и [руководство по управлению правилами через API и MCP](https://docs.didit.me/ru/transaction-monitoring/rules-api.md). Правила применяются к каждой транзакции, отправленной через [`POST /v3/transactions/`](https://docs.didit.me/ru/management-api/transactions/create), а результат появляется в массиве `rule_runs[]` транзакции (см. [схему ответа](https://docs.didit.me/ru/transaction-monitoring/response-schema.md)).

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

Didit предоставляет готовую библиотеку правил, которая покрывает распространённые регуляторные типологии. Установите нужные предустановки или целые наборы из библиотеки: в консоли, через [API установки](https://docs.didit.me/ru/management-api/transactions/rules-install.md) или с помощью инструментов MCP. Для каждой установленной предустановки можно задать режим работы. Полный каталог всех предустановленных правил с пороговыми значениями и действиями см. в [Библиотеке правил](https://docs.didit.me/ru/transaction-monitoring/rules-library.md).

| Набор | Примеры |
| - | - |
| **Финансы** | Выявление структурирования (входящие/исходящие), крупные разовые транзакции сверх пороговых значений отчетности |
| **AML/CTF** | Лимиты совокупного объема, быстрое движение средств «туда и обратно», совпадение контрагентов с санкционными списками, подозрительные ключевые слова в платёжных референсах |
| **Выявление аномалий** | Высокая скорость входящих/исходящих операций, реактивация спящего счёта после 12+ месяцев бездействия |
| **FATF** | Связь контрагентов и IP-адресов субъектов с юрисдикциями высокого риска |
| **Анализ устройств** | Многократное использование бонусной кампании с одного отпечатка устройства, несколько отпечатков устройств у одного субъекта |
| **Предотвращение мошенничества** | Мультиаккаунтинг через общие отпечатки устройств у разных субъектов |
| **Крипто-мониторинг** | Связь с сервисами миксеров и обфускации, адреса кошельков высокого риска (адреса даркнет-сервисов, санкционированные адреса, адреса, связанные с украденными средствами) |
| **Крипто-скрининг** | Связь с источниками средств высокого риска (>30%), несколько рискованных контрагентов, автоматический отказ при финансировании терроризма и эксплуатации детей, удержание до завершения скрининга, пометка при средней оценке риска кошелька |
| **Ответственная игра** | Быстрые всплески депозитов за короткие промежутки времени |
| **Электронная коммерция** | Специфичные для электронной коммерции шаблоны транзакций |

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

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

| Источник | Описание |
| - | - |
| **Предустановка** | Правила, установленные из встроенной библиотеки Didit. Вы выбираете, какие предустановки (или целые наборы) установить, и управляете режимом каждой установленной предустановки (`Active`, `Test`, `Disabled`). Их условия и пороговые значения фиксированы: чтобы изменить одно из них, создайте свое правило. Предустановки удаляются деинсталляцией, а не удалением правила. |
| **Пользовательские** | Правила, которые ваша команда создает в Бизнес-консоли. Вы полностью контролируете свои правила: создаете, редактируете и удаляете их по необходимости. |

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

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

| Компонент | Описание |
| - | - |
| **Название и описание** | Понятное название и объяснение того, что обнаруживает правило |
| **Категория** | Логическая группировка (например, `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **Режим** | `Active` (вычисляется в боевом режиме), `Disabled` (пропускается) или `Test` (вычисляется, но результаты не влияют на транзакцию) |
| **Режим вычисления** | `All` (должны совпасть все условия) или `Any` (должно совпасть хотя бы одно условие) |
| **Область применения** | Ограничивает, к каким транзакциям применяется правило. Ключи: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`. Пустое значение или отсутствие ключа означает отсутствие ограничений |
| **Условия** | Проверки на уровне полей: сравнивают поля транзакции со значениями с помощью операторов, таких как `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` |
| **Агрегация** | Временные окна для подсчёта частоты операций: агрегируют исторические транзакции за период времени (например, количество, сумму или количество уникальных значений за 1 час, 7 дней, 30 дней) |
| **Действия** | Что происходит, когда правило срабатывает (см. ниже) |

## Действия

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

| Действие | `type` | Ключи | Описание |
| - | - | - | - |
| **Добавить баллы** | `add_score` | `value` (целое число, может быть отрицательным) | Добавляет баллы к оценке риска транзакции. Суммарная оценка по всем сработавшим правилам определяет, достигает ли транзакция порога проверки или порога отклонения либо превышает его. |
| **Изменить статус** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, псевдоним `status`), `workflow_id` (псевдоним `remediation_workflow_id`) | Напрямую задаёт статус транзакции независимо от оценки. `workflow_id` обязателен, когда `value` равно `AWAITING_USER`. Если его не указать, API вернёт `400`. |
| **Добавить метки** | `add_tags` | `tag_uuid` или `tag_name` (одно из двух), `tag_color` | Присваивает транзакции метку для классификации и фильтрации. Используется `tag_uuid` существующей метки или `tag_name`, которая создаётся при первом использовании и сохраняется в верхнем регистре. `tag_color` задаёт HEX-цвет новой метки. |
| **Добавить примечание** | `add_note` | `note` (псевдоним `value`) | Прикрепляет к транзакции автоматическое текстовое примечание для контекста аналитика. |
| **Добавить в список** | `add_to_list` | `list_id` | Добавляет `vendor_data` субъекта в список блокировки, список разрешённых или пользовательский список. |
| **Открыть дело** | `open_case` | `blueprint` (UUID шаблона кейса, необязательный), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (булево значение) | Открывает кейс расследования или добавляет транзакцию в существующий. К правилу применяется только первое действие `open_case`. |

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

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

Действие **Изменить статус → `AWAITING_USER`** делает больше, чем просто задаёт статус. Как только правило срабатывает, Didit автоматически создаёт размещённую сессию верификации для субъекта транзакции (с тем же `vendor_data`).
Сессия возвращается в блоке `action_required` транзакции (а также в объекте `remediation`) в ответе на создание и при каждом последующем чтении, а также в обоих событиях webhook транзакции. Поэтому можно сразу перенаправить пользователя. См. [обязательные действия пользователя](https://docs.didit.me/ru/transaction-monitoring/sdk-transaction-submission.md#требуемые-действия-пользователя).

Пользовательские правила должны указывать сценарий прямо в действии (`workflow_id`). Этого требуют и конструктор правил в консоли, и API правил.
Готовые правила из библиотеки не содержат сценария. Для них сценарий сессии определяется в таком порядке:

1. **Сценарий устранения последствий**, настроенный в ваших [настройках транзакций](https://docs.didit.me/ru/transaction-monitoring/settings.md#сценарий-устранения).
2. Сценарий **«Биометрическая аутентификация»** вашего приложения, если у субъекта уже есть сохранённое эталонное лицо из одобренной верификации.
3. Сценарий по умолчанию вашего приложения.

Таким образом, правила `AWAITING_USER` из библиотеки всегда создают действующую сессию без дополнительной настройки: биометрическую повторную проверку для пользователей, которых вы уже верифицировали, и полную верификацию для остальных.
Транзакции Travel Rule исключены из этого автоматического резервного варианта. Их ожидание `AWAITING_USER` предназначено для подтверждения владения кошельком, и для этого есть [отдельный процесс](https://docs.didit.me/ru/transaction-monitoring/wallet-ownership-widget.md).

Самый надёжный выбор для транзакций высокого риска это сценарий **«Биометрическая аутентификация»**. Субъект является пользователем, которого вы уже верифицировали с помощью KYC, поэтому Didit использует подтверждённое эталонное лицо из его онбординга (одобренное селфи для проверки живости, фото из чипа паспорта или портрет из документа). Пользователю достаточно сделать одно живое селфи, а Didit выполняет проверку живости и сравнение лица 1:1 с лицом пользователя, открывшего аккаунт.
Украденные учётные данные, одноразовые коды, полученные в результате фишинга, и подмена SIM-карты не пройдут эту проверку.
Полное руководство: [пошаговая биометрическая проверка для вывода крупной суммы](https://docs.didit.me/ru/transaction-monitoring/sdk-transaction-submission.md#пример-повторная-биометрическая-проверка-для-крупного-вывода-средств).

Когда сессия получает решение, транзакция автоматически следует за ним, и срабатывает webhook `transaction.status.updated`. Одобренная сессия одобряет транзакцию (`decision_reason_code: user_action_approved`), отклонённая сессия отклоняет её (`user_action_declined`), а сессия, которая завершается переводом на проверку, переводит транзакцию в `IN_REVIEW` (`user_action_in_review`).
Если сессия истекла или прервана, транзакция остаётся в `AWAITING_USER`.

> [!NOTE]
>
> В качестве действия по устранению последствий можно использовать сценарий любого типа, кроме KYB.
> Сценарии Биометрическая аутентификация (а также сценарии, где сравнение лиц выполняется до верификации личности) дополнительно требуют сохранённого эталонного лица субъекта: одобренное селфи для проверки живости, фото из чипа паспорта, портрет из документа или лицо, добавленное вручную в профиль.
> Если такого лица нет, пользователю предлагается пройти сценарий по умолчанию вашего приложения. Это также зарегистрирует его лицо для следующих проверок, а примечание к транзакции зафиксирует замену.
> Сессия пропускается только тогда, когда не существует и подходящего сценария по умолчанию. В этом случае примечание объясняет причину.

## Скоринг

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

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

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

| Настройка | По умолчанию | Описание |
| - | - | - |
| **Порог проверки** | 75 | Оценка, равная этому значению или выше, переводит транзакцию в `IN_REVIEW` |
| **Порог отклонения** | 500 | Оценка, равная этому значению или выше, переводит транзакцию в `DECLINED`. Значение по умолчанию (`500`) никогда не отклоняет транзакцию по оценке |

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

Пользовательские правила можно создать в **Бизнес-консоли** или через **Management API** (он также доступен через [Didit MCP](https://docs.didit.me/ru/integration/mcp/tools.md) и любой ИИ-ассистент с подключением MCP).

> [tab] Консоль
>
> 1. Перейдите в **Транзакции** > **Правила** в консоли
> 2. Нажмите **Create Rule**
> 3. Укажите название правила, описание и категорию
> 4. Задайте **режим**: `Active`, чтобы правило работало в реальном времени, или `Test`, чтобы оценивать его без влияния на транзакции
> 5. Выберите **режим оценки**: `All` (должны совпасть все условия) или `Any` (достаточно одного совпадения)
> 6. Задайте **область применения**: типы или направления транзакций, к которым применяется правило
> 7. Добавьте **условия**: сравнения полей, такие как пороги суммы, коды стран и проверки пользовательских свойств
> 8. При необходимости добавьте **агрегацию**: проверки скорости за временное окно (количество, сумма, количество уникальных значений и другие)
> 9. Определите одно или несколько **действий**: добавить оценку, изменить статус, добавить теги, добавить заметки, добавить в список или открыть кейс
> 10. Сохраните и включите правило

> [tab] API
>
> Вызовите [`POST /v3/transactions/rules/`](https://docs.didit.me/ru/management-api/transactions/rules-create) с теми же полями: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. Полный справочник полей, операторов и действий находится на этой странице. В разделе [управление правилами через API и MCP](https://docs.didit.me/ru/transaction-monitoring/rules-api.md) описан рекомендуемый порядок: создание -> бэктестинг -> активация, включая перенос набора правил из CSV-экспорта другого провайдера.

Правила в режиме `Active` применяются сразу ко всем новым транзакциям. Названия правил уникальны в рамках приложения.

## Бэктестинг

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

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

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

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

| Метрика | Описание |
| - | - |
| `count` | Количество транзакций, совпадающих с фильтрами, в окне |
| `sum` | Сумма числового `field` (например, `preferred_currency_amount`) в окне |
| `max` / `min` / `avg` | Наибольшее, наименьшее или среднее значение числового `field` в окне |
| `distinct_count` | Количество уникальных значений `field` (например, уникальных отпечатков устройств) в окне (`unique_count` также допустим как синоним) |

Каждая агрегация задаёт:

* **Временное окно**: `<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)

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

| Шаблон | Как это работает |
| - | - |
| **Структурирование** | Количество транзакций одного субъекта за 30 дней >= 20 при значении `max` для суммы меньше \$10,000 за то же окно |
| **Высокая скорость** | Количество входящих транзакций одного субъекта за 7 дней >= 20 |
| **Быстрый вход и выход** | Текущая транзакция является исходящей, а количество входящих транзакций того же субъекта за 6 часов >= 1 |
| **Мультиаккаунтинг** | Количество уникальных субъектов, использующих один и тот же отпечаток устройства, за 7 дней >= 3 |
| **Реактивация спящего счёта** | Количество дней с момента предыдущей транзакции субъекта >= 365 в сочетании с суммой >= \$1,000 |

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

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

| Поле | Описание |
| - | - |
| `amount`, `currency` | Сумма транзакции и код валюты |
| `preferred_currency_amount`, `default_currency_code` | Сумма, пересчитанная в предпочтительную валюту вашего приложения (если значения нет, используется `amount_in_default_currency`) |
| `direction` | `INBOUND` или `OUTBOUND` |
| `action_type` | Ваш тип действия, например `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | Свободный текстовый реквизит платежа (целевое поле для `contains_any` в правилах по ключевым словам) |
| `score`, `severity` | Текущая оценка риска и уровень серьёзности транзакции |
| `subject_vendor_data`, `counterparty_vendor_data` | Ваши идентификаторы двух сторон |
| `subject_country`, `counterparty_country` | Коды стран сторон (принимаются ISO-2 и ISO-3; перед сравнением приводятся к единому виду) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | Отпечаток устройства или постоянный идентификатор устройства |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Подробности контекста устройства (доступно также `counterparty_browser_family`) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Сетевой контекст |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | Платёжный метод субъекта (те же четыре поля есть для `counterparty_payment_method_*`) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Состояние проверки Travel Rule |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Что вам известно о VASP-контрагенте, с которым был установлен обмен данными по Travel Rule: ваше решение по нему (`APPROVED`, `RESTRICTED`, `BLOCKED`), его уровень риска (`LOW`, `MEDIUM`, `HIGH`; `HIGH`, пока ваш собственный скрининг контрагента помечен), его страна и отзывчивость (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). См. [Проверка контрагента по Travel Rule](https://docs.didit.me/ru/transaction-monitoring/travel-rule.md#поля-правил-и-пресеты) |
| `subject_days_since_previous_transaction` | Количество дней с предыдущей транзакции этого субъекта того же типа (правила для неактивности) |
| `tags` | Названия тегов транзакции |
| `custom_values.<key>` | Любой ключ, который вы передали в `custom_properties` при создании транзакции |

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

Правила поддерживают следующие операторы сравнения для условий:

| Оператор | Описание | Пример |
| - | - | - |
| `eq` / `ne` | Равно / не равно | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | Сравнение чисел и дат; никогда не совпадает, если одна из сторон отсутствует | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | Вхождение в список (допускается также одно скалярное значение) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | Подстрока в строковом значении без учёта регистра | `payment_details contains "refund"` |
| `contains_any` | Любая из строк списка является подстрокой поля без учёта регистра | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | Шаблон значения совпадает с полем | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | Нечёткое сравнение строк; требует порог `score` (0–100) в условии | `counterparty_name fuzzy_match "Acme Corp"` с `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | Поле присутствует (псевдонимы; `value` игнорируется) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | Поле отсутствует или пустое (псевдонимы; `value` игнорируется) | `subject_ip_address is_empty` |

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

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

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

| `value_type` | Значение |
| - | - |
| `list` | `value` является UUID списка: записи списка блокировки, списка разрешений или пользовательского списка становятся значением сравнения, поэтому правило может проверять условие «контрагент есть в моём пользовательском списке наблюдения». |
| `field` | `value` является путём к другому полю: условие сравнивает два поля транзакции, например `subject_payment_method_account_id ne counterparty_payment_method_account_id`. |
| `relative_date` | `value` является относительной датой, например `{"direction": "past", "unit": "days", "amount": 30}`, для полей дат, таких как `txn_date`. |

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

Плоский список условий объединяется в соответствии с `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/`](https://docs.didit.me/ru/transaction-monitoring/transactions), сохраняется в транзакции как `custom_values` и может использоваться в условиях с путём поля `custom_values.<key>`. Например, транзакция, отправленная с `"custom_properties": {"channel": "mobile_app"}`, соответствует условию `custom_values.channel eq "mobile_app"`. Все перечисленные выше операторы работают с пользовательскими свойствами, их также можно сравнивать с другими полями или использовать в фильтрах окон скорости.

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

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

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

Проверяются следующие объекты:

| Объект | Тип списка блокировки | Что проверяется |
| - | - | - |
| **Пользователь (заявитель)** | Список блокировки пользователей | Идентификатор `vendor_data` заявителя |
| **Компания** | Список блокировки компаний | Идентификатор `vendor_data` компании |
| **Адрес кошелька** | Список блокировки адресов кошельков | `account_id` способов оплаты криптокошельком |
| **Банковский счёт** | Список блокировки банковских счетов | `account_id` способов оплаты банковским переводом |
| **IP-адрес** | Список блокировки IP-адресов | IP-адрес из контекста устройства стороны (поддерживаются диапазоны CIDR) |
| **Отпечаток устройства** | Список блокировки отпечатков устройств | Отпечаток устройства или постоянный идентификатор устройства |

При совпадении со списком блокировки:

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

> [!NOTE]
>
> Проверки списков блокировки выполняются до оценки правил. Объект из списка блокировки всегда отклоняется независимо от конфигурации правил и пороговых значений оценки.

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

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

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

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

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

> [card] [Отправка транзакций](https://docs.didit.me/ru/transaction-monitoring/transactions.md)
>
> Как структурированы транзакции для оценки по правилам.

> [card] [Скрининг криптовалют](https://docs.didit.me/ru/transaction-monitoring/aml-screening.md)
>
> Результаты скрининга криптовалют и то, как готовые правила их используют.

> [card] [Настройки](https://docs.didit.me/ru/transaction-monitoring/settings.md)
>
> Настройте пороговые значения оценок и сценарии устранения проблем.

> [card] [Справочник API](https://docs.didit.me/ru/management-api/transactions/create.md)
>
> Эндпоинт API для создания транзакций.


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