How Stripe Risk Review Works: Inside the Machines That Restrict Accounts (2026)#

TL;DR: Stripe runs continuous automated reviews on three axes — business model (what you declared vs what transactions show), transaction behavior (disputes, velocity, patterns), and identity/consistency (KYC data vs operational reality). Restrictions fire when the axes disagree. You can't game the model, but you can design your account so its data tells a coherent story — which is what every favorable review outcome has in common.

Stripe restricts thousands of legitimate accounts, and the affected merchants share one experience: the restriction email reads like it came from a different conversation than anything they did. That's because it did — the restriction decision is a model output across signals you mostly can't see. Understanding the machinery won't let you trick it (nothing will, and attempts read as evasion), but it will let you build an account that reviews cleanly.

Axis 1: Business Model Coherence#

At onboarding you declared a business: category, website, expected volume, average ticket. Stripe's first continuous check compares transactions to declaration:

• Average charge sizes drifting far from your stated ticket
• Volume ramps that outpace your stated trajectory
• Product descriptors on disputes/cards revealing categories you didn't declare
• Website changes (new product lines) unaccompanied by profile updates

The model doesn't punish growth — it punishes unexplained divergence. The account whose live behavior matches its declaration is boring to the risk system, and boring is safe.

Axis 2: Transaction Behavior#

The behavioral layer watches the classic risk pattern language of card networks, translated by Stripe's models:

• Dispute rate climbing toward monitoring-program thresholds
• Refund velocity spikes — refunds are information; bursts of them pattern-match to fulfillment failures or buyer's-remorse products
• Velocity anomalies — sudden success-rate drops, test-transaction patterns, card-testing signals on your checkout
• Descriptor confusion — buyers not recognizing your billing name, driving "fraud" disputes that are really confusion

Axis 3: Identity and Consistency#

The KYC layer re-verifies continuously rather than once: legal entity data, beneficial owners, bank account ownership, website contact information matching the account. Divergences — a new bank account owned by a different name, a website's legal page naming a different entity — surface as "verification required" reviews.

What Happens in a Review#

When signals stack past thresholds, the flow typically moves through stages, each with different recovery odds:

1. Under review — processing continues; information requests arrive. This is the highest-leverage moment: complete, consistent documents end most reviews here. (Our Stripe under review guide covers this stage.)
2. Restriction — payouts held or processing limited pending review. Documentary response remains effective.
3. Account deactivated / terminated — the model's final output, appealable but rarely reversed. Fund release runs on a rolling window regardless.

The escalation usually requires repeated divergences or a single severe signal (confirmed fraud patterns, restricted-category detection). Most legitimate accounts that resolve reviews badly did so by answering information requests slowly or inconsistently — the model doesn't read your excuse, the human reads your documents.

Designing Your Account to Review Cleanly#

The actionable summary of everything above:

• Keep the declaration current. Business model changed? Update the Stripe profile before the transactions change. Divergence declared-in-advance reads as normal business evolution; divergence discovered reads as concealment.
• Name your descriptors recognizably. Buyer-recognized billing descriptors quietly reduce "fraud" disputes.
• Reconcile your website to your account. Legal entity name, contact information, product line — one story, everywhere.
• Watch your own dispute rate the way Stripe does — weekly, with a threshold that triggers your own review before theirs does.
• Answer information requests completely, once. The account that resolves reviews in one pass has a materially different history than the account that answers in fragments — and that history is itself a signal.

FAQ#

Can I ask Stripe what specifically triggered my review?#

Support discloses the review category (KYC, dispute patterns, business-model question) more readily than the specific model signal. Ask directly — the answer shapes which documents matter for your response.

Does volume growth itself trigger reviews?#

Growth triggers velocity checks, which trigger reviews mainly when growth is inconsistent with your declared trajectory or arrives with dispute spikes. Declared growth with clean disputes doesn't restrict accounts — undocumented growth does.

My account is restricted but every document is accurate. Why me?#

Accurate-but-incomplete loses to accurate-and-consistent: reviews check whether your documents reconcile with each other — invoice amounts vs statement lines vs website claims. A single mismatched entity name across documents is enough to extend a review.

How long do Stripe reviews take?#

No published SLA — document-complete responses commonly resolve within days to two weeks; complex compliance reviews run longer. The range compresses dramatically when the first response is complete.

---

Under review or restricted right now? UnBanAI structures your response around the consistency Stripe's reviewers actually check.