Fraud Rules Engines: How to Build Rules Your Team Can Change

A fraud rules engine is software that applies a merchant's own if-then logic to every transaction. It decides whether each order is approved, declined, challenged, routed, or sent to manual review. Most fraud rules engines answer to engineering, though, not to the fraud team that owns the policy.

You already know which rule is wrong. The velocity limit is too loose, or a score threshold is pushing good customers into 3DS. Fixing it takes an engineering ticket, a wait for the next release window, and the same edit repeated in every gateway console, each with its own syntax.

This guide covers what a fraud rule is made of, when rules beat machine learning, where your rules should run, and how to change them without waiting in the sprint queue.

What a fraud rules engine does

A fraud rules engine turns a risk signal into a decision. Fraud vendors and machine learning models produce a score. The rules engine reads that score alongside other transaction data and applies your policy to decide what happens next.

Everything else in this guide depends on that split: scores come from vendors and models, while rules decide the outcome. A risk score of 72 means nothing on its own until a rule that says "above 70, step up to 3DS" tells the order where to go.

Rules also carry the business context no vendor model has. Your model doesn't know you stopped shipping to a region last quarter. It doesn't know which SKUs resell well on the gray market, which promo code draws abuse every holiday, or which market has issuers that handle 3DS badly. You know those things, and rules are where that knowledge goes to work on every transaction.

The four parts of a fraud rule

Every fraud rule has four parts. A condition (the data it reads), a checkpoint (where in the customer journey it runs), an action (what it does), and feedback (the outcome data that tells you whether the rule worked).

Condition. The data the rule reads. Most conditions draw on identity, velocity, device, session, and order history. "Five cards tried on one device in ten minutes" is a condition, and so is "shipping country differs from card country."

Checkpoint. Where the rule runs. The industry framework puts checkpoints at account creation, profile changes, before authorization, and after authorization. A rule that catches a fake account at signup saves you from scoring every order that account would have placed.

Action. What the rule does when the condition is true. The common options are approve, decline, step up to 3DS or MFA, route to a specific gateway, or send to manual review.

Feedback. Authorization and dispute outcomes flowing back to the rule owner and the fraud vendor. Without feedback, a rule is a guess that never gets graded. With it, you can tune thresholds and your vendor's model gets better data to learn from.

Rule-based fraud detection works best alongside machine learning

Rule-based fraud detection handles known patterns, business policy, and decisions that need a clear reason. Machine learning handles patterns that shift faster than anyone can write rules. Strong fraud programs run both, with rules acting on model scores.

Rules win when you already know what you're looking for, such as a known card-testing pattern, a compliance requirement, or a policy you set on purpose. They also win any time you need to explain a decision to a customer, an issuer, or an auditor, because "the order exceeded our new-customer limit" is an answer and "the model said so" is not.

Models win on volume and speed. They spot patterns across thousands of signals that no analyst would write as a rule, and they adjust as fraudsters change tactics.

That makes the rules-versus-models debate a distraction. Treat them as layers, where the model produces the score and your rules decide what the score means for your business today.

Both layers need upkeep, and that's where teams feel the strain. In the Merchant Risk Council's 2025 fraud report, 32% of merchants named updating fraud risk models as a challenge. In the 2026 edition, 80% of merchants said they struggle with at least one of five data and technology issues, updating fraud risk models among them. Models need retraining, and rules need someone with the access to change them.

Fraud detection rules payment teams run every day

Most fraud rule sets start with the same building blocks: velocity limits, BIN and geolocation mismatches, amount thresholds, allow and deny lists, and score thresholds that trigger 3DS. Here's how they usually look.

The right values for X and Y depend on your traffic, your products, and your tolerance for friction. Velocity limits are the first line against card testing, and stopping card testing takes more than one rule. Score thresholds only work if you know what your vendor's scores mean, which is its own topic in fraud scores and thresholds. And every 3DS step-up should account for SCA exemptions, so you don't add friction where the regulation doesn't require it.

Why rules engines get stuck

Rules engines stall when only engineering can change them. Hard-coded rules wait on release cycles, every PSP uses its own rule syntax, and rules nobody revisits keep declining good customers long after the pattern behind them is gone.

Hard-coded logic. If a threshold lives in application code, changing it is a code change. A fraud analyst can't move 70 to 75 without a pull request.

