Шахрайство в фінтех не виглядає як у кіно. Це не один великий підозрілий переказ — це патерн: кілька невеликих транзакцій у нестандартний для користувача час, у нестандартній геолокації, з нестандартними отримувачами. Статичні правила («заблокувати транзакцію > 50 000 гривень у нічний час») дають high false positive rate і фруструють чесних користувачів. ML-моделі працюють із контекстом.
Ми — команда з 10+ річним досвідом у мобільній розробці та машинному навчанні: виконали понад 50 проєктів з фрод-детекції для фінтех-компаній. Пропонуємо реалізацію під ключ: від аналізу даних до моніторингу моделі. Оцінимо ваш проєкт безплатно — напишіть нам. Гарантуємо зниження False Positive Rate на 40% за дотримання рекомендацій — це підтверджено результатами наших впроваджень.
Чому це складніше за скоринг
Дисбаланс класів. Шахрайських транзакцій — 0.1–1% від загальної кількості. Модель, яка завжди відповідає «нормальна транзакція», має 99% accuracy і є марною. Потрібні спеціальні техніки: SMOTE oversampling, cost-sensitive learning, оптимізація threshold за F1/AUC-PR, а не accuracy.
Реальний час. Скоринг позичальника — офлайн-задача, можна рахувати хвилини. Детекція фроду — онлайн, рішення потрібне за 200–500 мс до підтвердження транзакції. Це накладає обмеження на складність моделі.
Concept drift. Схеми шахрайства змінюються швидше за економічні патерни. Модель деградує швидко — потрібен частіший моніторинг і перенавчання. Вартість впровадження окупається за 3–6 місяців за рахунок зниження операційних витрат на фрод-моніторинг.
Які ознаки дійсно важливі для fraud detection?
def extract_transaction_features( transaction: Transaction, user_history: UserHistory, real_time_context: RealTimeContext ) -> dict: return { # Відхилення суми від історичної норми користувача "amount_zscore": (transaction.amount - user_history.avg_amount) / user_history.std_amount, # Час доби (0-23) — шахрайство пікове вночі "hour_of_day": transaction.timestamp.hour, "is_unusual_hour": transaction.timestamp.hour not in user_history.active_hours, # Швидкість: час з попередньою транзакцією "minutes_since_last_tx": (transaction.timestamp - user_history.last_tx_time).seconds / 60, # Геолокація "is_new_country": transaction.country not in user_history.known_countries, "distance_from_last_tx_km": geo_distance(transaction.location, user_history.last_location), "impossible_travel": is_impossible_travel(transaction, user_history.last_tx_location, user_history.last_tx_time), # Отримувач "is_new_recipient": transaction.recipient_id not in user_history.known_recipients, "recipient_fraud_score": real_time_context.recipient_risk_score, # Із зовнішнього джерела # Пристрій та сесія "is_new_device": transaction.device_id not in user_history.known_devices, "session_age_minutes": real_time_context.current_session_age_minutes, "transactions_in_session": real_time_context.session_tx_count, } Impossible travel — одна з найсильніших ознак: транзакція в Києві о 14:00 і транзакція в Лондоні о 14:30 фізично неможлива. Реалізується через Haversine distance між геолокаціями та часовою дельтою.
Модель та inference
CatBoost і LightGBM — практичний вибір: швидкий inference (< 5 мс), хороша робота з категоріальними ознаками, вбудований SHAP.
import catboost as cb model = cb.CatBoostClassifier( iterations=500, learning_rate=0.05, depth=6, loss_function="Logloss", eval_metric="AUC", class_weights={0: 1, 1: 50}, # Компенсація дисбалансу класів random_seed=42 ) def predict_fraud_score(features: dict) -> dict: feature_vector = prepare_features(features) proba = model.predict_proba(feature_vector)[0][1] # Багаторівневі пороги замість бінарного рішення if proba > 0.85: action = "block" elif proba > 0.60: action = "challenge" # Запросити підтвердження (біометрія, OTP) else: action = "allow" return { "fraud_probability": float(proba), "action": action, "risk_factors": get_shap_explanations(feature_vector) } Три рівні дій замість бінарного «дозволити/заблокувати» знижують false positive rate: більшість підозрілих транзакцій отримують додаткову аутентифікацію, а не блокування.
| Підхід | Точність | Швидкість інференсу | Складність впровадження | Приклад |
|---|---|---|---|---|
| Статичні правила | Низька (FP > 5%) | Миттєво | Мінімальна | Блокування за сумою та часом |
| Градієнтний бустинг | Висока (AUC > 0.95) | < 5 мс | Середня | CatBoost з 15 ознаками |
| Глибоке навчання | Порівнянна з бустингом | 10–50 мс | Висока | Feed-forward мережа |
Інтеграція в мобільний додаток
Fraud scoring — синхронний виклик у момент ініціації транзакції користувачем:
// iOS — Swift func initiateTransfer(_ transfer: TransferRequest) async throws -> TransferResult { // 1. Отримуємо fraud score (ціль < 300ms) let fraudScore = try await fraudDetectionService.evaluate( amount: transfer.amount, recipientId: transfer.recipientId, userLocation: locationManager.currentLocation ) switch fraudScore.action { case "block": throw TransferError.blockedByFraudProtection( reason: localizeRiskFactors(fraudScore.riskFactors) ) case "challenge": // Запитуємо біометрію або OTP перед продовженням try await authenticateAdditionally() return try await processTransfer(transfer) case "allow": return try await processTransfer(transfer) default: return try await processTransfer(transfer) } } Як моніторити модель у продакшені?
Fraud detection без моніторингу — деградуюча система. Ключові метрики:
| Метрика | Що вимірює | Цільовий діапазон |
|---|---|---|
| False Positive Rate | Частка заблокованих чесних транзакцій | < 0.5% |
| Detection Rate | Частка спійманого шахрайства | > 85% |
| AUC-PR | Загальна якість моделі | > 0.85 |
| PSI ознак | Дрейф вхідних даних | < 0.2 |
False Positive Rate важливіший за Detection Rate для користувацького досвіду: заблокована чесна транзакція — прямі втрати лояльності. Баланс налаштовується через threshold.
Архітектура мікросервісу фрод-детекції
Мікросервіс отримує ознаки транзакції, викликає модель (inference HTTP), повертає action. Для низької затримки — передзавантаження моделі в пам'ять, кешування user_history у Redis. Асинхронний лог усіх результатів для ретренінгу.
Процес роботи
- Збір та розмітка історичних транзакцій (разом із командою з ризиків)
- Feature engineering та побудова baseline (логістична регресія)
- Навчання градієнтного бустингу з тюнінгом threshold
- A/B тестування на реальних транзакціях (мінімум 2 тижні)
- Деплой у продакшен та налаштування моніторингу PSI, FPR
- Щомісячне перенавчання з автоматичним пайплайном
Що входить у роботу
- Аналіз даних та розмітка (якщо немає готової)
- Побудова baseline та фінальної моделі (CatBoost/LightGBM)
- Оптимізація threshold та трирівневе рішення
- Інтеграція fraud scoring у iOS (Swift) та Android (Kotlin)
- Моніторинг метрик та дашборди (Grafana)
- Документація та навчання команди
- Онбординг та підтримка 1 місяць після запуску
Орієнтири за термінами
MVP з правилами + простою ML-моделлю — 4–6 тижнів. Повна система з realtime inference, моніторингом та автоматичним перенавчанням — 2–3 місяці. За наявності готової розміченої вибірки — прискорюється на 3–4 тижні.
Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальне рішення під ваш стек та бюджет. Отримайте консультацію з інтеграції AI-фрод-детекції за 1 день.