Graph Databases in Practice: Fraud Detection and Recommendations

Picture a UK bank’s fraud team on a Tuesday morning. A single graph query returns a cluster of twelve accounts that all received funds from the same mule, shared a device fingerprint, and paid the same landlord within ninety seconds of each other. What would have taken a relational analyst days of join-writing takes seconds, because the relationships themselves are the data. That is the promise of graph databases, and in this post we want to demystify them for practical UK data engineering work — where they genuinely help with fraud detection and recommendations, and where they do not.

Why Graph Databases Excel at Connected Data

Relational databases store relationships implicitly, in foreign keys and junction tables. Graph databases store them explicitly, as edges that carry their own properties, direction, and type. When you ask “who else touched this account within two hops,” a graph engine follows pointers rather than scanning and joining indexes. That structural difference is why platforms such as Neo4j and Amazon Neptune have found a home in UK fintech. Monzo, a UK digital bank, uses graph analytics to detect fraud rings precisely because its investigators need to hop across accounts, devices, merchants, and phone numbers without pre-defining every join path.

The Limits of Relational Joins for Deep Relationships

A three-table join in PostgreSQL is fine. A seven-hop traversal across a fraud network is not. Each additional join multiplies the work the planner must do, and recursive CTEs become hard to read and harder to tune. Graph databases invert this: traversal cost scales roughly with the size of the neighbourhood you touch, not the total size of the dataset. In practice, UK teams report that queries which timed out against denormalised SQL warehouses return in milliseconds against a property graph, particularly when the question is “find the path” rather than “aggregate the rows.”

Property Graphs vs. RDF Triples: What UK Teams Choose

Two models dominate. Property graphs (Neo4j, TigerGraph, Neptune’s property-graph mode) attach key-value attributes to nodes and edges, which suits engineering teams coming from application development. RDF triples (subject-predicate-object) with SPARQL suit organisations with ontology, linked-data, or regulatory reporting requirements — pharmaceutical and public-sector projects in the UK often lean this way. Our advice: pick property graphs for operational fraud and recommendation workloads, and consider RDF where standards compliance and data interchange matter more than query ergonomics.

Fraud Detection: Uncovering Hidden Networks

Fraud is rarely a single bad transaction; it is a pattern across entities. Graph queries expose fraud rings, synthetic identities built from stolen credentials, and money-laundering layering where funds bounce through accounts to obscure origin. HSBC has invested in graph database technology for anti-money laundering, and Barclays has explored graph analytics for financial-crime detection. Commercial platforms Neo4j and TigerGraph are widely used graph database platforms in the UK for exactly these workloads, alongside open-source stacks built on Apache TinkerPop.

Pattern Matching for Circular Transactions

Circular flows — A pays B, B pays C, C pays A — are a classic laundering signal. In Cypher or Gremlin you express this as a pattern: match a directed cycle of length three to five, filter by amount thresholds and time windows, and return the participating accounts. The equivalent SQL requires self-joins whose count grows with cycle length, plus careful indexing to avoid full scans. Graph engines treat the cycle as a first-class query shape, which makes the detection logic readable and maintainable by analysts rather than only by database specialists.

Real-Time Scoring with Graph Algorithms

Detection is not only pattern matching. Graph algorithms such as PageRank, community detection (Louvain), and centrality measures score entities by their position in the network. A newly opened account that suddenly sits at the centre of a dense cluster is a stronger risk signal than one with a single suspicious transfer. UK fraud teams increasingly run these algorithms on streaming updates so that a risk score is attached to a transaction before it settles. A typical pipeline looks like this:

• Ingest transaction and device events from Kafka into a graph store.
• Run incremental community detection and centrality scoring.
• Emit a risk score back to the payment authorisation service.
• Persist flagged subgraphs for investigator review and audit.

Recommendations: From Browsing to Buying

The same traversal mechanics that catch fraud also drive product discovery. ASOS, a UK online fashion retailer, leverages graph-based recommendations to connect shoppers with items through shared attributes, co-purchase behaviour, and style similarity. Tesco has applied graph and knowledge-graph techniques to understand product relationships across its catalogue. Neo4j and Amazon Neptune both serve this market, and the pattern is consistent: the graph answers “what is near this user’s current intent” faster than a batch recommender can refresh.

Collaborative Filtering with Graph Traversals

Classic collaborative filtering says: users who bought X also bought Y. In a graph, this is a two-hop traversal — user to item to other users to their items — filtered by recency and weighted by interaction strength. Because the graph stores the interactions directly, you can mix signals (views, wishlists, returns) as edge properties and tune the traversal without rebuilding a feature store.

Session-Based Recommendations in E-commerce

Session-based recommendation is where graphs shine in retail. As a shopper clicks through a site, each click extends a path through the item graph. A short traversal from the current item, constrained by the session’s category and price band, produces a “you might also like” list in single-digit milliseconds. This is why graph databases pair well with real-time personalisation engines rather than replacing the batch model entirely — they handle the live tail, while the warehouse handles long-horizon analytics.

