PEP проверка: где рвётся процесс и что теряет компания
Скрининг клиентов рвётся не на подключении базы, а на разборе её выдачи. Нечёткое сравнение отдаёт совпадения по фамилии и году рождения — на потоке в несколько тысяч записей это сотни карточек в день. Аналитик просматривает первые десятки, остальные закрывает формальным признаком «не совпало», и именно в этом хвосте проходит реальный фигурант списка.
Вторая точка отказа — качество сопоставления. Один и тот же человек приходит в трёх транслитерациях, с девичьей фамилией, без отчества и с переставленными местами именем и фамилией. Дубли в базе не сводятся к мастер-записи, а порог срабатывания выбирается наугад: занизишь — очередь ручного разбора совпадений растёт быстрее штата, завысишь — снимаются настоящие попадания.
Третье и самое дорогое — отсутствие перепроверки. Статус присваивается на дату онбординга и дальше не пересчитывается: санкционные и PEP-перечни обновляются, а карточки клиентов и контрагентов остаются с прежним решением. Проверка контрагентов при этом живёт отдельным процессом со своими справочниками, и два контура не видят друг друга.
Компания узнаёт о расхождении из запроса банка или регулятора — уже как о нарушении, а не как о задаче. Все три места закрываются инженерно: версионирование перечней, пересчёт по событию обновления и разбор совпадений с обоснованием и журналом решений. Разбираем, как именно это устроено.
Что даёт выстроенный скрининг клиентов и контрагентов
Готовый скрининг превращает комплаенс из ручного процесса в проверяемый конвейер: каждый клиент и контрагент проходит сверку с санкционными и PEP-перечнями, а результат фиксируется с датой, версией списка и причиной решения. Источники подключаются как сервис: открытые реестры и коммерческие базы вроде OpenSanctions обновляются по расписанию, поэтому проверка идёт по актуальному срезу, а не по выгрузке месячной давности. Эффект виден в трёх метриках: срок онбординга, доля кейсов, ушедших на ручной разбор, и класс совпадений, которые система не пропускает.
Скорость онбординга и повторных запросов
Скрининг в реальном времени отвечает на запрос за секунды: сначала быстрая сверка по индексу, затем точечная проверка по совпавшим кандидатам. Повторное обращение к тому же контрагенту не запускает цикл заново — результат переиспользуется, пока не сменилась версия списка или не истёк заданный срок актуальности. Онбординг перестаёт зависеть от загрузки команды комплаенс: типовой клиент проходится в день обращения, а не ждёт очереди.
Меньше ручных разборов и ушедших отказов
Основной источник ручной работы — совпадения по фамилии без контекста. Оценка совпадения учитывает дату рождения, гражданство, год назначения на должность и попадание имени сразу в несколько перечней, а пороги настраиваются отдельно для PEP, санкционных списков и негативных упоминаний. Автоматизация комплаенс снижает долю ложных срабатываний, поэтому аналитик разбирает не весь поток, а только пограничные случаи — и добросовестные клиенты реже получают отказ из-за однофамильца.
Режимы скрининга: разовый, регулярный, непрерывный
Режим скрининга выбирают не по удобству, а по скорости изменения списков и риск-профилю клиента. Санкционные перечни и базы PEP обновляются чаще, чем клиент проходит онбординг, поэтому результат разовой проверки устаревает почти сразу после её завершения. Ниже — три режима и границы, за которыми каждый из них перестаёт работать.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Разовый скрининг на входе | низкий риск-профиль, редкие операции, длительный онбординг | снимок на дату: нет реакции на попадание клиента в листинг позже |
| Перепроверка базы клиентов по расписанию | действующая база с регулярной активностью, отчётность по регламенту | между прогонами окно в дни и недели; пиковая нагрузка на пакетную обработку |
| Непрерывный мониторинг | высокий риск, операции в реальном времени | нужен стабильный поток обновлений списков и обработка событий без пропусков |
Разовый скрининг на входе
Проверка выполняется при онбординге: сверка имени, даты рождения и документа с санкционными и PEP-перечнями, фиксация результата вместе с версией списка и настройками нечёткого сравнения. Это дешёвый и предсказуемый режим, но он отвечает только на вопрос «был ли клиент в списке на дату проверки». Транзакционный контроль и повторная сверка здесь не закрыты.
Непрерывный контроль и перепроверка базы
Скрининг превращается в поток: подписка на обновления перечней, пересчёт только затронутых записей, дельта-прогон по всей базе клиентов и постановка совпадений в очередь ручного разбора. Ключевые требования — повторный прогон не плодит дубли, у каждого решения остаётся след: кто, когда и по какой версии списка снял или подтвердил совпадение. Разовый и непрерывный режимы совместимы: первый закрывает вход, второй — весь срок жизни клиента.
Как мы внедряем: этапы работ от аудита до передачи
Внедрение комплаенс-проверки начинается не с загрузки списков, а с аудита клиентской базы. Без реального распределения совпадений правила настраиваются наугад: один набор пропускает PEP, другой даёт поток ложных срабатываний, который разбирают вручную. Мы идём от данных к правилам и только потом — к настройке.
Аудит базы и текущих правил
Проверяем полноту полей, дубли, варианты транслитерации, качество документов. Отдельно разбираем журнал прошлых срабатываний: сколько совпадений закрывалось вручную и по каким признакам — это показывает, где правила не работают.
Схема совпадений и очереди разбора
Правила раскладываем по уровням строгости: точное совпадение по документу, имя вместе с датой рождения, нечёткое сравнение транслитерации. У каждого уровня свой порог и очередь разбора: блокирующая проверка, ручной разбор или автоматическое закрытие с обоснованием.
- Аудит клиентской базы: объём, полнота полей, дубли, качество транслитерации.
- Инвентаризация текущих правил и журнала срабатываний — что уходило на ручной разбор и почему.
- Схема правил совпадений: уровни строгости, пороги, очереди разбора.
- Настройка: подключение списков, справочники, регламент обновления источников.
- Проверка на исторических данных: прогон прошлых клиентов, замер доли ложных срабатываний.
- Калибровка порогов по итогам прогона, фиксация регламента разбора спорных совпадений.
- Передача: документация, обучение разбору, порядок обновления списков и пересмотра порогов.
Что передаём на руки: регламенты, политики, настройки
Проект закрыт не в момент, когда проверка PEP отвечает на тестовых запросах, а когда ваша команда может менять правила и разбирать спорные срабатывания без нас. Поэтому в передачу входит не только сервис, но и слой эксплуатации: регламент комплаенс, политики доступа, документация по скринингу и журнал решений по каждой проверке. Ниже — артефакты, с которыми вы работаете самостоятельно.
- Регламент комплаенс — порядок запуска проверки, пороги совпадения, правила эскалации на ручной разбор и сроки реакции по уровням риска.
- Политики доступа — роли аналитика, проверяющего и администратора, матрица прав на справочники, выгрузки и изменение порогов.
- Документация по скринингу — как сопоставляются имена с санкционными и PEP-перечнями, как читать коэффициент совпадения и что делать с ложными срабатываниями.
- Журнал решений — кто, когда и на каком основании подтвердил или снял срабатывание; запись неизменяема и выгружается для внутреннего контроля.
- Справочники — источники списков, частота обновления, порядок ручного добавления записи.
- Чек-лист приёмки и план сопровождения — как проверить работу после релиза и что делать при обновлении внешнего перечня.
Схема данных и правила доступа
Описание схемы фиксирует, какие поля попадают в проверку, какие остаются во внутреннем контуре, а какие обезличиваются перед выгрузкой. Доступ к персональным данным выдаётся не «на всякий случай», а под конкретную задачу и с записью в журнале — это первое, что смотрит внутренний контроль.
Кейс: как снизили долю ложных срабатываний в потоке
Кейс комплаенс-команды платформы с потоком подключений и переводов: несколько тысяч проверок в сутки, значительная часть — физлица с трансграничными связями. Скрининг работал по точному совпадению строки с перечнями, поэтому очередь забивали омонимия фамилий, варианты транслитерации и устаревшие адреса, а аналитики разбирали однотипные сигналы вручную.
Что было до и что стало после
| Метрика скрининга | До | После |
|---|---|---|
| Доля ложных срабатываний | 74% | 18% |
| Заявок на ручной разбор в сутки | 1200 | 260 |
| Время до снятия с ручного разбора | 40 минут | 6 минут |
| Разбор одной заявки аналитиком | 25 минут | 8 минут |
Сопоставление перевели с точного совпадения строки на сравнение сущностей: имя с учётом транслитерации, дата рождения, страна, документ и роли в связанных компаниях. Списки PEP и санкционные перечни подтягиваются из OpenSanctions вместе с локальными списками регулятора, а вес совпадения считается по числу совпавших полей — сигнал по одной фамилии больше не встаёт в очередь наравне с полным совпадением.
Нагрузка на сотрудников комплаенс упала без расширения штата: очередь сократилась почти в пять раз, а освободившееся время ушло на разбор действительно рискованных случаев. Решение по каждой заявке по-прежнему принимает человек — система лишь ранжирует очередь, показывает причину срабатывания и хранит историю для проверяющего, поэтому доля пропущенных совпадений не выросла.
Чем отличается разовая PEP проверка от непрерывного контроля?
Разовая PEP проверка — это снимок на дату приёма на обслуживание: сверяем ФИО, дату рождения, страну и должность с перечнями публичных должностных лиц и фиксируем заключение. Снимок устаревает в тот же день, когда клиент меняет должность или выходит новая редакция перечня. Рекомендации ФАТФ требуют не однократной сверки, а актуального профиля риска на всём протяжении отношений.
Непрерывный контроль держится на двух механизмах: плановый пересмотр по риск-категории и событийные триггеры — обновление перечней, смена должности, публикация о клиенте. Каждое событие запускает переоценку: меняется категория риска, круг связанных лиц, глубина проверки источников средств. Без триггеров контроль вырождается в формальный ежегодный пересмотр, который не видит изменений между циклами.
Главная точка расхождения — частичное совпадение. При разовой проверке его разбирают один раз и закрывают решением, при непрерывном контроле поток совпадений приходит заново на каждом цикле, и без правил приоритизации очередь растёт пропорционально частоте пересмотра. Поэтому имена нормализуют: транслитерация, дедупликация профилей, оценка по совокупности признаков, а не по одной строке.
Технические сомнения: данные, доступы, ограничения
Инженерные возражения обычно касаются не самой идеи проверки, а её границ: откуда берутся данные, кто их видит и где метод перестаёт работать. Ниже — ответы на те, что чаще всего всплывают до старта.
Качество результата определяется не алгоритмом сравнения, а источником. Списки обновляются с разной частотой, часть записей приходит с разноязычными вариантами написания и неполными датами рождения — отсюда и разная доля ложных срабатываний.
Что делать, если в исходных данных есть пробелы?
Скрининг снижает риск, но не исключает его: он работает только по подключённым источникам. В документации фиксируем, какие списки подключены, как часто обновляются и какие категории записей покрывают. Если нужной юрисдикции в них нет — это видно до старта, а не после первой проверки.
Как разграничивается доступ к результатам?
Роли описываем по действиям, а не по отделам: кто запускает проверку, кто видит совпадение с указанием источника, кто снимает отметку вручную. Каждый просмотр записи и каждое решение попадают в неизменяемый журнал — проверку со стороны регулятора можно пройти без выгрузки всей базы.
Что с конфиденциальностью и хранением записей?
Персональные данные и вердикт хранятся раздельно: в рабочей базе остаётся ссылка на результат, а не сам документ. Срок хранения задаётся политикой — историю держим столько, сколько требует ваш внутренний регламент, дальше она вычищается автоматически.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы вернуться с оценкой проекта, а не с расплывчатым диапазоном, нужен ввод по данным и процессу проверки. Первый шаг — разбор задачи: смотрим, какие перечни PEP и санкционные списки вы используете, где проверка встаёт в клиентский путь, кто разбирает найденные совпадения.
На выходе вы получаете схему решения и план работ с этапами и критериями приёмки — по ним видно, что и в каком порядке делается, и можно сравнивать подходы, а не только сроки.
Что нужно от вас для старта и что мы отдаём на первом шаге:
- источники данных: какие перечни PEP и санкционные списки используются, в каком виде приходят выгрузки и с какой периодичностью обновляются;
- профиль проверяемого: физлицо, компания, связи и доли владения — до какой глубины обходим цепочку;
- правила срабатывания: пороги совпадения, транслитерация, обработка однофамильцев и полных тёзок;
- точки встраивания: первичная проверка при приёме клиента, повторная проверка, ручной разбор находок и эскалация;
- журнал и доступы: кто видит находки, кто подтверждает решение, что попадает в след для аудита;
- схема решения: поток данных, хранилище, обновление списков, поведение при недоступности источника;
- план работ: этапы, объём проверок на каждом, критерии приёмки и порядок отката при сбое.
Опишите задачу в свободной форме — вернёмся с разбором, схемой решения и планом работ по этапам.
