Graph neural network fraud detection lifts TPR 33%

Graph neural network fraud detection lifts true positive rate by 27 percent to 33 percent at a matched alert rate by feeding GraphSAGE embeddings into the existing XGBoost classifier instead of replacing it. The same setup cuts the cache footprint from roughly 60 GB to 2 to 3 GB and serves in 2.3 ms median and 3.1 ms P99.

Graph neural network fraud detection: what EXL changed

Graph neural network fraud detection at EXL keeps the existing XGBoost classifier and feeds it GraphSAGE embeddings built from transaction, user and merchant edges, lifting true positive rate 33 percent at the same alert rate. Somya Rai, VP of AI engineering, and MD Sharique, principal AI architect, presented the system at AI Engineer NYC 2026.

GraphSAGE is an inductive graph neural network that learns aggregation weights rather than a fixed vector per node, so a new user or merchant can be embedded without retraining. XGBoost is the gradient-boosted decision-tree library that already handled the tabular scoring; the talk's authors state plainly that they did not replace it, they fed it.

How the two configurations compare

Configuration	Scoring model	Node embeddings	New node handling
XGBoost alone	XGBoost	none	tabular features only
XGBoost plus graph embeddings	XGBoost	GraphSAGE	inductive, no retraining

The comparison is XGBoost alone versus XGBoost plus the graph embeddings, measured on the same alert rate, the same evaluation window, and the same features available to both models. Rai frames the objective as precision at a fixed K rather than area under the curve, because analysts only review the top 0.5 percent to 1.5 percent of scored transactions.

Two portfolios, two models

The talk separates two portfolios that share the name fraud. Card-present transactions carry a natural fraud rate of roughly 0.05 percent, or one in 2,000, with the signal sitting mostly in the card's own transaction velocity. Online transactions run at 0.6 percent, twelve times higher, with more noise and more of the signal in merchant and neighbor context. EXL runs two models, not one.

Why tabular features hit a ceiling

Adding tabular features stopped paying off because every engineered column was still a function of the same row and the same card's own history, so the model kept reprojecting information it already had.

EXL expanded card-present data from 40 raw attributes to 87 engineered features. After selection and leakage checks, the true positive rate moved from 35.5 percent to 36.6 percent. The online portfolio followed the same pattern with nearly 200 engineered features and roughly one point of gain.

Rai calls that a ceiling, not a tuning failure. Deriving a new column from the same row cannot answer who a transaction is connected to or what those connections are doing in the current hour. Device sharing, velocity chains across cards, and a merchant that went bad forty minutes ago all live in the edges between rows.

A model that sees one row at a time is blind to that structure by construction, no matter how many columns are appended to it. The talk's one-line framing: fraud is a property of the neighborhood a transaction sits in, not a property of the transaction itself.

GNN plus XGBoost: the reported results

At a fixed 0.5 percent alert rate, EXL reports card-present true positive rate rising from 36 percent with the best XGBoost model to 48 percent with GNN plus XGBoost, a 33 percent relative lift, and online true positive rate rising from 48 percent to 61 percent, a 27 percent relative lift.

For card-present transactions the reported capture is $5.66 million at an 83 percent capture rate. For online transactions it is $35.4 million at 71 percent. EXL describes the combined figure as approximately $65 million in projected annualized incremental fraud capture. The word projected matters: this is a forecast, not realized savings, and it belongs to EXL rather than to any independent evaluation.

The mechanism behind the jump is the aggregation choice. GraphSAGE in this build concatenates three order-invariant statistics over each node's sampled neighbors: mean, maximum, and standard deviation. Sharique gives the example directly: three neighbors scoring around 0.1 and one tied to a fraud ring scoring 0.92 average to 0.32, letting the ring-linked neighbor dissolve into the crowd. Maximum passes it through at 0.92. Standard deviation adds a third view of how much the neighborhood disagrees with itself.

That choice costs nothing extra at serving time because it adds no learned parameters and keeps a fixed-size output regardless of neighbor count. A 128-dimension embedding won over 64 and 256 in EXL's sweep: 64 was slightly underfit, and validation performance flattened past 128 before starting to overfit.

Sampling without destroying graph neighborhoods

EXL holds a soft target fraud rate of roughly 0.5 percent for card-present and 6 percent for online transactions, about ten times the natural rate in each case, instead of the aggressive oversampling or undersampling a tabular pipeline would use.

The reason is structural. Every selected user's complete transaction history stays in the graph. Trimming a genuine user's history to hit a class ratio severs the connectivity their neighbors depend on, and a fraud user's own genuine transactions stay in as hard negatives, which are the most useful examples for the decision boundary.

