Imagine watching a single raindrop fall. It tells you almost nothing. Now imagine watching an entire storm from a satellite, and suddenly a clear, unmistakable pattern — a hurricane — emerges from millions of individual raindrops that, one at a time, looked completely ordinary. Detecting money laundering works the same way. A single transaction of 9,000 rupees sent from one account to another looks completely normal, the kind of thing that happens millions of times a day on any payment platform. But when the same account receives twenty separate 9,000-rupee deposits from twenty different people within three days, and then immediately forwards nearly all of it to an account in another country, a pattern emerges that a single transaction, viewed in isolation, could never reveal.

Money laundering — the process of disguising the origins of illegally obtained money so it appears to come from a legitimate source — has existed for as long as organised crime and financial systems have coexisted. The term itself is said to trace back to the practice of laundromats being used as fronts for illicit cash businesses in the early twentieth century, but the underlying activity, structuring transactions to hide their true origin, is far older. What has changed dramatically is scale and speed. In a paper-based banking era, investigators could review suspicious activity reports manually, over days or weeks. Today, a large digital payment platform processes millions of transactions every single minute, and criminals have adapted their techniques specifically to blend in with this ocean of legitimate activity — breaking large sums into many small transactions, called structuring or smurfing, and routing money through long, complex chains of accounts, called layering, precisely to avoid triggering any single, simple threshold rule.

Regulators worldwide, including bodies like the Financial Action Task Force (FATF), require financial institutions and many payment platforms to actively monitor for these patterns and file Suspicious Activity Reports (SARs) when warranted. Failing to do so is not just a reputational risk; it carries serious legal and financial penalties. This tutorial walks through, piece by piece, how to design a system capable of finding these aggregate patterns — patterns invisible in any single transaction — across the enormous, continuous flood of activity a modern payment platform generates.

1.1 From Manual Review to Automated, Continuous Monitoring

It is worth understanding how this field evolved to appreciate why the architecture in this tutorial looks the way it does. In the earliest era of anti-money-laundering compliance, banks relied almost entirely on branch staff noticing unusual behaviour and filing paper reports — an approach that worked reasonably well when transaction volumes were modest and relationships between a bank teller and a regular customer were personal and direct. As transaction volumes grew through the twentieth century, and especially as electronic banking exploded from the 1990s onward, this manual, relationship-based approach became structurally impossible to sustain; no human reviewer could realistically notice a subtle pattern spread across thousands of accounts and millions of transactions. This drove the industry toward automated, rule-based transaction monitoring systems in the 1990s and 2000s, and more recently toward the combination of streaming analytics, graph-based network analysis, and machine learning covered throughout this tutorial — each evolutionary step driven by the same underlying pressure: transaction volume growing faster than any purely manual or simplistic automated approach could keep up with.

1.2 A Short Timeline of Anti-Money-Laundering Detection

Let’s carefully break down what makes this problem genuinely difficult, and distinct from many of the other systems covered elsewhere in this tutorial series.

2.1 The Core Problem: Signal Hidden in Aggregate, Not in Any Single Event

Unlike fraud detection on a single transaction — where a stolen card number or an impossible travel pattern can sometimes be spotted from that one event alone — money laundering patterns are, by design, invisible at the level of any individual transaction. The signal only exists in the relationship between many transactions: their timing, their amounts relative to known thresholds, the network of accounts involved, and how money flows through that network over hours, days, or weeks. A system that only evaluates transactions one at a time, no matter how sophisticated its rules, will structurally miss this entire category of pattern.

2.2 The Classic Laundering Patterns to Detect

• Structuring, or smurfing: Breaking a large sum into many smaller transactions, each individually below a regulatory reporting threshold, often spread across multiple accounts or time windows to avoid detection.
• Layering: Moving money rapidly through a long chain of accounts, sometimes across many institutions or countries, specifically to obscure the money’s original source before it reaches its final destination.
• Round-tripping: Money that eventually flows back, often through a complex, disguised path, to an account connected to its original sender — sometimes used to fabricate a false paper trail of legitimate business activity.
• Smurf networks or rings: A cluster of seemingly unrelated accounts that, when viewed as a network graph, reveal a tight, coordinated pattern of money moving in and out among themselves, often controlled by a single actor using many different identities.
• Sudden behavioural shifts: An account with years of small, predictable, personal transaction history suddenly beginning to receive and forward large sums in a pattern completely unlike its established behaviour.

