radar rule limit reached: cannot add new fraud rule

Not specified by the original author.

TL;DR

Hitting the Radar rule limit is a housekeeping problem, not a reason to delete live protection at random. Audit the rule set first: most accounts carry disabled duplicates, test rules left in live mode, and five narrow rules that one rule with a value list or an OR condition can replace. Consolidate those, archive what is truly dead with an export, and the new rule fits with coverage intact.

radar rule limit reached: cannot add new fraud rule

Use this when

• Radar shows a rule limit message when you try to save a new rule.
• The rule list contains old campaign, test, or duplicate rules.
• Several rules differ only by one value such as a country or BIN range.

Not for this skill when

• A single rule is too complex to save. That is an editor or syntax problem, not the account cap.
• You hit a value list item quota. Consolidate list items instead of rules.

Steps

1. Export or screenshot every rule with its action, condition, and last triggered date from the Radar rules analytics. Verify: you have an inventory showing which rules actually fired in the last 90 days.
2. Disable, do not yet delete, rules that never fired and duplicate another rule, and note the change date. Verify: the disabled set is documented and live coverage rules stay enabled.
3. Merge narrow sibling rules into one rule using OR conditions or a value list for the varying field, keeping the same action. Verify: one consolidated rule covers the same test payments the sibling rules covered.
4. Save the new rule that was blocked, now that headroom exists, and put it in the intended position in the evaluation order. Verify: the new rule saves without the limit error.
5. Delete the disabled duplicates after a full business cycle with no coverage complaint, and keep the export for rollback. Verify: the final rule count sits comfortably below the cap with the export archived.

Variant phrasings

cannot create new radar rule limit

Save error phrasing.

too many stripe radar rules how to consolidate

Consolidation phrasing.

radar rules cap reached cleanup

Cleanup phrasing.

Compatibility: Stripe Radar for Fraud Teams. Rule limits are account level and shared across block, review, and allow rules, so cleanup in any one action type frees space for the others.

Why it happens

Rule sets grow by accretion: a rule per incident, per campaign, per country, and test rules promoted and forgotten. The cap counts them all. Because Radar evaluates conditions cheaply, consolidation rarely costs detection quality, while deleting a live rule at random costs real coverage.

Edge cases / pitfalls

• Rule order matters for review and block precedence. Photograph the order before consolidating and restore it after.
• Allow rules count toward the cap too, and deleting an allow rule can start blocking good customers. Consolidate allows with extra care.
• Seasonal rules, for example holiday velocity rules, should be disabled off season rather than deleted and rebuilt.

Provenance

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

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

Thread query: radar rule limit reached: cannot add new fraud rule

TL;DR: Hitting the Radar rule limit is a housekeeping problem, not a reason to delete live protection at random. Audit the rule set first: most accounts carry disabled duplicates, test rules left in live mode, and five narrow rules that one rule with a value list or an OR condition can replace. Consolidate those, archive what is truly dead with an export, and the new rule fits with coverage intact.

Not specified by the original author.

TL;DR

Radar value lists have a per-list item cap, so prune expired entries before inserting new ones. Split the list by purpose, one for blocked emails and one for trusted customers, so each stays under the cap and stays readable. If you are constantly near the cap, move the logic into rule conditions on fields your system already sets instead of growing the list forever.

stripe radar list quota exceeded error on value list insert

Use this when

• Inserting into a value list returns a quota or limit error.
• A list that used to accept inserts suddenly rejects them.
• You maintain large allow or block lists in Radar.

Not for this skill when

• The error is on rule count, not list items. Rule limits are a separate quota.
• Inserts fail with a validation error rather than a quota error. Check the item format.
• You need per-item expiry. Value lists do not expire entries automatically; prune on a schedule.

Steps

