Every financial platform — a bank, a card issuer, a digital wallet, a crypto exchange — sits on top of a river of money moving between people it has never met in person. Most of that money is completely ordinary: rent, salaries, groceries, invoices. But a small fraction of it is not ordinary at all. It might be money from a stolen identity, a drug trafficking operation, or an attempt to move funds to a sanctioned country while disguising where it really came from. Governments around the world have decided that financial platforms are the best-positioned party to notice this kind of activity, because they are the ones who can actually see the transaction happening. This is the foundation of what is broadly called Anti-Money Laundering, or AML, regulation, and the system we are about to design is the engineering backbone that makes a platform’s AML obligations actually enforceable in practice.

To understand why this needs serious engineering rather than a spreadsheet and a compliance officer’s good judgment, imagine a small neighborhood shop that only takes cash from a handful of regular customers. The shop owner can genuinely remember and notice if someone suddenly starts buying strange, large quantities of something unusual. Now imagine that same shop processing millions of transactions a day, from customers all over the world, most of whom the shop owner will never speak to. No human being, or even a large team of human beings, can manually watch that volume of activity and reliably notice the small number of transactions that look wrong. The noticing has to be done by software, continuously, at the same speed the transactions themselves are happening.

The specific obligation this tutorial focuses on is the filing of a Suspicious Activity Report, commonly abbreviated SAR (some jurisdictions call it a Suspicious Transaction Report, or STR). This concept traces back to the U.S. Bank Secrecy Act of 1970 and has since been adopted, in various forms, by financial regulators worldwide — FinCEN in the United States, the FCA and NCA in the United Kingdom, AUSTRAC in Australia, and similar bodies elsewhere. The common thread across all of them is a strict legal deadline: once a financial institution’s internal process determines that a transaction is suspicious, it typically has a fixed number of calendar days (commonly 30 days in the U.S., though the exact number varies by jurisdiction and circumstance) to file a formal report with the regulator. Miss that deadline, and the institution is not just embarrassed — it is in violation of the law, facing potential fines that can run into the millions of dollars, and in serious or repeated cases, the loss of its license to operate as a financial institution at all.

What makes this different from a typical alerting or ticketing system is the combination of three properties that all have to hold simultaneously: the detection has to happen automatically across enormous transaction volumes, the investigation and decision has to involve trained human judgment because false accusations have real consequences, and the entire process — detection, investigation, decision, and filing — has to complete within a legally fixed window that the institution does not control and cannot negotiate. This is why the system is best understood not as a fraud-detection tool, though it shares components with one, but as a compliance workflow platform with a legal clock built into its core.

The Problem, Stated Precisely

Stripped of jargon, the engineering problem is this: build a system that continuously evaluates a very high-volume stream of transactions against evolving suspicion criteria, surfaces a manageable number of genuinely worth-investigating alerts to trained human investigators, tracks each alert’s decision-making process in a way that could later be defended to an external auditor or regulator, and — if a human decides the activity is indeed suspicious — reliably produces and transmits a correctly formatted legal filing before a hard deadline that started ticking the moment suspicion was first identified, not the moment the transaction happened. Every one of those clauses hides real distributed-systems and workflow difficulty, but the deadline clause is the one that makes this fundamentally different from ordinary fraud tooling: a missed SAR filing is not a lost feature, it is a legal violation with the institution’s own name directly attached to it.

How This Differs From Ordinary Fraud Detection

It is worth being precise about the distinction between fraud detection and suspicious activity reporting, because interviewers frequently probe exactly this boundary, and because the two systems, while related, optimize for different outcomes. Fraud detection exists to protect the institution and its customers from direct financial loss — a stolen card being used, an account takeover in progress, a chargeback-prone merchant. Its success metric is straightforward: money saved, losses prevented. Suspicious activity reporting exists to satisfy a legal transparency obligation to a regulator, and its “success” is not measured in money saved at all, but in whether genuinely suspicious activity was correctly identified, investigated, and reported within the legal window, regardless of whether the institution itself lost any money in the process. A transaction can be entirely legitimate from a fraud perspective — the account holder authorized it themselves — and still be highly suspicious from an AML perspective, because the money being moved may have illegal origins the account holder is deliberately trying to obscure.

In practice, the two systems share significant infrastructure — both need real-time transaction visibility, both need customer risk context, and both generate alerts that trained staff review — which is why many platforms build them on a shared data and detection foundation while keeping their decisioning, workflow, and reporting obligations clearly separated. Conflating the two, however, is a common and costly mistake: a suspicious activity case that gets treated with the urgency and playbook of a fraud case may be closed quickly once financial loss is ruled out, even though the underlying money-laundering concern was never actually addressed.

Why the Deadline Cannot Simply Be Engineered Away

