AI-Based Fraud Transaction Detection: LightGBM, ONNX, Real-Time

We integrate an AI fraud transaction detector based on LightGBM and ONNX Runtime that analyzes each transaction within 50–200ms. Within that time, the system collects velocity features from Redis, computes z-score deviations, checks the merchant risk DB, and outputs the model score. If the model produces a false positive, the client loses money and patience. If it misses a fraudster—even more. We build turnkey ML detectors that reduce FPR to 0.5% without sacrificing recall. Below is the technical implementation.

Our experience includes over 10 fintech projects where we solved feature coordination and concept drift challenges. Every project involves custom feature engineering, threshold tuning, and online learning. We use LightGBM with cost-sensitive training and export the model to ONNX Runtime for inference with 3–8ms latency. A feature store based on Redis and PostgreSQL ensures real-time retrieval of all features. Drift monitoring via ADWIN and Page-Hinkley tests allows automatic retraining when fraud patterns shift. Result: P99 latency of 67ms for 800,000 transactions per day, FPR reduced from 3.2% to 0.6%. Savings from reduced false positives reached millions of rubles monthly.

Which features deliver 80% of predictive power?

def build_transaction_features(txn: Transaction,
                                 customer_profile: CustomerProfile,
                                 velocity: VelocityStore) -> np.ndarray:
    features = {
        # Velocity
        "txn_count_1h": velocity.count(txn.card_id, window="1h"),
        "amount_sum_1h": velocity.sum(txn.card_id, "amount", window="1h"),
        "unique_merchants_24h": velocity.nunique(txn.card_id, "merchant_id", window="24h"),

        # Deviation
        "amount_zscore": (txn.amount - customer_profile.avg_amount) / customer_profile.std_amount,
        "is_new_country": int(txn.country not in customer_profile.known_countries),
        "hour_is_unusual": int(txn.hour not in customer_profile.active_hours),

        # Context
        "merchant_chargeback_rate": merchant_risk_db.get(txn.merchant_id),
        "device_first_seen_days": device_db.days_since_first_seen(txn.device_id),
        "bin_country_mismatch": int(txn.bin_country != txn.transaction_country)
    }
    return np.array(list(features.values()), dtype=np.float32)

Why LightGBM is optimal for anti-fraud systems?

LightGBM is the optimal choice for most production cases: fast inference (1.5x faster than CatBoost by latency), excellent handling of missing values (not all features are always available), and interpretability via SHAP. Exporting to ONNX and inference via ONNX Runtime yields 3–8ms latency on a typical feature set. This leaves enough budget for feature retrieval from Redis and the final decision engine. More details: LightGBM documentation.

How do we set thresholds and account for error costs?

A classic mistake: optimize for AUC and choose a threshold of 0.5. In anti-fraud, this is wrong. The cost of errors is asymmetric: FN (missing a fraudster) is a direct loss equal to the transaction amount; FP (blocking a legitimate transaction) incurs complaint handling costs and negative UX impact. We build a cost matrix to select the optimal threshold based on actual economics. For large amounts, the threshold is lowered; for small ones, it is raised (dynamic threshold by amount).

How is online learning and adaptation to drift implemented?

Fraud patterns change quickly. Once a month is too slow. We implement:

Mini-batch online learning. The model is updated every 24 hours on newly labeled transactions (labeling comes from actual chargebacks plus manual verification). LightGBM supports continue training.

Concept drift detection. ADWIN or Page-Hinkley test on the incoming feature stream. When drift is detected, the model is automatically retrained and the team is notified.

Shadow mode. The new model version runs in parallel, scoring 100% of traffic without affecting decisions. Metrics are compared after 48 hours—deployment proceeds only if improvement is confirmed.

Practical case

Client: an acquiring company handling 800,000 transactions per day. Problem: The old rule-based system produced a False Positive Rate of 3.2%—every 31st legitimate transaction was blocked. Losses from FP: complaints, churn, damaged reputation with merchants.

After the ML detector (LightGBM, 180 features, ONNX Runtime):

• FPR dropped to 0.6%.
• Fraud Detection Rate at same FPR increased by 34%.
• P99 latency (feature retrieval + inference): 67ms.
• Automatic detection of a new fraud pattern (a wave targeting a specific BIN): 3 hours instead of a day of manual analysis.

Key insight: 60% of the accuracy gain came from adding velocity features with different time windows (1 min / 5 min / 1 hour)—they capture coordinated attacks on multiple cards simultaneously.

Comparison of batch vs online learning

What's included in the turnkey implementation

• Feature engineering: development and validation of features, feature store on Redis + PostgreSQL.
• Model: LightGBM with cost-sensitive training, export to ONNX.
• Infrastructure: ONNX Runtime on Kubernetes, pipeline for online learning.
• Monitoring: drift detection (ADWIN), score distribution, FPR/Recall.
• Documentation: model card, technical docs, runbook.
• Training: hands-on session for the client's team, transfer of code and access.
• Support: 3 months of post-production maintenance.

Typical mistakes when deploying

• Using AUC as the only metric—wrong; a cost matrix must be considered.
• Ignoring feature drift—the model quickly becomes outdated.
• Not running a shadow mode before deployment—risks degrading metrics.

Implementation phases

1. Analytics (1–2 weeks): requirements gathering, data audit, feature prototype.
2. Design (1 week): architecture of feature store, ML pipeline, monitoring.
3. Development (2–4 weeks): model, inference service, online learning loop.
4. Testing (1 week): A/B test in shadow mode, metric verification.
5. Deployment (1 week): production launch, monitoring setup.
6. Support (3 months): feature optimization, drift mitigation.

Timeline and pricing

A basic detector takes 4–8 weeks; a production system with real-time feature store, online learning, and monitoring takes 10–16 weeks. Pricing is determined individually after evaluating your project. We guarantee at least a 50% reduction in FPR from your current values.

Request a consultation to evaluate your project. Contact us to discuss details and get a proposal.