The fraud industry went through a transition period in the mid-2010s where the narrative was: rules are brittle and slow, ML models are adaptive and powerful, you should replace your rule engine with a model. A lot of teams listened. A lot of those same teams spent the following years quietly rebuilding rule logic alongside their models, often without acknowledging that the replacement story was incomplete.
The right framing is not rules versus models. It is understanding what each component does well and structuring a stack where they are not working against each other.
What Rules Actually Do Well
Rules are explicit, deterministic, and fast to deploy. When you discover a specific fraud pattern, you can write a rule that blocks it within hours. The rule fires exactly when its conditions are met. You know why it fired. You can explain the decision to a customer or a regulator in plain language. The rule does not drift or decay over time unless you change it.
Rules are also the right tool for categorical exclusions: block transactions from sanctioned countries, refuse transactions above a regulatory reporting threshold without additional verification, hard-block accounts with confirmed fraud labels. These decisions do not require probabilistic judgment. They require hard boundaries that apply uniformly and reliably. A model that produces a 92% probability of fraud is still a probabilistic output; a rule that says "block confirmed-fraud accounts" is not.
Rules also provide the fastest time-to-response for known attacks. If you are under a specific card testing attack and you know the IP range it is coming from, writing a rule to block that range is faster than retraining or recalibrating a model. The rule fires in milliseconds. The model update cycle takes days.
Where Rules Break Down
Rules are brittle against novel patterns and evolved attacks. A rule designed to catch a specific fraud signature catches that signature only. Fraud operations that adapt their behavior to evade the rule are no longer caught. Over time, a rule set accumulates dead weight: rules that were written for attacks that no longer occur, rules that partially overlap and produce confusion about which rule fired, rules whose thresholds were calibrated against a traffic mix that has since changed.
Rule maintenance is a full-time job in a high-transaction-volume environment. The operational cost is in the constant tuning: every threshold needs recalibration as your platform changes, every new attack pattern needs a new rule, every rule interaction needs to be tested when you add a new one. A rule set that has grown organically over several years without systematic pruning is often a source of false positives and reviewer confusion rather than a clean detection instrument.
Rules also cannot combine many weak signals into a composite risk judgment. A single transaction might have five features that are each mildly elevated, none of which individually crosses a rule threshold but which together suggest high risk. Rules handle this by adding a combination rule for every relevant combination, which grows the rule set combinatorially. A model handles it naturally by learning the joint feature distribution.
What Anomaly Detection Models Actually Do Well
ML-based anomaly detection and classification models excel at exactly what rules struggle with: combining many signals, learning non-obvious feature interactions, and generalizing to patterns that share underlying structure with known fraud without requiring explicit rule encoding.
A behavioral anomaly model can learn that a particular combination of session duration, transaction amount relative to account history, device age, and time-since-last-transaction is associated with elevated fraud risk, even if no single feature individually triggers a rule. The model captures the joint distribution of legitimate and fraudulent transactions across a high-dimensional feature space in a way that a rule set cannot practically encode.
Models also handle gradual pattern shift better than rules. Fraud evolution that gradually moves the feature distribution in a particular direction will eventually cause model performance to degrade, but that degradation is detectable through performance monitoring. A rule, by contrast, does not degrade gracefully; it either fires or it does not, with no intermediate signal that the attack pattern is moving.
The Conflict Pattern: When Rules and Models Override Each Other
The common failure mode in a layered stack is not technical; it is organizational and logical. A team deploys a model alongside an existing rule engine without establishing a clear hierarchy for when each component's output governs the final decision. The result is a system that produces conflicting signals with no principled resolution.
A specific example: a model scores a transaction at 35 (low risk). A rule flags it because it is above a velocity count threshold. Which signal governs? If the answer is "it depends on who's on call," you have an operational problem. The velocity count rule may be detecting an attack the model has not learned to recognize yet (the rule is right, the model is incomplete). Or the velocity count rule may be firing because of a promotional campaign that is generating legitimate high-volume activity that the model correctly ignores (the model is right, the rule needs a carve-out).
Getting to a clean answer requires knowing which component is authoritative for which decision class. A reasonable architecture is: hard rules govern categorical exclusions and known-attack blocks, the model governs probabilistic risk assessment on everything else, and when a rule fires on a transaction the model scores as low-risk, that conflict is flagged for review rather than silently resolved by one component overriding the other.
Rules as Model Feature Context
One of the more underused patterns in practice is feeding rule outputs as features into the anomaly model rather than treating them as separate blocking mechanisms. A binary "this transaction triggered the high-velocity rule" feature in the model's input vector allows the model to learn how much weight to give that rule trigger in context with other features.
This is architecturally interesting because it lets the model learn the combination that actually predicts fraud rather than requiring you to pre-specify which combinations matter. The rule identifies a condition. The model determines whether that condition, in combination with the other features present, produces a fraudulent-transaction posterior that warrants a block versus a review versus a flag for investigation.
This pattern also makes the rule set easier to maintain. If a rule is consistently capturing transactions that the model otherwise would not have flagged, and those transactions turn out to be confirmed fraud, the rule is adding information. If a rule is capturing transactions that the model already scores as high-risk, the rule is redundant as a model feature even if it is useful as a hard block for speed reasons. Feature importance tracking on rule-derived inputs tells you which rules are adding lift and which are noise.
Maintaining the Stack Without Building a Monster
The operational reality for most fraud teams is that rule sets grow faster than they shrink. New attacks produce new rules. Old attacks recede but their rules remain. Over time you end up with hundreds of rules, unclear ownership, and a combinatorially explosive set of interactions to test whenever you want to change anything.
Systematic rule lifecycle management is not glamorous, but it is necessary. Rules should have explicit owners. They should have clear performance metrics (how often does this rule fire, what fraction of its fires are confirmed fraud, how does its performance compare to running the model alone on the same transactions). Rules that have not fired in six months should be reviewed for deprecation. Rules that fire frequently but have low fraud confirmation rates should be examined for false-positive impact.
The goal is a rule set that is actually complementary to your model: catching known categorical cases the model should not need to handle, hard-blocking confirmed-bad actors, and rapidly responding to novel attacks during the window before the model can be updated. Not a growing collection of legacy logic that the model has to score around.