A natural first instinct for an engineer encountering this domain is to ask whether the deadline problem can be solved simply by making detection and investigation fast enough that the deadline is never at risk. In practice, this is only part of the answer, because investigation quality genuinely takes time — a rushed review that overlooks a legitimate explanation, or misses a connected pattern across accounts, is itself a real cost, not just a theoretical one. The deadline is not purely an engineering performance target to be minimized; it is a legally fixed budget of time that the system needs to spend as effectively as possible, front-loading detection speed specifically so that the bulk of that fixed budget can go toward genuine human judgment rather than being consumed by internal processing delay before an investigator ever sees the case.

Before drawing the architecture, it is worth naming the actors, because the design only makes sense once you know who each component is really serving. There is the customer, whose transaction is being evaluated. There is the financial platform itself, which owns the legal obligation to detect and report. There are compliance investigators, trained staff who review flagged activity and make the final judgment call. There is the regulator (FinCEN, the FCA, AUSTRAC, or an equivalent body), which receives the filing and may follow up with further requests. And there is often an internal Financial Intelligence Unit, or FIU, a specialized team that sits above day-to-day investigators and handles the most complex or highest-risk cases.

A suspicious transaction regulatory reporting system is best understood as a continuous detection pipeline feeding a deadline-driven investigation workflow, which itself feeds a highly structured, auditable filing and submission process. The diagram below lays out the major components.

Transaction Monitoring Engine

This is the system’s constant, tireless watcher. It evaluates every transaction, in near real time, against a combination of deterministic rules (for example, “more than ten transfers to newly created accounts within one hour”) and machine learning models trained to recognize patterns that resemble historically confirmed money laundering typologies, such as structuring — breaking a large amount into many smaller transactions specifically to stay under a reporting threshold. The engine’s job is not to make a final judgment; it is to narrow an enormous stream down to a much smaller set of transactions worth a closer look.

Notification and Escalation Channels

Investigators and senior reviewers need to be reliably informed as a case approaches its deadline, through multiple channels — an in-app queue indicator, an email digest, and for the most time-critical cases, a direct escalation to a compliance manager rather than relying solely on someone happening to check a dashboard. Because a missed notification here carries far more weight than a missed notification in most other domains, delivery is tracked per channel, and if the primary channel shows no acknowledgment within an expected window, the system automatically escalates to a secondary channel rather than assuming the first attempt was sufficient.

Sanctions and Watchlist Screening

Separate from behavioral monitoring, every transaction’s counterparties are screened against government sanctions lists and other watchlists, since a payment involving a sanctioned individual, entity, or country can itself be independently reportable and, in some cases, must be blocked outright rather than simply flagged for later review. This screening component often has the strictest latency requirements in the entire architecture, because in high-risk cases the transaction may need to be held or blocked before it settles, not just flagged after the fact.

Alert Generation Service

When the monitoring engine or the screening service identifies something worth a closer look, the Alert Generation Service creates a structured alert record, attaches a risk score, and links every transaction and account involved. Multiple related alerts about the same customer or the same underlying pattern are correlated together rather than left as separate, disconnected items, since investigators need to see the full picture, not fragments of it scattered across unrelated queue entries.

Investigator Work Queue

Alerts are not reviewed in the order they were created; they are prioritized by a combination of risk score and how much of the legal filing deadline has already elapsed since the underlying suspicion could reasonably have been identified. This queue is effectively the visible tip of the deadline-tracking system, giving investigators a constantly reordering, always-current view of what most urgently needs their attention.

Case Management Service

This is the heart of the system, playing the same architectural role a case management service would play in any structured, deadline-driven workflow. It owns the investigation’s state machine — from alert triage, through active investigation, to a final decision to file or close — and it is the component every other service reports progress to and takes direction from.

Customer Risk Profile Service

Effective investigation depends on context, not just the single flagged transaction in isolation. This service maintains an aggregated, continuously updated view of each customer’s risk factors: their KYC (Know Your Customer) onboarding information, historical transaction patterns, prior alerts and their outcomes, and any previously filed reports. Investigators pull from this service constantly, since a transaction that looks alarming in isolation might be completely explainable in the context of a customer’s established, legitimate business.

Decision Engine and Dual Approval

Because filing a SAR is a serious legal action with real consequences for the person or business named in it, the decision to file is rarely left to a single individual. The Decision Engine enforces a dual-approval workflow, typically requiring a senior reviewer or the Financial Intelligence Unit to confirm an investigator’s recommendation before a filing is actually generated, providing a built-in check against both false positives and, just as importantly, against any single point of human error or misconduct in a legally consequential decision.

Regulatory Filing Service and Submission Gateway

Once a filing decision is confirmed, the case’s narrative and structured data must be translated into the exact schema and format the relevant regulator expects — for example, the U.S. BSA E-Filing system has its own strict XML schema and validation rules. The Filing Service handles this formatting and validation, and the Submission Gateway manages secure, authenticated transmission to the regulator, along with tracking the regulator’s own acknowledgment of receipt, since a filing that was sent but never confirmed as received is not a filing the institution can safely consider complete.

