AML-перевірка імен: практичний посібник для команд

У понеділок провайдер розрахунку заробітної плати починає роботу зі звичайною чергою реєстрацій. До ранку вівторка перевірка за санкційними списками створює стільки сповіщень, що перевірка доброчесних клієнтів зупиняється. Причиною стала не прихована санкційна мережа, а поширене ім'я в кількох варіантах транслітерації разом із порогом нечіткого зіставлення, налаштованим для іншого сегмента клієнтів.

Цей випадок показує головну проблему AML-перевірки імен. Складність не в тому, щоб надіслати ім'я провайдеру контрольних списків. Потрібна відтворювана система ухвалення рішень, яка працює з різними писемностями, псевдонімами, структурою власності, оновленнями списків, перевіркою аналітиком, аудиторськими доказами та збоями API. Водночас операційна команда не повинна обирати між надмірним шумом і пропущеним ризиком. У багатьох системах перевірки частка хибнопозитивних результатів становить близько 90–95%, а в деяких системах моніторингу на основі правил — 95–99% (Sanctions.io пояснює проблему хибнопозитивних результатів, MemberCheck розглядає налаштування моніторингу транзакцій).

Головний ворог — непрозорі типові налаштування: оцінка провайдера, яку ніхто не може розкласти на складові, поріг, який ніхто не може обґрунтувати, і запис про сповіщення, з якого неможливо визначити версію списку чи шлях нормалізації. Робочій системі потрібні вимірювана логіка, контрольовані зміни та інфраструктура, що зберігає докази від отримання даних до остаточного рішення.

Зміст

• Чому AML-перевірка імен дає збої в робочому режимі
  • Типові інженерні помилки
• Нормалізація імен до початку зіставлення
  • Порядок виконання, що зберігає докази
• Вибір алгоритмів нечіткого зіставлення
  • Групи методів та типові помилки
• Транслітерація та зіставлення різних писемностей
  • Детермінований процес
• Налаштування порогів за рівнем ризику та напрямом
  • Зміни конфігурації потребують контролю
• Сукупна оцінка, рішення та практичний приклад
  • Діапазони рішень
• Аудиторський слід, інтеграція API та перевірка контролів
  • Вибір моделі API за робочим процесом

Чому AML-перевірка імен дає збої в робочому режимі

Нічна обробка у провайдера розрахунку зарплат показала чотири одночасні помилки. Транслітерація імені «Muhammad» дала 14 варіантів латиницею, а поріг для роздрібного сегмента сприйняв кожен варіант як суттєвий збіг. Пакетна обробка створила 12 000 сповіщень і перевантажила чергу до того, як аналітики встигли відокремити шум від поширених імен та ймовірних санкційних збігів.

Це не аргумент на користь вузького зіставлення. Це показує, чому зіставлення треба сегментувати. Надто широке вікно Левенштейна створює збіги для поширених імен, а агресивне видалення символів може стерти відмінності, потрібні для правильного порівняння арабських імен. Часто модель сповіщень дає збій раніше, ніж самі дані контрольного списку.

Типові інженерні помилки

• Втрата під час нормалізації: видалення всіх символів поза ASCII до транслітерації знищує інформацію про писемність і може перетворити ім'я, яке можна відновити, на наближення без простежуваного походження.
• Невідповідний поріг: граничне значення для напряму з високим ризиком застосовують до великого роздрібного пакета або пакета зарплат, створюючи чергу, яку операційна команда не може опрацювати.
• Конфлікт оновлень: нічне оновлення санкційного списку накладається на реєстрацію клієнтів, тому два запити можуть перевірятися за різними станами списку без збереження використаної версії.
• Помилки поділу на сторінки: завдання імпорту може неправильно обробити сторінки, створити дублікати або пропустити записи під час оновлення списку OFAC SDN. Наслідком стає нерівномірне покриття перевірки, а не лише помилка відображення.

Правило 50 відсотків OFAC означає, що точної перевірки імен недостатньо. Компанія, якою заблоковані особи прямо або опосередковано володіють сукупно на 50% чи більше, вважається заблокованою, навіть якщо її назви немає у списку SDN (пояснення правила в OFAC FAQ). Тому перевірка має охоплювати кінцевих бенефіціарних власників і проміжні холдингові компанії та підсумовувати частки власності на всіх рівнях.

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

Команда також має визначити ознаки якісного контрольного списку ще до вибору рушія. Матеріал про ознаки хорошого контрольного списку допомагає оцінити якість джерел, дисципліну оновлень і зручність використання, а не лише назву набору даних. Для криптокоманд цей контроль має бути частиною ширшої операційної моделі відповідності вимогам AML, особливо коли транзакція може стосуватися клієнта, отримувача, гаманця або посередника.

Нормалізація імен до початку зіставлення

