Transaction Monitoring Architecture: Rules, ML, Triage and SAR Filing (2026)

Systems and architecture analysis only. This is not legal, compliance or financial advice; consult your compliance officer and counsel for obligations that apply to your institution.

Most anti-money-laundering programs do not fail because they lack a detection model. They fail because the plumbing around the model produces more alerts than people can read, in a form investigators cannot act on, with a feedback loop that never reaches the tuning team. Industry commentary routinely describes the large majority of alerts from legacy rule systems as false positives, although published figures vary widely by institution and I treat any single number as indicative at best.

Transaction monitoring is the continuous analysis of customer activity to surface behavior consistent with money laundering, terrorist financing or sanctions evasion, and to route it to a human who decides whether a suspicious activity report is warranted. In 2026 the pressure is two-sided: regulators in the United States are signalling a shift toward effectiveness over volume, while the European Union is building a single rulebook and a new supervisor.

This post lays out a reference architecture. You will leave with the pipeline stages, a clear comparison of rules and machine learning, a triage and case design that survives audit, the SAR filing mechanics, sanctions screening as a parallel path, and a runnable scoring sketch.

What this covers: the regulatory frame, the end-to-end pipeline, rules versus ML, alert triage and case management, SAR filing, sanctions screening, tuning and model governance, and the failure modes that sink programs.

Context and Background

Transaction monitoring exists because of a legal duty, not a product category. In the United States, the Bank Secrecy Act (BSA) and its implementing regulations require banks to file a suspicious activity report (SAR) for transactions of $5,000 or more where the institution knows, suspects or has reason to suspect the activity involves illicit funds, is designed to evade BSA requirements, or has no apparent lawful purpose. Money services businesses face a lower $2,000 threshold. The Financial Action Task Force (FATF) sets the international analogue in Recommendation 20, which obliges institutions to report suspicious transactions to the financial intelligence unit, and Recommendation 10 on customer due diligence supplies the context monitoring relies on. The FATF recommendations are available at fatf-gafi.org.

The regulatory weather is changing in both major jurisdictions. On April 7, 2026, FinCEN issued a proposed rule to reform AML and counter-terrorist-financing (CFT) program requirements, replacing a July 2024 proposal. As described in FinCEN’s announcement, it emphasizes institutions assessing their own illicit finance risks, directing resources to higher risks, and discouraging examiners from substituting subjective judgment for a reasonably designed risk-based program. The comment period closed June 9, 2026; check the current status before assuming any final text.

Earlier, on October 9, 2025, FinCEN and the federal banking agencies issued four SAR FAQs. They clarified that activity near the $10,000 currency transaction report (CTR) threshold does not by itself require a SAR without knowledge or suspicion of evasion, that institutions need not systematically review accounts after a SAR to see whether activity continued, that the old 90 and 120 day continuing-activity cadence is not a requirement, and that there is no BSA requirement to document a decision not to file. A good summary is in Mayer Brown’s note. Many institutions will keep documenting anyway, because examiners and internal audit still ask for it.

In the European Union, the Anti-Money Laundering Regulation (AMLR) becomes directly applicable on July 10, 2027, and the new Anti-Money Laundering Authority (AMLA) is due to begin direct supervision of a limited set of high-risk cross-border institutions from January 1, 2028, per secondary sources I could verify but not against the primary text. Treat those dates as the working timeline and confirm them with the official Journal publications.

The architectural consequence is the same everywhere. Regulators ask three questions: did you detect the risky behavior, can you show why you did or did not escalate, and can you prove the system you run is the system you validated. The rest of this post is the engineering needed to answer all three.

Monitoring also does not stand alone. It consumes risk ratings produced by onboarding and refresh processes, so the design of perpetual KYC determines how good your customer context is. And it overlaps, but is not identical to, fraud detection: scam payments that a customer authorizes are a fraud typology with a different control set, discussed in authorized push payment fraud detection. The money laundering that follows a scam, as mule accounts move the proceeds, is squarely a monitoring problem.

Reference Architecture for Transaction Monitoring

A transaction monitoring system is a pipeline with six stages: ingest events from payment and core systems, enrich them with customer context, detect using rules and models, consolidate detections into alerts, triage and investigate alerts in a case system, and file reports while feeding outcomes back to detection. The feedback edge is what separates a learning program from a static one.

