ML-модели для финансов: скоринг, антифрод и управление рисками

ML-модели для финансов: где ломается скоринг и антифрод

Скоринг заявок и модель антифрода почти никогда не ломаются на этапе обучения — они ломаются в рабочем контуре, где данные уже не те, на которых модель училась. На отложенной выборке метрики выглядят прилично, а в потоке доля одобрений смещается, очередь ручной проверки растёт, и риск-аналитики перестают доверять решениям системы.

Первое слабое место — признаки. Скоринг заявок живёт на данных кредитного бюро, потоковых событиях и агрегатах по клиенту, и любая из этих веток может отставать: выгрузка приходит раз в сутки, счётчики по устройству ещё не собрались, категория торговой точки не подтянулась. Модель получает половину картины и занижает балл заявке, которая проходит по профилю риска.

В антифроде картина другая. Модель работает поверх набора жёстких правил, и правила перекрывают её выход: сработал стоп-лист — заявка уходит человеку независимо от того, что вероятность мошенничества низкая. Со временем правила накапливаются и пересекаются, а доля заявок в ручной проверке растёт быстрее самого потока.

Третья причина — петля обратной связи. Разметка для модели антифрода приходит только из подтверждённых случаев, а подтверждаются те, что прошли ручную проверку. Если проверять лишь заявки с высоким баллом, следующий цикл обучения закрепит это смещение: ML-модели для финансов так и не увидят мошенничество, которое сами же и пропустили.

Управление рисками держится на трёх вещах: предсказуемости балла, объяснимости отказа и скорости решения. Когда они расходятся — мониторинг не ловит дрейф данных, причину отказа не восстановить, в ручной проверке копится очередь, — система формально работает, но перестаёт управлять потоком. Дальше разбираем, как это закрывается: от контроля качества признаков и калибровки балла до разбора очереди ручных проверок.

Измеримый эффект: скорость решений и доля ошибочных отказов

Ручная проверка задаёт потолок по скорости: заявка ждёт разбора, в пиковые часы очередь растёт, решение принимается через минуты. Модель считает балл на потоке событий и отдаёт ответ за секунды, оставляя человеку только спорные случаи. Служба рисков перестаёт быть узким местом — пропускная способность растёт без расширения штата.

Доля ложных отказов — второй измеримый рычаг. Жёсткие правила срабатывают на добросовестных клиентах: крупная сумма у человека с короткой историей, покупка сразу после смены региона. Модель ранжирует по вероятности, а порог отсечения настраивается под целевую долю ложных отказов и пересчитывается по контрольной выборке. Отдельный контур для повторных обращений снимает основную массу раздражения.

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

MLflow хранит версии моделей, наборы признаков и метрики, поэтому результат после релиза сравнивают с базовой линией на той же выборке, а не «на глаз». Если метрика просела на живом трафике, откат к предыдущей версии занимает минуты. Такой контур учёта делает изменения проверяемыми для аудита и предсказуемыми для службы рисков.

Варианты реализации: правила, статистика, обучение на данных

Подход выбирают не по «современности», а по объёму размеченной истории, требованиям к объяснимости решения и цене ошибки. Правила и экспертные пороги запускаются сразу и полностью объяснимы, но каждую новую схему мошенничества приходится описывать вручную, а вместе с числом правил растёт доля ложных срабатываний. Обучение на исторических данных находит неочевидные сочетания признаков, зато чувствительно к сдвигу распределения: схема, которой не было в прошлых данных, для модели выглядит нормальной.

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

За основу берём тот вариант, который выдерживает матрицу ошибок конкретного процесса: где дороже пропустить событие, а где — заблокировать добросовестного клиента.

Этапы работы: от разбора данных до передачи решения

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