Якість зіставлення залежить від підготовки полів. Застосовуйте однаковий детермінований процес нормалізації до даних клієнтів і записів контрольного списку, зберігаючи початкові значення незмінними. Якщо дві системи використовують різні правила регістру, пунктуації або транслітерації, їхні оцінки не можна порівняти, а аналітики не зможуть відтворити результат.

Порядок виконання, що зберігає докази

1. Застосуйте нормалізацію Unicode NFKC. Вона зводить сумісні форми, зокрема лігатури, не видаляючи початкове значення.
2. Нормалізуйте регістр до поділу на лексеми. Перетворіть текст на узгоджене подання в нижньому регістрі, щоб регістр не впливав на межі лексем або перевірку рівності.
3. Виконайте декомпозицію та видаліть комбінувальні знаки. Застосуйте NFD, а потім видаліть комбінувальні знаки. Наприклад, Muḥammad перетвориться на muhammad.
4. Застосуйте настроювані списки винятків. Обробляйте звертання й частки на кшталт mr, al-, bin і ben відповідно до ринку та набору ризикових даних. Не закріплюйте їх у коді як універсально несуттєві.
5. Уніфікуйте пунктуацію. Приберіть повторювані пробіли та визначте однакове правило для дефісів. Вирішіть, чи abd-al-rahman стає однією лексемою або кількома, і застосовуйте це правило послідовно.
6. Індексуйте псевдоніми окремо. Зберігайте значення AKA та попередні імена в паралельному індексованому полі. Об'єднання псевдонімів з основним ім'ям створює штучні рядки й ускладнює тлумачення доказів.

Практичний запис може мати такий вигляд:

Початкове значення має зберігатися поруч із кожною похідною формою. Саме це дозволяє аналітику пояснити збіг після зміни правил, а не покладатися на повторну перевірку за поточними налаштуваннями, яка може дати інший результат. Не видаляйте всі символи поза ASCII до транслітерації. Збережіть ознаки писемності для наступного етапу й записуйте кожне перетворення в аудиторському сліді.

Вибір алгоритмів нечіткого зіставлення

Жоден алгоритм не дає надійної відповіді для всіх мов, структур імен і груп ризику. Точна рівність проста для пояснення, але пропускає відмінності транслітерації. Фонетичне зіставлення допомагає з англійськими прізвищами, проте гірше працює, коли відрізняються звукові системи та правила романізації. Методи відстані редагування допускають невеликі зміни, а методи лексем враховують змінений порядок імен, але можуть надавати надмірну вагу поширеним словам.

Практичне рішення — багаторівневий процес із видимими оцінками кожної складової. Не покладайтеся на сукупну оцінку провайдера з прихованими вагами. Якщо аналітики не бачать, що саме спричинило результат — спільний початок, псевдонім, збіг країни або лексем, — команда з відповідності не зможе впевнено налаштувати правило.

Групи методів та типові помилки

Точний збіг нормалізованих рядків має дуже високу точність, коли обидва записи використовують однакове подання. Повнота різко падає, щойно відрізняються транслітерація, порядок лексем, пробіли або псевдонім.

Soundex, Metaphone та Double Metaphone корисні як допоміжні сигнали для англійських прізвищ. Вони не мають бути основним рівнем рішення для арабських коренів, де форми Hussein і Husayn можуть відрізнятися попри спільне початкове ім'я.

Jaro-Winkler враховує перестановки й надає додаткову вагу спільним початкам рядків. Для латиниці практично почати з коефіцієнта префікса 0,1 і порога 0,88, а потім відкалібрувати їх на перевірених сповіщеннях. Для коротких лексем до 6 символів обмежена відстань Дамерау — Левенштейна з максимумом 2 редагувань може знаходити перестановки, але потребує захисту від коротких поширених імен.

Подібність Жаккара, косинусна подібність TF-IDF і перетин n-грам працюють зі зміненим порядком лексем, наприклад Smith John і John Smith. Вони можуть переоцінювати поширені частки та бізнес-терміни, тому коефіцієнт множини лексем краще використовувати як додатковий критерій, а не окремий вирок.

У тесті Федеральної резервної системи, на який посилається Sigma360, перевірка за допомогою LLM зменшила кількість хибнопозитивних результатів санкційної перевірки на 92% і покращила виявлення на 11% порівняно з найкращою базовою моделлю нечіткого зіставлення (опис тесту від Sigma360). Це не скасовує потреби в детермінованих контролях. Результат показує, що базовий рушій нечіткого зіставлення може створювати значний шум, а будь-яка складніша модель усе одно потребує пояснюваних вхідних даних, порогів і діапазонів перевірки.

Транслітерація та зіставлення різних писемностей

