Financial Crime & Fraud Analytics
An end-to-end transaction monitoring case study focused on detecting, prioritising and investigating unusual customer behaviour using behavioural baselines, calibrated thresholds and transaction-network analysis.
the 30-second version
Problem
Spot potentially suspicious behaviour across 50,000 transactions and 2,500 customers, without treating a rule match as proof that laundering occurred.
What I built
A rule-based monitoring workflow: customer behaviour profiling, calibrated detection thresholds, behavioural alert rules and risk-based case prioritisation for investigation.
Results
50K
Transactions
2.5K
Customers
2,007
Alerts
1,366
Cases
33
Critical cases
Rule-based red flags support investigation prioritisation; they do not determine whether laundering occurred.
Skills demonstrated
what was actually being investigated
I built a rule-based transaction monitoring workflow that turns raw transaction data into customer behaviour profiles, generates alerts and prioritises investigation cases using thresholds calibrated from the data itself.
Methodology note
I did not use the dataset's laundering labels as the analytical answer. I developed detection logic independently from customer behaviour and transaction patterns.
Brief_01
Brief_02
Brief_03
Brief_04
behaviour > isolated transactions
50K
Transactions analysed
2.5K
Customer profiles
3
Behavioural detection rules
2,007
Alerts generated
1,366
Investigation cases
33
Critical cases
I built an end-to-end behavioural transaction monitoring workflow that compares customer activity against expected and historical behaviour, generates rule-based alerts, consolidates them into investigation cases and assigns risk-based case priority.
Detection Pipeline
Every stage below is covered in detail further down this page, from how I profiled customer behaviour through to how I checked the rule-based prioritisation against the dataset's ground truth.
nine stages, one investigation
End-to-end pipeline
Customer profiling
I used expected monthly volume and customer attributes to establish behavioural context.
source: customer_profile.py
Behavioural baseline
I aggregated transactions by customer and month to build a behavioural baseline for every account.
source: monthly_behavior.py
Feature engineering
Seven behavioural metrics per customer-month: total volume, transaction count, average and maximum amount, unique receivers, and volume/maximum vs expected.
source: behaviour_features.py
seven signals, one profile
Calibration
I derived thresholds from empirical distributions rather than picking them manually.
source: threshold_calibration.py
Investigation
I reviewed triggered customers using transaction patterns, timing, counterparties and customer context.
source: case_review.py
rules flag, investigators decide
three signals. three different behaviours.
Customer activity was first normalised against each customer's own expected monthly volume. The anomaly threshold was then derived from the portfolio-level distribution of these behavioural ratios, set at the 95th percentile (≈3.82×).
Metric
total_monthly_volume / expected_monthly_volume
Alerts
723
one threshold, drawn from portfolio-wide behaviour, not set per customer
Compares a customer's largest single transaction in a month against their expected monthly volume.
Metric
largest_transaction / expected_monthly_volume
Alerts
723
95th percentile of observed customer-month behaviour
Compares a customer's current cross-border transaction ratio against their own historical baseline. A spike signals a behavioural change, not that cross-border activity is inherently suspicious.
Metric
current_cross_border_ratio - historical_cross_border_average
Alerts
561
alerts when cross-border share rises more than 40 points versus the customer's own baseline
this is where money moves, not just grows
Threshold Calibration
not guessed. measured.
Rather than picking round numbers by intuition, I first normalised each customer's monthly activity against their own expected_monthly_volume, then calibrated two of the project's three detection thresholds from the portfolio-level distribution of these behavioural ratios. The third rule, CROSS_BORDER_SPIKE, uses a fixed percentage-point threshold instead, covered in Detection Rules above.
HIGH_MONTHLY_VOLUME threshold
3.82×
LARGE_SINGLE_TXN threshold
2.58×
I set both ratio-based thresholds at the 95th percentile of the portfolio-level distribution of these ratios — one threshold, applied across all customers, not calibrated individually per customer.
Observed behavioural ratios
Distribution
95th percentile, both ratio-based thresholds sit here
Detection quality is a trade-off, not a single number.
Alert → Case Consolidation
2,007
Alerts generated
1,366
Investigation cases
Multiple alerts for the same customer and month are consolidated into a single investigation case:
cases triggered exactly one detection rule
cases triggered two of the three detection rules
cases triggered all three detection rules
The number of triggered rules adds useful context for prioritisation, but it does not by itself determine whether the underlying activity represents financial crime.
More triggered rules did not automatically mean more risk.
Case Prioritisation
For every triggered rule, I calculate how strongly the observed behaviour exceeds its detection threshold. I use the strongest of those ratios across all triggered rules, the maximum threshold ratio, to derive the case's severity.
Prioritisation logic
threshold_ratio =
metric_value / threshold
Severity levels
Final case priority distribution
33
Critical
104
High
302
Medium
927
Low
Featured Investigation
Profile Deviation
C01222 processed €131,303.18 in May 2026 against an expected monthly volume of just €1,906.46.
Expected monthly activity
Transaction Concentration
A single transaction of €128,755.50 accounted for most of the observed volume on its own.
€128.8K
Largest transaction
Expected monthly volume
Risk Assessment
Triggered rules
Analyst Interpretation
C01222 displayed an extreme deviation from its expected monthly activity. The account processed €131.3K during May against an expected monthly volume of approximately €1.9K, with a single €128.8K transaction accounting for most of the observed volume. The combination of extreme profile deviation and transaction concentration justified critical-priority review.
“These indicators identify unusual behaviour and prioritise the case for investigation; they do not independently establish money laundering.”
Investigation Exhibit / Contrast Case
Expected monthly volume
January 2026 volume
Volume vs expected
Largest transaction
Largest transaction vs expected
Largest transaction share of monthly volume
This case produced an extreme monthly-volume alert, with nearly all activity concentrated in a single transaction, a pattern also seen in C01222, though at roughly half the magnitude (33.66× versus 68.87× expected volume). The same combination of triggered rules does not always mean the same underlying severity.
Investigation Workflow
Rules identify unusual behaviour. Investigation determines whether the activity is explainable, requires enhanced review or should be escalated.
rules flag, humans decide
Post-analysis / Findings
Note_01
context > raw amount
Note_02
signal count is not severity
Good transaction monitoring is not about generating more alerts.
It is about generating better decisions.
Note_03
percentile-based, not guessed
Note_04
same alert, different story
Note_05
detect → review → calibrate → repeat
what changed after looking closer
Post-Analysis Validation
I did not use the dataset's laundering labels to build the detection rules or calibrate the underlying behavioural features. I used them only afterwards, to evaluate how well the rule-based case prioritisation aligned with the dataset's ground truth.
Calibration logic
predicted_suspicious =
max_threshold_ratio >= threshold
I used ground-truth laundering labels only after rule generation, for validation and calibration, not to build the detection rules.
Precision vs recall
Calibration chart
Selected threshold 3.0×·Precision 72.1%·Recall 51.5%
Chosen operating point
Raising the threshold improves precision but reduces recall, illustrating the operational trade-off between alert quality and detection coverage. I selected threshold 3.0× as the working threshold for this project, not because it is universally optimal, but because it balanced alert quality against case coverage for this dataset.
In-sample calibration
The 3.0× operating point was selected during post-analysis calibration on the available labelled dataset. These metrics therefore represent in-sample calibration performance rather than expected production performance on unseen transactions.
Next Validation Step
A stronger, production-style evaluation would use a temporal holdout: thresholds selected using only a development period, then precision and recall reported on a separate holdout period of previously unseen transactions.
Operating Point / Threshold 3.0
better coverage, still selective
After calibration, I correctly flagged 176 of the dataset's labelled laundering cases while maintaining 72.1% precision and improving recall to 51.5%.
I set the final threshold to prioritise broader coverage of labelled laundering cases, without creating an unmanageable alert queue.
In-sample calibration performance on the available labelled dataset, not a projection of performance on unseen transactions.
Precision
72.1%
Recall
51.5%
Evidence counters
laundering correctly prioritised
normal case prioritised
laundering not prioritised
normal case correctly left below threshold
Confusion matrix
Predicted
normal
Predicted
suspicious
Actual
normal
956
68
Actual
laundering
166
176
176
caught
68
false alarms
166
missed
956
correctly ignored
By recalibrating the threshold, I turned a high-precision, low-recall system into a more balanced monitoring workflow.
Threshold 5.0 → 81.1% precision / 28.9% recall
Threshold 3.0 → 72.1% precision / 51.5% recall
Review Notes
good systems evolve
Capabilities
Transaction Monitoring
Behavioural Analytics
Threshold Calibration
Alert Prioritisation
Network Analysis
Risk-based Investigation
This project demonstrates my ability to translate transaction data into monitoring logic, investigate behavioural anomalies and communicate risk findings in a structured Financial Crime workflow.
Case status
Case 001 / FinCrime Analytics Lab
Built to detect unusual behaviour.
Calibrated to make better decisions.
From raw transactions to behavioural monitoring, alerts, case prioritisation and threshold calibration.
Case 001
AML Transaction Monitoring Engine
Status
Calibrated
Stack Python · Pandas · AML Analytics
case closed.