Audit and Compliance Ledger

Every single action taken on a case — who viewed it, who added a note, who approved the filing, and exactly when — is written to an immutable audit ledger. This is not an optional nicety; regulators can and do request a full audit trail showing exactly how and when an institution identified and acted on suspicious activity, and an incomplete or tamperable trail can itself become a compliance failure independent of whether the underlying filing was correct.

Deadline Tracking Service

Given how central deadlines are to this domain, they are managed by a dedicated service rather than being an incidental field on the case record. The Deadline Tracking Service computes and continuously monitors the legally relevant countdown for every open case, distinguishes between the “date of initial detection” and the “date the institution reasonably should have identified suspicion” (a legally important distinction, since a poorly run investigation process can itself extend an institution’s exposure), and drives escalation actions well before the actual legal deadline arrives, rather than only reacting once it has already passed.

Regulatory Change Management Layer

Regulators periodically update filing schemas, reporting thresholds, and even the definition of what qualifies as reportable activity. Rather than scattering this knowledge across every service that happens to touch it, a dedicated Regulatory Change Management layer maintains versioned, machine-readable rule sets describing exactly which schema, threshold, and deadline logic applies for each regulator and effective date range. Every case is stamped with the specific rule-set version that governed it, so that a case opened before a regulatory update is handled consistently with the rules that were actually in force at the time, even if the platform’s overall configuration has since moved on to a newer version.

Internally, this system behaves as a durable, time-driven state machine layered on top of a continuous stream-processing pipeline. This dual nature — always-on detection combined with a strictly staged investigation workflow — is what makes the internal design more involved than either a pure streaming system or a pure workflow engine on its own.

As with any state machine carrying legal weight, every transition is written to the immutable audit ledger before any other side effect occurs, following the same event-sourcing discipline used in other high-stakes financial workflows: record the fact first, then react to it. This ordering guarantee is what allows the system to recover cleanly from a partial failure — if a notification fails to send after a state transition, the transition itself is still correctly and durably recorded, and the notification can be safely retried without any risk of re-applying the underlying state change.

Stream Processing at the Front End

The Transaction Monitoring Engine operates as a continuous stream processor rather than a batch job, evaluating each transaction against both stateless rules (checks that only need the current transaction) and stateful rules (checks that need a rolling window of recent history, like “total transfers from this account in the last 24 hours”). Stateful evaluation requires maintaining windowed aggregates per account, typically implemented using a stream-processing framework’s built-in state store, checkpointed regularly so that a worker crash does not silently reset an account’s rolling history back to zero and cause either a burst of false negatives or a burst of false positives immediately after recovery.

Deadline Computation

Unlike a simple fixed-offset timer, the regulatory deadline in this domain is computed, not just set. It typically starts from the date the institution “becomes aware of facts that may constitute a basis for filing,” which in practice is usually anchored to when an alert is confirmed as a genuine concern during triage, not when the underlying transaction originally occurred. The Deadline Tracking Service recalculates this anchor point carefully and records the justification for it in the audit ledger, since regulators can and do scrutinize exactly when an institution says it “knew,” especially in cases where a filing arrives close to or after the deadline.

Idempotency Across the Pipeline

Transaction streams retry, investigator UIs can submit the same action twice due to a network blip, and regulator submission gateways can time out and be retried by client code. Every meaningful operation — alert creation, state transition, filing submission — carries an idempotency key, checked against a processed-operations record before any effect is applied, so that a retried message never creates a duplicate alert, never double-advances a case’s state, and critically, never results in the same SAR being filed twice for the same underlying activity.

Concurrency Control on a Single Case

It is entirely possible for two triggers to act on the same case nearly simultaneously — for example, a senior reviewer approving a filing recommendation at the exact moment an investigator adds a late piece of evidence that would materially change the recommendation. Without protection, this is a race condition whose outcome could depend purely on which write happened to land last, which is not acceptable for a legally consequential decision. The Case Management Service guards against this with optimistic concurrency control: every case row carries a version number, and every update includes the version it expects to be updating from, so a write against a stale version is rejected and the service re-reads current state before deciding what to do next, rather than silently overwriting a decision that already happened underneath it.

Consensus for Deadline Sweeper Leadership

Just as in other durable-scheduling domains, redundant instances of the Deadline Tracking Service need to agree on which one is currently authorized to fire escalation actions, so the same escalation is never triggered twice. This is solved using a coordination service providing distributed locks with automatic lease expiry, so that if the current leader instance crashes, its lease naturally expires and a standby instance can safely take over within a bounded, predictable amount of time, without any risk of two instances briefly believing they are both in charge simultaneously.

CAP Theorem Trade-offs in This Domain