1. Разбор данных и постановка задачи. Профилируем источники: смотрим заполненность полей, расхождения между системами, задержку появления данных и признаки утечки целевой переменной. Фиксируем, что именно предсказываем и в какой момент времени эта информация реально доступна.
2. Подготовка признаков. Собираем витрину для обучения, описываем расчёты и версионируем их так, чтобы одинаковые значения получались и при обучении, и при работе модели.
3. Базовое решение и сравнение. Строим простую модель-ориентир: она показывает, есть ли в данных сигнал вообще, и служит планкой, ниже которой усложнять нечего.
4. Проверка на независимой выборке. Оцениваем качество на отложенном периоде, который не пересекается с обучающим по времени. Так видно, держится ли результат на новых данных, а не только на знакомых примерах.
5. Калибровка и выбор порога. Приводим оценки к реальным вероятностям и подбираем границу срабатывания под цену ошибок первого и второго рода.
6. Внедрение модели. Сервис оценки подключаем к процессу заказчика и запускаем в теневом режиме — модель считает, решение принимает человек; версии и параметры фиксируются, чтобы результат был воспроизводим.
7. Передача в эксплуатацию. Отдаём регламенты переобучения, наборы проверок, дашборды по дрейфу входных данных и порядок отката на предыдущую версию.

Что остаётся у команды заказчика после передачи

Передача завершена не тогда, когда модель показана на демо, а когда команда заказчика может объяснить любое её решение, повторить обучение на тех же данных и отключить модель без нас. Поэтому сдаём пакетом артефактов, а не набором скриптов: у каждого решения описана граница применимости и условия, при которых его нужно пересмотреть.

Что остаётся на руках:

• Документация по модели: источники данных, схема признаков, метрики на отложенной выборке, известные ограничения и сценарии, где решение нельзя принимать без ручной проверки.
• Регламент переобучения: триггеры — падение метрик, сдвиг распределения входных данных, смена бизнес-правил; периодичность, ответственный, порядок валидации новой версии.
• Политика работы с решениями: пороги для автоматического одобрения, отказа и ручного разбора; как фиксируется несогласие специалиста и как этот сигнал возвращается в обучающие данные.
• Схема мониторинга качества: контрольные срезы, метрики стабильности входа и качества выхода, частоты расчёта, пороги оповещений и порядок действий дежурного.
• Карта версий и откат: какой набор данных и параметров породил каждую версию, как развернуть предыдущую и что происходит с уже принятыми решениями.
• Матрица доступов: кто вправе менять правила, кто — переобучать, кто — только смотреть, и как это разделение проверяется.
• Критерии приёмки: по каким метрикам принимается каждая версия и в каких точках мы подключаемся дальше.

Кейс: скоринг и антифрод в одном потоке заявок

Заявки приходили в один поток, но обрабатывались двумя независимыми сервисами: скоринг считал вероятность дефолта, антифрод — риск мошенничества, и каждый видел только свою часть признаков. На практике это давало две проблемы: доля ложных срабатываний антифрода доходила до 12%, а часть подтверждённого мошенничества проходила внутри уже одобренных заявок.

Что перестроили

Оба контура свели в единый поток: признаки собираются в общее хранилище на уровне события заявки, антифрод и скоринг работают по одной витрине и обмениваются решениями до выдачи ответа клиенту. Пороги антифрода настраиваются по сегментам — для зарплатных клиентов и новых заёмщиков они разные, поэтому снижение ложных срабатываний не куплено ростом пропусков. Версии моделей фиксируются в MLflow, и откат на предыдущую версию не требует пересборки потока.

Метрики до и после снимались на одном периоде нагрузки, чтобы сравнение было честным. Поток заявок вырос примерно втрое без расширения команды ручного разбора, а доля отказов, которые клиент оспорил и выиграл, сократилась вдвое.

Что делать, если в компании уже работают правила и ручные проверки

Правила и ручные проверки — не то, что нужно гасить при внедрении ML. Они уже содержат экспертизу: лимиты, стоп-факторы, отраслевые регламенты, наработанные годами. Разумный порядок — не замена, а параллельная работа: старый контур остаётся основным и продолжает принимать решения, новый считается в теневом режиме на том же потоке заявок.

