Когда карту прикладывают к POS-терминалу, клиент ждёт максимум секунду-две. За это окно операция проходит десятки шагов — сеть, карточную схему, core banking и фрод-контроль. Бюджет, остающийся фрод-скоринг-сервису, обычно меньше 100 миллисекунд. Эта статья о том, как тратятся эти 100 мс и как строится архитектура.
Бюджет задержки
Типичная разбивка бюджета для real-time фрод-скоринга:
- Сеть + десериализация: 10 мс
- Feature lookup (feature store): 20-30 мс
- Инференс модели: 20-40 мс
- Движок правил + решение: 10 мс
- Логирование + ответ: 10 мс
Цель — ~80 мс суммарно; p99 не должен превышать 100 мс. Превышение бюджета переводит операцию из синхронного отказа в асинхронный мониторинг — а это снижает долю пойманного фрода.
Двухуровневое решение: правила + модель
Зрелая фрод-система — не только ML:
- Движок правил (детерминированный): чёрные списки, правила страны/лимита, velocity (5 операций за минуту) — быстрые объяснимые проверки. Микросекунды.
- ML-модель (вероятностная): gradient boosting (XGBoost/LightGBM) или компактная нейросеть. Учится на прошлом поведении и ловит то, что правила пропускают.
Решение — комбинация: если правило говорит hard-decline, модель не запускается; иначе скор модели объединяется с порогом.
Feature store: горячий и холодный
Признаки, нужные фрод-модели, приходят на двух скоростях:
- Горячие (online): real-time-счётчики вроде 'операций за последнюю минуту' или 'суммы за последние 5 минут'. Хранятся в Redis или похожем low-latency store.
- Холодные (offline): batch-вычисляемые значения вроде 'средний расход клиента за 90 дней' или 'типичный час операции'. Обновляются ежедневно/ежечасно.
Feature store вроде Feast генерируют оба уровня из одного определения, поэтому обучение и serving используют одну feature-логику (нет train-serve skew).
Стрим-хребет
События операций текут через Kafka (или аналог). Типичный конвейер:
- Событие операции попадает в Kafka-топик.
- Stream-процессор (Flink/Kafka Streams) обновляет горячие признаки.
- Скоринг-сервис на синхронном вызове читает online-признаки, запускает модель и возвращает скор.
- Решение и скор пишутся в audit-топик; downstream-отчётность и переобучение модели питаются оттуда.
Модель должна оставаться свежей
Паттерны фрода меняются за недели. В архитектуре нужны два контура:
- Online: скор возвращается мгновенно.
- Offline: размеченные исходы (chargeback, ручной разбор) собираются; модель переобучается еженедельно/ежемесячно; champion-challenger в тени тестирует новую модель и продвигает её при выигрыше.
Объяснимость и комплаенс
BDDK и EU AI Act требуют объяснимости для высоковлиятельных решений вроде фрода. Для каждого отказа надо логировать топ 3-5 признаков модели (со значениями SHAP). Обоснование вроде 'сумма в 8 раз выше нормы и из необычной страны' отвечает и аудиту, и спору клиента.
Типичный результат
В поле с гибридом правила+модель: поимка фрода растёт на 30-45% против системы только на правилах, а false positive (отказ настоящему клиенту) падает на 20-30% при правильной калибровке порога. False positive — это прямая неудовлетворённость клиента и потерянная выручка, поэтому калибровка порога важна не меньше модели.
Заключение
Real-time фрод-скоринг — не проблема модели, а проблема бюджета задержки. Feature lookup, инференс и решение правил должны уместиться в 100 мс; модель должна оставаться свежей; каждое решение должно быть объяснимым. При правильной постройке падают и потери от фрода, и ложные отказы.