The CAP theorem states that during a network partition, a distributed system must choose between consistency and availability. For case state and the audit ledger, this system deliberately favors consistency: if replicas cannot agree during a partition, it is safer to briefly reject a write than to risk two conflicting versions of a legally significant decision being independently accepted and needing reconciliation later, which could itself undermine the integrity of the audit trail. For less critical paths, such as the investigator dashboard’s queue view, the system leans toward availability instead, tolerating a few seconds of staleness rather than blocking investigators from working entirely during a brief network hiccup. This is a good illustration of why CAP trade-offs are rarely made once for an entire system — they are made independently, component by component, based on what each one actually protects.

Let’s trace one case end to end. A customer’s account suddenly receives fourteen incoming transfers of just under a common reporting threshold, each from a different, newly created account, all within a six-hour window — a classic structuring pattern. The monitoring engine’s stateful rule catches this the moment the fourteenth transfer clears.

Every one of these steps happens within a strict overall window, but individual steps themselves often need internal service-level targets — an alert should reach an investigator’s queue within seconds of detection, not hours, simply because every hour spent in transit is an hour subtracted from the time available for genuine investigation before the legal deadline arrives.

Evidence and Narrative Construction in Detail

The investigation step deserves closer attention because it is where the most valuable human judgment in the entire system is applied. A trained investigator does not just look at the one flagged transaction; they build a narrative that answers specific questions a regulator will expect to be addressed: what is suspicious about this activity, why does it not have an obvious legitimate explanation, and what supporting evidence — account opening details, prior transaction history, any customer communication — backs up that judgment. The Evidence and Narrative Service structures this process with guided templates rather than a blank text box, since a well-structured, complete narrative is significantly less likely to be challenged or returned for rework by a senior reviewer, and dramatically speeds up the filing preparation step that follows.

Reason Typologies Drive Prioritization

Much like reason codes drive branching logic in other reporting domains, an alert’s underlying typology — the category of suspicious pattern it matches, such as structuring, layering, rapid movement of funds, or unusual geographic patterns — drives how it is prioritized and which evidence template applies. Getting typology classification right early in the pipeline matters enormously, because it shapes almost everything downstream: which evidence checklist an investigator sees, which specialist team may need to be looped in for particularly complex patterns like trade-based laundering, and even how the final narrative is structured to align with the language regulators expect for that specific category of concern.

The Alert Generation Service’s scoring model is essentially a large, versioned decision surface keyed on typology, customer risk tier, transaction amount, and historical alert outcomes for similar patterns. Because regulatory guidance and observed money-laundering techniques both evolve, this scoring configuration is data-driven and updatable without a full application redeploy, in the same way policy tables are kept external to core application code in other compliance-heavy systems.

A Sharded View of the Detection Pipeline

It helps to visualize how transaction and case data physically spreads across partitions as volume grows, since this is a natural follow-up question once the sequence flow is understood.

Linking Related Cases Across Accounts

Money laundering schemes rarely involve a single, isolated account; they often spread activity across several accounts, sometimes controlled by different individuals working together, specifically to avoid drawing attention to any single account. The Case Management Service supports explicit case linking, so that when an investigator recognizes a shared pattern — the same beneficiary appearing across several seemingly unrelated accounts, for instance — the related cases can be tied together, their evidence shared, and a single, coordinated filing decision made rather than several fragmented ones that each individually looked minor but together would have told a much clearer story.

A central trade-off is between detection sensitivity and investigator capacity. A very sensitive monitoring engine catches more genuine suspicious activity but floods investigators with false positives, and an overwhelmed investigation team is itself a compliance risk, since a genuinely suspicious case buried under thousands of noise alerts can just as easily miss its filing deadline as one that was never detected at all. Mature platforms treat this as a continuously tuned balance, using historical alert-to-filing conversion rates per typology to adjust thresholds, rather than a one-time configuration decision made at launch and left untouched.

Another real trade-off is between investigation thoroughness and deadline pressure. A rushed investigation to beat the clock risks a poorly supported filing or, worse, missing genuinely suspicious linked activity that a more thorough review would have caught, while an overly cautious, slow investigation process risks the deadline itself. This tension is exactly why the system escalates cases well before the legal deadline rather than only reacting once time is nearly out — the goal is to buy investigators as much genuine investigation time as possible within the fixed window the law provides, not to optimize the workflow down to the wire.

A further, less obvious trade-off concerns how much weight to place on machine learning-driven scoring versus deterministic, clearly explainable rules. Machine learning models can surface subtle, non-obvious patterns that a fixed rule set would miss entirely, but their outputs are inherently harder to explain to a regulator who may ask exactly why a particular transaction was, or was not, flagged. Deterministic rules are easy to justify and audit, but by nature can only catch patterns someone has already thought to write a rule for. Most mature platforms run both in parallel, using rules as an auditable, explainable floor and machine learning as an additional layer to catch what the rules alone would miss, rather than betting the entire detection strategy on one approach exclusively.

