## TL;DR
Find the single rule or signal driving the surge in the Radar analytics view, then demote it from block to review or pause it while you investigate. Bulk-resolve the obvious good payments as safe so the queue drains, and add the affected customer segment to an allowlist. Then tighten the rule condition so the surge cannot repeat.

```text
radar review queue flooded: how to fix false positive surge
```

## Use this when
- The review queue grew sharply in a short period.
- Many queued payments share a pattern: same country, same product, same price point.
- Analysts cannot keep up with manual review volume.

## Not for this skill when
- The queue is full of genuinely suspicious payments. That is Radar working; staff the queue.
- The surge came from a traffic spike, not a rule change. Scale review capacity instead.
- Payments are being blocked, not queued. That is a block-rule problem.

## Steps
1. In Radar analytics, group recent reviews by matched rule and by signal. Verify: one rule or signal accounts for most of the surge.
2. Change that rule's action to review-only, or pause it, immediately. Verify: new payments stop entering the queue from that rule.
3. Bulk-select the clearly legitimate queued payments and mark them safe. Verify: the queue count drops to a manageable level.
4. Add the affected segment, such as customer ids, emails, or card fingerprints, to an allowlist value list. Verify: a re-evaluation of a sample no longer matches the rule.
5. Rewrite the rule condition more narrowly, then restore its original action. Verify: the rule tester matches the true positives but not the surge pattern.

## Variant phrasings
### radar review queue too many false positives
Volume phrasing.
### stripe radar sudden spike in manual reviews
Spike phrasing.
### radar queue overwhelmed how to clear
Operations phrasing.

Compatibility: Stripe Radar with review queues; Radar for Fraud Teams for custom review rules. Applies to card payments.

## Why it happens
A new or edited rule with a broad condition starts matching a large slice of legitimate traffic. Because every match needs a human decision, the queue floods faster than analysts can clear it, and the backlog itself becomes the incident.

## Edge cases / pitfalls
- Bulk-marking safe trains Radar. Only bulk-resolve payments you have actually verified as legitimate.
- Pausing the rule also pauses its true positives. Watch the dispute rate while it is paused.
- Surges sometimes come from a partner or affiliate sending new traffic patterns. Check traffic sources before blaming the rule.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YU_lYqH_V91TfB2aX_czsA