Real-Time Card Fraud Detection at a GCC Tier-1 Bank — 43% Fraud Loss Reduction at Half the False-Positive Rate

MindMap deployed Fraud Guard (Fg) as the new primary fraud scoring engine, with Anomaly Detector (Ad) as the long-tail behavioural layer and Sentiment Analyzer (Sa) reused for the customer-service dispute path. The brief was structured as a parallel-run replacement — Fraud Guard would shadow the legacy engine for ten weeks before any traffic switched.

The first phase was data archaeology. Our team ingested three years of historical authorisation data, three years of confirmed fraud cases (the labels), and the full configuration history of the legacy rules engine. The objective was twofold: train a fraud model on the bank's actual fraud patterns rather than a generic benchmark, and capture the institutional knowledge embedded in the 1,400 hand-maintained rules so that the new engine could be measurably better, not just different.

The model itself is a hybrid. A gradient-boosted tree ensemble (XGBoost) handles the bulk of the scoring on classical features — amount, merchant category, geographic distance, time-of-day, velocity windows, customer behavioural baseline. A graph neural network layer adds device-to-card-to-merchant relationship signals — the patterns that distinguish a legitimate first-time international purchase from a card-testing attack. An LLM-based reasoning layer (a fine-tuned Qwen 2.5 7B model) runs only for the borderline cases where the tree ensemble's confidence is between 30% and 70%, and provides the structured explanation that the customer-service team uses.

The model is trained nightly on the rolling window of authorisation outcomes — the previous day's confirmed-fraud cases and confirmed-non-fraud cases — with a champion-challenger framework that promotes a new model version only when its lift over the production model is statistically significant on a held-out validation set.

The Fraud Guard stack runs entirely on the bank's primary on-premises infrastructure in its main data centre, with a hot-standby cluster at the bank's secondary site. No fraud scoring traffic leaves the country's borders.

The inline scoring path is the latency-critical component. The XGBoost model and the graph features are served from an in-memory feature store (Redis Cluster, sized at 480GB across the cluster) with sub-millisecond feature lookups. The XGBoost inference itself runs at a p99 of 6ms on the bank's CPU fleet — no GPU is used on the inline path because the latency overhead of GPU dispatch exceeded its benefit at this model size.

The LLM reasoning layer runs off the inline path as an asynchronous enrichment. When the inline scorer returns a borderline confidence, the transaction is approved or declined based on the deterministic threshold, and the LLM is invoked separately to generate the explanation that is attached to the authorisation record. By the time the customer calls customer service to dispute a decline (typically several minutes later), the explanation is already in the case-management system. The LLM is served on a small cluster of L40S GPUs using vLLM, with the Qwen 2.5 7B model quantised to 8-bit.

The graph component is the architectural novelty. The bank's eight million cards, the merchant base, the device fingerprints and the historical authorisation graph are held in a Neo4j cluster with a custom-built incremental updater. Graph features (neighbourhood risk score, shortest path to a known fraud cluster, community-detection cluster ID) are precomputed on a 5-minute cadence and pushed to the feature store.

The full authorisation trace, the model inputs, the model outputs and the LLM explanation are persisted to an audit store with the regulator's required retention period.