Розробка AI-системи автоматизації комплаєнсу у фінансах

AI compliance у фінансах: де ламається автоматизація перевірок

Правила у фінансовій установі живуть довше за процеси, які вони описують.

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

Формально автоматизація перевірок є, але працює фрагментами: кожна система бачить свій зріз операції й не знає, що поруч спрацювало правило з іншим порогом.

Звідси перша й найдорожча ділянка — ручний контроль операцій. Вибірка для розбору формується вручну: контролер відбирає за датою, сумою та ознакою, витрачає на це години, а потрапляння операції до вибірки залежить від того, наскільки вдало він задав фільтр.

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

Другий шар вузьких місць перевірок — відсутність сліду рішень.

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

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

Що дає автоматизація перевірок: швидкість, повнота, слід

Швидкість перевірки перестає залежати від завантаження конкретного фахівця. Дані підтягуються автоматично, типові звірки за регламентом рахуються за хвилини.

Інженерний сенс не в «швидше», а в передбачуваному часі на потік: видно, скільки перевірок система пропускає за зміну, і навантаження планується за фактом.

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

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

Повнота перевірок тримається на тому, що правило застосовується до всіх записів однаково. Пропуски через людський фактор і відкладені розбори зникають, хибні спрацювання знижуються налаштуванням порогів: перевірка звіряється з джерелом, а не з пам’яттю співробітника.

Слід рішення — те, що запитують під час внутрішнього контролю та зовнішньої перевірки. На кожну операцію залишається запис: які дані подавалися, яке правило застосувалося, яке значення вийшло, хто й коли підтвердив. Історія відновлюється запитом до журналу, а не пошуком у листуванні.

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

Способи розгортання: локальний контур, хмара, гібрид

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

Галузеві вимоги, наприклад PCI DSS, прямо обмежують, де можуть зберігатися й оброблятися платіжні та персональні відомості, і архітектуру фіксують до першого рядка коду, а не після першого аудиту.

Ключове питання — де живе модель і де лежать дані: від цього залежать затримка відгуку, вимоги до шифрування та обсяг доказів для перевіряльників. Переміщення готової системи між контурами коштує кратно дорожче, ніж вибір на старті.

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

Таке рішення ми закріплюємо схемою потоків даних і правилами розмежування доступу, щоб кожна операція була простежуваною для аудиту.

Етапи впровадження: від аудиту правил до передачі в експлуатацію

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

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

2. Схема перевірок. Реєстр перетворюємо на схему: які дані потрібні на вході, які перевірки детерміновані, а які потребують оцінки моделі, де обов’язковий ручний розбір. Схема задає порядок перевірок і точки, де операція блокується без підтвердження людиною.

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

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

5. Приймання якості. Узгоджуємо метрики — повноту виявлення, точність, частку випадків, що пішли на ручний розбір. Приймання йде на вибірці, яку формуєте ви, а не ми: це унеможливлює підгонку під зручні приклади.

6. Передача в експлуатацію. Віддаємо конфігурації, реєстр правил, схему перевірок і порядок їх оновлення при зміні вимог. Моніторинг фіксує розбіжність між рішеннями системи та розбором аналітиків — це сигнал, що ознаки застаріли.

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

Система комплаєнс-контролю передається не як «чорна скринька», а як комплект артефактів, з яким ваша команда працює без нас.

Правила перевірок описані декларативно й лежать у вашому репозиторії, модель зафіксована у версії, що пройшла приймання, а кожне рішення відтворюване за журналом.

• Регламенти контролю: які операції перевіряються, за якими ознаками, що блокує проведення, а що йде на розбір оператору.
• Конфігурації правил: версіоновані файли, правка яких не потребує зміни коду — лише рев’ю та відкат за історією.
• Схема ухвалення рішень: маршрут від надходження даних до вердикту, точки втручання людини, межі автоматики.
• Правила доступу: ролі аналітика, оператора, аудитора й адміністратора правил; право змінювати правило відокремлено від права його затверджувати.
• Журналювання: незмінний лог за кожним спрацюванням — вхідні дані, версія моделі й правила, вердикт, факт втручання; вивантаження під аудит.
• Інструкції оператора: розбір типових спрацювань, порядок ескалації, оформлення спірного рішення.
• Порядок оновлення правил: погодження, перевірка на історичних даних, введення нової версії в роботу, підпис відповідального.

