Estimate the annual addressable market for Radar among platform businesses

Problem Statement Description

Product context: Stripe is financial infrastructure for internet businesses; its products include payments, Checkout, Billing, Connect, Radar, Issuing, Terminal, and tax tools.

Stripe Radar helps businesses detect and prevent payment fraud while balancing false positives, conversion, and operational effort. In this guesstimate, estimate the annual addressable market for Radar specifically among platform businesses, such as marketplaces, SaaS platforms, creator platforms, delivery networks, booking platforms, and other companies that process payments on behalf of many sellers, merchants, or service providers.

Focus on the annual revenue opportunity that a fraud-prevention product like Radar could reasonably address in this segment. The estimate should be grounded in a clear definition of “platform businesses,” the relevant payment volume or transaction base, fraud-risk exposure, likely product adoption, and monetization model. You may choose a geography or global scope, but you should state it explicitly.

This is not asking for Stripe’s current Radar revenue or a precise industry figure. It is asking for a structured market-sizing estimate that shows how you break down the market, choose assumptions, test reasonableness, and identify the biggest drivers of uncertainty.

The experience should consider:

- Scope: whether the estimate covers global platform businesses or a specific region, and which types of platforms are included or excluded.

- Unit of estimation: whether you size by number of platforms, number of connected merchants, transaction volume, payment count, fraud-review volume, or Radar-like software spend.

- Population: how many relevant platform businesses exist across segments such as marketplaces, vertical SaaS, gig economy, ticketing, travel, creator economy, and commerce enablement.

- Adoption and frequency: what share of platforms would need automated fraud protection, how often transactions require screening, and how fraud risk varies by category.

- Monetization assumptions: how Radar could be priced or valued, such as per-transaction fees, basis points on volume, bundled fraud tools, or enterprise contracts.

- Sensitivity: which assumptions most affect the estimate, including platform payment volume, fraud exposure, attach rate, average pricing, and competitive alternatives.

- Sanity checks: how to compare the result against broader payments volume, fraud-loss economics, fraud-prevention software spend, and the scale of comparable payment infrastructure businesses.

The goal is to produce a defensible annual addressable market estimate with transparent assumptions, logical segmentation, and clear acknowledgment of uncertainty, rather than a single unsupported number.