Fraud screening without killing approval rates

A fraud rule that blocks too little lets chargebacks through. A rule that blocks too much does something quieter and often more expensive: it turns away good customers, who never appear in any dispute report. Most merchants measure the first cost carefully and the second not at all.

This article is about the screening a merchant controls before a payment reaches the issuer: rules, risk scores, reviews, authentication and blocklists. It explains how to measure the trade-off, how to layer checks so the uncertain middle is not simply declined, how to test rules safely, and where screening matters even when issuers will decline anyway. Issuer-side declines are a separate topic, covered in our guide to soft vs hard declines.

What is the trade-off in fraud screening?

Every rule sorts payments into those it stops and those it lets through, and it gets some of each wrong.

	Payment is fraudulent	Payment is genuine
Rule stops it	Fraud prevented	False positive: a good customer lost
Rule lets it through	Fraud missed: chargeback and fraud report	Approved sale

The two error cells pull against each other. Tighten a rule and fraud missed falls while false positives rise. The aim is not zero fraud; it is the lowest combined cost of fraud losses, dispute fees, monitoring risk and lost sales.

Stripe’s guidance on block rules puts it simply: a good block rule blocks significantly more fraudulent payments than legitimate ones. Its rule metrics show an estimated false positive rate next to the fraud prevented, because one number without the other is misleading.

How do you measure false positives?

Directly, you cannot: a blocked payment never gets a verdict. Indirectly, several signals together give a good estimate:

• Rule simulation. Run a candidate rule against past payments with known outcomes. Stripe’s rule testing simulates a rule on the last 6 months of charges and shows how many legitimate, fraudulent and already-blocked payments it would have caught.
• Review outcomes. If most payments a rule sends to review are approved, the same rule as a block would have stopped mostly good customers.
• Holdout traffic. Let a small share of matching payments through and follow their outcomes for up to 120 days, the dispute window card networks typically allow.
• Retry success. A customer blocked on one card who then pays successfully with a local method or another card was probably genuine.
• Complaints. Support tickets about failed payments, grouped by the rule that fired.

How should the checks be layered?

Think of three bands rather than a yes or no:

1. Clearly bad: block. Cards on your blocklist, cards involved in earlier chargebacks, card-testing patterns, impossible combinations. These rules should be narrow and confident.
2. Uncertain: add friction, not a decline. Request 3-D Secure, ask for verification, hold the order for review, or authorise now and capture after review. A genuine customer can pass; a fraudster usually cannot.
3. Clearly good: let through. Returning customers with a clean history, verified accounts, small amounts on known cards.

Stripe’s defaults follow this pattern. Radar scores payments from 0 to 99, treats 65 or above as elevated risk and 75 or above as high risk, blocks high-risk payments and allows elevated-risk ones, which can be sent to review. Stripe also warns that indiscriminate use of 3-D Secure might lower conversion rates, which is why authentication belongs in the middle band, not across all traffic.

One technique deserves attention: authorise, review, then capture. Stripe notes that issuers must report possible fraud on a captured payment even if it is refunded, but not on an authorisation. A suspicious payment reversed before capture does not become a fraud report.

Which signals are worth using?

Signal	What it catches	False positive risk
Card BIN country vs IP country vs shipping country	Stolen cards used abroad	High for travellers and cross-border shoppers; combine with other signals
Velocity: attempts per card, device, email or IP	Card testing and bot attacks	Low when thresholds are generous
Funding type from the BIN (prepaid, debit, credit)	Disposable prepaid cards on high-value orders	Medium; prepaid is common in some markets
Customer history and verification level	New accounts placing large orders	Low for returning customers
Device and email age	Freshly created identities	Medium
Amount relative to the customer’s norm	Account takeover	Low to medium

Country mismatch deserves care in cross-border commerce. Expatriate workers, travellers and customers on VPNs legitimately pay with cards issued in one country from another, and merchants selling into the Gulf, the Caucasus or Central Asia see all three. A rule that blocks every mismatch blocks those customers too. Stripe’s own example improves such a rule by adding a risk-level condition rather than blocking on country alone.

How do you test a rule before trusting it?

1. Simulate it on past payments and read both columns: fraud caught and good payments caught.
2. Run it in shadow. Stripe lets a rule run at 0% traffic allocation, evaluating it and reporting what would have happened without acting.
3. Roll out gradually. Apply it to a small share of matching payments and increase only when the results hold.
4. Prefer review before block. Stripe advises sending uncertain patterns to review first and converting to a block only once reviews confirm them.
5. Date every change so a shift in approval or dispute rates can be traced to a rule.

Why screen if the issuer will decline fraud anyway?

Because some of what reaches the issuer still counts against you. Card testing, where fraudsters run many small authorisations to find working cards, is monitored by Visa: its VAMP program flags merchants when enumerated authorisations reach 300,000 in a month and 20% of all authorisations, approved or declined. Fraud reports from issuers count towards Visa’s VAMP ratio even when no dispute follows, as our article on chargeback management explains. And a burst of declined fraud attempts can make issuers more cautious with your genuine payments too.

Worked example: tightening a rule

Example figures, for illustration only.

A merchant blocks every card whose issuing country differs from the IP country. In a month, the rule blocks 2,400 payments. Following a holdout sample, the merchant estimates 1,900 of them were genuine customers and 500 were fraud. At an average order of USD 60 and a 25% margin, the lost margin from genuine customers is about USD 28,500; the fraud prevented is worth USD 30,000 in goods plus dispute fees.

The merchant changes the rule: mismatch alone sends the payment to 3-D Secure, and only mismatch plus a high risk score blocks. Blocks fall to 600, of which 450 are fraud. Of the 1,800 sent to authentication, most genuine customers complete it and most fraud attempts fail. Fraud losses barely move; approved sales rise by over a thousand orders a month.

What are the common mistakes?

• Judging rules by fraud caught alone. A rule that stops 500 frauds and 1,900 good customers looks excellent on a fraud report.
• Rules nobody owns. Stripe’s guidance is to remove rules that no longer match payments and to revisit those whose behaviour changes. Without an owner, the rule set only grows.
• Allow rules that are too broad. Stripe notes that allow rules override everything else, including its own risk assessment, so one loose allow rule can undo the rest.
• One rule set for every market. Prepaid cards, foreign-issued cards and shared devices are normal in some markets and rare in others. Rules by country or customer group fit better.
• A review queue nobody clears. Payments waiting for days lose customers as surely as a decline.
• Screening only cards. Account-level checks, such as new accounts placing large first orders, apply to local methods too.

How does Omno support fraud screening?

Omno’s risk controls sit in the same routing layer as the payment: card blocking stops cards linked to fraud or chargebacks before any provider sees them, PSP eligibility can be restricted by customer verification level and customer group, fraud scoring runs on every transaction, and blacklists are shared across partner merchants. Reporting and the routing-decision log show outcomes by provider, method and segment, so rule changes can be measured. The risk controls page covers the settings.