Transaction Monitoring Rules vs. Machine Learning Models

Last updated: September 2026

Transaction monitoring rules vs machine learning is rarely an either-or decision in anti-money laundering (AML) programs. Rules carry coverage: the known AML typologies and policy lines an examiner can map to a red flag. Machine learning models carry context and priority where fixed thresholds misfire. What differs most is the evidence each approach owes an examiner, and the revised model risk guidance of April 2026 changed how that question is asked.

TL;DR

• Rules cover known typologies and policy lines. Machine learning models compare each customer with its own history and its peers, and rank alerts by risk.

• Under the revised model risk guidance (SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026), the exclusion for deterministic rules applies only where no statistical, economic or financial theory underpins their design or use. Each institution classifies its own scenarios and documents the call.

• The guidance never mentions BSA/AML, and the FFIEC manual still expects the monitoring system to be independently validated, whatever its scenarios are called.

• A rule owes a typology mapping, a threshold rationale and testing when it changes. A model owes validation, monitoring after release and effective challenge. Both owe a decision record an examiner can reconstruct.

What is the difference between rules-based and machine learning transaction monitoring?

The difference between rules-based and machine learning transaction monitoring is where the logic that raises an alert comes from. In rules-based monitoring, a person writes down a condition, such as an amount, a count or a pattern over a period, and the system raises an alert when activity meets it. In machine learning monitoring, a model learns what normal activity looks like from historical data, scores new activity against that expectation for the customer or its peers, and flags or ranks what looks unusual.

Bank examiners draw the same line. The examination manual published by the Federal Financial Institutions Examination Council (FFIEC) says that "surveillance monitoring systems include rule-based and intelligent systems," and that intelligent systems "are adaptive and can filter transactions, based on historical account activity or compare customer activity against a pre-established peer group or other relevant data." Vendors often call a rule a scenario.

Programs commonly run both, so the more useful question for a head of risk is what each approach has to prove to an examiner. Whether monitoring runs in real time or in batches is a separate choice, covered in a guide to real-time transaction monitoring.

What do rules do well, and where do they break?

Transaction monitoring rules, often called AML rules or scenarios, work best where a typology or policy line can be written down precisely. A rule maps directly to a named red flag, and a team can change it and explain the change the same day. Examiners know how to read rules: a BSA/AML compliance lead at a community bank said examiners treat an established monitoring vendor as already vetted and focus on how the bank tuned it.

The FFIEC manual attaches an obligation to that clarity: "Management should document and be able to explain filtering criteria, thresholds used, and how both are appropriate for the bank's risks." Rules fail when those thresholds age. A compliance risk strategy officer at a regional bank described rules so old that the bank's portfolio and data had moved beyond what they were written for, which produced a lot of alert volume and little productive work. A threshold shared by customer segments that behave differently also misses the peer comparison that separates normal activity from unusual.

A rule set is explainable only if the institution can see it. A BSA/AML/OFAC compliance manager at a credit union said that when regulators ask how alerts are generated, the team cannot show them the specific rules, because its monitoring vendor exposes only a high-level view. Validators want the same visibility: a BSA/AML/OFAC technology systems manager at a community bank said they will want to "see obviously all of the underlying rules and the logic for the queries," and to query the database themselves.

How to test and document a threshold change so coverage holds is covered in a separate guide to reducing AML false positives.

What do machine learning models do well, and where do they break?

Machine learning models are most useful where a fixed threshold cannot tell normal activity from unusual. A model can compare a customer with its own history and with peers that behave like it, surface patterns no rule anticipated, and rank alerts so analysts see the riskiest first. A director of engineering at a fintech put the case plainly: "machines are better at tuning thresholds than humans."

Models bring costs of their own: they need enough good historical data, labeled with past outcomes, and they are harder to explain. The same engineering director set the limit: "You don't want something super complicated, a model that's not understandable by humans because many times you don't have enough data to go that way." A model should stay as simple as the data supports, because an examiner cannot follow a model nobody can explain.

Explainability gets tested twice. A validator or examiner will ask how the model was built, and an AML compliance manager at an online gaming operator expected the regulator to ask how the team determined "what key coefficients to use for this risk factor" and whether that was documented clearly. The analyst working the alert needs the reasons too, so each model decision should carry reason codes the analyst can see in the queue.

Stacking opaque systems makes a model harder to explain. A senior model risk executive at a regional bank said model risk teams used to complain that machine learning approaches such as neural networks were black boxes, and that now "it's like a black box on top of a black box, right? So there is no transparency into the decisioning that's going on." When one opaque system scores the output of another, outcome testing has to carry more of the weight.