Figure 1: Reference pipeline. Rules and ML run side by side over the same enriched features; every closed case writes a label back to the model.

The diagram shows the shape. Core banking, card, wire and instant-payment systems publish events to a bus. A feature store holds customer risk ratings, expected activity from onboarding, peer group, and rolling aggregates. A rules engine and an ML scoring service both read events and features, and a single alert generator merges their output, together with sanctions screening hits, into one queue. Analysts work cases, make SAR decisions, and the labels flow back.

Ingestion and enrichment

Detection quality is capped by data quality. Monitoring needs the full transaction record, not just amount and timestamp: counterparty name and account, originator and beneficiary details from the payment message, channel, device and IP where available, country of each leg, and the product. For cross-border wires the ISO 20022 message formats carry structured party and purpose fields that older formats flattened into free text, which materially helps both screening and network analysis.

Enrichment joins that event to context that changes its meaning. A $9,500 cash deposit means something different for a retail account with a documented cash-intensive business than for a student account opened last month. The join targets are the customer risk rating, expected account activity captured at onboarding, industry code, geography, relationship graph (shared addresses, devices, directors), and watchlist status. When this context is stale, every downstream stage is guessing.

Latency requirements differ by use. Most AML detection is batch or micro-batch, run daily or intraday over windows, because many typologies only appear across days or weeks. Real-time paths are reserved for sanctions screening and for instant-payment rails where funds settle in seconds and a post-hoc alert cannot stop movement. A pragmatic design runs a streaming layer that maintains windowed aggregates and a batch layer that recomputes them for backfill, with both writing to the same feature definitions so a scenario behaves identically in either.

The feature layer and windows

The workhorse of monitoring is the windowed aggregate: count and sum of transactions per customer, per counterparty and per channel over 1, 7, 30 and 90 days, plus ratios such as inbound to outbound within 48 hours, which is a classic pass-through signal. Peer-relative features compare a customer to a cohort defined by segment, geography and product, which tolerates behavior that is unusual in absolute terms but normal for the business.

Define each feature once, with a version, an owner and a point-in-time definition. Point-in-time correctness matters for two reasons. Model training must not leak future information, and, more practically, when an examiner asks why an alert fired on March 3, you must be able to reconstruct the exact feature values the system saw that day, not today’s recomputed values. This is the same discipline described in event sourcing and bitemporal data for audit trails: store what was known and when it was known, and replay deterministically.

Alert generation and deduplication

Detections are not alerts. A customer who trips three scenarios and one model on the same day should produce one alert with four reasons, not four alerts routed to four people. The alert generator groups detections by customer (or by a linked entity group), assigns a composite priority, and attaches the evidence: triggering transactions, feature values, the scenario or model version, and the threshold in force.

Alert generation is also where a below-the-line sample is drawn. Below-the-line testing means sampling activity that did not meet the alerting threshold and having analysts review it, to estimate what you are missing. Regulators expect threshold choices to be justified empirically, and this sample is the cheapest evidence you can produce.

Rules versus ML in Transaction Monitoring

Rules are explicit scenarios such as “cash deposits over a threshold across several days.” Machine learning scores behavior statistically, either by finding outliers or by predicting historical outcomes. Neither dominates. Rules are transparent and easy to defend; ML finds patterns rules cannot express and ranks alerts better. The strongest 2026 architecture layers them: rules as the regulatory floor, ML as the prioritization and discovery layer.

Figure 2: Detection layer. Rule scenarios and model scores converge at deduplication, while a below-the-line sample audits the thresholds.

What rules do well, and where they break

A scenario is a parameterized pattern: a customer segment, a window, a count or amount threshold, and an exclusion list. Examples include structuring signals (repeated deposits just under a reporting threshold), rapid movement of funds (credit followed by near-equal debit within a short period), high-risk-jurisdiction flows, dormant account reactivation, and round-amount transfers. They map neatly onto typologies published by FATF and national FIUs, which makes mapping to a regulator’s expectations straightforward.

