Определение задачи: обнаружение мошенничества¶
~4 минуты чтения
Предварительно: Подготовка к интервью MLSD, Метрики классификации
По данным Nilson Report, глобальные потери от платёжного мошенничества в 2023 году составили $33.8 млрд, а к 2028 году прогнозируются $40.6 млрд. При этом fraud rate типичной платёжной системы -- всего 0.05-0.2%, что создаёт экстремальный дисбаланс классов 1:1000. Система, которая просто всегда отвечает "не фрод", будет иметь 99.9% accuracy -- и нулевую ценность. Именно поэтому fraud detection является каноническим кейсом на ML System Design интервью: здесь пересекаются class imbalance, adversarial environment, real-time requirements и cost-sensitive learning.
Бизнес-контекст¶
Fraud Detection -- ML-система для обнаружения мошеннических транзакций, аккаунтов или действий в реальном времени. Критически важная система для финтеха, e-commerce, страхования.
Примеры применения¶
| Компания | Тип фрода | Объём | Ущерб от пропуска |
|---|---|---|---|
| Visa/Mastercard | Payment fraud | 500M txn/day | Миллиарды $ |
| PayPal | Account takeover | 100M accounts | Репутация + деньги |
| Uber | Promo abuse | 10M rides/day | Сотни млн $ |
| Amazon | Return fraud | 1B orders/year | % от выручки |
| Insurance | Claims fraud | Millions claims | 10-20% claims |
Типы мошенничества¶
1. Payment Fraud (Платёжное)¶
- Card-not-present fraud: Украденные данные карты
- Card-present fraud: Скимминг, клонирование
- Friendly fraud: Chargeback после получения товара
- Account takeover (ATO): Взлом аккаунта
2. Identity Fraud (Идентификационное)¶
- Synthetic identity: Поддельная личность
- Identity theft: Украденные документы
- Application fraud: Ложные заявки на кредит
3. Abuse/Promotion Fraud¶
- Promo abuse: Множественные аккаунты для скидок
- Referral fraud: Фейковые рефералы
- Free trial abuse: Бесконечные триалы
4. Merchant Fraud¶
- Fake merchant: Фейковый продавец
- Collusion: Сговор с покупателем
- Money laundering: Отмывание денег
Постановка задачи¶
Функциональные требования¶
- Real-time scoring: Оценка транзакции за < 100ms
- Batch analysis: Ежедневный анализ паттернов
- Alert generation: Уведомления о подозрительной активности
- Case management: Интерфейс для расследований
- Feedback loop: Учёт решений аналитиков
Нефункциональные требования¶
| Метрика | Требование | Обоснование |
|---|---|---|
| Latency (p99) | < 100ms | Не блокировать транзакции |
| Throughput | 50K TPS | Пиковая нагрузка |
| Availability | 99.99% | Критичный сервис |
| Precision | > 90% | Минимизировать false positives |
| Recall | > 95% | Ловить почти весь фрод |
Уникальные challenges фрод-детекции¶
1. Extreme Class Imbalance¶
Легитимные транзакции: 99.9%
Фродовые транзакции: 0.1%
Проблема: Модель может просто предсказывать "не фрод" и иметь 99.9% accuracy
Решение: Precision/Recall, F1, AUC-PR, cost-sensitive learning
2. Adversarial Environment¶
Фродстеры адаптируются к модели:
- Узнают правила -> обходят их
- A/B тестят разные подходы
- Используют ботов для автоматизации
Решение: Постоянное обновление моделей, не раскрывать правила
3. Concept Drift¶
Паттерны фрода меняются со временем:
- Новые схемы мошенничества
- Сезонные изменения
- Изменения в бизнесе
Решение: Мониторинг drift, частое переобучение
4. Fast Decision Required¶
Транзакция не может ждать:
- User experience страдает
- Конкуренты не блокируют
Решение: Быстрые модели, асинхронная доскоринг
5. Label Delay¶
Узнаём о фроде с задержкой:
- Chargeback через 30-90 дней
- Некоторый фрод никогда не репортится
Решение: Semi-supervised learning, proxy labels
Метрики успеха¶
Business Metrics¶
- Fraud Loss Rate: $ потерь / $ транзакций
- False Decline Rate: % легитимных отклонённых
- Manual Review Rate: % на ручную проверку
- Chargeback Rate: % chargeback-ов
ML Metrics¶
# Precision: Из тех, что модель назвала фродом, сколько реально фрод?
precision = TP / (TP + FP) # Target: > 90%
# Recall: Из всего фрода, сколько модель поймала?
recall = TP / (TP + FN) # Target: > 95%
# False Positive Rate: Сколько легитимных блокируем?
fpr = FP / (FP + TN) # Target: < 0.1%
# Cost-weighted metrics
cost = C_fn * FN + C_fp * FP
# где C_fn = сумма транзакции, C_fp = потеря клиента
Operational Metrics¶
- Alert Volume: Количество алертов в день
- Investigation Time: Время на кейс
- Escalation Rate: % эскалаций
- Model Latency: Время scoring
Trade-offs¶
| Решение | Pros | Cons |
|---|---|---|
| Строгие правила | Высокий recall | Много false positives |
| Мягкие правила | Хороший UX | Пропуск фрода |
| Block | Останавливает фрод | Теряем клиента |
| Review | Балансирует | Дорого (люди) |
| Allow | Хороший UX | Риск потерь |
Заблуждение: accuracy -- хорошая метрика для fraud detection
При fraud rate 0.1% модель-заглушка, всегда предсказывающая "не фрод", покажет 99.9% accuracy. Это бесполезно. Правильные метрики -- precision, recall, AUC-PR и cost-weighted F1. На интервью использование accuracy -- мгновенный red flag.
Заблуждение: достаточно одной ML-модели без правил
В production fraud detection всегда работает многоуровневая система: blocklists + velocity rules + ML + graph analysis. Одна модель не покрывает edge cases (impossible travel, known fraudster devices). Правила срабатывают за 2-5 мс, модель -- за 15-30 мс. Без правил вы пропустите очевидный фрод, пока модель считает фичи.
Заблуждение: можно обучить модель на свежих данных
Из-за label delay (chargeback приходит через 30-90 дней) модель обучается на данных 3-месячной давности. Фродстеры за это время уже адаптировались. Решение -- proxy labels (жалобы клиентов, failed delivery, подозрительные паттерны) + semi-supervised learning.
Ключевые вопросы для интервью¶
- Какой тип фрода? (payment, identity, abuse)
- Какой объём транзакций? (100K/day vs 100M/day)
- Есть ли исторические данные о фроде?
- Какой текущий fraud rate? (0.01% vs 1%)
- Latency requirements? (sync vs async)
- Есть ли команда аналитиков? (manual review)
- Какие последствия ложных срабатываний? (UX vs losses)
- Регуляторные требования? (PCI DSS, GDPR)
Секция для интервью¶
Вопрос: "Почему accuracy не подходит для fraud detection?"
Слабый ответ: "Потому что данные несбалансированные."
Сильный ответ: "При fraud rate 0.1% dummy-классификатор набирает 99.9% accuracy, не поймав ни одной фродовой транзакции. Нужно оптимизировать precision (чтобы не блокировать легитимных клиентов -- каждый false positive это потенциальная потеря LTV $2000+) и recall (чтобы ловить фрод -- каждый пропущенный FN это прямой убыток в размере суммы транзакции). На практике оптимизируют AUC-PR или cost-weighted метрику, где вес FN = сумма транзакции, вес FP = стоимость потери клиента."
Вопрос: "Как выбрать порог для approve/decline?"
Слабый ответ: "Порог 0.5 -- стандартный."
Сильный ответ: "Порог 0.5 почти никогда не оптимален при дисбалансе. Я бы выбирал порог по precision-recall кривой: например, фиксирую recall на 95% и смотрю какой precision получается. Дополнительно -- три зоны: auto-approve (score < 0.1), review (0.1-0.7), auto-decline (> 0.7). Конкретные пороги калибрую на бизнес-стоимость: если FN стоит в среднем $500, а FP -- потеря клиента с LTV $2000, то optimal threshold сдвигается в сторону высокого recall."