Graph analytics maps relationships between entities to uncover money laundering structures that per-transaction monitoring misses. These are the five tools most often shortlisted for anti-money laundering (AML) detection and investigation:
- Neo4j: Native graph database with a graph data science library, queried in Cypher.
- TigerGraph: Native distributed graph database built for parallel traversal of large graphs.
- Linkurious: Investigation and visualisation layer that runs on top of a graph database you already have.
- DataWalk: No-code analytics platform that ingests multiple sources and models them as connected data.
- SAS Fraud, AML & Security Intelligence: End-to-end AML suite covering monitoring, case management and regulatory reporting.
The single most useful thing to understand before comparing them is that they are not the same kind of product. Two are databases, one is a user interface, one is an analytics platform and one is a complete compliance suite. A shortlist containing all five is really a shortlist of three different decisions.
Related video from YouTube
Quick Comparison
| Tool | What it actually is | Deployment and licence | Where it fits in an AML stack |
|---|---|---|---|
| Neo4j | Native property-graph database, queried in Cypher, with a graph data science library | Self-hosted Community edition under GPLv3, or commercial Enterprise licence; AuraDB managed cloud with a free tier | Infrastructure. You build the AML logic on top of it. Nothing about it is AML-specific. |
| TigerGraph | Native distributed graph database, queried in GSQL, designed for parallel traversal across large graphs | Commercial licence, self-hosted or managed cloud | Infrastructure, same as Neo4j. Choose between the two on scale, query workload and the skills of your team, not on AML features. |
| Linkurious | Investigation and visualisation layer, not a database | Commercial licence; connects to Neo4j, Amazon Neptune, Azure Cosmos DB, Memgraph and others | Sits on top of a graph store you already run and gives investigators somewhere to work. On its own it does nothing. |
| DataWalk | No-code analytics platform that combines disparate sources into a connected model | Commercial licence | More complete than a bare database, less complete than a full AML suite. Suits teams without engineering capacity to build on a graph database. |
| SAS | End-to-end AML suite: transaction monitoring, scenario management, alert and case handling, regulatory reporting | Commercial enterprise licence | The whole compliance stack from one vendor. Bought by institutions that want a single supplier accountable when a regulator asks. |
When choosing, work out which of the three decisions you are actually making first: whether to build on a graph database, whether to add an investigation layer to one, or whether to buy a suite and stop building.
The Five Tools in More Detail
Graph analytics changed how banks and financial firms look for money laundering. As schemes grow more layered, per-transaction rules struggle to see the connections between entities. These five products come up repeatedly on shortlists, for different reasons.
1. Neo4j
Neo4j is a native graph database, meaning relationships are stored as first-class objects rather than reconstructed with joins at query time. That is what makes multi-hop traversals practical. Key features include:
| Feature | Description |
|---|---|
| Native Graph Database | Stores entity relationships directly, so traversals do not degrade the way SQL joins do as hops increase |
| Cypher Query Language | Declarative pattern-matching syntax; the main thing your team has to learn |
| Graph Data Science Library | Community detection, centrality and similarity algorithms you would otherwise implement yourself |
| Scalability | Handles large data volumes; horizontal scaling and fine-grained access control are Enterprise-tier features |
| Licensing | Community edition is GPLv3, which has implications if you embed it in a product; Enterprise and AuraDB are commercial |
2. TigerGraph
TigerGraph is a native graph database with a distributed, parallel execution model. Its pitch is deep traversals across very large graphs. Key features include:
| Feature | Description |
|---|---|
| Distributed Parallel Engine | Partitions the graph across machines and executes traversals in parallel |
| GSQL Query Language | Procedural, SQL-like language; more expressive than Cypher for some analytics, and less widely known |
| Deep-Link Analytics | Aimed at queries that traverse many hops, which is where layering shows up |
| Scalability | Scales horizontally; the vendor publishes throughput benchmarks, which are worth reading as vendor benchmarks |
| Licensing | Commercial, self-hosted or managed cloud |
3. Linkurious
Linkurious Enterprise is not a database. It is the layer investigators actually use, connected to a graph store you already run. That makes it a complement to Neo4j or Neptune rather than an alternative. Key features include:
| Feature | Description |
|---|---|
| Graph Visualisation | Interactive exploration of the network around an alert, which is the day-to-day work of an investigation |
| Entity Resolution | Unifies records that refer to the same person or company across sources |
| Case-Oriented Workflow | Lets an investigator save, annotate and hand over a piece of work |
| Database Support | Connects to Neo4j, Amazon Neptune, Azure Cosmos DB, Memgraph and others |
| Prerequisite | You need a graph database and populated data before it is worth anything |
4. DataWalk
DataWalk is a no-code analytics platform rather than a database or a pure UI. It ingests multiple sources and lets analysts build queries and screens without engineering support. Key features include:
| Feature | Description |
|---|---|
| No-Code Platform | Analysts build applications and queries without writing code, which matters if you have no graph engineers |
| Multi-Source Ingestion | Combines internal systems and external data into one connected model |
| Data Preparation | Cleansing and matching are part of the platform rather than a separate project |
| Investigation Tooling | Provides context around an entity for analysts working a case |
| Trade-off | Less flexible than building on a graph database, less complete than a full AML suite |
5. SAS Fraud, AML & Security Intelligence
SAS sells the whole stack rather than a component. If you are replacing a transaction monitoring system and not just adding analytics to one, this is a different kind of purchase from the other four. Key features include:
| Feature | Description |
|---|---|
| End-to-End Suite | Monitoring, scenarios, alerts, cases and regulatory reporting in one product |
| Scenario and Model Management | Tuning, versioning and documenting detection logic, which is what examiners ask to see |
| Case Management | Full investigation workflow with audit trail |
| Entity Resolution | Resolves entity identities across the institution’s systems |
| Trade-off | Enterprise cost, enterprise implementation timeline, and a single-vendor dependency |
Which of these is right depends far more on what you already run and who will operate it than on any feature list. A bank with a data engineering team and an existing monitoring system is making a different purchase from a payments firm with three compliance analysts and no engineers.
Entity Resolution and False Positives
This article previously carried a “User Ratings” column scoring each product between 4.2 and 4.6 out of five, and graded each one’s integration and performance as High, Medium, Excellent or Very Good. Those scores and grades came from nowhere we can point to, so they have been removed. The same comparison table also appeared twice, identically; the duplicate has gone too.
Every vendor here claims to cut false positives. None of them publishes a false-positive rate you can compare against a competitor’s, and there is no independent benchmark for AML detection quality. The benchmarks that do circulate measure graph database throughput, and several are run by the vendors whose products they favour. Treat a false-positive claim in a sales deck as a statement about one customer’s data, not about the product.
Why graph analytics moves the false positive count at all
Rule-based monitoring alerts on a transaction. Graph analytics alerts on a structure. That difference is the entire mechanism:
- Context suppresses weak alerts. A payment that looks anomalous in isolation often looks routine once you can see the counterparty has been paid on the same day every month for three years. A per-transaction rule cannot see that history as a relationship; a graph can.
- Structure raises strong ones. Layering, circular transfers and shared attributes between apparently unrelated accounts are relationships rather than transactions. They are close to invisible to a threshold rule and obvious in a graph.
- The alert arrives with its own explanation. A large share of investigation time goes on reconstructing why an alert fired. A subgraph is that reconstruction, already done.
Entity resolution decides whether any of it works
Every claim above depends on correctly knowing that two records describe the same person or company. Get that wrong and graph analytics amplifies the error instead of correcting it:
- Under-matching — one customer held as three separate nodes — hides precisely the structure you bought the tool to find. The graph looks clean and is wrong.
- Over-matching — two different people merged because they share a surname and a postcode — invents relationships that do not exist and then alerts on them. This is the worse failure. Investigators have no obvious way to tell a manufactured link from a real one, and the output is confident either way.
- It is a data problem, not a graph problem. Resolution quality is set by your KYC records, your name and address normalisation, and how much of your customer base predates your current onboarding standards. None of these five products fixes bad source data, and any of them will happily build a network out of it.
What to ask for in a proof of concept
Run it on your own data rather than the vendor’s demo set, and pick a period where you already know the answers:
- Replay a stretch of historical alerts. How many of your known false positives would this have suppressed — and did it suppress any confirmed true positive along with them? The second question is the one vendors are least keen on.
- Check entity resolution output by hand on a sample. Count both the merges that should not have happened and the ones that should have.
- Time a real investigation end to end, including data preparation, not just the query.
- Establish who is accountable to your regulator for a detection model your team cannot fully explain. For some institutions that question eliminates the more opaque options before price is discussed.
When not to buy any of this
If your alert backlog comes from badly tuned rule thresholds, graph analytics is an expensive way to avoid tuning them. Retune first and see what is left. These tools earn their cost when what you are missing is genuinely relational — mule networks, shared beneficial ownership, accounts connected only through third parties — and not simply when you have too many alerts.
Conclusion
Key Takeaways
Graph analytics finds structures that per-transaction rules cannot: relationships between accounts, rather than anomalies within a single payment. The five products here — Neo4j, TigerGraph, Linkurious, DataWalk and SAS Fraud, AML & Security Intelligence — approach that from different layers of the stack, and comparing them as though they were interchangeable is the most common mistake on this shortlist.
Choosing the Right Tool
Start from what you already run and who will operate it. Evaluate the tool’s ability to handle your data volumes, the query patterns you actually need, and how much engineering it assumes you have. Then check the things that do not appear in feature lists: the licence terms, the implementation timeline, and whether you can explain the resulting model to an examiner.
| Key Factors | Description |
|---|---|
| Layer of the stack | Database, investigation layer, analytics platform or full suite. Decide this before comparing products. |
| Data quality going in | Entity resolution quality caps everything downstream. Assess it before you assess vendors. |
| In-house skills | A graph database needs engineers. A no-code platform or a suite does not, and costs accordingly. |
| Integration | How the tool connects to your existing monitoring, case management and core systems. |
| Explainability | Whether you can show a regulator why an alert fired, and who owns that answer. |
| Licensing | Open-source terms, commercial tiers and what each actually permits in production. |
| Scalability | Whether performance holds at your transaction volume, tested on your data rather than a benchmark set. |
| Customer Support | Vendor support and training, which matters most for the products that assume the least engineering. |
More on this topic
Browse all 79 articles on Security & Compliance.