Their strengths are explainability and control. A compliance officer can read the logic, change one threshold and predict the effect. Their weaknesses are equally structural. Thresholds are static cliffs: a customer at 99% of a threshold is invisible and one at 101% is an alert, though the risk is nearly identical. Criminals who learn the thresholds structure around them. Rules also multiply: mature institutions accumulate dozens to hundreds of scenarios, each with segment-specific parameters, and the tuning burden grows combinatorially.

The usual outcome is a very high false-positive rate. Without a published, comparable benchmark, I will only say that many institutions report that most alerts close without a SAR, and that this is the problem ML is usually brought in to attack. The rate depends heavily on how thresholds were tuned and how segments were defined, so any vendor claim of a specific reduction should be validated on your own data.

What ML adds

Two families of model are used, and they answer different questions.

Supervised models learn from historical labeled outcomes: alerts that led to SARs or case escalations are positives, alerts closed as false positives are negatives. They are usually gradient-boosted trees over the engineered features, because tree ensembles handle mixed tabular data well, train quickly, and can be explained with attribution methods. Their typical role is alert scoring: take the alerts that rules already generate and rank them so analysts see the likeliest true positives first. This is a lower-risk deployment because the rules still define what can alert, and the model only reorders and, if you choose, suppresses the bottom of the list.

Unsupervised models (isolation forests, autoencoders, clustering) find behavior that deviates from the norm without labels. They surface unknown typologies and are valuable precisely because labels are scarce and biased: you only have labels for what your old rules caught. The cost is explainability. “This account is 4.2 standard deviations from its peer cluster” is not a reason an examiner or an investigator accepts without translation into features a person can check.

Graph methods add a third dimension. Money laundering is a network phenomenon: layering through many accounts, shared devices, circular flows, fan-in and fan-out around a mule. Features such as degree, community membership, and flow through a node can be computed from the transaction graph and fed into either family. Graph database or graph-feature pipelines are costlier to run but target typologies that per-account rules cannot see.

A decision matrix

Dimension	Rules	Supervised ML	Unsupervised / graph
Explainability	High, readable logic	Medium, needs attribution	Low to medium
Regulatory defensibility	Highest, maps to typologies	Good with validation	Needs strong governance
Handles novel patterns	Poor	Poor, learns past	Best
Alert ranking quality	Weak, binary	Strong	Moderate
Label dependence	None	Heavy, biased labels	None
Tuning effort	High, many thresholds	Moderate, retraining	Moderate, monitoring drift
Typical role	Regulatory floor	Prioritize and suppress	Discovery

The labeling trap

Supervised models inherit the biases of the process that produced labels. If analysts only investigate alerts above a score or from certain scenarios, the label set contains no information about transactions that never alerted, and a model trained on it learns to rediscover your existing rules. The remedies are the below-the-line sample described earlier, deliberate randomization of a small slice of alert routing, and treating “closed without SAR” as a weak negative rather than ground truth: a case can close as unfounded simply because the analyst lacked data. Also note that a SAR filed is an escalation decision, not a conviction; it is a noisy proxy for true laundering.

Alert Triage, Case Management and SAR Filing

Alert triage is the process of deciding quickly and consistently which alerts deserve investigation. A good triage design uses tiered review: a first level closes obvious false positives with a structured rationale, a second level investigates real concerns, and a compliance officer approves any SAR. Scoring and routing keep high-risk alerts ahead of low-risk ones and protect the filing clock.

Figure 3: Alert lifecycle. Closures emit model feedback labels; approved SARs are filed, retained and revisited through continuing-activity review.

Designing the triage queue

Triage is a queueing problem with a cost function. Analysts are the scarce resource, alerts arrive stochastically, and each has a different expected value. The levers are routing, ordering and automation.

Routing sends alerts to people with the right skills: trade-based laundering to one team, cash-intensive business to another, sanctions to a specialist group. Ordering uses the composite risk score so that a high-priority alert never ages behind a hundred low-value ones. Automation closes or enriches alerts without a human where the evidence is mechanical, for example auto-dismissing a repeat alert on a counterparty already reviewed and cleared within a defined lookback with no material change in behavior.

