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

# Регламент AMLR ЕС 2024/1624: руководство по API

> Сопоставьте каждое требование Регламента ЕС о борьбе с отмыванием денег (AMLR) со сценариями, endpoints API и webhooks Didit, которые его реализуют.

Регламент ЕС по борьбе с отмыванием денег (AMLR), Регламент (ЕС) 2024/1624, объединяет правила надлежащей проверки клиентов (CDD) в единый документ прямого действия. Он распространяется на кредитные и финансовые учреждения, включая поставщиков услуг, связанных с криптоактивами (CASP), поставщиков услуг в сфере азартных игр и других обязанных лиц, перечисленных в статье 3. Регламент вступил в силу 9 июля 2024 года и начнет применяться с 10 июля 2027 года. До этого момента продолжают действовать национальные законы, имплементирующие текущую директиву.

Эта страница предназначена для разработчиков и комплаенс-инженеров, перед которыми стоит задача реализовать эти требования. В каждом разделе изложены требования регламента, указана статья и приведены шаг сценария Didit, API endpoint или webhook, которые можно использовать для соответствующей задачи. Обзор для бизнеса см. на [странице решения AMLR](https://didit.me/solutions/amlr).

Дата последней проверки: 2 октября 2026 г.

> [!WARNING]
>
> **Didit предоставляет проверки и доказательства. Вы остаетесь обязанным лицом.** Вы определяете профиль риска клиента, принимаете решение об онбординге и несете полную ответственность за любые задачи, переданные на аутсорсинг (статья 18). Использование Didit само по себе не делает вашу компанию соответствующей требованиям AMLR. Эта страница не является юридической консультацией: согласуйте применение каждого правила к вашему бизнесу с юридическим консультантом и надзорным органом.

## Что требует AMLR: краткий обзор

| Обязательство | Статья | Где реализовано в Didit |
| - | - | - |
| Определять, когда требуется надлежащая проверка | Ст. 19 | Ваша собственная логика маршрутизации, затем сессия на каждый триггер. См. [Когда применяется надлежащая проверка](#когда-применяется-надлежащая-проверка) |
| Идентификация клиента и проверка его личности | Ст. 20(1)(a), ст. 22 | Верификация личности с помощью кошельков цифровой идентификации или съёмки документов. См. [Идентификация и проверка физических лиц](#идентификация-и-верификация-физических-лиц) |
| Идентификация бенефициарных владельцев и установление структуры владения | Ст. 20(1)(b), ст. с 51 по 53 | Сценарий «Верификация бизнеса (KYB)». См. [Проверка бизнеса и бенефициарных владельцев](#верификация-бизнеса-и-бенефициарных-владельцев) |
| Проверка санкций и политически значимых лиц (PEP) | Ст. 20(1)(d) и (g), ст. 42 | AML-скрининг. См. [Скрининг по санкциям и PEP](#скрининг-на-санкции-и-pep) |
| Мониторинг деловых отношений и поддержание актуальности данных клиентов | Ст. 26 | Постоянный AML-мониторинг и истечение срока действия документов. См. [Постоянный мониторинг и обновление данных](#постоянный-мониторинг-и-обновление-данных) |
| Определение цели деловых отношений и, при необходимости, источника средств | Ст. 25 | Анкеты. См. [Цель деловых отношений и источник средств](#цель-деловых-отношений-и-источник-средств) |
| Мониторинг транзакций и сообщение о подозрениях | Ст. 26(1), ст. 69 | Мониторинг транзакций и управление кейсами. См. [Мониторинг транзакций и отчетность](#мониторинг-транзакций-и-отчётность) |
| Хранение записей в течение 5 лет с последующим удалением персональных данных | Ст. 77 | Настройка сроков хранения, экспорт и удаление по запросу. См. [Хранение записей и удаление данных](#храните-записи-затем-удаляйте) |
| Участие человека в автоматизированных решениях | Ст. 76(5) | Ручная проверка и обновление статусов. См. [Участие человека в автоматизированных решениях](#проверка-автоматизированных-решений-человеком) |
| Контроль процессов, переданных на аутсорсинг | Ст. 18 | Ваш реестр аутсорсинга. См. [Аутсорсинг](#аутсорсинг) |

## Сквозной процесс

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

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant User as Your customer
    participant You as Your backend
    participant Didit as Didit API
    participant Team as Your compliance team

    You->>Didit: POST /v3/session/ (workflow_id, vendor_data)
    Didit-->>You: session_id and url
    You->>User: Redirect to url
    User->>Didit: Completes the workflow
    Didit--)You: status.updated webhook
    You->>Didit: GET /v3/session/{sessionId}/decision/
    Didit-->>You: Decision with the result of every check
    You->>Team: Queue the case for a decision
    Note over You,Team: Risk profile and onboarding decision are yours (Article 18)
    Team->>Didit: PATCH /v3/session/{sessionId}/update-status/
    You->>Didit: POST /v3/users/aml-monitoring/
    Didit--)You: status.updated and data.updated on each change
```

## Когда применяется надлежащая проверка

В статье 19 указано, когда вы обязаны применять надлежащую проверку клиентов: при установлении деловых отношений; при разовой транзакции на сумму не менее 10 000 евро в рамках одной операции или нескольких связанных транзакций; при возникновении подозрений в отмывании денег или финансировании терроризма независимо от суммы; а также при сомнениях в достоверности ранее полученных идентификационных данных. В некоторых секторах действуют более низкие пороги: 1 000 евро для разовых переводов средств и для CASP, 3 000 евро для разовых операций с наличными (как минимум идентификация и проверка) и 2 000 евро в сфере азартных игр. CASP обязан как минимум идентифицировать и верифицировать клиента при разовой транзакции на сумму менее 1 000 евро.

Didit не принимает решение о применении триггера. Вы выполняете маршрутизацию по типу и сумме транзакции в своем собственном коде, а затем запускаете соответствующий сценарий.

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Запуск надлежащей проверки для новых деловых отношений (ст. 19(1)(a)) | Сессия верификации в рамках вашего сценария онбординга | [`POST /v3/session/`](https://docs.didit.me/ru/sessions-api/create-session) |
| Запуск надлежащей проверки при превышении порога разовой транзакции (ст. 19(1)(b), с 19(2) по 19(5)) | Сессия верификации в рамках сценария, выбранного для этого триггера | [`POST /v3/session/`](https://docs.didit.me/ru/sessions-api/create-session) с соответствующим `workflow_id` |
| Выявление связанных транзакций, превышающих порог в совокупности | Правила контроля частоты операций в Мониторинге транзакций | [`POST /v3/transactions/`](https://docs.didit.me/ru/transaction-monitoring/transactions), [правила](https://docs.didit.me/ru/transaction-monitoring/rules.md) |
| Запрос верификации у клиента до проведения расчёта по помеченной транзакции | Действие правила переводит транзакцию в `AWAITING_USER` и создается связанная сессия верификации | [Статусы транзакций](https://docs.didit.me/ru/transaction-monitoring/statuses.md) |

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

```python theme={null}
# Illustrative only. The figures are the Article 19 thresholds in EUR.
def due_diligence_for(event) -> str:
    """Return "full_cdd", "identify_and_verify" or "none"."""
    if event.new_business_relationship or event.suspicion or event.doubts_about_identity_data:
        return "full_cdd"

    amount = event.linked_total_eur  # one operation, or linked transactions added together

    if event.sector == "casp":
        return "full_cdd" if amount >= 1_000 else "identify_and_verify"
    if event.is_transfer_of_funds and amount >= 1_000:
        return "full_cdd"
    if event.sector == "gambling" and amount >= 2_000:
        return "full_cdd"
    if amount >= 10_000:
        return "full_cdd"
    if event.is_cash and amount >= 3_000:
        return "identify_and_verify"
    return "none"


WORKFLOWS = {
    "full_cdd": "YOUR_FULL_CDD_WORKFLOW_ID",
    "identify_and_verify": "YOUR_ID_ONLY_WORKFLOW_ID",
}
```

## Идентификация и верификация физических лиц

Статья 22(1) перечисляет данные, которые вы обязаны хранить о физическом лице: все имена и фамилии, место и полную дату рождения, гражданства, национальный идентификационный номер при наличии, обычное место жительства и, при наличии, налоговый номер. Затем статья 22(6) указывает два способа верификации личности: документ, удостоверяющий личность, паспорт или эквивалентный документ, либо электронную идентификацию (eID), соответствующую уровням доверия eIDAS «существенный» (substantial) или «высокий» (high), совместно с соответствующими квалифицированными доверительными услугами.

### Данные в решении

Решение, возвращаемое [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/ru/sessions-api/retrieve-session), содержит по одной записи на каждую проверку личности в `id_verifications[]`.

| Данные согласно статье 22(1)(a) | Поле в `id_verifications[]` | Примечания |
| - | - | - |
| Все имена и фамилии | `first_name`, `last_name`, `full_name` | В том виде, как они указаны в документе или возвращены кошельком |
| Место и полная дата рождения | `place_of_birth`, `date_of_birth` | Место рождения присутствует, если оно указано в документе |
| Гражданства | `nationality` | Фиксируйте дополнительные гражданства, заявляемые клиентом, в вашей собственной системе |
| Национальный идентификационный номер при наличии | `personal_number` | Содержимое этого поля зависит от документа. См. [отчёт о Верификации личности](https://docs.didit.me/ru/core-technology/id-verification/report-id-verification.md) |
| Обычное место жительства | `address`, `formatted_address`, `parsed_address` | Паспорта редко содержат адрес. Добавьте [Подтверждение адреса](https://docs.didit.me/ru/core-technology/proof-of-address/overview.md) или [проверку по базам данных](https://docs.didit.me/ru/core-technology/database-validation/overview.md), если в документе он отсутствует |
| Налоговый номер при наличии | `extra_fields.tax_number` | Только если он указан в документе. В противном случае соберите его с помощью [анкеты](https://docs.didit.me/ru/core-technology/questionnaires/overview.md) |

### Два пути

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Верификация с помощью электронной идентификации (ст. 22(6)(b)) | [Кошельки цифровой идентификации (Digital ID)](https://docs.didit.me/ru/core-technology/id-verification/digital-id-wallets.md). Доступно в продакшн-среде: MitID (Дания), BankID Sweden, Finnish Trust Network (Финляндия), Smart-ID (Эстония, Латвия, Литва, Бельгия) и Mobile-ID (Эстония, Литва). European Digital Identity (EUDI) Wallet: **Скоро** | Настройте методы для каждой страны в [шаге Верификации личности](https://docs.didit.me/ru/console/id-verification-methods.md). В результате возвращаются `verification_method` и `wallet_provider` |
| Верификация с помощью документа, удостоверяющего личность (ст. 22(6)(a)) | [Захват документов](https://docs.didit.me/ru/core-technology/id-verification/overview.md) с проверкой подлинности и [чтение NFC-чипов](https://docs.didit.me/ru/core-technology/nfc-verification/overview.md) для электронных паспортов и e-ID. Для удалённого использования ознакомьтесь с проектом стандартов ниже | Шаги Верификации личности и NFC в сценарии |
| Проверка того, что лицо, предъявляющее документ, является его владельцем | [Проверка живости](https://docs.didit.me/ru/core-technology/liveness/overview.md) и [Сравнение лиц](https://docs.didit.me/ru/core-technology/face-match/overview.md) с фотографией в документе | Шаги Проверки живости и Сравнения лиц. Результаты в `liveness_checks[]` и `face_matches[]` |
| Сохранение подтверждений для последующей проверки | Запись сессии с изображениями, извлечёнными данными и временными метками | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/ru/sessions-api/generate-pdf), [экспорт](https://docs.didit.me/ru/console/export-pdf-csv.md) |

Уровень доверия, сообщаемый каждым кошельком, указан на странице [Кошельки цифровой идентификации (Digital ID)](https://docs.didit.me/ru/core-technology/id-verification/digital-id-wallets.md). Соответствует ли конкретная схема статье 22(6)(b) для вашего сценария использования, вы определяете самостоятельно. Didit предоставляет интеграцию, позволяющую вашему клиенту использовать кошелёк; сам Didit не является поставщиком квалифицированных доверительных услуг или схемой eID.

### Что говорят проекты технических стандартов об удалённой верификации

Регуляторные технические стандарты (RTS) по надлежащей проверке клиентов в соответствии со статьёй 28(1) разрабатываются Управлением по борьбе с отмыванием денег (AMLA). Итоговый отчёт AMLA датирован 30 сентября 2026 года, а о нём было объявлено 1 октября 2026 года. **Это финальный проект, представленный в Европейскую комиссию. Он не принят и не имеет силы закона.** Комиссия всё ещё может внести в него изменения, а проект предполагает применение через шесть месяцев после его вступления в силу.

Этот проект рассматривает два способа из статьи 22(6) как предусмотренные по умолчанию. Удалённая верификация с помощью документа является альтернативным решением для случаев, когда от лица нельзя обоснованно ожидать очного предъявления документа и оно не имеет доступа к подходящей eID (проект статьи 7(1)). Если вы используете эту альтернативу, проект требует, чтобы вы могли обосновать причину и продемонстрировать своему надзорному органу наличие защитных мер в данном решении (проект статьи 7(2) и 7(3)). Проект технологически нейтрален: в нём не называются конкретные технологии.

Как защитные меры из проекта соотносятся с тем, что фиксирует сессия Didit:

| Защитная мера в проекте (статья 7(2)) | Что можно использовать в Didit |
| - | - |
| Контроль того, что лицо, предъявляющее документ, является его владельцем | Результаты Проверки живости и Сравнения лиц в сессии |
| Изображения, видео и данные достаточного качества для идентификации лица | Проверки качества захвата в процессе прохождения с предупреждениями в отчёте |
| Остановка при возникновении сомнений в личности человека или целостности процесса | Предупреждения и статус сессии `"Declined"` или `"In Review"` |
| Сохранение копий с временными метками, доступных для последующей проверки | Запись сессии, PDF-отчёт и ваши [настройки хранения данных](#храните-записи-затем-удаляйте) |

Причина, по которой клиент прошёл верификацию по документу вместо eID, должна фиксироваться вами. Сохраняйте её в собственной системе или прикрепляйте к сессии через `metadata` при её создании.

## Верификация бизнеса и бенефициарных владельцев

Для юридического лица Статья 22(1)(b) требует указывать организационно-правовую форму и наименование, адрес места нахождения, законных представителей и, при наличии, регистрационный номер, налоговый номер и идентификатор юридического лица (LEI). Вы также обязаны идентифицировать бенефициарных владельцев и принять разумные меры для их проверки, чтобы понимать структуру владения и контроля (Статья 20(1)(b)). Бенефициарным владельцем является физическое лицо, прямо или косвенно владеющее «25 % или более» акций, прав голоса или иной доли владения (Статья 52(1)) либо контролирующее организацию через владение или иным образом (Статьи 51 и 53). Контроль оценивается параллельно с владением.

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Идентификация юридического лица и его проверка по реестру | [Верификация бизнеса](https://docs.didit.me/ru/business-verification/overview.md) (know your business, KYB) с проверкой по реестру компаний на уровнях Lite, Shareholders или UBOs. Доступность уровней зависит от страны | [`POST /v3/session/`](https://docs.didit.me/ru/sessions-api/create-session) с `workflow_id` для KYB. См. [поддерживаемые страны](https://docs.didit.me/ru/business-verification/supported-countries.md) |
| Определение конечных бенефициарных владельцев (UBO) с долей 25 % или более | [Структура владения](https://docs.didit.me/ru/business-verification/ownership.md) из реестра при наличии, подтверждённая и дополненная представителем компании | Порог UBO в разделе **Workflows**, в KYB-сценарии. Результаты в `key_people_checks[]` |
| Верификация личности владельцев, директоров и представителей | Связанные проверки личности: каждое [ключевое лицо](https://docs.didit.me/ru/business-verification/key-people.md) проходит дочернюю сессию верификации по выбранному для его роли сценарию | Настройки для каждой роли в разделе **Key People** в KYB-сценарии |
| Сравнение данных из реестра с декларацией клиента (Статья 22(7), Статья 24) | Сопоставление данных из реестра и заявленных сторон | `key_people_checks[].registry` и `key_people_checks[].submitted` в решении |
| Скрининг компании, её владельцев и контролирующих лиц | [AML-скрининг](https://docs.didit.me/ru/business-verification/aml.md) компании и физических лиц | Шаг AML в KYB-сценарии |

Четыре момента, которые следует учитывать при проектировании:

* **Порог настраивается вами.** В AMLR указано «25 % или более», а не «более 25 %». Порог UBO в сценарии настраивается, поэтому задайте его в соответствии с этим значением и пересмотрите его, если ваши внутренние правила строже.
* **Одного реестра недостаточно.** Статья 22(7) требует обращаться к центральным реестрам в дополнение к верификации бенефициарных владельцев. Сообщение о расхождениях в реестр в течение 14 календарных дней (Статья 24) является вашей обязанностью.
* **Отсутствие данных в реестре не доказывает отсутствие владельцев у компании.** В реестре может не быть записей о структуре владения для конкретной компании или страны. Если вы не выявили бенефициарного владельца, Статья 22(2) предписывает зафиксировать этот факт, а также установить и верифицировать высших должностных лиц.
* **Мониторинг реестров скоро появится.** Непрерывный мониторинг изменений в реестрах пока недоступен. До его появления повторно запускайте верификацию бизнеса в соответствии с вашим графиком обновления данных.

## Скрининг на санкции и PEP

Вы обязаны проверить, подпадают ли клиент или его бенефициарные владельцы под целевые финансовые санкции, а также контролируют ли подсанкционные лица клиента, являющегося юридическим лицом, или владеют более чем 50 % компании (Статья 20(1)(d)). В AMLR под целевыми финансовыми санкциями понимаются санкции ЕС. Вы также обязаны определить, является ли клиент или бенефициарный владелец политически значимым лицом (PEP), членом его семьи или близким соратником (Статья 20(1)(g)). Для PEP Статья 42 дополнительно требует одобрения высшего руководства, принятия мер по установлению источника благосостояния и источника средств, а также применения усиленного постоянного мониторинга.

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Скрининг при онбординге | Шаг [AML-скрининга](https://docs.didit.me/ru/core-technology/aml-screening/overview.md) в сценарии для проверки по санкционным спискам, спискам PEP и спискам наблюдения | Шаг AML и его пороги в сценарии. Результаты в `aml_screenings[]` |
| Скрининг без размещённого сценария | Отдельный скрининг физического лица или компании | [`POST /v3/aml/`](https://docs.didit.me/ru/standalone-apis/aml-screening) |
| Знать, какие списки охватываются | [База данных списков наблюдения](https://docs.didit.me/ru/core-technology/aml-screening/watchlist-database-aml-screening.md), включающая консолидированный перечень финансовых санкций ЕС | Справочная страница |
| Фиксация решения по каждому совпадению | Проверка совпадения со статусом `review_status` для каждого совпадения | [`PATCH /v3/session/{sessionId}/update-aml-hit-status/`](https://docs.didit.me/ru/sessions-api/update-aml-hit-status) |
| Передача совпадений по PEP и санкциям проверяющему | Пороги, переводящие сессию в статус `"In Review"` | Пороги AML в сценарии, затем [ручная проверка](https://docs.didit.me/ru/console/manual-review.md) |

```bash theme={null}
curl -X POST 'https://verification.didit.me/v3/aml/' \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "full_name": "Javier Ejemplo Modelo",
    "entity_type": "person",
    "date_of_birth": "1974-01-01",
    "nationality": "ES",
    "vendor_data": "user-1234"
  }'
```

Присвоение совпадению статуса `Confirmed Match` или `False Positive` инициирует webhook `data.updated` и само по себе не меняет решение по сессии. Получение одобрения высшего руководства для отношений с PEP является вашей задачей: направьте сессию на проверку и зафиксируйте, кто дал одобрение.

## Постоянный мониторинг и обновление данных

Статья 26 требует осуществлять постоянный мониторинг деловых отношений и поддерживать информацию о клиентах в актуальном состоянии. Период между обновлениями не должен превышать 1 год для клиентов повышенного риска и 5 лет для всех остальных клиентов (статья 26(2)). Вы также обязаны обновлять данные при изменении обстоятельств клиента или когда вам становится известен значимый факт (статья 26(3)). Проверки по санкционным спискам необходимо регулярно повторять, а кредитные и финансовые организации обязаны проводить их при каждом новом включении в санкционный список (статья 26(4)).

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Повторный скрининг клиентов по санкционным спискам и спискам PEP | [Постоянный AML-мониторинг](https://docs.didit.me/ru/core-technology/aml-screening/continuous-monitoring-aml-screening.md) с ежедневным повторным скринингом | Включите его на шаге AML или для отдельного профиля с помощью [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/ru/management-api/aml-monitoring/toggle-users) |
| Повторный скрининг компаний | Постоянный AML-мониторинг для профилей компаний | [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/ru/management-api/aml-monitoring/toggle-businesses) |
| Оповещение об изменении результата повторного скрининга | Webhook-уведомления по сессии | `status.updated` при изменении статуса, например на `"In Review"`, и `data.updated`. В payload передаётся `trigger: "ongoing_monitoring"` |
| Подтверждение выполнения мониторинга при отсутствии изменений | Дата последнего скрининга и история проверок | `last_ongoing_screening_at` в AML-отчёте и экспорт истории скрининга |
| Отслеживание документов, удостоверяющих личность, с истёкшим сроком действия | [Мониторинг документов](https://docs.didit.me/ru/core-technology/id-verification/document-monitoring-id-verification.md) | Сессия переходит из `"Approved"` в `"Kyc Expired"`, и отправляется webhook `status.updated` |

```bash theme={null}
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"]}'
```

Переключение режима мониторинга не отправляет отдельного webhook-события. Когда мониторинг включён, повторные проверки вызывают стандартные события `status.updated` и `data.updated`.

### Настройте в собственной системе обновление данных с учётом периодов в 1 и 5 лет

График актуализации зависит от присвоенного вами уровня риска, и это решение нельзя передать на аутсорсинг. Didit не хранит присвоенный вами класс риска и не планирует периодическое обновление за вас.

**1. Сохраняйте класс риска и дату последнего обновления**

Храните их в записи клиента в своей системе рядом с `vendor_data`, которые вы отправляете в Didit.

**2. Запускайте запланированную задачу**

Выбирайте клиентов, у которых дата последнего обновления раньше заданного интервала: не более 1 года для повышенного риска и не более 5 лет для остальных. Это максимальные сроки, поэтому вы можете выбрать более короткий интервал.

**3. Создавайте новую сессию**

Вызовите [`POST /v3/session/`](https://docs.didit.me/ru/sessions-api/create-session) с теми же `vendor_data` и вашим сценарием обновления данных, затем отправьте клиенту полученный `url`.

**4. Реагируйте на сопутствующие события**

Используйте статус `"Kyc Expired"`, webhook мониторинга, переводящий сессию в `"In Review"`, а также изменения, о которых сообщил сам клиент, как триггеры для досрочного обновления данных.

## Цель деловых отношений и источник средств

Перед установлением деловых отношений или проведением разовой транзакции статья 25 обязывает выяснить цель и предполагаемый характер таких отношений или операции. При необходимости вы собираете информацию о цели и экономическом обосновании, предполагаемом объёме операций, источнике средств, направлении средств, а также о роде деятельности или профессии клиента. Формулировка «при необходимости» означает, что глубина проверки определяется риск-ориентированным подходом. Усиленная комплексная проверка может дополнительно потребовать подтверждения источника благосостояния (статья 34(4)).

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Сбор информации о цели и ожидаемой активности | [Анкеты](https://docs.didit.me/ru/core-technology/questionnaires/overview.md) с шаблоном Purpose of Account | Шаг анкеты в сценарии |
| Сбор сведений об источнике средств с подтверждающими документами | Шаблон Source of Funds с загрузкой файлов | Шаг анкеты в сценарии |
| Сбор сведений о профессии и работодателе | Шаблон Employment Details | Шаг анкеты в сценарии |
| Ручная проверка каждого ответа человеком | Анкета, настроенная на обязательный результат `"In Review"` | Настройка ручной проверки в анкете |

Шаблоны служат отправной точкой. Настройте вопросы в соответствии с вашей оценкой рисков и сохраняйте ответы в рамках сессии, чтобы они находились в одной записи с проверкой личности.

## Мониторинг транзакций и отчётность

Постоянный мониторинг охватывает транзакции, совершаемые в ходе деловых отношений, обеспечивая их соответствие имеющимся у вас сведениям о клиенте (статья 26(1)). Если вы знаете, подозреваете или имеете достаточные основания подозревать, что средства получены преступным путём либо связаны с финансированием терроризма, вы направляете сообщение в своё подразделение финансовой разведки (ПФР) в соответствии со статьёй 69.

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Передача каждой транзакции на оценку | [Мониторинг транзакций](https://docs.didit.me/ru/transaction-monitoring/overview.md) для фиатных средств и криптовалюты | [`POST /v3/transactions/`](https://docs.didit.me/ru/transaction-monitoring/transactions) |
| Применение утверждённых вами критериев выявления | Наборы готовых правил и кастомные [правила](https://docs.didit.me/ru/transaction-monitoring/rules.md), каждое с контролируемым вами режимом работы | Правила в консоли или API правил |
| Получение результата проверки | Webhook-уведомления | `transaction.created` и `transaction.status.updated` |
| Проведение расследования | [Оповещения](https://docs.didit.me/ru/transaction-monitoring/alerts.md) и [кейсы](https://docs.didit.me/ru/transaction-monitoring/cases.md) с историей каждого действия | Управление кейсами в консоли |
| Подготовка отчёта | [Подготовка отчётов для ПФР](https://docs.didit.me/ru/console/case-management/fiu-reports.md) на основе данных кейса | Вкладка **Отчёты ПФР** в кейсе |

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "finance0001",
    "transaction_category": "finance",
    "transaction_details": {
      "direction": "outbound",
      "amount": "1200.00",
      "currency": "EUR"
    },
    "subject": { "entity_type": "person", "vendor_data": "user-123", "full_name": "John Doe" },
    "counterparty": { "entity_type": "person", "full_name": "Jane Doe" }
  }'
```

Два ограничения, о которых следует помнить:

* **Вы утверждаете критерии выявления.** Утверждение критериев для выявления подозрительных или необычных транзакций не может быть передано на аутсорсинг (статья 18(3)(f)). Проверяйте каждое подключаемое правило и фиксируйте его утверждение в своих внутренних политиках.
* **Вы подаёте отчёт.** Didit готовит файлы отчёта на основе данных кейса. Платформа ничего не отправляет в ПФР. Подачу отчёта выполняет ваш комплаенс-офицер через канал вашего ПФР.

## Храните записи, затем удаляйте

Статья 77 устанавливает вашу обязанность по хранению записей. Вы храните документы и сведения, полученные в рамках надлежащей проверки клиентов, записи проведённых вами оценок подозрений и записи транзакций в течение 5 лет. Этот срок начинается с момента прекращения деловых отношений, совершения разовой транзакции или отказа от установления отношений (Статья 77(3)). По истечении 5 лет вы удаляете персональные данные, если только не применяется другой закон или уполномоченный орган не потребует хранить конкретные записи дольше.

Отсчёт времени начинается с события в вашей системе: прекращения отношений. Didit не знает эту дату, поэтому настроенный вами срок хранения данных и запрашиваемые вами удаления определяете вы.

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Хранить записи сессий на протяжении всего срока действия обязанности | [Настройка хранения данных](https://docs.didit.me/ru/console/data-retention.md): период от 1 месяца до 10 лет или без ограничений | **Business Console → App Settings → Data retention** |
| Удалять данные по истечении 5-летнего периода | Удаление сессии по запросу | [`DELETE /v3/session/{sessionId}/delete/`](https://docs.didit.me/ru/sessions-api/delete-session) |
| Предоставлять материалы надзорному органу или аудитору | PDF-отчёт по каждой сессии и по каждому пользователю, массовый экспорт в CSV | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/ru/sessions-api/generate-pdf), [экспорт](https://docs.didit.me/ru/console/export-pdf-csv.md) |
| Сохранять подтверждения скрининга | Экспорт истории скрининга по каждой сессии | [Подтверждения постоянного мониторинга](https://docs.didit.me/ru/core-technology/aml-screening/continuous-monitoring-aml-screening.md#подтверждение-выполнения-мониторинга) |

**1. Выберите период хранения данных, который не может завершиться раньше времени**

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

**2. Зафиксируйте прекращение отношений**

Сохраните дату прекращения отношений, проведения транзакции или отказа в собственной системе. С этой даты начинается отсчёт ваших 5 лет.

**3. Удалите данные по истечении срока**

Вызовите `DELETE /v3/session/{sessionId}/delete/` для каждой сессии этого клиента. Удаление необратимо, а URL медиафайлов перестают работать.

> [!WARNING]
>
> **Журналы аудита и история скрининга сами по себе не покрывают 5-летнее обязательство.** Журналы аудита доступны от 30 дней до 3 лет в зависимости от вашего [тарифа](https://docs.didit.me/ru/console/audit-logs.md#хранение-данных), а история запусков скрининга доступна в течение двух лет по умолчанию. Если ваша политика хранения записей опирается на них, экспортируйте их в свои собственные записи до истечения этих сроков. Требованиям Статьи 77 соответствуют именно записи сессий в рамках вашей настройки хранения данных.

## Проверка автоматизированных решений человеком

Статья 76(5) разрешает вам принимать решения, вытекающие из автоматизированных процессов, включая профилирование и системы ИИ, при соблюдении трёх условий. Данные ограничиваются сведениями надлежащей проверки. Любое решение об установлении, отказе или сохранении деловых отношений, о проведении или отказе в разовой транзакции либо об изменении объёма надлежащей проверки подлежит существенному вмешательству человека. А клиент имеет возможность получить разъяснение решения и оспорить его.

| Требование | Функция Didit | Endpoint или настройка |
| - | - | - |
| Направлять кейсы человеку | Пороги и ветви сценария, которые завершаются статусом `"In Review"` | [Сценарии](https://docs.didit.me/ru/console/workflows.md) |
| Проверять доказательства и принимать решение | [Ручная проверка](https://docs.didit.me/ru/console/manual-review.md) с указанием причины отклонения и заметок проверяющего | Консоль или [`PATCH /v3/session/{sessionId}/update-status/`](https://docs.didit.me/ru/sessions-api/update-status) |
| Требовать второго проверяющего | [Проверка по принципу четырёх глаз](https://docs.didit.me/ru/console/case-management/four-eyes.md) в шаблоне кейса: другой сотрудник одобряет или отклоняет решение | Управление кейсами в консоли |
| Разъяснять результат | Результаты по каждой проверке, предупреждения и комментарии проверяющего к сессии | [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/ru/sessions-api/retrieve-session) |

```bash theme={null}
curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "new_status": "Approved",
    "comment": "Cleared after manual review by compliance team"
  }'
```

Статус сессии `"Approved"` или `"Declined"` является результатом настроенных вами проверок. Он служит исходными данными для вашего решения об онбординге, которое Статья 18(3) закрепляет за вами. Определите вместе с юристом, на каком этапе требуется вмешательство человека, а затем встройте этот шаг в сценарий и в собственный бэк-офис.

## Аутсорсинг

Статья 18 позволяет вам передавать на аутсорсинг поставщику услуг задачи, вытекающие из AMLR. Она устанавливает условия: вы уведомляете своего надзорного органа до того, как поставщик приступит к работе (статья 18(1)), вы сохраняете полную ответственность за переданные на аутсорсинг задачи (статья 18(2)), а также закрепляете условия в письменном соглашении и проводите регулярный контроль поставщика (статья 18(4)). Регламент также указывает, что использование стороннего программного обеспечения или доступ к базам данных и сервисам скрининга, когда вы выполняете требование самостоятельно, аутсорсингом не является (преамбула 47). То, под какую категорию подпадает использование Didit, зависит от способа применения. Руководящие принципы AMLA по аутсорсингу должны быть выпущены не позднее 10 июля 2027 года.

Шесть задач не могут быть переданы на аутсорсинг ни при каких обстоятельствах (статья 18(3)). Они остаются за вами:

1. Подготовка и утверждение общекорпоративной оценки рисков.
2. Утверждение внутренних политик, процедур и мер контроля.
3. Решение о присвоении клиенту риск-профиля.
4. Решение об установлении деловых отношений или проведении разовой транзакции.
5. Направление сообщений о подозрительной деятельности и отчётов на основе пороговых значений в подразделение финансовой разведки (FIU).
6. Утверждение критериев выявления подозрительных или необычных транзакций и действий.

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

Что внести в ваш реестр аутсорсинга в отношении Didit:

| Элемент | Что фиксировать | Где найти |
| - | - | - |
| Письменное соглашение (ст. 18(4)) | Ваш договор с Didit и соглашение об обработке данных (DPA) | Запросите соглашение об обработке данных (DPA) и описание технических и организационных мер у вашего представителя Didit |
| Делегированные задачи | Проверки в каждом выполняемом вами сценарии, с разбивкой по версиям сценария | [Сценарии](https://docs.didit.me/ru/console/workflows.md). Сессии и webhook содержат `workflow_id` и `workflow_version` |
| Сохраняемые за вами задачи | Шесть перечисленных выше задач с указанием ответственного лица в вашей организации | Ваши внутренние политики |
| Квалификация поставщика (ст. 18(4)) | Сертификации и аттестации | [Сертификации](https://docs.didit.me/ru/getting-started/certifications.md) |
| Местонахождение данных | По умолчанию данные обрабатываются и хранятся в ЕС. Локальная обработка внутри страны доступна на тарифе Enterprise | [Хранение данных](https://docs.didit.me/ru/console/data-retention.md#роль-и-место-обработки) |
| Регулярный контроль (ст. 18(4)) | Ваша выборочная проверка сессий, экспорты и история проверок с периодичностью, соответствующей критичности задачи | [Экспорты](https://docs.didit.me/ru/console/export-pdf-csv.md), [журналы аудита](https://docs.didit.me/ru/console/audit-logs.md) |
| Уведомление надзорного органа (ст. 18(1)) | Дата уведомления вашего надзорного органа до запуска в продакшн | С вашей стороны. Уведомление не означает, что надзорный орган принимает эту договорённость |

## Эталонный сценарий

Отправная точка для сценария онбординга физических лиц. Адаптируйте его под вашу оценку рисков.

**1. Создайте сценарий**

В Business Console перейдите в раздел **Сценарии** и создайте сценарий «знай своего клиента» (KYC). Используйте визуальный конструктор, если вам нужны ветви по странам или по результатам проверок.

**2. Выберите методы идентификации для каждой страны**

На шаге **Верификация личности** включите кошельки цифровой идентификации, доступные в обслуживаемых вами странах, а настройте сбор документов как маршрут для всех остальных. См. раздел [Методы верификации личности](https://docs.didit.me/ru/console/id-verification-methods.md).

**3. Привяжите документ к личности**

Для маршрута с проверкой документа добавьте **Проверка живости** и **Сравнение лиц**, а также **NFC**, если документ содержит чип.

**4. Проверьте адрес**

Добавьте **Подтверждение адреса** для клиентов, в чьих документах адрес не указан.

**5. Настройте скрининг и мониторинг**

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

**6. Запросите цель и источник средств**

Добавьте компонент **Анкеты** на основе шаблонов «Цель открытия счёта» и «Источник средств».

**7. Подпишитесь на события webhook**

Создайте адрес назначения webhook с подпиской на события `status.updated` и `data.updated`. См. раздел [Webhook](https://docs.didit.me/ru/integration/webhooks.md).

**8. Опубликуйте сценарий и скопируйте его ID**

Опубликуйте сценарий и используйте его `workflow_id` при создании сессий.

Создайте сессию:

```bash theme={null}
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "YOUR_KYC_WORKFLOW_ID",
    "vendor_data": "user-42",
    "callback": "https://yourapp.com/callback"
  }'
```

Ответ (`201 Created`):

```json theme={null}
{
  "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
  "session_kind": "user",
  "session_number": 1024,
  "session_token": "...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "workflow_id": "YOUR_KYC_WORKFLOW_ID",
  "vendor_data": "user-42"
}
```

Перенаправьте клиента по ссылке `url`. Когда по сессии сформировано решение, Didit отправляет webhook `status.updated`. Пример фрагмента:

```json theme={null}
{
  "event_id": "9c0c8b8a-1111-4222-9333-444444444444",
  "webhook_type": "status.updated",
  "timestamp": 1774970000,
  "created_at": 1774969994,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "status": "In Review",
  "workflow_id": "66666666-7777-8888-9999-000000000000",
  "workflow_version": 4,
  "vendor_data": "user_42",
  "decision": { "...": "see /sessions-api/retrieve-session" }
}
```

Проверьте подпись, привяжите логику идемпотентности к значению `event_id` и сверяйте `status` как точную строку с учётом регистра. Значения перечислены в разделе [Статусы верификации](https://docs.didit.me/ru/integration/verification-statuses.md). Затем запросите полное решение с помощью `GET /v3/session/{sessionId}/decision/` и передайте его лицу или процессу, принимающему решение об онбординге.

## Хронология

| Дата | Что происходит |
| - | - |
| 19 июня 2024 г. | AMLR, Регламент (ЕС) 2024/1624, опубликован в Официальном журнале ЕС |
| 9 июля 2024 г. | AMLR вступает в силу |
| 30 сентября 2026 г. | AMLA указывает дату в своём итоговом отчёте по проектам стандартов надлежащей проверки клиентов (объявлено 1 октября 2026 г.). Документ передан в Комиссию, но ещё не принят |
| 10 июля 2027 г. | Начало применения AMLR. Крайний срок для транспонирования государствами-членами шестой Директивы по борьбе с отмыванием денег, Директивы (ЕС) 2024/1640. Срок выпуска руководящих принципов AMLA по аутсорсингу |
| 2028 г. | AMLA начинает прямой надзор за отдельными финансовыми организациями. Первая группа ограничена 40 организациями |
| 10 июля 2029 г. | Требования AMLR начинают применяться к футбольным агентам и профессиональным футбольным клубам |

## Часто задаваемые вопросы

> [accordion] Когда начинает применяться AMLR?
>
> AMLR вступил в силу 9 июля 2024 года и будет применяться с 10 июля 2027 года. Для футбольных агентов и профессиональных футбольных клубов он начнет применяться с 10 июля 2029 года. До 10 июля 2027 года действуют национальные законы, имплементирующие текущую директиву.

> [accordion] В чем разница между AMLR, AMLD6 и AMLA?
>
> AMLR представляет собой Регламент (ЕС) 2024/1624. Он содержит правила для обязанных субъектов и применяется напрямую, без транспонирования в национальное законодательство. AMLD6 представляет собой Директиву (ЕС) 2024/1640. Она адресована государствам-членам и охватывает надзорные органы, реестры и штрафные санкции, а срок её транспонирования установлен до 10 июля 2027 года. AMLA является Органом по борьбе с отмыванием денег, созданным Регламентом (ЕС) 2024/1620 со штаб-квартирой во Франкфурте. Он разрабатывает технические стандарты и руководства, а с 2028 года будет напрямую контролировать выбранную группу финансовых организаций.

> [accordion] Разрешена ли по-прежнему удаленная верификация по документу, удостоверяющему личность?
>
> Да, при соблюдении определенных условий. Статья 22(6) называет два способа: документ, удостоверяющий личность, или eID со значительным или высоким уровнем доверия. Окончательный проект стандартов AMLA от 30 сентября 2026 года сохраняет удаленную верификацию по документу как альтернативу для случаев, когда от лица нельзя обоснованно ожидать очного предъявления документа и у него нет доступа к подходящему eID. Вы должны быть способны обосновать её использование и продемонстрировать меры защиты. Проект не указывает конкретную технологию и пока не вступил в силу как закон.

> [accordion] Являются ли технические стандарты окончательными?
>
> Нет. AMLA финализировал свой проект 30 сентября 2026 года и направил его в Европейскую комиссию. Он станет обязательным только после того, как Комиссия утвердит его и он будет опубликован в Официальном журнале, при этом Комиссия может внести в него изменения. Проект предполагает начало применения через шесть месяцев после вступления в силу, поэтому точная календарная дата пока отсутствует.

> [accordion] Обязательно ли принимать EUDI Wallet, и поддерживает ли его Didit?
>
> AMLR сам по себе указывает eID как один из двух способов верификации. Он не обязывает каждого обязанного субъекта принимать EUDI Wallet. Обязанность принимать его закреплена в регламенте eIDAS: частные доверяющие стороны, обязанные использовать строгую аутентификацию пользователей для онлайн-идентификации, принимают кошелёк по запросу пользователя не позднее чем через 36 месяцев после вступления в силу имплементирующих актов, а микро- и малые предприятия освобождены от этого требования. Относится ли это к вашему онбордингу, следует уточнить у ваших юристов. В Didit для EUDI Wallet указан статус **Скоро**. Кошельки, доступные в продакшене уже сегодня: MitID, BankID Sweden, Finnish Trust Network, Smart-ID и Mobile-ID.

> [accordion] Порог бенефициарного владения составляет 25% или 15%?
>
> Он составляет «25 % или более» акций, прав голоса или иной доли владения (статья 52(1)), при этом контроль оценивается параллельно. Статья 52(2) позволяет Комиссии снизить порог до максимум 15 % для категорий организаций с повышенным уровнем риска с помощью делегированного акта. Такого акта не существует. В Didit порог UBO настраивается в вашем сценарии KYB.

> [accordion] Как реализовать обновление данных раз в 1 год и раз в 5 лет?
>
> Сохраняйте класс риска клиента и дату последнего обновления в собственной системе, запускайте периодическую задачу по расписанию, которая отбирает клиентов с истекшим интервалом, и создавайте новую сессию с помощью `POST /v3/session/` с тем же `vendor_data`. Добавьте триггеры событий: статус `"Kyc Expired"`, webhook мониторинга или изменение, о котором сообщил клиент. Сроки в 1 год и 5 лет в статье 26(2) являются максимальными периодами.

> [accordion] Что можно передать на аутсорсинг?
>
> Такие задачи, как сбор идентификационных данных, проведение верификации, запросы к реестрам, скрининг и проведение мониторинга транзакций по утвержденным вами критериям. Шесть задач нельзя передавать на аутсорсинг: утверждение общекорпоративной оценки рисков, утверждение внутренних политик, определение профиля риска клиента, принятие решения об онбординге, подача отчетов в FIU и утверждение критериев выявления. Вы несете полную ответственность за процессы, переданные на аутсорсинг (статья 18(2)).

> [accordion] Как настроить хранение данных для правила 5 лет?
>
> Срок в 5 лет отсчитывается с момента прекращения отношений, а не с момента верификации клиента. В **Business Console → App Settings → Data retention** выберите период, достаточный для покрытия срока отношений плюс 5 лет, или оставьте его неограниченным. Отслеживайте дату окончания отношений в собственной системе и вызывайте `DELETE /v3/session/{sessionId}/delete/`, когда ваш срок истечет. Экспортируйте журналы аудита и историю скрининга, если ваша политика хранения записей опирается на них.

> [accordion] Обеспечивает ли использование Didit соответствие AMLR?
>
> Нет. Соответствие требованиям зависит от вашей программы в целом: вашей оценки рисков, ваших политик, ваших решений и ваших механизмов контроля. Didit предоставляет проверки, мониторинг и доказательную базу, на которых строятся эти компоненты программы. Сертификации или официального утверждения поставщиков или инструментов в рамках AMLR не существует.

## Связанные ресурсы

> [card] [Обзор решения для AMLR](https://didit.me/solutions/amlr)
>
> Взгляд со стороны бизнеса: на кого распространяется AMLR и как вписывается Didit.

> [card] [Методы верификации личности](https://docs.didit.me/ru/core-technology/id-verification/verification-methods.md)
>
> Захват документов, поиск без документов и цифровые кошельки удостоверений личности.

> [card] [Цифровые кошельки удостоверений личности](https://docs.didit.me/ru/core-technology/id-verification/digital-id-wallets.md)
>
> Доступность и уровень доверия для каждого кошелька.

> [card] [Верификация бизнеса (KYB)](https://docs.didit.me/ru/business-verification/overview.md)
>
> Поиск в реестрах, структура владения и ключевые лица.

> [card] [AML-скрининг](https://docs.didit.me/ru/core-technology/aml-screening/overview.md)
>
> Скрининг по санкциям, PEP и спискам наблюдения с постоянным мониторингом.

> [card] [Мониторинг транзакций](https://docs.didit.me/ru/transaction-monitoring/overview.md)
>
> Правила, оповещения, кейсы и подготовка отчётов для подразделения финансовой разведки.

> [card] [Анкеты](https://docs.didit.me/ru/core-technology/questionnaires/overview.md)
>
> Шаблоны для определения цели установления отношений и источника средств.

> [card] [Хранение данных](https://docs.didit.me/ru/console/data-retention.md)
>
> Сроки хранения и удаление по запросу.

> [card] [Webhook](https://docs.didit.me/ru/integration/webhooks.md)
>
> Типы событий, payload и проверка подписи.

> [card] [Цены](https://docs.didit.me/ru/getting-started/pricing.md)
>
> Оплата за проверку. Ознакомьтесь с актуальной ценой каждой функции.


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