2.3 Why This Is Especially Hard at Scale

• Enormous transaction volume: At a scale of millions of transactions per minute, the system must continuously maintain and update behavioural context for an enormous number of accounts simultaneously, not just process each transaction in isolation.
• Time-window reasoning: Patterns unfold over minutes, hours, or even weeks, requiring the system to maintain rolling historical context far beyond a single request-response interaction — unlike many of the other systems covered in this tutorial series.
• Network, not just individual, analysis: Detecting a smurf ring requires understanding relationships between many accounts, a fundamentally different kind of computation than checking one account’s balance or history alone.
• High cost of both false positives and false negatives: Flagging too many legitimate customers as suspicious overwhelms human investigators and damages customer trust, while missing genuine laundering activity carries serious legal and regulatory consequences.
• Adaptive adversaries: Unlike a shipping-cost calculation or a payment retry, the “opponent” here actively studies and adapts to known detection rules, meaning the system must evolve continuously — not be built once and left unchanged.

Let’s design the system, layer by layer, with every box explicitly labelled by the type of component it represents.

3.1 Component-by-Component Explanation

Upstream Payment Platforms

The various transfer, card-processing, and wallet systems within the marketplace or bank generate a continuous stream of transaction events. This monitoring system does not initiate transactions itself; it observes and analyses them as they happen, sitting alongside, not inside, the critical payment path.

API Gateway

The API Gateway authenticates and validates incoming transaction event submissions from upstream systems, as well as serving a separate, lower-volume API used by compliance analysts to query cases and account histories.

Global and Regional Load Balancers

Standard two-tier load balancing — exactly as used throughout this tutorial series — routes ingestion traffic to the nearest healthy region and then evenly across many Stream Ingestion Service replicas within that region.

Stream Ingestion Service

A stateless microservice that validates incoming transaction events for basic structural correctness and publishes them onto the Event Bus. This service deliberately does no analysis itself; its only job is fast, reliable ingestion.

Event Bus

A Kafka cluster serving as the durable, ordered backbone of the entire system. Every transaction event is published here once, and multiple independent downstream consumers — the Real Time Feature Engine and the Data Lake — read from it independently, allowing real-time and batch analysis to proceed without interfering with each other.

Real Time Feature Engine

An Apache Flink cluster, chosen specifically for its strength in stateful stream processing, continuously maintains rolling aggregates for every account: transaction counts and sums over sliding time windows, counts of distinct counterparties, and velocity metrics — updating these figures incrementally as each new transaction event arrives.

Feature Store

A Redis cluster holds the current, low-latency-accessible value of every account’s rolling behavioural features, allowing the Rule Engine to check an account’s recent aggregate behaviour in single-digit milliseconds rather than recomputing it from raw transaction history on every check.

Rule Engine

A stateless microservice that evaluates known structuring and velocity patterns against the current feature values for each account — such as “more than five transactions just below the reporting threshold within twenty-four hours” — flagging candidates for deeper analysis.

Graph Database

A Neo4j cluster stores the transaction network as a graph, where accounts are nodes and transactions are edges. This is essential for detecting layering and smurf-ring patterns, which are fundamentally about relationships and paths between accounts — a kind of query that graph databases are purpose-built to answer efficiently, unlike a traditional relational database.

ML Scoring Service

A stateless microservice hosting behavioural anomaly detection models, combining an account’s rolling features and its position in the transaction graph into a single risk score — catching subtler, less rule-like patterns that a fixed set of hand-written rules might miss.

Case Management Service

Creates and tracks investigation cases whenever a candidate pattern crosses a risk threshold, routing them into a queue for human compliance analysts, and recording every decision made along the way for audit purposes.

Case Database

A PostgreSQL cluster storing the full lifecycle of every alert and investigation — from initial flag through analyst review to final resolution, including a Suspicious Activity Report filing where warranted.

Batch Pattern Mining Service

An Apache Spark cluster that periodically re-analyses the full transaction history stored in the Data Lake, searching for slower-forming, more complex patterns spanning days or weeks that would be impractical to detect purely through real-time streaming aggregation alone.

Data Lake

An object storage cluster retaining the complete, immutable history of every transaction event, serving both the Batch Pattern Mining Service and regulatory record-keeping requirements — which often mandate retaining transaction data for several years.

Monitoring Stack

