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

Hi, I'm Somya Rai, VP of AI Engineering. What we see here are two score, same transaction both the times. On the left, a single online purchase where we look at the amount spent, who is the merchant, MCC code, device type, what time of the day, and with one ninety-eight features by the time we are done engineering. And it scores zero point zero four, comfortably under any threshold we would alert on. As far as we are concerned, this one looks clean. On the right,

same transaction, same feature vector. Not one byte of that row is different. The only thing that we change is what model is allowed to look at, the neighborhood it sits in. Three of the four transactions, a user, a merchant, and two other transactions were flagged fraud within the last hour. Now the score is zero point nine one. So the signal was never in the row, it was in the edges. Therefore, fraud isn't a property of a transaction, it is a property of the neighborhood it sits in.

Let me describe the shape of the problem, because it is two problems wearing one name. Physical transaction at the merchant point of sale roughly has zero point zero five percent natural fraud rate. That is one in two thousand. These are tight, low noise signal and fraud largely resides in the card's own transaction velocity. Whereas online transactions have zero point six percent of the fraud rate, twelve times higher, with higher volume, noisier, and far more of it of the signal sits in the merchant and the neighbor context.

These two portfolios have a different base rate and a different signal geometry. Therefore, in practice, two models, not one. And here is the constraint that makes this as an engineering problem, not... and not just a modeling one. The alert budget is fixed. Analysts review the top zero point five to one point five percent of the score transaction. That's it. So the area under the curve isn't just the objective we care about, rather the precision at the fixed K. To be worth anything, a model has to move a

real fraud into that slice and do it at the same latency. So the obvious question here is: Why not just build a better XGBoost model? We did. Physical point of sale, we went from the forty raw attributes to eighty-seven engineered features. After selection and the leakage checks, the true positive rates moves from thirty-five point five to thirty-six point six. And for the online transaction, same story. Nearly two hundred engineered features, and we c-- we pick up about a point. So

you know, two to five times the feature surface, one point of TPR. Now, that's not a tuning failure, right? That's ceiling. Because every feature we engineered is just a function of the same row and the same card's own history. We are projecting the information we already had. Tabular features answers one question, "What does this transaction look like?" They cannot answer the second one, "Who is it connected to, and what are they doing right now?" Rates sharing a device, velocity chains across card, a merchant

went... that went bad forty minutes ago. This lives in edges between the rows, and a model that sees one row at a time is blind to it by design, no matter how many columns we add to it. Okay. So here's the mental model for the rest of the talk. A graph neural network does not learn a node from its own feature. It learns from its, its neighborhood. One layer, three operations. First, gather. We pull in each neighbor's hidden states across the tight

edges, such as transaction to user, transaction to merchant. Aggregate. We collapse that neighbor set, which is, you know, a different size for every node, one into a fixed-width vector, and we do it with a permutation invariant function. Which function we pick mattered way more than we expected, and Sharique is going to come back to that. Third, update. We concatenate that aggregate with the node's own state, push it through learned weights, and then we stack it twice. So every transaction knows about its neighbors

and its neighbor's neighbor before the classifiers ever sees it. So does these results hold up? Yes, it does. And I want to be precise about what's being compared. We did not replace XGBoost. We fed it. The GNN produces the embeddings. These embeddings goes into the same gradient boosted model, and that's what gets scored. So XGBoost alone versus XGBoost plus the graph is what we are comparing at. So the three numbers that we would like to highlight, first is twenty-seven to thirty percent--

thirty-three percent relative lift in the true positive rate over a tuned XGBoost baseline using the same alert rate, same evaluation window, and same features available to both the models. Second, approximately sixty-five million dollars projected annualized incremental fraud capture across the two card portfolios. And third, the three millisecond P99 in production. So this talk is just not about the numbers. It's about how we got here. Four decisions and order

matters. First, in the foremost, sampling. Fraud is one in two thousand, so we cannot train a raw distribution. We have to lift the fraud rate, but this is not a tabular data set where the rows are independent. Every negative we drop takes its edges with it. Downsample the easy way, we keep the labels, but lose the neighborhood that makes them worth anything. So holding a soft target fraud rate without really breaking the connectivity was the key. Second, graphing features.

