Fraud detection ідентифікує зловмисні транзакції або поведінку серед легітимних. Це adversarial проблема - фродстери активно адаптуються до вашого захисту. Успіх вимагає real-time scoring, обробки екстремального дисбалансу класів та постійного оновлення моделей.

Де використовується

Fraud detection захищає дохід та довіру в різних індустріях:

Платежі: Фрод кредитних карток, несанкціоновані транзакції
Банкінг: Account takeover, відмивання грошей, synthetic identity
E-commerce: Зловживання промо, фейкові відгуки, return fraud
Страхування: Claims fraud, інсценовані аварії
Реклама: Click fraud, impression fraud, attribution fraud
Геймінг: Виявлення читерства, бот-акаунти

Продукти: Stripe Radar, PayPal risk engine, Visa Advanced Authorization, Amazon fraud prevention.

Типові дані

Аспект	Типові значення
Обсяг транзакцій	10K до 100M транзакцій/день
Fraud rate	0.01% до 1% транзакцій
Вимога латентності	< 100ms для real-time scoring
Ознаки	100 до 1000+ сигналів
Затримка мітки	Години до тижнів для підтвердженого фроду

Типова структура таблиці:

txn_id | user_id | amount | merchant | device | ip | timestamp | is_fraud

Категорії ознак: - Атрибути транзакції (сума, тип, локація) - Історія користувача (velocity, патерни, tenure) - Device/network сигнали (fingerprint, IP reputation) - Behavioral biometrics (патерни набору, рухи миші) - Graph features (мережеві зв'язки, shared attributes)

Що робимо на практиці

Визначити типи фроду - Що вважається фродом? Різні моделі для різних типів?
Встановити якість міток - Як підтверджується фрод? Яка затримка мітки?
Побудувати feature pipeline - Real-time та batch ознаки з консистентним обчисленням
Обробити дисбаланс класів - Стратегії семплінгу, loss functions, тюнінг порогів
Натренувати початкову модель - Gradient boosting з engineered features
Додати graph features - Зв'язки, shared devices, network patterns
Впровадити rules layer - Hard blocks для очевидних патернів
Задеплоїти multi-layer систему - Rules + ML scores + human review queue
Моніторити на дрифт - Fraud patterns змінюються; staleness моделі небезпечна
Закрити feedback loop - Підтверджені frauds тренують наступну модель; adversarial retraining

Спочатку Baseline

Почніть з rules-based системи перед ML:

Velocity rules: > N транзакцій за T хвилин
Amount thresholds: Незвичний розмір транзакції
Geographic rules: Неможлива подорож, високоризикові країни
Device rules: Відомі погані пристрої, кілька акаунтів на пристрій
Behavioral rules: Аномалії першої транзакції, breaks патернів

Чому правила спочатку: - Інтерпретовані та auditable - Швидко деплоїти та оновлювати - Ловлять очевидний фрод негайно - Дають training signal для ML

ML layer додає: nuanced scoring, узагальнення патернів, обробку нових attack vectors.

Типові моделі та коли їх обирати

Модель	Найкраще для	Час тренування	Інтерпретованість
Rules engine	Відомі патерни, регуляторні вимоги	N/A	Висока
Logistic Regression	Baseline, інтерпретованість	Хвилини	Висока
XGBoost/LightGBM	Найкращий дефолт, табличні ознаки	Години	Середня
Neural Network	Складні патерни, великі дані	Години-Дні	Низька
Isolation Forest	Unsupervised, нові fraud patterns	Години	Низька
Graph Neural Network	Network fraud, координовані атаки	Дні	Низька
Autoencoders	Anomaly detection, reconstruction error	Години	Низька

Продакшн-системи зазвичай комбінують: Rules (hard blocks) + ML score (risk ranking) + Manual review (high-risk queue).

Патерни Feature Engineering

Velocity features: - Кількість транзакцій за 1h, 24h, 7d, 30d - Унікальні merchants, унікальні devices - Сума amount sum, max, mean по вікнах - Acceleration (це вікно vs попереднє)

Behavioral deviation: - Поточна сума / середня сума користувача - Час з останньої транзакції - Відстань від типової локації - New device flag, new merchant flag

Network features: - Акаунти, що ділять device/IP/адресу - Graph distance до відомого фроду - Community detection scores - PageRank-style influence scores

Device та session: - Device fingerprint match - Browser/OS аномалії - Патерни тривалості сесії - Консистентність JavaScript rendering

External enrichment: - IP reputation scores - BIN/card reputation - Вік email-домену - Верифікація номера телефону

Оцінка та метрики

Основні метрики:

Метрика	Опис	Типова ціль
Precision at threshold	% заблокованих транзакцій, що є фродом	> 50%
Recall at threshold	% фроду зловленого	> 80%
False positive rate	% хороших транзакцій заблокованих	< 1%
Detection rate by amount	% fraud dollars зловлено	> 90%
AUC-PR	Area under precision-recall curve	> 0.5

Бізнес-метрики: - Fraud loss rate (fraud amount / total amount) - Customer friction (вплив false positives) - Manual review volume - Time to detection

Підводні камені: - Оптимізація для AUC ігнорує бізнес-costs (false positive cost != false negative cost) - Delayed labels означають оцінку на застарілих даних - Фродстери адаптуються після деплою моделі - Aggregated метрики ховають segment-level failures

Режими відмови та чеклист дебагу

[ ] Label leakage: Використання ознак, виведених з fraud investigation
[ ] Label delay: Модель оцінюється на непідтверджених мітках
[ ] Adversarial adaptation: Фродстери вивчили пороги моделі
[ ] Population shift: Новий сегмент користувачів з іншими патернами
[ ] Feature staleness: Real-time ознаки не оновлюються
[ ] Threshold decay: Операційна точка більше не оптимальна
[ ] Cold start: Нові користувачі без історії, високий FP rate
[ ] Coordinated attack: Graph patterns пропущені per-transaction моделлю

Продакшн-чеклист

Перед деплоєм: - [ ] Оцінено лише на підтверджених мітках - [ ] Продуктивність перевірена по сегментах (нові користувачі, high-value тощо) - [ ] Вимоги латентності виконані (< 100ms p99) - [ ] Fallback behavior визначена (якщо модель впала, default allow чи block?) - [ ] Manual review queue capacity запланована - [ ] Explainability доступна для review queue

Після деплою: - [ ] Real-time моніторинг розподілу scores - [ ] Відстеження fraud rate по score buckets - [ ] Alert на зсув розподілу scores - [ ] Daily/weekly review продуктивності моделі - [ ] Регулярне ретренування (weekly або triggered by drift) - [ ] Red team exercises (симуляція атак)

Compliance: - [ ] Рішення моделі auditable - [ ] Adverse action reasons доступні - [ ] Bias monitoring по protected attributes - [ ] Regulatory reporting на місці

Інструменти та стек

Категорія	Інструменти
Feature store	Feast, Tecton, Redis (real-time)
Тренування	XGBoost, LightGBM, PyTorch
Graph analytics	Neo4j, NetworkX, PyTorch Geometric
Real-time scoring	FastAPI, Seldon, custom C++
Rules engine	Custom, Drools, Open Policy Agent
Моніторинг	Evidently, custom dashboards
Case management	Custom, SAS, FICO

Приклад міні-кейсу

Сценарій: Payment processor обробляє 5M транзакцій/день, 0.1% fraud rate, $50M річних fraud losses.

Поточний стан: Rule-based система ловить 60% фроду, 2% false positive rate.

Підхід: 1. Feature engineering: 200 ознак (velocity, behavioral, device, network) 2. Модель: LightGBM з focal loss для дисбалансу 3. Threshold: Встановлено для 0.5% FP rate, ~80% recall 4. Архітектура: Rules layer (hard blocks) → ML score → Review queue

Продакшн setup: - Model scoring за < 50ms - Real-time ознаки з Kafka streams - Щоденний dashboard продуктивності моделі - Щотижневе ретренування з підтвердженими мітками - Щомісячний adversarial review

Результати: 85% fraud detection, 0.5% FP rate, $15M річне зменшення фроду.

Ongoing work: Graph-based detection для координованого фроду, покращення device fingerprinting.

Пов'язані сторінки

Індекс: ML Field Guide
Unsupervised виявлення аномалій
Бінарна класифікація в продакшні
Основи Feature Engineering

Додаткове читання

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

Дослідіть пов'язану модель на практиці: відкрийте Fraud Detection System - AI Simulation і змінюйте параметри під час роботи. Усе лишається у вашому браузері.

▶ Відкрити симуляцію Fraud Detection System - AI Simulation

Системи виявлення фроду