Prometheus and Grafana track ingestion lag, feature computation latency, and alert volume trends — essential for a system where a silent pipeline failure could mean genuinely suspicious activity goes completely undetected.

3.2 Why This System Sits Beside, Not Inside, the Payment Path

It is worth being explicit about a deliberate architectural choice: this system observes transactions after they have already been authorised and processed by the underlying payment or transfer system, rather than sitting directly in the critical path that decides whether a transaction succeeds. This is different from the fraud detection systems that often do sit directly in the authorisation path, blocking a transaction in real time before it completes. The reasoning is that most laundering patterns can only be confidently identified by looking at aggregate behaviour across multiple transactions, which by definition cannot be known at the moment any single transaction is being authorised. Placing this system alongside the payment path, consuming transaction events after the fact, keeps the core payment systems — covered in earlier tutorials in this series — free to optimise purely for speed and correctness on a single transaction, while this system focuses entirely on the different, aggregate-shaped problem it exists to solve: generating alerts and cases for review rather than blocking decisions in the moment.

Let’s zoom into exactly how a structuring pattern — invisible in any single transaction — is detected across many events over time.

4.1 Maintaining Rolling Windows Incrementally

The Real Time Feature Engine cannot afford to recompute an account’s full transaction history from scratch every time a new transaction arrives; at millions of events per minute, this would be far too slow. Instead, it maintains incremental, sliding-window aggregates using Flink’s native stateful processing capabilities, updating a small, bounded state — such as a count and sum for the last twenty-four hours — with each new event, and automatically expiring old entries as the window slides forward, rather than ever scanning the complete history.

public class StructuringDetectionFunction
        extends KeyedProcessFunction<String, TransactionEvent, StructuringAlert> {

    private transient ValueState<RollingWindow> windowState;
    private static final BigDecimal REPORTING_THRESHOLD = new BigDecimal("10000");
    private static final int MIN_TRANSACTION_COUNT = 5;

    @Override
    public void processElement(TransactionEvent event, Context ctx,
                                Collector<StructuringAlert> out) throws Exception {
        RollingWindow window = windowState.value();
        if (window == null) {
            window = new RollingWindow();
        }

        window.addTransaction(event.getAmount(), event.getTimestamp());
        window.evictOlderThan(event.getTimestamp().minusHours(24));

        boolean belowThreshold = event.getAmount().compareTo(REPORTING_THRESHOLD) < 0;
        boolean nearThreshold  = event.getAmount()
            .compareTo(REPORTING_THRESHOLD.multiply(new BigDecimal("0.9"))) > 0;

        if (belowThreshold && nearThreshold &&
            window.getTransactionCount() >= MIN_TRANSACTION_COUNT) {
            out.collect(new StructuringAlert(event.getSenderId(),
                window.getTotalAmount(), window.getTransactionCount()));
        }

        windowState.update(window);
    }
}

4.2 Network Analysis for Layering and Smurf Rings

Once the Rule Engine flags a candidate account based on its rolling aggregates, it queries the Graph Database to understand that account’s position within the broader transaction network. A query might ask, “find all accounts within three hops that have also received or sent structured-looking amounts within the same time window,” a question that is natural and efficient to express as a graph traversal, but would require many slow, complex joins in a traditional relational database.

MATCH (source:Account {id: $accountId})-[t:TRANSACTED*1..3]-(related:Account)
WHERE t.timestamp > datetime() - duration('P3D')
  AND t.amount < 10000
WITH related, count(t) AS transactionCount, sum(t.amount) AS totalAmount
WHERE transactionCount >= 4
RETURN related.id, transactionCount, totalAmount
ORDER BY totalAmount DESC

4.3 Combining Signals With ML Scoring

Rules alone tend to be either too rigid — missing patterns just outside their exact defined thresholds — or too broad, generating overwhelming numbers of false positives. The ML Scoring Service combines the rule-based signal, the graph network context, and the account’s own long-term behavioural baseline into a single risk score using a supervised model trained on historically confirmed cases, giving compliance analysts a prioritised, ranked queue rather than an undifferentiated flood of equally weighted alerts.

4.4 Choosing Good Features Is Half the Battle