Санкційний список латиницею не може надійно зіставити дані арабською, кирилицею, китайською, перською, івритом або деванагарі без контрольованого процесу перетворення писемності. Порядок важливий: спочатку нормалізуйте джерело, потім транслітеруйте і лише після цього виконуйте нечітке зіставлення. Якщо універсальний транслітератор отримує неуніфіковані пунктуацію, діакритичні знаки та межі лексем, він може створювати правдоподібні, але непослідовно індексовані результати.

Детермінований процес

Спочатку збережіть original_name і визначте source_script. Застосуйте нормалізацію Unicode, уніфікацію регістру та доречну обробку діакритичних знаків. Потім зіставте особливості писемності за версіонованою таблицею транслітерації, створіть канонічну форму та збережіть повний ланцюг:

original_name → normalized_source → transliterated_form → canonical_tokens

Для арабської треба врахувати гамзу, та марбуту й варіанти аліфа. Мета не в тому, щоб вважати Ibrahim, Abe та Ebrahim лінгвістично тотожними в кожному контексті. Треба помістити відомі варіанти у порівнювану групу, зберігши оригінальне написання для аналітика. Для кирилиці потрібні явні правила для таких символів, як ё, й і ъ. Для CJK можуть знадобитися окремі подання піньїнем, каною та ієрогліфами замість перетворення всіх даних на один латинський рядок.

Ці правила потребують керування, а не одноразової зміни коду. Зберігайте версію таблиці, хеш вхідного значення та результати. Кешуйте результати транслітерації за хешем, щоб підтримувати стабільну затримку, але не втрачайте через кешування метадані про версію списку чи правил. Аналітик повинен мати змогу повторно оцінити ту саму особу після оновлення списку й побачити, що саме перевіряв попередній рушій.

CSSF повідомляла про неефективну перевірку за санкційними списками, зокрема про неналежні пороги нечіткого зіставлення та постійні недоліки перевірки імен (огляд річного звіту CSSF). Саме тому зіставлення різних писемностей є частиною системи контролю, а не необов'язковим завданням у черзі «інтернаціоналізації». Пропущений збіг у Ер-Ріяді чи Москві залишається помилкою перевірки, навіть якщо шлях для латиниці працює добре.

Налаштування порогів за рівнем ризику та напрямом

Один поріг дає збій у двох передбачуваних випадках. Якщо він занизький, реєстрація роздрібних клієнтів створює сповіщення для поширених імен. Якщо зависокий, перевірка напрямів із підвищеним ризиком втрачає повноту через незвичні варіанти транслітерації. Зберігайте пороги як дані конфігурації, пов'язані з ризиком клієнта, продуктом, напрямом, типом списку та події.

Використовуйте цю матрицю як початкову точку для впровадження, а не універсальне правило:

Перевірка PEP потребує окремого шляху рішень. Подібність імені має запускати збір додаткових ідентифікаторів, а не автоматичний негативний висновок. Робочий процес AML-перевірки PEP має залишатися окремим від санкційних рішень, навіть якщо обидва процеси використовують ту саму службу нормалізації ідентифікаційних даних.

Налаштування напрямів також потребують робочої телеметрії. Відстежуйте частоту сповіщень, підтверджених збігів, тривалість перевірки та вибіркові хибні пропуски за рівнем ризику, напрямом, типом списку й правилом. Поріг, який добре працює для внутрішніх гаманців, може бути непридатним для арабських, кириличних або CJK-імен після транслітерації. Перевіряйте ці зрізи окремо, щоб загальні показники черги не приховували втрату повноти.

Зміни конфігурації потребують контролю

Зберігайте пороги поза кодом застосунку. Кожна зміна має містити попереднє й нове значення, версію конфігурації, особу, яка схвалила зміну, причину, результат тестування та посилання на завдання. Перевіряйте кожну зміну на історичних сповіщеннях, а потім вибірково переглядайте закриті й передані на вищий рівень випадки. Менша черга не доводить покращення, якщо аналітики перестають бачити випадки, що потребують розслідування.

Вимірюйте частку підтверджень для кожного правила, а не лише загальний розмір черги. Мета контролю — обґрунтована якість виявлення з документальними доказами того, що кожен поріг прийнятно працює для відповідної групи. Повторно калібруйте правила, коли змінюються склад списків, структура клієнтів, обсяг за напрямами або поведінка транслітерації. Зберігайте попередні конфігурації, щоб аналітики могли відтворити давні рішення.

Сукупна оцінка, рішення та практичний приклад

Рівень ухвалення рішення має поєднувати незалежні сигнали, а не дозволяти одній функції подібності вирішувати справу. Сукупна оцінка може охоплювати Jaro-Winkler, коефіцієнт множини лексем, близькість дати народження, відповідність країни, докази псевдонімів і контекст власності. Для кожної складової треба визначити діапазон, вагу, поведінку за відсутності даних і пояснення.

