Financial crime does not stop at four hops. Does your analysis?
Introduction
When financial crime teams follow the money in an investigation, each payment from one account to another adds a step, or a “hop”. In our work with banks, these teams tell us that they often follow payment trails for two hops, or maybe four. That limit affects investigations, and the criminals rely on this. However, the greater consequence may be the failure of detection and monitoring: a suspicious structure and money movement may remain undetected if the analysis stops before its parts are all connected.
Tariq and Hassani’s 2023 study helps explain this starting point. They describe banks as “rarely interested” in trails beyond two hops because they see only their side of the money trail. The study also examines the computational difficulty of finding longer flows and proposes ways to reduce the search space.[1]
Yet a payment leaving the bank need not end the trail. The same external account may appear in both outgoing and incoming payments. Connecting those records can reveal a longer route already present in the bank’s data. The first case in this paper shows how separate payment fragments become a connected structure when examined together.
The next question is which other accounts are connected to the activity under review, and through which relationships. Answering it requires sufficient depth and access to the full available dataset, including records outside the original alert or case extract. The examples that follow explain why banks need both, and then we will consider the technology needed to make this practical.
1. Source: Link2. Source: Link
The missing link can change the whole analysis
In one of my investigations, as shown in Figure 1a, higher-risk accounts 1–7 each sent several thousand dollars to customer account A, below the threshold being examined. Lower-risk accounts 8–11 funded customer account B, and funds from accounts A and B were then transferred outside the bank (denoted by the “X”). In addition, there were incoming transfers to the bank’s accounts C and D, and then external transfers from those accounts.
Separate payment checks or short-chain searches can show these records as disconnected fragments. Viewed separately, they do not show that payments from both the higher-risk and lower-risk groups ultimately reach the same external recipient, Y.
Local views: pairs and short chains
A bank does not need visibility into every transaction in the financial system to perform deeper analysis. Its own records may contain several parts of the same scheme: transfers between customers, payments to shared external recipients, funds returning to the bank, and connections through ownership. The question is whether the bank can connect these records and identify its customers’ involvement. The first investigation described in this paper shows how that connection can remain hidden when analysis stops too soon.
The same records, one connected structure
Matching X across outgoing and incoming payments reconnects the fragments in Figure 1a. Every payment in Figure 1b has an endpoint at the bank, so the connected view uses records the bank already holds.
Account X connects the two groups after two payment steps from their starting accounts. However, that alone does not explain the flow. Following the subsequent payments allows the analyst to test whether their timing and aggregate values support a coordinated route through to Y. The route 1 → A → X → C → 12 → Y contains five payment steps, such that a four-step trace would miss the full picture.
In this investigation, payments were deliberately spread over time to obscure the connection, while compared flow values differed by 5–10%. Concern about Y prompted a reassessment of the lower-risk accounts. The wider investigation identified 14 similar structures. These were leads for investigation, not proof of wrongdoing on every connected account.
Later-stage mule accounts are a banking challenge
In a review published in 2025, the UK Financial Conduct Authority found that most banks investigated alerts involving mule accounts receiving funds directly from fraud victims. They were less responsive to alerts involving indirect recipients, despite clear risk factors.[3]
For a bank, this raises a practical question: which other accounts in its customer base are helping move the proceeds, even though they never received a payment directly from the victim?
Following a flow involves moving between data sets: accounts → transactions → accounts, then repeating the sequence. We sometimes call this “ping-ponging”. Filters refine each result. The inquiry can also move into KYC, IP data, or ownership records.[4] Tracing a layered ownership structure can add several steps before returning to the identified owner’s accounts and payments.
3. Source: Link4. Source: Link
Where deeper analysis helps a bank
A longer analytical path does not always mean following money through more banks. It can also mean connecting payments with customer, ownership and device records. The examples below show how five steps can connect information that would remain separated in a two-step view.
| Use case | Illustrative path | Depth | What the bank can investigate |
|---|---|---|---|
| Layering and returning funds | Account A → Account B → External account X → Account C → External account Y → Account D … | 5-7 payment hops | Whether transfers through external counterparties connect several of the bank’s accounts into a coordinated flow. Accounts A–D are held at the bank, so every payment has an internal endpoint. |
| Connecting flows through ownership | Account A → Company A → Holding companies → Common owner → Company B → Account B … | 5-12 relationship hops | Whether apparently separate customer flows are connected through ownership, using KYC records and available ownership information. |
| Finding connected accounts through device data | Account A → Customer A → Shared device → Customer B → Account B → Payment recipient … | 5-7 relationship hops, including one payment hop | Whether customers using the same device operate accounts or make payments that warrant investigation together, where the bank collects and can link those device records. |
These are illustrative paths, not typical hop counts for each type of crime. Each arrow represents one relationship in the example. Payment arrows follow the direction of the transfer; ownership and device relationships may be explored in either direction.
A connection is a reason to investigate, not proof of wrongdoing. Payment analysis also requires checks on timing, amounts and supporting evidence. The broader objective is to establish which additional accounts are connected to the activity under review, including accounts outside the original investigation.
The institution’s role changes the scale of the problem
The connected structure above in Figure 1b uses a customer bank’s records. In correspondent banking and intermediary payment services, tracing a payment can also involve settlement and technical accounts.[5] FIUs and related agencies can combine information from multiple institutions under their national mandates.[6] Broader visibility makes the ability to analyze long paths across the available population more important.
Lawful information sharing can also extend a bank’s view beyond its own records. In the United States, Section 314(b) of the USA PATRIOT Act supports voluntary information sharing between eligible participating financial institutions for specified AML/CFT purposes, subject to safeguards.[7] In the EU, Article 75 of Regulation (EU) 2024/1624 provides a framework for information-sharing partnerships, applicable to banks from 10 July 2027, with strict necessity and data-protection requirements.[8]
Information obtained through these channels may supply a missing account, transaction or ownership link. The bank can then examine how it connects to its own customers and transactions, including accounts outside the original investigation. Those connections may emerge only after several steps. Additional information therefore strengthens the case for deep traversal across the full dataset available for the inquiry, subject to the applicable limits on use.
| Customer bank | Customer accounts and counterparties |
| Correspondent/intermediary | Additional settlement and technical layers |
| FIU / related agency | Cross-institution records, subject to mandate |
Figure 2. The institution’s role changes the scope of available relationships. These are differences in data coverage, not measured hop counts or a ranking of case complexity.
5. Source: Link6. Source: Link7. Source: Link8. Source: Link
In one of the bank investigations I’ve tracked, reconstructing an intermediary payment required around 16 steps through accounts and accounting entries.
The bank could not interpret the connected activity across the full population. Review was limited to transactions alerted by flat rules without network context; analysts received a separate Excel extract for each alert. It includes the names of the originator and beneficiary, a second originator and beneficiary, and a dozen or so technical accounts. To understand the full picture, the bank had to link these accounts and trace the transactions across multiple steps. Relevant data existed, but the bank could not use the relationships systematically. That gap can leave compliance-relevant activity outside review. The accounting steps were not separate acts of laundering.
For an FIU, the same problem can span several banks and jurisdictions. The scope varies by country, but the analytical task extends beyond reconstructing one alerted payment. Latvia’s FIU, for example, obtained one bank’s complete transaction history for a five year period and consolidated customer KYC, declared UBOs, and transaction IP addresses.[4] This wider view creates more opportunities to connect flows, provided the analysis can follow the resulting paths at scale.
FIU case:
In a confidential client case, a DataWalk customer traced 28 domestic transfer steps and helped block €5 million. The chain continued to the United States, where the FBI blocked further funds.
4. Source: Link
Why deep traversal needs the full dataset
Relevant accounts may sit several payment steps away from the starting account and outside the original case extract. A bank needs sufficient depth to reach them and sufficient data coverage to preserve the connecting relationships. Limiting the analysis to accounts already under investigation can remove the very records needed to establish their wider connections.
Here, the full dataset means all records available and permitted for the inquiry remain in scope, subject to its filters. A traversal can begin with one account or a defined group and continue through every qualifying result at each step. It need not visit every record or begin from every account simultaneously.
Follow connected sets across the available data
- Start with higher-risk accounts
Group outgoing payments by external recipient. Retain the contributing accounts, payment count, and total value for a defined time window.
- Compare the next recorded stage
Match that recipient’s identifier to subsequent payments into the bank. Compare totals in a consistent currency and time window, for example allowing up to 10% less, then tightening to 5%. Similar amounts alone do not establish a flow.
- Continue through the available records
Repeat through internal accounts and recorded external counterparties until no qualifying continuation remains or the time window ends. Retain transaction identifiers to prevent double-counting.
- Handle highly connected accounts explicitly
Flag technical and settlement hubs. Document any exclusions and retain the excluded set for review. A busy account can still be relevant.
- Compare higher-risk and lower-risk populations
Repeat from lower-risk accounts and intersect the results to find common recipients or intermediaries. Follow those objects into KYC or ownership records, then return to related payments and test the revised question.
Each step operates on the full qualifying set, including accounts with no alert history. The steps illustrate traversal, filtering and comparison of connected sets across the available records. The complete workflow was not measured in the benchmark.
The analyst needs to follow those findings, change the criteria and examine the resulting groups of accounts without commissioning a new data extract for every step. This is where understanding one investigation becomes an architectural requirement: the bank needs to explore relationships across the available population as the question develops.
Going beyond four hops requires the right architecture
The workflow above changes the records being examined as new connections emerge. If each revision needs a new extract or a specially tuned query, the analysis becomes a sequence of engineering requests. Teams can end up limited to the questions prepared in advance.
DataWalk connects records in a shared knowledge graph where analysts
whole sets. Each result feeds the next step without an engineer writing every query. Matching and business rules define relationships that can be stored and reused.
A payment can be followed between accounts, examined by amount and time, and connected to a device, document or investigation. DataWalk calls this approach Connecting Sets: the same payment works as both a traversable connection and an object for further analysis.
The benchmark below measures a core operation needed for this work: following many successive payment relationships from a starting account in a large graph. The reported result uses the internal booking graph within the 20 TB dataset.
A DataWalk example:
The timing is the median of ten complete requests counting accounts reached from one seed, using synthetic data, one virtual user and warmed local storage. This demonstrates deep traversal under the tested conditions. It does not establish performance for starting from every account simultaneously or for the complete analytical workflow above. Cost depends on the connected data reached as well as depth.
AI agents depend on the same capability
An agent can propose the next question, revise conditions, and follow results. The execution engine must calculate the paths, filters, and intersections over the data. If every revision needs engineers to optimize a query, the agent hits the same bottleneck as the analyst. Agents need governed access to these operations, supporting records and human review; this benchmark did not test agent detection performance.
For a Head of Financial Crime, the practical test is whether this capability identifies additional accounts that warrant investigation across the customer population, including accounts that existing rules have never flagged.
DataWalk Platform
See DataWalk in action
Request a personalised live demo and discover how DataWalk connects the dots across your data.