Network Analysis in AML: How It Works & Use Cases

An AML investigation can change when apparently unrelated accounts turn out to share a beneficiary, a controller, or a sequence of transfers. Assessing each account separately leaves those connections outside the decision. Network analysis brings them into view, helping investigators examine whether activity that looks ordinary locally forms a suspicious pattern across several parties.

This article explains how network analysis works in anti-money laundering (AML), how to build a transaction network, and which techniques support useful investigations. It also covers implementation choices that determine whether a network produces defensible evidence or simply more alerts.

What is network analysis in AML?

Network analysis in AML examines relationships among accounts, people, businesses, and transactions to identify patterns that merit investigation. It represents entities as nodes and relationships as edges. A payment connects two accounts; an ownership relationship connects a person or company to another entity.

The network can contain several relationship types without treating them as equivalent. An account holder, an authorized signatory, and a payment beneficiary have different roles. Preserving those distinctions lets an investigator ask how parties are connected and what that connection actually establishes.

For example, consider an illustrative case where several personal accounts receive unrelated payments and then transfer funds to the same business. Common destinations alone may have a normal explanation. If the account holders also share contact details and the transfers follow a repeated sequence inconsistent with their profiles, the combined evidence warrants closer examination.

Network analysis supports both detection and investigation. Detection searches for defined patterns across a population. Investigation starts from an alert or entity and expands the relevant relationships. Both should produce a traceable explanation of the connections found, with uncertainty visible.

How network analysis works

The process starts with a question, such as whether several alerted accounts belong to a coordinated collection network. That question determines the entities, relationship types, and time window needed for analysis.

Connect records to entities. Payment systems, customer due diligence records, and company data may use different identifiers for the same party. Entity resolution links those records using reliable identifiers and, where necessary, assessed combinations of attributes. Keep uncertain matches distinguishable from confirmed identities so they can be reviewed or reversed.

Build the relevant relationships. Represent transfers with direction, timestamps, amounts, currencies, and transaction identifiers. Add ownership or contact relationships where available and permitted. Record the source of each connection, including when it was observed and when it was valid.

Search and evaluate. A traversal follows relationships from a starting entity. Pattern matching finds arrangements such as multiple senders paying a common intermediary. Algorithms summarize connectivity or divide a network into groups. Investigators then compare the results with customer activity, supporting records, and plausible legitimate explanations.

Time ordering is essential. If account B pays C before receiving a payment from A, the path A → B → C does not establish that the later receipt funded the earlier payment. When funds are pooled, chronological transfers with similar amounts do not by themselves identify which incoming funds financed an outgoing transfer. Keep the transaction sequence available alongside the network view.

Why network analysis is important for AML

The unit of investigation can be larger than the unit that generated an alert. An account-level trigger may identify one participant while the relevant activity spans several customers, businesses, and payment channels. Network analysis gives the investigator a way to test that wider scope.

It can also make individual signals more interpretable. A shared address might mean a household or a registered-office provider. A common recipient might be a utility company. Combining relationship meaning with payment timing and customer context helps distinguish these explanations from a pattern requiring escalation.

There is public evidence for investigating this approach, with clear limits. The BIS Innovation Hub's Project Aurora report (2023) describes a proof of concept combining network analysis, machine learning, and privacy-enhancing technologies. It compared monitoring approaches using synthetic payment data with embedded laundering patterns. Its findings support the potential of collaborative analysis, but they do not establish the detection improvement a particular bank will achieve on real customers.

For an AML team, the practical test is whether network context improves case decisions: finding relevant participants, reducing repeated evidence gathering, or explaining why an alert deserves attention. A larger graph is useful only when it improves those outcomes.

How to build an AML transaction network

Start with the smallest model that can answer the selected investigation question. An account-transfer graph is often a useful foundation. Extend it with customer and ownership data when the use case needs those relationships.

A proposed starting schema is:

‍Keep transactions individually recoverable. Multiple payments between the same accounts should remain distinguishable. An aggregated edge can summarize a period for analysis, but investigators still need its underlying transactions. Define how reversals, refunds, rejected payments, and duplicate messages affect the representation.

Separate identity from association. Two customers using the same telephone number are associated through an identifier; that fact alone does not make them the same person. Represent shared attributes separately from entity merges. Otherwise, a weak match can join unrelated customers and contaminate subsequent paths.

