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

# Постоянный AML-мониторинг: ежедневный повторный скрининг

> Didit: автоматический ежедневный AML-скрининг верифицированных пользователей, webhook-оповещения о новых санкционных совпадениях и смене статуса. От $0.07/год.

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

![Панель непрерывного AML-мониторинга Didit с ежедневным повторным скринингом и оповещениями через webhook](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/aml-continuous-monitoring.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=8cf8c4ecef0f78953423a598defd2b2b)

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

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

1. **Ежедневные автоматические проверки**:
   * Наша система выполняет ежедневные автоматические проверки для всех сессий, которые ранее были одобрены
   * Каждая проверка повторно проверяет пользователя по нашей обширной базе списков наблюдения и санкционных списков
   * Система сопоставляет любые новые совпадения с настроенными вами AML-порогами

2. **Обновления на основе пороговых значений**:
   * Если обнаружены новые совпадения, превышающие ваш настроенный порог проверки, статус сессии меняется на «На проверке»
   * Если новые совпадения превышают порог отклонения, статус сессии автоматически меняется на «Отклонена»
   * Эти пороги те же, которые вы настроили в своих [Сценариях](https://docs.didit.me/ru/console/workflows.md)

3. **Уведомления в реальном времени**:
   * При изменении статуса ваше приложение получает webhook-уведомление
   * Payload webhook содержит обновлённый статус и подробную информацию о новых AML-совпадениях
   * Эти уведомления следуют тому же формату, что и наша стандартная [система webhook](https://docs.didit.me/ru/integration/webhooks.md)

4. **Обновления в Business Console**:
   * Все изменения немедленно отображаются в вашей Business Console
   * Ваша команда комплаенса может исследовать новые AML-совпадения, просматривать подробные результаты и принимать соответствующие меры
   * Консоль сохраняет полный журнал аудита всех действий мониторинга и изменений статуса

### Включение мониторинга для пользователей и компаний

Вы можете включать или отключать постоянный мониторинг для пользователей и компаний целиком прямо из консоли — включая пользователей, которые никогда не проходили AML-проверку, например, импортированных пользователей.

1. Откройте **Пользователи** (или **Компании**) в вашей Business Console, выберите профили, которые хотите отслеживать, и нажмите **Постоянный AML-мониторинг**.
2. В диалоговом окне отобразится предварительная оценка стоимости до запуска: сколько профилей выбрано, скольким требуется новый AML-скрининг, единовременная стоимость скрининга и годовая стоимость мониторинга.
3. Нажмите **Включить мониторинг**. Небольшие выборки обрабатываются мгновенно; более крупные выполняются в фоновом режиме, пока в диалоговом окне отображается ход выполнения в реальном времени.
4. По завершении выполнения в диалоговом окне отображается детализация результата по каждому профилю: включён, проверен и включён, уже включён или пропущен с указанием причины (например, в профиле отсутствуют полное имя, дата рождения и страна, необходимые для скрининга).

Несколько важных деталей:

* **Профили без AML-скрининга проверяются первыми.** Didit создает для них новую AML-верификацию (отображается на вкладке профиля **Верификации**), оплачиваемую как обычный AML-скрининг. Затем для этого скрининга включается мониторинг.
* **Один AML-скрининг под мониторингом на профиль.** При включении для пользователя или компании сохраняется ровно один AML-скрининг под мониторингом, поэтому человек, прошедший верификацию несколько раз, отслеживается — и тарифицируется — только один раз. Отключение деактивирует мониторинг по всем скринингам профиля.
* **Списки наглядно показывают статус мониторинга.** В списках **Пользователи** и **Компании** есть столбец **Постоянный мониторинг**; наведите курсор на него, чтобы увидеть дату следующего ежегодного биллинга.
* **Выбор всех элементов работает с вашими фильтрами.** При выборе всех строк действие применяется к вашему текущему отфильтрованному представлению, а не только к загруженной странице.

### Включение мониторинга через API

Та же операция доступна вашему бэкенду с помощью API-ключа, поэтому вам никогда не придётся заново проверять профиль или открывать консоль для изменения параметров мониторинга:

* [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/ru/management-api/aml-monitoring/toggle-users) для пользователей
* [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/ru/management-api/aml-monitoring/toggle-businesses) для компаний
* [`GET /v3/aml-monitoring/jobs/{job_id}/`](https://docs.didit.me/ru/management-api/aml-monitoring/get-job) для опроса статуса задачи

Оба endpoint для переключения принимают список ваших собственных идентификаторов (`vendor_data_list`) и/или идентификаторов Didit (`didit_internal_id_list`), до 1000 за один вызов, и в точности следуют правилам консоли: один AML-скрининг под мониторингом на профиль, профили без скрининга сначала проверяются, а отключение выключает мониторинг по всем скринингам профиля.

```bash theme={null}
# 1. Preview the cost. Nothing is written.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "estimate_only": true, "vendor_data_list": ["user-123", "user-456"]}'

# 2. Enable monitoring. 20 profiles or fewer complete inline (200);
#    larger selections return 202 and a job_id to poll.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'
```

Ответ содержит ту же детализацию, что и диалоговое окно консоли, плюс одну запись `results` на профиль с его результатом: `enabled`, `screened_and_enabled`, `already_enabled`, `disabled` или причину пропуска, такую как `skipped_no_identity_data`. Идентификаторы, которым ничего не соответствует, возвращаются в `unmatched`. Само переключение мониторинга не отправляет webhook; как только мониторинг включён, повторные проверки вызывают обычные события `status.updated` и `data.updated`.

### Подтверждение выполнения мониторинга

Оповещения, записи об активности и webhook, описанные выше, срабатывают только при **изменении**. Субъект, проверяемый ежедневно в течение года без новых совпадений, не сгенерирует ни одного из них, поэтому формулировки «нет новостей» и «ничего никогда не выполнялось» выглядят одинаково — а такой ответ аудит не устроит. Три интерфейса фиксируют сами запуски.

**1. Дата последнего скрининга в AML-отчёте.** Значение `last_ongoing_screening_at` обновляется при каждом завершённом запуске, с изменениями или без, в решениях по сессиям `/v2/` и `/v3/`, а также в отдельном AML-отчёте. Параметр `last_ongoing_screening_datasets_updated_at` рядом с ним представляет собой самое последнее обновление набора AML-данных, о котором поставщик сообщил для этого запуска. Ни одно из них никогда не является оценочным: `null` означает «повторный скрининг не проводился» и «о дате набора данных не сообщалось» соответственно, а не «неизвестно, поэтому вот примерная дата». Не воспринимайте `next_ongoing_monitoring_bill_date` как дату скрининга — это дата биллинга.

**2. История скринингов по каждому субъекту.** Endpoint `GET /v1/session/{session_id}/aml-screening-history/` возвращает каждый завершённый запуск для AML-проверки этой сессии, начиная с самых новых, включая запуски, результатом которых было `NO_CHANGE`. Добавьте `?node_id=`, если графовый сценарий содержит более одного AML-узла.

```bash theme={null}
curl https://verification.didit.me/v1/session/SESSION_ID/aml-screening-history/ \
  -H "x-api-key: YOUR_API_KEY"
```

```json theme={null}
{
  "count": 2,
  "results": [
    {
      "uuid": "0d1c...",
      "completed_at": "2026-09-12T04:03:11Z",
      "started_at": "2026-09-12T04:00:02Z",
      "outcome": "NO_CHANGE",
      "trigger": "ONGOING_MONITORING",
      "status": "Approved",
      "score": 0,
      "total_hits": 0,
      "dataset_freshness": null
    }
  ]
}
```

| Поле | Значение |
| - | - |
| `outcome` | `NO_CHANGE` — запуск завершен, результат не изменился. `CHANGED` — запуск завершен, оценка, статус или совпадения изменились. `FAILED` — провайдер не вернул пригодного для использования ответа для этого субъекта, поэтому скрининг не проводился и ничего не изменилось. Пробел в покрытии фиксируется, а не скрывается. |
| `completed_at` / `started_at` | Время завершения скрининга этого субъекта и время запуска пакета, к которому он относился. |
| `status` / `score` / `total_hits` | Состояние, в котором запуск оставил проверку. |
| `dataset_freshness` | Насколько актуальными были списки провайдера для этого запуска, или `null`, если даты наборов данных были недоступны. |

**3. Экспортируемые доказательства.** `GET /v1/session/{session_id}/aml-screening-history/export/` передает ту же историю в виде CSV-файла — по одной строке на каждый завершенный скрининг, с датой обновления набора данных для каждого семейства источников, если провайдер сообщил ее, и пустой ячейкой, если нет. Этот файл комплаенс-команда передает аудитору. Business Console отображает тот же список и тот же экспорт рядом с результатом AML, поэтому проверяющим не требуется доступ к API для его получения.

> [!NOTE]
>
> **Ограничения доступности, сформулированные прямо.** История записывается с момента выпуска этой функции; более ранние скрининги не восстанавливаются и попросту отсутствуют. Запуски сохраняются в течение настроенного срока хранения данных (два года по умолчанию). Свежесть наборов данных зависит от того, публикует ли провайдер даты наборов данных для вашей среды — если нет, каждое поле набора данных содержит `null`, а `GET /v1/aml/dataset-freshness/` возвращает `availability: "not_configured"`. Отсутствующая дата никогда не заменяется искусственным значением.

### Преимущества постоянного мониторинга

1. **Непрерывный комплаенс**: обеспечение постоянного соблюдения требований AML/KYC без дополнительной настройки.
2. **Снижение рисков**: быстрое выявление и устранение возникающих рисков с помощью автоматического мониторинга.
3. **Операционная эффективность**: автоматизация трудоемких процессов повторного ручного скрининга без дополнительных интеграционных работ.
4. **Углубленная проверка**: автоматическое поддержание профилей клиентов в актуальном состоянии.
5. **Поддержка соблюдения нормативных требований**: легко демонстрировать регуляторам постоянные усилия по соблюдению требований.
6. **Интеграция без ручного вмешательства**: используйте преимущества постоянного мониторинга без дополнительной работы по разработке.


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