A worked example with illustrative numbers shows why ranking matters. Suppose a team of 20 analysts each closes 25 alerts a day, so capacity is 500 alerts. Rules generate 1,200 alerts daily, and 3% are genuine escalations, so 36 true positives are buried in the pile. With first-in-first-out ordering, the team reviews 500 of 1,200 and, on average, finds about 15 of the 36. If a model ranks alerts such that the top 500 contain 80% of true positives, the same team finds about 29. Nothing about headcount changed; ordering did. These figures are illustrative, not measured benchmarks, but the arithmetic is general: ranking quality converts directly into found risk under a fixed capacity.

The same arithmetic exposes the danger of ML-based suppression. If you auto-close the bottom 40% of alerts, you are accepting some false-negative rate on that slice. Make that choice explicitly, size it with the below-the-line sample, record the approval, and review it periodically. Many programs begin with prioritization only and move to suppression after months of parallel running.

Investigation and the evidence package

A second-level investigator reconstructs the story. The case system should assemble the evidence automatically so the analyst spends time judging, not copying data: the account and customer profile, the expected-activity profile, a timeline of transactions with counterparties, linked parties and accounts, prior alerts and SARs on the subject, adverse media, and open-source research notes. A visual of the flow of funds is a large time saver in layering cases.

Every decision needs a recorded rationale in structured fields plus free text. The structure matters for two reasons: it feeds model training as cleaner labels (reason codes such as “explained by documented business activity” are far more useful than a bare “closed”), and it lets quality assurance sample consistently. After the October 2025 FAQs, FinCEN states there is no BSA requirement to document a decision not to file a SAR. Most institutions will still retain a short rationale, because it supports internal audit, model validation and examiner dialogue, and because its absence makes later reconstruction hard.

Case management as a state machine

Model the case as an explicit state machine with allowed transitions, timers and role permissions: open, assigned, in investigation, pending information, SAR recommended, approved, filed, closed. Each transition records actor, time and reason. Two controls deserve special attention. Segregation of duties prevents the person who drafts a SAR from being the only approver. And the clock: for filing deadlines the system should start timers from the date of initial detection of facts that may constitute a basis for filing, not from the date a case was assigned.

For long-running investigations that span systems, such as requesting documents from branches, waiting on customer responses, or coordinating with a sister entity, orchestration choices matter. The same trade-off described in saga orchestration versus choreography applies: a central workflow engine gives you a visible, auditable timeline and timers, while event choreography is flexible but harder to prove complete to an examiner. For regulated case flow I lean to orchestration.

SAR filing mechanics (United States)

For US banks, the rule in 31 CFR 1020.320 requires filing within 30 calendar days of initial detection of facts that may constitute a basis for filing. If no suspect is identified at that time, the period may extend to 60 days, but no further. Records, including the SAR and supporting documentation, are retained for five years from filing. SARs are filed electronically through FinCEN’s BSA E-Filing System.

Three properties of the regime shape system design. First, confidentiality: disclosing a SAR or its existence to the subject is prohibited, so access control and audit logging for SAR data must be tight, and customer-facing systems must never leak SAR status. Second, the safe harbor in 31 U.S.C. 5318(g)(3) protects institutions from civil liability for good-faith reporting, which is why institutions err toward filing when uncertain, and why regulators are now trying to rebalance toward quality. Third, the narrative is the product: FinCEN has long emphasized that the narrative should answer who, what, when, where, why and how, and law enforcement reads it directly.

The October 2025 clarifications relaxed several burdens. Continuing-activity SARs are no longer tied to a mandated 90 and 120 day review cycle, institutions may use risk-based policies for post-SAR review, and structuring-adjacent activity does not automatically require a SAR. Architecturally this means your continuing-activity scheduler should become configurable policy rather than hard-coded timers. Whether to keep the older cadence is a risk-based call, and I would keep it for high-risk subjects until your policy documents a justified alternative.

Generative AI in the narrative workflow

Large language models are an obvious fit for drafting narratives from structured case facts. The control design matters more than the model. Constrain the model to the case data supplied, include citations back to the source records, forbid unsupported inferences, and keep the investigator as the accountable author who reviews and edits the text before submission. Log prompts, outputs and edits. Do not send customer data to external services without the data-protection and vendor-risk approvals your institution requires. The investigator remains responsible for the filing; AI shortens drafting time, it does not shift accountability.

Other jurisdictions in brief

