Fraud rules engine and risk scoring: how to build rules that do not block good customers
A fraud rules engine turns signals about a payment, device and customer into a risk score and a decision: allow, review or block. Good setups combine readable rules, velocity checks and lists with a calibrated score, then test every change in shadow mode against real outcomes before it affects a single customer.
Updated · RiskCogs team
Key facts
- A risk score sums up many signals into one number, so teams can set thresholds instead of judging each payment by hand.
- Velocity checks count events in a time window, such as card attempts per device in two minutes, and catch automated attacks.
- Allow, watch and block lists handle known customers, cards, devices, emails and IP addresses directly.
- Every rule has a false-positive cost: blocked good customers and lost revenue. Measure it before enforcing.
Rules engine vs risk scoring
Rules are explicit conditions, such as block if the card country differs from the IP country and the amount is above a limit. They are easy to read and explain, but each rule only sees what it was written for.
Risk scoring weighs many signals at once and produces a number, usually from 0 to 100. A score adapts better to new patterns, while rules give you precise control. Most teams use both: the score sets the baseline, and rules and lists handle known cases and urgent attacks.
Signal families a fraud engine should cover
- Payment: amount, currency, BIN type (prepaid, virtual, unknown), BIN country, AVS result, 3-D Secure outcome.
- Identity: disposable or invalid email, emails or phones seen on many devices, dispute and refund history.
- Network and location: data-center, VPN or Tor IP, distance and country mismatches between card, IP and time zone.
- Device and behaviour: device links across accounts, automation and tampering traces, unusual paste or click patterns.
- Velocity: attempts per card, device, email, phone or IP in short windows.
- Trust: returning customer on the same device as an approved payment, successful 3-D Secure.
How to write and roll out a new rule
- Start from a real pattern in your data, such as a card testing burst or a refund abuse case.
- Write the rule as a readable condition and decide its effect: add to the score, send to review, or block.
- Run it in shadow mode for one to two weeks so it scores traffic without changing decisions.
- Compare what it would have caught with confirmed outcomes: chargebacks, refunds, confirmed good orders.
- Enforce it if the catch rate justifies the false positives, then review it monthly.
Rules, scores and lists compared
| Tool | Best for | Watch out for |
|---|---|---|
| Readable rules | Known patterns and urgent attacks | Rule sprawl and overlaps |
| Velocity checks | Card testing, bots, promo farming | Thresholds that are too tight for busy shops |
| Risk score | Weighing many weak signals together | Needs outcome feedback to stay accurate |
| Allow, watch, block lists | Known good and bad customers or cards | Stale entries, manual upkeep |
How RiskCogs scores and explains decisions
RiskCogs returns a risk score with a level and a recommendation for each payment. By default, scores below 40 are allowed, 40 to 69 go to review and 70 or more are blocked, and you can tune these thresholds per project. Each decision lists the signals that drove it, so analysts can see why a payment was flagged.
You can add custom rules and allow, watch and block lists for cards, devices, emails and IP addresses, run them in shadow mode, and send confirmed outcomes back so the scoring learns from your traffic.
{
"risk_score": 18,
"level": "low",
"recommendation": "allow",
"shadowMode": true,
"flags": []
}Frequently asked questions
What is a fraud rules engine?
A fraud rules engine is software that checks each payment or account event against a set of conditions and decides what to do with it. Rules can add points to a risk score, send the event to manual review or block it. Modern engines combine rules with a scoring model and lists, and log why each decision was made.
What is a good fraud risk score threshold?
There is no universal number. The right threshold depends on your margins, chargeback costs and how much review capacity you have. A common approach is three bands, allow, review and block, then adjusting each band after measuring false positives and missed fraud in shadow mode on your own traffic.
What are velocity checks in fraud prevention?
Velocity checks count how often something happens in a time window, such as payment attempts per card, device, email or IP in the last few minutes. Sudden bursts usually point to automation, card testing or promotion abuse. They are simple, fast and effective, but thresholds should match your normal traffic.
How do I test fraud rules without blocking customers?
Use shadow mode. The rule scores live traffic and records what it would have done, but your current decision process stays in charge. After a week or two, compare its flags with confirmed chargebacks and good orders, then enforce only the rules whose catch rate justifies the false positives.
Sources and related reading
- European Banking Authority, Regulatory Technical Standards on strong customer authentication (transaction risk analysis, Article 18).
- Visa and Mastercard public rules on fraud and dispute monitoring programs.
Measure first. Enforce when ready.
Run RiskCogs in shadow mode next to your existing payment setup and review the decisions before they affect a single customer.