Мы интегрируем AI-детектор мошеннических транзакций на базе LightGBM и ONNX Runtime, который анализирует каждую транзакцию за 50–200ms. За это время система собирает velocity-признаки из Redis, вычисляет z-score отклонений, проверяет merchant risk DB и отдаёт score модели. Если модель ошибается с False Positive, клиент теряет деньги и нервы. Если пропускает мошенника — теряет ещё больше. Мы строим ML-детекторы под ключ, которые снижают FPR до 0.5% без потери в выявлении. Ниже — техническая реализация.
Наш опыт — более 10 проектов в финтехе, где мы решали проблему координации признаков и дрейфа концепций. Каждый проект — это индивидуальная настройка feature engineering, порогов и онлайн-обучения. Мы используем LightGBM с cost-sensitive обучением и экспортируем модель в ONNX Runtime для инференса с latency 3–8ms. Feature store на базе Redis и PostgreSQL обеспечивает real-time retrieval всех признаков. Мониторинг дрейфа через ADWIN и Page-Hinkley тесты позволяет автоматически переобучать модель при изменении фрод-паттернов. Результат: P99 latency решения 67ms при 800 000 транзакций в день, FPR снижен с 3.2% до 0.6%. Экономия от снижения FP составила около $9k–13k ежемесячно.
Какие признаки обеспечивают 80% предсказательной силы?
| Группа | Примеры | Источник |
|---|---|---|
| Velocity features | Количество транзакций за 1 мин/1 час, сумма, уникальные merchant'ы | Redis sliding window (<5ms) |
| Deviation from history | Z-score суммы, новая страна, необычное время | Feature store (профиль клиента) |
| Contextual risk signals | Chargeback rate merchant'а, device first seen, BIN mismatch | Merchant risk DB, device DB, BIN-таблица |
def build_transaction_features(txn: Transaction, customer_profile: CustomerProfile, velocity: VelocityStore) -> np.ndarray: features = { # Velocity "txn_count_1h": velocity.count(txn.card_id, window="1h"), "amount_sum_1h": velocity.sum(txn.card_id, "amount", window="1h"), "unique_merchants_24h": velocity.nunique(txn.card_id, "merchant_id", window="24h"), # Deviation "amount_zscore": (txn.amount - customer_profile.avg_amount) / customer_profile.std_amount, "is_new_country": int(txn.country not in customer_profile.known_countries), "hour_is_unusual": int(txn.hour not in customer_profile.active_hours), # Context "merchant_chargeback_rate": merchant_risk_db.get(txn.merchant_id), "device_first_seen_days": device_db.days_since_first_seen(txn.device_id), "bin_country_mismatch": int(txn.bin_country != txn.transaction_country) } return np.array(list(features.values()), dtype=np.float32) Почему LightGBM оптимален для антифрод-систем?
LightGBM — оптимальный выбор для большинства продакшн-кейсов: быстрый инференс (в 1.5 раза быстрее CatBoost по latency), отличная работа с пропусками (не все признаки всегда доступны), интерпретируемость через SHAP. Экспорт в ONNX и инференс через ONNX Runtime дают latency 3–8ms на типичном наборе признаков. Это оставляет достаточно бюджета на feature retrieval из Redis и финальный decision engine. Подробнее — LightGBM документация.
Как мы выставляем пороги и учитываем стоимость ошибок?
Классическая ошибка: оптимизировать на AUC и выбирать порог 0.5. В антифроде это неправильно. Стоимость ошибок асимметрична: FN (пропустить мошенника) — прямые потери, равные сумме транзакции; FP (заблокировать легальную транзакцию) — стоимость обслуживания жалобы и потери от негативного UX. Строим cost matrix для выбора optimal threshold под реальную экономику. Для крупных сумм порог снижается, для небольших — повышается (динамический threshold по сумме).
Как реализуется онлайн-обучение и адаптация к дрейфу?
Фрод-паттерны меняются быстро. Раз в месяц — слишком редко. Реализуем:
Mini-batch online learning. Модель обновляется каждые 24 часа на новых размеченных транзакциях (разметка — по факту chargeback + ручная верификация). LightGBM поддерживает continue training.
Concept drift detection. ADWIN или Page-Hinkley тест на входящем потоке признаков. При детекции дрейфа — автоматическое переобучение с уведомлением команды.
Shadow mode. Новая версия модели параллельно считает score на 100% трафика без влияния на решения. Сравниваем метрики через 48 часов — деплой при подтверждённом улучшении.
Практический кейс
Клиент — эквайринговая компания, 800 000 транзакций в день. Проблема: старая rule-based система давала False Positive Rate 3.2% — каждая 31-я легальная транзакция блокировалась. Потери от FP: жалобы, churn, репутация у merchant'ов.
После ML-детектора (LightGBM, 180 признаков, ONNX Runtime):
- FPR снизился до 0.6%.
- Fraud Detection Rate при том же FPR: +34%.
- P99 latency решения (feature retrieval + inference): 67ms.
- Автоматическое обнаружение нового фрод-паттерна (волна по конкретному BIN): 3 часа вместо дня ручного анализа.
Ключевой инсайт: 60% прироста точности дало добавление velocity-признаков с разными временными окнами (1 мин / 5 мин / 1 час) — они захватывают координированные атаки на несколько карт одновременно.
Сравнение пакетного и онлайн-обучения
| Параметр | Пакетное обучение | Онлайн-обучение |
|---|---|---|
| Частота обновления | Раз в месяц | Ежедневно |
| Адаптация к дрейфу | Низкая | Высокая (ADWIN) |
| Инфраструктура | Простая | Требует pipeline |
| Латенси обновления | Часы | Минуты |
Что входит в реализацию под ключ
- Feature engineering: разработка и валидация признаков, feature store на базе Redis + PostgreSQL.
- Модель: LightGBM с cost-sensitive обучением, экспорт в ONNX.
- Инфраструктура: ONNX Runtime на Kubernetes, pipeline для онлайн-обучения.
- Мониторинг: drift detection (ADWIN), распределение score, FPR/Recall.
- Документация: model card, техническая документация, runbook.
- Обучение: тренинг команды заказчика, передача кода и доступов.
- Поддержка: 3 месяца постпродакшн сопровождения.
Типичные ошибки при внедрении
- Использовать AUC как единственную метрику — неправильно, нужно учитывать cost matrix.
- Игнорировать дрейф признаков — модель быстро устаревает.
- Не делать shadow mode перед деплоем — рискуете ухудшить метрики.
Этапы внедрения
- Аналитика (1–2 недели): сбор требований, аудит данных, прототип признаков.
- Проектирование (1 неделя): архитектура feature store, ML pipeline, мониторинг.
- Разработка (2–4 недели): модель, сервис инференса, online learning цикл.
- Тестирование (1 неделя): A/B-тест в shadow mode, проверка метрик.
- Деплой (1 неделя): production-запуск, настройка мониторинга.
- Сопровождение (3 месяца): оптимизация признаков, устранение drift.
Сроки и стоимость
Базовый детектор — 4–8 недель, production-система с real-time feature store, онлайн-обучением и мониторингом — 10–16 недель. Стоимость рассчитывается индивидуально после оценки вашего проекта. Гарантируем снижение FPR минимум на 50% от текущих значений.
Закажите консультацию для оценки вашего проекта. Свяжитесь с нами, чтобы обсудить детали и получить предложение.