Скринінг у реальному часі: що це вимагає від інфраструктури

Кожного ранку ви відкриваєте чергу алертів, і половина з них — вчорашні операції, які треба було зупинити вчора.

Чому пакетна обробка більше не працює під FATF і санкційним режимом?

Пакетна обробка раз на добу створює вікно уразливості: між оновленням списку OFAC і запуском ночного джоба проходять години, під час яких заборонений контрагент може пройти платіж. FATF Recommendation 10 та Interpretive Note to Recommendation 15 (FATF, 2023) вимагають, щоб фінансові установи застосовували заходи відповідно до ризику до виконання операції, а не пізно. Практика показує: банки-кореспонденти відмовляють у обробці, якщо ви не можете довести, що перевірка відбувалася в момент ініціювання SWIFT MT103.

Яка архітектура даних витримує навантаження на піку?

Відповідь: event-driven архітектура з аппенд-онлі логом (Kafka / Pulsar), де кожна зміна у санкційному реєстрі — це подія, яка миттєво розсилається до всіх сервісів скринінгу. Монолітні БД з الليلними ETL не дають консистентності: версія списку в платіжному шлюзі відрізняється від версії в CRM, і аудитор знаходить розбіжність. NKCSPFR у липні 2026 р. підкреслила, що ринкові інфраструктури віртуальних активів мають забезпечувати синхронізацію стану реєстрів у реальному часі (NKCSPFR, 2026-09-16, https://www.nssmc.gov.ua/ua-holova-nktspfr-pytannia-ne-v-tomu-chy-rehuliuvaty-virtualni-aktyvy-a-iak/). Це прецедент для всього фінсектору.

Як організувати версіонування списків без хаосу?

Кожен запит до скринінгу має нести заголовок: X-Sanctions-List-Version: EU-2026-09-16T14:30:00Z; OFAC-2026-09-16T12:00:00Z; UA-2026-09-16T10:15:00Z. Сховище рішень (decision log) зберігає цю версію разом із хешем запиту та результатом: match / no-match / review. Коли регулятор запитує «чому пропустили компанію X 15 вересня о 14:32», ви видаєте лог за 30 секунд, а не збираєте логи з п'яти систем за тиждень. EBA у своїх Guidelines on ML/TF risk factors (EBA/GL/2022/01, оновлено 2024) вимагає можливості відтворювати стан знань установи в момент операції.

Де лягає межа між автоматичним блокуванням і ескалацією до аналітика?

Чітке правило: авто-блок — тільки при точному збігу (exact match) на основному ідентифікаторі (LEI, SWIFT BIC, єдиний державний реєстр). Усі fuzzy-match, псевдоніми, пар셜-збігі по імені — на ескалацію з SLA 15 хвилин для платежів і 4 години для онбордингу. Хибні спрацювання зростають експоненційно, якщо пушите fuzzy в авто-блок: команди тонуть у ручному розборі, а справжні ризики проходять. Детальніше про баланс автоматизації та людського фактору — у статті «Автоматизація фінансового моніторингу: що справді можна віддати машині».

Які інфраструктурні метрики стежити щодня?

Ці метрики стають артефактами для الداخلي аудиту і для відповідей банкам-кореспондентам. Коли ви пишете листа на запит correspondent bank, ви додаєте цю таблицю як додаток — це скорочує кол-во follow-up запитань на 60–70%.

Як інтегрувати скринінг у процесс онбордингу, щоб не гальмувати бізнес?

Послідовність: 1) пре-скрінг на етапі KYC-форми (клиєнт ще не підписав договір) — легковажний API-клиєнт у браузері, 2) повний скринінг бенефіціарів і структури власності перед підписанням — асинхронний таск з вебхуком у CRM, 3) пост-підписаний безперервний моніторинг (ongoing) з інкрементальними оновленнями. Ключ: онбординг не блокується на скринінгу — блокується лише активація лімітів. Це дозволяє комерційному відділу працювати, а комплаєнсу — мати час на якісний розбір складних структур власності.