It is worth pausing to appreciate that the quality of this entire system rests heavily on the specific rolling aggregates and network features chosen — not just the sophistication of the rules or model applied on top of them. Useful features for this kind of detection typically go well beyond simple transaction count and sum, including the number of distinct counterparties an account has interacted with in a given window, how tightly clustered the timing of transactions is, whether transaction amounts cluster suspiciously close to known reporting thresholds, and how quickly incoming funds are subsequently forwarded onward (sometimes called funds velocity). Designing this feature set well is genuinely a collaborative effort between engineers who understand how to compute these values efficiently at scale, and compliance domain experts who understand which behavioural signals actually correlate with real laundering activity based on confirmed historical cases — and this collaboration, more than any single clever algorithm, is usually what separates an effective detection system from an ineffective one.

Let’s trace the complete life of a structuring pattern, from the first individually unremarkable transaction to a filed Suspicious Activity Report.

The design target for this system specifies millions of transaction events per minute — roughly 16,700 events per second sustained — with peaks potentially reaching several times that during periods of heavy platform-wide activity. Let’s examine how each layer holds up.

7.1 Partitioning the Streaming Layer by Account

The Real Time Feature Engine partitions its stream processing by account identifier, meaning all events for a given account are always routed to and processed by the same processing task, in order. This is essential for correctness — since rolling aggregates must be updated sequentially per account — and it also naturally enables horizontal scaling: adding more partitions and more Flink task slots spreads the overall workload across more parallel processing units, with each individual account’s state remaining small and independently manageable.

7.2 Keeping the Feature Store Fast

The Redis Feature Store must support extremely fast reads and writes, since every single transaction event triggers both a read of prior state and a write of updated state. It is deployed as a sharded, replicated cluster, with keys distributed by account identifier, and values kept small and bounded — storing only compact rolling summary statistics rather than raw transaction lists — keeping both memory usage and per-operation latency low even at very high throughput.

7.3 Scoping Graph Queries to Stay Fast

Unbounded graph traversals — exploring every possible path with no limit — can become extremely slow on a large, densely connected transaction network. The Rule Engine’s graph queries are deliberately scoped with a maximum hop count, typically two or three hops, and a bounded time window, keeping each individual query fast (typically well under a hundred milliseconds) even though the underlying graph itself may contain many millions of nodes and edges.

7.4 Only a Small Fraction of Traffic Reaches the Expensive Path

Just as earlier tutorials in this series rely on caching to ensure only a small fraction of requests reach the slowest, most expensive layer, this system relies on the Rule Engine’s fast threshold checks to ensure only a small fraction of transactions — typically well under one percent — ever trigger the more computationally expensive graph query and ML scoring steps. This means the vast majority of the millions-per-minute event volume flows through the cheap, purely additive rolling aggregate update, with the heavier analysis reserved for genuinely promising candidates.

7.5 Capacity Planning With Real Numbers

At a sustained rate of 16,700 events per second, with peaks toward 50,000, the Kafka Event Bus — partitioned appropriately across many brokers — comfortably handles this throughput, since Kafka is specifically designed for exactly this kind of high-volume, ordered event streaming. The Real Time Feature Engine’s Flink cluster is sized based on per-partition throughput, typically a few thousand events per second per processing slot, meaning a cluster of a few dozen to a few hundred slots comfortably covers peak load, scaled elastically as traffic patterns vary throughout the day. The Graph Database and ML Scoring Service, receiving only the small filtered fraction of flagged candidates, need to sustain a far lower query rate — often only tens to low hundreds of queries per second even at peak — a comparatively light load given the expensive nature of each individual query.

7.6 A Tiered Approach to Managing Load Under Extreme Spikes

During genuinely extreme traffic events — such as a platform-wide surge well beyond normal peak — it can be useful to design the system with graceful, tiered degradation rather than a single all-or-nothing failure mode. The cheapest, most essential tier — ingesting and durably persisting every transaction event to Kafka and the Data Lake — must never be sacrificed, since this is the permanent record the Batch Pattern Mining Service can always fall back to later. The next tier — updating rolling aggregates in the Feature Store — should be prioritised to stay as close to real time as possible, since this feeds the fastest-acting detection path. The most expensive tier — graph queries and ML scoring for flagged candidates — can, if genuinely necessary under extreme load, tolerate a brief, bounded processing delay measured in minutes without materially undermining the system’s overall effectiveness, since the underlying event data is never lost and can always be caught up once load subsides.

A pattern that goes undetected due to a system outage is not a minor inconvenience; it can mean a genuine regulatory failure and real financial crime going unnoticed, so this system is built for continuous, reliable operation.

