Перейти к основному содержанию
Регламент ЕС по борьбе с отмыванием денег (AMLR), Регламент (ЕС) 2024/1624, объединяет правила надлежащей проверки клиентов (CDD) в единый документ прямого действия. Он распространяется на кредитные и финансовые учреждения, включая поставщиков услуг, связанных с криптоактивами (CASP), поставщиков услуг в сфере азартных игр и других обязанных лиц, перечисленных в статье 3. Регламент вступил в силу 9 июля 2024 года и начнет применяться с 10 июля 2027 года. До этого момента продолжают действовать национальные законы, имплементирующие текущую директиву. Эта страница предназначена для разработчиков и комплаенс-инженеров, перед которыми стоит задача реализовать эти требования. В каждом разделе изложены требования регламента, указана статья и приведены шаг сценария Didit, API endpoint или webhook, которые можно использовать для соответствующей задачи. Обзор для бизнеса см. на странице решения AMLR. Дата последней проверки: 2 октября 2026 г.
Didit предоставляет проверки и доказательства. Вы остаетесь обязанным лицом. Вы определяете профиль риска клиента, принимаете решение об онбординге и несете полную ответственность за любые задачи, переданные на аутсорсинг (статья 18). Использование Didit само по себе не делает вашу компанию соответствующей требованиям AMLR. Эта страница не является юридической консультацией: согласуйте применение каждого правила к вашему бизнесу с юридическим консультантом и надзорным органом.

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

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

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

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

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

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

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

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

Решение, возвращаемое GET /v3/session/{sessionId}/decision/, содержит по одной записи на каждую проверку личности в id_verifications[].

Два пути

Уровень доверия, сообщаемый каждым кошельком, указан на странице Кошельки цифровой идентификации (Digital ID). Соответствует ли конкретная схема статье 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: Причина, по которой клиент прошёл верификацию по документу вместо eID, должна фиксироваться вами. Сохраняйте её в собственной системе или прикрепляйте к сессии через metadata при её создании.

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

Для юридического лица Статья 22(1)(b) требует указывать организационно-правовую форму и наименование, адрес места нахождения, законных представителей и, при наличии, регистрационный номер, налоговый номер и идентификатор юридического лица (LEI). Вы также обязаны идентифицировать бенефициарных владельцев и принять разумные меры для их проверки, чтобы понимать структуру владения и контроля (Статья 20(1)(b)). Бенефициарным владельцем является физическое лицо, прямо или косвенно владеющее «25 % или более» акций, прав голоса или иной доли владения (Статья 52(1)) либо контролирующее организацию через владение или иным образом (Статьи 51 и 53). Контроль оценивается параллельно с владением. Четыре момента, которые следует учитывать при проектировании:
  • Порог настраивается вами. В AMLR указано «25 % или более», а не «более 25 %». Порог UBO в сценарии настраивается, поэтому задайте его в соответствии с этим значением и пересмотрите его, если ваши внутренние правила строже.
  • Одного реестра недостаточно. Статья 22(7) требует обращаться к центральным реестрам в дополнение к верификации бенефициарных владельцев. Сообщение о расхождениях в реестр в течение 14 календарных дней (Статья 24) является вашей обязанностью.
  • Отсутствие данных в реестре не доказывает отсутствие владельцев у компании. В реестре может не быть записей о структуре владения для конкретной компании или страны. Если вы не выявили бенефициарного владельца, Статья 22(2) предписывает зафиксировать этот факт, а также установить и верифицировать высших должностных лиц.
  • Мониторинг реестров скоро появится. Непрерывный мониторинг изменений в реестрах пока недоступен. До его появления повторно запускайте верификацию бизнеса в соответствии с вашим графиком обновления данных.

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

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

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

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

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

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

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

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

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

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

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

Вызовите POST /v3/session/ с теми же vendor_data и вашим сценарием обновления данных, затем отправьте клиенту полученный url.
4

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

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

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

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

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

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

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

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

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

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

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

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

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

Вызовите DELETE /v3/session/{sessionId}/delete/ для каждой сессии этого клиента. Удаление необратимо, а URL медиафайлов перестают работать.
Журналы аудита и история скрининга сами по себе не покрывают 5-летнее обязательство. Журналы аудита доступны от 30 дней до 3 лет в зависимости от вашего тарифа, а история запусков скрининга доступна в течение двух лет по умолчанию. Если ваша политика хранения записей опирается на них, экспортируйте их в свои собственные записи до истечения этих сроков. Требованиям Статьи 77 соответствуют именно записи сессий в рамках вашей настройки хранения данных.

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

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

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

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

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

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

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

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

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

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

Проверьте адрес

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

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

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

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

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

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

Создайте адрес назначения webhook с подпиской на события status.updated и data.updated. См. раздел Webhook.
8

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

Опубликуйте сценарий и используйте его workflow_id при создании сессий.
Создайте сессию:
Ответ (201 Created):
Перенаправьте клиента по ссылке url. Когда по сессии сформировано решение, Didit отправляет webhook status.updated. Пример фрагмента:
Проверьте подпись, привяжите логику идемпотентности к значению event_id и сверяйте status как точную строку с учётом регистра. Значения перечислены в разделе Статусы верификации. Затем запросите полное решение с помощью GET /v3/session/{sessionId}/decision/ и передайте его лицу или процессу, принимающему решение об онбординге.

Хронология

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

