Network Analysis: Definition and Use in Compliance

What is Network Analysis?

Network analysis is the application of graph theory to model and examine relationships between entities in financial data. Each entity becomes a node: an account, an individual, a company, a device, or a transaction. Each relationship becomes an edge: a fund transfer, a shared address, a beneficial ownership link, a common phone number.

The value is in the structure that emerges, not in any single data point. A customer might have unremarkable transaction volumes in isolation. Place their accounts into a graph alongside 20 connected entities, and a hub-and-spoke pattern becomes visible: funds flowing in from dozens of sources, aggregating briefly, then exiting through a single channel. That structure is a textbook layering signature.

Graph algorithms compute structural metrics on this topology. Degree centrality measures how many direct connections a node has. Betweenness centrality identifies nodes that sit on the shortest path between many others, a recurring indicator of coordinators or cut-outs in a laundering ring. Community detection algorithms (Louvain and Girvan-Newman are the most common in financial crime applications) surface clusters of accounts that behave as an interconnected group.

Network analysis is also called graph analytics, and the two terms are used interchangeably across the industry. Both describe something fundamentally different from transaction monitoring: transaction monitoring scores individual events against rules; network analysis scores the relationships between events and entities. An account sending $9,900 eight times is a transaction monitoring problem. An account that is two hops from 40 others each doing the same thing is a network analysis finding.

That second framing is the better tool for organized schemes. Single-account rules catch individual accounts. Graph analysis finds the ring behind them.

How is Network Analysis used in practice?

In AML operations, network analysis runs across three workflows: SAR investigation support, high-risk account review, and proactive typology hunting.

During a Suspicious Activity Report investigation, an analyst builds a relationship graph centered on the subject account. Every counterparty, shared device identifier, registered address, phone number, and corporate ownership link enters the graph. What looks like a single suspicious account in a case queue frequently resolves into a 40-to-60-node cluster within two hops. That changes the case entirely: it's no longer a single filing, it's a coordinated network potentially requiring a multi-account referral to law enforcement. We've seen institutions open investigations on one account and close them with 55 accounts linked in a structured mule network.

For Enhanced Due Diligence reviews on high-risk customers, network analysis answers a question that KYC forms can't: "Who else is this entity connected to, and what are those connections doing?" A politically exposed person with unremarkable personal transaction history might route funds through a web of related entities linked by shared nominee directors or common registered addresses. Standard due diligence doesn't surface that. A graph view of beneficial ownership and associated transaction flows does.

On the proactive side, financial intelligence units run community detection across the full customer population before any individual alert fires. Clusters with unusually high internal transfer density and low external transaction variety are prioritized for review. Banks that operate this way consistently find their highest-severity cases through proactive graph scans, not through alert queues.

The tooling varies: some institutions build graph infrastructure in Neo4j or Amazon Neptune; others use specialist vendors. Whatever the stack, the core workflow is the same. Model the relationships, compute the metrics, triage the clusters.

Network Analysis in regulatory context

Regulators have increasingly pointed toward network analysis as a component of sophisticated financial crime programs, though most frameworks describe the outcome rather than mandate the specific technique.

FATF's 2021 report "Opportunities and Challenges of New Technologies for AML/CFT" explicitly cited graph-based relationship analysis as suited to complex typologies, particularly for correspondent banking risk and cross-border schemes. The report concluded that institutions combining network analysis with behavioral scoring were outperforming those relying on rule-based systems alone.

In the United States, FinCEN's Section 314(b) voluntary information-sharing program enables institutions to share information with each other to identify subjects under joint AML investigation. In operational terms, 314(b) is a manual, inter-institutional network analysis protocol. Automated graph analysis takes the same concept and runs it at scale within a single institution's data estate, without the latency of manual inter-bank requests.

The UK's Financial Crime Guide references relationship mapping for large retail institutions, noting that firms with extensive customer bases should consider graph-based approaches as part of their transaction monitoring framework.

For ultimate beneficial owner (UBO) verification requirements under the EU's 5th Anti-Money Laundering Directive and the US Corporate Transparency Act, network analysis is the primary method for cross-checking declared ownership structures against observed financial flows. A stated ownership chain that doesn't match actual fund flows through connected entities is a material discrepancy requiring escalation under both frameworks. Compliance teams that rely solely on self-reported ownership filings without graph-level verification are leaving a significant control gap.

Common challenges and how to address them

Network analysis in financial crime has three consistent failure modes: data quality, scale, and explainability.

Data quality is the first problem. A graph is only as good as the entity resolution underneath it. If the same person appears as "John Smith," "J. Smith," and "Jonathan Smith" across different source systems, the graph fragments into three disconnected nodes. The connections between them are invisible. Entity resolution is a prerequisite, not an optional enhancement. Banks that skip it before building graphs consistently produce fragmented views that miss the exact connections they're trying to find. For corporate customers, this means resolving the parent entity, all subsidiaries, all named directors, and all associated accounts into a single unified graph before running any detection algorithm.

Scale is the second challenge. A mid-sized retail bank with two million customers has potentially billions of edges when you account for transactions, shared identifiers, and ownership links. Querying a graph of that size in real time requires purpose-built graph databases and optimized traversal algorithms. Running naive SQL joins across normalized relational tables doesn't work beyond a few thousand nodes. This is an infrastructure investment, but it's a one-time architecture decision rather than a recurring operational cost, and the unit economics improve substantially as the graph grows.

Explainability is the hardest problem. A community detection algorithm surfaces a cluster of 45 accounts as suspicious. A compliance officer needs to explain to a model risk examiner why those accounts are connected and why that connection matters. "The algorithm flagged them" doesn't satisfy model risk governance requirements under SR 11-7 or equivalent frameworks. Teams need to document specific graph paths: account A sent $12,000 to account B, which shares a device ID with account C, which received funds from account D already under investigation. That narrative is the evidence, and it needs to accompany any SAR filing. This adds documentation time to each case, but the defensibility gain is worth it.

Related terms and concepts

Network analysis sits at the intersection of several disciplines that compliance teams need to understand in combination.

Transaction monitoring is the most common companion method. Rule-based monitoring generates alerts on individual events; network analysis provides the relationship context that turns an isolated alert into a coordinated scheme. The two work best together: transaction monitoring feeds alert queues, and network analysis provides investigation context for flagged accounts. Teams that run both consistently close cases faster than those relying on either method alone.

Behavioral analytics extends network analysis by adding a time dimension. Where network analysis maps structural relationships at a point in time, behavioral analytics tracks how an entity's activity pattern changes. Combined, they detect both organized schemes set up months in advance and rapid behavioral shifts characteristic of an account takeover attack.

Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD) both feed into and benefit from network analysis. CDD collects the raw relationship data: ownership structures, connected parties, registered addresses. Network analysis processes that data into a scored relationship graph. For high-risk accounts, a pre-built graph showing second and third-degree connections substantially reduces EDD investigation time.

For corporate customers, network analysis is the primary tool for verifying UBO declarations. Stating a beneficial owner on a disclosure form is straightforward. Confirming that the declared ownership structure matches actual observed fund flows through connected entities requires a graph view of the full relationship set.

Finally, shell company detection is almost entirely a network analysis problem. Shells are designed to look clean in isolation. Their exposure comes from the graph: shared directors with known-risk counterparties, circular fund flows, or ownership chains terminating in secrecy jurisdictions. None of that is visible in a single-entity file review.