8.1 Redundancy at Every Layer

Every stateless service runs multiple replicas across multiple availability zones. Kafka, Flink, Neo4j, and the Case Database all run in clustered, replicated configurations, so the loss of any single node does not interrupt the continuous flow of transaction monitoring.

8.2 Exactly-Once Processing Guarantees

Since this system’s entire purpose is accurate aggregate counting, it is important that a transaction event is neither lost nor double-counted — even across a service restart or a brief network partition. The Real Time Feature Engine uses Flink’s checkpointing mechanism, which periodically saves a consistent snapshot of all in-flight aggregation state, combined with Kafka’s exactly-once processing semantics, ensuring that a restart resumes exactly where processing left off, without either skipping events or replaying them and inflating counts.

8.3 Graceful Handling of Downstream Slowness

If the Graph Database or ML Scoring Service becomes temporarily slow or unavailable, flagged candidates are placed into a durable retry queue rather than being dropped, ensuring that a temporary downstream issue causes a delay in alert creation, never a silent loss of a genuinely suspicious pattern.

8.4 Disaster Recovery

The Data Lake, being the permanent, authoritative record of all transaction history, is replicated across regions and retained according to regulatory requirements — often several years. In the event of a full regional outage affecting the real-time pipeline, the Batch Pattern Mining Service can, once service is restored, re-process the affected time window from the durable Data Lake, ensuring no pattern is permanently missed due to a temporary infrastructure failure.

8.5 Testing Reliability on Purpose

Given the regulatory stakes, teams operating this kind of system run regular, deliberate tests injecting known synthetic laundering patterns — using clearly marked test accounts — into a staging environment that mirrors production, verifying end to end that the pipeline correctly detects them within an expected time window, rather than only trusting that the individual components work correctly in isolation.

This system handles some of the most sensitive data in the entire organisation — complete transaction histories and active law-enforcement-adjacent investigations — and security must reflect that sensitivity.

9.1 Strict Access Control

Access to case data, raw transaction histories, and the graph database is tightly scoped through role-based access control, limited specifically to compliance analysts and authorised systems, with every single access logged for audit purposes, since even internal, unauthorised browsing of this data represents a serious policy and, in many cases, legal violation.

9.2 Protecting the Detection Logic Itself

The specific thresholds and rules used for detection are themselves sensitive; if leaked, they would give bad actors a precise playbook for evading detection. Access to the Rule Engine’s configuration and the ML model’s exact feature weights is restricted to a small, trusted group, separate from the broader engineering organisation’s usual access patterns for less sensitive systems.

9.3 Data Retention and Privacy Compliance

Transaction and case data is subject to strict, often lengthy, regulatory retention requirements, while simultaneously needing to respect data privacy regulations governing personal financial information. The Data Lake and Case Database implement clear, automated retention and deletion policies aligned with applicable regulations in each jurisdiction the platform operates in, which can genuinely differ from one country to another.

9.4 Encryption and Audit Trails

All data is encrypted both in transit and at rest, and every action taken on a case — from creation through analyst review to final SAR filing — is recorded in an immutable audit trail, since regulators may require a complete, tamper-evident record of exactly how and when a suspicious pattern was identified and handled.

9.5 Insider Threat Considerations

Because this system’s purpose is specifically to detect illicit financial activity, it must also be resilient against an insider — someone with legitimate system access — attempting to suppress or delete evidence of a genuine pattern. Alert creation and case data are designed to be append-only and tamper-evident, so that even a user with elevated access privileges cannot quietly make a legitimate alert disappear without leaving a clear, auditable trace.

9.6 Explainability as a Security and Compliance Requirement

It is worth treating explainability itself as a security-adjacent requirement, not merely a nice-to-have feature. When the ML Scoring Service flags an account as high risk, both the human analyst and, potentially, a regulator reviewing the platform’s compliance program afterward, need to understand which specific signals drove that score — not just trust an opaque number. This is why the system captures and stores the underlying rule triggers, network context, and key contributing features alongside every alert, not just the final risk score itself, ensuring that every automated decision remains genuinely explainable and defensible long after the moment it was made — which is essential both for maintaining analyst trust in the system and for satisfying regulatory expectations around explainable, auditable decision-making in automated financial compliance systems.

