Talk on graph-based fraud detection by Somya Rai and MD Sharique of EXL. They describe augmenting an existing XGBoost classifier with graph embeddings to surface suspicious transaction neighborhoods, targeting precision within a fixed analyst alert budget. Reported results are relative detection improvements of 27–33% over a tabular baseline at matched alert rates, with the financial figure framed as projected annualized incremental fraud capture rather than realized savings. Topics covered include sampling that preserves transaction neighborhoods, monthly graph construction with leakage controls (earlier timestamps, training-only preprocessing), GraphSAGE with mean/max/standard-deviation aggregation, edge attribution for analyst review, and serving via cached entity-level embeddings (reported reduction in cache footprint from roughly 60 GB to 2–3 GB), rolling windows, temporal decay, and reported millisecond latency. # Video Identity Observations ## Explicit Self-Description (creator statements) - **Speaker identities and seniority**: The presenters introduce themselves with corporate and role titles: > "Hi, I'm Sam Ray, VP of AI engineering" and "Hi I am Mohammed Sarik principal AI architect." A metadata-derived company attribution appears in the title: **"Somya Rai & MD Sharique, EXL"** — presenting as vendor/practitioner experts rather than educators or hobbyists. - **Invitation to engage further** (positions the channel as a professional/technical resource): > "We are both happy to go deeper sampling, graph construction, explanability or serving. Reach out anytime." ## Observable Presentation Evidence - **Deep technical scope**: The talk covers end-to-end production ML — sampling, graph construction, GNN architecture, explainability, and low-latency serving — with concrete numbers ("27 to 30% 33% related lift", "3 millisecond P99", "60 GBTE" cache footprint, "128 dimension is the sweet spot"). - **Practitioner framing**: Terms are used without introductory definition ("leakage checks", "balanced batch sampling", "P99", "edge level prediction", "inductive"), assuming audience familiarity. - **Production/industry orientation**: Emphasis on constraints that matter in deployed systems: > "The alert budget is fixed… a model has to move a real fraud into that slice and do it at the same latency." and regulated-industry requirements: > "This is a regulated work where the score has to come with an evidence so or it does not ship." ## Intended Audience (inferred from demonstrated level, not stated) - **ML engineers, data scientists, and fraud/risk practitioners** evaluating or building production fraud systems — evidenced by implementation-level detail (thread pool pinning, ring buffers, embedding stores, train/inference neighborhood parity) rather than conceptual tutorials. ## Claimed Scope - A **conference-style technical case study** (announced talk format: "this talk is just not about the numbers, it's about how we got here… with this I would like to hand it over"), scoped to one system: GNN-augmented XGBoost for payment fraud detection at EXL. ## Distinguishing Claims vs. Demonstration - **Creator claims**: performance metrics ($65M projected annualized fraud capture, 27–33% relative TPR lift, 3.1ms P99) are asserted results, independently unverifiable from the transcript. - **Demonstrated pattern**: the video itself demonstrates a practitioner/expert presentation style with engineering-decision-first narrative ("four decisions and order matters"). # Delivery Observations — "Judge a Transaction by the Company It Keeps" ## Speaker Roles & Voice Handoff - **Two distinct voices** with a clean division of labor: - **Somya Rai (VP of AI Engineering)** — problem framing, motivation, results - **MD Sharique (Principal AI Architect)** — technical build and serving details - Handoff is explicit and scripted-sounding: *"with this I would like to hand it over to Shahi to get into the nuts and bolts"* and Sharique opens by restating the title: *"Hi I am Mohammed Sarik principal AI architect. This is judge a transaction by the company it gives."* ## Recurring Phrases & Signature Lines - **"Therefore" as a pivot word** — used repeatedly to convert evidence into conclusions: > *"Therefore, fraud isn't a property of a transaction. It is a property of the neighborhood it sits in."* > *"Therefore in practice two models not one."* - **Numbered enumeration habit** — both speakers count things out constantly: - *"four decisions and order matters"* - *"One layer, three operations. First, gather... Third update"* - *"Four properties fall out of that construction"* - *"Four reasons. One, regulatory... Two, analyst trust... Three, model debugging... Four, feedback loop quality"* - **"Why?" as a rhetorical device** — pose the reader's question, then answer it: > *"Why three statistics instead of one? Let me show you."* > *"Why this matters? The graph tells the model who a transaction is connected to."* > *"Why does this matter so much specifically in fraud? Four reasons."* - **Contract-with-the-audience framing**: *"here's the metal model for the rest of the talk"*, *"here's the receipt"*, *"Here's the actual request path."* ## Teaching Habits - **Concrete worked micro-examples before abstractions** — the mean-pooling dilution lesson uses four specific scores: > *"Three look completely normal. Scores around 0.1. The fourth is tied to a fraud ring. 0.92. Average those four together and you get 0.32."* - **Anticipating and dismissing the obvious alternative** — *"So the obvious question here is why not just build a better HD boost model. We did."* Then shows the numbers (35.5 → 36.6) before pivoting. - **Precision caveats about comparisons** — repeated care to scope claims: > *"I want to be precise about what's being compared. We did not replace XG post. We fed it."* > *"same alert rate same evaluation window and same features available to both the models."* - **"By construction, not after the fact"** framing — *"Four for four verified by construction not by post hawk audit."* ## Vocabulary & Style - **Heavy quantification in prose** — nearly every claim carries a number: *"one in 2,000"*, *"12 times higher"*, *"2.3 millisecond at the median, 3.1 at P99"*, *"about 20 times smaller"*. - **Colloquial anchors between technical passages**: *"So does these results work up? Yes, it does."*, *"Now there's a catch."*, *"That's not a philosophical debate, just a sweep."* - **Definitional aphorisms** — punchy claim statements: *"fraud isn't a property of a transaction. It is a property of the neighborhood it sits in."*; *"it's two problems wearing one name."* ## Stable Patterns vs. Isolated Moments - **Stable (multiple instances each):** numbered decision lists, "why?" rhetorical questions, numeric grounding of claims, comparison scoping, "therefore" conclusions. - **Thin evidence (uncertain):** humor or asides are rare — only isolated moments like *"and charik is going to come back to that"* and *"That alone is the difference between 30 milliseconds and one"* carry a lighter register; can't confirm this as a pattern from one pass. - **Note:** transcript contains recognition errors (*"HD boost"* / *"Exib Boost"* for XGBoost, *"metal model"* for mental model), so exact wording of technical terms should be verified against audio. ## Overall Communication Pattern Summary The delivery follows a consistent loop: **claim → concrete example → numbers → "therefore" conclusion → numbered roadmap**. Both speakers favor evidence-first persuasion and repeatedly tell the audience *what will be covered before covering it*, giving the talk a deliberately structured, engineering-briefing cadence. # Observation Record — "Judge a Transaction by the Company It Keeps" **Video:** `01a15ca6-726e-78c6-a6e3-da8819c9e543` **Speakers (as introduced in transcript):** "Sam Ray" / "Somya Rai" per title, VP of AI Engineering (opening speaker); "Mohammed Sarik" / "MD Sharique" per title, principal AI architect (second speaker). *Note: transcript spellings of the names vary; titles are attributed here, not private beliefs.* --- ## Part 1 — Motivation and Problem Framing (Speaker 1) ### Opening demonstration - Two identical transactions ("not one bite of that row is different") are shown with the same feature vector: - **Left (row-only model):** single online purchase, ~198 engineered features, score **0.04** — "comfortably under any threshold we would alert on." - **Right (neighborhood-aware model):** same row, but three of four transactions in its neighborhood (user, merchant) were flat fraud within the last hour → score **0.91**. - Stated conclusion: **"The signal was never in the row, it was in the edges"** and **"fraud isn't a property of a transaction. It is a property of the neighborhood it sits in."** ### Two problems "wearing one name" | Portfolio | Natural fraud rate | Character | |---|---|---| | Physical (point of sale) | ~0.05% (1 in 2,000) | Tight, low-noise; signal in card's own transaction velocity | | Online | ~0.6% (~12× higher) | Higher volume, noisier; signal in merchant/neighbor context | - Claim: different base rate and "signal geometry" → **in practice, two models, not one.** ### Alert budget constraint - Analysts review only the **top 0.5–1.5%** of scored transactions (fixed budget). - Therefore, objective is framed as **precision at a fixed K** (and true positive rate at fixed alert rate), not just AUC — and latency must hold. ### Why not just a better XGBoost? - Physical POS: 40 raw attributes → 87 engineered features; TPR moved **35.5% → 36.6%**. - Online: ~200 engineered features; "about a point" gained. - Speaker's interpretation: "not a tuning failure… that's ceiling" — every feature is a function of the same row and the card's own history; tabular features answer *"what does this transaction look like?"* but not *"who is it connected to and what are they doing right now?"* ### GNN primer (as presented) - One layer = three operations: **gather** (neighbor hidden states over typed edges: transaction–user, transaction–merchant), **aggregate** (permutation-invariant function into fixed-width vector — speaker noted the choice "mattered way more than we expected"), **update** (combine with node's own state via learned weights), stacked twice. ### Headline results - "We did not replace XGBoost. We fed it" — GNN embeddings score into the same gradient-boosted model. - **27–33% relative lift in true positive rate** over a two-leg XGBoost baseline (same alert rate, window, features). - **~$65M projected annualized incremental fraud capture** across both card portfolios. - **3 ms P99** serving latency. ### Four decisions (order emphasized as mattering) 1. **Sampling** — fraud at 1-in-2,000 means raw distribution can't be trained on, but naive downsampling "keeps the labels but loses the neighborhood"; goal was holding a soft target fraud rate without breaking connectivity. 2. **Graph features / leakage control** — "harder than it sounds when your edges carry timestamps." 3. **Explainability** — "analysts won't action a number… the score has to come with evidence or it does not ship." 4. **Serving at 3 ms.** - Post-launch iteration: rolling-window training plus an edge-headed DNN approach "moved the numbers again." *(No specific figures given for this final iteration in the transcript.)* --- ## Part 2 — Technical Build (Speaker 2) ### Decision 1: Sampling - Soft target fraud rate of **0.5%** (card-present, ~10× natural) and **6%** (online, ~10× natural) — deliberately gentler than tabular pipelines. - Reasoning: every selected user's full transactional history stays in the graph; trimming a genuine user's history "breaks the connectivity their neighbors depend on." Fraud users' own genuine transactions are kept as **hard negatives**; when capping triggers, only genuine users' budgets shrink — fraud users are never capped. - Class imbalance handled downstream via balanced batch sampling in the trainer. - Receipt offered: average user degree at training ~11.5 → ~14 for card-present, matching inference-time neighborhoods; stable across all 12 months tested. ### Decision 2: Leakage control by construction - Each calendar month is a **disjoint graph**; no edge crosses boundaries. Transaction is the central node with edges to its user and merchant, plus a **five-hop follow chain** back into its own recent history. - Four properties claimed, "verified by construction, not by post-hoc audit": no future leakage (only earlier-timestamp neighbors aggregated), no train/val/test leakage (disjoint months), no label leakage (fraud flag never a feature/edge), no distribution leakage (scalers/vocabularies fit on training months only, then frozen). ### Feature inventory - **202 model features across three node types:** 73 user, 109 transaction, 20 merchant; **32 transaction features derived** for fraud, added in three waves: 1. **10 entity-history features** (past transaction counts, days since last activity, mean/std/max of last five amounts — per-user/per-merchant behavioral baselines). 2. **8 risk aggregates** (amount z-score vs. history, recent-vs-past ratio, transactions/day — flagging deviation from the entity's own baseline, "not some global threshold"). 3. **14 rolling-window velocity/temporal features** (5-min/1-hr/24-hr counts and amounts, distinct counterparties in last day, seconds since last transaction, country-change rate for "impossible travel"). - Framed as complementary to the graph: "graph says who a transaction is connected to; these tell it how the entity is behaving differently from its own normal." ### Architecture (GraphSAGE-style) - **Sample:** fixed recency-biased neighbor set per hop "so one enormous merchant node can't dominate every message." - **Aggregate:** not a plain average — **concatenation of mean, max, and standard deviation** (three order-invariant statistics). - **Inductive:** aggregator weights are learned, not a fixed vector per node, so brand-new users/merchants embed on the fly with no retraining. ### Why mean alone fails (worked example) - Four neighbors: three normal (~0.1), one tied to a fraud ring (0.92). Mean → 0.32 ("diluted into the crowd"); max → 0.92 untouched. Claim: "a single dangerous neighbor among many genuine ones is exactly the pattern fraud rings create." Standard deviation adds a third view — neighborhood disagreement. - Cost at serving: none — no extra learned parameters, fixed-size output regardless of neighbor count. ### Hyperparameter note - **128 dimensions** is "the sweet spot"; 64 slightly underfits; 256 costs more GPU "and gives you nothing back" — validation flattens past 128 then overfits. Presented as a sweep result, "not a philosophical debate." ### Results (side by side) | Portfolio | XGBoost alone (TPR @ 0.5% alert rate) | GNN + XGBoost | Relative lift | Captured | Capture rate | |---|---|---|---|---|---| | Card-present | 36% | 48% | **33%** | $5.66M | 83% | | Online | 48% | 61% | **27%** | $35.4M | 71% | - Claim: most of the $65M savings lives in online due to the 12× fraud rate. ### Decision 3: Explainability - **Subgraph attribution** across 200 flagged cases per channel: - Transaction-to-transaction velocity edges: **0.94 mean importance** (card-present), **0.62** (online); top evidence in all 200 card-present cases. - Merchant edges matter more online: **0.19 vs 0.04** (card-present) — consistent with online fraud riding merchant acceptance points while card-present fraud rides card velocity. - Stated contrast: "the model says 91" vs. "the model says 91 **because of these three linked transactions in the last 40 minutes**." - Four stated reasons it matters: (1) regulatory/model-risk documentation requirements for automated decisions; (2) analyst trust and investigation speed (unexplained scores get rubber-stamped or ignored); (3) model debugging — attribution reveals reliance on spurious/decaying signals before production performance visibly drops; (4) feedback-loop quality — explanations matching analyst suspicions improve borderline labeling for the next training round. - Bold closing claim: **"An accurate black box simply doesn't get used."** ### Decision 4: Serving in 3 ms - **Offline:** memory-bound, GPU, shard/layer-wise forward over the full graph, batched by destination node (claimed numerically identical to full-graph forward); per-layer representations for every user, merchant, and recent transaction cached in a low-latency embedding store; each user's last five transactions held in a ring buffer. - **Online:** lightweight assembly reconstructs neighbor states from cache (no graph build, no sampling; recency weighted by exponential decay "that reproduces training exactly"); only the new transaction's own two-layer forward plus the XGBoost head runs per request — "nothing that scales with graph size runs per request." - Three speed tricks: pinning math-library thread pools to one before libraries load ("the difference between 30 milliseconds and one"), model warm-up at startup, single in-memory process with a path to distributed cache. ### The catch and the fix - Caching per-transaction embeddings at production scale = **60 GB**, expensive high-memory serving, and with a one-day embedding lag the real-time TPR **drops 48% → 44%**. - **Fix: predict on the edge, not the node** — precompute embeddings for users and merchants only, never per transaction → footprint collapses to **2–3 GB (~20× smaller)**, runnable on the same CPU class as the XGBoost model. - Attributed support: "Nvidia independently recommended the same approach and expects it to perform on par with the node model." *(Reported as a claim; no independent validation figures provided in the transcript.)* ### Latency breakdown - Pre-processing, cache lookup, XGBoost head: fractions of a millisecond. - GNN two-layer forward: largest single piece at **1.61 ms**. - End-to-end: **2.3 ms median / 3.1 ms P99**, "comfortably inside our 3–4 millisecond SLA." Reoptimizing/compiling the GNN forward named as the first headroom lever. --- ## Open items and qualifications preserved - The **edge-level prediction model** is described as validated "after launch" but no before/after figures are given for that iteration in the transcript. - The Nvidia endorsement of the edge-level approach is relayed by the speaker, not demonstrated with data here. - The transcript contains garbled passages (e.g., "two positive rates," "DPR," "edge himed DK") where exact metric names could not be reliably recovered; those are reproduced above only where context makes the meaning clear. - Name spellings differ between the title metadata ("Somya Rai & MD Sharique") and the transcript's self-introductions ("Sam Ray," "Mohammed Sarik"); both are recorded as-is. # Attribution & Provenance Record **Video:** *Judge a Transaction by the Company It Keeps — Somya Rai & MD Sharique, EXL* ## Speakers & Roles | Speaker | Stated Role | Segment | |---|---|---| | "Sam Ray" (per title: **Somya Rai**) | **VP of AI Engineering** | Opens the talk; problem framing, modeling overview, results summary | | "Mohammed Sarik" (per title: **MD Sharique**) | **Principal AI Architect** | Second half; technical build — sampling, graph construction, serving, explainability | - Handoff is explicit in the transcript: the first speaker says he will hand over to "Shahi" to cover the graph engineering details. - Both speakers conclude jointly ("We are both happy to go deeper…"). No other speakers, guests, or narrator are identified. ## Speaker Affiliation - Title metadata attributes both speakers to **EXL**. The transcript itself does not state the company affiliation; this is metadata-derived, not transcript-confirmed. ## Third-Party Claims & Referenced Sources - **NVIDIA:** cited as having "independently recommended the same approach" (edge-level prediction rather than node-level) and expecting parity with the node model. This is the speakers' claim; no source document is linked in the transcript. - Internal/regulatory context: reference to financial-industry frameworks requiring "documented rationale for automated decision" (generic, unnamed regulation). - All performance figures (e.g., **33% relative lift** card-present, **27%** online, **~$65M** projected annualized incremental capture, **3 ms P99**) are speaker-reported and not independently verifiable from the transcript. ## Promotional Segments - **Closing outreach:** "Reach out anytime" — an open invitation for follow-up, functioning as light self-promotion. Flagged per rules. - The talk is effectively a technical showcase of EXL's fraud-detection work; no product pitch or third-party promotion appears. ## Comment Availability - Not stated in transcript or metadata. **Unknown** — later authors should treat comment channel availability as unconfirmed. ## Uncertainty Notes - Transcript spellings of speaker names ("Sam Ray," "Mohammed Sarik," "Shahi") conflict with title metadata (Somya Rai, MD Sharique); title treated as authoritative identity, transcript as phonetic artifact. - Transcript contains transcription artifacts (e.g., "XG post," "Exib Boost," "exeost" for **XGBoost**; "genet"/"graph says" likely for **GNN / GraphSAGE**); normalized here for readability only. Hi, I'm Sam Ray, 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 or time of the day and with 198 features by the time we are done engineering and it scores 0.04. 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 bite 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 flat fraud within the last hour. Now the score is 0.91. 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 a merchant point of sale roughly has 0.05% natural fraud rate. That is one in 2,000. These are tight low noise signal and fraud largely resigns the card's own transaction velocity. Whereas online transactions have 0.6% of the fraud 12 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 the modeling one. The alert budget is fixed. Analysts review the top 0.5 to 1.5% 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 a 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 HD boost model. We did physical point of sale. We went from the 40 raw attributes to 87 engineered features. After selection and the leakage checks, the two positive rates moves from 35.5 to 36.6. And for the online transaction, same story. Nearly 200 engineered features and we pick up about a point. So you know two to five times the feature surface one point of DPR. 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 safe card's own history. We are projecting the information we already had. Tableau 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? Range sharing a device velocity chains across cart. A merchant went that went bad 40 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 metal 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 tie 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 in function. Which function we picked mattered way more than we expected and charik is going to come back to that. Third update. We concentrate that aggregate with the node's own state, push it through learns and then we stack it twice. So every transaction knows about its neighbors and its neighbors neighbor before the classifiers ever sees it. So does these results work up? Yes, it does. And I want to be precise about what's being compared. We did not replace XG post. We fed it. The genet produces the embeddings. these embedding scores into the same gradient boosted model and that's what can score. So XG boost alone versus XG boost plus the curve is what we are comparing at. So the three numbers that we would like to highlight first is 27 to 30% 33% related lift in the true positive rate over a two leg baseline using the same alert rate same evaluation window and same features available to both the models. Second, approximately $65 million projected annualized incremental fraud capture across the two cardboard or third the 3 millisecond P99 in barash. So this talk is just not about the numbers, it's about how we got here four decisions and order matters. First and the foremost sampling fraud is 1 in 2,000. So we cannot train a raw distribution. We have to lift the thought rate but this is not a tablet data set where the rows are independent. Every negative we drop takes its edges with it. Down sample 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 at leakage state which is harder than it sounds when your edges carry time stamps plus 32 derived features created to detect fraud. The third explanability 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 3 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 himed DK approach and this move the numbers again with this I would like to hand it over to Shahi 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 Sarik principal AI architect. This is judge a transaction by the company it gives. How a graph neural network bid exib boost by over 30% on fraud capture and how we serve it in 3 milliseconds. I will walk through the technical build, sampling, graph construction, serving and explanability. So let's get into it. First decision most teams get wrong is the data sampling. We hold a soft target fraud rate of.5% for card related merchant transactions about 10 times the 0.05% natural fraud rate and 6% for online transactions again about 10 times the 0.6% 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 two. As hard negatives, the most useful example for the decision boundary. If capping ever triggers, only the genuine users 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 11 and a half to almost 14 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 12 months we tested at natural rate of 0.05% and 0.6%. No windage 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 types 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 time stamp. No train val test leakage because of the disjointed 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 hawk audit. One more decision before the architecture. 202 model features across three node types. 73 on the user, 109 on the transaction, 20 on the merchant. 32 of the transactional features are derived. Purpose-built for fraud added in three waves. 10 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 jet 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 14 true rolling window velocity and temporal features. 5 minute, 1 hour, and 24hour 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 complimentary signals not redundant ones under the hood. This is graph says 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 detailed worth pausing on. We don't just average. We concatenate three order invariant statistics. Mean, max, and standard deviation. Combine that with the nodes own vector through learn weights. Embed a fixed length vector to hops. It's inductive. We learned that the aggregator waits 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 0.1. The fourth is tied to a fraud ring. 0.92. Average those four together and you get 0.32. That ring linked neighbor just got diluted into the crowd. Take the max instead and it comes through untouched. 0.92. 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 128 dimension is the sweet spot 64 dimension is close but slightly under fit 256 cost more GPU and gives you nothing back validation performance flattens past 128 and then starts to overfeit It's not a philosophical debate, just a sweep. Now the actual numbers side by side. For card related merchant transactions, best Exib Boost gets 36% true positive rate at a fixed 0.5% alert rate. GNN plus Exiboost gets 48%. A 33% relative lift, $5.6 6 million captured at an 83% capture rate. For online transactions, 48% up to 61%. 27% relative lift, $35.4 million captured at 71%. Online transaction is where most of that $65 million savings lives since it runs at 12 times the fraud rate of card related merchant transactions. Third decision explanability. We ran subgraph attribution across 200 flag cases in each channel. Transaction totaction velocity edges carry 0.94 mean importance in card related transactions 0.62 in online transactions and they are the top piece of evidence in all 200 card present cases. Merchant edges matter more in online transactions 0.19 versus 0.04 04 in card present where fraud writes the card's own velocity rather than the acceptance point. That's the difference between the model says 91 and the model says 91 because of these three linked transaction in the last 40 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 rational for automated decision. This isn't optional. Two, analyst trust and investigation speed and unexplained high score gets rubber stamped or ignored. Edge level evidence turns recomputee the case from scratch into verified three linked transactions. Three, model debugging attribution patterns show us when the model leans on a speurious 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 3 milliseconds. offline van memory bound GPU sarded layer wise graph says forward pass over the entire graph bashed 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 cast 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 cast. No grab build, no sampling. Recense weighted by an exponential decay that reproduces training exactly. Then the realtime scoring services runs only the new transactions own two layer forward from those cache states plus the exeost head. Nothing that scales with graph size runs per request. Three small tricks make it fast in practice. We pin math library thread pulls to one before the heavy libraries even load. That alone is the difference between 30 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 60 GBTE and it needs expensive high memory serving with a one day embedding lag in real time. True positive rate actually drops from 48 to 44%. The fix predict on the edge not the node. premputee embeddings for user and merchants only, never per transaction. That collapses the footprint to two to three gigabytes, about 20 times smaller, cheap enough to run on the same CPU class as the Exib Boost model it sits beside. Nvidia independently recommended the same approach and expects it to perform on par with the node model. Here's the actual request path. pre-processing, cast lookup, and the exubost head are all fractions of a millisecond. The GNN's own true two layer forward is the biggest single piece at 1.61 millisecond. End to end 2.3 millisecond at the median, 3.1 at P99, comfortably inside our 3 to 4 millisecond SLA. If we ever need more headroom that GNN forward is the first thing we would recompile or contise. Thank you for watching. We are both happy to go deeper sampling, graph construction, explanability or serving. Reach out anytime. Thank you.