There is a version of the "velocity rules vs ML" conversation that is annoying and unhelpful: the one where someone with a shiny new ML stack dismisses rules as legacy, and someone maintaining a rules engine defends it by pointing at uptime. Both sides are arguing about the wrong thing.
Velocity rules and behavioral ML are not competing for the same job. They're solving different parts of the fraud problem, with different strength profiles and different failure modes. Building a good fraud system means knowing which is appropriate where, not picking a winner.
Here is how we think about it after building and operating both in production.
What Velocity Rules Are Actually Good At
Velocity rules are deterministic, auditable, and fast. When a rule fires, you can explain exactly why in plain language: "This card was used 7 times in 15 minutes across 4 different merchants." That explainability is not a nice-to-have. It's operationally necessary for dispute resolution, regulator audits, and consumer complaint responses.
Rules are also immediately deployable. A new attack pattern surfaces, a human analyst identifies the distinguishing characteristic, and a rule encapsulating that characteristic can be in production within hours. No training data required. No model validation process. No feature engineering pipeline. Velocity rules are the fastest path from observed attack pattern to active defense.
For high-confidence, high-volume attack patterns, rules are genuinely hard to beat on the precision-to-engineering-cost ratio. A rule that blocks cards with more than 5 authorization attempts on 3 or more merchants within 10 minutes will catch the vast majority of carding probes with near-zero false positives on that specific behavior. The rule is simple. It works. It requires essentially no maintenance as long as the attack pattern remains the same.
Rules also have a predictability property that ML models lack: if you change a rule, you know exactly what the effect will be. If you change an ML model, the effect is probabilistic and requires empirical validation. For risk teams that operate under tight compliance constraints, that predictability is worth a lot.
Where Velocity Rules Break Down
Velocity rules fail in exactly the ways you'd expect from their design: they're brittle against attackers who know the rules.
The carding probe example above works because the attack sends 7 attempts in 15 minutes. Sophisticated attackers have learned to throttle their probes to 3 attempts per 30 minutes, spacing them just below whatever threshold they've reverse-engineered or probed to identify. The rule never fires. The attack succeeds more slowly but it still succeeds.
Threshold gaming is a real and widespread problem. Fraud rings actively probe rules engines: send requests at various rates until finding the rate that doesn't trigger a block, then operate permanently just below that rate. A published or inferrable velocity threshold is effectively a published safe operating window for attackers.
The second failure mode is distribution shift. A rule written to catch an attack pattern from 2022 may be completely irrelevant by 2024 if attackers have shifted tactics. Rules require active maintenance: regular review of which rules are still firing on real fraud versus which have become dead code that only blocks legitimate edge cases. That maintenance burden grows as the rules library grows, and most teams underinvest in it.
The third failure mode is population blind spots. Velocity rules look at aggregates. They can't distinguish between a high-velocity legitimate user (a business card processing many legitimate purchases) and a high-velocity attacker. Context-free velocity counts over-block high-frequency legitimate users and under-block low-frequency attackers who stay under the threshold.
What Behavioral ML Is Actually Good At
Behavioral ML excels at detecting anomalies relative to an account's own history. The question isn't "did this card get used 7 times today" but "did this account behave in a way that is inconsistent with its prior behavioral profile." Those are fundamentally different questions, and the second one requires a model, not a rule.
An account that normally makes 2 to 4 transactions per week, primarily weekday mornings, primarily at recurring merchants, suddenly initiating 8 transactions in 4 hours at unfamiliar merchants on a Saturday night is anomalous relative to its own history. A velocity rule with a hard count threshold would need that threshold set at 8 to catch it, which would mean it doesn't fire on the majority of accounts (who never reach 8 transactions in 4 hours legitimately or fraudulently). Per-account behavioral scoring catches this as a deviation from the account's baseline, regardless of whether the absolute count crosses any universal threshold.
Behavioral ML also adapts over time without manual rule updates. As user behavior shifts (a customer's spending patterns change, a merchant's transaction profile evolves), the model's learned baseline shifts with it. Rules don't adapt. They require someone to notice the shift and update the threshold manually.
The third advantage is combinatorial. A rule can check one condition or a small number of ANDed/ORed conditions. A model can learn complex, non-linear interactions between dozens of features simultaneously. The feature interactions that distinguish sophisticated fraud from legitimate behavior often can't be expressed as a simple rule, but a well-trained model learns them implicitly.
Where Behavioral ML Falls Short
ML models are opaque. When a model scores a transaction at 0.87 and you need to explain to a regulator or customer why the transaction was blocked, "the model said so" is not an acceptable answer. This is a genuine production constraint, not a philosophical objection. Regulated environments require explainable decisions, and gradient boosting feature importance or SHAP values are better than nothing but are not equivalent to rule explainability.
ML models also require training data, and they degrade as fraud tactics shift. A model trained primarily on one attack vector will underperform on a new attack vector it hasn't seen. Rules, paradoxically, are more flexible in this specific way: a human analyst who observes a new attack pattern can write a rule for it immediately, before any labeled training data exists. The model catches the pattern only after enough labeled examples accumulate.
The cold start problem is also real for per-account behavioral scoring. New accounts have no behavioral history to score against. The model has to fall back to population-level baselines for new accounts, which is exactly where rules-based approaches using static features (account age, device age, email age, etc.) are most effective. The ML model's relative advantage grows with account tenure.
The Case for Running Both
We're not saying you should run both just to cover your bases. There's a specific architectural reason to run both: they catch different fraud populations at different points in the attack lifecycle.
Velocity rules are most effective at catching high-volume, high-frequency attack patterns where the absolute behavior is anomalous regardless of account history. Card testing, credential stuffing at scale, and account creation farms all produce high enough absolute velocities that rules catch them cleanly.
Behavioral ML is most effective at catching low-and-slow attacks, sophisticated ATO, and patterns that are anomalous relative to account history but not anomalous in absolute terms. Account takeovers that produce plausible transaction volumes for the account, synthetic identity bust-outs that never exceed any universal velocity threshold, and insider-assisted fraud that deliberately mimics legitimate patterns are all categories where behavioral scoring outperforms rules.
The populations don't fully overlap. Running both in a composite scoring approach, where each system contributes a score component that's combined at decision time, outperforms either alone for the combined threat landscape. The rule-based component provides fast, auditable decisions on clear-cut cases. The ML component handles the nuanced, account-relative anomalies the rules miss.
The Operational Reality
There's one more thing worth saying about this debate: ML fraud models are expensive to build and maintain correctly. Training pipelines, feature engineering, model validation, drift monitoring, and champion-challenger testing all require ongoing engineering investment. For a small team, a well-maintained rules engine with good coverage of the top attack patterns may genuinely deliver better fraud outcomes per engineering hour than a poorly maintained ML model.
The choice isn't just a technical question. It's an operational one. A sophisticated behavioral ML system run by a team with the bandwidth to maintain it properly will outperform rules over time. The same system, undertrained or under-monitored, may underperform a good rules engine that gets regular maintenance attention. Starting with strong rules and incrementally adding ML where it demonstrably outperforms the rules on specific fraud categories is a more reliable path than replacing rules with ML wholesale and hoping the model covers everything.
