AI-скринінг контрагентів: де він помиляється передбачувано

Щодня ви дивитеся на дашборд скринінгу і питаєте себе: чи можна довірити зеленому прапорцю, чи все одно треба лізти в реєстри власноруч?

Чому AI пропускає реальні санкційні зв'язки?

AI не бачить контроль, якщо він не зафіксований у відкритих реєстрах. Алгоритм порівнює імена з базою санкцій, але не відновлює ланцюг власності через трьох-чотири правні шари, де кожен шар зареєстрований у різній юрисдикції. ICIJ у вересні 2026 року документував випадок, коли американська адміністрація видала ліцензію компанії з зв'язками до донора для роботи з підсанкційним російським банком — перевірка автоматизованих баз не виявила кінцевого бенефіціара через складну структуру власності (https://www.icij.org/news/2026/09/trump-administration-gave-firm-with-ties-to-ballroom-donor-the-green-light-to-do-business-with-a-sanctioned-russian-bank/). У українській практиці це виглядає так: українська ТОВ належить кіпрській холдинговій, та — БВІ-структурі, за якою стоїть особа з підсанкційним паспортом, але в єдиному реєстрі бенефіціарів фігурує лише nominee-директор.

Де розмитий пошук генерує хвилі хибних спрацьовувань?

Фамілії «Іваненко», «Коваленко», «Шевченко» у поєднанні з популярними іменами дають десятки тисяч збігів у санкційних списках. Алгоритм не розрізняє контекст: це однакова людина чи тісник. Географічні збіги — мista з однаковими назвами в Україні, Росії, Білорусі, Казахстані — створюють додатковий шум. Комплаєнс-команда витрачає 60–80% робочого часу на розслідування тривог, які виявилися «Іваном Івановим з іншого міста». Це не помилка моделі — це обмеження даних, які модель має на вході.

Як відсутність єдиного ідентифікатора ламає логіку скринінгу?

У України фізична особа має РНОКПП, юридична — ЄДРПОУ. Але санкційні листи OFAC, EU, UK оперують прізвищами, датами народження, паспортами — без єдиного ключа. Коли алгоритм пробує зматчити "Олексій Петренко, 1975 р.н." з базою OFAC, він не знає, чи це той самий Олексій Петренко, що фігурує в українському реєстрі бенефіціарів. Транслітерація (Petrenko / Petrenko / Petrenka), зміна прізвища після шлюбу, використання другого паспорта — усе це створює розірв, який AI не закриває без додаткових даних про документ, адресу, телефон, email, історію адрес.

Які дані відсутні в комерційних базах, але критичні для рішення?

• Історія змін бенефіціарів за останні 3–5 років (хто вийшов, хто зайшов, чому).
• Судові спори про корпоративні права, рейдерські захопи, банкрутства з підозрілими схемами.
• Зв'язки через спільні номери телефонів, email, IP-адреси, облікові записи в соцмережах ключових осіб.
• Інформація про номінальних директорів і акціонерів, що масово реєструють компанії.
• Дані про попередні перевірки ДФС, НАБУ, СБУ, які не стали публічними справом, але залишили слід у реєстрах.

Цих даних немає в стандартних пакетах World-Check, Refinitiv, Dow Jones. Їх збирає аналітик вручну або через спеціалізовані.osint-інструменти.

Як не стати заручником «зелёного прапорця» системи?

1. Встановіть правило: автоматичне рішення «чисто» дійсне лише для контрагентів низького ризику (одноразові платежі до порогу фінмоніторингу, відомі державні підприємства, банки-резиденти).
2. Для всіх інших — обов'язковий ручний огляд логів скринінгу: які тривоги виникли, чому вони закриті, чи перевірив аналітик ланцюг власності до кінцевого бенефіціара.
3. Введіть обов'язкове поле у CRM/ERP: «Хто і коли прийняв рішення по скринінгу» — з посиланням на артефакти (скріншоти, виписки, нотатки аналітика).
4. Раз на квартал робіть вибіркову перевірку 10–15 «чистих» контрагентів за повною методологією due diligence. Якщо знайдете пропущені ризики — перегляньте правила автозакриття тривог.