Комплект розрахований на передачу: ваші інженери та комплаєнс-офіцер змінюють правила й проходять перевірки, не звертаючись до нас. Опишіть задачу — повернемося з оцінкою та планом.

Кейс: як скоротили ручні перевірки в кредитному підрозділі

Пілот запускали в кредитному підрозділі: аналітик звіряв пакет документів позичальника з регламентом вручну, 40-60 хвилин на заявку.

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

Регламент розібрали на формалізовні пункти та спірні випадки. Перші стали правилами в рушії перевірок, другі — моделлю з оцінкою впевненості: усе, що нижче порога, йде людині з поясненням, якого документа бракує.

Кожна перевірка залишає запис у журналі — який пункт спрацював і які ознаки вплинули на висновок, тому внутрішній контроль проходить без переробок. Правила звели за методологією FATF.

Метрики до і після

Точка контролю змістилася з перенесення даних на розбір винятків: аналітик закриває 5-7 спірних заявок за зміну замість потоку однотипних.

Правила версіонуються — при зміні регламенту правиться конкретний пункт, а не вся система, і пропусків стало менше не за рахунок жорсткості порогів, а тому що модель навчалася на рішеннях самих фахівців підрозділу.

Що робити, якщо частина compliance-контролю вже автоматизована

Часткова автоматизація — не перешкода, а готова опорна площадка.

Коли контроль уже частково працює, задача формулюється не як «впровадити з нуля», а як вбудуватися в наявний контур: зберегти чинні правила, ролі та журнал перевірок і добудувати шар, що закриває залишок ручних операцій.

Починаємо з інвентаризації: які правила вже виконуються, у якій системі живе кожне, хто власник і за якою ознакою правило спрацьовує.

Картина зазвичай неоднорідна — частина перевірок описана в правилах профільної платформи на кшталт Actimize, частина тримається на скриптах вивантаження, частина залишається в регламентах аналітиків.

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

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

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

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

Часті технічні сумніви: розбір типових питань

Сумніви щодо системи, яка виносить судження про законність операцій, закономірні: вимоги змінюються швидше, ніж живе реліз, а ціна помилки вища, ніж у звичайній автоматизації.

Чотири питання, які технічні замовники задають першими: дані й доступи, пояснюваність рішень, оновлення правил, межі відповідальності.

Як ви боретеся з хибними спрацюваннями та пояснюєте рішення?

Кожне спрацювання супроводжується посиланням на конкретне правило та на ознаки, що вплинули на оцінку: перевіряльник бачить причину, а не знеособлений флаг.

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

Що відбувається при зміні вимог?

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

Хто відповідає за роботу системи після запуску?

Ми відповідаємо за логіку перевірок, інфраструктуру та оновлення правил у межах супроводу. Підсумкове рішення за операцією залишається за комплаєнс-підрозділом: відповідальність за судження не можна передати алгоритму.

Обговоримо задачу: які дані потрібні для оцінки

Оцінка проєкту будується на трьох опорах: які перевірки автоматизуємо, які дані для розрахунку вже є і як будемо вимірювати якість. Чим конкретніші вхідні дані, тим точніші строки етапів і менше правок у плані робіт. Нижче — що надіслати, щоб ми повернулися з оцінкою, а не з уточнювальними запитаннями.

• Опис процесу: які перевірки йдуть зараз, хто і на якому кроці ухвалює рішення, де залишаються ручні операції і що з’їдає найбільше часу.
• Джерела даних: системи-джерела, формати вивантажень, періодичність оновлення та приблизний обсяг — число операцій або документів за місяць.
• Знеособлена вибірка: кілька сотень реальних прикладів, включно з рідкісними та пограничними випадками — на них калібрується модель і перевіряється точність.
• Вимоги регулятора: перелік норм, форми звітності, строки надання та зауваження, які вже отримували.
• Обмеження контуру: де система буде працювати, які сервіси не можна змінювати, вимоги до зберігання даних і розмежування доступу.
• Критерії приймання: допустима частка пропусків і хибних спрацювань, хто і як перевіряє відповіді моделі перед впровадженням.
• Зовнішні дати: звітні періоди або перевірки, до яких рішення має бути готове, — від них залежать строки етапів.

З цим набором ми повертаємося з оцінкою проєкту, розбивкою на етапи та зрозумілими строками кожного. Опишіть задачу — покажемо, що беремо в роботу першим і які дані потрібні вже на старті.