Building it leakage safe, which is harder than it sounds when your edges carry timestamps plus thirty-two derived features created to detect fraud. The third, explainability. An analyst won't action a number. This is a regulated work where the score has to come with an evidence, so or it does not ship. And serving at three milliseconds, two thing got us here, the aggregation method and the pivot from the node level prediction to edge level. Then at the end, one iteration that we validated

after launch was creating and training the, training the model at a rolling window plus an edge time decay approach, and this moved the numbers again. With this, I would like to hand it over to Sharique to get into the nuts and bolts of how did we create the graphs, how did we optimize the same, and what were the engineering decisions that we have taken in order to make this model more optimized.

Hi, I am Mohammed Sharique, Principal AI Architect. This is judge a transaction by the company it keeps. How a graph neural network beat XGBoost by over thirty percent on fraud capture, and how we serve it in three milliseconds. I will walk through the technical build, sampling, graph construction, serving, and explainability. So let's get into it. First decision most teams get wrong is the data sampling. We hold a soft target

fraud rate of point five percent for card-related merchant transactions, about ten times the zero point zero five percent natural fraud rate, and six percent for online transactions, again, about ten times the zero point six percent natural fraud rate. Both far gentle than the aggressive over or under-sampling a tabular pipeline would use. Why? Because every selected user's complete transactional history

stays in the graph. If you trim a genuine user's history to hit a class ratio, you break the connectivity their neighbors depend on, and a fraud user's own genuine transactions stay in too as hard negatives, the most useful example for the decision boundary. If capping ever triggers, only the genuine user's word budget shrinks. Fraud users are never capped. Class imbalance gets handled downstream instead with balanced batch sampling inside the trainer.

Here's the receipt. Average user degree at training time, eleven and a half to almost fourteen for card-related merchant transactions. Matches what the model sees at inference. If training time neighborhood don't match inference time neighborhood, the model learns the wrong thing. It's stable across all twelve months we tested at natural rate of zero point zero five percent and zero point six percent. No vintage drift to correct for.

Second decision, leakage control built into the graph itself, not checked for afterward. Each calendar month is its own disjoint graph. No edge overcrosses the boundary. The transaction is the central node with type stages out to its user and its merchant, plus a five-hop follows chain back to its own recent history. Because months never connect, there's no path for information to leak from one split

into another.

Four properties fall out of that construction. No future leakage. A transaction only ever aggregates neighbors with an earlier timestamp. No train val test leakage because of the disjoined month. No label leakage. The fraud flag is the target, never a feature or an edge. And no distribution leakage. Every scalar and vocabulary is fit on training month only, then frozen. Four for four, verified by construction,

not by post-hoc audit.

One more decision before the architecture. Two hundred two model features across three node types. Seventy-three on the user, a hundred and nine on the transaction, twenty on the merchant. Thirty-two of the transactional features are derived, purpose-built for fraud, added in three waves. Ten entity history features, past transaction count, days since last activity, the mean standard

deviation, and max of the last five amounts. A behavioral baseline per user and merchant. Eight risk aggregates, an amount Z-score against that history, a recent versus past ratio, transactions per day. These flag deviation from the entity's own baseline, not some global threshold. And fourteen true rolling window velocity and temporal features. Five-minute,

one-hour, and twenty-four-hour, uh, transactional counts and amounts, distinct counterparties in the last day, seconds since the last transaction, even a country change rate for impossible travel patterns. Why this matters? The graph tells the model who a transaction is connected to. These derived features tell it how that entity is behaving differently from its own normal. Complementary signals, not redundant

ones.

Under the hood, this is GraphSAGE architecture. Sample, aggregate, combine, embed. Sampling, a fixed recency bias set of neighbors per hop, so one enormous merchant node can't dominate every message. Aggregate, and here's a detail worth pausing on. We don't just average. We concatenate three order invariant statistics: mean, max, and standard

deviation. Combine that with the node's own vector through learned weights, embed a fixed-length vector to hops. It's inductive. We learn that the aggregator weights not a fixed vector per node, so a brand-new user or merchant gets embedded on the fly, no retraining. Why three statistics instead of one? Let me show you

Picture four neighbors of a transaction. Three look completely normal, scores around zero point one. The fourth is tied to a fraud ring, zero point nine two. Average those four together and you get zero point three two. That ring-linked neighbor just got diluted in, into the crowd. Take the max instead, and it comes through untouched, zero point nine two. That's why we don't