Model external counterparties conservatively. A bank may see a beneficiary account identifier without having the beneficiary's full customer profile. Keep that counterparty as an explicitly partial record. Do not manufacture ownership or identity relationships from a name string.

Preserve time and amount semantics. Distinguish transaction time from ingestion time and document timezone handling. Retain original currency and amount when deriving normalized values. For ownership, retain the period during which the relationship applied, so today's structure does not silently explain yesterday's payments.

Before running detection, reconcile transaction counts and amounts with source records. Examine missing endpoints and ambiguous identities. These checks establish whether a path represents the underlying evidence accurately enough to investigate.

Network analysis techniques for AML

Choose techniques according to the question they answer. Their outputs describe network structure; the AML interpretation depends on the evidence attached to that structure.

Neighborhood and path analysis. Expand a bounded neighborhood around an alerted account to find counterparties, connected customers, and relevant ownership links. Apply explicit relationship and time filters. A payment path and an ownership path answer different questions, even when they reach the same business. Return the contributing records with the path.

Pattern and temporal analysis. Search for fan-in, fan-out, chains, or cycles, then apply timing and business constraints. Fan-in means several sources converge on a recipient; fan-out means one source pays several recipients. A cycle returns to its starting node. These shapes are candidates for review, since payroll, settlement, refunds, and treasury activity can create similar structures.

Centrality. Connectivity measures can identify accounts worth examining within a defined population. Count distinct sending and receiving counterparties separately from payment volume. Betweenness measures a node's participation in shortest paths, as defined in the NetworkX betweenness documentation. It describes a structural position, not proof that funds passed through that node or that its owner controls a scheme.

Components and communities. Connected components identify reachable groups; weakly connected components ignore edge direction. Community detection seeks a finer grouping. For example, Louvain optimizes modularity, a measure comparing within-group connections with a reference model. Neither a component nor a community is automatically a criminal organization. Inspect which relationship types and high-volume counterparties created the group.

Network features for machine learning. A model can use features such as distinct counterparties, changes in neighborhood size, or participation in selected patterns. Compare it with a baseline using account and transaction attributes. Construct features from information available at the decision time; later investigation outcomes and future connections must not leak into historical predictions.

Begin with a method an investigator can explain. Add complexity when it finds useful evidence that simpler queries miss, and retain a way to inspect the records behind the result.

Role of graph analytics in AML

Graph analytics provides the computational methods for querying and measuring the network. Visualization helps an investigator inspect a result, but detection also needs repeatable queries, documented filters, and outputs that can enter an existing case workflow.

The graph model determines what those queries mean. If a relationship means authorized signatory, a query must not silently treat it as beneficial ownership. A shared semantic model gives engineers and investigators a common vocabulary for these distinctions and reduces repeated interpretation of source tables.

Architecture then determines how the model reaches the data. A graph database can store an ingested representation of the network. Another option is to define the graph over existing analytical tables. Evaluate the choices against source coverage, refresh requirements, traversal workloads, and operational ownership.

For AML data already held in supported SQL databases, warehouses, or lakehouses, PuppyGraph lets teams query those tables in place without requiring a persistent duplicate graph dataset. Teams define a graph schema mapping tables to nodes and edges, giving investigators a model of accounts, parties, transfers, and ownership over the existing records. Data preparation and entity resolution remain necessary; zero graph-specific ETL does not remove those tasks.

PuppyGraph supports openCypher and Gremlin queries and built-in algorithms including PageRank, Louvain, and weakly connected components. An AML application can use these capabilities to retrieve connected evidence and calculate network features alongside existing monitoring and case management. The team still defines detection logic, validates results, and decides how evidence enters investigations.

AML network analysis use cases

The following use cases combine recognizable financial crime concerns with proposed investigation approaches. The network provides leads whose meaning must be assessed against the underlying records.

Investigating suspected money mule networks. The FBI's money mule guidance describes people moving illicit funds on behalf of others, sometimes without knowing their role. Start from suspected recipient accounts and examine common destinations, transfer sequences, and corroborating identity links. This can identify additional accounts for review without assuming every connected account holder acted knowingly.

