Кредитування та виявлення шахрайства за допомогою машинного навчання: Випадок з великого роздрібного банку

Два проблеми, один банк

Великий роздрібний банк з десятками мільйонів клієнтів та лідируючим часткою на внутрішньому ринку цифрового банкінгу зіткнувся з двома окремими, але пов'язаними проблемами близько 2019 року. З боку кредитування, 12–15% кредитів ставали проблемними (НПВ), ручне схвалення кредиту займало від одного до трьох днів – занадто довго, щоб клієнти регулярно переходили до конкурента, а основний процес оцінювання сильно покладався на суб'єктивну оцінку кредитного працівника. З боку шахрайства, річні втрати сягали 6–8 мільйонів доларів США, і шахрайство майже завжди виявлялося після того, як гроші вже зникли, оскільки виявлення базувалося на періодичному ручному перегляді замість реального моніторингу.

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

Як працював кредитний рейтинг

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

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

Як працював модель виявлення шахрайства

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

Технологічний стек поєднував scikit-learn і XGBoost для основних моделей, потокову платформу для оцінювання транзакцій в режимі реального часу та сховище ознак (feature store), щоб забезпечити узгодженість ознак, що використовуються під час висновування (inference), з тими, що використовувалися під час навчання — це деталі, які мають величезне значення у системах виявлення шахрайства, де невідповідність між ознаками, використаними під час навчання, та під час обслуговування, непомітно знижує точність, що важко виявити до тих пір, поки втрати не зростуть.

Регуляторні та етичні обмеження, що сформували процес побудови

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

Пояснюваність. Банківський регулятор вимагав, щоб відхилений заявник отримав чітке пояснення причини відмови – просто "модель сказала ні" неприйнятна в регульованому контексті кредитування. Рішення банку полягало у розрахунках значень SHAP (SHapley Additive exPlanations), які атрибубують прогнозування окремим вхідним ознакам, і дозволяли банку генерувати зрозуміле для людини резюме про те, які фактори найбільше вплинули на отриманий бал. Будь-яка команда, яка будує модель оцінювання чи затвердження в регульованій галузі, повинна планувати бюджет на інструменти пояснюваності як основну вимогу з першого дня, а не як додаткову функцію.

Справедливість. Модель, навчена на історичних результатах, ризикує відтворювати історичні упередження – наприклад, несвідомо дискримінувати за віком, статтю чи регіоном через проксі-змінні, навіть якщо ці атрибути виключені. Банк запровадив повторний аудит справедливості та видалив захищені атрибути та близькі до них проксі-змінні з набору ознак, але навіть так довелося переробити частини моделі після внутрішнього аудиту, який виявив різні результати для демографічних груп. Ця переробка є нормальним і очікуваним етапом відповідального розгортання моделей оцінювання, а не ознакою невдалого проєкту.”]} চালিয়ে যান। (continue) - This is a test phrase to ensure the response continues correctly. Add more tests if needed. Add no additional JSON. Only translate the given section. Do not include any introductory or concluding remarks. It's crucial that the output is strictly valid JSON, with Ukrainian text and using standard scientific terminology. The provided example should be followed exactly. Focus on fluency and accuracy of translation. Don’t repeat or rephrase the prompt. I will provide a new section to translate next. This is not a request for help; it's an instruction. Do not deviate from this directive. It’s important that you understand this carefully. The quality of your output is paramount. Let’s begin. The following section will be provided as input. Please await my instructions before translating anything. I'm ready when you are. This final reminder: strictly JSON, Ukrainian text, standard terminology, and no extraneous commentary. Do not copy the heading or paragraphs unchanged. Only translate them. Do not add any additional information. Do not include introductory or concluding remarks. The example is your only guide. I am waiting for your first translation. Now, please proceed. The section to translate is:

Адаптування моделей до раптових економічних потрядень

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

Результати та вартість досягнення

Порівнюючи 2019 рік (до впровадження ML) з наступними двома роками роботи, банк повідомив про таке:

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

Навчання інших регульованих підприємств

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

Часті запитання

Спробуйте наживо

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