ML-Based Anti-Fraud System Implementation

ML-система антифрода

Фрод-команды работают быстро. Новую схему мошенничества обнаружили — через 48 часов мошенники адаптировались под правило-исключение. Rule-based антифрод всегда опаздывает на один шаг. ML-система с поведенческим анализом и anomaly detection успевает ловить паттерны раньше, чем правила написаны.

Типы фрода и методы детекции

Транзакционный фрод. Несанкционированные транзакции по скомпрометированным картам/аккаунтам. Классическая бинарная классификация — fraud/not-fraud на уровне транзакции. Ключевые признаки: velocity (сколько транзакций за последний час), geography (новая страна), device fingerprint, merchant category.

Account takeover (ATO). Захват аккаунта: смена пароля, добавление нового устройства, вывод средств. Детектируется через поведенческую аномалию — пользователь вдруг начинает вести себя иначе, чем 6 месяцев истории.

Synthetic identity fraud. Мошенник создаёт «синтетическую» личность из реальных фрагментов данных разных людей. Детектируется через граф-анализ: несоответствия в identity graph, необычные паттерны формирования кредитной истории.

Friendly fraud (chargeback abuse). Реальный пользователь заявляет, что транзакция не была авторизована. Задача — отличить реальный фрод от злоупотребления chargeback. Поведенческие признаки и история диспутов.

Архитектура real-time системы

Антифрод на транзакциях — это задача с жёсткими latency требованиями: решение нужно за 100–300ms до авторизации транзакции. Это диктует архитектуру:

Транзакция → Kafka → Feature Store → ML-модель → Decision Engine → Ответ
               ↑
        Online features:          Offline features (pre-computed):
        - velocity (Redis)        - customer risk profile
        - device fingerprint      - merchant risk score
        - session behavior        - historical patterns

Feature Store — критически важный компонент. Online features (velocity, текущая сессия) — из Redis, latency <5ms. Offline features (профиль клиента за 90 дней) — pre-computed в Feast или Hopsworks, latency <20ms.

Модель. XGBoost или LightGBM для core скоринга. ONNX Runtime для инференса — латентность в 3–5x ниже, чем Python скоринг на сырой модели. Цель: P99 latency <50ms только для ML-части.

Граф-анализ для синтетического фрода

Это наиболее технически интересная часть. Транзакционный граф: узлы — аккаунты, устройства, IP, телефоны; рёбра — транзакции, связи. Паттерны фрода в графе:

• Один device_fingerprint → много аккаунтов (device sharing у фрод-ринга)
• Star pattern: новые аккаунты все отправляют деньги одному получателю
• Cyclic transfers: A→B→C→A — отмывание через кольцо

Graph Neural Networks (GraphSAGE, GAT) на транзакционном графе дают +5–12% AUC по сравнению с tabular моделями без графовых признаков.

import torch_geometric as pyg

class FraudGNN(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.conv1 = pyg.nn.SAGEConv(in_channels=64, out_channels=128)
        self.conv2 = pyg.nn.SAGEConv(128, 64)
        self.classifier = torch.nn.Linear(64, 1)

    def forward(self, x, edge_index):
        x = F.relu(self.conv1(x, edge_index))
        x = self.conv2(x, edge_index)
        return torch.sigmoid(self.classifier(x))

Практический кейс

Платёжная система, 2.5 млн транзакций в день. Исходная система: 47 жёстких правил. Потери от фрода: 0.18% от оборота. Правила писали неделями, мошенники обходили через 3–5 дней.

После внедрения ML-антифрода:

• Потери от фрода: 0.06% (снижение в 3x)
• False Positive Rate (честные транзакции заблокированы): снизился с 2.1% до 0.4%
• Новый паттерн фрода детектируется автоматически через аномалию, правило пишется только для white-listing исключений
• Время реакции на новую схему: 4–6 часов вместо недели

P99 latency инференса: 38ms (ONNX Runtime + Redis для online features).

Работа с имбалансом в антифроде

Соотношение fraud/legit: типично 1:500 – 1:2000. При таком imbalance:

• Sampling: undersample majority class для обучения, но оценивать на реальном распределении
• Метрики: не accuracy (бессмысленна при 1:2000), а precision@recall=0.9, Average Precision, Kolmogorov-Smirnov статистика
• Порог не 0.5: подбираем threshold под бизнес-требование — сколько FP допустимо при каком уровне recall

Monitoring и champion-challenger

Фрод-паттерны дрейфуют. PSI мониторинг ежедневно. Champion-challenger: новая версия модели на 10% трафика параллельно с champion. Переключение при подтверждённом улучшении метрик.

Сроки: 6–10 недель для базовой транзакционной системы, 4–7 месяцев для комплексного решения с граф-анализом и real-time feature store.