ML-моделі для фінансів: де ламається скоринг і антифрод
Скоринг заявок і модель антифроду майже ніколи не ламаються на етапі навчання — вони ламаються в робочому контурі, де дані вже не ті, на яких модель навчалася.
На відкладеній вибірці метрики виглядають пристойно, а в потоці частка схвалень зміщується, черга ручної перевірки зростає, і ризик-аналітики перестають довіряти рішенням системи.
Перше слабке місце — ознаки. Скоринг заявок живе на даних кредитного бюро, потокових подіях і агрегатах по клієнту, і будь-яка з цих гілок може відставати: вивантаження приходить раз на добу, лічильники по пристрою ще не зібралися, категорія торгової точки не підтягнулася. Модель отримує половину картини і занижує бал заявці, яка проходить за профілем ризику.
В антифроді картина інша. Модель працює поверх набору жорстких правил, і правила перекривають її вихід: спрацював стоп-лист — заявка йде людині незалежно від того, що ймовірність шахрайства низька.
З часом правила накопичуються і перетинаються, а частка заявок у ручній перевірці зростає швидше за сам потік.
Третя причина — петля зворотного зв'язку. Розмітка для моделі антифроду приходить тільки з підтверджених випадків, а підтверджуються ті, що пройшли ручну перевірку.
Якщо перевіряти лише заявки з високим балом, наступний цикл навчання закріпить це зміщення: ML-моделі для фінансів так і не побачать шахрайство, яке самі ж і пропустили.
Управління ризиками тримається на трьох речах: передбачуваності балу, пояснюваності відмови і швидкості рішення.
Коли вони розходяться — моніторинг не ловить дрейф даних, причину відмови не відновити, у ручній перевірці накопичується черга, — система формально працює, але перестає керувати потоком.
Далі розбираємо, як це закривається: від контролю якості ознак і калібрування балу до розбору черги ручних перевірок.
Вимірюваний ефект: швидкість рішень і частка помилкових відмов
Ручна перевірка задає стелю за швидкістю: заявка чекає розбору, в пікові години черга зростає, рішення приймається через хвилини. Модель рахує бал на потоці подій і віддає відповідь за секунди, залишаючи людині тільки спірні випадки. Служба ризиків перестає бути вузьким місцем — пропускна здатність зростає без розширення штату.
Частка хибних відмов — другий вимірюваний важіль. Жорсткі правила спрацьовують на добросовісних клієнтах: велика сума в людини з короткою історією, покупка одразу після зміни регіону.
Модель ранжує за ймовірністю, а поріг відсікання налаштовується під цільову частку хибних відмов і перераховується за контрольною вибіркою. Окремий контур для повторних звернень знімає основну масу роздратування.
Втрати від шахрайства падають за рахунок зниклого класу помилок — схем, які окремо виглядають нешкідливо: дроблення сум, ланцюжки пов'язаних облікових записів, підміна пристрою. Граф зв'язків і агрегати по клієнту видимі моделі там, де правила безсилі.
MLflow зберігає версії моделей, набори ознак і метрики, тому результат після релізу порівнюють з базовою лінією на тій самій вибірці, а не «на око». Якщо метрика проснулася на живому трафіку, відкат до попередньої версії займає хвилини. Такий контур обліку робить зміни перевіряними для аудиту і передбачуваними для служби ризиків.
Варіанти реалізації: правила, статистика, навчання на даних
Підхід обирають не за «сучасністю», а за обсягом розміченої історії, вимогами до пояснюваності рішення і ціною помилки.
Правила та експертні пороги запускаються одразу і повністю пояснювані, але кожну нову схему шахрайства доводиться описувати вручну, а разом із числом правил зростає частка хибних спрацьовувань.
Навчання на історичних даних знаходить неочевидні поєднання ознак, зате чутливе до зсуву розподілу: схема, якої не було в минулих даних, для моделі виглядає нормальною.
Саме тому в промисловій експлуатації частіше збирають гібридну схему: правила закривають очевидні випадки і працюють страховкою, модель ранжує залишок за ймовірністю, а статистика по портфелю задає пороги відсікання.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та експертні пороги | Немає накопиченої історії, потрібна повна пояснюваність кожного вердикту | Погано масштабуються: правила конфліктують між собою, зростає частка хибних блокувань |
| Статистичні моделі | Ознаки стабільні, важлива інтерпретація внеску кожного фактора | Не тримають нелінійні зв'язки, швидко застарівають при зміні поведінки клієнтів |
| Навчання на історичних даних | Є розмічена історія в сотні тисяч подій, допустима затримка на перенавчання | Потребує контролю дрейфу даних, уразливе до отруєння вибірки і до нових схем |
| Гібридна схема | Промислова експлуатація з високою ціною помилки і вибірковою пояснюваністю | Складніше в підтримці: дві гілки логіки, потрібен моніторинг узгодженості вердиктів |
За основу беремо той варіант, який витримує матрицю помилок конкретного процесу: де дорожче пропустити подію, а де — заблокувати добросовісного клієнта.
Етапи роботи: від розбору даних до передачі рішення
Порядок етапів задає не методологія, а те, як модель буде жити в експлуатації: хто її запускає, за якими даними вона рахує в момент рішення і що відбувається, коли розподіл вхідних даних з'їжджає.
Тому робота йде ітераціями — результат кожного кроку або підтверджує наступний, або повертає нас на крок назад.
- Розбір даних і постановка задачі. Профілюємо джерела: дивимося заповненість полів, розбіжності між системами, затримку появи даних і ознаки витоку цільової змінної. Фіксуємо, що саме передбачаємо і в який момент часу ця інформація реально доступна.
- Підготовка ознак. Збираємо вітрину для навчання, описуємо розрахунки і версіонуємо їх так, щоб однакові значення виходили і при навчанні, і при роботі моделі.
- Базове рішення і порівняння. Будуємо просту модель-орієнтир: вона показує, чи є в даних сигнал взагалі, і слугує планкою, нижче якої ускладнювати нічого.
- Перевірка на незалежній вибірці. Оцінюємо якість на відкладеному періоді, який не перетинається з навчальним за часом. Так видно, чи тримається результат на нових даних, а не тільки на знайомих прикладах.
- Калібрування і вибір порогу. Приводимо оцінки до реальних ймовірностей і підбираємо межу спрацьовування під ціну помилок першого і другого роду.
- Впровадження моделі. Сервіс оцінки підключаємо до процесу замовника і запускаємо в тіньовому режимі — модель рахує, рішення приймає людина; версії та параметри фіксуються, щоб результат був відтворюваним.
- Передача в експлуатацію. Віддаємо регламенти перенавчання, набори перевірок, дашборди по дрейфу вхідних даних і порядок відкату на попередню версію.
Що залишається у команди замовника після передачі
Передача завершена не тоді, коли модель показана на демо, а коли команда замовника може пояснити будь-яке її рішення, повторити навчання на тих самих даних і вимкнути модель без нас.
Тому здаємо пакетом артефактів, а не набором скриптів: у кожного рішення описана межа застосовності та умови, за яких його потрібно переглянути.
Що залишається на руках:
- Документація по моделі: джерела даних, схема ознак, метрики на відкладеній вибірці, відомі обмеження і сценарії, де рішення не можна приймати без ручної перевірки.
- Регламент перенавчання: тригери — падіння метрик, зсув розподілу вхідних даних, зміна бізнес-правил; періодичність, відповідальний, порядок валідації нової версії.
- Політика роботи з рішеннями: пороги для автоматичного схвалення, відмови і ручного розбору; як фіксується незгода спеціаліста і як цей сигнал повертається в навчальні дані.
- Схема моніторингу якості: контрольні зрізи, метрики стабільності входу і якості виходу, частоти розрахунку, пороги оповіщень і порядок дій чергового.
- Карта версій і відкат: який набір даних і параметрів породив кожну версію, як розгорнути попередню і що відбувається з уже прийнятими рішеннями.
- Матриця доступів: хто має право змінювати правила, хто — перенавчати, хто — тільки дивитися, і як цей розподіл перевіряється.
- Критерії приймання: за якими метриками приймається кожна версія і в яких точках ми підключаємося далі.
Кейс: скоринг і антифрод в одному потоці заявок
Заявки приходили в один потік, але оброблялися двома незалежними сервісами: скоринг рахував ймовірність дефолту, антифрод — ризик шахрайства, і кожен бачив тільки свою частину ознак.
На практиці це давало дві проблеми: частка хибних спрацьовувань антифроду сягала 12%, а частина підтвердженого шахрайства проходила всередині вже схвалених заявок.
| Метрика | До | Після |
|---|---|---|
| Частка хибних спрацьовувань антифроду | 12% | 3,4% |
| Заявки, що пішли на ручний розбір | 18% | 5% |
| Час рішення по заявці | до 40 хвилин | до 2 хвилин |
| Повнота вилову підтвердженого шахрайства | 71% | 91% |
| Виведення нової версії моделі скорингу | 6–8 тижнів | 10 днів |
Що перебудували
Обидва контури звели в єдиний потік: ознаки збираються в загальне сховище на рівні події заявки, антифрод і скоринг працюють по одній вітрині і обмінюються рішеннями до видачі відповіді клієнту.
Пороги антифроду налаштовуються по сегментах — для зарплатних клієнтів і нових позичальників вони різні, тому зниження хибних спрацьовувань не куплено зростанням пропусків. Версії моделей фіксуються в MLflow, і відкат на попередню версію не потребує перезбирання потоку.
Метрики до і після знімалися на одному періоді навантаження, щоб порівняння було чесним. Потік заявок зріс приблизно втричі без розширення команди ручного розбору, а частка відмов, які клієнт оспорив і виграв, скоротилася вдвічі.
Що робити, якщо в компанії вже працюють правила і ручні перевірки
Правила і ручні перевірки — не те, що потрібно гасити при впровадженні ML. Вони вже містять експертизу: ліміти, стоп-фактори, галузеві регламенти, напрацьовані роками.
Розумний порядок — не заміна, а паралельна робота: старий контур залишається основним і продовжує приймати рішення, новий рахується в тіньовому режимі на тому самому потоці заявок.
Вибір між правилами і машинним навчанням роблять за природою ознаки. Жорсткі детерміновані умови — санкційні списки, вікові та лімітні обмеження, обов'язкові стоп-фактори — залишаються правилами: їх потрібно вміти пояснити перевіряючому і регулятору.
Машинне навчання забирає те, де правил стало занадто багато і вони почали конфліктувати: перетини ознак, нелінійні залежності, сегменти, де коректна ручна перевірка перетворюється в чергу на кілька днів. За методологією CRISP-DM це окремий крок — аналіз даних і постановка задачі, а не підбір алгоритму.
Перехід без зупинки процесу будується на порівнянні. Беремо історію закритих справ із відомим результатом, проганяємо через моделі і через діючі правила, дивимося, де оцінки розходяться і чому.
Дві метрики вирішують долю рішення: яка частка ризикових випадків перехоплюється і яка частка добросовісних клієнтів йде в ручну чергу. Поки нова схема програє за будь-якою з них, вона не виходить з тіні.
Прикордонні випадки виносяться в окремий контур. Модель повертає оцінку, а не вердикт: в зоні невизначеності кейс йде на ручну перевірку з готовим набором ознак і причин, які її підсвітили.
Поріг налаштовується, частка таких звернень — керований параметр, зазвичай це одиниці відсотків, і її можна рухати, не змінюючи ні правила, ні модель.
Далі контур звужується поступово: правило вимикається тільки тоді, коли модель стабільно його перекриває на відкладеній вибірці і в живому потоці. Відкат — повернення порогу і включення правила назад, без релізу і зупинки прийому заявок.
Технічні сумніви, які варто зняти до старту
Технічні сумніви навколо ML у фінансах рідко стосуються самих алгоритмів — вони стосуються даних, пояснюваності рішень, стійкості моделі на нових даних і того, як усе це вбудується у вже працюючий процес. Нижче — чотири питання, які задають до старту найчастіше, і те, як ми закриваємо їх інженерно.
Наших даних вистачить, щоб модель працювала?
Обсяг рідко буває вузьким місцем — критична якість. Починаємо з профілювання вивантаження: пропуски, розсинхрон джерел, рідкісні класи на кшталт поодиноких шахрайських операцій.
Далі — очищення, стабілізація довідників і контроль дрейфу, щоб модель не «осліпла» при зміні поведінки клієнтів.
Як пояснити рішення моделі перевіряючому або клієнту?
Для фінансів пояснюваність — не надбудова, а вимога. Даємо важливості ознак по кожному рішенню, локальні пояснення під конкретний випадок і правила-сурогати, за якими рішення відтворюється людиною. На виході — формулювання, яке можна показати в спірній ситуації.
Модель перенавчиться і розвалиться на нових даних?
Це ловиться на етапі перевірки, а не на проді. Навчаємо на минулому, перевіряємо на майбутньому — відкладений за часом період замість випадкової вибірки. Після запуску відстежуємо якість і дрейф вхідних даних, перенавчання йде за регламентом і за тригером деградації.
Як вбудувати модель у поточний процес?
Модель не замінює правила, а працює поверх них. Спочатку режим підказок: спеціаліст бачить оцінку і пояснення, рішення приймає сам. Коли точність на впевнених наслідках підтверджена, ці випадки йдуть в автоматику, а спірні залишаються людині. Інтеграція — через сервісний шар, без перебудови процесів.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Оцінка проєкту з моделей машинного навчання для фінансів починається не з вибору алгоритму, а з розбору задачі і даних: яка цільова змінна, як швидко приходить підтвердження правильної відповіді, які помилки дорожчі — пропущена прострочка чи відхилений платоспроможний клієнт.
Від цього залежать метрика, поріг спрацьовування і схема перевірки якості. Тому обговорення задачі йде раніше, ніж ми називаємо терміни.
На розборі закриваємо конкретні питання, кожне з яких змінює план робіт:
- Дані та розмітка. Де лежать історії видач і операцій, чи підтверджений результат по кожному випадку, скільки часу проходить до появи мітки.
- Метрика і поріг. Яка частка помилок допустима на робочому потоці, як співвідносяться втрати від пропуску і від хибного спрацьовування.
- Схема перевірки. Відкладений за часом період замість випадкового розбиття — інакше якість на папері вища, ніж у робочому контурі.
- Пояснюваність. Які рішення потрібно обґрунтовувати перед перевіряючими і клієнтом, які ознаки допустимо використовувати.
- Формат впровадження. Пакетний скоринг, оцінка в момент операції або черга ручної перевірки за пріоритетом.
- Спостереження і відкат. Контроль дрейфу вхідних даних, перенавчання за розкладом, повернення на попередню версію моделі.
- Ресурси. Що потрібно від вашої сторони щодо даних, доступів і знання процесу.
Опишіть задачу — повернемося з оцінкою проєкту і планом робіт: етапи, склад команди, зони відповідальності.
