Banking — 1M+ transactions dailyKnowledge graphs & graph neural networks

Knowledge graphs and graph neural networks for transaction fraud detection

How a top-20 bank moved from rule-based screening that caught 71% of fraud to a graph-native system catching 92% — while cutting false positives by 62%.

A side-by-side comparison of two representations of the same transaction data. On the left, a flat table: each row is scored in isolation against a known bad pattern, which caught 71% of fraud and produced 40% false positives with a four to six hour decision time. On the right, the same 250,000 historical records rebuilt as a knowledge graph of 24,000 nodes and 176,000 edges at 99.6% processing accuracy, spanning amounts, 150+ merchant categories, demographics, 2,000+ locations and internal operator details, reaching 92% detection with 62% fewer false positives and a 30-minute decision. Below, four things the graph carries that the table could not: an amount band of 300 to 600 units carrying 3.8 times the fraud risk, merchant categories with under 0.01% incidence, 2,000+ locations linked to operators, and 15 behaviour clusters found rather than defined.
The same 250,000 records, held two ways. A fraud ring is a shape — a flat table has nowhere to put it.

Project snapshot

Client
A top-20 banking institution processing over 1 million transactions daily. Results were validated across multiple financial institutions rather than a single engagement.
Industry
Financial services — retail banking and card issuing
Business function
Fraud detection and analyst operations
Challenge
Existing rule-based screening caught only 71% of fraudulent transactions while generating 40% false positives, and average response time to a potential fraud case was 4–6 hours. The analytics team needed detections they could interpret and act on, not just scores.
Solution
Transaction data became a knowledge graph of 24,000 nodes and 176,000 edges built from 250,000 historical records, spanning amounts, 150+ merchant categories, demographics, 2,000+ locations and internal operator details. DeepWalk, GCN and GraphSAGE run over the graph, community detection clusters behaviour, and an LLM layer lets analysts interrogate patterns in natural language.
Result
Detection rose from 71% to 92% within three months, false positives fell 62%, and detection time dropped from 4 hours to 30 minutes. An estimated $12M in fraud losses was prevented in the first quarter, against a 312% first-year ROI.

Key outcomes

92%
Fraud detection rate, up from 71%
62%
Reduction in false positives
30 min
Mean time to detect a fraud case
$12M
Estimated losses prevented in Q1

The client

A bank where a million decisions a day ran on rules

Financial fraud losses reached $41 billion globally in 2023, and the average cost of fraud for financial institutions rose 19.8%. Across the industry, traditional rule-based systems catch roughly 65% of fraudulent transactions.

This client — a top-20 banking institution processing over a million transactions daily — sat just above that line at 71%.

Which is to say almost three in ten got through.

The challenge

Catching more fraud without drowning the analysts

Raising the detection rate is easy if you do not care about false positives. This bank cared. Its existing rules already produced 40% false positives, and every one of those was an analyst’s afternoon.

The incumbent

71%
of fraudulent transactions caught by the rule engine — against a 65% industry norm
4–6 hrs
average response time to a potential fraud case, before anyone looked at it

Five things had to move at once. Detection had to rise from 71% without inflating false positives. The 40% false-positive rate had to come down, not hold steady. Detection had to become proactive — identifying emerging patterns rather than matching known ones. Whatever the system flagged had to be interpretable, because the analytics team had to act on it. And the four-to-six hour response window had to shrink.

Constraints

What we had to design around

  • VolumeOver 1M transactions a day, built against 250,000 historical records, with a production requirement of 2.5M transactions daily.
  • LegibilityA score with no explanation is not actionable. The analytics team had to see why, and had to be able to turn what they saw into rules themselves.
  • ComparisonThe system would be judged against an incumbent rule set everyone already trusted, so the gain had to be legible — not merely statistically significant.
  • BreadthFraud signal lives across amounts, merchant categories, demographics, geography and internal operator behaviour. A flat table loses the connections between them, and the connections are the signal.

The last of those is the one that decided the architecture. Fraud is not a property of a transaction. It is a property of a pattern of transactions — and a pattern is a set of relationships that a row-shaped store has nowhere to put.

Our approach

Model the relationships, not the rows

A rule engine asks whether a transaction matches a known bad pattern. A graph asks who this transaction is connected to, and what those connections look like collectively. The first can only ever find what someone already wrote down.

What we built it from

250K
historical transaction records
24K
nodes in the resulting graph
176K
edges between them

Construction ran at 99.6% data processing accuracy, with only 0.4% requiring manual review. The graph incorporates transaction amounts, merchant categories across 150+ categories, user demographics, transaction locations mapped across 2,000+ points, and internal operator details — all of it in one structure rather than five joins.

The solution

Three analyses over one graph, two consumers

The graph is built once. What changes is who reads it and why.