rely on mean alone. A single dangerous neighbor among many genuine ones is exactly the pattern fraud rings create, and mean pooling is precisely the operation that would hide it. The standard deviation adds a third view. How much the neighbor disagree with itself. A uniform boring neighborhood looks nothing like one with a live outlier in it, and this cost us nothing extra at

serving time. No additional learned parameters, still a fixed size output no matter how many neighbors a node has.

One quick hyperparameter note. One twenty-eight dimension is the sweet spot. Sixty-four dimension is close, but slightly underfit. Two fifty-six cost more GPU and gives you nothing back. Validation performance flattens past one twenty-eight and then starts to overfit. It's not a philosophical debate, just a sweet.

Now, the actual numbers side by side. For card-related merchant transactions, best XGBoost gets thirty-six percent true positive rate at a fixed zero point five percent alert rate. GNN plus XGBoost gets forty-eight percent. For thirty-three percent relative lift, five point six million dollars captured at an eighty-three percent capture rate. For online transactions,

forty-eight percent up to sixty-one percent. Twenty-seven percent relative lift, thirty-five point four million dollar captured at seventy-one percent. Online transaction is where most of that sixty-five million dollar savings lives, since it runs at twelve times the fraud rate of card-related merchant transactions.

Third decision, explainability. We ran subgraph attribution across two hundred flagged cases in each channel. Transaction-to-transaction velocity edges carry zero point nine four mean importance in card-related transactions, zero point six two in online transactions, and they are the top piece of evidence in all two hundred card present cases. Merchant edges matter

more in online transactions, zero point one nine versus zero point zero four in card present, where fraud writes the card's own velocity rather than the acceptance point. That's the difference between the model says point nine one, and the model says point nine one because of these three linked transaction in the last forty minutes.

Why does this matter so much, specifically in fraud? Four reasons. One, regulatory and model risk management. Financial institutions operate under frameworks that require documented rationale for automated decision. This isn't optional. Two, analyst trust and investigation speed. An unexplained high score gets rubber-stamped or ignored. Edge-level

evidence turns recompute the case from scratch into verified three linked transactions. Three, model debugging. Attribution patterns show us when the model leans on a spurious or decaying signal before performance visibly drops in production. And four, feedback loop quality. When explanation match what an analyst already suspects, they trust the borderline calls enough to label them

correctly, improving the next round of training data. An accurate black box simply doesn't get used.

Now, the real fight, serving these solution in three milliseconds. Offline, we run a memory-bound GPU-sharded layer-wise GraphSAGE forward pass over the entire graph batched by destination node. So it's numerically identical to a full graph forward, just bounded to a few gigabyte at a time across multiple GPUs. Every user, merchant, and recent transaction

gets its per-layer representation cached in a low-latency embedding store. Each user's last five transaction sit in a ring buffer. Online, at request time, a lightweight assembly step reconstructs the neighbor states straight from that cache. No graph build, no sampling, recency weighted by an exponential decay that reproduces training exactly. Then the real-time

scoring services runs only the new transaction's own two-layer forward from those cached states, plus the XGBoost head. Nothing that scales with graph size runs per request. Three small tricks make it fast in practice. We pin math library thread pools to one before the heavy libraries even load. That alone is the difference between thirty milliseconds and

one. We warm the model up at startup, so the first real request isn't slow. And today, it's a single in-memory process. The same interface maps directly into a distributed cache when we need to scale out.

Now, there's a catch. That trick requires caching a representation for every node, including every transaction. At production scale, that's sixty gigabyte, and it needs expensive high memory serving. With a one-day embedding lag in real-time, true positive rate actually drops from forty-eight to forty-four percent. The fix, predict on the edge, not the node. Precompute

embeddings for user and merchants only, never per transaction. That collapses the footprint to two to three gigabytes, about twenty times smaller, cheap enough to run on the same CPU class as the XGBoost model it sits beside. Nvidia independently recommended the same approach and expects it to perform on par with the n-node model. Here's the actual request path. Pre-processing, cache

lookup, and the XGBoost head are all fractions of a millisecond. The GNN's own true two-layer forward is the biggest single piece at one point six one millisecond. End-to-end, two point three millisecond at the median, three point one at P99, comfortably inside our three-to-four millisecond SLA. If we ever need more headroom, that GNN forward is the first thing

we would recompile or quantize.

Thank you for watching. We are both happy to go deeper, sampling, graph construction, explainability, or serving. Reach out anytime. Thank you.