A financial platform processing millions of transactions per minute needs its Transaction Monitoring Engine to keep pace continuously, since falling behind on stream processing does not just delay a dashboard update — it delays the start of the legal deadline clock itself for any suspicious activity buried in the backlog.

Horizontal Scaling of Stream Processing

The monitoring engine is partitioned by account or customer ID, so that all transactions for a given account are processed in order by the same partition, preserving the correctness of stateful, windowed rules while still allowing the overall engine to scale horizontally across many partitions and worker instances. This is the same partitioning principle that underlies most high-throughput stream processing systems: correctness for stateful logic requires that related events land on the same worker, while unrelated accounts can be spread arbitrarily wide for scale.

Backpressure Between Detection and Investigation

Detection can scale far faster than human investigation capacity ever can. When alert volume spikes — for example, immediately after a scoring model update or during unusual market conditions — the system needs deliberate backpressure between the Alert Generation Service and the Investigator Work Queue, using risk-based triage to ensure the highest-priority, most time-critical cases are surfaced first rather than simply processed in raw creation order, which could bury a genuinely urgent case behind a flood of lower-priority ones.

Read Scaling for Investigator Context

Every investigation pulls a wide slice of historical data — the Customer Risk Profile Service, linked transaction history, prior case outcomes — and these read-heavy queries are served through dedicated read replicas or a purpose-built aggregation store, kept separate from the write-heavy, latency-sensitive transaction monitoring path, so a burst of investigator activity never competes for the same database resources as the real-time detection pipeline.

Connection Pooling and Backpressure at the Database Layer

Even a well-partitioned data store can be overwhelmed by an unbounded flood of writes during a sudden burst. Every service maintains a bounded connection pool rather than opening a fresh connection per request, and when a pool is exhausted, incoming work queues safely in the durable message bus rather than piling up as half-finished database connections. It is far better for a burst of alerts to sit for a few extra minutes in a durable queue than for the database to be driven into a degraded state that would slow down deadline checks for every other, entirely unrelated case.

Capacity Planning Around Regulatory Events

Detection and investigation load is not always driven purely by the platform’s own transaction volume. A widely publicized sanctions list update, a new regulatory guidance document describing a fresh typology, or a major geopolitical event can all cause sudden spikes in both detection alerts and investigator workload, independent of any change in ordinary transaction volume. Capacity planning for this system therefore has to account for these external, unpredictable triggers, not just organic growth, typically by maintaining meaningful headroom in both compute capacity and investigator staffing plans rather than provisioning purely against historical averages.

Because a missed legal filing deadline is a compliance violation with the institution’s name directly attached, the deadline-tracking and case-management path is the single most reliability-critical part of this system, arguably even more so than the detection pipeline itself, since a delayed detection can sometimes still be caught later within the window, while a fully missed deadline generally cannot be undone.

Multi-Region Deployment

The case database and audit ledger typically run with synchronous replication within a region for strong consistency on financial and legal records, and asynchronous replication across regions for disaster recovery, accepting a small, bounded recovery-point gap in exchange for avoiding cross-region write latency on every single case update.

Graceful Degradation

If the Sanctions and Watchlist Screening service becomes unavailable, the system must not simply let transactions flow through unscreened — it fails safe by holding affected transactions for manual review rather than silently skipping a legally required check. Conversely, if the Customer Risk Profile Service is degraded, investigators can still proceed with a documented note that full context was unavailable at review time, rather than the entire investigation workflow grinding to a halt because one supporting service is temporarily down.

Deadline Redundancy

Given the legal stakes, the Deadline Tracking Service runs with redundant instances coordinated through distributed leader election, so a single instance failing does not silently stop deadline evaluation. A secondary, independent reconciliation job periodically cross-checks every open case’s computed deadline against the case’s actual stage, specifically to catch the scenario where a case has silently stalled in an intermediate state for far longer than is normal, well before that stall becomes a missed deadline.

Backup, Retention, and Disaster Recovery

Beyond live replication, the system takes regular point-in-time snapshots of case, ledger, and filing data, retained for a period long enough to satisfy both regulatory record-keeping requirements, which can extend to five years or more depending on jurisdiction, and any internal need to reconstruct a historical case for a later regulator inquiry. Disaster recovery drills are executed on a fixed schedule rather than left as a written but untested runbook, since the exact moment a real regional failure happens is the worst possible time to discover that a recovery assumption was stale or an access credential had expired.

Defining “Available” for This System

