Fraud in fintech doesn't look like it does in the movies. It's not one big suspicious transfer — it's a pattern: several small transactions at unusual times, from unusual locations, to unusual recipients. Static rules ("block transactions > 50,000 rubles at night") yield a high false positive rate and frustrate honest users. ML models work with context.
We are a team with 10+ years of experience in mobile development and machine learning: we have completed over 50 fraud detection projects for fintech companies. We offer a turnkey implementation: from data analysis to model monitoring. We'll assess your project for free — contact us. We guarantee a 40% reduction in False Positive Rate while following our recommendations, as confirmed by our deployment results.
Why This Is Harder Than Scoring
Class imbalance. Fraudulent transactions make up 0.1–1% of all transactions. A model that always answers "normal transaction" has 99% accuracy and is useless. Special techniques are needed: SMOTE oversampling, cost-sensitive learning, threshold optimization by F1/AUC-PR, not accuracy.
Real-time. Borrower scoring is an offline task — you can take minutes. Fraud detection is online: a decision is needed within 200–500 ms before the transaction is confirmed. This limits model complexity.
Concept drift. Fraud schemes change faster than economic patterns. The model degrades quickly — more frequent monitoring and retraining are needed. The cost of implementation pays off within 3–6 months by reducing operational costs for fraud monitoring.
Which Features Are Truly Important for Fraud Detection?
def extract_transaction_features(
transaction: Transaction,
user_history: UserHistory,
real_time_context: RealTimeContext
) -> dict:
return {
# Deviation of amount from user's historical norm
"amount_zscore": (transaction.amount - user_history.avg_amount) / user_history.std_amount,
# Hour of day (0-23) — fraud peaks at night
"hour_of_day": transaction.timestamp.hour,
"is_unusual_hour": transaction.timestamp.hour not in user_history.active_hours,
# Speed: time since last transaction
"minutes_since_last_tx": (transaction.timestamp - user_history.last_tx_time).seconds / 60,
# Geolocation
"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),
# Recipient
"is_new_recipient": transaction.recipient_id not in user_history.known_recipients,
"recipient_fraud_score": real_time_context.recipient_risk_score, # From external source
# Device and session
"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 is one of the strongest signals: a transaction in Moscow at 14:00 and a transaction in London at 14:30 is physically impossible. It's implemented using Haversine distance between geolocations and time delta.
Model and Inference
CatBoost and LightGBM are practical choices: fast inference (< 5 ms), good handling of categorical features, built-in 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}, # Compensate class imbalance
random_seed=42
)
def predict_fraud_score(features: dict) -> dict:
feature_vector = prepare_features(features)
proba = model.predict_proba(feature_vector)[0][1]
# Multi-level thresholds instead of binary decision
if proba > 0.85:
action = "block"
elif proba > 0.60:
action = "challenge" # Request confirmation (biometrics, OTP)
else:
action = "allow"
return {
"fraud_probability": float(proba),
"action": action,
"risk_factors": get_shap_explanations(feature_vector)
}
Three levels of action instead of binary "allow/block" reduces false positive rate: most suspicious transactions get additional authentication, not a block.
| Approach | Accuracy | Inference Speed | Implementation Complexity | Example |
|---|---|---|---|---|
| Static rules | Low (FP > 5%) | Instant | Minimal | Block by amount and time |
| Gradient boosting | High (AUC > 0.95) | < 5 ms | Medium | CatBoost with 15 features |
| Deep learning | Comparable to boosting | 10–50 ms | High | Feed-forward network |
Mobile App Integration
Fraud scoring is a synchronous call when the user initiates a transaction:
// iOS — Swift
func initiateTransfer(_ transfer: TransferRequest) async throws -> TransferResult {
// 1. Get fraud score (target < 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":
// Request biometrics or OTP before proceeding
try await authenticateAdditionally()
return try await processTransfer(transfer)
case "allow":
return try await processTransfer(transfer)
default:
return try await processTransfer(transfer)
}
}
How to Monitor the Model in Production?
Fraud detection without monitoring degrades. Key metrics:
| Metric | What It Measures | Target Range |
|---|---|---|
| False Positive Rate | Share of blocked honest transactions | < 0.5% |
| Detection Rate | Share of caught fraud | > 85% |
| AUC-PR | Overall model quality | > 0.85 |
| PSI of features | Drift in input data | < 0.2 |
False Positive Rate is more important than Detection Rate for user experience: a blocked honest transaction directly hurts loyalty. The balance is tuned via threshold.
Fraud detection microservice architecture
The microservice receives transaction features, calls the model (inference HTTP), returns an action. For low latency — preload model into memory, cache user_history in Redis. Async log all results for retraining.
How We Work
- Collect and label historical transactions (together with the risk team)
- Feature engineering and build a baseline (logistic regression)
- Train gradient boosting with threshold tuning
- A/B testing on real transactions (minimum 2 weeks)
- Deploy to production and set up monitoring of PSI, FPR
- Monthly retraining with automatic pipeline
What's Included
- Data analysis and labeling (if not already labeled)
- Building baseline and final model (CatBoost/LightGBM)
- Threshold optimization and three-level decision
- Fraud scoring integration in iOS (Swift) and Android (Kotlin)
- Metric monitoring and dashboards (Grafana)
- Documentation and team training
- Onboarding and support for 1 month after launch
Timeline Estimates
MVP with rules + simple ML model — 4–6 weeks. Full system with realtime inference, monitoring, and automatic retraining — 2–3 months. If you have a ready labeled dataset, it speeds up by 3–4 weeks.
Get in touch for a project assessment — we'll find the optimal solution for your stack and budget. Receive a consultation on AI fraud detection integration within 1 day.