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