Что требует AMLR: краткий обзор
Сквозной процесс
Ваш бэкенд создает сессию, пользователь проходит сценарий, Didit отправляет вам уведомление, и вы получаете полное решение. Решение об онбординге остается за вашей командой. Мониторинг продолжается после завершения онбординга.Когда применяется надлежащая проверка
В статье 19 указано, когда вы обязаны применять надлежащую проверку клиентов: при установлении деловых отношений; при разовой транзакции на сумму не менее 10 000 евро в рамках одной операции или нескольких связанных транзакций; при возникновении подозрений в отмывании денег или финансировании терроризма независимо от суммы; а также при сомнениях в достоверности ранее полученных идентификационных данных. В некоторых секторах действуют более низкие пороги: 1 000 евро для разовых переводов средств и для CASP, 3 000 евро для разовых операций с наличными (как минимум идентификация и проверка) и 2 000 евро в сфере азартных игр. CASP обязан как минимум идентифицировать и верифицировать клиента при разовой транзакции на сумму менее 1 000 евро. Didit не принимает решение о применении триггера. Вы выполняете маршрутизацию по типу и сумме транзакции в своем собственном коде, а затем запускаете соответствующий сценарий.Идентификация и верификация физических лиц
Статья 22(1) перечисляет данные, которые вы обязаны хранить о физическом лице: все имена и фамилии, место и полную дату рождения, гражданства, национальный идентификационный номер при наличии, обычное место жительства и, при наличии, налоговый номер. Затем статья 22(6) указывает два способа верификации личности: документ, удостоверяющий личность, паспорт или эквивалентный документ, либо электронную идентификацию (eID), соответствующую уровням доверия eIDAS «существенный» (substantial) или «высокий» (high), совместно с соответствующими квалифицированными доверительными услугами.Данные в решении
Решение, возвращаемоеGET /v3/session/{sessionId}/decision/, содержит по одной записи на каждую проверку личности в id_verifications[].
Два пути
Что говорят проекты технических стандартов об удалённой верификации
Регуляторные технические стандарты (RTS) по надлежащей проверке клиентов в соответствии со статьёй 28(1) разрабатываются Управлением по борьбе с отмыванием денег (AMLA). Итоговый отчёт AMLA датирован 30 сентября 2026 года, а о нём было объявлено 1 октября 2026 года. Это финальный проект, представленный в Европейскую комиссию. Он не принят и не имеет силы закона. Комиссия всё ещё может внести в него изменения, а проект предполагает применение через шесть месяцев после его вступления в силу. Этот проект рассматривает два способа из статьи 22(6) как предусмотренные по умолчанию. Удалённая верификация с помощью документа является альтернативным решением для случаев, когда от лица нельзя обоснованно ожидать очного предъявления документа и оно не имеет доступа к подходящей eID (проект статьи 7(1)). Если вы используете эту альтернативу, проект требует, чтобы вы могли обосновать причину и продемонстрировать своему надзорному органу наличие защитных мер в данном решении (проект статьи 7(2) и 7(3)). Проект технологически нейтрален: в нём не называются конкретные технологии. Как защитные меры из проекта соотносятся с тем, что фиксирует сессия Didit: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)).status.updated и data.updated.
Настройте в собственной системе обновление данных с учётом периодов в 1 и 5 лет
График актуализации зависит от присвоенного вами уровня риска, и это решение нельзя передать на аутсорсинг. Didit не хранит присвоенный вами класс риска и не планирует периодическое обновление за вас.Сохраняйте класс риска и дату последнего обновления
vendor_data, которые вы отправляете в Didit.Запускайте запланированную задачу
Создавайте новую сессию
POST /v3/session/ с теми же vendor_data и вашим сценарием обновления данных, затем отправьте клиенту полученный url.Реагируйте на сопутствующие события
"Kyc Expired", webhook мониторинга, переводящий сессию в "In Review", а также изменения, о которых сообщил сам клиент, как триггеры для досрочного обновления данных.Цель деловых отношений и источник средств
Перед установлением деловых отношений или проведением разовой транзакции статья 25 обязывает выяснить цель и предполагаемый характер таких отношений или операции. При необходимости вы собираете информацию о цели и экономическом обосновании, предполагаемом объёме операций, источнике средств, направлении средств, а также о роде деятельности или профессии клиента. Формулировка «при необходимости» означает, что глубина проверки определяется риск-ориентированным подходом. Усиленная комплексная проверка может дополнительно потребовать подтверждения источника благосостояния (статья 34(4)).Мониторинг транзакций и отчётность
Постоянный мониторинг охватывает транзакции, совершаемые в ходе деловых отношений, обеспечивая их соответствие имеющимся у вас сведениям о клиенте (статья 26(1)). Если вы знаете, подозреваете или имеете достаточные основания подозревать, что средства получены преступным путём либо связаны с финансированием терроризма, вы направляете сообщение в своё подразделение финансовой разведки (ПФР) в соответствии со статьёй 69.- Вы утверждаете критерии выявления. Утверждение критериев для выявления подозрительных или необычных транзакций не может быть передано на аутсорсинг (статья 18(3)(f)). Проверяйте каждое подключаемое правило и фиксируйте его утверждение в своих внутренних политиках.
- Вы подаёте отчёт. Didit готовит файлы отчёта на основе данных кейса. Платформа ничего не отправляет в ПФР. Подачу отчёта выполняет ваш комплаенс-офицер через канал вашего ПФР.
Храните записи, затем удаляйте
Статья 77 устанавливает вашу обязанность по хранению записей. Вы храните документы и сведения, полученные в рамках надлежащей проверки клиентов, записи проведённых вами оценок подозрений и записи транзакций в течение 5 лет. Этот срок начинается с момента прекращения деловых отношений, совершения разовой транзакции или отказа от установления отношений (Статья 77(3)). По истечении 5 лет вы удаляете персональные данные, если только не применяется другой закон или уполномоченный орган не потребует хранить конкретные записи дольше. Отсчёт времени начинается с события в вашей системе: прекращения отношений. Didit не знает эту дату, поэтому настроенный вами срок хранения данных и запрашиваемые вами удаления определяете вы.Выберите период хранения данных, который не может завершиться раньше времени
Зафиксируйте прекращение отношений
Удалите данные по истечении срока
DELETE /v3/session/{sessionId}/delete/ для каждой сессии этого клиента. Удаление необратимо, а URL медиафайлов перестают работать.Проверка автоматизированных решений человеком
Статья 76(5) разрешает вам принимать решения, вытекающие из автоматизированных процессов, включая профилирование и системы ИИ, при соблюдении трёх условий. Данные ограничиваются сведениями надлежащей проверки. Любое решение об установлении, отказе или сохранении деловых отношений, о проведении или отказе в разовой транзакции либо об изменении объёма надлежащей проверки подлежит существенному вмешательству человека. А клиент имеет возможность получить разъяснение решения и оспорить его."Approved" или "Declined" является результатом настроенных вами проверок. Он служит исходными данными для вашего решения об онбординге, которое Статья 18(3) закрепляет за вами. Определите вместе с юристом, на каком этапе требуется вмешательство человека, а затем встройте этот шаг в сценарий и в собственный бэк-офис.
Аутсорсинг
Статья 18 позволяет вам передавать на аутсорсинг поставщику услуг задачи, вытекающие из AMLR. Она устанавливает условия: вы уведомляете своего надзорного органа до того, как поставщик приступит к работе (статья 18(1)), вы сохраняете полную ответственность за переданные на аутсорсинг задачи (статья 18(2)), а также закрепляете условия в письменном соглашении и проводите регулярный контроль поставщика (статья 18(4)). Регламент также указывает, что использование стороннего программного обеспечения или доступ к базам данных и сервисам скрининга, когда вы выполняете требование самостоятельно, аутсорсингом не является (преамбула 47). То, под какую категорию подпадает использование Didit, зависит от способа применения. Руководящие принципы AMLA по аутсорсингу должны быть выпущены не позднее 10 июля 2027 года. Шесть задач не могут быть переданы на аутсорсинг ни при каких обстоятельствах (статья 18(3)). Они остаются за вами:- Подготовка и утверждение общекорпоративной оценки рисков.
- Утверждение внутренних политик, процедур и мер контроля.
- Решение о присвоении клиенту риск-профиля.
- Решение об установлении деловых отношений или проведении разовой транзакции.
- Направление сообщений о подозрительной деятельности и отчётов на основе пороговых значений в подразделение финансовой разведки (FIU).
- Утверждение критериев выявления подозрительных или необычных транзакций и действий.
Эталонный сценарий
Отправная точка для сценария онбординга физических лиц. Адаптируйте его под вашу оценку рисков.Создайте сценарий
Выберите методы идентификации для каждой страны
Привяжите документ к личности
Проверьте адрес
Настройте скрининг и мониторинг
Запросите цель и источник средств
Подпишитесь на события webhook
status.updated и data.updated. См. раздел Webhook.Опубликуйте сценарий и скопируйте его ID
workflow_id при создании сессий.201 Created):
url. Когда по сессии сформировано решение, Didit отправляет webhook status.updated. Пример фрагмента:
event_id и сверяйте status как точную строку с учётом регистра. Значения перечислены в разделе Статусы верификации. Затем запросите полное решение с помощью GET /v3/session/{sessionId}/decision/ и передайте его лицу или процессу, принимающему решение об онбординге.
Хронология
Часто задаваемые вопросы
Когда начинает применяться AMLR?
Когда начинает применяться AMLR?
В чем разница между AMLR, AMLD6 и AMLA?
В чем разница между AMLR, AMLD6 и AMLA?
Разрешена ли по-прежнему удаленная верификация по документу, удостоверяющему личность?
Разрешена ли по-прежнему удаленная верификация по документу, удостоверяющему личность?
Являются ли технические стандарты окончательными?
Являются ли технические стандарты окончательными?
Обязательно ли принимать EUDI Wallet, и поддерживает ли его Didit?
Обязательно ли принимать EUDI Wallet, и поддерживает ли его Didit?
Порог бенефициарного владения составляет 25% или 15%?
Порог бенефициарного владения составляет 25% или 15%?
Как реализовать обновление данных раз в 1 год и раз в 5 лет?
Как реализовать обновление данных раз в 1 год и раз в 5 лет?
POST /v3/session/ с тем же vendor_data. Добавьте триггеры событий: статус "Kyc Expired", webhook мониторинга или изменение, о котором сообщил клиент. Сроки в 1 год и 5 лет в статье 26(2) являются максимальными периодами.Что можно передать на аутсорсинг?
Что можно передать на аутсорсинг?
Как настроить хранение данных для правила 5 лет?
Как настроить хранение данных для правила 5 лет?
DELETE /v3/session/{sessionId}/delete/, когда ваш срок истечет. Экспортируйте журналы аудита и историю скрининга, если ваша политика хранения записей опирается на них.Обеспечивает ли использование Didit соответствие AMLR?
Обеспечивает ли использование Didit соответствие AMLR?