Как построить процесс скрининга по санкционным спискам: от совпадений по именам к проверке, пригодной для аудита

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

В обсуждении на r/ComplianceOps о сбое сервиса скрининга описывалась ситуация: после того как поставщик стал недоступен, транзакции массово ушли в очередь, команды временно скачивали официальные списки, а правила ручной обработки заранее не были определены. Пост и ответы не проверялись независимо и не отражают общую практику финансовых организаций, но поднимают здравый вопрос для проектирования продукта: что выдаёт продукт для скрининга — результаты поиска или процесс принятия решений, который можно отследить как в штатном, так и в деградированном режиме?

Официальный список — источник, а не окончательный вердикт

OFAC Sanctions List Service предоставляет такие точки входа, как SDN, сводный список Non-SDN, настраиваемые наборы данных и исторические файлы изменений, и отдаёт данные списков в форматах для скачивания. Слой загрузки должен сохранять исходные списки, идентификаторы записей, время публикации, время скачивания, хеши файлов и версии парсера. Только тогда система сможет позднее ответить, какая версия списка использовалась при конкретной проверке.

У одного субъекта могут быть основные имена, слабые псевдонимы, адреса, гражданство, даты рождения, идентификационные номера или идентификаторы судов и воздушных судов. Продукт не должен склеивать эти поля в одну длинную строку, чтобы затем выдать непрозрачную оценку. Слой нормализации должен сохранять типы полей и исходные значения из источника, формируя нормализованные представления для поиска; любая транскрипция, удаление пунктуации или транслитерация должны быть объяснимы.

Записи в списках не покрывают весь объём комплаенс-требований. В разъяснениях OFAC по правилу 50 процентов отмечается, что некоторые не включённые в списки организации также могут считаться заблокированными, если одному или нескольким лицам под санкциями в совокупности принадлежит доля 50 процентов или более. Проверка одних лишь названий контрагентов не заменяет анализ структуры владения. Продукт должен разделять прямые совпадения со списками и проверку цепочек владения и не делать выводов о последних на основе поиска по именам без данных о долях.

Оценка сходства лишь отбирает кандидатов

В OFAC FAQ 246 поясняется, что Sanctions List Search применяет нечёткую логику только к полю имени, а для остальных полей использует посимвольное сопоставление. Иными словами, оценка по имени служит сигналом для отбора кандидатов, а не вероятностью риска по совокупности полей.

Продукт может расширять отбор за счёт имён, псевдонимов и транслитераций, а затем использовать даты рождения, адреса, гражданство, юрисдикции регистрации, документы, удостоверяющие личность, или типы субъектов, чтобы помочь аналитикам различать кандидатов. Однако расхождения в полях нужно трактовать с учётом качества данных: отсутствие года рождения не означает несовпадения, другой адрес может быть просто прежним местом нахождения, а конфликт типов «физическое лицо» и «юридическое лицо» обычно служит более сильным сигналом для исключения. Интерфейс должен показывать сравнение полей бок о бок, а не единственную оценку [87].

Рекомендуем предусмотреть как минимум четыре категории результатов:

• Ожидает проверки: имя или псевдоним соответствует критериям отбора, но дополнительных полей недостаточно.
• Кандидат, которого можно исключить: аналитик исключает его на основании явных различий в полях, фиксируя обоснование и срок действия решения.
• Эскалация: ключевые поля совпадают или связи владения требуют решения комплаенс-офицера.
• Результат недоступен: запрос неполный, данные списка устарели или входных данных недостаточно, поэтому статус «пройдено» показывать нельзя.

Автоматическое закрытие ложных срабатываний требует особой осторожности. Субъект, ранее исключённый как тёзка, не остаётся исключённым при новой версии списка, обновлённом адресе или новом удостоверении личности. Надёжные правила исключения совпадений должны быть привязаны к идентификаторам объекта, подтверждающим полям, применимым спискам и условиям истечения срока действия.

Качество входных данных определяет качество скрининга

Если системы на предыдущих этапах передают только усечённое имя получателя платежа, даже сложная логика на бэкенде не восстановит недостающие идентификационные данные. API скрининга должны возвращать подсказки о качестве входных данных: не указана страна, неизвестен тип субъекта, имя, возможно, обрезано из-за длины поля, удалён корпоративный суффикс или формат идентификатора не распознан. Тогда бизнес сможет запросить дополнительные данные, а не снижать пороги снова и снова.

Для физических лиц, компаний, судов и воздушных судов используются разные модели полей. Если втиснуть все объекты в [name + country], регистрационные номера компаний, даты рождения людей и номера IMO судов теряют смысл. Единый интерфейс может использовать общую обёртку, но каждый тип объекта должен сохранять собственные надёжные идентификационные поля.

Необходимо также соблюдать ограничения, связанные с конфиденциальностью. Поля, необходимые для скрининга, не оправдывают бессрочного хранения данных клиентов. Исходные документы, удостоверяющие личность, извлечённые поля, запросы на скрининг и выводы аналитиков требуют ролевого контроля доступа и отдельных сроков хранения. Наше руководство по проектированию единого API данных поможет определить границы между исходными доказательствами и бизнес-действиями, но не заменит оценку требований конкретной юрисдикции и допустимых целей обработки.

Непрерывный мониторинг — это не ежедневные повторяющиеся оповещения

После обновления списка система должна определить добавленные, изменённые и удалённые записи и только затем повторно проверить объекты, которые могли быть затронуты. Без стабильных идентификаторов исходных записей и сравнения версий система рискует принять изменение форматирования имени за новое совпадение или пропустить новые псевдонимы и поля идентификаторов.

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

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

Работу в деградированном режиме нужно спроектировать до инцидента

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

Правила деградированного режима должны быть заранее утверждены руководителями бизнеса и комплаенса: какие процессы приостанавливаются автоматически, где допускается только сохранение черновиков, когда включается ручная маршрутизация и в каком порядке обрабатываются накопившиеся задачи на повторную проверку. Технические команды не должны во время инцидента решать на ходу, разблокировать ли средства или подключать ли клиентов. OFAC Compliance Commitments Framework называет оценку рисков, внутренний контроль, тестирование и аудит, а также обучение ключевыми компонентами комплаенс-программы; продукты для скрининга должны давать доказательства для этих организационных мер контроля, а не претендовать на их замену.

После восстановления нужно сформировать перечень для догоняющего скрининга: объекты и транзакции за период сбоя, использованные тогда версии списков, изменились ли результаты повторной проверки и кто разбирал расхождения. Наше руководство по ошибкам API и самовосстановлению поможет спроектировать повторные попытки, пути деградации и очереди исключений, но реальные правила разблокировки должны определять уполномоченные сотрудники.

При проверке MVP важен цикл анализа, а не ноль ложных срабатываний

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

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

В статье рассматриваются превращение санкционных списков в продукт и инженерные меры контроля; она не является юридической или комплаенс-консультацией и не означает, что [EveryInfra] выпустила сервис санкционного скрининга. Главный результат санкционной системы — не метка «пройдено», а чётко очерченный процесс принятия решений, который учитывает неопределённость, допускает проверку уполномоченными лицами и может быть воспроизведён спустя годы.