Equivalent regimes differ in thresholds and clocks. The UK requires suspicious activity reports to the National Crime Agency with a consent regime that can suspend a transaction while a decision is awaited, an operational difference that affects holding logic in your payment path. EU member states report to their national FIUs today, with harmonization under the AMLR and AMLA coming. I have not verified each jurisdiction’s current deadlines for this post, so confirm local rules before building timers.

Sanctions Screening as a Parallel Path

Sanctions screening is related to transaction monitoring but architecturally different. Monitoring looks for suspicious behavior over time and tolerates hours or days of latency. Sanctions screening compares parties and payment data against lists, such as the OFAC Specially Designated Nationals (SDN) list, EU consolidated list and UN lists, and it must act before funds move. Sanctions liability is largely strict, so the design goal is a very low miss rate with a manageable hit volume.

Figure 4: Real-time screening path. Hits above threshold hold the payment; clear messages release without human touch.

Matching is the hard part

Names are messy: transliteration (Arabic, Cyrillic and Chinese names have multiple Latin renderings), word order, titles, initials, and deliberate obfuscation. Screening engines combine normalization, phonetic algorithms, edit-distance measures such as Jaro-Winkler and Levenshtein, token-set comparison, and secondary identifiers (date of birth, nationality, passport number, address) to score a candidate match. Lowering the fuzzy threshold catches more variants and produces more false hits; raising it does the opposite. This is precisely the trade-off of alert tuning, but with an asymmetric penalty because missing a true match is far worse than reviewing a false one.

Ownership adds a layer. OFAC’s 50 Percent Rule treats entities owned 50% or more in the aggregate by blocked persons as blocked themselves, even if they are not named on the list. Screening only the listed names therefore misses blocked subsidiaries. The architecture needs ownership data, from KYC and beneficial-ownership records or a commercial provider, and graph traversal to compute aggregate ownership.

Screening patterns

Screen at three points: at onboarding and on every customer-data change, in batch whenever lists change (re-screening the customer base against new designations), and on every payment in real time against originator, beneficiary, intermediaries and free-text fields. List updates are events; the system should recompute only affected customers rather than a full rescan where possible, and it must be able to prove which list version was in force at a given moment.

Good-guy lists, also called allow lists, suppress repeated false hits for a customer-and-list-entry pair that an analyst has already cleared. They save substantial effort but are a control risk: each entry must carry an expiry, an approver and an automatic invalidation if the customer’s identifiers or the list entry change.

Finally, sanctions hits and transaction-monitoring alerts about the same subject should converge on the same entity view. An analyst reviewing a payment hit should see the customer’s open AML alerts, and vice versa. Treating them as separate silos is a common cause of missed linkage.

Tuning, Validation and Model Governance

A monitoring system that is not tuned drifts out of calibration as customer behavior, products and criminal typologies change. Tuning is not a project you finish; it is a recurring operating process with evidence.

Threshold tuning with data, not instinct

The standard method is to rerun a scenario at several threshold settings over historical data and compare alert volume, the share of alerts that led to escalation, and the share of known suspicious activity captured. Plot alert volume against captured-risk and look for the knee where additional alerts add little. Combine that with the below-the-line sample to estimate what lies under the current cut.

Segment before you tune. A single threshold for all retail customers is almost always wrong; a segment of salaried workers and a segment of small cash businesses have different distributions. Mature programs segment by customer type, product, geography and risk rating, and tune each segment separately, subject to enough volume per segment for the statistics to mean anything.

Model risk management

ML models used in compliance are subject to model risk management expectations. In the US, the supervisory guidance on model risk management (SR 11-7 from the Federal Reserve and the OCC’s companion bulletin) has long framed the expectations: conceptual soundness, ongoing monitoring and outcomes analysis, and independent validation. Interagency statements have also encouraged responsible innovation in AML, including AI, but I recommend confirming the current guidance text rather than relying on my summary, since the supervisory landscape has been moving.

Practically, treat each model as a governed asset: a model card with intended use and limits; documented training data and labeling process; performance metrics beyond accuracy (precision at the review capacity, recall of known SAR cases, lift over the rules baseline); stability monitoring such as population stability index on inputs and score distributions; and a challenger process. Because SAR-filing populations are small and imbalanced, validate on time-based splits and report confidence intervals, not a single AUC.

