TYPE_01
COLLECTION ACCOUNT
High fan-inConcentrates funds received from a wide, largely unrelated base of senders.
CASE 002
Financial Crime Analytics · Network Analysis
AML Network & Flow Analysis
PythonPandasNetworkXMatplotlibGraph Analysis
Case status: Investigation complete · validation pendingA transaction-network investigation that treats transactions as a directed graph, surfacing suspicious account relationships, concentration and dispersion patterns, rapid movement of funds, and potentially circular transaction flows.
“follow the connections, not just the transaction.”
01 — Case Overview
Following the Money Through the Network
Traditional transaction monitoring evaluates individual transactions or customer behaviour. I extended that analysis by treating transactions as a directed network, so I could investigate suspicious relationships and the movement of funds between accounts.
My objective was to identify accounts behaving as collection points, dispersion accounts, intermediaries or network hubs, without using the dataset's laundering labels to define the detection logic.
the account, not just the transaction
Case File / Network Analysis
- Case type
- Network & Flow Analysis
- Data
- 50,000 transactions · 2,500 customers
- Method
- Graph-based behavioural detection
- Tools
- Python · Pandas · NetworkX
02 — Building the Transaction Network
Every account is a node. Every transaction, an edge.
- Each customer account becomes a node.
- Each sender → receiver relationship becomes a directed edge.
I aggregated edges using
Transaction countTotal volumeAverage amountFirst transactionLast transaction
C00124 → C01016 → C00821 ↘ C01420
03 — Fan-In / Fan-Out
Concentration, meet dispersion
FAN-IN
MANY → ONEMetrics tracked
- Unique senders
- Incoming transaction count
- Incoming volume
Unusually high fan-in may indicate a collection or aggregation account.
FAN-OUT
ONE → MANYMetrics tracked
- Unique receivers
- Outgoing transaction count
- Outgoing volume
Unusually high fan-out may indicate dispersion of funds across multiple accounts.
Detection threshold
Exploratory threshold28
unique counterparties, applied to both unique senders and unique receivers, per account.
Set manually as an exploratory project cutoff, not statistically derived from the portfolio's counterparty-count distribution. A production system would calibrate this threshold empirically instead of setting it by hand.
04 — Rapid Pass-Through Flow
Funds that don't stay long
I searched for accounts that receive funds, send a similar amount shortly afterwards, and repeat this behaviour multiple times.
This analysis measures behavioural flow-through at account level; it does not perform transaction-level tracing of identical funds.
- Timing
- outgoing transaction within 6 hours
- Amount match
- 80% – 105% of incoming amount
- Repetition
- minimum 4 events
- Cluster window
- maximum 3-day span
in and out, before the trail goes cold
Account A
↓ €9,500
Intermediary
↓ €9,200
Account B
TIME · 2.4HFLOW RATIO · 96.8%
potential pass-through behaviour
Illustrative visualisation only, not a dataset finding.
05 — Network Typologies
Classifying the behaviour
TYPE_02
DISPERSION ACCOUNT
High fan-outDistributes funds outward across a wide, largely unrelated base of receivers.
TYPE_03
NETWORK HUB
High fan-in + high fan-outBoth concentrates and disperses funds, a structural chokepoint in the network.
TYPE_04
PASS-THROUGH / INTERMEDIARY
Repeated rapid movement of similar amountsReceives and forwards comparable amounts in short succession, repeatedly.
TYPE_05
HIGH-CONNECTIVITY PASS-THROUGH
High fan-in + high fan-out + rapid flowCombines structural centrality with rapid pass-through behaviour, the highest-priority typology.
06 — Graph Analysis
Beyond simple aggregation
- Betweenness centrality
- I used this to identify accounts positioned between different parts of the transaction network.
- Community detection
- I used greedy modularity to identify clusters of strongly connected accounts.
- Directed graph
- I built the network using NetworkX as a directed graph, with transaction volume and transaction count stored on each edge.
07 — Circular Flow Detection
When money comes back around
2-Node Return Flow
Money returning within 24 hours, where the returned amount represented roughly 80–120% of the original.
Illustrative diagram of the detection logic, not a matched instance from the dataset.
3-Node Cycle
Temporally ordered three-account cycles completing within 72 hours, with each subsequent amount within 80–120% of the initial one.
Illustrative diagram of the detection logic, not a matched instance from the dataset.
Detection outcome
The detection logic was implemented, but no qualifying circular flow meeting the defined conditions was identified in this dataset.
connectivity alone isn't evidence; timing and amount are
08 — Network Risk Model
Scoring the behaviour, not just flagging it
Each rule contributes a fixed, interpretable weight rather than a learned probability — a simple, auditable score built for prioritising investigation, not a statistically fitted risk model.
score = fan_in(+1) + fan_out(+1) + rapid_flow(+3) + betweenness(+2)
Scoring logic
- High fan-in
- +1
- High fan-out
- +1
- Repeated rapid flow
- +3
- High betweenness
- +2
The weighting is a project-specific prioritisation heuristic designed for analytical experimentation, not a production AML risk model.
Priority bands
0
No Priority
1
Low
2–3
Medium
4–5
High
6+
Critical
09 — Case Investigation
Case #C01016
Critical Network Case
Investigation File / C01016
36
Inbound counterparties
28
Outbound counterparties
€239.2K
Inbound volume
€224.5K
Outbound volume
93.8%
Flow-through ratio
99.96th
Betweenness percentile
7 / 7
Network risk score
CRITICAL
Priority
Exhibit / Ego Network
Investigated customerFlagged counterpartyOther counterpartyTransaction direction
Node size reflects account priority. The investigated customer is drawn largest, flagged counterparties larger than ordinary ones.
Bolder edges mark the specific flow path under investigation, not transaction volume.
Illustrative ego-network view: only the focus account and flagged counterparties are labelled, to avoid clutter.
Network Profile
C01016 interacted with 36 unique inbound and 28 unique outbound counterparties, both at or above the project's high-connectivity detection threshold of 28 unique counterparties (Section 03).
Flow Behaviour
The account received €239,248.64 and sent €224,521.44 onward. That works out to an aggregate flow-through ratio of 93.8%, not a claim that the same funds moved on, but a sign that outgoing value closely tracked incoming value over the period. The account also triggered the REPEATED_RAPID_FLOW rule.
Network Position
- Betweenness percentile
- 99.96th
- Community
- 9
A betweenness percentile this high means C01016 sat in an unusually central intermediary position within the transaction network, a structural pattern worth investigating on its own, not proof of laundering.
Risk Assessment
- Network risk score
- 7 / 7
- Priority
- Critical
- Case type
- High-Connectivity Pass-Through
Triggered rules
Analyst Interpretation
C01016 combines unusually high inbound and outbound connectivity with repeated rapid movement of funds and an extremely high network-centrality position. The combination of these indicators makes the account a strong candidate for enhanced investigation as a potential intermediary or pass-through account.
“These network indicators identify unusual transaction behaviour and prioritise the account for review; they do not independently establish money laundering.”
Full investigation framework
The case above surfaces the headline figures for C01016. The framework below is the full set of criteria the investigation evaluates for every flagged account.
Incoming counterparties
Unique accounts sending funds to the account.
Outgoing counterparties
Unique accounts receiving funds from the account.
Incoming volume
Total value of funds received.
Outgoing volume
Total value of funds sent onward.
Overall flow ratio
Outgoing volume relative to incoming volume.
Network risk score
Combined score from the scoring framework above.
Network case type
Typology classification, such as collection, hub, pass-through, and so on.
Betweenness centrality
The account's position between other parts of the network.
Community membership
The cluster the account belongs to, from community detection.
Triggered network rules
Which network detection rules the account crossed.
10 — Validation
Checking the method against the answer key
I intentionally excluded the laundering labels supplied with the synthetic dataset from the network-risk detection logic. I built the rules and scoring model entirely from transactional network behaviour, not from the labels themselves.
True Positives
Flagged accounts that were also labelled as involved in laundering.
False Positives
Flagged accounts that were not labelled as suspicious.
False Negatives
Labelled laundering accounts the network model did not flag.
Precision & Recall
The trade-off between flagging accurately and flagging completely.
Independent validation layer
I used the dataset labels only after completing the network detection workflow, as an independent validation layer. I based the detection logic itself entirely on transactional network behaviour and did not train it on the provided labels.
Validation Roadmap
Quantitative network-model validation has not yet been completed. The planned next steps are:
- Evaluate individual rule precision / recall where labels permit
- Evaluate combined alert logic
- Confusion matrix
- Threshold sensitivity analysis
- Compare risk-score cutoffs
- Analyse false positives and missed labelled cases
Capabilities
What This Investigation Demonstrates
01
Transaction Network Analysis
Moving beyond isolated transactions to analyse relationships between accounts.
02
AML Typology Design
Translating patterns such as collection, dispersion, pass-through and circular flow into detection logic.
03
Graph Analytics
Using directed networks, centrality and community detection to investigate financial flows.
04
Detection Engineering
Building thresholds, flags, scoring logic and prioritisation rather than simply visualising data.
05
Analytical Validation
Separating detection methodology from labelled ground truth and evaluating performance afterwards.
This project demonstrates my ability to move beyond isolated transaction analysis into network-based investigation: designing typologies, engineering detection logic, applying graph analytics and validating methodology against real-world evaluation concepts, within a Financial Crime & AML context.
Case status
Case 002 / Network Analytics Lab
Built to trace connections.
Calibrated to prioritise the ones that matter.
From a directed transaction graph to typology classification, risk scoring and network detection logic, pending quantitative validation.
Case 002
AML Network & Flow Analysis Engine
Status
Investigation complete · validation pending
Stack Python · Pandas · NetworkX · Graph Analytics
Investigation complete11 / 11
quantitative validation pending.