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

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.

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.

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.

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.

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.

The high-ticket digital-goods case is the clearest review win. Because fulfillment is under your control, you can hold delivery until the review completes, which caps your fraud exposure at the ticket value — no goods leave, so a fraudulent approval costs you a refund and fees, not irreplaceable inventory. Meanwhile, a false decline on a transaction that size wipes out more margin than a dozen legitimate sales earn. The asymmetry forces review.

The low-ticket physical-goods case flips for two reasons stacked on top of each other. First, per the crossover logic, you should auto-block only when your measured false-decline cost per transaction exceeds your measured fraud loss per transaction — compute both and place the cutoff there. Second, even where review might catch marginal cases, the economics of human screening don't work: at $1–3 per manual check against tickets under $50 on thin margins, review labor alone can consume the profit from the transaction you're protecting.

The third row is not a threshold decision at all. Tokenized mobile-wallet transactions carrying valid cryptograms are cryptographically authenticated — the credential-presentment risk your keyed-PAN cutoff exists to catch is already answered. Exempting them shrinks the population the cutoffs must judge, which improves the precision of both.

Before trusting the table, run one check per row: pull a month of decisions, segment by profile, and confirm your actual fraud losses and false-decline costs land where the winner column says they should.

The 2-Hour Delay: What It Costs

To quantify the conversion cost of holding a transaction for asynchronous review versus an instant decision, A/B your review queue: hold a share of review-eligible transactions for 2 hours and measure completion rate against instant-approve controls drawn from the same review-eligible set. The delta between those two completion rates, applied to the number held, is your delay cost per held transaction. Measure it against the exact slice you would actually route to review rather than extrapolating from unrelated payout figures.

Before you accept that delta at face value, run one strict check on authorization validity. A payment authorization hold does not last indefinitely: it expires within the authorization validity window set by the network, and your capture window may be shorter than that window. Because of this, a 2-hour review must re-authorize if it exceeds your capture window. Check your acquirer's spec for both values for the routes you run, as they are not universal. Any failed re-authorization from that test must be counted as part of the same completion-rate delta, not written off as a separate "technical" item.

Keep this constraint separate from payout gating. As defined by the Flutterwave Help Center, a settlement threshold is the minimum amount that must accumulate before due settlement can be remitted to a merchant account. That is a remittance condition, not an authorization expiry. Conflating the two will pull your focus to when money leaves your account, instead of whether the transaction can still be captured at all after the hold.

Finally, lock your test to discipline: only route review-eligible transactions to the hold branch, only compare to instant-approve controls, and only count completed captures. If your routes require re-authorization for any portion of that 2-hour hold, record its failure rate explicitly in the same A/B. The output of this test is one measured delay cost per held transaction — nothing more, and nothing borrowed from settlement minimums — to be used strictly for the tradeoff of holding for asynchronous review versus an instant decision.

Worked Example: Run the Numbers

This section works one concrete numeric example end to end. For illustration, the scenario is a single-party checkout, and the party is treated only as the merchant in question. The inputs for this illustration are limited strictly to the components named by the reader rule: a declined-valid rate, an average ticket, a margin, a fraud rate, and a recovery rate. No other identifiers, fees, or windows are assigned here.

The first calculation step is the false-decline cost per transaction: take the declined-valid rate and multiply by the average ticket and by the margin. The second calculation step is the fraud loss per transaction: take the fraud rate and multiply by the average ticket and by (one minus the recovery rate). These are computed against the same transaction unit, with no unit mismatch introduced. At every step, the check is to only use values that were isolated from your own data, not borrowed from an outside list.

The comparison is direct: block automatic only if the false-decline cost per transaction is greater than the fraud loss per transaction. The winner for this illustration is automatic block in that case, and the break-even trigger is equality between those two measured amounts. If the fraud loss per transaction is greater, the winner is not automatic block by this test, and if equal, the test gives no automatic block advantage by cost alone. This is the only decision drawn from this example, and it is made solely by those two measured costs.

And Decision Rules

This section walks the full numeric worked example with both wrong-answer costs and the copy-usable threshold worksheet. The comparison must be made in dollars, not in percentages alone, because the two wrong answers do not scale equally for every business.

Using a stable set of inputs for 10,000 monthly transactions at a $100 average ticket, a 0.15% fraud rate, a 0.5% false-positive rate, 60% chargeback recovery, and 40% gross margin: fraud loss = 15 × $100 × (1 − 0.60) = 15 × $100 × 0.40 = $600/mo. False-decline cost = 50 × $100 × 0.40 = $2,000/mo. With those numbers, review wins, so do not tighten the cutoff to chase the 0.5% false-positive rate.

The cost of being wrong both ways is what locks in that choice. Tightening to kill the 0.5% false-positive rate costs ~$1,400/mo more in forfeited valid revenue than it saves in fraud. Loosening to zero false positives adds ~$600/mo in unrecovered fraud. Even with the 2-hour review delay factored in, the $2,000/mo false-decline cost remains larger than the $600/mo fraud loss under these inputs, making the review path the cheaper wrong answer.

Copy-usable threshold worksheet: (1) False-decline cost per transaction = (declined-valid rate) × (average ticket) × (gross margin). (2) Fraud loss per transaction = (fraud rate) × (average ticket) × (1 − recovery rate). (3) Rule: block automatic only if your measured false-decline cost per transaction exceeds your measured fraud loss per transaction. (4) Check both directions: estimate the monthly delta for tightening (lost margin from removed false positives minus fraud saved) and for loosening (fraud added minus margin gained). If either delta is negative in your favor, do not move the cutoff.

Run this worksheet against your own numbers before changing any cutoff. The question is not which percentage looks better, but which wrong answer you can afford, measured in the same dollars per transaction.

What to do next

Frequently Asked Questions

Are the 0.5% false-positive rate and 2-hour review delay meant to be traded off against each other?

For 2026 digital payment fraud screening, evaluate the 0.5% rate and 2-hour delay together, as they are two axes, not competing thresholds.

What condition must be met before enabling automatic blocking?

Auto-block only when false-positive cost per approved transaction exceeds fraud loss per transaction.

Which formula should I use to calculate false-decline cost per transaction?

Compute false-decline cost per transaction using declined-valid rate × average ticket × margin.

Which formula should I use to calculate fraud loss per transaction?

Compute fraud loss per transaction using fraud rate × average ticket × (1 − recovery rate).

If I adjust my block cutoff, will it impact my review queue?

Because both cutoffs live on the same score axis, moving either one changes the population that reaches the other, so the block cutoff and review cutoff are not independent dials.

Which risk engines can I use to visualize the overlap between valid and fraud scores?

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.

Quick answers

Also worth reading: Instant merchant payouts: $1M Instant Payments (FedNow) vs Venmo Myth: Instant merchant payouts: $1M Instant · Tap to pay fraud: Phone vs Plastic vs Chip Cut 60% Loss 2026: Tap to pay fraud: Phone · EMV counterfeit fraud: verify the 76% claim before adopt or skip: EMV counterfeit fraud: verify the