Антифрод для транзакций: правила или машинное обучение

Короткий ответ

Правила (rule engine) — это явные условия вида «если сумма больше X и страна карты не совпадает со страной IP — отклонить». Они прозрачны, быстро меняются и понятны аудиторам, но ловят только то, что кто-то уже описал.

ML-скоринг — модель, которая по сотням признаков оценивает вероятность мошенничества. Она находит неочевидные комбинации и адаптируется к новым схемам после переобучения, но требует размеченных данных, мониторинга и объяснений.

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

Сравнение подходов

Какие признаки используются

Признаки (features) важнее выбора алгоритма. Основные группы:

• Транзакция: сумма, валюта, MCC мерчанта, канал (e-commerce, POS, P2P), время суток.
• Velocity-признаки: число операций и сумма по карте, устройству, IP за последние 5 минут, час, сутки.
• Устройство и сессия: device fingerprint, новое ли устройство, эмулятор, скорость ввода, смена пароля перед платежом.
• Геолокация: расхождение страны карты, IP и адреса доставки, «невозможное путешествие» между двумя операциями.
• Поведение клиента: отклонение от его обычной суммы, типичных мерчантов и времени активности.
• Граф связей: сколько карт привязано к одному устройству или телефону, связи с ранее подтверждённым мошенничеством.

Velocity и поведенческие признаки требуют онлайн-хранилища агрегатов (feature store, Redis, потоковая обработка), иначе модель в продакшене увидит не те данные, что при обучении.

Ограничения реального времени

Решение по авторизации нужно принять за миллисекунды, пока ждёт платёжная схема и покупатель. Отсюда требования:

• Признаки считаются заранее или инкрементально, а не SQL-запросом к истории в момент платежа.
• Модель должна быть лёгкой в инференсе: градиентный бустинг часто удобнее глубоких сетей.
• Нужен fallback: если скоринг не ответил вовремя, срабатывает набор базовых правил, а не «пропустить всё».
• Тяжёлый анализ (графовые связи, ручная проверка) выносится в post-authorization — после одобрения, с возможностью заблокировать отгрузку или вывод средств.

Ложные срабатывания

Отклонённый честный платёж — это потерянная выручка и раздражённый клиент. Чтобы держать баланс:

• Измеряйте не только долю пойманного фрода, но и precision и долю отказов честным клиентам.
• Используйте три исхода вместо двух: одобрить, отклонить, отправить на дополнительную проверку (3-D Secure, OTP, звонок, ручная очередь).
• Подбирайте порог скора по стоимости ошибок: пропущенный фрод и ложный отказ стоят по-разному для разных сегментов.
• Проверяйте новые правила в shadow-режиме: правило логирует решение, но не блокирует, пока не оценено его влияние.

Комбинированная архитектура

Платёж -> Обогащение (device, гео, velocity из feature store)
       -> Блок-листы и обязательные правила (санкции, лимиты)
       -> ML-модель: score 0..1 + reason codes
       -> Decision rules: порог по сегменту, сумме, каналу
       -> approve / challenge / decline
       -> Логи решений -> разметка (chargeback, жалобы, аналитики)
       -> Переобучение и настройка правил

Ключевые элементы:

1. Единый decision engine, где правила и скор видны в одной логике и одном журнале.
2. Обратная связь: чарджбэки и решения аналитиков возвращаются как метки. Учтите задержку — чарджбэк может прийти через недели.
3. Кейс-менеджмент для аналитиков с причинами решения, историей клиента и кнопками действий.
4. Мониторинг дрейфа: распределение скоров, доля отказов, качество на свежих метках.

Типичные ошибки

• Обучать модель только на одобренных транзакциях — отклонённые правилами операции не получают меток, и модель «не видит» часть фрода.
• Утечка будущего: признаки, которые на момент платежа ещё не были известны.
• Копить правила без ревизии — через год никто не знает, зачем нужно половина из них.
• Один порог для всех сегментов и каналов.