Network Analysis in AML: Why You Don't Need a Graph Database
Published by EyesClear | February 2026
Every serious AML conversation eventually arrives at the same question: "How do you detect relationships between accounts?"
Rule-based transaction monitoring catches the obvious — threshold breaches, velocity spikes, structuring patterns. But money laundering doesn't happen in isolation. It happens across networks of accounts, entities, and intermediaries connected by carefully obscured transaction flows.
Detecting those networks requires network analysis. And the conventional wisdom says network analysis requires a graph database.
The conventional wisdom is wrong.
What Network Analysis Actually Does in AML
Before diving into architecture, it's worth understanding what network analysis solves that traditional transaction monitoring cannot.
Traditional monitoring asks: "Is this transaction suspicious?"
Network analysis asks: "Is the pattern of relationships between these accounts suspicious?"
That's a fundamentally different question, and it catches fundamentally different typologies.
Layering Detection
A money launderer moves $500,000 through 15 accounts across 4 institutions over 6 days. No single transaction exceeds a reporting threshold. No single account shows unusual velocity. Every individual transaction looks routine.
But the network tells a different story. The same funds flow from a single origin through a web of accounts and arrive at a single destination. Network analysis sees the complete path. Transaction monitoring sees 47 unremarkable transfers.
Money Mule Networks
A fraud ring recruits 30 individuals to receive and forward funds. Each mule processes small amounts — $2,000 here, $3,500 there. No individual account triggers an alert.
Network analysis identifies the cluster. These 30 accounts share common counterparties, similar transaction timing, and coordinated movement patterns. Community detection algorithms surface them as a group — even though no single account looks problematic.
Sanctions Evasion Through Intermediaries
A sanctioned entity doesn't transact directly. Instead, four layers of intermediary companies handle the funds, each adding a degree of separation. Traditional screening checks each entity against sanctions lists and finds nothing.
Network analysis traces the path. The sanctioned entity sits three hops away from the bank's customer, connected through a chain of transactions that path analysis reveals in seconds.
Hub-and-Spoke Structures
A central account receives funds from dozens of sources and distributes them to dozens of recipients. The central account itself may have a legitimate business explanation. But the network structure — high degree centrality, bridging unrelated account clusters — is a classic money laundering architecture.
Centrality measures identify these hubs automatically, ranking accounts by their structural importance in the transaction network.
The Graph Database Approach — And Its Problems
The standard industry approach to AML network analysis involves deploying a dedicated graph database — Neo4j, TigerGraph, Amazon Neptune, or similar. The logic seems sound: graph databases are purpose-built for relationship queries, so they must be the right tool for network analysis.
In theory, yes. In practice, the costs and complexity often outweigh the benefits.
Cost
Graph databases are not free — at least not at enterprise scale. Neo4j Enterprise licensing runs $100,000-$300,000+ annually. TigerGraph is comparable. Amazon Neptune bills by compute and storage, which escalates quickly with financial transaction volumes. Add in the infrastructure to run them alongside your existing AML platform, and you're looking at $150,000-$500,000 in additional annual cost — just for the network analysis layer.
Integration Complexity
A graph database doesn't replace your AML platform — it sits alongside it. That means building and maintaining a data pipeline between your transaction monitoring system and the graph database. Every transaction, every entity, every relationship needs to be transformed into graph format, loaded, and kept in sync.
This isn't a one-time project. It's a permanent integration that requires ongoing maintenance. When your data model changes — a new data source, a new entity type, a new relationship category — the graph integration needs to change too.
Operational Overhead
Graph databases require specialized expertise to operate effectively. Cypher query language (Neo4j), GSQL (TigerGraph), or Gremlin (Neptune) are not skills most AML teams have. You either hire graph database specialists or become dependent on the graph vendor's professional services.
Your compliance team can't build new network queries independently. Every new investigative question requires someone who speaks the graph query language. The same vendor dependency problem you're trying to solve with your AML platform reappears in your network analysis layer.
Time-to-Value
Implementing a graph database for AML network analysis is typically a 6-12 month project after the AML platform is already running. Six months of integration, testing, tuning, and training — before your investigators see their first network visualization.
The Built-In Alternative
What if network analysis wasn't a separate product bolted onto your AML platform, but a native capability built into the same engine that processes your transactions?
That's the approach EyesClear takes. Here's what it looks like in practice.
Relationships Built During Processing
EyesClear constructs the transaction network as a natural byproduct of message processing. Every transaction that flows through the system — whether real-time from SWIFT queues or batch from core banking — creates and strengthens relationships between entities in the unified data model.
There's no separate ETL pipeline to a graph database. No synchronization to maintain. No data format transformation. The network exists because the transactions exist.
Full Analytics Without a Graph Database
EyesClear's network analysis engine, accessible at `/network_analysis`, delivers the analytics capabilities that graph databases are known for — running directly against the platform's PostgreSQL data layer:
Centrality Measures: Degree centrality identifies the most connected accounts. Betweenness centrality finds accounts that bridge otherwise separate clusters — classic intermediary indicators. Closeness centrality identifies accounts with short paths to all others. PageRank assigns importance scores based on transaction flow patterns, not just connection count.
Community Detection: Modularity optimization algorithms identify tightly connected groups of accounts that transact primarily with each other — the signature of mule networks, fraud rings, and coordinated laundering schemes. Hierarchical clustering reveals multi-level community structures. Temporal community analysis shows how these groups form, evolve, and dissolve over time.
Path Analysis: Trace the complete flow of funds between any two entities, across any number of intermediaries. Identify transaction chains, circular flows, and layering patterns. This is the capability that makes sanctions evasion through intermediaries visible.
Risk Propagation: Network-based risk scores calculate how risk spreads through the transaction network. A high-risk entity doesn't just affect its direct counterparties — risk propagates through the network based on transaction volume, frequency, and structural position. Isolation metrics identify accounts that are structurally positioned to avoid detection.
Interactive Visualization
The network analysis interface provides the visual investigation capabilities that compliance officers and investigators actually need:
Interactive network graphs with entity relationship mapping and transaction flow visualization
Dynamic filtering to explore specific time periods, amount ranges, or entity types in real-time
Node sizing based on transaction volume — high-volume accounts are visually prominent
Time-based animation showing how the network evolves over days, weeks, or months
Zoom and pan controls for navigating networks with thousands of nodes
An investigator starts with a suspicious entity, expands to its immediate network, identifies unusual structural patterns, traces funds through intermediaries, and documents the complete picture — all within a single interface, in a single session.
Same Engine, Historical and Real-Time
Because network analysis runs on the same engine as transaction processing, it benefits from EyesClear's reprocessing capability. When you refine your network analysis parameters, add a new relationship type, or adjust community detection sensitivity, you can apply those changes to historical data overnight.
With a separate graph database, retroactive changes require re-ingesting data through the integration pipeline. With built-in network analysis, it's the same rerun capability that applies to everything else in the platform.
What This Means in Practice
For the Investigator
You're investigating a suspicious account. In the network analysis view, you see it's connected to 14 other accounts through direct transactions. Two of those accounts have high betweenness centrality — they bridge this cluster to another cluster of 22 accounts. Community detection has already flagged this 36-account group as unusually tightly interconnected.
You expand the visualization. The time-based animation shows the network forming over three months, with transaction frequency accelerating in the last two weeks. Path analysis reveals that funds entering the network on one side exit on the opposite side within 48 hours.
Total time: 10 minutes. With a legacy platform and no network analysis: this pattern is invisible. With a separate graph database: you'd need to switch tools, run a separate query, and manually correlate the results.
For the Compliance Officer
A regulator asks: "Can you demonstrate that your monitoring system detects layering schemes involving more than three intermediaries?"
You open the network analysis interface, set the path analysis to four or more hops, filter for the past 12 months, and show the patterns detected. You export the results as part of your examination documentation.
With a legacy platform: you explain that layering detection would require a separate project. With a separate graph database: you pull up one tool for the network view and another for the case history, hoping the data is in sync.
For the Technology Team
No additional database to license, deploy, monitor, patch, or back up. No integration pipeline to maintain. No specialized query language to learn. No second vendor relationship to manage. The network analysis capability is part of the platform you're already running.
Questions to Ask Any AML Vendor About Network Analysis
Is network analysis built into the platform or a separate product? If separate, ask about integration timelines, costs, and ongoing maintenance.
What database does network analysis require? If it requires a graph database, add that licensing to the total cost.
Can your compliance team run network queries independently? If it requires a specialized query language (Cypher, GSQL, Gremlin), you're buying a dependency.
How long to implement? If network analysis adds 6-12 months to the implementation timeline, factor that into time-to-value.
Can you retroactively analyze historical data? If applying new network analysis logic to historical data requires re-ingestion, understand the operational cost.
What centrality measures and community detection algorithms are available? Degree centrality alone isn't enough. Look for betweenness, closeness, PageRank, and modularity-based community detection at minimum.
The Bottom Line
Network analysis is essential for modern AML compliance. The question isn't whether you need it — it's how you get it.
The graph database approach works. But it adds six figures in annual cost, months of implementation, integration complexity, and vendor dependency for a capability that modern platforms can deliver natively.
EyesClear builds the transaction network as a natural byproduct of processing, then provides full centrality analysis, community detection, path tracing, risk propagation, and interactive visualization — all without a separate database, a separate integration, or a separate budget.
Same engine. Same data. Same interface. No graph database required.
EyesClear delivers built-in network analysis alongside real-time transaction monitoring, case management, and regulatory reporting. No graph database. No separate integration. No additional licensing. See it in action.