If capping ever triggers, only genuine users lose budget; fraud users are never capped. Class imbalance is handled downstream with balanced batch sampling inside the trainer. The talk offers a receipt: average user degree at training time runs 11.5 to almost 14 for card-present transactions, matching what the model sees at inference. Neighborhoods that differ between training and serving teach the model the wrong thing, and EXL reports the match is stable across all 12 months tested.

A production implementation adding this constraint is a real delta from the idealized GraphSAGE paper. The paper assumes sampled neighbor sets during training and full neighborhoods or fixed sampling at inference; EXL's whole sampling design exists to make training-time and inference-time neighborhoods agree.

Leakage control built into the graph

Leakage control is structural: each calendar month is a disjoint graph, and every feature is timestamp-constrained, so future, split, label, and distribution leakage are prevented by construction rather than caught in an audit.

Each calendar month is its own disjoint graph with no edge crossing the boundary, so train, validation, and test splits cannot leak into each other through a graph path.

The central node is the transaction, with typed edges out to its user and its merchant, plus a five-hop chain back to its own recent history. The construction yields four properties.

Leakage type	Why it cannot occur	Enforcement
Future	A transaction only aggregates neighbors with an earlier timestamp	Edge timestamps
Split	The months never connect	Disjoint monthly graphs
Label	The fraud flag is the target and never a feature or an edge	Target isolation
Distribution	Every scalar and vocabulary is fit on the training month only, then frozen	Fit-and-freeze on training month

EXL describes all four as verified by construction rather than by a post-hoc audit. The dataset carries 202 model features across three node types: 73 on the user, 109 on the transaction, and 20 on the merchant. Thirty-two transaction features are derived specifically for fraud and were added in three waves. The three waves are:

1. 10 entity-history features such as past transaction count, days since last activity, and the mean, standard deviation and maximum of the last five amounts.
2. Eight risk aggregates such as an amount z-score against that history and a recent versus past ratio.
3. 14 rolling-window velocity and temporal features covering 5-minute, 1-hour and 24-hour counts and amounts, distinct counterparties in the last day, seconds since the last transaction, and a country-change rate for impossible-travel patterns.

Edge-level attribution for analyst review

EXL ran subgraph attribution across 200 flagged cases in each channel, connecting a suspicious score to specific transaction edges so an analyst sees why the model returned 0.91 rather than only that it did.

Transaction-to-transaction velocity edges carry a mean importance of 0.94 in card-present cases and 0.62 online, and they are the top piece of evidence in all 200 card-present cases. Merchant edges matter more online, at 0.19 versus 0.04 in card-present, which matches the structural difference: card-present fraud rides the card's own velocity rather than the acceptance point.

The talk gives four reasons explanation is load-bearing in fraud specifically. Financial institutions operate under model risk management frameworks that require documented rationale for automated decisions. Analyst trust depends on it, because an unexplained high score gets rubber-stamped or ignored. Attribution patterns surface a model leaning on a spurious or decaying signal before production performance visibly drops. And explanations that match what an analyst already suspects make them more willing to label borderline calls correctly, which improves the next round of training data.

The practical framing from the talk: an accurate black box does not get used.

Serving graph embeddings at 3 ms P99

EXL serves each scoring request with only the new transaction's own two-layer forward pass plus the XGBoost head, reading cached neighbor states so nothing that scales with graph size runs on the request path.

The offline side is a memory-bound GPU sharded layer-wise GraphSAGE forward pass over the entire graph, batched by destination node so it is numerically identical to a full-graph forward, bounded to a few gigabytes at a time across multiple GPUs. Every user, merchant and recent transaction gets its per-layer representation cast into a low-latency embedding store, and each user's last five transactions sit in a ring buffer online. A lightweight assembly step reconstructs neighbor states from that cache with exponential recency decay that reproduces training exactly.

Three implementation tricks do the latency work. Math-library thread pools are pinned to one before the heavy libraries load, which the talk attributes to the difference between 30 milliseconds and one. The model is warmed at startup so the first real request is not slow. Today it runs as a single in-memory process, and the same interface maps into a distributed cache when scale-out is needed.

The measured request path: preprocessing, cache lookup and the XGBoost head each take fractions of a millisecond, the GNN's own two-layer forward is the largest single piece at 1.61 ms, and end-to-end latency lands at 2.3 ms median and 3.1 ms P99 inside a 3 to 4 ms SLA.