Explainability and attribution

Investigators and examiners need reasons. For tree models, per-alert feature attributions (for example SHAP values) translate a score into “high inbound-to-outbound ratio over 48 hours, new counterparties, high-risk corridor.” Store the top reasons with the alert. This also catches silly drivers: if the top attribution is a data-quality artifact, you found a pipeline bug before an examiner did.

A runnable scoring sketch

The following Python sketch shows the layered idea at small scale: a rule flags the alert, a gradient-boosted model ranks it, and the combined priority orders the queue. Data is synthetic and the numbers are illustrative only.

import numpy as np
import pandas as pd
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import average_precision_score

rng = np.random.default_rng(7)
n = 20000

df = pd.DataFrame({
    "cash_7d": rng.gamma(2.0, 1500, n),
    "in_out_ratio_48h": rng.beta(2, 5, n) * 1.2,
    "new_counterparties_30d": rng.poisson(2, n),
    "high_risk_corridor": rng.binomial(1, 0.05, n),
    "customer_risk": rng.integers(1, 4, n),
})

# Synthetic ground truth: pass-through behavior plus corridor risk
logit = (-6.0 + 3.0 * (df.in_out_ratio_48h > 0.8)
         + 1.2 * df.high_risk_corridor
         + 0.25 * df.new_counterparties_30d
         + 0.0002 * df.cash_7d)
p = 1 / (1 + np.exp(-logit))
df["suspicious"] = rng.binomial(1, p)

# Rule layer decides what can alert
df["rule_alert"] = ((df.cash_7d > 9000) |
                    (df.in_out_ratio_48h > 0.9) |
                    (df.high_risk_corridor == 1)).astype(int)

features = ["cash_7d", "in_out_ratio_48h", "new_counterparties_30d",
            "high_risk_corridor", "customer_risk"]
X_tr, X_te, y_tr, y_te, r_tr, r_te = train_test_split(
    df[features], df.suspicious, df.rule_alert,
    test_size=0.3, random_state=7, stratify=df.suspicious)

model = GradientBoostingClassifier(random_state=7).fit(X_tr, y_tr)

alerts = X_te[r_te == 1].copy()
alerts["label"] = y_te[r_te == 1]
alerts["score"] = model.predict_proba(alerts[features])[:, 1]

capacity = 100  # analyst review budget, illustrative
fifo = alerts.head(capacity)["label"].sum()
ranked = alerts.sort_values("score", ascending=False).head(capacity)["label"].sum()
print(f"alerts={len(alerts)} true={alerts.label.sum()}")
print(f"found with FIFO={fifo}  found with ML ranking={ranked}")
print("PR-AUC on alerts:", round(average_precision_score(alerts.label, alerts.score), 3))

The point is the comparison at fixed capacity, not the absolute numbers. In production you would add time-based splits, calibration, reason codes, and a randomized slice that bypasses the model so you keep collecting unbiased labels.

Trade-offs, Gotchas, and What Goes Wrong

The most common failure is alert volume inflation without learning. A program adds scenarios after each audit finding, never retires any, and ends with an investigator workforce that closes alerts mechanically. Cure it with scenario lifecycle management: every scenario has an owner, a hypothesis, a measured yield, and a retirement review.

The second is data lineage failure. Monitoring silently misses a product because a feed broke, or a field changed meaning after a core upgrade. Reconciliation of record counts and amounts between source systems and the monitoring store, with alerting on gaps, is unglamorous and essential. Regulatory penalties in this area have repeatedly involved institutions that failed to monitor entire segments of activity rather than ones with subtle models.

Third, model drift and feedback loops. A model trained on alerts shaped by old rules inherits their blind spots; if it then suppresses alerts, it starves itself of the contradicting evidence. Keep randomized exploration and a champion-challenger setup. Fourth, explainability gaps: a black-box score with no reason codes is hard to defend in an exam, and a regulator may reasonably reject suppression based on it.

Fifth, latency traps in real time paths. A screening service that times out must fail in a defined way. Failing open risks a prohibited payment; failing closed freezes legitimate flows. Decide per rail, document it, and test it.

