Fraud & transaction screening
On this page
Every payment is a yes/no decision made under a deadline: approve it, decline it, or send it for review, in the moment, before the customer gives up. That is a rule engine's home turf.
⚡ Where speed pays for itself
Screening runs inside the payment-authorization deadline. A rules service that is too slow forces a bad trade: time out and approve unscreened (take the fraud loss), or add delay (lose the sale to checkout abandonment). Winnow decides in microseconds, inside your own payment software, so the whole transaction stream is screened without a dedicated server fleet: fraud caught and deadlines kept, on less hardware.
The stakes🔗
Card fraud is large and growing: global card-fraud losses reached $33.41 billion in 2024 and are projected to climb to about $41 billion by 2030 (Nilson Report).
But the subtler cost is over-blocking. When screening is too blunt, it rejects good customers: "false declines." Industry analyses estimate merchants lose more to false declines than to fraud itself (by one estimate roughly 13× more), and that about 42% of wrongly declined shoppers abandon the purchase entirely (NoFraud, Riskified). So the goal is precise screening, evaluated fast, not just aggressive blocking.
How it works🔗
Risk analysts express each red flag as a rule and the engine scores every
transaction against all of them in real time. A single rule might say "flag a
transaction over $5,000 from a high-risk country on a device first seen less than
a week ago." Money is written the way an analyst says it — $5,000.00, held as an
exact decimal amount rather than a floating-point number, so no rounding drift can
reach a decline. Categories such as country are stored as
numeric codes; free-text fields (a memo, a merchant name) can be matched by
text search. Dozens of such rules combine
with plain and/or/not logic, and thresholds are tuned by editing text; no code change.
🤖 With AI in the loop
This is how the industry's best fraud stacks already work: a machine-learning model scores the payment, and rules make the decision. Stripe Radar scores every payment 0–99 and lets merchants write rules combining that score with amount, payment method, and geography. Its default controls kick in at scores of 65 (elevated) and 75 (high). Adyen's Protect blocks on its ML risk classification only at a merchant-set threshold, with explicit allow-rules that override the model. In Winnow the model's score is simply one more column: a risk score of 75 or more on an amount over $5,000 is a microsecond rule check, and when a fraud wave hits, analysts move the threshold in minutes instead of waiting weeks for a retrained model. More patterns: Deep Dive: AI + Rules Engines.
The authorization budget🔗
A payment authorization is a deadline, not a preference. The customer is waiting, the network is waiting, and the screen has to finish inside a budget measured in tens of milliseconds — or the system takes the bad trade the callout above describes: approve unscreened, or lose the sale. Winnow is one step inside that budget: the rule decision, not the network, not the ledger write. The question is what fraction of the deadline that step costs.
A tens-of-milliseconds authorization budget, and the slice a 250,000-rule screen takes
The whole rule book fits in a rounding error of the deadline. Screening 250,000 standing rules costs ~5 µs, about one ten-thousandth of a tens-of-milliseconds authorization budget — so there is never a latency argument for thinning the book, sampling the traffic, or dropping the expensive rules. Even the deliberately exhaustive cross-check, 76× slower, stays under 1%. The one row here that would actually threaten the deadline is the network call you avoid by running in-process. Both µs figures are ours, measured in the run below; the round-trip and budget bands are the industry's.
Why Winnow fits🔗
- Every kind of check is native. Amount and velocity thresholds are number checks; country, merchant category, and device type are category checks; memos and payee names are text matches, each stored the way that makes its check fastest.
- Real-time or batch. Score one transaction in microseconds on the authorization path, or sweep the whole day's file in a single pass.
- Tune live, safely. Rules are plain text, so an analyst can adjust a threshold on a running system with no downtime; decisions already in flight still see a complete, consistent rulebook.
- No extra hop. Winnow runs as a library inside your payment service, so no part of the authorization deadline is spent calling out to a separate rules server.
🧪 In simulation — 250,000 fraud rules, 500,000 authorizations
To put numbers on the above, we built the rule book in the shape a real one drifts into: 250,000 standing rules in six families, each filed under whatever is most distinctive for it — the merchant, the card's issuing range, the merchant category, or an amount band on its own — plus a descriptor watchlist that cannot be filed under anything. Then we screened 500,000 card authorizations, worth $326.6 million of payment volume, against all of it.
What this is: a test run on a generated rule book and a generated stream of payments, not a customer deployment — the rules and traffic are invented, the speeds and costs are measured. It ran on one ordinary 16-core desktop computer, priced at a standard cloud rate of $0.043 per processor-hour running around the clock, the same basis as the Deep Dive: Cost Savings. About a third of authorizations matched at least one rule, and every decision was double-checked against a slow, exhaustive pass over all 250,000 rules before any stopwatch started — that slow way takes about 76 times longer — so a rule book that quietly caught nothing could not pass itself off as a fast one. Treat the speeds as approximate, moving by about a fifth with machine load, and the counts as exact; the test ships with Winnow for your team to re-run on your own rules.