Rules-based fraud detection and ML scoring are not just different implementations of the same thing -- they operate on fundamentally different representations of a transaction. Understanding what that means in practice explains why ML models catch specific pattern classes that rules routinely miss, and why rules still have a role alongside them.
What rules see: a point in feature space
A rules engine evaluates a transaction as a single point. The point is defined by the values of its fields at authorization time: amount, card BIN, merchant category code, IP country, billing country, transaction velocity on that card in the last hour. Rules are conditions on individual fields or combinations: if amount > 500 AND IP country != billing country, then flag. If card velocity > 3 in 60 minutes, then decline.
This representation is sufficient for fraud patterns that can be fully described by single-transaction field conditions. A rule catches a card that has been used 6 times in the last hour. It catches a transaction from a high-risk merchant category. It catches an amount threshold breach.
But the point representation throws away a lot of information. It cannot represent: the trajectory leading to this transaction (what this account has done over the past week), the position of this transaction in a behavioral graph (what other accounts are connected to this device or card), or the statistical unusualness of this field value for this particular account's history (whether $800 is anomalous for this user specifically or is consistent with their normal purchase behavior).
What ML models see: a distribution over histories
A gradient-boosting model evaluates a transaction as a point plus its context. The context includes features computed from historical data: the mean and standard deviation of transaction amounts for this user over the past 90 days, the number of distinct devices this user has been seen on, the time since the last login, the number of failed authentications in the past 24 hours, the position of this device fingerprint in a fraud-association graph.
These contextual features are what allow ML models to recognize the patterns that rules miss. The model does not need a rule that says "if amount is more than 3 standard deviations above the user's historical mean, flag it" -- it learns from data that this feature is predictive and weights it accordingly. It also learns the interactions: a high-amount transaction from a user who has been transacting steadily for 18 months from a consistent device scores very differently from the same high-amount transaction from a new user on a new device, even though the rule condition would treat them identically.
The three pattern classes where ML outperforms rules most clearly
1. Behavioral drift patterns
Behavioral drift is when a user's transaction behavior changes gradually in ways that are individually below any threshold but collectively represent a significant shift. An account that begins by making legitimate small purchases and over six weeks escalates to higher amounts, new merchants, and eventually fraudulent transfers -- a rules engine sees each transaction independently and each is below any single-transaction threshold. A model that has encoded the trajectory sees the drift.
This is most important in the context of account takeover fraud where the attacker takes gradual control of an account rather than doing a single large fraudulent transaction. Gradual escalation is specifically designed to avoid threshold-based rules; it is the evasion pattern that attackers have learned to use against rules engines. The behavioral trajectory is the signal that only models trained on historical sequences can exploit.
2. Graph-embedded patterns
Card testing, synthetic identity fraud, and organized ring fraud all have a graph structure. A set of devices is associated with a set of cards, which are used at a set of merchants. The individual transactions may look unremarkable; the graph topology is the signature. A card that shares a device with 12 other cards that have all been declined in the past week is part of a testing operation even if the card itself has never been declined. A rule on the individual card misses this; a model with graph-embedded features sees it.
Graph features also handle cross-platform signals. A device fingerprint that has been associated with fraud on other platforms in our network carries that association forward. A rules engine operating on a single platform has no mechanism for this; it can only see what has happened on its own transactions. A model that ingests cross-platform graph edges sees the global fraud graph.
3. Ambiguous field patterns with context resolution
Many fraud signals are ambiguous at the field level -- they correlate with fraud but also appear frequently in legitimate transactions. IP-billing country mismatch is the canonical example: most mismatches are legitimate travelers, VPN users, or people with outdated billing addresses. A rule on this field alone has poor precision. A model can use the same signal conditionally: if the mismatch is combined with a new device, no prior transaction history, and a high-risk merchant category, it contributes heavily to the score. For the same mismatch combined with a long account history, consistent device, and typical amount, it contributes minimally.
This conditional weighting is what makes ML models achieve better precision on ambiguous signals. The rule has to choose a threshold and lives with the precision it gets. The model learns the context under which the signal is predictive and applies it accordingly.
Where rules still have the edge
Rules remain superior in two specific scenarios. First, when the pattern is known and explicit: if you know that transactions from a specific BIN range associated with a confirmed fraud ring should be declined, a rule executes that logic immediately, without retraining. Models need labeled data to pick up new patterns; rules can act on expert knowledge in real time.
Second, when interpretability and auditability are required. A rule can be described exactly: "declined because IP country is RU and card BIN is in the high-risk category and amount exceeded $200." A model can produce signal codes explaining the top contributors, but cannot provide a complete audit trail of the decision in the way a rule can. For regulated use cases where decline decisions need to be explainable to compliance teams or customers, rules provide a stronger audit trail.
How Riskgrove's models handle feature engineering
The quality of an ML fraud model depends almost entirely on the quality of its feature engineering -- the representation of each transaction as a vector of contextual signals that the model can learn from. Bad features produce poor models regardless of the ML algorithm.
Riskgrove's feature pipeline processes each transaction in real time to compute features across four categories: transaction-level (amount, merchant category, time of day, amount deviation from user baseline), account-level (account age, session anomalies, device history, authentication events), device-level (device reputation, cross-account associations, platform-wide velocity), and network-level (graph distance from known fraud entities, cross-platform signal from the shared device graph).
The network-level features are what distinguish our models from a platform-deployed model that only sees its own data. The shared device graph means that a device fingerprint entering your checkout for the first time, which would have zero history on your platform, may have extensive history across our network. A new-to-you device that is a known fraud device network-wide scores appropriately on the first transaction -- there is no learning curve on your own data required.
This is the architectural reason why a shared scoring layer provides better first-transaction fraud detection than any individual platform can achieve with its own model. The first transaction from a known-bad device is the transaction a single-platform model cannot score confidently; the shared graph resolves it immediately.
Model maintenance and drift
Fraud patterns are not stationary. Attackers adapt to detection, new fraud types emerge, and seasonal patterns shift. A model trained 18 months ago without updates degrades in coverage. This is a real cost of ML-based fraud detection that is often underestimated at evaluation time.
Our scoring models are retrained on a rolling 90-day window of labeled transaction data. The labeling pipeline processes chargeback outcomes, manual review decisions, and confirmed fraud reports into a training set. Retraining occurs weekly. The net effect is that the model's understanding of current fraud patterns is always within 2-4 weeks of the most recent confirmed fraud data in our network.
For rule-based systems, the analogous maintenance cost is the analyst time required to identify new fraud patterns and write new rules. Both approaches require ongoing investment; the nature of the investment differs. What ML cannot do is respond instantly to a newly discovered fraud vector the way a rule can -- that asymmetry remains, and it is why the two approaches are complementary rather than substitutes.