Node versus edge prediction: the 60 GB to 3 GB tradeoff

Caching a representation for every node, including every transaction, required roughly 60 GB of embedding storage at production scale and introduced a one-day embedding lag, and the real-time true positive rate dropped from 48 percent to 44 percent in that configuration.

The fix was to predict on the edge instead of the node, precomputing embeddings for users and merchants only and never per transaction. That collapses the footprint to 2 to 3 GB, about 20 times smaller, cheap enough to run on the same CPU class as the XGBoost model beside it.

Sharique says Nvidia independently recommended the same edge-level approach and expects it to perform on par with the node model. That is a vendor recommendation rather than an independent benchmark of EXL's pipeline, and the performance comparison is an expectation rather than a reproduced measurement.

The comparison table below separates what was measured from what was projected or recommended.

Current status of the open-source tooling

As of October 2026, EXL has not published this fraud detection system as an open-source repository, and the talk itself is the primary public record of the architecture.

The building blocks it depends on are open source and actively maintained. GraphSAGE is the inductive graph embedding method from the 2017 NeurIPS paper by William Hamilton, Rex Ying and Jure Leskovec, with the reference implementation published by the authors. XGBoost is the gradient-boosted decision-tree library maintained under the Distributed Machine Learning Community. PyTorch Geometric and DGL are the graph deep learning libraries commonly used to build neighbor sampling and aggregation at this scale.

The distinction matters for anyone planning a build. The research algorithm comes from the paper. The aggregator configuration, the three-statistic pooling, the sampling discipline and the edge-serving split are EXL's production choices, and their reported 27 percent to 33 percent lift belongs to that implementation rather than to GraphSAGE in general.

A useful comparison of the two prediction targets:

Graph neural network fraud detection FAQ

• What is graph neural network fraud detection? It is a fraud detection design in which a graph neural network like GraphSAGE produces embeddings from transaction, user and merchant edges, and a tabular classifier such as XGBoost scores those embeddings. The graph supplies relationship context that row-level features cannot express.

• Did EXL replace XGBoost with a GNN? No. Somya Rai states directly that they did not replace XGBoost, they fed it. GraphSAGE produces embeddings and the same gradient-boosted model performs the final scoring, and the reported comparison is XGBoost alone versus XGBoost plus the graph embeddings.

• How much did graph embeddings improve fraud detection? EXL reports a 33 percent relative lift in true positive rate for card-present transactions, from 36 percent to 48 percent at a fixed 0.5 percent alert rate, and a 27 percent relative lift online, from 48 percent to 61 percent. Both are measured at a matched alert rate against the tabular baseline.

• Why is alert rate used instead of AUC? Fraud analysts review only the top 0.5 percent to 1.5 percent of scored transactions, so a model that raises overall ranking quality without moving real fraud into that slice does not help. Precision at a fixed K is the metric that matches the operational constraint.

• Why concatenate mean, max and standard deviation in aggregation? Mean pooling dilutes a single dangerous neighbor among many normal ones. In the talk's example, three neighbors scoring around 0.1 and one fraud-ring neighbor at 0.92 average to 0.32, while max passes 0.92 through unchanged. Standard deviation captures how much the neighborhood disagrees with itself.

• How is leakage prevented in the graph construction? Each calendar month is its own disjoint graph so no edge crosses a split boundary, transactions only aggregate neighbors with earlier timestamps, the fraud flag never appears as a feature or edge, and every scalar and vocabulary is fit on the training month only and then frozen.

• Why does training use a soft fraud rate instead of oversampling? Dropping rows in a graph removes their edges too. EXL keeps each selected user's complete history so neighborhood structure survives, and handles class imbalance downstream with balanced batch sampling inside the trainer.

• How is serving latency kept under 3 milliseconds? Only the new transaction's two-layer forward pass and the XGBoost head run per request, reading cached neighbor states. Math-library thread pools are pinned to one before the heavy libraries load, and measured end-to-end latency is 2.3 ms median and 3.1 ms P99.

• Can edge prediction run without high-memory GPU serving? Yes. Precomputing embeddings for users and merchants only, and never per transaction, reduces the cache from roughly 60 GB to 2 to 3 GB, which the talk describes as cheap enough to run on the same CPU class as the XGBoost model.

• Is the reported improvement independently verified? No. The 27 percent to 33 percent lift, the $65 million projected annualized incremental fraud capture, and the latency figures all come from EXL's own presentation. They are vendor-reported results for one production deployment, not a reproduced external benchmark.

Source video