Rules and models, side by side

Rules and machine learning models differ most in the evidence each has to produce.

Whichever column a scenario falls in, the FFIEC manual expects the monitoring system as a whole to be independently validated.

Is a monitoring rule a model under the revised guidance?

A transaction monitoring rule can sit outside the revised definition of a model, but the exclusion is conditional: it covers deterministic rule-based processes only where no statistical, economic or financial theory underpins their design or use. Whether a given scenario meets that condition is a classification each institution has to make and write down.

On April 17, 2026, the Federal Reserve, the OCC and the FDIC issued revised model risk management guidance as SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026. It supersedes SR 11-7 and SR 21-8, the 2021 interagency statement on model risk for BSA/AML systems. The guidance defines a model as "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates." The term "excludes simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use."

Read closely, the rule exclusion carries a condition. A fixed threshold set from policy, with no statistical basis, reads as excluded. A threshold derived from statistical analysis of the institution's own data is not covered by the exclusion, so on one reading that rule can fall inside the definition, as a scoring or segmentation model can. The agencies published no FAQs with the guidance, so this remains a reading of the text and no reason to treat any rule set as out of scope.

Footnote 3, attached to the definition, adds two points. A bank's own "risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document," which reads as reaching an excluded rule too. The guidance's principles "apply to traditional statistical and quantitative models and non-generative, non-agentic AI models," which takes in machine learning models that score and rank alerts. Generative and agentic AI are outside its scope, and the agencies have said they plan to issue a request for information on banks' use of AI.

The revised guidance never mentions the Bank Secrecy Act, AML, transaction monitoring or sanctions, so classifying monitoring logic rests on the general definition. Some institutions govern all of it as models anyway: a compliance risk strategy officer at a regional bank said the bank treats every monitoring scenario as a model for governance purposes, although only some rely on machine learning or more sophisticated modeling techniques. The guidance "is expected to be most relevant to banking organizations with over $30 billion in total assets," though it may also be relevant to smaller banks with significant exposure to model risk.

How a monitoring model is validated end to end is covered in a separate guide to AML model validation.

What evidence does each approach owe an examiner?

Rules and machine learning models each owe an examiner a different set of evidence, and both owe a decision record the examiner can reconstruct from its inputs and rationale.

A rule owes:

• a documented mapping to the typology or red flag it is meant to catch

• a threshold rationale showing why the threshold suits the institution's risks

• testing whenever it changes, and periodic review to show it still works

• a reason an analyst can read when it fires

A model owes:

• validation of its conceptual soundness, its data and its outcomes

• monitoring after release for data, feature and concept drift, and for outcomes by customer segment

• effective challenge from people with the expertise to question it, "sufficient independence to maintain objectivity, as well as the organizational standing and influence to effect any change," in the revised guidance's words

• reason codes that reach the analyst working the alert

One expectation covers rules and models alike, whatever the definition says. The FFIEC manual states that "the monitoring system's programming methodology and effectiveness should be independently validated to ensure that the models are detecting potentially suspicious activity." That sentence predates the revised guidance, calls monitoring systems "models," and does not depend on asset size.

A vendor's model is still the institution's to validate: the revised guidance acknowledges that banks "may not receive from the vendor the underlying code, data, or methodology," and says "the principles of model risk management remain applicable." Switching approach is itself a change an examiner will want evidenced. As a BSA officer at a money transmitter put it: "It's a change and we just have to prove to our examiners and our bank partners that it's a change for the better, right?"

How do rules and models work together in practice?

Rules and models usually work together in one of two patterns: a model finds a pattern and a rule deploys it, or rules raise the alerts and a model ranks them. In both, typology coverage stays in rules an examiner can read.

A risk analytics manager at a regional bank described the first pattern: the team runs cluster analysis to find patterns, then converts the output into rules and tables because the bank's monitoring system can only run rules. That hybrid also blurs the model question, because when statistical analysis sets a rule's parameters, the rule's design rests on the kind of theory the exclusion turns on.

The second pattern lets analyst attention follow risk while coverage stays put. An AML risk governance manager at a regional bank described the problem it answers: profile-based monitoring that covered the typologies regulators expect but raised a large volume of alerts. Some logic stays in rules regardless, as a chief risk officer at a digital bank said: "There are analysts who are going to tune rules all the time because not everything can be in a model."

