When we started building Riskgrove, the obvious product to build was a rules management platform. Better UI for writing rules, better versioning, better testing infrastructure. The fraud tooling market was full of friction around rule authoring, and every risk team we talked to complained about it.
We decided not to build that. This post is about why.
The conversation that changed our direction
Early in our research, I spoke with a head of risk at a consumer fintech who had been running a rules engine for three years. She had a team of two analysts who did nothing but write and maintain fraud rules. She showed me their rule library: 847 active rules. Each rule was a condition-action pair -- if these field values match this condition, take this action (approve, decline, flag).
I asked her: how many of those rules were catching new fraud patterns that hadn't been caught before? She thought about it and said, honestly, maybe 40 or 50. The rest were variants of rules they'd had for years -- updated thresholds, slightly different field combinations. The rule library had grown every time they had a fraud incident, but the incremental coverage kept shrinking.
Then I asked: what were you still missing? She said the things that always got through were the patterns that didn't fit any obvious field-level condition -- where the transaction fields looked fine, but the behavior leading up to it was wrong. New device on a high-value transaction. Cards being tested across the platform in a distributed way. Session anomalies that only became visible when you looked at many accounts at once. None of those were writable as field-level conditions on a single transaction record.
The structural problem with rules
Rules engines operate on the transaction record as it exists at authorization time. They are excellent at capturing patterns that can be expressed as conditions on that record: amount thresholds, field mismatches (billing country vs. IP country), per-card velocity within a time window. These are real and important fraud signals, and rules engines catch real fraud with them.
The structural limitation is that the most adaptive fraud patterns are not expressible as conditions on a single transaction record. They require:
- Cross-entity state: what has this device done across all transactions, not just the current one?
- Graph relationships: what accounts has this card appeared with? What devices have logged into this account recently?
- Behavioral context: how does this session's pace and navigation compare to the baseline for this account?
- Pattern recognition in noise: is this cluster of small transactions consistent with known card testing patterns, even when no individual transaction is anomalous?
Writing rules for these patterns is not impossible, but it requires infrastructure that a standard rules engine doesn't have -- real-time feature stores, cross-entity lookups, graph databases. At that point, you're not really building a rules engine anymore; you're building a scoring system that happens to have a rule-like interface at the top.
What we built instead
Riskgrove is a scoring system, not a rules manager. The output is a number between 0 and 100 that represents our estimate of the probability this transaction is fraudulent, plus a set of signal reason codes explaining the top contributors.
The scoring is done by gradient-boosting models and behavioral graph models that are trained on transaction data across our customer base. The models evaluate 200+ signals simultaneously -- transaction fields, account history, session context, device graph, cross-platform signals -- and produce a score that reflects the joint distribution of all of them. No human writes a rule for each combination; the model learns the predictive combinations from data.
This approach has real advantages for the fraud patterns that rules miss. It handles novel combinations -- patterns the model has not seen in exactly that form, but that are close enough to known fraud patterns to produce a high score. It handles distributed patterns -- card testing spread across devices and sessions, ATO campaigns that hit the same platform from different entry points. It handles the behavioral context that rules can't see.
What rules engines are still better at
I want to be honest about the tradeoffs. Rules engines have genuine advantages that a pure ML scoring system doesn't match. They are transparent -- you know exactly why a transaction was declined, and you can audit the logic. They are controllable -- if a rule is generating false positives, you can identify it and change it. They are fast to update for known patterns -- if you discover a new fraud vector on Monday, you can have a rule for it by Tuesday.
ML models are less transparent and slower to update. Our signal reason codes give you the top contributors to a score, but they don't give you the complete decision logic. And retraining a model to catch a brand-new pattern requires labeled data, which takes time to accumulate.
The honest answer is that most mature fraud stacks use both. Rules for known, high-confidence patterns where you want explicit control and immediate updates. ML scoring for the behavioral and cross-entity patterns that rules can't express. Riskgrove is designed to fit into a fraud stack that already has rules, not to replace the rules you have.
What we are trying to solve is the gap -- the patterns that rules miss because they require cross-entity state, behavioral context, or pattern recognition in noise. That gap is where most of the fraud dollar losses are going, because rules engines have gotten good at what they're good at, and attackers have learned to stay out of the obvious rule conditions.