Given that a silent failure here could mean genuinely missed criminal activity, monitoring must be especially thorough and specifically tuned to this system’s unique risks.

10.1 Key Metrics to Track

10.2 Distributed Tracing

A trace ID follows each transaction event through ingestion, feature computation, rule evaluation, and, where applicable, graph analysis and scoring — letting engineers and even compliance analysts investigating a specific alert see the complete, precise evidence trail that led to its creation.

10.3 Structured, Immutable Logging

Every service emits structured logs, and, given the audit trail requirements discussed in the security section, case-related events are additionally written to a dedicated, append-only audit log, separate from general application logs, since these specifically need to be retained and remain unalterable for potentially many years.

10.4 Alerting and Service Level Objectives

A reasonable SLO for this system might state that consumer lag stays under two minutes during normal operation, and that alert volume does not deviate more than a defined percentage from its trailing thirty-day baseline without an identified, explained cause. Alerts fire immediately if consumer lag grows unexpectedly, or if alert volume drops sharply and unexpectedly, since both are strong, early signals that something in the pipeline may not be functioning correctly.

10.5 Dashboards Built for Different Audiences

An engineering dashboard tracks pipeline health, latency, and consumer lag — the detail needed to diagnose a technical issue. A compliance-and-risk-facing dashboard tracks alert volume, case aging, false positive rate, and SAR filing statistics over time, giving compliance leadership and, where required, regulators, clear visibility into how effectively the system is operating, separate from its underlying technical implementation.

All services are packaged as containers and orchestrated with Kubernetes, with deployment practices reflecting the regulatory sensitivity of this system.

11.1 Careful, Gradual Rollouts for Detection Logic

Changes to the Rule Engine’s thresholds or the ML Scoring Service’s model are rolled out using a shadow deployment strategy: the new logic runs in parallel with the existing production logic, generating its own candidate alerts for comparison, without those candidate alerts actually being surfaced to analysts yet — allowing the team to measure the impact on alert volume and precision before fully switching over. This matters because an overly aggressive change could either flood analysts with false positives or, worse, silently suppress genuine detections.

11.2 Auto-Scaling the Streaming Layer

The Flink cluster’s parallelism, and the number of Stream Ingestion Service replicas, scale based on observed event throughput and consumer lag, allowing the system to absorb both predictable daily transaction volume patterns and unexpected spikes without falling behind.

11.3 Regional Deployment and Data Residency

Given strict, often country-specific regulatory requirements around where financial transaction data may be stored and processed, this system is often deployed with careful attention to data residency — sometimes requiring separate, regionally isolated deployments rather than a single, globally shared instance, unlike some of the other systems in this tutorial series that can more freely operate in an active-active multi-region configuration.

11.4 Infrastructure as Code

All infrastructure, including the Kafka, Flink, Neo4j, and database clusters, is defined in code using tools such as Terraform, ensuring every change is reviewable and reproducible — which matters particularly here given the compliance and audit obligations placed on this specific system.

12.1 Why a Graph Database for Network Analysis

We chose Neo4j specifically because the core analytical question this system needs to answer repeatedly — “how are these accounts connected, and through what kind of pattern” — is fundamentally a graph traversal problem. Graph databases store relationships as first-class entities and are optimised for efficiently walking these connections to arbitrary depth, a capability that would require increasingly complex and slow multi-way joins in a traditional relational database as the relevant relationship depth grows.

12.2 Why Redis for the Feature Store

The Feature Store needs to support extremely high-throughput reads and writes of small, frequently updated values — exactly Redis’s core strength, as seen in other tutorials throughout this series. Rolling behavioural aggregates are compact, bounded in size, and need sub-millisecond access, making Redis a natural fit — distinct from the Graph Database’s role, which is reserved for the comparatively rarer, deeper relationship queries.

12.3 Why PostgreSQL for Case Management

Case and investigation data benefits from PostgreSQL’s strong consistency guarantees and rich support for structured, relational queries — such as “show me all open cases assigned to this analyst, sorted by risk score,” a query pattern that is a natural fit for a relational database, distinct from the network-shaped queries the Graph Database handles.

12.4 Object Storage for the Data Lake

The complete, immutable transaction history is stored in an object storage cluster, chosen for its ability to hold enormous, ever-growing volumes of historical data cost-effectively, serving the Batch Pattern Mining Service’s periodic, large-scale re-analysis without needing to keep years of raw transaction data in more expensive, latency-optimised storage.

