BSA/AML Transaction Surveillance Pipeline

The Bank Secrecy Act requires financial institutions to maintain programs that detect and report suspicious activity indicative of money laundering, terrorist financing, fraud, and other financial crimes. In practice, most institutions rely on transaction monitoring systems that apply static threshold rules—transactions exceeding $10,000, wire transfers to high-risk jurisdictions, cash deposits just below reporting thresholds—to generate alerts for compliance analyst investigation. These rule-based systems produce false positive rates of 95-98%: for every 100 alerts generated, 95-98 are closed as non-suspicious after investigation, wasting thousands of analyst hours monthly and creating a needle-in-a-haystack problem that causes genuinely suspicious activity to be missed or under-investigated.

Money laundering techniques have evolved far beyond the simple structuring and smurfing patterns that rule-based systems were designed to detect. Modern laundering typologies exploit trade-based value transfer (over- and under-invoicing of goods), funnel account networks (accounts receiving deposits from multiple geographic areas and immediately wiring funds overseas), nested correspondent banking relationships, and layered transactions through shell companies. FinCEN typologies guidance (FIN-2014-A007 through FIN-2021-A004) documents dozens of patterns that require behavioral analysis, network mapping, and temporal pattern recognition that static threshold rules cannot perform. Examiners from the OCC, FDIC, and state banking departments increasingly expect institutions to demonstrate that their monitoring systems can detect these complex typologies, not just the basic scenarios that were sufficient a decade ago.

The SAR filing process itself is a significant operational bottleneck. After an analyst determines that activity is suspicious, drafting the SAR narrative—a detailed, factual description of the suspicious activity, the subjects involved, and the basis for suspicion—requires 2-4 hours of writing per filing. The narrative must meet FinCEN quality standards: it must describe the 5 W's (who, what, when, where, why), reference specific transaction details, explain why the activity is inconsistent with the customer's known profile, and avoid conclusory language (stating suspicion, not guilt). Many institutions accumulate backlogs of hundreds of pending SARs, creating regulatory risk and reducing the intelligence value of the filing to law enforcement, which depends on timely SAR data to build cases.

The surveillance pipeline ingests transaction data from core banking systems, payment platforms, wire transfer systems, and digital banking channels via Apache Kafka, normalizing disparate data formats into a unified transaction event model. Apache Flink streaming jobs apply the first detection layer: scenario-based rules implementing the FinCEN typologies that examiners expect to see covered (structuring, rapid movement, funnel accounts, high-risk jurisdiction activity, cash-intensive business anomalies). These rules are parameterized and configurable via a compliance analyst interface, with parameters tunable by customer segment, product type, and risk rating—avoiding the one-size-fits-all thresholds that drive excessive false positives in legacy systems.

The second detection layer applies machine learning models trained on the institution's historical alert dispositions and SAR filing decisions. A gradient boosting model (XGBoost) operates on customer-level behavioral features: transaction velocity, counterparty diversity, geographic dispersion, deviation from historical patterns, and peer group comparison metrics. A separate graph neural network analyzes the transaction network, identifying clusters of accounts that exhibit coordinated behavior (synchronized deposits, sequential transfers, shared counterparties) characteristic of laundering networks. The graph model processes a rolling 90-day transaction graph stored in Neo4j, with community detection algorithms (Louvain) identifying tightly connected account clusters and centrality metrics flagging accounts that serve as hubs or bridges in suspicious networks. ML-generated alerts include explainability outputs (SHAP values for the XGBoost model, subgraph visualizations for the graph model) that enable analysts to understand why the model flagged the activity.

The case management and SAR filing module provides an end-to-end workflow from alert generation through SAR submission. Alerts are deduplicated, prioritized by a composite risk score (combining rule severity, ML confidence, and customer risk rating), and assigned to analysts based on workload balancing and specialization (some analysts specialize in trade-based laundering, others in digital currency activity). The investigation workspace presents a unified view of the customer: KYC documentation, account opening information, transaction history with interactive timeline and network visualizations, prior alerts and SARs, and negative media screening results. When the analyst determines a SAR filing is warranted, the system generates a draft SAR narrative using a template engine that populates transaction details, subject information, and typology-specific language from the investigation findings. The analyst reviews and edits the narrative, then the system files the SAR electronically via FinCEN's BSA E-Filing system, tracks the filing confirmation, and maintains the complete audit trail required for examiner review.

The streaming detection pipeline processes transactions through Apache Flink with event-time semantics and watermark-based windowing. Structuring detection uses a tumbling window of 1 banking day per customer, aggregating cash transactions and comparing the daily total against the $10,000 CTR threshold while simultaneously evaluating individual transaction amounts for just-below-threshold patterns (transactions between $9,000 and $9,999 occurring with frequency inconsistent with the customer's historical cash activity). Rapid movement detection uses a session window with a 24-hour gap: when a customer receives funds and moves them to a different account or beneficiary within the session window, the rule evaluates the percentage moved, the relationship between sender and receiver, and the customer's historical hold-time patterns. Each rule outputs a detection event with a severity score, the matched typology code (mapped to FinCEN's typology taxonomy), and the specific transactions that triggered the rule.

The XGBoost behavioral model is trained on 36 months of historical alert data with analyst dispositions as labels (SAR filed = positive, closed non-suspicious = negative). Feature engineering produces 180+ features per customer-month, grouped into categories: velocity (transaction count, total amount, unique counterparties per day/week/month), volatility (standard deviation of transaction amounts, coefficient of variation in daily balances), geographic (unique originating/beneficiary countries, percentage of transactions involving FATF grey/black list jurisdictions), channel (ratio of wire to ACH to digital, off-hours transaction frequency), and peer comparison (z-scores of key metrics compared to customers in the same segment, product type, and risk tier). The model is retrained monthly on a rolling 36-month window, and model performance is tracked via precision-recall curves, with a minimum recall threshold of 0.85 on known SARs enforced as a deployment gate. SHAP (SHapley Additive exPlanations) values are computed for each prediction, and the top 5 contributing features are included in the alert detail to support analyst investigation.

The graph neural network operates on a heterogeneous transaction graph where nodes represent accounts and edges represent fund flows, with edge attributes encoding transaction amount, channel, timestamp, and purpose code. The model architecture uses a Graph Attention Network (GAT) with 3 attention heads and 2 convolutional layers, trained to predict SAR-associated nodes using a semi-supervised approach (only a fraction of nodes have SAR labels). At inference time, the model produces a suspicion embedding for each account that captures both its individual behavior and its structural position in the transaction network. Community detection (Louvain algorithm at multiple resolution parameters) identifies clusters of accounts with dense internal connectivity and sparse external connections—a signature of layering networks. Bridge accounts (high betweenness centrality connecting otherwise separate communities) are flagged as potential funnel accounts. The graph is materialized in Neo4j with incremental updates as new transactions arrive, and the GNN inference runs daily on the updated graph, with results merged into the alert stream alongside rule-based and XGBoost-generated alerts.