Implementing Graph Databases in UK Data Engineering

Adoption is rarely a greenfield project. Most UK teams already run a warehouse, a lake, and a streaming layer, and the graph becomes another consumer of that data. Cloud options reduce the operational burden: Amazon Neptune on AWS, Azure Cosmos DB’s Gremlin API on Azure, and managed Neo4j offerings from several UK-based providers. Consultancies such as ThoughtWorks have helped UK enterprises integrate graph stores into existing pipelines, and open-source Apache TinkerPop provides a standard interface for graph computing, which matters when you want to avoid vendor lock-in.

ETL and Streaming into Graph Stores

Batch ETL into a graph is straightforward but slow; streaming is where the value sits for fraud and recommendations. Practical patterns we see:

1. Land raw events in object storage for replay and audit.
2. Transform to node and edge records with stable identifiers.
3. Upsert via bulk loaders for history, and via streaming connectors for live events.
4. Maintain idempotency so replays do not duplicate edges.

Query Languages: Cypher, Gremlin, and SPARQL

Cypher (Neo4j) is the most readable for analysts and is now standardised through openCypher. Gremlin (Apache TinkerPop) is imperative and portable across many engines, which suits platform teams building abstractions. SPARQL serves RDF stores and linked-data use cases. Our experience in UK projects: start with Cypher for speed of delivery, keep Gremlin in mind if portability is a hard requirement, and reserve SPARQL for ontology-driven work.

Performance, Scalability, and Trade-Offs

Graph databases are not automatically faster than SQL or NoSQL. They are faster for a specific shape of question — deep, variable-length traversals. For wide aggregations, columnar warehouses still win. For simple key-value lookups, a document or KV store is cheaper. UK benchmarks we have seen show graph engines beating multi-join SQL by one to three orders of magnitude on path queries, while losing on bulk aggregation. Cost also matters: graph stores often need more memory per record because edges are first-class objects.

When Graphs Beat SQL Joins

Choose a graph when the query is about paths, neighbourhoods, or variable-depth relationships, and when those relationships change frequently. Choose SQL when the workload is reporting, aggregation, and well-defined schemas. Many UK teams run both, with the graph as an operational serving layer and the warehouse as the analytical source of truth.

Scaling Graphs: Sharding and Replication

Scaling graphs is harder than scaling key-value stores because traversals cross partitions. Approaches include sharding by entity type or tenant, replicating read-heavy subgraphs, and using engines such as TigerGraph that are designed for distributed traversal. Replication handles read scale and availability; sharding handles write scale but can turn a two-hop query into a cross-node operation. Plan your partition key around your most common traversal pattern, not around storage convenience.

FAQ

Do we need to replace our SQL database to use a graph database?

No. Most UK teams run a graph store alongside their existing warehouse and operational databases. The graph handles relationship-heavy queries such as fraud rings and real-time recommendations, while SQL continues to serve reporting and aggregation. Integration happens through ETL and streaming pipelines rather than wholesale replacement.

Which graph database should a UK team start with?

For most operational fraud and recommendation projects, Neo4j is the fastest route to value because of Cypher’s readability and the maturity of its tooling. Amazon Neptune is a strong choice if you are already committed to AWS and want a managed service. TigerGraph suits larger distributed deployments. Apache TinkerPop compatibility is worth checking if portability matters.

How do graph databases fit with GDPR and UK data protection rules?

Graphs make personal data relationships more visible, which is both an opportunity and a risk. You need clear retention rules on edges as well as nodes, and the ability to delete a data subject’s relationships on request. In practice, UK teams tag nodes and edges with provenance and retention metadata so that erasure requests can be executed as graph operations rather than manual audits.

Are graph databases suitable for small teams with limited budgets?

Yes, if the use case is clear. Open-source Neo4j Community Edition, Apache TinkerPop with a compatible engine, and small managed instances keep entry costs low. The bigger investment is skills: Cypher and graph data modelling take time to learn, and a poorly modelled graph can be slower than the SQL it replaced.

What metrics should we track in a graph database pilot?

Track query latency at the 95th percentile for your target traversal, ingestion throughput for streaming edges, memory cost per million edges, and the accuracy of the downstream outcome — fraud catch rate or recommendation click-through. Compare against your existing SQL or NoSQL baseline on the same questions, and set a decision date before the pilot begins.

Graph databases are not a silver bullet. They are a powerful tool for relationship-heavy problems, and the UK organisations getting value from them — Monzo, HSBC, ASOS, and many smaller teams — treat them as one component in a broader data engineering stack rather than a replacement for everything else. Our advice is to pilot with a narrow, measurable use case, define success metrics in advance, and let the results decide whether the graph earns a permanent place in your architecture.