Reviewing funnel account activity. FinCEN's funnel account advisory (2014) describes geographically dispersed cash deposits followed by withdrawals elsewhere with little delay. A useful network therefore includes deposit events and locations as well as account transfers. Compare that geography and timing with the customer's business. A generic fan-in pattern alone does not establish funnel account activity.

Tracing possible layering. In an illustrative investigation, several businesses pass funds through a chain before money reaches an account related to an earlier participant. Search for time-ordered paths and repeated cycles, then examine payment purpose, amounts, and ownership evidence. Keep pooled balances and missing external transactions visible as limits on any claim about the movement of specific funds.

Examining concealed ownership relationships. The FATF–Egmont Group's Concealment of Beneficial Ownership report (2018) examines how legal structures and intermediaries can obscure ownership. An investigation graph can connect documented shareholders, controllers, companies, and their accounts. It can expose a relationship absent from the account view, while also showing where ownership information is missing or outdated.

Connecting related alerts into an investigation. Several alerts may reference different accounts in the same suspected activity. Use shared counterparties and substantiated control links to suggest related cases, then let analysts assess whether consolidation is appropriate. Preserve each alert's original reason and avoid merging cases merely because they share a common service provider.

Across these uses, the valuable output is a bounded set of relationships that changes an investigation's scope or explanation. A dense diagram without a clear evidentiary question adds little.

Challenges of using network analysis for AML

Incomplete and incorrect connections. Missing external transactions can break a path; a mistaken entity merge can invent one. Shared infrastructure creates another problem: payment processors and registered-office addresses can connect large numbers of unrelated customers. Expose data coverage and match confidence, and assess the effect of including these hubs.

Privacy and access boundaries. Connecting customer, payment, and ownership records makes the combined dataset sensitive. Define permitted purposes, access controls, and retention arrangements before expanding the graph. FATF's Stocktake on Data Pooling, Collaborative Analytics and Data Protection (2021) treats collaborative analytics and data protection as linked considerations. Technical ability to join datasets does not establish permission to share them across institutions or borders.

Weak labels and misleading evaluation. An alert, an escalation, and a confirmed criminal outcome are different labels. Treating them as interchangeable can train a model to reproduce earlier decisions rather than identify useful new evidence. A closed case also does not necessarily prove the activity was legitimate. Document what each evaluation label establishes.

Computation and reproducibility. Broad traversals through high-degree accounts can generate large result sets. Bound exploratory queries and measure the coverage lost through each restriction. Preserve the query, schema version, analysis window, and source evidence needed to reconstruct a result after underlying data changes.

These challenges belong in the design from the beginning. They affect which conclusions an investigator can defend, not just whether a query executes successfully.

How to implement network analysis in an AML program

Start with one operational question and an accountable AML owner. For example, test whether network context helps investigators identify related accounts when reviewing suspected mule activity. Define the expected evidence and the point in the current workflow where it would be used.

Build a limited dataset with data engineering and investigation staff together. Agree on entity identifiers, relationship meanings, transaction status handling, and historical coverage. Review sample networks against original records before selecting algorithms. Investigators should be able to challenge both a connection and the reason it appeared.

Run a retrospective evaluation using only information available at each historical decision point. Compare results with the existing process and include legitimate activity with similar shapes. Keep related entities together when designing evaluation splits where appropriate, so near-duplicate networks do not create an inflated impression of generalization.

Measure operational outcomes: relevant additional accounts found, evidence-gathering time, duplicate case creation, and investigator-assessed usefulness. Where labels support it, assess detection quality at the review capacity the team actually has. More alerts or more escalations alone do not demonstrate better detection.

Introduce the workflow in shadow mode before making it part of routine prioritization. Present the triggering pattern, source transactions, time window, and uncertainty with each result. Collect reasons for dismissal and escalation, then use those findings to revise relationship filters and detection logic.

Assign owners for ongoing data quality, schema changes, query changes, and performance monitoring. Expand to another use case only after the first produces repeatable evidence that investigators can use and explain.

Conclusion

Network analysis helps AML teams examine the relationships around an account or transaction: where payments converge, how parties are connected, and which related activity deserves review. Its value depends on accurate identities, meaningful relationship types, time-aware analysis, and evidence that survives scrutiny.

Try the forever-free PuppyGraph Developer Edition and book a demo to explore connected AML evidence across existing analytical tables with no graph-specific ETL.