A left-to-right pipeline. 250,000 historical transaction records enter graph construction, producing 24,000 nodes and 176,000 edges at 99.6% processing accuracy. Three analysis families then run over the same graph: DeepWalk embeddings at 89% pattern recognition accuracy, graph neural networks using GCN and GraphSAGE at 94% precision, and community detection at 87% clustering accuracy resolving the corpus into 15 clusters. Their output feeds two consumers rather than one score: a visual layer projecting 1000-dimensional embeddings into two and three dimensions at 94% pattern recognition, and an LLM analyst interface that cut analysis time 85% and drives automated rule generation at 91% accuracy, producing rule sets 45% more efficient than the legacy engine. Manual review requirements fell 73%, and the system runs 2.5 million transactions a day at 99.99% uptime.
Three analyses read the same graph. What matters is that the output goes to an analyst who can act on it, not to a score.

Representation learning. DeepWalk generates node embeddings at 89% accuracy in pattern recognition. Graph neural networks — GCN and GraphSAGE — run over the same structure at 94% precision. Community detection clusters behaviour at 87% clustering accuracy, resolving 250,000 transaction rows into 15 distinct clusters.

Visual intelligence. 1000-dimensional embeddings reduce to 2D and 3D projections at 94% pattern recognition accuracy. An analyst sees the shape of a fraud ring rather than reading a list of flagged rows.

Interactive analysis. An LLM layer lets analysts interrogate patterns in real time, cutting analysis time by 85%. Decision-tree models built from the graph reach 91% accuracy, and rule generation is automated at the same 91% — producing rule sets 45% more efficient than the legacy system.

15behaviour clusters the graph found on its own — none of them written down in advance by anyone
Two scatter plots of the learned node embeddings from the engagement. The upper plot shows the unlabelled embedding space: several hundred transaction nodes projected to two dimensions, forming distinct arcs and clusters rather than a uniform cloud. The lower plot is the same projection with fraud labels applied, showing the fraudulent nodes concentrated in a separate region from the legitimate ones — which is the visual confirmation that the graph structure separates the two classes before any classifier is applied.
The embedding space, unlabelled above and fraud-labelled below. The separation is a property of the graph, not of a classifier applied afterwards.
A six-panel grid of the same embedding projection, each panel coloured by a different attribute: fraud label, merchant, category, age, gender and amount. The node definition dictionary above shows the schema — target is fraud, customer carries age, gender, amount and category, and merchant and category are categorical features. Merchant and category produce strong visible structure. Gender produces none, which is the finding that gender showed under 0.1 percent correlation with fraud.
The same projection coloured six ways. Merchant and category structure the space; gender does not — which is how we established it was not a factor.
A hand-drawn working diagram of the pipeline from graph to rule. The full transaction graph at top left resolves into labelled communities, annotated with the 250,000 record count. Those communities are partitioned — one group of about 10,000 and the remainder around 240,000 — and fed into a decision tree, where a highlighted path from root to leaf is annotated as a rule. This is the path by which a cluster the graph discovered becomes a rule the analytics team can deploy.
The working sketch of how a cluster becomes a rule — the step that turned graph output into something the analytics team could deploy themselves.

Responsible by design

A flag an analyst can argue with

The interpretability requirement was not a nice-to-have; it decided the design. A model that raises a high-confidence flag nobody can explain creates two failures at once: the analyst cannot justify acting on it, and cannot justify ignoring it either.

So the output of every analysis path lands somewhere a person can interrogate it — the 2D and 3D projection for shape, the LLM layer for questions in plain language, and generated decision trees for the rule the pattern implies. The team stopped receiving scores and started receiving explanations they could turn into their own rules.

That is also why some of the findings are negative and were kept anyway: gender showed effectively no correlation with fraud patterns, under 0.1%. A model that cannot tell you what does not matter is not being read carefully enough.

Results

Measured against the incumbent rule engine

  • Detection rose from 71% to 92% within the first three months, with high-risk transaction flagging at 95% accuracy.
  • False positives fell 62%, against a legacy engine generating 40%. Manual review requirements dropped 73%.
  • Detection time went from 4 hours to 30 minutes, against a prior process that ran four to six hours.
  • $12M in fraud losses prevented in the first quarter, alongside a 312% first-year ROI, operational costs down 35%, and $800K a year no longer spent investigating false positives.

The graph also surfaced things the rules could not. A transaction amount range of 300–600 units carrying 3.8× higher fraud risk. Merchant categories with under 0.01% fraud incidence, safe to stop screening. Prediction of emerging fraud patterns at 88% accuracy.

Beyond the numbers

What else changed

Against industry benchmarks the system detects 47% better than average, holds a false-positive rate 52% lower than standard, processes 3.2× faster than traditional systems, and costs 45% less per fraudulent transaction detected.

2.5M / daytransactions handled in production at 99.99% uptime

Rule set updates got 75% faster and team efficiency improved 54% — both downstream of the same thing. When an analyst can see why a pattern is a pattern, writing the rule for it stops being guesswork.

One qualifier worth stating plainly: the results above reflect actual implementations across multiple financial institutions rather than a single engagement, and individual results vary with organisational context and implementation scope. The industry figures in the opening — $41bn in global losses, the 19.8% cost increase, the 65% typical catch rate — are published third-party research, not our measurements.

If your fraud rules are catching less than you would like

The first question is not which model. It is whether your data is shaped so the patterns can be seen at all — and that is answerable from your own historical transactions.