Що змінює введення реєстру бенефіціарів і закон про віртуальні активи в Україні?

Закон України «Про санкції» (стаття 15-1, редакція 2024) та постанови НБУ №64, №417 вимагають верифікації бенефіціарів через єдиний державний реєстр (ЄДР/ЄДРПОУ) і реєстр бенефіціарів. NKCSPFR у вересні 2026 р. ухвалила рішення щодо регламентування VASP, включаючи обов'язок реальночасової перевірки контрагентів проти санкційних списків (NKCSPFR, 2026-09-16, https://www.nssmc.gov.ua/ua-protydiia-zlovzhyvanniam-ta-ievrointehratsiia-kliuchovi-rishennia-nktspfr/). Для банків і фінтех це означає: API до реєстрів має бути в критичному контурі, а не в периметрі batch-обробки. Падіння API Державного реєстру не може бути причиною зупинки всього онбордингу — потрібен fallback на кешовану версію з TTL ≤ 4 хв і явним позначенням source=cached.

Як будувати аудит-шлях, який висточить перевірку FATF / НБУ?

Кожне рішення (allow / block / review) — це immutable запис: timestamp UTC, user_id або system_id, версії всіх списків, вхідні параметри запиту, скор моделі (якщо ML), текстове обґрунтування (для review — обов'язкове). Логи пишуться в append-only сховище (WORM storage / immutable S3 / Kafka compacted topic) з терміном зберігання ≥ 7 років. При перевірці ви видаєте filtered view за entity_id або transaction_id за секунди. Це не «для галочки» — це єдиний спосіб довести, що ви не пропустили змогусаний платіж через версію списку, яка не встигла поширитися.

Чекліст: готовність інфраструктури до реальночасового скринінгу

1. Event-driven шина даних розгорнута і пройдена навантажувальними тестами (10x пікового трафіку).
2. Версіонування списків реалізовано на рівні API-контракту (заголовок версії в кожному запиті/відповіді).
3. Decision log — immutable, пошукуваний за entity_id, transaction_id, list_version, timestamp.
4. SLA ескалації задокументовано, вимірюється, відображено в дашборді керівника комплаєнсу.
5. Fallback-ланка на кешовані версії реєстрів з явним позначенням та TTL ≤ 4 хв.
6. Тестовий набор з синтетичними match / near-match / false-positive кейсами, що проганяється в CI/CD при кожному деплої.
7. Документація для кореспондентів — one-pager з архітектури, версіонуванням, SLA, контактами ескалації.

FAQ

Чи обов'язково блокувати платіж автоматично при exact match?

Так, для основних ідентифікаторів (LEI, BIC, код ЄДРПОУ) — авто-блок є стандартом де-факто. Для іменних збігів без ідентифікатора — лише ескалація.

Яку частоту оновлення списків вважати мінімальною?

OFAC, EU, UK оновлюють списки щоденно, іноді кілька разів на день. Інфраструктура має підхоплювати зміну за хвилини після публікації офіційного джерела.

Як обробляти ситуацію, коли API реєстру бенефіціарів недоступне?

Використовуйте кешовану версію з TTL 4 хвилини, позначайте відповідь source=cached, ескалацій на ручний перевірку після відновлення API. Не блокуйте онбординг повністю.

Чи потрібен окремой скринінг для крипто-операцій?

Так. NKCSPFR вимагає від VASP реальночасової перевірки проти санкційних списків. Архітектура має підтримувати перевірку адрес гаманців (blockchain analytics) паралельно з перевіркою легальних осіб.

Як довести банку-кореспонденту, що скринінг відбувається в реальному часі?

Надайте архітектурну діаграму, логи латентності (P50/P99), приклад decision log з версіями списків, SLA ескалації. Це стандартний запит у DDQ (Due Diligence Questionnaire).

Що робити, якщо fuzzy-модель дає занадто багато хибних спрацювань?

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

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