# Payment fraud detection thresholds: 0.5% False Positives vs 2-Hour Delay: Block or Review?

Nathan Lawson · October 27, 2026

> Compare 0.5% false positives with a 2-hour review delay: auto-block only when false-decline cost per transaction exceeds fraud loss per transaction.

| Takeaway | Detail |
| --- | --- |
| Treat the 0.5% false-positive rate and 2-hour review delay as two axes, not competing thresholds. | For 2026 digital payment fraud screening, evaluate the 0.5% rate and 2-hour delay together. |
| Auto-block only when false-positive cost per approved transaction exceeds fraud loss per transaction. | Compare declined-valid rate × average ticket × margin with fraud rate × average ticket × (1 − recovery rate). |
| Compute false-decline cost per transaction before choosing automatic blocking. | Use declined-valid rate × average ticket × margin. |
| Compute fraud loss per transaction before choosing automatic blocking. | Use fraud rate × average ticket × (1 − recovery rate). |

This guide shows how to weigh false-decline cost against fraud loss in digital payment screening.

It gives a two-axis rule for choosing auto-block or review using your own measured rates.

![Payment fraud detection thresholds](https://static.mm-ais.com/article-images-ai/payment-fraud-detection-thresholds-0-5-f-ai-f50db153.jpg)

## How the Two Thresholds Interact

A single fraud score feeds both decisions: one cutoff sends a transaction to automatic block, and a lower cutoff sends it to review. Because both cutoffs live on the same score axis, moving either one changes the population that reaches the other; the block cutoff and review cutoff are not independent dials.

To see the interaction, pull the score distribution from your risk engine—Stripe Radar, Adyen's risk engine, or Sift—and plot valid and fraud transactions as separate score histograms. The overlap zone between the score that produces your 0.5% false-positive rate among valid transactions and your block cutoff is your review band: transactions there are neither clearly safe enough to auto-approve nor risky enough to auto-block.

Most platforms apply a flat score cutoff calibrated on keyed-PAN fraud. Tokenized mobile-wallet transactions, such as Apple Pay and Google Pay with valid cryptograms, sit lower in that risk distribution, yet the same cutoff is applied to them. The cutoff does not adapt to the shift created by tokenization, so wallet traffic is judged against a threshold built for a different payment type.

| Score band | Typical handling |
| --- | --- |
| Below review cutoff | Auto-approve |
| Between review cutoff and block cutoff | Asynchronous review |
| Above block cutoff | Auto-block |

When you tighten the block cutoff, you do not merely block more transactions; you also enlarge or shrink the review band depending on where the review cutoff sits. The same is true in reverse: moving the review cutoff changes how many transactions are eligible to be blocked later. Any threshold change should therefore be checked against both cutoffs before it is deployed.

Use the band size as a capacity check. If a cutoff change pushes more transactions into review, the queue and the 2-hour review delay absorb that volume; if it pushes more into auto-block, your false-decline exposure changes. Recompute the band from the score distribution after every model, rule, or wallet-mix change, and compare the resulting populations with your measured false-positive cost and fraud loss rather than with the cutoff alone.

![How the Two Thresholds Interact — Payment fraud detection thresholds](https://static.mm-ais.com/article-images-ai/payment-fraud-detection-thresholds-0-5-f-ai-98ea58c8.jpg)

## Measuring Your Own FP Cost

Before you decide where any cutoff sits, you need a number most payment teams never calculate: what a wrongly declined valid customer actually costs you. The formula is simple, but isolating the inputs requires a month of decline data and a little discipline.

Start by tagging every decline by reason code over a rolling 30-day window. Visa reason code 57 — do not honor — is where your fraud screen's false positives hide, because it's the generic signal issuers return when a risk model balks. Reason code 05, the truly generic decline, is a mixed bag and should be tracked separately. The population you care about is code 57 declines on tokenized transactions: tokenization already authenticates the card, so a fraud block firing there is your likeliest innocent casualty.

To estimate the valid rate inside that population, re-run a sample of code 57 tokenized declines as test transactions against the same instruments. Whatever share succeeds is your empirical false-decline rate. Then apply the formula: false-decline cost per transaction = (false declines ÷ total attempted) × average ticket × gross margin. On a $100 average ticket at roughly a 3.5% margin net of processing fees, each wrongly declined valid payment forfeits about $3.50 in profit — before counting the lifetime value of a customer who may simply complete the purchase elsewhere and never come back.

Run the mirror calculation on the other axis: fraud loss per transaction = fraud rate × average ticket × (1 − recovery rate). Your recovery rate comes from your own chargeback and representment history, not industry benchmarks. Once you hold both numbers, the decision rule is mechanical — auto-block only when your measured false-decline cost per approved transaction exceeds your measured fraud loss per transaction. If the false-decline number is larger, you are paying more to stop fraud than the fraud itself takes.

Two hygiene checks keep the measurement honest. First, exclude declines you can attribute to customer error — expired cards, typos in expiry or CVV — since no cutoff change will rescue those. Second, re-run the test-transaction sample quarterly, because issuer risk models shift and last quarter's valid rate is not this quarter's.

What this buys you is a defensible starting position. Instead of arguing about thresholds in the abstract, you arrive at the table with two measured dollars-per-transaction figures and a rule for comparing them — and the cutoff debate becomes arithmetic rather than opinion.

![Measuring Your Own FP Cost — Payment fraud detection thresholds](https://static.mm-ais.com/article-images-pixabay/payment-fraud-detection-thresholds-0-5-f-7a767b61.jpg)

## Block vs Review vs Decline Compared

When you line up the three outcomes side by side — auto-block, 2-hour review, and straight decline — the right choice stops being a policy debate and becomes an arithmetic one. A straight decline without review is almost never the right call for valid-looking traffic, because you lose the sale and the data that would tell you whether your cutoffs are set correctly. The real contest is between auto-block and review, and the winner flips depending on ticket size, margin, and how much friction your fulfillment model can absorb. The table below is the comparison this section exists to deliver, with an explicit winner for each profile.

| Transaction profile | Auto-block | 2-hour review | Winner |
| --- | --- | --- | --- |
| High-ticket digital goods (>$200, instant fulfillment) | Risky — false decline destroys the margin on a big sale | Delivery hold caps fraud loss; delay cost is small relative to ticket | Review |
| Low-ticket physical goods (

Canonical: https://l0t.me/blog/payment-fraud-detection-thresholds-05-false-positives-vs-2-hour-delay-block-or-review.php
Markdown: https://l0t.me/blog/payment-fraud-detection-thresholds-05-false-positives-vs-2-hour-delay-block-or-review.php/index.md