The agencies anticipated the case where a model finds what the rules missed. Their 2018 joint statement on innovation says that when "artificial intelligence-based transaction monitoring systems" find suspicious activity existing processes would have missed, "the Agencies will not automatically assume that the banks' existing processes are deficient."

What happens to an alert after it fires, whichever approach raised it, is covered in a separate guide to AML L1 alert automation. For fraud detection, where the decision is an authorization rather than an alert, the same comparison appears in a separate guide to machine learning fraud detection versus rules.

Where are the primary sources?

The primary sources on rules, models and transaction monitoring are four documents, each published by its issuing agency:

• SR 26-2 and its attachment (Federal Reserve), with OCC Bulletin 2026-13 and FDIC FIL-15-2026, issued April 17, 2026: the model definition and exclusions, footnote 3, vendor models and effective challenge.

• The FFIEC BSA/AML Examination Manual, in its suspicious activity reporting section: rule-based and intelligent systems, thresholds and independent validation. Its monitoring text has been unchanged in substance since 2014.

• The 2018 Joint Statement on Innovative Efforts to Combat Money Laundering and Terrorist Financing, still in effect: pilots and AI-based transaction monitoring.

• FinCEN's proposed AML/CFT program rule (91 FR 18704, April 2026), which is still a proposal. It "does not reference or require the use of any particular technology," and asks which program components, such as "transaction monitoring rules and parameters," should be required in writing.

Neither approach is required. The 2018 statement says the agencies "will not advocate a particular method or technology," and the FFIEC manual says the sophistication of monitoring systems "should be dictated by the bank's risk profile." Examiners' questions have moved, though: a global head of compliance operations at a crypto firm said examiners once judged a program by how many alerts it had and how many people reviewed them, and now ask whether it is being strategic, including whether AI and machine learning are in use.

How Oscilar approaches rules and models

Oscilar runs configurable rules alongside behavioral baselines, anomaly detection and alert prioritization, so models add context while rules stay explainable and a person reviews the outcome. Rules and models alike can be backtested, A/B tested and unit tested against historical data before they go live, and Oscilar's alert prioritization model ranks alerts "based on their significance and potential risk."

After release, Oscilar monitors data, feature and concept drift alongside outcome KPIs by segment, and it monitors for bias. Every decision keeps a full audit trail with stored reasoning, and the platform is human-in-the-loop by design. Banks operate under the interagency model risk management guidance, and the platform is designed to fit it; the bank keeps its own validation standards, approval authority and regulatory accountability.

Frequently asked questions

Can machine learning replace rules in AML transaction monitoring?

Machine learning rarely replaces rules outright in AML transaction monitoring, because rules still carry the typologies and policy lines an examiner expects to see mapped. Models add context and prioritization, and the agencies' 2018 joint statement on innovation says they will not automatically assume existing processes are deficient when an AI-based system finds suspicious activity those processes missed.

What testing and validation does each approach need?

A rule needs a documented typology mapping, a threshold rationale, testing whenever it changes and periodic review. A machine learning model needs validation of its conceptual soundness, data and outcomes, monitoring after release, and effective challenge from independent reviewers. Whatever a scenario is called, the FFIEC manual expects the monitoring system's programming methodology and effectiveness to be independently validated.

Which approach is easier to explain to an examiner?

A rule is usually easier to explain to an examiner, who can read the condition, the threshold and the activity that met it. A model can be as explainable when each alert carries reason codes and the institution can show how the model's inputs were chosen and validated, while a rule set hidden inside a vendor's system can be harder to explain than either.

What does a hybrid of rules and models look like in practice?

A hybrid of rules and models usually takes one of two forms. Either a model such as a cluster analysis finds a pattern that the team converts into a rule the monitoring system can run, or rules raise the alerts and a model ranks them so analysts work the riskiest first.

Where can teams find the primary regulatory sources on monitoring and model risk?

The primary sources are SR 26-2 and its attachment from the Federal Reserve, with OCC Bulletin 2026-13 and FDIC FIL-15-2026; the suspicious activity reporting section of the FFIEC BSA/AML Examination Manual; and the 2018 Joint Statement on Innovative Efforts to Combat Money Laundering and Terrorist Financing. FinCEN's AML/CFT program rule, published in April 2026 at 91 FR 18704, is still a proposal.

Rules and machine learning models answer different questions in AML transaction monitoring, and a defensible program documents both answers along with the record behind each decision. To see configurable rules and models running side by side with a full audit trail, read about AML transaction monitoring for banks.