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. Risk scores can then propagate through that graph, so a high-risk node raises the assessed risk of its connected neighbors even when those neighbors show no individually suspicious behavior.

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, which treats each account in isolation and scores individual events against rules. Network analysis traces funds across multiple hops and entities, scoring the relationships between events. 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. Single-account rules catch individual accounts; graph analysis finds the ring behind them.

The control sits in the detection layer of an AML program, feeding directly into customer due diligence reviews. Its primary outputs are network-level alerts, enriched SAR narratives, and risk-score adjustments fed back into the customer risk model.

It's best positioned to catch schemes invisible at the individual account level. A bank monitoring accounts in isolation won't detect a network of 200 connected mule accounts where each account stays below standard alert thresholds. Money mule networks are the textbook example: each account looks clean on its own; the network pattern is the tell.

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 Recommendation 10 requires financial institutions to conduct ongoing due diligence on business relationships and to understand the ownership and control structure of legal entity customers. Understanding control structure means mapping it, which makes network analysis at minimum strongly implied. FATF's 2021 Guidance on Beneficial Ownership of Legal Persons is more explicit, calling for technical tools capable of identifying complex ownership structures and beneficial owner chains across jurisdictions. Its 2021 report "Opportunities and Challenges of New Technologies for AML/CFT" cited graph-based relationship analysis as suited to complex typologies, particularly correspondent banking risk and cross-border schemes, concluding that institutions combining network analysis with behavioral scoring were outperforming those relying on rule-based systems alone.

In the United States, the FFIEC BSA/AML Examination Manual requires institutions to identify customers' networks of relationships and understand fund flows within them. SAR regulations under 31 CFR 1020.320 require filings to describe "related accounts" and "known accomplices," which makes network visibility a statutory requirement rather than a best practice. FinCEN's Section 314(b) voluntary information-sharing program enables institutions to share information 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.

In Europe, the Sixth Anti-Money Laundering Directive criminalizes facilitation of money laundering across borders, putting pressure on banks to detect multi-entity schemes before the fact. For ultimate beneficial owner verification under the Fifth 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 relying solely on self-reported ownership filings without graph-level verification are leaving a significant control gap. 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 monitoring framework.

The risk-based approach established by FATF allows institutions to calibrate depth of analysis to customer risk, but regulators are increasingly skeptical of programs applying only individual-account monitoring. High-risk customers, politically exposed persons, and correspondent banking relationships require the deepest mapping. Recommendation 13 on correspondent banking creates a direct obligation to understand the customer base of respondent banks, which is a network problem by definition, and enhanced due diligence requirements reinforce the same point: when the customer is high-risk, regulators expect the institution to understand who that customer is connected to, not just the customer themselves.

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.

What do regulators expect to see?

On examination day, regulators want documented evidence that network analysis is a designed, tested, and governed control. An ad hoc investigation tool pulled out after a suspicious pattern surfaces doesn't satisfy the requirement.

Policy and procedures. Examiners expect written policies describing when network analysis triggers (at onboarding, during periodic CDD review, on SAR investigation, and in real-time monitoring), which data sources feed the graph, how risk scores are calculated and propagated, and who has authority to act on network-level alerts. Oral explanations don't satisfy the documentation standard.

Calibration records. Any algorithm that generates alerts needs a documented tuning history. Examiners will ask how the institution chose its connection thresholds (for example, "flag if three accounts share an address and combined monthly flows exceed $50,000"), what backtesting was done against known typologies, and when the model was last reviewed. Undocumented thresholds are a standing citation in almost every thematic review.

Coverage testing. Regulators want proof the tool catches what it's designed to catch. That typically means running the system against known case studies or synthetic data and recording true-positive detection rates. Without testing evidence, a tool's effectiveness is unverifiable on exam day.

Governance and escalation. Who owns network analysis outputs? What's the escalation path when a network-level alert fires? How are alerts documented, tracked, and resolved? Boards and MLROs should receive MI reports covering network alert volumes, closure rates, and SAR conversion rates, at minimum quarterly.

Record-keeping. Under FATF Recommendation 11, graph data, alert records, investigation notes, and decisions must be retained for at least five years in most jurisdictions. Examiners will test retention completeness.

What does good Network Analysis look like?

Best-practice network analysis goes beyond detecting known typologies. It generates hypotheses from structural patterns and tests them against transaction data and CDD records. The Wolfsberg Group's 2019 AML Principles call for risk assessment methodologies that consider a customer's full relationship context. The Basel Committee's guidance on sound management of ML/FT risks takes the same position: detection systems must account for associated relationships, not just account-level activity.

A mature implementation follows these steps:

1. Build the entity graph at onboarding. When a customer is onboarded, map all declared relationships immediately: beneficial owners, directors, authorized signatories, affiliated businesses. Cross-reference against existing customers to detect shared attributes, especially shared addresses, devices, and phone numbers.

2. Refresh the graph continuously. New transactions, address changes, and relationship disclosures update the graph in real time. Monthly batch refreshes miss connections that form and dissolve quickly.

3. Apply risk propagation. A customer assessed as low-risk at onboarding who later links to a sanctioned entity or a high-risk PEP should have their risk score updated automatically, triggering a fresh Customer Due Diligence review across connected accounts.

4. Alert on structural patterns. Hub-and-spoke configurations (many accounts funneling into one), rapid cycling between accounts, and clusters of accounts with unusual shared attributes are network-level signals. They don't appear at the individual account level.