Порівняння: що робить машина, а що — аналітик

Як оцінити якість вашого вендора скринінгу перед купівлею?

1. Попросіть тестовий набір: 50 контрагентів із відомими ризиками (складні ланцюги, номіналі, історичні зміни бенефіціарів) і 50 «чистих». Запустіть у демо-режимі.
2. Порівняйте recall (повноту виявлення) і precision (точність) на ваших даних, а не на маркетингових слайдах.
3. Перевірте, чи підтримує система українську транслітерацію (ДСТУ 9112:2021) і кирилицю без втрати якості.
4. Дізнайтеся, як часто оновлюються санкційні листи (годинно, щоденно, щотижнево) і чи є вебхуки для пуш-оновлень.
5. Запитайте API для інтеграції у ваш процес: чи можна надіслати пакет запитів і отримати структурований JSON з рішенням і евіденсом.

Коли регулятор запитає «чому ви так вирішили» — що показати?

bank або НАБУ не приймає посилання на «система видала чисто». Потрібен пакет: лог запиту до системи з таймстампом, виписки з реєстрів на момент перевірки, нотатки аналітика з обґрунтуванням закриття кожної тривоги, підпис відповідального комплаєнс-офіцера. Якщо тривога була, але аналітик закрив її — має бути записано «перевірено: збіг тільки по прізвищу, дата народження не співпадає, географія різна, додаткових зв'язків не виявлено». Це займає 5–10 хвилин, але рятує під час перевірки.

Як підключити OSINT до процесу без хаосу?

1. Визначте обов'язковий мінімум перевірки для високоризикових контрагентів: Google/Яндекс по ПІБ + ключові слова (суд, банкрутство, рейдер, арешт, схема), YouControl/Опендатабот/РЕР по ЄДРПОУ, судові реєстри (РЕР, Державний реєстр судових рішень), реєстр бенефіціарів, реєстр ПЕП, санкційні листи.
2. Створіть шаблон звіту аналітика (одна сторінка A4): контрагент, ризик, джерела, висновок, рекомендація, дата, аналітик.
3. Автоматизуйте збір лише повторюваних частин (виписки з реєстрів через API), інтерпретацію залиште за людиною.
4. Навчіть команду не гуглити «на щастя», а йти за чеклістом — це знімає суб'єктивність і прискорює онбордінг нових аналітиків.

FAQ

Чи може AI повністю замінити комплаєнс-аналітика при скринінгу?

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

Які мінімальні дані потрібні для якісного ручного доопрацювання автоматичного скринінгу?

ПІБ/найменування, ЄДРПОУ/РНОКПП, дата народження/реєстрації, повна історія змін бенефіціарів і керівників за 3–5 років, судові спори, зв'язки через контактні дані ключових осіб.

Як задокументувати рішення «ризик прийнятний» для банку або інвестора?

Лог запиту до системи скринінгу, виписки з реєстрів на дату перевірки, нотатки аналітика з обґрунтуванням закриття кожної тривоги, підпис відповідального комплаєнс-офіцера, дата прийняття рішення.

Чи достатньо комерційної бази (World-Check, Refinitiv) для покриття санкційних ризиків України?

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

Як часто треба перевіряти існуючих контрагентів (ongoing monitoring)?

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

Що робити, якщо контрагент потрапив під санкції після укладення договору?

Негайно зупинити операції, повідомити банк-обслуговувача, зафіксувати дату та час виявлення, розпочати процедуру відсторонення (termination) за умовами договору або законом, повідомити регулятора за встановленими каналами, зберегти всі комунікації для аудиту.

AI-скринінг — це потужний фільтр першої лінії, але не суд і не відповідальний за рішення. Системні провали — пропущені ланцюги власності, номінальні структури, контекст репутації — лежать в зоні відповідальності людини. Будьте-правилом: машина пропонує, аналітик перевіряє, керівник підписує, архів зберігає. Це єдина схема, яка витримує перевірку регулятором і запити інвестора.