12.5 Load Balancing Strategy

The same two-tier load balancing approach used throughout this tutorial series applies to the ingestion path: a Global Load Balancer routes to the nearest healthy region, and a Regional Load Balancer distributes traffic across Stream Ingestion Service replicas, ensuring ingestion itself — the entry point for every downstream analysis — remains fast and highly available even under peak transaction volume.

12.6 A Quick Side-by-Side of the Four Stores

12.7 Keeping the Graph Database Bounded and Manageable

Left unmanaged, a transaction graph capturing every account and every transaction across a large platform’s entire history would grow to an enormous, unwieldy size — making even well-scoped queries progressively slower over time. In practice, the Graph Database typically retains only a rolling window of the most recent relationship history, commonly ranging from ninety days to a year depending on regulatory and detection requirements, with older relationship data archived to the Data Lake, accessible to the Batch Pattern Mining Service for deeper historical analysis when specifically needed, but not kept live in the graph indefinitely. This keeps the graph’s working size manageable and query performance predictable, while still preserving the complete underlying history for the cases — thankfully rare — where a genuinely long-horizon investigation requires looking further back than the live graph’s rolling window covers.

13.1 The Transaction Ingestion API

Request Body:
{
  "transactionId": "TXN-991823",
  "senderAccountId": "ACC-5001",
  "receiverAccountId": "ACC-6002",
  "amountCents": 920000,
  "currency": "INR",
  "timestamp": "2026-08-03T10:15:00Z"
}

Response Body:
{
  "status": "ACCEPTED",
  "transactionId": "TXN-991823"
}

13.2 The Case Query API for Analysts

Response Body:
{
  "cases": [
    {
      "caseId": "CASE-4471",
      "riskScore": 0.92,
      "patternType": "STRUCTURING",
      "involvedAccounts": ["ACC-5001", "ACC-5002", "ACC-5003"],
      "createdAt": "2026-08-03T10:20:00Z"
    }
  ]
}

13.3 Internal Service Contracts

Internal services communicate over a combination of Kafka event streams for the high-throughput ingestion and feature computation path, and gRPC for lower-volume, synchronous calls such as the Rule Engine querying the Graph Database or ML Scoring Service — matching each internal communication pattern to the tool best suited for its specific throughput and latency characteristics.

13.4 Why Microservices Fit This Problem

Separating ingestion, feature computation, rule evaluation, graph analysis, ML scoring, and case management allows each to scale and evolve on its own schedule. The ML Scoring Service, for example, might be updated frequently as new models are trained, while the core ingestion path — being the most latency-critical and highest-throughput component — changes far more conservatively, and this separation lets each team responsible for a given piece move at the pace appropriate to its own risk and iteration profile.

14.1 Patterns Used

14.2 Anti-patterns to Avoid

15.1 Best Practices

• Always reason about aggregate, cross-transaction behaviour — never rely solely on evaluating individual transactions in isolation.
• Combine fast, transparent rule-based detection with slower, more nuanced ML scoring and network analysis, rather than relying on only one approach.
• Keep detection thresholds and models under strict access control, and evolve them deliberately over time rather than treating them as fixed and permanent.
• Feed analyst decisions — both confirmed and false positive — back into the system continuously to improve precision over time.
• Maintain an append-only, tamper-evident audit trail for every alert and case decision, given the regulatory and legal weight this data carries.
• Continuously test the pipeline against known synthetic laundering patterns, not just individual component unit tests.

15.2 Common Mistakes

• Building only single-transaction fraud-style rules and assuming they are sufficient for money laundering detection, missing the entire category of aggregate, network-based patterns.
• Allowing graph queries to run unbounded, causing severe performance degradation as the transaction network grows over time.
• Treating a drop in alert volume as automatically good news, without investigating whether it reflects a genuine improvement or a silent pipeline failure.
• Failing to separate the real-time and batch paths clearly, leading to a system that is either too slow for fast-forming patterns or too shallow for slow, complex ones.
• Under-resourcing the human analyst review process relative to the volume of alerts the automated system generates, undermining the entire pipeline’s practical effectiveness regardless of how well the detection logic itself performs.

15.3 A Pre-Launch Readiness Checklist