5. Integrate network findings into SAR narratives. A SAR that says "Account X received funds from Account Y" is weak. A SAR that maps the full network, identifies the hub, and quantifies total flows gives prosecutors something to act on. The FFIEC BSA/AML Examination Manual explicitly calls for comprehensive SAR narratives that describe the full scope of suspicious activity.

6. Tune and retest at least quarterly. As typologies shift, thresholds need updating. Document every change with a business justification and a test result. Changes with no documented rationale are a finding on the next exam.

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.

Common audit findings and exam citations

Network analysis failures cluster into a few repeating patterns.

Siloed monitoring. The most costly failure is treating accounts in isolation while networks flow through undetected. The Danske Bank enforcement action in 2018 is the defining case: approximately €200 billion moved through the Estonian branch over a decade, largely through interconnected non-resident accounts that shared attributes, cycling through hub accounts. Individual transaction monitoring wasn't calibrated to detect the network pattern. No single account alert fired because individual thresholds were set low enough that each account looked unremarkable.

Threshold gaps. Institutions configure thresholds for individual accounts but nothing at the network level. A network of 50 accounts each transacting below $10,000 can collectively move $3 million a month in smurfing patterns without triggering a single standard alert. Without network-level detection, the program misses it entirely.

Untested tools. Examiners routinely cite institutions where network analysis was deployed but never formally tested against known typologies. The FFIEC Examination Manual states clearly that institutions must test the effectiveness of their detection systems. A tool with no test record offers no regulatory assurance, even if it happens to work.

Weak connectivity across jurisdictions. The Deutsche Bank mirror trade case (2017) resulted in $630 million in fines from US and UK regulators. Investigators found that transaction monitoring was running, but the bank had no mechanism to connect trades across Moscow, London, and New York into a coherent network picture. The scheme was a network problem. The monitoring program wasn't.

Documentation gaps. Missing tuning records, no evidence of model governance, no formal change management for detection logic. A control that works but has no documented evidence it works is still a finding.

Metrics and KPIs

Measuring network analysis health requires a distinct metric set, separate from individual account monitoring KPIs.

Alert volumes and patterns

• Network-level alerts per month, broken down by typology: hub-and-spoke, cycling, shared-attribute cluster, mule network
• Alert-to-investigation rate: what percentage of network alerts advance to full investigation?
• Network alert-to-SAR conversion rate: below 5% often indicates over-broad thresholds generating noise rather than signal

False positive rate For network analysis, false positive rate is harder to measure than in rule-based systems. A useful proxy: what percentage of network alerts close with no action within 30 days, and what's the median investigation time per closed alert? If investigators are averaging 15 hours per alert and closing 90% with no action, the model needs recalibration.

Coverage

• Percentage of the customer portfolio covered by network analysis (some institutions run it only on high-risk segments)
• Percentage of the portfolio where the beneficial ownership graph is complete to at least two levels

SLA and backlog

• Median time from network alert creation to closure: target under 30 days for standard alerts, under 72 hours for high-priority
• Backlog size and trend: a growing backlog is a leading indicator of threshold or staffing problems before they become exam findings

Tuning cadence

• Number of threshold changes in the past 12 months, each with a documented business rationale
• Date of last model validation against known typologies

These metrics belong in MLRO reporting and board AML committee packs, at minimum quarterly.

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 closest sibling and the most common companion method. Rule-based monitoring fires on individual account behavior; network analysis fires on structural patterns across accounts, providing the relationship context that turns an isolated alert into a coordinated scheme. The two should share data bidirectionally: a monitoring alert should trigger a network review to check whether the account sits inside a larger cluster, and a network-level risk score elevation should lower alert thresholds on connected accounts automatically. Teams that run both consistently close cases faster than those relying on either method alone.

Customer due diligence is the primary feeder, and enhanced due diligence is a primary beneficiary. CDD collects the raw relationship data: ownership structures, connected parties, registered addresses. Network analysis processes that into a scored relationship graph. The graph is only as good as the KYC data populating it, so weak CDD means incomplete beneficial ownership chains and missing nodes, and stale data (reviewed on five-year cycles rather than risk-based triggers) lets the graph drift out of accuracy until risk scores become unreliable. For high-risk accounts, a pre-built graph showing second and third-degree connections substantially reduces EDD investigation time.

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.

Sanctions screening feeds network analysis with node-level risk labels. When a node in the graph hits a sanctions match, risk propagates to connected accounts, triggering enhanced review across the cluster.

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 structure matches actual observed fund flows through connected entities requires a graph view of the full relationship set.

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.

The typologies network analysis is best positioned to detect are money mule networks, where the network structure is the scheme itself; layering, where funds move through multiple entities and jurisdictions to obscure origin; and structuring patterns where a cluster of accounts coordinates to stay below individual detection thresholds while collectively moving large sums.

How FluxForce supports Network Analysis

FluxForce AI agents run continuous entity graph analysis across account populations, detecting structural patterns including hub-and-spoke networks, cycling clusters, and shared-attribute anomalies in real time rather than overnight batch runs. Risk scores update dynamically as new transactions and relationship disclosures arrive. Every network alert includes full decision evidence: the nodes, edges, and scoring logic that triggered it, formatted for SAR attachment and examiner review. The result is faster alert triage, stronger SAR narratives, and an audit trail ready for examiner requests from day one.

Request a demo to see network analysis in a regulated environment.