Availability here means more than “the API responds to a health check.” A more meaningful definition is “every case with a deadline in the next several days can still be correctly evaluated, escalated, and acted upon.” A system can appear healthy by ordinary infrastructure metrics while still silently failing its actual reliability promise if, for instance, the Deadline Tracking Service’s core query begins timing out under load without triggering an obvious infrastructure-level alert. Defining availability around this business outcome, rather than purely around uptime, is what actually protects the institution from the outcome that matters most: a missed legal deadline caused by an internal tooling failure rather than any genuine ambiguity in the underlying case.

This system sits at an unusually sensitive intersection: it processes detailed financial behavior data, personal identity information, and, in some cases, evidence that a specific named individual is suspected of a serious crime. A breach here is not just a data-privacy incident; leaked knowledge that a specific person is under investigation, sometimes called “tipping off,” can itself be illegal in many jurisdictions, since it can let a genuinely guilty party destroy evidence or flee.

Strict Need-to-Know Access Control

Access to open case details is restricted specifically to assigned investigators, their direct reviewers, and the compliance function overseeing the case, enforced through fine-grained, per-case authorization rather than a broad “all compliance staff” role. Every single view of a case is logged, since the audit trail needs to demonstrate not just what decision was made, but who had access to sensitive suspicion details and when.

Confidentiality of the Filing Itself

Most SAR regulatory regimes legally prohibit disclosing to the subject of the report, or to unauthorized staff, that a filing has been made at all. The system enforces this at a structural level: the fact that a case resulted in a filing is never exposed through any customer-facing channel, and even internal systems outside the compliance function (like a general customer service tool) are deliberately not given visibility into filing status, to prevent an accidental disclosure through an unrelated support interaction.

Encryption and Data Handling

Case narratives, evidence, and personal identity data are encrypted at rest using envelope encryption with strict key management, and every network hop is encrypted in transit, following the same layered approach used across sensitive financial systems generally. Given the multi-year retention periods regulators often require for these records, encryption key rotation is designed from the start to support decrypting old records without needing to re-encrypt an entire historical archive on every rotation.

Key Management

Master keys used in the envelope encryption scheme are managed through a dedicated key management service with strict separation of duties, so no single engineer can both approve and independently execute a key rotation without a second authorized approver, and every key operation is itself recorded as an auditable event. Keys are rotated on a fixed schedule and immediately upon any suspected compromise, while old key versions are retained only long enough to decrypt legitimately old case records, never reused for encrypting anything new.

Segregation of Duties in Software, Not Just Policy

Many compliance programs describe segregation of duties as a policy — the person who investigates should not be the same person who approves a filing. A well-designed system enforces this structurally in software rather than relying purely on organizational trust: the Decision Engine technically rejects an approval action submitted by the same user identifier who authored the investigation recommendation, regardless of whether that user happens to also hold a reviewer role for other cases. This turns a policy expectation into a guarantee the system itself upholds, rather than a rule that depends entirely on individual staff remembering to follow it.

Because the entire system exists to protect a legal deadline, observability has to be built around time remaining and stage progression, not just generic system health.

Key Metrics

Distributed Tracing by Case ID

Since a single case touches detection, screening, investigation, dual approval, and filing over a period that can span weeks, every log line, event, and trace span is stamped with a persistent case ID from the moment of creation through final regulator acknowledgment, letting a compliance engineer reconstruct a case’s full timeline instantly if it is ever challenged internally or externally.

Alerting Philosophy

Alerts are tiered strictly by legal and financial impact. A slow analytics dashboard refresh is a low-priority notice; a stalled Deadline Tracking Service, or a case sitting untouched with only a few days of runway left, is an immediate page to the on-call compliance engineering team, because the cost of delay here is measured in regulatory exposure, not just user experience.

Service Level Objectives and Error Budgets

Rather than pursuing generic, undifferentiated uptime targets, the platform defines explicit service level objectives around the outcomes that actually matter — for example, “99.99 percent of deadline evaluations complete within one minute of becoming due” or “alert-to-triage latency stays under five minutes for 99.9 percent of alerts.” An error budget derived from these objectives gives engineering and compliance teams a shared, data-driven way to balance shipping detection improvements against tightening reliability, slowing deployment velocity deliberately when the budget is being consumed too quickly rather than making that trade-off informally or discovering the problem only after an incident.

Structured Logging

Every log line across every service is emitted as structured data rather than free-form text, with consistent fields for case ID, account ID, typology, and current state. This structure is what makes case-ID-based tracing genuinely practical at the scale this system operates at — a structured query across the log store can retrieve every event tied to one case in milliseconds, whereas searching free-text logs across months of high-volume activity would be far too slow to be useful during an active compliance inquiry or incident.

Each service in this architecture is independently deployable, packaged and orchestrated so that the always-on, latency-sensitive detection pipeline scales independently from the steadier, workflow-oriented case management path, and again independently from the periodic, lower-throughput filing and submission path.

Progressive Delivery for Detection Logic