AMLR вступил в силу 9 июля 2024 года и будет применяться с 10 июля 2027 года. Для футбольных агентов и профессиональных футбольных клубов он начнет применяться с 10 июля 2029 года. До 10 июля 2027 года действуют национальные законы, имплементирующие текущую директиву.
AMLR представляет собой Регламент (ЕС) 2024/1624. Он содержит правила для обязанных субъектов и применяется напрямую, без транспонирования в национальное законодательство. AMLD6 представляет собой Директиву (ЕС) 2024/1640. Она адресована государствам-членам и охватывает надзорные органы, реестры и штрафные санкции, а срок её транспонирования установлен до 10 июля 2027 года. AMLA является Органом по борьбе с отмыванием денег, созданным Регламентом (ЕС) 2024/1620 со штаб-квартирой во Франкфурте. Он разрабатывает технические стандарты и руководства, а с 2028 года будет напрямую контролировать выбранную группу финансовых организаций.
Да, при соблюдении определенных условий. Статья 22(6) называет два способа: документ, удостоверяющий личность, или eID со значительным или высоким уровнем доверия. Окончательный проект стандартов AMLA от 30 сентября 2026 года сохраняет удаленную верификацию по документу как альтернативу для случаев, когда от лица нельзя обоснованно ожидать очного предъявления документа и у него нет доступа к подходящему eID. Вы должны быть способны обосновать её использование и продемонстрировать меры защиты. Проект не указывает конкретную технологию и пока не вступил в силу как закон.
Нет. AMLA финализировал свой проект 30 сентября 2026 года и направил его в Европейскую комиссию. Он станет обязательным только после того, как Комиссия утвердит его и он будет опубликован в Официальном журнале, при этом Комиссия может внести в него изменения. Проект предполагает начало применения через шесть месяцев после вступления в силу, поэтому точная календарная дата пока отсутствует.
AMLR сам по себе указывает eID как один из двух способов верификации. Он не обязывает каждого обязанного субъекта принимать EUDI Wallet. Обязанность принимать его закреплена в регламенте eIDAS: частные доверяющие стороны, обязанные использовать строгую аутентификацию пользователей для онлайн-идентификации, принимают кошелёк по запросу пользователя не позднее чем через 36 месяцев после вступления в силу имплементирующих актов, а микро- и малые предприятия освобождены от этого требования. Относится ли это к вашему онбордингу, следует уточнить у ваших юристов. В Didit для EUDI Wallet указан статус Скоро. Кошельки, доступные в продакшене уже сегодня: MitID, BankID Sweden, Finnish Trust Network, Smart-ID и Mobile-ID.
Он составляет «25 % или более» акций, прав голоса или иной доли владения (статья 52(1)), при этом контроль оценивается параллельно. Статья 52(2) позволяет Комиссии снизить порог до максимум 15 % для категорий организаций с повышенным уровнем риска с помощью делегированного акта. Такого акта не существует. В Didit порог UBO настраивается в вашем сценарии KYB.
Сохраняйте класс риска клиента и дату последнего обновления в собственной системе, запускайте периодическую задачу по расписанию, которая отбирает клиентов с истекшим интервалом, и создавайте новую сессию с помощью POST /v3/session/ с тем же vendor_data. Добавьте триггеры событий: статус "Kyc Expired", webhook мониторинга или изменение, о котором сообщил клиент. Сроки в 1 год и 5 лет в статье 26(2) являются максимальными периодами.
Такие задачи, как сбор идентификационных данных, проведение верификации, запросы к реестрам, скрининг и проведение мониторинга транзакций по утвержденным вами критериям. Шесть задач нельзя передавать на аутсорсинг: утверждение общекорпоративной оценки рисков, утверждение внутренних политик, определение профиля риска клиента, принятие решения об онбординге, подача отчетов в FIU и утверждение критериев выявления. Вы несете полную ответственность за процессы, переданные на аутсорсинг (статья 18(2)).
Срок в 5 лет отсчитывается с момента прекращения отношений, а не с момента верификации клиента. В Business Console → App Settings → Data retention выберите период, достаточный для покрытия срока отношений плюс 5 лет, или оставьте его неограниченным. Отслеживайте дату окончания отношений в собственной системе и вызывайте DELETE /v3/session/{sessionId}/delete/, когда ваш срок истечет. Экспортируйте журналы аудита и историю скрининга, если ваша политика хранения записей опирается на них.
Нет. Соответствие требованиям зависит от вашей программы в целом: вашей оценки рисков, ваших политик, ваших решений и ваших механизмов контроля. Didit предоставляет проверки, мониторинг и доказательную базу, на которых строятся эти компоненты программы. Сертификации или официального утверждения поставщиков или инструментов в рамках AMLR не существует.

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

Обзор решения для AMLR

Взгляд со стороны бизнеса: на кого распространяется AMLR и как вписывается Didit.

Методы верификации личности

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

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

Доступность и уровень доверия для каждого кошелька.

Верификация бизнеса (KYB)

Поиск в реестрах, структура владения и ключевые лица.

AML-скрининг

Скрининг по санкциям, PEP и спискам наблюдения с постоянным мониторингом.

Мониторинг транзакций

Правила, оповещения, кейсы и подготовка отчётов для подразделения финансовой разведки.

Анкеты

Шаблоны для определения цели установления отношений и источника средств.

Хранение данных

Сроки хранения и удаление по запросу.

Webhook

Типы событий, payload и проверка подписи.

Цены

Оплата за проверку. Ознакомьтесь с актуальной ценой каждой функции.
Последнее изменение 7 ноября 2026 г.