Abstract

A growing number of financial crime compliance platforms support batch and streaming processing paradigms with event-driven architectures and streaming models servicing the streaming capability. The question arises as to whether these streaming capabilities should be deployed to complement or replace the batch processing capability. In batch implementations, transaction data produced in one period—typically daily—serves as the basis for detecting money laundering activity. Event-driven architectures also support near-real-time money laundering detection by examining transactions within windowed timeframes, thereby producing results sooner. Nevertheless, two latent data behaviours may undermine detection effectiveness. First, transaction data within a batch window may be stale, which is not true for transactions produced in a streaming architecture. Second, a very small percentage of transaction data, by design, is ungated by having an attached backtesting period. These behaviours can be the focus of successive stages of a multi-stage detection or AML programme; however, when they are not done or when their underlying pipelines cannot keep up with demand, extra transactions may be routed through money laundering detection models early but without the gating. A comparison of an event-driven architecture with a batch-process architecture of a compliance platform shows differential effects on detection timeliness, coverage, false positives, false negatives, and the detection-validation process. The event-driven architecture also offers the potential for deployment with more resilience to operational impact from the failure of external systems, such as core-banking systems. However, operational resilience can come with increased operational complexity, and, depending on the detection models employed, such models may incur higher processing costs. Such trade-offs as detection effectiveness—timeliness, coverage, false positives, false negatives, and the validation process—and operational resilience—fault tolerance; deployment complexity; ongoing operational costs; and facilitation of operational maintenance—can help guide decisions regarding the streaming capability. Keywords: Anti-Money Laundering (AML) Platforms, Event-Driven Compliance Architectures, Batch vs. Streaming Processing, Near-Real-Time Transaction Monitoring, Financial Crime Detection Systems, Multi-Stage Detection Pipelines, Detection Timeliness and Coverage, False Positive and False Negative Management, Streaming Analytics for Compliance, Windowed Transaction Analysis, Operational Resilience in Compliance Systems, Fault-Tolerant Detection Architectures, Detection Model Validation, Data Freshness in AML Pipelines, Gating and Backtesting Strategies, Scalable Compliance Engineering, Deployment Complexity Trade-Offs, Cost-Aware Detection Models, Core Banking System Integration, Enterprise RegTech Platforms

Keywords

  • Financial Crime Compliance
  • Batch-to-Streaming