Because a bug in the scoring model or a detection rule could silently suppress genuinely suspicious alerts, or conversely flood investigators with noise, changes to the Transaction Monitoring Engine are rolled out through shadow deployment first — the new logic runs in parallel against live traffic without affecting real alerts, and its output is compared against the existing production logic before it is trusted to go live, rather than being validated purely through offline testing against historical data.

Configuration as Governed Data

Typology definitions, scoring thresholds, and deadline computation rules are treated as versioned configuration, deployed through their own reviewed and approved pipeline, distinct from application code releases. This lets the compliance function update detection policy in direct response to new regulatory guidance without waiting on an engineering release cycle, while still preserving a clear, auditable record of exactly which policy version was active for every single case.

Infrastructure as Code and Environment Parity

The complete platform topology — service definitions, network policies, database clusters, scaling rules — is defined declaratively and version-controlled rather than manually configured through a cloud console. This gives two important properties directly relevant to this domain: an auditor can be shown exactly what infrastructure state was active at any point in the platform’s history, and a full disaster-recovery environment can be reliably reconstructed from the same definitions used in production, avoiding the common and dangerous failure mode where a rarely-used recovery environment has silently drifted out of sync with what production actually looks like.

Cost Optimization

Historical case and evidence data spanning several years of mandatory retention can become a significant, steadily growing storage cost if left unmanaged. A tiered storage lifecycle policy automatically moves older, closed-case data to cheaper, lower-access-frequency storage classes after a defined window, while keeping recently active and recently closed cases on fast storage, striking a balance between ongoing cost and the occasional, legally important need to retrieve older records for a regulator inquiry or internal audit years after a case was originally closed.

Environment Isolation for Sensitive Data

Staging and testing environments use synthetic or heavily anonymized case data rather than real customer and transaction information, since case narratives in particular can contain sensitive personal and behavioral detail that has no legitimate reason to exist outside the tightly access-controlled production environment.

Primary Store Choice

Case records, deadlines, and the audit ledger require strong consistency and transactional guarantees, since these are legally significant financial and compliance records where “approximately correct” is never acceptable. A distributed relational database, or a distributed SQL engine offering strong consistency at scale, is the natural fit for this core data, in the same way it is for any workflow where correctness matters more than raw write throughput.

Where a Different Store Fits Better

The raw transaction stream feeding the monitoring engine, and the large volume of dismissed, low-value alerts, are better suited to a high-throughput, horizontally scalable store optimized for high-volume writes and time-series style access patterns, since this data is written constantly, read comparatively rarely in full, and does not need the same multi-row transactional guarantees as case and ledger data. This is a clear example of polyglot persistence — using a different storage engine for the always-on detection firehose than for the smaller, slower, legally weighty case workflow.

Caching Strategy

Investigator dashboards and queue views are cached aggressively with short expiry, since a few seconds of staleness on a queue ordering view is acceptable, while the underlying case state transitions always write directly to the primary store and never go through the cache. Cache invalidation is event-driven, triggered the instant a case changes state or priority, rather than relying purely on a fixed expiry window that could show an investigator a stale, already-resolved case as if it still needed attention.

Load Balancing

Investigator-facing API traffic is distributed across gateway instances using health-check-aware load balancing, ensuring traffic never lands on an instance that is mid-restart or otherwise unhealthy. Internally, calls from Case Management to supporting services like the Customer Risk Profile Service go through client-side or mesh-based load balancing, so a single slow profile-service instance cannot become a bottleneck for every investigator pulling context across the platform.

Replication and Indexing in Detail

Within a region, the primary shard for each case partition replicates synchronously to at least one standby, so a failover promotes a standby with zero loss of already-acknowledged writes. Across regions, replication is asynchronous, trading a small, bounded replication lag for the ability to avoid adding cross-region latency to every single case update. The store is indexed around the specific questions the system actually needs answered quickly — “all open cases assigned to investigator X,” “all cases with a deadline before time Y,” and “the full linked-case graph for account Z” — translating into composite indexes on assignee plus state, and on deadline timestamp plus state, so the Deadline Tracking Service’s core query stays fast even as the total volume of historical, closed cases grows into the millions.

The system exposes at least two very different API surfaces, and treating them identically is a common design mistake. The investigator-facing API is an internal, tightly access-controlled interface optimized for the case management workflow, queue views, and evidence gathering. The regulator submission interface speaks in the rigid, standardized schema each specific regulator mandates, changes rarely, and demands strict validation and delivery guarantees, much like any external, standards-governed integration point.

Service Boundaries

Each microservice owns its own data and exposes a narrow interface, following the same discipline used across well-designed distributed systems generally. The Case Management Service never writes directly into the Audit Ledger’s storage; it publishes an event, and the Audit Ledger service is solely responsible for durably and immutably recording it. This separation ensures that a bug or slowdown in, say, the investigator dashboard’s read path can never accidentally corrupt the legally significant audit record, because there is no shared mutable data between them.