Sixth, privacy and security. Monitoring concentrates sensitive data, and SAR confidentiality adds legal exposure for leaks. Apply least-privilege access, field-level audit logging, and strict separation of SAR data from systems staffed by relationship managers. Cross-border data-sharing restrictions can also complicate group-wide monitoring and are a design constraint in multinational deployments.

Finally, the people problem. Automation shifts analyst work from clearing noise to making harder calls. Without training, quality assurance and a defensible feedback process, you get inconsistent decisions at higher speed.

Practical Recommendations

Start from the regulatory floor and an honest measurement of today’s state. Inventory scenarios, their yields and their data dependencies. Establish the below-the-line sample before touching any threshold, because without it you cannot tell whether a change improved detection or merely reduced workload.

Introduce ML as a ranking layer first. Keep rules as the generator, score alerts, order the queue, and measure found-risk at fixed capacity against the old ordering. Only after months of parallel running, and with documented approval, consider suppression of the lowest-scored slice, with a randomized bypass to protect future training data.

Invest disproportionately in the case system and feedback labels. Structured disposition reasons, evidence auto-assembly, and a state machine with timers pay back more than another model. Model SAR deadlines as first-class timers from initial detection, and make continuing-activity review a configurable policy now that the US rules allow risk-based approaches.

A short checklist:

Version every feature, scenario and model; reconstruct any alert as of its date.
Reconcile source-to-monitor counts daily and alert on gaps.
Segment before tuning; document the evidence for each threshold.
Run a below-the-line sample and a randomized exploration slice.
Capture structured disposition reasons for every closure.
Store per-alert attribution and show it to investigators.
Enforce SAR confidentiality and segregation of duties in access control.
Define fail-open or fail-closed behavior per payment rail for screening.
Track the US program-rule and EU AMLR and AMLA timelines and re-plan as final texts land.

Frequently Asked Questions

What is transaction monitoring in AML?

Transaction monitoring is the ongoing review of customer transactions and behavior to detect activity that may indicate money laundering, terrorist financing or sanctions evasion. Systems apply rules and, increasingly, machine learning to generate alerts, which analysts triage and investigate. When suspicion is established, the institution files a suspicious activity report with the financial intelligence unit, such as FinCEN in the United States. It differs from one-time onboarding checks because it is continuous.

How is transaction monitoring different from sanctions screening?

Transaction monitoring looks for suspicious patterns of behavior over time, usually in batch or micro-batch, and tolerates latency. Sanctions screening compares names and payment details to government lists and must usually run in real time, before funds are released. Monitoring outputs alerts that may become SARs; screening outputs hits that must be resolved as true or false matches, and true matches require blocking or rejecting and reporting under the applicable sanctions rules.

How long do you have to file a SAR?

For US banks, a SAR is due within 30 calendar days of initial detection of facts that may constitute a basis for filing, extendable to 60 days if no suspect has been identified. Records are kept for five years. Other jurisdictions and institution types differ, so confirm local rules. Note that October 2025 FAQs relaxed continuing-activity expectations but did not change these core filing clocks, to my knowledge.

Can machine learning replace rules in transaction monitoring?

In most programs it does not fully replace them. Rules provide transparent, regulator-mapped coverage and a defensible floor, while ML improves alert ranking and can discover new patterns. The common 2026 pattern is rules generating alerts and a model prioritizing them, with careful governance, validation and explainability. Replacing rules entirely requires strong evidence of equivalent or better coverage, which below-the-line testing and parallel runs can provide.

What is alert triage and why does it matter?

Alert triage is the first-pass decision on which alerts merit investigation and in what order. It matters because investigator capacity is fixed while alert volume is not; ordering by risk converts model quality into found suspicious activity. Good triage routes alerts by skill, applies tiered review, records structured closure reasons, and protects filing deadlines. Poor triage lets high-risk alerts age behind noise and weakens the evidence regulators examine.

Does generative AI belong in SAR filing?

It can help draft narratives from structured case facts, reducing investigator time, but the investigator remains accountable for accuracy. Constrain the model to case data, require source citations, log prompts and outputs, and require human review before submission. Handle customer data under your institution’s data-protection and vendor-risk controls, and be mindful that SAR confidentiality rules limit where this data may be processed.