The fraud operations team at a mid-size regional bank spent three weeks in early 2024 tuning their velocity rules after a card-not-present attack cluster hit over a holiday weekend. They adjusted thresholds, added new BIN-country mismatch conditions, tightened time-window triggers. By the time the rules were approved, tested, and pushed to production, the attack wave had already shifted — new device fingerprints, different BIN ranges, transactions spaced just far enough apart to avoid the updated velocity checks.
This is the core problem with rule-based fraud detection. It's a retrospective system operating against a forward-moving threat.
How rule engines actually work — and where they break
A rule engine evaluates each transaction against a defined set of conditions. Something like: if transaction amount exceeds $500 AND shipping address differs from billing country AND device is new, score as high risk. These conditions are written by analysts, reviewed by compliance, approved by risk committees, and deployed through change management. In a well-run shop, that cycle takes two to six weeks per change.
Fraud operators — the people actually running the attacks — don't have change management. They iterate in hours. When a rule starts catching their transactions, they probe the system, identify the trigger condition, and adjust. Drop the amount just below threshold. Use a device that was flagged as new three months ago (and therefore isn't flagged anymore). Route through a shipping intermediary that normalizes the address mismatch.
The asymmetry is structural. One side is institutional, the other is adaptive. Rules can't close that gap.
The specificity trap
Fraud analysts face a brutal tradeoff when writing rules. Broad rules catch more fraud but also block legitimate transactions — the false positive problem. Narrow rules protect good customers but let sophisticated attacks slip through.
Most teams land somewhere in the middle and call it tuned. What they've actually done is optimize against the attack patterns they've already seen. New patterns — anything that doesn't match the historical profile the rules were built on — have a relatively clear runway until someone notices, files a report, and kicks off another tuning cycle.
In 2025, our platform saw a category of account takeover attacks that exploited exactly this window. The attackers used compromised credentials that were months old — accounts that had passed their post-compromise dormancy period and no longer triggered velocity rules tied to recent credential activity. The initial access happened outside any monitored window. The fraud event itself — a payment method change followed by a large transfer — looked legitimate by every individual rule condition. The attack only became visible in aggregate, across sessions, using behavioral baseline data the rule engine didn't have access to.
Rule coverage erosion over time
There's another problem that doesn't get discussed enough: rules age. A rule written to catch a specific attack pattern from two years ago may be doing very little today — either because that attack vector has gone dormant, because the conditions it was written for no longer apply to current transaction flows, or because it's been superseded by a newer rule that wasn't removed.
Most fraud rule environments accumulate rules faster than they retire them. We've reviewed environments with 400, 600, even 900 active rules, many of which were triggering on fewer than 0.1% of transactions. The overhead of evaluating them is real. More importantly, the interaction effects between rules become unpredictable. A condition that was safe in isolation can combine with other conditions to produce unexpected behavior — either missing fraud or blocking legitimate transactions at a rate nobody intended.
A rule audit at one payment processor we work with found 23% of rules had last triggered on a sample that no longer matched their current transaction mix. Another 14% were duplicative of rules added later. The team had no systematic process for retiring rules because the organizational incentive was always to add, never to remove.
What "modern attack patterns" actually means
The phrase gets used loosely. Here's what it means in practice as of 2025-2026:
Automation at scale. Fraud operations are running automated probe-and-adapt cycles against production systems. They're not manually adjusting each attack; they're running scripts that test conditions and feed results back into attack parameter selection. The adaptation cycle is faster than any human-driven rule update process.
Cross-channel coordination. A single synthetic identity attack might involve account opening, a period of good-behavior cultivation, then simultaneous withdrawals across multiple payment channels. The individual channel events are each below threshold. The threat is only visible across channels — which most rule engines aren't designed to see.
Legitimate infrastructure abuse. Modern card-not-present fraud frequently uses residential proxy networks, real device profiles obtained from botnet-harvested machines, and email addresses that have legitimate history. The "suspicious" signals that rules were built on — datacenter IP ranges, newly registered domains, anonymous email providers — are largely irrelevant to these attacks.
Mule account networks. Funds are moved through chains of seemingly legitimate accounts before reaching the final destination. Each individual hop looks like a normal transfer. The pattern is only visible at the network level, mapping relationships between accounts across time.
What detection actually requires
None of this means rules have no role. For known, stable attack patterns — certain types of first-party fraud, specific compliance checks, hard regulatory limits — rules are efficient and auditable. They should stay in the stack.
But the portion of the threat landscape that rules can cover is shrinking. What the rest of it requires is a system that builds behavioral baselines per customer, per merchant, per device cluster; detects deviations from those baselines without needing explicit rules to define what "deviation" means; and adapts to new patterns without a six-week change management cycle.
That's not a rule engine with more rules. It's a different category of system operating on a different timescale with different data inputs. The fraud operations teams that are performing well right now are the ones that have made that architectural shift — not the ones that are adding more conditions to their existing rule trees.
If your detection program is still primarily rule-driven, the question isn't whether you'll get hit by something the rules don't cover. The question is when, and how much it costs before you catch it.