Совпадение - кандидат, а не вердикт. Решите, ваш ли это клиент и имеет ли значение, и зафиксируйте обоснование так, чтобы решение выдержало аудит.
Задайте два вопроса по порядку: это мой клиент (match score) и имеет ли это значение (risk score и категория). Большинство совпадений не проходят первый вопрос - совпадающие имена против очень больших списков. Фиксируйте обоснование в любом случае; именно след решений читает аудитор.
#Совпадение - это кандидат
Задача проверочного механизма - показать любого, кто потенциально может быть в списке. Решить, действительно ли это так, и что с этим делать, - ваша работа. Предупреждение POSSIBLE_MATCH_FOUND означает ровно то, что написано.
#Шаг 1: это действительно ваш клиент?
Сравните идентифицирующие данные из совпадения с тем, что установила верификация:
| Сравните | Почему это помогает |
|---|---|
| Дату рождения | Самый сильный различитель. Несовпадение обычно все решает |
| Гражданство и страну | Совпадение в стране, с которой у вашего клиента нет никакой связи |
| Полное имя, включая отчества и вторые имена | Частичное совпадение имени - главный источник ложных срабатываний |
| Любой идентификатор в записи о совпадении | Там, где список его публикует |
Распространенные имена дают большое количество совпадений с низкой уверенностью по санкционным и PEP-спискам - это не дефект, а именно то, как работает проверка по имени. Если ваша очередь забита такими случаями, ваш порог match score установлен слишком низко. См. как понимать результаты AML-проверки.
Здесь важна транслитерация. Имя из нелатинского алфавита можно романизировать несколькими корректными способами, поэтому один и тот же человек может встречаться под написаниями, которые не совпадают текстуально, а разные люди могут схлопнуться в одно и то же написание. В таких случаях придавайте больший вес дате рождения и гражданству.
#Шаг 2: имеет ли это значение?
В разделе AML выберите Подтвердить совпадение или Не совпадает; несколько результатов можно исключить вместе. Изменение записывается в Рецензии и требует права изменения проверок. Затем вынесите решение по сессии и запишите причину.
- Совпадение по санкциям. Самое серьезное. Обрабатывайте по вашей собственной санкционной процедуре; это не то решение, которое стоит принимать походя.
- PEP. PEP - не преступник. В большинстве режимов статус PEP запускает усиленную должную осмотрительность - дополнительную информацию, источник происхождения средств, согласование на уровне руководства - а не отказ. Автоматическое отклонение PEP - это политическое решение, и обычно неудачное.
- RCA. Родственник или близкий партнер PEP, проверяется по той же причине и обычно обрабатывается так же.
- Adverse media. Прочитайте размеченную категорию. Однократно упомянутое обвинение - не приговор, и ваша политика должна их различать.
- Страновой или геополитический риск. Обычно это входные данные для оценки риска, а не готовое решение.
#Шаг 3: зафиксируйте решение
Разберите совпадение в консоли, добавив заметку с обоснованием. Это как раз то, что будет иметь значение позже: аудитора куда меньше интересует ваш процент совпадений, чем то, принимались ли решения последовательно и были ли они задокументированы.
Пишите заметку так, будто через два года ее прочитает кто-то другой, а вас рядом не будет, - потому что так и будет. «Дата рождения отличается на 14 лет, другое гражданство, совпадение отклонено» - полезно. «Не совпадение» - нет.
Каждое действие фиксируется в журнале аудита на 365 дней. См. использование журналов аудита.
#Как снизить число ложных срабатываний, не потеряв бдительность
Если включены управление делами и проверка двумя сотрудниками, процесс требует второго проверяющего. Доступность зависит от настроек дела и разрешений.
#Согласование по принципу «четырех глаз»
Если ваш процесс требует, чтобы AML-решение подтверждали два проверяющих, Didit поддерживает флоу «четырех глаз», где второй человек должен подтвердить решение. См. проверка по принципу четырех глаз.
#Мониторинг будет возвращать совпадения
При включенном постоянном мониторинге ранее одобренный клиент может позже дать новое совпадение и вернуться в статус In Review. Это работа функции, а не регресс - и это значит, что разбор совпадений нужно организовать как постоянный процесс, а не разовую задачу при онбординге. См. постоянный AML-мониторинг.
#Тренировка до того, как это станет реальностью
В sandbox есть два AML-сценария: decline_aml_hit создает совпадение, которое приводит к отклонению, а review_aml_possible_match создает совпадение с меньшей уверенностью, которое попадает в статус In Review с заполненной записью совпадения - та же схема, что и у реального совпадения, включая разбивку оценки. Используйте их, чтобы провести свою команду через процесс разбора, прежде чем реальный клиент будет ждать решения. См. тестирование в sandbox.
Не нашли ответ? Поговорите с человеком.
Укажите ID организации и ID сессии, о которой спрашиваете.