Judge a Transaction by the Company It Keeps — Somya Rai & MD Sharique, EXL

Somya Rai and MD Sharique of EXL present an innovative fraud detection system that significantly enhances an existing XGBoost classifier by incorporating graph embeddings. Their core premise is that transactional fraud is often a property of the “neighborhood” a transaction sits in, rather than its isolated features.

The Problem: Limitations of Tabular Models

Traditional tabular fraud detection models, even with extensive feature engineering (up to 200 features), often hit a performance ceiling. Rai illustrates this with an example: a transaction scoring 0.04 in isolation might jump to 0.91 when its connections to recent fraudulent activities (user, merchant, other transactions) are considered. This demonstrates that “the signal was never in the row, it was in the edges.” Such models are inherently blind to crucial relational information, like shared device velocity chains across cards or a merchant recently going bad, because they process one row at a time.

The context of fraud varies significantly between physical (0.05% natural fraud rate) and online transactions (0.6% natural fraud rate, 12x higher), necessitating separate models due to differing base rates and signal geometries. A key constraint is a fixed analyst alert budget (0.5% to 1.5% of scored transactions), meaning the objective is “precision at a fixed K” rather than just a better overall AUC score. To be valuable, a model must move real fraud into this limited alert slice at the same latency.

The Solution: Graph Neural Networks (GNNs) for Contextual Learning

The EXL system leverages a Graph Neural Network to generate embeddings that are then fed into the existing gradient-boosted (XGBoost) model. This approach allows the model to learn a node’s properties from its neighborhood rather than solely from its own features. The GNN process involves three key operations for each layer:

1. Gather: Pulling in each neighbor’s hidden states across defining edges (e.g., transaction to user, transaction to merchant).
2. Aggregate: Collapsing the variable-sized neighbor set into a fixed-width vector using a permutation-invariant function.
3. Update: Concentrating the aggregated vector with the node’s own state, pushing it through learned weights, and stacking layers. This enables a transaction to incorporate information from its direct neighbors and their neighbors.

Four Critical Engineering Decisions

Sharique details four crucial engineering decisions that were pivotal to the system’s success:

1. Sampling without Breaking Connectivity:

   • Given the rarity of fraud (1 in 2,000), a soft target fraud rate is maintained during training (e.g., 0.5% for card-related, 6% for online), which is about 10x the natural rate but far gentler than typical tabular over/under-sampling. This is critical because every dropped negative sample would take its edges with it, destroying valuable neighborhood information.
   • The complete transactional history of every selected user is retained in the graph. If a genuine user’s history is trimmed, it breaks connectivity for their neighbors. Fraud users are never capped; only genuine users’ histories might be selectively sampled to manage the overall class ratio. Class imbalance is handled downstream using balanced batch sampling during GNN training, ensuring the average user degree at training time matches inference time.

2. Graph Construction and Leakage Control:

   • To prevent information leakage, each calendar month is constructed as its own disjoint graph, ensuring no edges cross monthly boundaries. Transactions are central nodes, linked to users and merchants, with a five-hop chain back to their own recent history.
   • This construction inherently enforces four leakage controls:
     • No future leakage: A transaction aggregates neighbors with only earlier timestamps.
     • No train/validation/test leakage: Due to disjoint months.
     • No label leakage: The fraud flag is the target, never a feature or edge.
     • No distribution leakage: Scalars and vocabulary are fit on training data only and then frozen.
   • The system employs 202 model features across three node types (73 on user, 109 on transaction, 20 on merchant), including 32 derived transactional features. These include entity history features (e.g., past transaction count, days since last activity), risk aggregates (e.g., amount Z-score, transactions per day), and true rolling window velocity and temporal features (e.g., 5-minute, 1-hour, 24-hour counts/amounts, distinct counterparties, seconds since last transaction, country change rate). These derived features tell how an entity is behaving differently from its normal baseline, complementing the graph structure.

3. GraphSAGE Aggregation for Robustness:

   • The GraphSAGE architecture is used, which is inductive and learns aggregator weights rather than fixed vectors per node, allowing new users or merchants to be embedded on the fly. A crucial detail is the aggregation method: instead of just averaging, the system concatenates three order-invariant statistics: mean, maximum, and standard deviation of neighbor features.
   • This multi-statistic aggregation is vital because a simple mean could dilute the signal of a single dangerous neighbor (e.g., linked to a fraud ring) among many genuine ones. The max preserves the strong signal of an outlier, while standard deviation captures the variability within a neighborhood, indicating the presence of an outlier even if the mean is normal. This effectively addresses fraud patterns where a single anomalous connection is key.
   • Hyperparameter tuning found 128 dimensions to be the sweet spot for embeddings, balancing performance and computational cost.

4. Explainability for Analyst Review and Trust:
   • Explainability is not optional in regulated financial environments. The system provides subgraph attribution, connecting suspicious scores to specific transaction edges. For example, an explanation might be: “the model says 0.91 because of these three linked transactions in the last 40 minutes.”
   • This is critical for regulatory compliance, building analyst trust, speeding up investigations, debugging models (by identifying spurious signals), and improving feedback loops for future training data. Analysis showed transaction-to-transaction velocity edges were highly important (0.94 mean importance in card-related fraud), while merchant edges played a larger role in online transactions (0.19 importance).

Performance and Real-time Serving

The combined GNN + XGBoost system demonstrated significant improvements over the tabular XGBoost baseline at matched alert rates:

• Card-related merchant transactions: 36% True Positive Rate (TPR) for XGBoost alone vs. 48% for GNN+XGBoost, a 33% relative lift. Projected $5.6 million captured.
• Online transactions: 48% TPR for XGBoost alone vs. 61% for GNN+XGBoost, a 27% relative lift. Projected $35.4 million captured.
• Overall, this translated to an approximately $65 million projected annualized incremental fraud capture across both portfolios.

Serving these solutions in real-time with a 3-millisecond P99 latency was another significant engineering challenge:

• An offline, memory-bound, GPU-sharded layer-wise GraphSAGE forward pass pre-computes representations for users, merchants, and recent transactions, which are then cached in a low-latency embedding store.
• At request time, a lightweight assembly reconstructs neighbor states from this cache, and only the new transaction’s two-layer forward pass and the XGBoost head run in real-time. Crucially, “nothing that scales with graph size runs per request.”
• Initial implementations involved caching representations for every transaction, leading to a 60GB footprint and high costs. The system pivoted to predicting on the edge, not the node, by pre-computing embeddings for users and merchants only. This reduced the cache footprint to 2-3GB (20x smaller), enabling it to run efficiently on the same CPU class as the XGBoost model without performance degradation.
• Optimizations like pinning math library thread pools and model warm-up contributed to the 3.1ms P99 latency (2.3ms median), comfortably within the 3-4ms SLA. The GNN forward pass is the largest component at 1.61ms.
• Further improvements were achieved post-launch by incorporating rolling windows and an edge-weighted temporal decay approach for training.

• Tags:
• Graph Neural Networks
• Feature
• Explainable AI
• Feature Engineering
• Financial Services
• Fraud Detection
• Low Latency
• GNN
• GraphSAGE
• Machine Learning Engineering
• XGBoost
• Real-Time Inference
• Data Sampling
• Leakage Control