В одному варіанті реалізації збіг країни додає 0,05, а збіг дати народження з відхиленням до двох років — 0,10. Ці значення не є універсальними регуляторними нормами. Це настроювані правила, які треба перевірити з огляду на якість даних установи та її прийнятний рівень ризику.

Діапазони рішень

• Понад 0,90: автоматично передати на перевірку другого рівня.
• Від 0,80 до 0,90: призупинити до рішення аналітика та, якщо можливо, запросити додаткові ідентифікатори.
• Нижче 0,80: автоматично закрити з вибірковим аудитом, якщо оцінку не перевизначає тригер щодо власності, псевдоніма, гаманця чи іншого правила.

Розгляньмо Mohammed Al-Hassan порівняно з Muhammad al Hasan зі списку OFAC SDN, датою народження 1972-03-15 і кодом країни Сирії. Нормалізація прибирає відмінності регістру та пунктуації, транслітерація узгоджує варіанти імені, а обидва рівні порівняння рядків дають сукупну оцінку 0,93. Дату народження та країну підтверджено, тому випадок автоматично передається на вищий рівень.

Запис аналітика має показувати не лише остаточну оцінку:

Такий поділ відрізняє пояснюване сповіщення від «чорної скриньки». Зберігайте версію правила ухвалення рішення, версію списку, конфігурацію порогів і рішення аналітика разом. Якщо згодом перевіряльник запитає, чому випадок передали на вищий рівень, система повинна відповісти за початковими доказами, а не повторно обчислювати результат за сьогоднішніми правилами.

Аудиторський слід, інтеграція API та перевірка контролів

Інтеграція перевірки не готова лише тому, що кінцева точка повертає оцінку. Вона готова, коли команда може відтворити рішення, безпечно повторити запит, визначити точний стан списку та довести, що збій не призвів до схвалення клієнта.

Незмінний аудиторський запис має містити:

request_id, screened_name, normalized_form, transliteration_chain, algorithms_run, окремі оцінки, composite_score, threshold_applied, matched_list_entry, list_version_timestamp, рішення (clear, match або refer), reviewer_id і review_notes.

Зберігайте ці записи щонайменше п'ять років у сховищі WORM. Строк зберігання та архітектура мають відповідати застосовному законодавству й внутрішнім правилам, але змінювані журнали застосунку не є достатньою заміною контрольованого сховища доказів.

Вибір моделі API за робочим процесом

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

До запуску перевірте роботу на історичних сповіщеннях, вибірку хибнопозитивних результатів, актуальність санкційних списків, періодичність повторної перевірки PEP і навчання з аварійного відновлення служби перевірки. Приймання інтеграції має завершуватися невдачею, якщо відповідь не містить list_version, повторні запити повертають різні оцінки без зміни правил або система не відрізняє тайм-аут провайдера від справжнього дозволу.

Для команд, що порівнюють засоби робочих процесів, простір інтеграцій Donely є корисним прикладом того, як пов'язані системи показують стан інтеграції та операційну відповідальність. Сам API перевірки має залишатися документованим, версіонованим і придатним до тестування, як описано в цьому посібнику з API для AML-перевірки.

Така сама модель контролю діє, коли перевірка виходить за межі імен клієнтів. Правило власності OFAC потребує аналізу бенефіціарних власників, а в криптоопераціях слід також враховувати агентів, уповноважених підписантів і адреси гаманців. Вимоги ЄС до переказів криптоактивів передбачають передавання повних даних відправника й отримувача для кожного переказу без мінімального порога, а санкційна перевірка має супроводжувати ці дані. Перевірена, але санкційна сторона все одно означає порушення санкцій, а не відповідність Travel Rule (Chainalysis пояснює Travel Rule, SecurePoint описує аналіз власності OFAC, Blockchain Analysis розглядає перевірку гаманців).

BroLabel може надавати AML-перевірку через інтегрованого провайдера відповідності як частину інфраструктури, що також охоплює BroSettlement, BroWallet, гаманці AI-агентів, контроль через Co-Signer, розгорнутий у клієнта, MPC-підписання, WebSocket-події, незмінний операційний журнал, підтримку звірки та API-доступ з обмеженими правами. Під час перевірки робочої системи зіставте ці модулі з власними межами правил, зокрема ідемпотентністю, схваленням за ролями, повторним відтворенням подій, доказами журналу та контролями виплат.

Перед увімкненням робочих процесів використайте цей посібник як інженерний перелік приймальних перевірок: закріпіть версії списків, збережіть початкові й похідні ідентифікаційні дані, протестуйте варіанти різних писемностей, версіонуйте пороги та відпрацюйте збої провайдера. Потім перегляньте, як BroSettlement може поєднати докази перевірки з гаманцями, розрахунками, операційним журналом і подієвими контролями у вашому продукті.