Network Analysis: What It Is, What Regulators Expect, and What Gets You Cited

What is Network Analysis?

Network analysis is an AML compliance control that applies graph mathematics to map the connections between accounts, legal entities, beneficial owners, and transactions. It's also called graph analytics. The two terms describe the same thing: building a structured picture of who is connected to whom, through what transactions, and at what risk level.

Where standard rule-based Transaction Monitoring treats each account in isolation, network analysis traces funds across multiple hops and entities. The control builds a directed graph: nodes represent customers, accounts, corporate entities, individuals, or devices; edges represent transactions, shared attributes (same address, phone number, device fingerprint), or declared relationships. Risk scores can then propagate through that graph. A high-risk node raises the assessed risk of its connected neighbors, even when those neighbors show no individually suspicious behavior.

Network analysis 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.

The control is best positioned to catch schemes that are 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. Network analysis catches the structure. Money Mule Networks are the textbook example: each account looks clean in isolation; the network pattern is the tell.

Why is Network Analysis required?

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. That makes network analysis, at minimum, strongly implied.

More explicitly, the FATF's 2021 Guidance on Beneficial Ownership of Legal Persons calls for technical tools capable of identifying complex ownership structures and beneficial owner chains across jurisdictions. The EU's Sixth Anti-Money Laundering Directive (6AMLD) criminalizes facilitation of money laundering across borders, putting pressure on banks to detect multi-entity schemes before the fact. In the US, the FFIEC BSA/AML Examination Manual requires that institutions identify customers' networks of relationships and understand fund flows within them. SAR regulations under 31 CFR 1020.320 require that filings describe "related accounts" and "known accomplices," which means network visibility is a statutory requirement, not a best practice.

The risk-based approach established by FATF allows institutions to calibrate depth of analysis to customer risk. But regulators are increasingly skeptical of programs that apply only individual-account monitoring. High-risk customers, politically exposed persons, and correspondent banking relationships require the deepest mapping.

FATF Recommendation 13 on correspondent banking creates a direct obligation to understand the customer base of respondent banks. That's a network problem by definition.

Enhanced Due Diligence requirements for elevated-risk customers 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.

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 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.

How Network Analysis connects to other controls

Network analysis draws from and feeds into nearly every other AML control in the program.

Its primary feeder is Customer Due Diligence. The entity graph is only as good as the KYC data that populates it. Weak CDD means incomplete beneficial ownership chains and missing nodes. When CDD data is stale (reviewed on five-year cycles rather than risk-based triggers), the graph drifts out of accuracy, and risk scores become unreliable.

Transaction Monitoring is the closest sibling. Transaction monitoring fires on individual account behavior; network analysis fires on structural patterns across accounts. The two should share data bidirectionally: a transaction 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.

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.

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.