Why Stripe Radar false positives at multi-brand scale

Stripe Radar is one of the best fraud-detection products in the payments industry. On a single-brand account with a few million dollars of volume, Radar's false-positive rate typically sits at 0.5-1% — acceptable tradeoff for the fraud it catches. The teardown in this post is about what happens to that same Radar system when an operator runs 5-15 brands across linked Stripe accounts and the same customer base is purchasing across multiple of those brands.

1. How Radar actually works

Radar is a machine-learning fraud system trained on Stripe's global transaction graph. It evaluates each transaction against ~200 signals including:

• Card age and issuing bank.
• Billing/shipping mismatch.
• Device fingerprint history.
• IP geolocation and velocity.
• Transaction amount vs merchant's average.
• Email domain reputation.
• Customer history with the merchant.
• Customer history across Stripe's entire network (this is the important one).

The cross-network signal is where multi-brand falls apart.

2. The "customer seen elsewhere" signal

Radar gives each card a reputation score partly based on where that card has transacted across the Stripe network. A card that has a clean history with one merchant is scored well. A card that shows a pattern — say, three transactions to three different merchants in the same 24 hours — is scored less well.

For a random card in the wild, this pattern suggests card testing. For your loyal customer who buys from three of your brands (because they bought your flagship product, loved it, and bought your adjacent-brand product two hours later), the signal looks identical.

3. Why this specifically hurts multi-brand

Single-brand operators do not trigger this pattern — their customers transact repeatedly with the same merchant, which Radar sees as relationship-building. Multi-brand operators trigger it structurally because:

• Their customer base overlaps across brands by design.
• Brands share marketing channels, so customers see multiple brands and convert across them.
• Portfolio operators often cross-sell, sending customers from brand A to brand B.
• Customers may use the same card across all your brands for convenience.

From Radar's perspective, your portfolio looks like "one card buying across N unrelated merchants in short windows," which is textbook card-testing behavior from the pattern-matcher's point of view.

4. The false positive rate numbers

In operator intakes we've seen across multi-brand Stripe accounts:

• Single-brand Stripe accounts running Radar: 0.5-1% false-positive decline rate.
• 3-brand portfolios: 1.5-2.5%.
• 5+ brand portfolios: 2-4%.
• 10+ brand portfolios with shared customer overlap: 3-5%+.

On $10M of annual revenue, a 3% false-positive rate represents roughly $300K of declined good customers — before accounting for cart abandonment caused by the friction.

5. The compounding cart-abandonment cost

A declined payment does not simply reroute to another card. The customer experience is:

• Customer enters card details, clicks pay.
• Radar declines. Stripe returns a generic "card declined" error.
• Customer thinks their card has an issue. Many do not retry.
• Those that do retry often try a different card, exposing Radar to the same signals on the new card.
• If both decline, 70-80% of customers abandon.

The hidden cost is not the declined transaction value. It is the LTV of the customer who concluded that your checkout is broken.

6. The Radar Rules problem

Stripe lets you write custom Radar Rules to adjust the model. Multi-brand operators try to fix false positives by writing rules like "allow transactions from known-good customer emails" or "relax fraud threshold for returning customers." These rules work within a single Stripe account but do not cross accounts.

Your customer who is "known-good" on Brand A's Stripe account is an unknown first-time buyer on Brand B's Stripe account. You cannot write a cross-account allow rule because Radar Rules are per-account.

7. The Radar for Teams workaround is incomplete

Stripe offers Radar for Teams which allows rule sharing across linked Stripe accounts. This helps the rule-sharing side but does not help the model-training side. Each connected account still has its own model that treats customers as first-time-buyers. The cross-account reputation comes from Stripe's network-wide signals, which still flag legitimate cross-brand purchases as anomalies.

8. What multi-brand operators actually need

• Portfolio-level customer identity. The fraud system needs to know that customer X has a trusted relationship with your portfolio, not just with one brand.
• Cross-brand allow listing — when a customer is known-good on Brand A, purchases on Brand B should get the benefit of that reputation.
• Brand-specific risk models — the risk profile of a supplement purchase is different from an apparel purchase. One fraud model across brands dilutes both.
• Manual-review orchestration — when a transaction is uncertain, route to a human workflow rather than auto-decline.

None of this is what Stripe Radar provides. Radar is built for single-merchant use cases where cross-brand customer portability is not a thing.

9. The alternatives

• Signifyd, Kount, Riskified — enterprise fraud tools with cross-account customer identity. All support portfolio-level rules and reputation.
• DataVisor, SEON, Sift — more flexible risk platforms that allow custom identity resolution across brands.
• Bespoke allow-listing at the orchestration layer — when your routing knows customer X has a 2-year history with Brand A, Brand B's checkout can apply looser rules.

For most multi-brand portfolios, the cost of an enterprise fraud tool ($2-8K/month) is recovered within 60 days via recovered false-positive revenue.

10. When Radar is fine

• Single-brand operations regardless of size. Radar is excellent in its intended use case.
• Multi-brand portfolios where brands have non-overlapping customer bases. E.g., a holding co with brands in unrelated verticals (apparel + B2B tools + restaurant POS). Customer overlap is near zero, cross-brand false positives do not occur.
• Very small portfolios where the absolute revenue impact is small enough to tolerate.

11. What to do if you are seeing high Radar false positives

• Pull your Radar false-positive report (Stripe dashboard → Radar → Reviews → Analytics). If >1.5% across brands, you have the problem.
• Identify the cross-brand overlap via customer email analysis. If >15% of customers transact on multiple brands, Radar's pattern-matcher is working against you.
• Reach out to Stripe about Radar for Teams rule sharing as a short-term mitigation.
• Evaluate a third-party fraud tool for portfolio-level identity.
• Consider orchestration-layer risk routing to keep Radar as one input rather than the sole fraud check.

Apply in 12 questions and we will return a fraud-stack recommendation tailored to your portfolio's cross-brand overlap pattern.