Розробка sanctions screening: де ламається перевірка
Перевірка контрагентів у крипті ламається не на підключенні, а в момент, коли платіж уже ініційовано. Скринінг адрес запускається синхронно з виведенням коштів, зовнішні списки — OFAC, ЄС, локальні регулятори — відповідають із різною затримкою та за різними правилами. Операція стає в чергу, клієнт бачить, що виплата не надійшла, підтримка отримує перший тікет.
Друга точка відмови — хибні спрацювання. Збіг за прізвищем під час транслітерації, адреса, пов’язана з міксером через п’ятого контрагента, гаманець біржі з неоднорідною історією входів — усе це йде аналітику на ручний розбір.
За потоку в сотні операцій на добу черга зростає швидше, ніж команда встигає її закривати, і перевірка перетворюється на постійний затор на виході.
Ціна передбачувана: затримка виплат, відхід корпоративних клієнтів туди, де перевірки непомітні, ручна праця на потоці.
Окремо — регуляторний ризик: на перевірці потрібно показати не факт наявності скринінгу, а обґрунтування за кожним рішенням, включно з тими, де спрацювання визнали хибним і пропустили платіж.
Розробка sanctions screening — це якраз про те, щоб розвести ці вузли: перевірка до ініціювання платежу, оцінка ризику за рівнем і сумою, прозорі правила ескалації замість ручного «на око». Нижче розбираємо, де саме проходить межа між автоматичним рішенням і роботою аналітика.
Що дає власний screening-контур
Власний контур перевірок будується навколо даних, які ми контролюємо: адресні мітки з Chainalysis, офіційні санкційні переліки та внутрішні стоп-листи зводяться в один потік, а правила зіставлення описуються конфігурацією, а не скриптом на стороні.
Автоматизація перевірок перестає бути чорною скринькою — частка рішень без участі людини стає вимірюваною та керованою величиною.
На практиці 85-95% перевірок закривається автоматично, і це не налаштування раз і назавжди: пороги чутливості змінюються разом із профілем ризику майданчика.
Скоринг ризику відсікає хибні збіги — якщо ім’я збіглося, а країна, дата народження та документ розходяться, спрацювання знімається без інженера. Людині залишаються випадки з реальною невизначеністю.
Черга ручного розбору отримує не сирий потік, а відранжовані випадки: із причиною спрацювання, ланцюжком транзакцій та історією адреси. Тому розбір одного збігу йде за один прохід, а не за три системи поспіль, і час на спрацювання падає з десятків хвилин до одиниць.
Окремо закривається клас відмов, який найдорожчий: перевірка, що мовчки перестала ловити адресу після зміни формату довідника.
Кожне правило зіставлення версіонується та проганяється на накопичених спрацюваннях до бойового викату — регрес видно заздалегідь, а не за підсумками розбору.
Кожне рішення зберігає обґрунтування: хто, коли і за яким правилом зняв або підтвердив ризик — цей слід і запитують під час перевірки з боку регулятора.
Способи підключення переліків і правила зіставлення
Переліки можна отримувати напряму від власника, через консолідоване джерело або вести власною курованою копією — від цього залежить затримка оновлення, обсяг ручного розбору та повнота покриття.
| Варіант підключення | Коли підходить | Обмеження |
|---|---|---|
| Прямі вивантаження у власників: OFAC SDN, консолідований список ЄС, UN, національні переліки | Потрібна першоджерельна повнота та посилання на офіційну публікацію | У кожного своя схема полів і свій графік публікації — потрібен окремий розбір кожного файлу |
| Консолідований агрегатор | Швидкий старт, єдина схема записів, дедуплікація вже зроблена постачальником | Затримка між публікацією та потраплянням в агрегатор, залежність від чужого розкладу |
| Внутрішній курований реєстр | Свої ризик-записи та зняті хибні спрацювання для повторного використання | Ручний супровід, потрібен регламент поповнення та відповідальний за нього |
Формати вивантажень різняться (XML, CSV з власною схемою), тому шар завантаження тримаємо окремо від шару зіставлення: зміна схеми не повинна ламати правила пошуку.
Оновлення забираємо дельта-файлами за розкладом, при зміні структури — повне перезавантаження снапшота з версіонуванням, щоб у журналі залишилося, на якій версії переліку ухвалено рішення щодо клієнта.
Режими зіставлення та поріг
Зіставлення імен починається з нормалізації: регістр, діакритика, транслітерація, перестановка «прізвище — ім’я», ініціали, дати народження та громадянство як додаткові ознаки.
Далі йде нечітке порівняння з порогом збігу: надто низький поріг дає потік хибних спрацювань, надто високий — ризик пропустити запис.
Пороги задаємо окремо для блокувальних та інших переліків, а спрацювання вище другого порогу йдуть аналітику на розбір, а не блокуються автоматично.
Частота оновлення списків вибирається за профілем ризику: щоденне дельта-опитування закриває більшість сценаріїв, на блокувальних переліках інтервал коротший.
Етапи впровадження: від аудиту процесів до передачі
Впровадження скринінгу починається не з коду, а з аудиту процесів комплаєнсу: важливо зрозуміти, де зараз ловиться санкційний збіг, які списки підключено і як часто вони оновлюються, хто зупиняє операцію і що потрапляє в журнал.
За підсумками аудиту видно, які перевірки дублюються, де дані губляться між системами і які точки потоку доведеться закрити. Далі робота йде ітераціями — від схеми до передачі в експлуатацію.
- Аудит процесів комплаєнсу. Розбираємо поточні перевірки: джерела даних, ручні кроки, строки розбору спрацювань, історію відмов та інцидентів. Фіксуємо, які операції сьогодні проходять без перевірки взагалі.
- Схема перевірок. Визначаємо точки вбудовування — реєстрація клієнта, вхідна та вихідна транзакція, виведення коштів. Узгоджуємо формати подій, ролі та права, поведінку системи при недоступності зовнішнього списку.
- Налаштування правил і порогів. Підбираємо логіку порівняння імен: транслітерація, перестановка частин, нечітке зіставлення, вага збігу. Налаштовуємо рівні ризику та черги ручного розбору, щоб аналітик бачив лише значущі спрацювання.
- Тестовий прогін на історії. Проганяємо накопичений масив операцій, звіряємо результат із рішеннями комплаєнс-офіцерів, рахуємо частку хибних спрацювань і пропусків. За цією звіркою калібруємо пороги, а не «на око».
- Регламент перевірки. Описуємо порядок розбору: строки реакції, критерії ескалації, підстави для блокування, обов’язкова фіксація рішення. Регламент узгоджується з чинною політикою і лягає в основу навчання команди.
- Передача в експлуатацію. Віддаємо конфігурації, схему інтеграції, інструкції для аналітиків і дашборд з метриками. Перші тижні супроводжуємо, поки команда не вийде на самостійний режим.
Ключовий критерій готовності — не запущений сервіс, а передбачувана робота: відомо, скільки операцій іде на ручний розбір і чому. Обговоріть задачу — повернемося з оцінкою та планом за етапами.
Комплект схем, регламентів і доступів на виході
Після запуску в команди замовника залишається не лише робочий контур перевірок, а й повний комплект артефактів: за ними новий інженер або фахівець з комплаєнсу вводиться в систему без звернення до нас.
Документація прив’язана до змін — правка правил або підключення нового джерела списку оновлює опис тією ж зміною.
- Схема інтеграції: точки підключення до транзакційного контуру та зовнішніх джерел списків, формати запитів і відповідей, поведінка при недоступності джерела.
- Схема потоків перевірок: шлях від появи операції до рішення, черги, точки логування та строки зберігання результатів.
- Документація з перевірок: правила зіставлення — пороги, транслітерація, розбір нечітких збігів, тести на історичних спрацюваннях.
- Матриця доступу: ролі аналітика, старшого перевіряючого, адміністратора правил і аудитора — що кожна читає, змінює та підтверджує.
- Регламент розбору збігів: строки реакції за рівнями ризику, склад картки, умови ескалації, хто ухвалює фінальне рішення.
- Журнал змін правил: хто і навіщо змінював пороги або список винятків, з відкатом конфігурації до попередньої ревізії.
- Інструкції для зміни: порядок чергування, дії при блокуванні джерела, передача незакритих спрацювань.
Артефакти перевіряємо на навчаннях: піднімаємо стенд, проганяємо сценарії з недоступним джерелом і потоком хибних збігів. Якщо за інструкцією рішення ухвалюється у відведений час — комплект вважаємо прийнятим.
Кейс: як скоротили хибні спрацювання вдвічі
У клієнта — криптобіржі з потоком операцій по кількох мережах — ручна перевірка вже не покривала обсяг. Зіставлення було зашите жорстко: будь-який збіг за ім’ям або адресою йшов аналітику, розбір займав до 40 хвилин, і черга зростала швидше, ніж її розбирали.
Ми перебудували маршрут перевірки на три кроки: звірка за санкційними списками (OFAC SDN, EU, OFSI, UN), збагачення адрес даними Chainalysis та розрахунок оцінки ризику за налаштовуваними вагами.
Пороги та правила розбору винесено в конфігурацію, тому чутливість змінюється без випуску нової версії.
Показники до і після
| Метрика | До | Після |
|---|---|---|
| Частка автоматичних рішень | ~35% | ~80% |
| Розбір одного збігу | до 40 хвилин | 6–9 хвилин |
| Ручна черга за добу | сотні звернень | одиниці |
| Час реакції на збіг | години, вручну | хвилини, автоматично |
Хибні спрацювання скоротилися вдвічі: збіги імені, які знімаються датою народження або країною, ідуть в автоматичне схвалення із записом у журнал. Кожне рішення зберігає, яке правило і яка версія списку його породили — це знімає питання під час перевірок регулятора.
Окремо включили постійний моніторинг: при оновленні списку вся база клієнтів перевіряється заново, влучання самі надходять у чергу. Раніше це робили вибірково та вручну, тому частина збігів спливала із затримкою.
Чим разова перевірка адреси відрізняється від постійного моніторингу?
Разова перевірка адреси — це знімок на конкретну дату: один запит до аналітичних реєстрів, санкційних переліків і списків нелегальних сервісів, результат якого фіксується в картці клієнта.
Для вхідного платежу або приймання на обслуговування такого знімка достатньо: він підтверджує, що на дату перевірки адреса чиста, і залишає слід для аудиту.
Але мітка — не властивість гаманця, а стан: адреса, чиста на момент приймання, пізніше може бути пов’язана з міксером, потрапити до переліку нової юрисдикції виду OFAC SDN або отримати переказ від кластера, який визнали шахрайським заднім числом.
Разова перевірка дивиться назад і не відстежує зміни. Тому там, де відносини з клієнтом тривають місяцями, вводиться постійний моніторинг гаманців: адреси перевіряються за розкладом і за подіями — велика транзакція, зміна юрисдикції, оновлення переліків.
Кожна повторна перевірка порівнює поточний профіль ризику з попереднім знімком і піднімає алерт на дельті: зросла категорія ризику, з’явився прямий або непрямий зв’язок із підсанкційною адресою, змінився власник кластера.
Другий режим потрібен не всім. Він обов’язковий для ліцензованих обмінників і кастодіальних сервісів, роботи з депозитами клієнтів, тривалих відносин і високих лімітів — там відмова від повторних перевірок означає, що перші ознаки ризику з’являться лише в регулятора.
Разова перевірка виправдана для разового платежу без подальших зобов’язань: моніторинг там не дає нічого, крім зайвого шуму.
Інженерно моніторинг будується як надбудова над перевіркою: дельта-порівняння вердиктів, щоб не проганяти всю базу при кожному оновленні реєстрів, кеш міток із датою актуальності, черга алертів і журнал усіх версій рішення — при запиті регулятора видно, що саме і коли ми знали про клієнта. Далі розбираємо, як такий контур збирається.
Технічні сумніви: збіги, навантаження, доопрацювання
Інженерні сумніви на цьому етапі майже завжди однакові: чи не загубляться перевірки на сплеску операцій, чи не перетвориться звірка імен на нескінченну чергу хибних спрацювань, чи можна змінювати правила без перевикату сервісу і як це сяде на облікову систему замовника. Проєктувати це потрібно до першого релізу — переробити потім дорожче.
Коротко закриваємо чотири пункти нижче; решту розберемо разом із нашим інженером на созвоні за вашою схемою процесів.
Схожі імена дають хибні збіги — що з цим робити?
Порівняння йде не за рядком цілком: ім’я нормалізується — єдиний алфавіт, регістр, відсікання титулів і службових приставок — і лише потім звіряється нечітко, з налаштовуваним порогом схожості.
Дату народження, громадянство та країну підключаємо як уточнювальні ознаки, тому аналітик отримує короткий список кандидатів замість сотні однофамільців.
Чи витримає система пікове навантаження?
Перевірки йдуть у чергу: обробники забирають завдання та додаються в міру зростання її глибини, тому сплеск дає зростання затримки, а не загублені записи. Звернення до зовнішніх переліків обмежуємо за швидкістю та кешуємо на короткий строк, щоб не впертися в квоту.
Як доопрацьовувати правила після запуску?
Правила — це дані, а не код: новий перелік, змінений поріг або додаткова ознака вносяться в конфігурацію та версіонуються. Перед увімкненням правило проганяється тіньовим режимом на історичних даних — видно, скільки спрацювань і хибних позначок воно додасть.
Як проходить інтеграція з обліковою системою?
Працюємо і через програмний інтерфейс у реальному часі, і обміном файлами за розкладом — вибір залежить від того, як влаштований потік операцій.
Запити ідемпотентні, при обриві завдання повторюється, статус перевірки повертається в облікову систему, а рішення з обґрунтуваннями лягають у незмінюваний журнал для аудиту.
Обговоримо задачу та повернемося з оцінкою і планом
Щоб оцінка обсягу робіт була предметною, а не усередненою за ринком, потрібен короткий ввід від вашої команди. Якщо частина пунктів поки відкрита — це нормально, розберемо разом на созвоні.
- Які активи та мережі обслуговуєте: блокчейни, типи токенів, адреси гаманців і контрактів.
- Звідки надходять транзакції: біржа, кастодіальний сервіс, платіжний шлюз, обмінник.
- Як перевірка влаштована зараз: на якому етапі дивляться адресу, чи є ручні черги на розбір.
- Вимоги регулятора та внутрішні правила: звітність, строки зберігання даних, хто відповідає за блокування.
- Куди вбудовувати результат: інтерфейс оператора, власний програмний інтерфейс, облікові системи.
- Хто з боку замовника приймає спірні випадки та затверджує порогові правила оцінки ризику.
У відповідь повертаємося з оцінкою обсягу робіт і планом впровадження: етапи, залежності, склад команди та точки, де потрібне ваше рішення.
Окремо показуємо варіанти на вибір — від швидкого запуску перевірки адрес до повного контуру з розслідуваннями та звітністю, щоб ви зіставили строки та глибину контролю.
Передача в експлуатацію йде окремим етапом: регламенти розбору спірних випадків, контроль хибних спрацювань, навчання операторів. Опишіть задачу — обговоримо деталі та повернемося з планом.
