Finance ops · Production

Stripe builds a payments foundation model lifting card-testing detection from 59% to 97% and scales internal AI to 8,500 employees daily

The problem

Traditional task-specific ML models achieved only 59% accuracy at detecting card-testing attacks hidden inside large-merchant transaction volumes. As AI inference costs rose, free trial and refund abuse became existentially threatening to AI businesses. Internally, Stripe's data discovery was hampered by low-quality tables and lack of persona context for table selection.

First attempt

Task-specific ML models trained on fraudulent dispute labels achieved only 59% accuracy at detecting card-testing attacks hidden in large-merchant transaction volumes.

Workflow diagram · grounded in source
1
Transaction enters charge path
Trigger
Every Stripe transaction enters the charge path, with the platform processing approximately 50,000 transactions per minute.
▾ source quote
“we see, like, 50,000 transactions a minute”
2
Foundation model embeds payment sequence
Ai action
A transformer-based domain foundation model treats each charge as a token and behavior sequences as the context window, ingesting full feature breadth including IPs, BINs, amounts, methods, geography, device, and merchant traits.
▾ source quote
“Treat each charge as a token and behavior sequences as the context window. Ingest tens of billions of transactions (50,000/min) with full feature breadth: IPs, BINs, amounts, methods, geography, device, merchant traits, and more.”
3
Card-testing clusters identified in real time
Ai action
Dense payment embeddings surface card-testing clusters in real time that traditional ML could not detect hidden within large-merchant volumes.
▾ source quote
“You start to see these clusters sort of pop out and you know in real time that they're card-testing and you can block them”
4
Block decision issued in under 100ms
Output
A block or allow decision is issued on the charge path in under 100 milliseconds of latency.
▾ source quote
“it is happening on the charge path in less than 100 milliseconds of latency”
5
Toolshed MCP server provides tool layer
Integration
Stripe's Toolshed MCP server provides a central tool layer wired into Slack, Drive, Git, a data catalog, and query engines, enabling internal agents to both retrieve and act.
▾ source quote
“Toolshed (MCP server). Central tool layer wired into Slack, Drive, Git, data catalog (Hubble), query engines, and more. Agents can both retrieve and act using tools.”
6
Text-to-SQL query via Hubert
Ai action
Internal text-to-SQL assistant Hubert, used by approximately 900 people per week, queries the Hubble data catalog with persona context to bias table selection.
▾ source quote
“"Hubert" (used by ~900 people/week) sits on Hubble for broad data; biggest failure mode is data discovery. Most of their work has been on deprecating low‑quality tables, creating human‑owned docs for canonical datasets, and persona context ("which org you're in") …”
Reported outcome

The payments foundation model lifted large-merchant card-testing detection from 59% to 97%, processing every Stripe transaction in under 100ms.
Internal AI adoption reached approximately 8,500 employees daily, with 65–70% of engineers using AI coding assistants. An LLM-assisted pan-EU payment integration was completed in approximately two weeks rather than approximately two months.

Reported metrics
card-testing detection accuracy — task-specific ML baseline59%
Card-testing detection accuracy — foundation model97%
Transaction processing latency through foundation model<100ms
Stripe employees using LLM tools daily~8,500
Show all 21 reported metrics
card-testing detection accuracy — task-specific ML baseline59%
card-testing detection accuracy — foundation model97%
transaction processing latency through foundation model<100ms
Stripe employees using LLM tools daily~8,500
engineer AI coding assistant adoption65–70%
pan-EU integration time — before LLM~2 months
pan-EU integration time — with LLM assistance~2 weeks
Hubert internal users per week~900
transactions processed per minute50,000
Link consumer base200m+
Lovable revenue share from Link transactions58%
AI company ARR ramp speed vs comparable SaaS cohort2–3× faster
median AI company year-1 country count55
median AI company year-2 country count>100
AI company growth rate vs S&P 5007x faster
annual transaction volume processed on Stripe~$1.4 trillion
global GDP share processed on Stripe~1.3%
payments leaders citing friendly fraud as top challenge47%
stable coin share of Shade Form payment volume20%
incremental revenue from stable coin channel (Shade Form)half of stable coin volume is fully incremental
AI company country count growth by year end~2× the country count
Reported stack
RadarToolshedSigma AssistantHubertHubbleLinkACPToken BillingBigQuerySlackDriveGit
◆ Does this fit your context?

Compare to your context

Tell us your scale, team, and constraints. We'll show what changes at your size, what fails at your scale, and whether this case is a fit, needs adaptation, or won't scale to you. Free demo, no signup.

Compare to your context →
~30 seconds · free
Source
https://www.latent.space/p/stripe
Read source ↗

Frequently asked questions

What did this team achieve with this AI workflow?

The payments foundation model lifted large-merchant card-testing detection from 59% to 97%, processing every Stripe transaction in under 100ms.

What tools did this team use?

Radar, Toolshed, Sigma Assistant, Hubert, Hubble, Link, ACP, Token Billing, BigQuery, Slack.

What results were reported?

card-testing detection accuracy — task-specific ML baseline: 59%; Card-testing detection accuracy — foundation model: 97%; Transaction processing latency through foundation model: <100ms; Stripe employees using LLM tools daily: ~8,500 (source-reported, not independently verified).

What failed first in this deployment?

Task-specific ML models trained on fraudulent dispute labels achieved only 59% accuracy at detecting card-testing attacks hidden in large-merchant transaction volumes.

How is this finance ops AI workflow structured?

Transaction enters charge path → Foundation model embeds payment sequence → Card-testing clusters identified in real time → Block decision issued in under 100ms → Toolshed MCP server provides tool layer → Text-to-SQL query via Hubert.

Related finance ops cases

WHAT TO DO WITH THIS

Now compare it to your context

This case is one data point. Whether its pattern fits you depends on your volumes, your stack, and your exception load — that comparison is the step no case study can do for you.

Browse the Finance ops cases →