AML / Transaction Monitoring Lakehouse
Self-initiated practice project — not real client work. End-to-end synthetic AML screening pipeline: IBM-labeled laundering typologies (smurfing, layering, structuring) cross-referenced against live OFAC, EU, and UN sanctions lists in a medallion lakehouse, built to learn and demonstrate production-style compliance architecture.
The problem
Production AML systems cross-reference high-volume transaction streams against live sanctions watchlists and flag known laundering typologies in near real-time. Building a credible portfolio demonstration of this requires realistic transaction data with labeled patterns, live-updateable sanctions data from authoritative sources, and a layered data architecture that mirrors how real compliance teams structure their pipelines.
The data combination that makes this work: IBM's AML dataset provides labeled smurfing, layering, and structuring patterns across a synthetic bank network — the same dataset academic AML research cites as the gold standard. OFAC, EU, and UN sanctions lists are real, legally usable public data pulled live via official APIs — the same lists a bank's screening engine checks daily.
Pipeline architecture
Medallion lakehouse: five stages from raw source ingestion to compliance-ready outputs.
Layer breakdown
Bronze — Raw Ingestion
Raw transaction records from PaySim and IBM AML land here unchanged. Sanctions lists (OFAC, EU, UN) are pulled on a schedule via their official APIs and stored as-is, preserving the source-of-truth snapshot for audit.
Silver — Python Transforms
Python scripts clean, type-cast, and conform transactions into fact_transactions and dim_accounts. The three watchlists are deduplicated and merged into consolidated_watchlist with a source tag — one table for the screening engine.
Gold — AML Logic
Business-logic models run velocity checks, round-trip detection, and near-threshold structuring flags. Sanctions name-matching was demonstrated with a small set of hand-coded test entities — the IBM dataset does not contain real names, so a full watchlist screening run was not possible. FATF country codes are applied as a jurisdiction risk overlay.
Power BI — Monitoring
Power BI connects directly to the Gold layer via Microsoft Fabric, surfacing alert volume by typology, sanctions hit rate, FATF jurisdiction exposure, and a live alert queue with risk-tier badges.
AML rule engine — typology detection
Structuring
- ›Transactions just below reporting thresholds ($10k)
- ›Multiple sub-threshold transactions by same account in 24h
- ›Cross-account structuring (same beneficiary)
Layering
- ›Rapid sequential fund movements A→B→C→D
- ›Round-trip detection (funds return to origin)
- ›High-velocity account with no matching business profile
Smurfing
- ›Coordinated small deposits across multiple accounts
- ›Aggregation patterns converging to single beneficiary
- ›Timing correlation across linked accounts
Sanctions screening design
OFAC SDN, EU Consolidated, and UN Security Council lists are downloaded daily via their official XML/CSV feeds and landed in the Bronze layer. A Python script merges them into a single consolidated_watchlist table with a source column for attribution. The IBM AML dataset does not include real company or individual names, so a full production-style name-screening run was not possible. Instead, sanctions matching was demonstrated using a small set of hand-coded test entities run through Jaro-Winkler similarity against the consolidated watchlist — enough to validate the pipeline logic without misrepresenting the dataset's scope. FATF high-risk country designations are applied as a jurisdiction risk overlay — flagging transactions that touch countries on the FATF grey or black list regardless of whether they hit a named entity.
Monitoring dashboard
Power BI connects to the Gold layer via Microsoft Fabric. Live alerts, typology breakdown, and sanctions-hit source distribution.
* Illustrative mockup — not a live dashboard. Data shown is synthetic (IBM AML Dataset + PaySim).
The approach
The pipeline uses IBM's AML dataset (which includes labeled smurfing, layering, and structuring patterns) and PaySim synthetic transactions as source data. Raw data lands in a Bronze layer, then Python scripts clean and conform it into Silver (fact_transactions, dim_accounts, consolidated_watchlist). The Gold layer runs the AML logic: velocity rules, round-trip detection, and near-threshold structuring checks. Note: the IBM dataset does not include real company or individual names, so sanctions name-matching was demonstrated using a small set of hand-coded test entities against the OFAC, EU, and UN watchlists — not a full production screening run. FATF high-risk country flags are applied as a jurisdiction risk overlay. Power BI consumes the Gold layer for monitoring.
Tools & technologies
Key outcomes
- Medallion lakehouse (Bronze → Silver → Gold) ingesting 6M+ synthetic transactions with full lineage.
- Consolidated watchlist merging live OFAC SDN, EU, and UN lists into a single screening table, refreshed on schedule.
- AML rule engine flagging smurfing, layering, and structuring typologies with precision/recall benchmarked against IBM labels.
- FATF jurisdiction risk overlay applied at the transaction level for high-risk country exposure reporting.
- Power BI monitoring dashboard with alert volume, typology breakdown, sanctions-hit rate, and risk heatmap.