1. List the current items and count them against the documented per-list limit. Verify: you know exactly how many slots are free.
2. Remove stale entries: expired promo blocks, one-off blocks older than your review window, and duplicates. Verify: the count drops well below the cap.
3. Retry the insert. Verify: the API returns the created list item.
4. If the list fills again quickly, split it by purpose into two or more lists. Verify: each list holds a single concern and stays under half the cap.
5. For high-churn data, switch the rule to match on payment fields your system already sets, and shrink the list to exceptions only. Verify: the rule still matches the same payments with fewer list items.

Variant phrasings

stripe radar value list limit reached

Shorter phrasing.

radar list item quota exceeded

Error-text phrasing.

cannot add to radar blocklist list full

Blocklist-centric phrasing.

Compatibility: Stripe Radar value lists; item limits vary by Radar plan. Applies to both allow and block lists.

Why it happens

Value lists are sized for curated exception sets, not for bulk data. Teams append every suspicious email or IP and never remove any, so the list grows until inserts start failing, usually during an incident when you need the insert most.

Edge cases / pitfalls

• There is no automatic expiry. A temporary block from two years ago still occupies a slot.
• Bulk deletes are rate-limited too. Prune in batches with pauses between them.
• Splitting a list means updating every rule that references it. Audit rule references before you split.

Provenance

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

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

Thread query: stripe radar list quota exceeded error on value list insert

TL;DR: Radar value lists have a per-list item cap, so prune expired entries before inserting new ones. Split the list by purpose, one for blocked emails and one for trusted customers, so each stays under the cap and stays readable. If you are constantly near the cap, move the logic into rule conditions on fields your system already sets instead of growing the list forever.

Not specified by the original author.

TL;DR

Roll the new rule back to review-only first, then measure the decline rate before and after the change in Radar analytics to confirm the rule is the cause. Narrow the condition or add exceptions for the legitimate segment it caught, and re-enable it only after the rule tester shows it matching the intended fraud pattern. Never ship a block rule without a review-only soak period again.

stripe radar decline rate spiked after enabling new rule

Use this when

• Authorization or conversion rate dropped right after a rule change.
• The new rule is the only recent change.
• You need to prove which rule caused the spike.

Not for this skill when

• The decline rate rose with no rule changes. Look at issuer declines, traffic mix, or outages.
• Declines come from the issuer side. Radar rules do not cause issuer declines.
• The spike is in disputes, not declines. That is a different problem.

Steps

1. Set the new rule to review-only, or disable it, right away. Verify: the rule list shows the change.
2. In analytics, compare the decline rate for the 24 hours before and after the rule went live. Verify: the spike lines up with the rule change.
3. Pull a sample of declined payments and confirm the rule matched them. Verify: the payment timelines name the rule.
4. Tighten the condition or add an allowlist exception for the legitimate segment. Verify: the rule tester matches the fraud pattern but not the sample good payments.
5. Re-enable the rule in review-only mode for a soak period before restoring block. Verify: review volume from the rule stays sane for several days.

Variant phrasings

radar new rule increased declines

Shorter phrasing.

stripe radar rule causing authorization drop

Authorization-focused phrasing.

decline spike after radar rule change

Metric-first phrasing.

Compatibility: Stripe Radar custom rules. Works with Radar analytics decline-rate views.

Why it happens

A rule that looks precise in the tester can still match a broad real-world segment, especially when it keys on a common attribute like billing country or order amount. Because block rules act silently, the first sign of trouble is the revenue dip, not an alert.

Edge cases / pitfalls

• Two rule changes close together can confound the before-and-after. Change one rule at a time.
• Seasonal traffic shifts can mimic a rule-caused spike. Compare against the same weekday last week, not just yesterday.
• Review-only mode still costs analyst time. Set a calendar reminder to revisit the rule after the soak.

Provenance

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

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

Thread query: stripe radar decline rate spiked after enabling new rule

TL;DR: Roll the new rule back to review-only first, then measure the decline rate before and after the change in Radar analytics to confirm the rule is the cause. Narrow the condition or add exceptions for the legitimate segment it caught, and re-enable it only after the rule tester shows it matching the intended fraud pattern. Never ship a block rule without a review-only soak period again.