Выбор между правилами и машинным обучением делают по природе признака. Жёсткие детерминированные условия — санкционные списки, возрастные и лимитные ограничения, обязательные стоп-факторы — остаются правилами: их нужно уметь объяснить проверяющему и регулятору. Машинное обучение забирает то, где правил стало слишком много и они начали конфликтовать: пересечения признаков, нелинейные зависимости, сегменты, где корректная ручная проверка превращается в очередь на несколько дней. По методологии CRISP-DM это отдельный шаг — анализ данных и постановка задачи, а не подбор алгоритма.

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

Пограничные случаи выносятся в отдельный контур. Модель возвращает оценку, а не вердикт: в зоне неопределённости кейс уходит на ручную проверку с готовым набором признаков и причин, которые её подсветили. Порог настраивается, доля таких обращений — управляемый параметр, обычно это единицы процентов, и её можно двигать, не меняя ни правила, ни модель.

Дальше контур сужается постепенно: правило отключается только тогда, когда модель стабильно его перекрывает на отложенной выборке и в живом потоке. Откат — возврат порога и включение правила обратно, без релиза и остановки приёма заявок.

Технические сомнения, которые стоит снять до старта

Технические сомнения вокруг ML в финансах редко касаются самих алгоритмов — они касаются данных, объяснимости решений, устойчивости модели на новых данных и того, как всё это встроится в уже работающий процесс. Ниже — четыре вопроса, которые задают до старта чаще всего, и то, как мы закрываем их инженерно.

Как объяснить решение модели проверяющему или клиенту?

Для финансов объяснимость — не надстройка, а требование. Даём важности признаков по каждому решению, локальные пояснения под конкретный случай и правила-сурогаты, по которым решение воспроизводится человеком. На выходе — формулировка, которую можно показать в спорной ситуации.

Модель переобучится и развалится на новых данных?

Это ловится на этапе проверки, а не на проде. Обучаем на прошлом, проверяем на будущем — отложенный по времени период вместо случайной выборки. После запуска отслеживаем качество и дрейф входных данных, переобучение идёт по регламенту и по триггеру деградации.

Как встроить модель в текущий процесс?

Модель не заменяет правила, а работает поверх них. Сначала режим подсказок: специалист видит оценку и объяснение, решение принимает сам. Когда точность на уверенных исходах подтверждена, эти случаи уходят в автоматику, а спорные остаются человеку. Интеграция — через сервисный слой, без перестройки процессов.

Обсудим задачу и вернёмся с оценкой и планом работ

Оценка проекта по моделям машинного обучения для финансов начинается не с выбора алгоритма, а с разбора задачи и данных: какая целевая переменная, как быстро приходит подтверждение правильного ответа, какие ошибки дороже — пропущенная просрочка или отклонённый платёжеспособный клиент. От этого зависят метрика, порог срабатывания и схема проверки качества. Поэтому обсуждение задачи идёт раньше, чем мы называем сроки.

На разборе закрываем конкретные вопросы, каждый из которых меняет план работ:

• Данные и разметка. Где лежат истории выдач и операций, подтверждён ли исход по каждому случаю, сколько времени проходит до появления метки.
• Метрика и порог. Какая доля ошибок допустима на рабочем потоке, как соотносятся потери от пропуска и от ложного срабатывания.
• Схема проверки. Отложенный по времени период вместо случайного разбиения — иначе качество на бумаге выше, чем в рабочем контуре.
• Объяснимость. Какие решения нужно обосновывать перед проверяющими и клиентом, какие признаки допустимо использовать.
• Формат внедрения. Пакетный скоринг, оценка в момент операции или очередь ручной проверки по приоритету.
• Наблюдение и откат. Контроль дрейфа входных данных, переобучение по расписанию, возврат на предыдущую версию модели.
• Ресурсы. Что требуется от вашей стороны по данным, доступам и знанию процесса.

Опишите задачу — вернёмся с оценкой проекта и планом работ: этапы, состав команды, зоны ответственности.