SardineCon SF/2026

Learn More
Detection & metrics4 分で読めます

Rules-based detectionとは?

SUBSCRIBE

Rules-based detection is fraud and risk decisioning driven by explicit, human-written logic and thresholds, such as decline when a signal crosses a set limit. It gives a team transparent, instant control over known patterns and hard policy, which is why almost every stack still runs rules alongside models.

What is rules-based detection, in plain English?

Rules-based detection is decisioning built from if-then logic that a human wrote. A rule states a condition and an action: if the device is less than an hour old and the order value is over 500, then hold for review. Each rule encodes something the team already knows, whether that is a policy the business must enforce or a fraud pattern an analyst has seen before.

Rules sit at the front of most risk stacks because they are transparent and instant. You can read a rule, explain exactly why a transaction was declined, and ship a change in minutes without retraining anything. That makes them the natural home for hard policy, such as blocking sanctioned countries, and for fast response to a fresh attack you need to stop today.

The catch is that a rule only catches what it was written for. It has no ability to generalize, so novel or adaptive fraud walks straight past it until someone notices and writes a new rule. In practice teams pair rules with machine learning models: rules handle the known and the non-negotiable, models handle the fuzzy and the emerging.

Rules versus models, side by side

What changes

Rules only

Rules plus models

Transparency

Every decision is fully explainable

Rules stay clear, model scores need interpretation

Speed to deploy

Minutes, no retraining

Model changes take a training and validation cycle

New fraud patterns

Blind until a human writes a rule

Models can flag anomalies rules never saw

Maintenance

Rule sprawl grows hard to manage

Fewer, sharper rules over a scoring layer

Control

Precise, deterministic outcomes

Deterministic policy plus probabilistic lift

Who touches the rulebook?

Who

Their role

Fraud analyst

Spots a new pattern in cases and proposes a rule to stop it.

Risk strategy or policy owner

Owns thresholds, approves changes, and balances capture against false positives.

Data or ML team

Builds the scoring layer and flags where a model would beat a brittle rule.

Compliance

Requires certain hard rules for policy and can audit exactly why a decision fired.

What it looks like in practice

In practice

A fraud team sees a burst of small card authorizations from a handful of freshly created accounts, a classic card-testing probe. By lunchtime an analyst has written a rule: if more than three card attempts come from one account in ten minutes, decline and lock the account. The attack stops within the hour.

Two weeks later the same crew comes back, but now they spread attempts across many accounts to stay under the count. The old rule sees nothing, because it only counts per account. The team adds a velocity rule at the device and IP level, and later hands the pattern to the model so it can generalize instead of playing whack-a-mole.

Why it matters to operators

Rules are where an operator has the most direct control, and where most day-to-day tuning happens. When an attack lands, a rule is the fastest lever you have, and when a regulator or a customer asks why a payment was blocked, a rule gives you a clean, defensible answer that a model score cannot always match.

The flip side is that an unmaintained rulebook quietly turns from an asset into a liability. Stale rules drive false positives that block good customers, and rule sprawl makes the whole system fragile and slow to reason about. Treating rule review as routine work, not a one-time build, is what keeps rules-based detection sharp.

What to watch in the rulebook

  • Rule sprawl. Hundreds of overlapping rules that nobody fully understands are a sign the book needs pruning, not more additions.
  • Stale thresholds. A limit set two years ago against old traffic may now over-block or under-catch; revisit them on a schedule.
  • Silent rules. A rule that never fires may be dead weight or may be masking a data change upstream. Check both.
  • False positive drift. Rising declines on good customers usually trace back to a specific rule that has aged out of usefulness.
  • No change log. Rule edits without review or version history make it impossible to explain or roll back a bad change.

Quick questions

Are rules better or worse than machine learning?

Neither, they solve different problems. Rules give transparency, instant control, and hard policy enforcement; models generalize to new patterns rules cannot anticipate. Mature stacks run both together rather than choosing one.

When should I write a rule instead of retraining a model?

Write a rule when you need to act now, when the logic is a firm policy, or when the pattern is precise and known. Reach for a model when the pattern is fuzzy, adaptive, or too varied to capture in explicit conditions.

Why do rules cause false positives?

A rule applies the same fixed logic to everyone, so it cannot tell a genuine payday spending spike from an attack. As traffic shifts, a once-good threshold starts catching legitimate behavior it was never meant to.

How often should rules be reviewed?

Set a regular cadence, often monthly or quarterly, and review after every major attack or product change. Look at each rule's hit rate, its false positive contribution, and whether it still reflects current fraud.

Can rules and models conflict?

Yes. A hard rule can override a low model score and vice versa, which is intended for policy but can cause confusion if the ordering is unclear. Define precedence explicitly so every outcome is predictable.

What is a good sign a rule should become a model feature?

When you keep writing near-duplicate rules to chase small variations of the same pattern, that pattern usually belongs in a model that can generalize, with a single guardrail rule left behind.

Go deeper

Rules-based detectionと併せて知っておきたい用語