Release cycles. That pull request waits for the next deploy window. Meanwhile the old rule keeps running on live traffic.

Forked rule sets. Each gateway configures rules its own way. One fraud policy becomes three configurations, and they drift apart within a quarter.

Stale rules. A rule with no owner, no review date, and no measurement just runs forever. Nobody can say what it costs in good orders, so nobody touches it.

Teams feel this in the review queue. The MRC 2026 report found 21% of merchants screen orders manually, down from 25%, and 18% of manually screened orders still end up declined. Every rule that sends the wrong orders to review spends analyst time on customers who were fine all along. It's no surprise that 62% of merchants call reducing time spent on fraud management a moderate or major factor in their investment plans.

Stale rules also hide their cost. Datos Insights research puts the average false decline rate at 1.51% of ecommerce sales. More than half of merchants (53%) believe their rate is under 1%, but only 34% actually are. The rule that "works" may be the one quietly turning away good revenue. For the full math, see the cost of false declines.

Every one of these problems traces back to where the rules live and who can edit them, and both of those are fixable.

Where your fraud rules should run

Fraud rules run in one of three places: an in-house engine, the rules tool inside a payment service provider, or an orchestration layer that sits across every gateway and fraud vendor. Only the orchestration layer applies one rule set to all of a merchant's traffic.

Build in-house. You get full control and you pay for all of it. Your team owns every vendor integration, every data pipeline, and every rule change. Internal engines are costly to stand up and costlier to keep running, and the rules usually end up as code that only engineers can edit. That puts you right back in the ticket queue.

PSP-embedded rules. Most gateways include a rules tool that is fast to start, and for a single-PSP merchant it can be enough. The limit is scope, because those rules only see that PSP's traffic. The day you add a second gateway, your rule set forks, and you now maintain two policies in two syntaxes that are supposed to say the same thing.

Orchestration layer. Here the rules sit in front of every gateway and fraud vendor. You write a rule once and it applies to all of your traffic, wherever the payment goes next. Transaction and outcome data land in one place, so you can see what each rule did. Adding a gateway or swapping a fraud vendor doesn't mean rewriting your policy, because the policy never lived inside the vendor.

[OPTIONAL PROOF POINT, pending data pull: share of Spreedly customers running fraud steps across two or more gateways.]

[VISUAL 2: Where rules run. In-house, PSP-embedded, and orchestration layer, showing one rule set across several gateways and fraud vendors versus forked rule sets per PSP.]

If you run more than one gateway, or plan to, the choice mostly makes itself.

Change fraud rules without an engineering ticket

Fraud teams change rules without engineering when the rules live in a no-code layer they control. They edit the condition or threshold, test the new rule against the current one on a split of live traffic, and measure the result against authorization rate and fraud rate together.

The operating model runs in four steps:

1. Edit. Change the threshold, condition, or action in the rule itself, not in code.
2. Test. Run the new rule against the current one on a split of live traffic.
3. Publish. Roll the winner out to all traffic, or roll back if results don't hold.
4. Measure. Track authorization rate and fraud rate side by side.

That last step is where most rule changes go wrong. A rule that cuts fraud by a point and cuts approvals by two is a net loss, and you'll only see it if you watch both numbers. Measuring one without the other is how stale rules survive.

This is how fraud orchestration workflows work in Spreedly Composer, which puts your gateways, fraud tools, identity checks, and 3DS on one visual canvas. Checkpoints are no-code workflows, and a decision editor branches on fraud vendor scores and other data to deny, step up to MFA or 3DS, or proceed to authorization. A common flow runs the fraud check first, triggers 3DS only when the risk score crosses your threshold, then authorizes. Fraud scoring, 3DS, and the payment run as steps in the same checkpoint, so one policy covers every gateway behind it.

Your team can split traffic to A/B test a new fraud rule against the current one, then keep the version that wins or roll back. The change ships from the team that owns the outcome, with no engineering ticket or release cycle. One ecommerce merchant running Composer reported 92% less engineering time spent on payment logic. Spreedly Protect gives you access to the fraud, 3DS, and identity providers you already trust through the same connection.

The fraud team already knows which rule to change, and with the rules in a layer they control, they can make the change themselves.

See How Composer Checkpoints Work