Reliability of the Regulator Submission Path

The Submission Gateway must be designed assuming the regulator’s own intake system will occasionally be slow or temporarily unavailable. Submissions are retried with exponential backoff, and every attempt, success, and failure is logged with full request and response detail, since being able to prove exactly when and how a filing attempt was made is often as legally important as the filing’s content itself if a dispute over timeliness ever arises.

Rate Limiting and API Fairness

The investigator-facing API applies rate limits per calling service and per user, not just globally, so that a misbehaving internal integration or a runaway automated script cannot degrade response times for every other investigator sharing the same gateway fleet. This matters more in this domain than in many others, because a slow investigator experience during a deadline crunch is not merely an inconvenience; it directly eats into the fixed legal time budget available for genuine investigation.

The Saga pattern is worth a closer look here because it directly answers a very natural interview question: “how do you coordinate detection, investigation, approval, and filing across multiple services without one enormous distributed transaction?” Instead of trying to lock detection, case management, and filing together atomically, each stage publishes an event when it completes, and the next stage reacts to that event. If a later stage fails — for example, a filing submission is rejected by the regulator gateway for a formatting issue — a compensating action routes the case back to a “filing prepared” state for correction, rather than attempting to roll back a transaction that spans services and was never atomic to begin with.

The Outbox Pattern, Explained Simply

A subtle but important bug in early designs of this kind of system is the gap between “we saved the case’s new state to the database” and “we published the event telling other services about it.” A crash between those two steps can leave the database correct while every other service remains unaware anything happened. The outbox pattern closes this gap by writing the event into an outbox table in the exact same database transaction as the state change itself, so both succeed or fail together atomically, and a simple background publisher reads and forwards new outbox entries, retrying safely since the underlying record is already durably committed. This small structural discipline quietly prevents an entire category of hard-to-reproduce bugs where one service’s view of a case has silently fallen out of sync with another’s, a failure mode that is especially costly in a domain where every service’s view of a case may eventually need to agree with what an external regulator was actually told.

Best practices in this domain tend to come from painful, real regulatory experience rather than pure theory, because the failure modes here are rarely dramatic outages — they are quiet, slow drifts that only surface weeks or months later during a regulator examination or an internal audit.

Best Practices

Common Mistakes

One especially valuable discipline is a regular, independent “quality review” of a sample of closed cases — including both filed and dismissed ones — checked by someone outside the original investigation, specifically to catch whether dismissals were consistently well-justified and whether filed narratives were consistently strong. Over time, this review process becomes one of the richest sources of both detection tuning improvements and investigator training feedback, because it surfaces the gap between how the system is designed to behave and how it is actually behaving for real cases.

Another practice worth calling out is treating investigator feedback on alert quality as a first-class input into the detection pipeline, not an informal side conversation. When an investigator dismisses an alert as a false positive, capturing a brief, structured reason code for that dismissal — rather than a free-text note nobody ever reads again — creates a continuously growing, labeled dataset that can be fed back into scoring model retraining and rule tuning. Platforms that skip this feedback loop tend to see their false-positive rate slowly climb over time as genuine transaction patterns evolve, since the detection layer never gets a structured signal telling it what it consistently got wrong.

Large banks and payment platforms all operate systems that closely resemble the architecture described here, even though implementation details vary by institution and regulator. Major global banks maintain dedicated Financial Intelligence Units supported by transaction monitoring platforms that closely mirror the detection, alerting, and case management pipeline described in this tutorial, and these institutions have historically faced some of the largest regulatory fines in financial history specifically tied to gaps in this kind of system — a clear signal of just how seriously regulators treat the reliability of this exact workflow.

Insurance and Securities Firms

Beyond banking and payments, insurance companies and securities brokerages face closely related suspicious activity reporting obligations, often under separate but structurally similar regulatory regimes. An insurance policy purchased with an unusually large upfront payment and cancelled shortly after for a refund, for example, can resemble a laundering pattern in much the same way a rapid sequence of transfers does for a bank, reinforcing that the architecture described in this tutorial — continuous monitoring, deadline-driven case management, dual approval, and a schema-flexible filing layer — generalizes well beyond traditional banking into any regulated financial services context that carries a similar legal reporting obligation.

If you remember nothing else from this tutorial, remember this: in most systems, a missed step can be quietly retried. In this system, a missed deadline is a legal violation that cannot be undone after the fact, no matter how good the underlying investigation turns out to be. Build for the deadline and the audit trail first, and the rest of the architecture follows naturally.

Key takeaways to carry into an interview

Taken together, these principles describe a system that looks, on the surface, like a specialized workflow tool, but underneath is a careful application of distributed systems fundamentals — stateful stream processing, event sourcing, durable scheduling, and strict access control — all in service of a genuinely important goal: helping a financial platform meet a serious legal obligation reliably, on time, every time, at a scale no human team could manage alone.