AI KYC система: де ламається ручна перевірка клієнтів
Поки потік заявок невеликий, ручна перевірка клієнтів виглядає керованою: оператор відкриває анкету, звіряє документ із базою, ухвалює рішення. Але потік зростає — і черга заявок на перевірку починає накопичуватися швидше, ніж відділ встигає її розбирати.
Час ухвалення рішення збільшується не через складність кейсів, а через пропускну здатність: кожен новий клієнт потребує рук, і найм проблему не вирішує.
Вузьке місце — перевірка документів клієнта. Скани надходять у різних форматах і якості, частина знімків зроблена під кутом, частина — із відблисками, поля заповнені вручну й з помилками.
Оператор витрачає основний час не на оцінку ризику, а на витяг і перенесення даних, звірку з внутрішніми списками та зовнішніми реєстрами. Навантаження на відділ перевірки зростає лінійно, а разом із ним — ціна помилки й плинність: навчання нового фахівця займає тижні.
Друга сторона проблеми — якість рішення під тиском черги. Коли за зміну потрібно закрити сотні заявок, спірні профілі проходять за залишковим принципом: не вистачило часу розібратися — пропустили.
Так ризиковані клієнти потрапляють у портфель, а регуляторні вимоги виявляються дотриманими лише на папері. Зворотна ситуація теж дорога: добросовісному клієнту відмовляють через формальність, і він іде до конкурента.
Розбираємо, як це закривається: AI KYC система знімає з людей рутину витягу та звірки даних, оцінює ризик за сукупністю ознак і передає оператору лише ті випадки, де справді потрібне рішення людини.
Що змінюється після впровадження: вимірювані ефекти
Ефект від AI KYC системи вимірюється не кількістю моделей, а метриками, які бачить комплаєнс: час перевірки клієнта, частка хибних спрацювань, поведінка під час простою зовнішніх джерел і клас відмов, який зникає повністю.
Швидкість перевірки клієнта
Автоматизація перевірки бере на себе розбір документів, звірку зі списками та скоринг ризику — аналітик підключається лише до спірних анкет.
Онбординг фізособи вкладається в хвилини, а юрособа зі складною структурою володіння закривається за години: зв'язки між засновниками будуються за графом, а не вручну.
Хибні спрацювання
Основне джерело шуму — збіги імен: транслітерація, ініціали, часті прізвища. Налаштовані пороги та врахування дати народження, громадянства й санкційної програми знижують частку хибних спрацювань у рази.
Звірка йде за OpenSanctions і комерційними списками, а аналітик розбирає кейси з підтвердженим ризиком, а не всю чергу.
Клас відмов, що зник
Скринінг раз на добу залишав вікно, у якому клієнт із нового санкційного списку продовжував проводити операції, — подієвий скринінг закриває його блокуванням у момент оновлення.
Простій зовнішнього джерела раніше означав зупинку перевірок; тепер це затримка в черзі з повторенням, а не відмова в обслуговуванні. Кожне рішення потрапляє до журналу з причинами спрацювання.
KYC-перевірка: порівняння режимів і обмежень
Режими перевірки не взаємовиключні — їх призначають за сценаріями: приймання нового клієнта, платіж, періодичний перегляд.
Автоматична перевірка закриває основний потік без участі людини, а співробітник підключається точково — там, де спрацювало правило ризику або модель не набрала впевненості. Вибір задається конфігурацією сценарію, а не переписуванням логіки.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повністю автоматичний | Типові анкети з повним набором даних, масовий потік | Хибні збіги йдуть клієнту; спірні документи нема кому розбирати; потрібне стабільне джерело даних |
| З підтвердженням співробітником | Високий ризик, розбіжності в документах, великі операції | Зростає час рішення й навантаження на ручний розбір; потрібні регламент і розмежування прав |
| Пакетна переперевірка бази | Оновлення списків, плановий перегляд клієнтської бази | Йде за розкладом, а не в реальному часі; результат розбирається пачками й потребує черги |
Окремо варто пам'ятати про обмеження перевірки: якість залежить від повноти джерел і свіжості списків, частина збігів виявляється хибною, а дані в анкеті застарівають.
Тому кожне рішення пишеться до журналу з причиною, версією правил і посиланням на джерело — інакше ручний розбір нема чим обґрунтувати, а відкат рішення стає неможливим.
На практиці режими комбінують: автоматика тримає потік, підтвердження співробітником страхує високий ризик, пакетна переперевірка запускається за розкладом або під час оновлення бази.
Метрика, за якою обирають пропорцію, — частка запитів, що пішли на ручний розбір, і час реакції на них.
Етапи впровадження: від розбору процесів до передачі
Впровадження AI-системи перевірки клієнтів починається не з моделі, а з інвентаризації того, як перевірки влаштовані зараз: які канали приймання заявок, які документи проходить верифікація, де рішення ухвалює співробітник, а де спрацьовує формальне правило.
Без цього кроку автоматизація закріплює вже наявні прогалини — ручний розбір накопичується, перевірки дублюються, а причина відмови не відновлюється за журналом.
- Аудит процесів перевірки. Розбираємо чинний маршрут клієнта: приймання заявки, верифікація документа, перевірка за списками, моніторинг операцій. На виході — карта рішень із позначками, де втрачається час і які відмови йдуть на ручний розбір.
- Проєктування цільової схеми. Фіксуємо, які перевірки йдуть автоматично, що залишається за співробітником, які події потрапляють у звітність. Схему погоджуємо до налаштування, щоб не переробляти логіку на середині.
- Налаштування сценаріїв і порогів. Під кожен сегмент клієнтів задаємо правила: які документи приймаються, за якими ознаками вмикається посилена перевірка, коли заявка блокується. Пороги виставляємо так, щоб хибні спрацювання не забивали чергу ручного розбору.
- Перевірка на історичних даних. Проганяємо сценарії на накопиченому масиві заявок і операцій: дивимося, кого система пропустила й кого відправила на доопрацювання, звіряємо з рішеннями, ухваленими вручну. Це основний спосіб упіймати помилки налаштування до запуску на живому потоці.
- Інтеграція з обліковими системами. Підключаємо сервіс до наявного контуру — заявки, статуси, повідомлення, журнал рішень. Кожна дія залишає запис, придатний для перевірки та розбору спірних випадків.
- Передача системи. Віддаємо документацію щодо правил, інструкції для співробітників і порядок зміни порогів, щоб команда могла правити налаштування без нас, і залишаємося на супроводі першого періоду роботи.
Кожен етап закінчується артефактом — картою процесів, схемою, набором правил, звітом про прогін. Це дозволяє повернутися на крок назад точково, без перезбирання всієї системи.
Що залишається у вас на руках: конфігурації та регламенти
Ми передаємо не доступ до сервісу, а систему, яку ваші інженери та комплаєнс-команда можуть розвивати й пояснювати регулятору. Нижче — що саме залишається у вашому контурі після запуску AI KYC-перевірки.
- Схема процесу — шлях заявки від приймання до підсумкового рішення: де спрацьовують автоматичні правила, де підключається ручна перевірка, які події пишуться до журналу.
- Налаштовані правила перевірки — конфігурація ризик-факторів і порогових значень із поясненням, чому вибрано такий поріг і як його змінити, не чіпаючи логіку сервісу.
- Політики доступу — ролі, області видимості персональних даних, порядок надання й відкликання прав, фіксація кожного звернення до даних клієнта.
- Регламент перевірки для співробітників — що робить оператор при спрацюванні правила, які документи запитує, у яких випадках ескалує і кому.
- Документація щодо системи — опис компонентів, формати даних від ваших джерел, схеми інтеграцій, порядок оновлення моделей і правил.
- Передача налаштувань — розгорнута конфігурація середовищ зі значеннями параметрів, перелік приймання та навчання команди на реальних сценаріях.
- План дій під час збою — як вимикається автоматичне рішення, куди перенаправляється потік заявок і як відновити обробку без втрати даних.
Усе це працює у вашому середовищі й не потребує нашої постійної участі: пороги та правила змінюються внутрішніми силами, а документація написана так, щоб новий інженер розібрався в процесі за кілька днів.
Як скоротили ручну перевірку: кейс із метриками
Платіжний сервіс підключав контрагентів потоком — кілька тисяч заявок на місяць, частина з номінальними власниками та свіжою реєстрацією. Перевірка йшла за точним збігом імені із санкційними переліками: транслітерація давала промах, однофамільці — хибне спрацювання. Черга ручних розборів сягала трьох діб, а на зміні документів або адреси контролю вже не вистачало.
Що змінили
Точний збіг замінили зіставленням за графом: ім'я, документи, адреса, телефони та зв'язки заявки з уже перевіреними профілями. Переліки підтягуємо з відкритих джерел, включно з OpenSanctions, і офіційних реєстрів, оновлюємо автоматично.
Кожній заявці присвоюється бал ризику: низький закривається без людини, граничні йдуть аналітику з готовим контекстом і посиланнями на джерела.
| Показник | До | Після |
|---|---|---|
| Заявки на ручний розбір | 38% | 9% |
| Час перевірки однієї заявки | 20–25 хвилин | 4–6 хвилин |
| Черга розборів | до трьох діб | того ж дня |
| Пропущені ризиковані профілі | 6 за квартал | 0 |
Пропуски закрилися ретро-скринінгом: під час оновлення переліку система переперевіряє всю базу й підсвічує збіги заднім числом. Аналітик перестав бути вузьким місцем — він розбирає одиниці складних випадків замість десятків однотипних.
Чим відрізняються правила та пороги від моделей оцінки ризику
Жорсткі правила та пороги — детермінований шар перевірки: сума операції вище ліміту, документ поза строком дії, контрагент з обмежувального переліку, незбіг адреси.
Працює він передбачувано: та сама подія завжди дає той самий результат, а в журналі залишається умова, що спрацювала, а не «бал схожості».
Саме тому правила тримають санкційні, лімітні та документарні перевірки, де відмова має бути відтворюваною й захищуваною.
Слабкі місця проявляються на дробленні сум, транзитних переказах і нетипових зв'язках клієнта з контрагентом: окремо кожна операція проходить, а разом вони утворюють схему.
Модель оцінки ризику працює інакше — вона оцінює профіль загалом: історію операцій, поведінку, зв'язки, галузь. На виході не вердикт, а бал ризику, тому потрібна пояснюваність рішення: внески ознак в оцінку фіксуються, щоб аналітик бачив, що саме підвищило ризик.
Налаштування чутливості — основна робота: поріг підбирають так, щоб потік хибних спрацювань не виснажував ручний розбір, але граничні випадки не проходили повз.
Згідно з FATF, обґрунтування рішення має бути пред'явним нагляду, тому і правило, що спрацювало, і бал моделі потрапляють до одного журналу з ознаками.
Часті технічні сумніви перед стартом
Автоматизація комплаєнсу — ділянка, де помилка коштує дорого: пропущений збіг за санкційним списком і зайве блокування клієнта б'ють однаково. Тому до старту ми розбираємо не лише функціональність, а й поведінку системи на нестандартних даних і в уже працюючому контурі. Нижче — питання, які найчастіше ставлять інженерні команди замовника.
Наскільки точна автоматична перевірка?
Рішення ухвалюється за порогом упевненості, а не за принципом «так чи ні»: вище порога — автоматичне проходження, нижче — ручна черга з уже зібраним контекстом.
Пороги налаштовуються під ризик-профіль, а на розміченому наборі замовника фіксується частка хибних спрацювань до виведення в продуктив.
Що робити з нечитабельними документами?
Відблиски, обрізані краї, скани з телефона — розпізнавання йде з оцінкою якості, і за низької впевненості система не вгадує, а віддає документ на ручний розбір із зазначенням причини.
Такі файли збираються в окремий набір: за ним уточнюються правила, тому частка ручного розбору з часом падає.
Як захищаються персональні дані?
Дані маскуються, результати перевірок зберігаються окремо від самих документів, доступ рольовий і логується, строки зберігання задає політика. Схему обробки та місця зберігання погоджуємо з вашою службою безпеки до першого запису.
У нас уже розгорнута система перевірок
Починаємо з обстеження: що працює, які джерела підключені, де вузьке місце. Нові модулі встають через штатні інтерфейси в паралельному режимі — чинна перевірка продовжує працювати, поки нова не покаже результат не гірший. Перемикання йде по кроках, зі збереженням можливості відкату.
Як розширювати на нові продукти?
Логіка перевірок виноситься в окремий шар, тому новий продукт — це набір правил і порогів під його ризик-профіль, а не переписування ядра. Підключення нового кроку перевірки не зачіпає вже працюючі сценарії.
Обговоримо завдання й повернемося з оцінкою та планом робіт
Починаємо не з презентації, а з розбору вашого процесу: як зараз влаштована перевірка клієнта, де вона гальмує і які перевірки обов'язкові за вимогами регулятора.
Щоб повернутися з оцінкою обсягу, а не із загальними словами, достатньо фактажу — його зазвичай надсилають коротким описом і парою вивантажень.
- опис клієнтських потоків: первинна перевірка, операції, повторні перевірки;
- чинні правила та пороги, за якими сьогодні ухвалюється рішення;
- перелік обов'язкових перевірок і звітності перед регулятором;
- точки стикування: ядро, система обліку клієнтів, платіжний шлюз, сховище документів;
- статистика щодо хибних спрацювань і ручних розборів за минулий період;
- зразки документів, які система має розпізнавати;
- вимоги до зберігання та доступів до персональних даних.
У відповідь віддаємо план робіт: склад робіт за етапами, схему стикування з вашими системами, список сценаріїв, які закриваємо в першій версії, та оцінку обсягу за фазами.
Окремо фіксуємо умови старту впровадження й те, що потрібно з вашого боку: тестовий контур, відповідальний за правила перевірки, вікно на викатку.
Обговоримо завдання в зручному форматі — короткий розбір процесу, після якого надсилаємо письмовий план та оцінку. Далі рішення за вами: йти ітераціями по всьому обсягу чи спочатку на одному сегменті клієнтів.