Before launching or significantly changing this system, experienced teams confirm each item above. It is also worth remembering that this close, ongoing collaboration between engineering and compliance is, in many ways, as important to this system’s ultimate success as any individual technical design decision covered throughout this tutorial, and it is worth carrying that lesson forward into how any team approaches building or operating a system like this in practice.

The most common questions that arise when engineers first approach this design — followed by a compact summary of everything the tutorial has covered, and the six ideas most worth carrying forward.

Generally no; this system is primarily an investigative and reporting tool operating alongside the payment path, not inside it, since most laundering patterns can only be confirmed by looking at aggregate behaviour after the fact. That said, in some jurisdictions and for certain very high-confidence real-time signals, a platform may choose to hold or review a specific transaction pending investigation.

Fraud detection typically focuses on protecting the platform and its customers from a single bad actor’s harmful individual transaction, such as a stolen card being used, while this system focuses on detecting patterns of financial activity, often across many individually valid transactions, that suggest an attempt to disguise the origin of funds — a related but distinct problem requiring different techniques, particularly the aggregate and network analysis covered throughout this tutorial.

Regulatory thresholds are typically set by law or regulation, not something a platform can simply adjust on its own, and even if it could, sophisticated actors would likely adapt their structuring amounts accordingly — this is precisely why detection must rely on aggregate behavioural and network patterns rather than any single fixed threshold value.

This is exactly why the ML Scoring Service incorporates an account’s own long-term behavioural baseline, rather than applying a single universal threshold to everyone; a small business account with a consistent, years-long history of frequent transactions looks very different in its established baseline pattern than an account with no prior history suddenly beginning to receive many near-threshold deposits from unrelated senders.

For patterns detectable by the real-time streaming path, typically within minutes of the pattern crossing its defining threshold, since the Real Time Feature Engine updates continuously as each transaction arrives. For the slower, more complex patterns only detectable by the Batch Pattern Mining Service’s deeper historical analysis, detection latency is naturally longer, often measured in hours, reflecting the genuinely greater computational depth required to uncover them.

This is a genuine, ongoing challenge rather than a fully solved problem; it is precisely why the system layers multiple independent signal types — rule thresholds, network position, and behavioural baseline anomaly — together, since evading every single layer simultaneously is considerably harder than evading any one detection mechanism in isolation, and it is also why continuous model retraining and threshold evolution, discussed in the best practices section, remain an ongoing, permanent part of operating this system rather than a one-time setup task.

17.1 Summary

Money laundering detection is fundamentally different from single-transaction fraud detection because the signal exists in aggregate behaviour across many transactions and across a network of related accounts — not in any single event. This tutorial has walked through a Lambda-style hybrid architecture that combines a fast, real-time streaming path (Kafka + Flink + Redis + Rule Engine) with a deeper batch path (Data Lake + Spark) and network analysis (Neo4j), coordinated by an ML Scoring Service and a human-in-the-loop Case Management workflow. Each layer has been chosen for the specific shape of the workload it handles: rolling aggregates in Redis, graph traversal in Neo4j, structured investigation records in PostgreSQL, and immutable historical retention in object storage. Security, monitoring, and deployment practices have been designed around the reality that a silent failure here is not just an outage but a compliance incident: append-only audit trails, shadow deployments for detection logic, alert-volume monitoring, and synthetic-pattern replay tests all exist because this system must not merely be correct today, but must remain provably correct over years of adversarial pressure.

This design gives a payment platform or financial institution the ability to see the sandcastle, not just the individual grains of sand — catching sophisticated patterns deliberately built to hide within the enormous, continuous flood of otherwise completely legitimate transaction activity. Achieving this requires a genuinely different architectural mindset than the single-request, single-transaction systems covered elsewhere in this tutorial series, embracing streaming aggregation, graph analysis, and batch pattern mining as first-class citizens, working together, rather than trying to force this fundamentally aggregate, relational problem into a single-transaction request-response model that was never designed to see the larger pattern in the first place.

For anyone approaching this as a system design interview question, the strongest signal is recognising early that this is not simply a scaled-up version of a single-transaction fraud check, but a categorically different kind of problem — one that requires reasoning about time, aggregation, and network relationships as first-class architectural concerns from the very beginning. Candidates who jump straight to “add more servers” without first identifying that the core challenge is behavioural and relational, not purely computational, tend to miss the heart of what makes this problem genuinely interesting, and genuinely important, both as an engineering challenge and as a real safeguard protecting the financial system from serious criminal misuse.