Stripe's Payments Foundation Model: How Data & Infra Create Compounding Advantage, w/ Emily Sands

Today my guest is Emily Sands, head of data and AI at Stripe, the programmable financial infrastructure company that in 2024 processed $1.4 trillion in payments, or roughly 1.3% of global GDP, for everyone from solo entrepreneurs to the Fortune 100, and which continues to grow at a blistering pace.

We begin by discussing the many fascinating details of Stripe’s new foundation model for payments and how Stripe is using this model to deliver improved performance across its broad suite of products. While it might seem unassuming at first glance, I would argue that the payments foundation model has several important lessons to teach us.

First, while payments are represented in text, the payments foundation model is not a language model in the familiar sense. On the contrary, payments are treated as a distinct modality. Importantly, no payment is an island. To properly understand a single payment requires Stripe to assemble extensive context, including recent activity associated with multiple entities: the buyer, the card, the device used to make the purchase, and the merchant.

So much context quickly becomes overwhelming to humans, but this is exactly where neural networks can shine. Indeed, when Stripe first deployed this model to detect card testing, which is a process fraudsters use to determine which stolen cards actually work, they saw a jump in their detection rate from 59% to 97%. Obviously, that’s a massive win, not just for Stripe, but for the entire e-commerce ecosystem that collectively bears the cost of fraud.

Now, if you’ve listened to this show for a while, you know that one of my pet theories is that the shortest path to superintelligence is to integrate today’s reasoning models with models that are trained on other modalities that humans aren’t well adapted to understand. I’d say it’s safe to say that the payments foundation model is superhuman when it comes to understanding payments.

This conversation left me wondering how many other businesses are training foundation models on their own modalities, as well as how many other interesting modalities might still currently be hiding in plain text. I can imagine that this proprietary-modality strategy might work in any number of domains, including health, cybersecurity, logistics, energy, and insurance. But, to be honest, I haven’t found too many other examples of this strategy being used today.

If you happen to know of any other foundation models being trained on interesting proprietary modalities, please ping me and let me know. I would love to do more episodes exploring this theme.

The next lesson, perhaps as important to Stripe’s success as the model itself, is the way they are using it. Rather than trying to design the foundation model to support all use cases directly, they are exposing payments foundation model representations, allowing engineers to use them as additional inputs to the many classification and other machine-learning systems they’ve already developed.

The richness of the foundation model signal makes everything else work better, but doesn’t require a major rethinking of existing systems. Again, outside of social network companies, which I do believe make their user and content representations available in this way, I’ve not heard of other companies taking this approach. It seems to me now that more of them should consider it.

Finally, the most important lesson from a societal standpoint might be that AI strongly favors incumbent platforms that have the data necessary to train such differentiated models. The flywheel that Stripe has created here, which translates its incredible scale into commercial advantage, is allowing it to reduce the cost of fraud for its customers even as fraud is rising across the broader ecosystem.

This makes Stripe the obvious choice going forward, which in turn further strengthens its data advantage and product lead. It is genuinely hard for me to imagine how anyone aside from a few of the world’s largest tech companies could ever compete with Stripe, meaning that even as history begins to unfold at a dizzying pace in many respects, competition in many key markets may effectively come to an end.

This isn’t necessarily a problem. I’ve never supported punishing companies for their excellence, and I’ve never been convinced that we should break up American tech companies. But it does seem like something that policymakers will need to think long and hard about as they envision the AI future and hopefully begin to imagine a new social contract.

There’s a lot more in this episode besides these key strategic insights, including how Stripe is designing processes to iterate quickly enough to stay ahead of fraudsters, including by using LLMs as judges to fill in missing data; how they ensure reliability in their LLM-powered “talk to your data” product experiences; how developers can accelerate product development by treating Stripe as their payments database of record; what Emily and her team are seeing in agentic commerce today; and how they think about scoping their AI ambitions and investments.

All in all, as you might expect from Stripe, it’s a high-alpha episode with practical lessons for rank-and-file AI engineers and big-picture implications for executive-level AI strategists. Without further ado, I hope you enjoy this deep dive into how smart use of AI is transforming one of the world’s most critical financial infrastructure companies with Emily Sands, head of data and AI at Stripe.

Thanks for having me.

I’m excited for this conversation. Stripe is obviously a globally recognized leader in payments and is doing some really interesting things in AI, with high standards everywhere and a lot of shared DNA with some of the big frontier AI developers. So, there’s a lot to get into today.

For folks who want to do a deeper dive into Stripe and the payments ecosystem, there’s a podcast from maybe 6 months ago now on our sister pod, Complex Systems. I’d definitely recommend that for folks who want to do a deeper primer on the payments world, which is a fascinating and Byzantine one with many rabbit holes to go down.

We won’t do nearly as much of that today. We’ll stay more focused on some of the cool new AI stuff that you guys are doing. But maybe, just for a super-quick primer, how would you describe the role that Stripe plays in the economy? Then we’ll use that as a jumping-off point to get into the AI stuff.

You said payments infrastructure. We started as payments infrastructure. Absolutely true. We now build broader programmable financial infrastructure.

In plain terms, we give any business—the business could be a teenager who’s selling a Figma template, or it could be any one of now more than half of the Fortune 100 that run on Stripe—the rails and intelligence to move money online and to grow faster.

Last year, companies processed $1.4 trillion through Stripe. We’ll talk about AI today. Every one of those charges becomes training data for the AI systems that we’ll talk about. But that flywheel also means that we’re no longer just the payments API.

We optimize the entire payments life cycle. The gory details are covered in that earlier episode, but it’s the checkout UX, fraud prevention, bank routing, retries, and even things like dispute paperwork, so that businesses can really keep more of every hard-earned dollar and scale up with very small teams.

We think of the tools we’re building as structural growth tailwinds, and we’re already seeing it in the data. Businesses on Stripe grew 7 times faster than the S&P 500 last year.

Wow. Okay, a lot of good nuggets there. I have been a customer, actually, for what it’s worth, since not the earliest early days, but pretty early days—at least 10 years that I’ve been a Stripe customer with my company, Waymark. So we’ve seen a lot of the evolution from the customer side.

The biggest thing that has caught my attention in terms of what Stripe is doing with AI is the payments foundation model. I’d love to spend a good chunk of time really going into the details on that, because one of the things that I have been fascinated with and trying to see around the corner and better understand is to what degree we’re going to get a form of superintelligence via AIs that become natively capable of understanding potentially a huge range of different modalities.

People are familiar now with image generation. Of course, we had text-to-image and image-generation models. Now those have come together in this really tightly coupled, deeply integrated way with Nano Banana and other recent innovations in that space.

I have this theory that one thing people really underappreciate is the degree to which training on these other modalities of data is going to create superhuman capability in these domains that are familiar to us, but also, in many ways, very alien.

Maybe for starters, what can you tell us about the fundamentals of the payments foundation model? What does the data look like? Obviously, it’s transaction data, but give us more detail on that. What is transaction data when you really get into the weeds of it?

Yeah, and it’s a good point.

There’s been a ton of coverage of large-scale traditional LLMs and a lot less coverage of domain-specific foundation models, of which the payments foundation model is one. For us, it’s really been a step-function change in the speed and quality with which we can deliver all of those optimization solutions I talked about in auth, in fraud, and in disputes.

At its core, it’s a transformer model that turns every payment—the tens of billions of transactions that run through Stripe—into a compact vector. It’s like giving each transaction its own kind of latitude and longitude. Once you have that map, you can use it for all sorts of downstream tasks: to figure out what’s fraud, to figure out how to authenticate, and to figure out what’s a valid versus invalid dispute, without having to train a new model from scratch every time.

I think what makes it work—the reason you can build a domain-specific foundation model in the payments context—is Stripe’s scale. We process about 50,000 new transactions every minute. At that density, payments start to look, in a lot of ways—not in all ways, but in a lot of ways—like language.

There’s kind of a syntax to a payment, right? There are the card BINs, the merchant codes, and the amounts. Then there’s an analog to semantics: how a device or card gets reused over time. In the same way that language transformers are learning embeddings, and words with similar meanings cluster together, the premise of the payments foundation model is: What if every charge or sequence of charges—and we can talk about that, too—had its own vector in a similar space?

The inputs are, you’re right, just the raw payment signals as they come in: the card details, the merchant categories, and the IPs, but also those sequences. What a given card, device, merchant, BIN, or customer has been doing in the last few minutes or the last k transactions. It’s actually that history that turns out to be a huge unlock.

From those inputs, the model produces an output, which is just a reusable embedding. It’s a dense vector for each payment or short sequence. We can layer lightweight classifiers on top for real-time detection. We also have a slower, higher-latency variant that generates explanations through a text decoder. I think we’ll get to a stage where that can be real-time-ish as well, but we’re not there just yet.

Cool. Okay, there are already a number of interesting things there. In terms of scale, the blog post that introduced the payments foundation model said tens of billions of transactions, and it also indicated hundreds of subtle signals. Could you go into a couple of examples of the long tail of these signals that illustrate just how much information the model is ultimately able to take in—information that might be hard for a person to represent?

We can classically handle about 7 items in working memory, right? So what are we missing with our feeble human working memories that the model is able to take in?

From there, I’m interested in the overall scale of data. It sounds like it’s getting into the trillions of tokens, which would be not at the high end of text foundation models, but not too far off—maybe 1 order of magnitude less. I wanted to sanity-check my estimates with you on that.

Yeah, your math is legit. I’ll answer the second question first and the first question second. The data is very different from the free-form text that you’d use to train a model to write like Shakespeare, right? Payments data is highly structured and dense, so we actually build a custom tokenizer that compresses the numeric and categorical signals very efficiently.

The dataset is big, but it’s also packed with purpose-built information that’s incredibly rich for the set of tasks that we care about in our context. You asked what’s hard for a human to eyeball. I think the thing that’s hardest for a human to eyeball is looking across those dimensions—not within any one payment, but within any combinatorial sequence.

If you think about it, what you need to look at in order to figure out if a fraud attack is happening or how to get a payment authenticated has very little to do with that particular transaction and everything to do with where that transaction sits vis-à-vis the transactions that have come around it. You’re not looking at a single screen. You’re looking at a clip of a movie, but there are a lot of different clips that include that screen that are relevant to look at.

You want to know what I was doing, what the merchant was doing, what my card was doing, and what my IP was doing. That’s really where the model sings, making it efficient not just to look at the individual payment. That’s hard to do at the scale of 50,000 a minute, but a human could, I suppose, if you had enough humans.

It’s really about the sequences that make the problem intractable for humans, but also very hard for traditional ML approaches, where you have to hand-engineer features to capture what’s happening in each of a range of different sequences. In our context, the foundation model pays off dramatically because it expands 3 things.

One is how much data we can learn from. We can learn from literally all of Stripe’s history, not just a task-specific subset of history. It changes how richly we can learn, because these dense embeddings capture very subtle interactions that manual feature lists, like count features, wouldn’t capture.

The third, which is more about how we work internally, is that it changes how efficiently we can build. Once you have a shared embedding, spinning up a new model becomes a weekend project, not a quarter project. That means we can open the aperture for the types of ML-powered solutions we can build.

Yeah, cool. I really like the idea of multiple clips. I take it that this basically reflects the reality that there are obviously multiple parties to any transaction. I’m inferring that the pattern of behavior of each of those different parties is really where the strong signal is.

It’s not that, if you looked at this particular transaction in isolation, you might not get much. But when you combine recent history for all of the parties to a single transaction, the combination of those recent histories is really what tells you what you need to know. Do I have that right?

There’s nothing about me using my card in Boston that tells you it’s fraudulent. But if I just use my card on my device at my home IP, which is, by the way, in Palo Alto, not in Boston, and I tend to be buying things that are totally different from what you suddenly see someone doing in Boston, that’s a red flag that it’s actually fraudulent use of my card.

Conversely, if you see someone rotating across a small number of cards to buy thousands of accounts from a given AI provider, maybe the card is truly theirs, but you’re almost certainly going to see some sort of reseller refund abuse happening, where they’re trying to steal your compute. It becomes more complicated when you add more entities, like the merchant, where there can actually be internal collusion happening.

You’re exactly right: it’s not about how any one entity acts in isolation. An entity is an individual, a card, or a merchant, and that’s the node, right? The edges are the transactions, and it’s how much sense those edges make in relation to each other and in relation to the combination of edges that we’ve seen in the past.

Does that graph extend outward? I could imagine that web extending easily farther, or you could imagine including the rendered judgment on previous transactions. For example, if I’m trying to buy something from you and the model is looking for the signal of fraud, you could also say, “Okay, all these transactions that you’ve recently done as a seller—maybe you just have the determination of whether they were fraud or not fraud.”

You could even look at who all those buyers are. How far out does this sort of path through the graph have to go to get you what you need to know? What is the shape of the curve in terms of scale versus diminishing returns?

Yeah, totally. I talked about the scale of the Stripe network, right? It’s a $1.4 trillion network, but it’s not just a big network. It’s also a very dense network. For example, 92% of cards that a merchant sees for the first time, Stripe has seen before on another merchant.

In those cases, you don’t have to do very many hops, although you do want to validate that nothing’s changed about the card or how the card’s being used in the time since. But fraud and conversion are tail events in some sense, too, right? If you can get 1% more conversion or 1% or 2% less fraud, that goes a long way.

You get really far from the dense network, but you also want to be able to traverse wide for more novel traffic that you see.

So, architecturally, this sort of reminds me a little bit of some of the stuff that Meta has done with their joint-embedding video models. I'm not sure if that's the right intuition for me to have, but it does seem like there's a clear difference here where you're not trying to predict the next token, right? It seems like it would be more of a dedicated—so it's not like an autoregressive-type model, right? It seems like it would be more of a dedicated-encoder, masked-type situation, where you could imagine doing a training setup where you mask out things randomly and have the model learn to fill in details.

Yeah, exactly. So our V1 did use a sort of BERT-style masked-modeling setup that you're talking about, and then we paired that with a second stage, which is explicit similarity fine-tuning. Most of the heavy lifting there was, okay, let's curate the right sequences to learn from, build the right encodings, and do post-training with that kind of similarity objective so that near neighbors in this payment space cluster together and the oddballs separate, and you can start to reason about those oddball clusters.

And again, the big unlock here was modeling short histories, right? So what a card or device or merchant BIN is doing over some number of minutes or the last K transactions, rather than the isolated payment. Now, in what we call V1.5, we're actually moving toward encoder-decoder setups and compressed-memory sequences—so, a few vectors together—which makes it actually easier to catch subtle abuse in real time because you're not averaging across noise. You're distilling the full story into these compact representations.

And so, yeah, the mental model is V1 masked modeling plus similarity training; V1.5 is compression-first with a tight sequence embedding. Then we can put lightweight, task-specific heads on top, which are for the charge-path use cases. If you think about the charge path, you've got to get the job done in tens of milliseconds at most, and so those lightweight, task-specific heads are important for latency and speed.

Yeah. Can you say how big the model is? I mean, 10 milliseconds doesn't allow it to be that big, I would assume, although they don't have to do a lot of steps in a forward pass.

Off the cuff, but the task-specific heads on top are small. I think when you reason about it, all you have to be able to do, actually, is place the new charges and sequences as they come through in this dense embedding space, which is a much easier problem than, obviously, the upfront training. And it's also just 1 forward pass of the model, right, as opposed to having to generate a whole sequence. So that 1-pass nature of it definitely helps with the latency as well.

Yeah, that's really interesting. It also reminds me of one of the first vision-language models that I studied deeply, the BLIP family of models. I remember that they had really amazing success with a frozen language model and a frozen vision model, and then just trained a few-million-parameter connector between the 2 to bridge from 1 latent space to the other. Of course, we've gone way past that now in vision-language, but this was an early-2023 thing, and you were able to get really quite good captions out of that setup, even though neither of the foundation models that were used had anticipated that use case.

So it sounds like you've—

It's been a while, but that's an interesting analog.

So, it sounds like you've kind of created a similar situation where people internally at Stripe can say, “Okay, I have a new use-case idea for this. I can train something really small.” You mentioned it can be like a weekend project instead of a multimonth project. And if I understand correctly, the idea is that because you've got the foundation work done, you can train a few-million-parameter connector, classifier, head—whatever you want to call it—very quickly. That step becomes a rapid-iteration step.

Yeah, exactly. And actually, it can be even simpler. The embeddings themselves—where most people start, actually, most modelers start—is just taking the embeddings themselves, which are stored in Shepherd, our feature-engineering platform, and literally just adding them as a feature to existing models, whatever those existing models are, and saying, “Is there added signal from these embeddings?”

And I would say you get some false negatives there. Obviously, just shoving the raw embedding into some number of SOTA models that have been iterated on over the last 6 years isn't going to produce uplift. But in other cases where it's a lower-priority model that's only in its V1 state, you actually do get something straight out of the gate, and you can start to reason about how much signal you get from understanding the payment better, how much signal you get from understanding the customer better, and how much signal you get from understanding the merchant better for each of these use cases. And that's also motivated which applications folks have leaned in harder on.

Yeah, that's really interesting. So, just to make sure I understand that correctly, Stripe's been around for a number of years. There have been many types of problems that you've brought machine learning to over time, typically with a more classical feature-engineering type of approach.

Yeah.

Hundreds of production models, right? Like point solutions.

And so now the foundation-model embeddings can become just tacked on as additional features. Rerun that training and immediately backtest against your set, and then you're like, “Okay, cool, we just made this better kind of for free because we were able to get additional signal.” That's really interesting.

I mean, our standout application wasn't that, right? It was card testing, where we literally had a whole new approach to card testing with the foundation model. Card testing is fraudsters trying hundreds of tiny authorizations, iterating across stolen cards, or literally just doing raw enumeration—trying a bunch of cards—and they bury those attempts inside floods of legitimate traffic.

A big retailer can have hundreds of thousands of charges come through, and then there are a couple hundred or maybe 1,000 fraudster charges of 30¢ or 50¢ peppered in. Classic models couldn't really pick up those kinds of needles in the haystack.

And so our first application of the foundation model was to treat those sequences again like frames in a movie, right? Suddenly, those 200 nearly identical requests—same low-entropy user agent, rotating across proxies, coming in about every 40 seconds—light up as an island in the embedding space and get blocked.

The impact of that was huge. Our detection rate of card testing at large merchants went from 59%, which is not bad but not great, to 97% from that change. But then, as we started reasoning about where else it could be useful, exposing the embeddings and letting them be added as features to these traditional single-task models was the next step. That was never intended to be the final state, but it's a way to get signal on where there's incremental value or incremental signal from these embeddings that requires very little lift.

Yeah. Fascinating. That's a very modular approach to AI deployment, and I can't recall hearing of any organization that has had a similarly modular structure. Maybe Meta comes to mind as another one that might have a sort of user model that could then be bridged over to any other space or problem that you might want to apply it to. But this is a fairly uncommon setup, I would say.

I don't know exactly what happened, how it went, or how it worked, but I know the former leader. I know there was a Cortex org at Twitter that was basically doing horizontal models. Again, I don't know exactly how it worked or the architecture.

We've been talking about it in the context of payments, but we've actually done the same thing over the last year in the merchant space. We have what's called the Merchant Intelligence team, but it basically has this MI service. It can go out and find anything on the web about a merchant and generate embeddings, and those merchant embeddings are also used as features downstream—for example, in merchant risk models. It's a service where the model owner can ask the Merchant Intelligence agent to come up with a more custom embedding or a more custom insight. Maybe you want to know what payment methods the merchant offers or whether they have anything that's counterfeit, and that's actually been another horizontal layer that's provided a ton of leverage for Stripe.

Historically, you had a lot of use cases. You want to know things about the merchant to understand supportability, like whether they meet the requirements of the current networks, issuers, and banks. You want to know whether or not they're fraudulent. You want to know whether they've had an account takeover. You want to know if they're creditworthy. You want to know whether or not we should give them Stripe Capital, like a loan. And you want to figure out whether you should be going to market with them. There are all sorts of things you want to know about a merchant.

Historically, when LLMs hit the scene, teams at Stripe were out building their own custom versions of this. But what we realized is there's actually just one service now that does that much more efficiently than everyone rolling their own.

The Bitter Lesson strikes again. I got a lot of different directions I want to go, but where does ground truth come from on some of these questions, and how long does that take? Because I imagine, especially in a fraud detection situation, fraudsters—I always assume—are going to be some of the most clever people in the world, diabolically so. Nevertheless, you've got to respect the smarts of some of these folks, right? So I assume that they're very savvy to real-world events.

You mentioned, I think, in the conversation with Patrick that somebody might have a flash sale and that sort of spike. Obviously, you don't want to turn them off when they're having a flash sale, because that's a horrible experience and a loss of business for the company running the flash sale. But at the same time, that's potentially a really good target for a card tester to come in and try to do whatever it is they want to do.

You're in a kind of eternal arms race between fraud and fraud detection. And then what I know—what little I know from my experience as a consumer and as a business owner—is that actually closing the whole loop and getting to the point where whether this was fraudulent or not has been set in stone, that's a long process, right?

Well, it's a long process if you even get to a definitive answer. With something like card testing, the first thing we did with the foundation model was deploy it internally for card testing. We passed those labels to internal expert humans, had them validate the labels, and then fed the validated labels into our traditional ML model for card testing. Suddenly, our traditional ML model for card testing—not the foundation model—started doing way better because finally it had a more comprehensive source of truth for the labels. So that was actually the first version, although I hadn't revealed that fun fact before.

Yes, attackers iterate, and so do their models. Our job is just to iterate faster, and we are. I'll talk about some of the ways we get around the late-arriving labels or the missing labels altogether.

But just to give you a sense of how we're comparing to the fraudsters, industry-wide e-commerce fraud is up—I think it's up 15% year over year. But the dispute rate for businesses running on Stripe is down 17% year over year. And that's because we, in a bunch of different ways—and I can give a couple of my favorite recent examples—are just consistently shortening the loop between a new tactic showing up and defenses adapting. That sort of loop-shortening is happening in production and, in some cases, in real time.

An example that our users are getting a ton of value from, which we recently released, is dynamic risk thresholds. Basically, Radar is on, they've got their threshold score, and it blocks stuff above the threshold. But when an attack starts, Radar learns that an attack has started and tightens the defenses. It kind of throttles, and that allows revenues to flow freely when you're not under attack, but then we're much more aggressively blocking when an attack arises. Again, an attack is almost never a single event; it's almost always a true cluster. In that case, the model is learning the policy of how to act. It's not learning that policy online just yet, but it's learning the policy of how to act.

Another powerful tool—and I think in payments, it's easy to think I put in my credit card and then just an objective decision is made to block me or not, but that's not actually true—is what we call a soft block. Adaptive 3DS is an example here. It applies that 3DS authentication. If you're in the U.S., most of the time you don't get 3DS.

Can you tell me what that is? I don't feel like you might have defined it in the complex systems, but if so, I could use a real explanation.

Yeah. You have a second factor. It's sort of like a two-factor auth-esque experience where you're verifying to the credit card network or the credit card issuer that it is, in fact, you. This is very common in Europe and very uncommon outside of Europe.

By the way, when it does happen, it often creates unnecessary friction. So part of what we do at Stripe is figure out when we need to authenticate and when we don't. But with adaptive 3DS, we are pushing for authentication selectively in cases where we have a sense that the charge may not be good.

Instead of just having this binary decision—block or don't block—you have this other arm you can go down, which is to hit them with 3DS. What ends up happening is the good guys get through the 3DS because they're excited to buy the thing and they're legitimate users, and the bad guys do not.

A lot of AI companies are using this. AI companies being hit with fraud is extra painful because their marginal costs are high, unlike SaaS companies, which care a lot less. Early adopters of adaptive 3DS were ElevenLabs and Character AI, and they're able to dramatically cut down fraudulent disputes without any effect on conversion because 3DS isn't super heavyweight for the end user.

In fact, U.S. checkout users saw a 30% average drop in fraud. They just turned this on with a single click in the dashboard, and then it lets us basically learn the policy of who is worth 3DS-ing to balance conversion and fraud and maximize their profits.

One way I like to frame some of these conversations is just in terms of practical lessons that people can apply in their own AI pursuits. One takeaway there is to add middle-ground outcomes to your classifiers so that they're not binary, but try to find that sort of middle space, if one exists, where something other than the model itself can step in to help resolve the most challenging cases.

It’s almost like Claude, you know, these days can sometimes end a conversation, right? If it has to ask for that additional information, you can get it from your users in a low-cost way. Don’t constrain yourself to being a modeler; be a product thinker and go figure out how to get that information, right? The model’s really good at deciding, and that’s not brute force. You don’t require that additional information from everybody; let the model decide where it needs more information and where it doesn’t.

Yeah. On the adaptive threshold concept, this suggests a state—basically, a sort of world state—that is maybe being fed into the model. I assume it’s not like the model itself is calculating that on the fly. This would be more like a global variable that the model would receive, or?

No. It’s actually like, hey, this merchant is starting to see clusters of scores creep up. Isn’t that interesting? When we look at the subset of transactions that have those higher scores, maybe they’re still below the block threshold, but they’re looking elevated. Is there anything about those that looks like it’s something collusive or coming from a small number of attackers, rotating across IPs, or coming from a geography that they haven’t seen before? Once we get the signal that, hmm, it looks like there’s a slice that’s an attack, you can actually start to lower the threshold for that subset, for what it takes to block.

But is that all happening with the same short histories that you described previously, or is there a longer history coming in at some point to inform that kind of decision? It just sounds like there’s a longer history at some point, but maybe not. I guess the short history could be enough.

There’s a longer history, but less at the individual transaction level. It’s basically detecting anomalies in slices of traffic, right? This geo, these bins, this cart size—something anomalous is happening here. That anomalous thing has elevated risk scores. It reads a bit like an attack.

Rules are really good in a lot of ways, right? Maybe another general lesson is that rules are good, but they’re also blunt. Figure out where you can blend rules with models.

You’d asked earlier when disputes actually come in. Disputes are super-lagged. They can take days; they can take months, right? I’m the cardholder. I have to see my bill, notice I didn’t buy the thing, and tell my bank. My bank has to go and file with the network. Those labels for sure arrive late, but we don’t wait. We use proxy signals. Those weak labels show up way earlier, all the way to real-time issuer feedback.

Real-time issuer feedback would be like a CVC mismatch, right? The CVC code—the little 3- or 4-digit credit card code—doesn’t match, or the ZIP code doesn’t match. It’d be easy to write a blunt rule that said, “If the CVC doesn’t match or if the ZIP code doesn’t match, block it.” But you’d be blocking a bunch of good revenue because who doesn’t sometimes fat-finger their CVC or ZIP code in a hurry, on their phone, or whatever?

We have these risk-based Radar rules, which are like: okay, take the model score, combine it with the issuer’s real-time responses, and make a decision based on that intersection. If it’s looking marginally risky and the CVC is wrong, for sure block. But if it’s a pretty known-good user and they fat-fingered a thing, let them through.

I think that blend of rules and models is important. It’s easy for modelers to put their nose up at rules, and it’s easy for rulemakers to put their nose up at models that aren’t fully explainable. But in plenty of contexts, blending the two actually does far better.

So, you actually do let transactions go with the wrong 3 digits. What was that called? CVC?

Yeah,

Nathan, I know you’re good. You’ve bought from this person before. Maybe you even use the same credit card. You’re coming from a legitimate IP, and I feel good about you in a lot of ways. The issuer comes back and says, “Hey, there’s a mismatch,” and we say, “Hey, let it through.”

By the way, once we let it through, we also have to get the issuer to let it through. We actually have data sharing with the issuers where we pass them our risk scores so that they can also understand why we passed it through. That motivates them to also pass it through when they see our signals. So it’s kind of a 2-step.

Very interesting. Let’s go back to how you are tightening the iteration loop. Again, I think this is something that basically everybody who’s developing AI products could stand to get better at. What have you guys found to be effective needle-movers in shortening your cycle time?

This isn’t one for us where there’s some magical reinforcement learning that we need to be implementing online for every single use case. I think it’s actually been quite context-dependent for us. The things that matter are having enough labels, having good labels, and having those labels fast enough. You can get pretty creative about what the label is. We talked about some examples. We also talked about human-generated labels.

Another thing that we’ve been leaning into is LLMs as a judge, especially for contexts where there actually is no source of truth. A simple example: we’ve been talking a bunch about fraudulent disputes, but there are a lot of suspicious payments that never result in a fraudulent dispute, right? Maybe the person starts a free trial and then cancels, asks for a refund, or just spins up a bot account but never even gets to the checkout page.

That type of friendly fraud is actually really costly to businesses, and it’s almost half of businesses. I think 47% of businesses say friendly fraud—which is a total misnomer because it’s not friendly—hurts their business more than stolen card credentials, or what most people think of as fraud. That cost of friendly fraud is particularly true for AI companies. There are a lot of AI companies running on Stripe. It’s very different from SaaS. Again, they have inference costs, they have compute costs, and therefore they have very high marginal costs. When someone is engaging in free-trial abuse, reseller abuse, or refund abuse, it’s super expensive to their unit economics.

Anyway, built on the foundation model, we now have these suspicious payments that we identify. These are fraudulent-ish things, but not in the traditional going-to-result-in-a-fraudulent-dispute sense. When we pass those over, for example, to AI companies, we want to be able to describe to them why they’re flagged as suspicious. It might be that they have an enumerated email, or are cycling through a small number of IP addresses, or whatever.

Those labels, those explainers, are generated by the foundation model. But then the question, of course, is: how do you know if they’re right? We have this LLM as a judge that sits on top. It looks at every transaction-label combination and asks, “Given everything you know about this transaction and everything you know about the cluster to which it belongs, how do you feel about the quality of the label?”

What ends up happening is that there’s a large share of labels that are good enough, trustworthy enough, that we pass them over to an AI company to make a decision on. There’s a small number that are too noisy, and we’re like, “Okay, we have to go work a little bit to make that label stronger.”

I call out that example because there’s no source of truth. You and I could manually go through, I guess, but at the transaction level we’re not going to. It’s been really helpful to have LLMs as a judge where there’s no clear north star.

Yeah, that’s fascinating. But I’m still confused about one thing—which is, well, probably confused about a lot of things, but the thing I’m focused on and confused about right now is this: when I try to advise people on AI broadly, or give people the lay of the land, one of the things I tell people is that AIs are not very adversarially robust.

They’re really good these days at the happy path. If you dial in the performance and control the inputs, in many, many cases you can get to superhuman performance on routine tasks. However, if you don’t control the inputs and you’re exposing your AI system to the world, you do have to be mindful about the fact that these systems are not adversarially robust. People can usually find some weakness, right?

That’s even been true with superhuman Go-playing AIs. We did an episode once on superhuman Go-playing AIs that were beaten by really simple attacks that no human would ever fall for, but which the AI—even though it was superhuman when playing Go in the normal way against other high-quality Go players—was totally blind to. This was a certain class of attack found through adversarial optimization.

It seems like you would be in this environment where you’ve got it on hard mode everywhere, right? Anybody can come test the system from any position. You can’t really deny people the ability to try a payment. They can gray-box you, right? They can test from a bunch of different angles and try to see what’s going to get through and what’s not going to get through.

And presumably, there’s always some vulnerability that you’re not aware of that they can systematically attack or try to find through these sorts of attacks. My guess would be that the only way to really deal with that is to just constantly be identifying and iterating. But that still sounds hard. Despite everything you’ve told me, it still sounds hard to be as responsive as you would need to be, especially given that the actual ground truth is so lagging.

So how do we not—maybe we do—how do we not just bleed a ton of money in one incident after another as attackers figure out that there’s some gap and then jam as much as they can to exploit it for a while until it’s closed? How does that not end up being a huge problem?

Yeah. A couple of thoughts. One is that we expose capabilities through products and APIs to our users, not through raw weights. So, for sure, anybody can try a payment and test to see if they can work around it, but just to be clear, we’re not actually exposing the model for them to have an attack surface against. I think the products and the APIs better meet the user needs, and they also narrow the potential attack surface.

As clarification one, I think it’s interesting to think: What’s the relevant alternative? What is a fraudster’s job? A fraudster’s job is to find loopholes and exploit the system. That’s what they make their money on. The relevant alternative isn’t perfectly airtight; the relevant alternative is baseline approaches.

When you start to think about foundation models, or LLMs, the payments foundation model, for example, is a lot more nuanced in the type of information that it’s using to make a decision versus, say, an early transaction fraud model that’s using last-7-day counters. The fraudster figures out that as long as they’re 8 days out, they’re safe: “I’m just going to do everything on day 8, hit them hard, and then go 7 days back.” So, to some extent, I think traditional ML is easier to get around, whereas the foundation model is more comprehensive.

But the other thing that we have certainly long done and continue to do is a layered approach. It isn’t just a single set of defenses. There’s a set of model defenses, a set of rule-based defenses, the soft blocks I mentioned, and the user’s own defense set, which can also vary all the way to how they treat you at sign-up or how they block bots at sign-up. So fortunately for us, unfortunately for the fraudsters, they’re not fighting against one model. They’re fighting against a whole system that is—I guess, until I said it—opaque to them.

Yeah. I want to ask you about any other big use cases. You mentioned fraud and disputes. There are some interesting talk-to-your-data product experiences at Stripe. What stands out to you as the most interesting applications—not even necessarily from what moved the most money, but what would be most interesting to the AI engineers in the audience in terms of interesting implementation details, surprises, or quirky stuff that you’ve learned along the way?

Yeah. We’ve talked a lot about transaction-level understanding. If you think about the path there in terms of modality, it’s mostly payments plus text. You have these structured payment signals and then language; using contrastive learning, you align the two, and you’ve got the text decoder and whatever else. But payments plus text is only the start, right?

The system is actually designed so that new modalities are just considered tools that the router on top can invoke. If you wanted to add another encoder, maybe for financial time series—which I’m very interested in, but I don’t have anything yet that I could share—or for images, it doesn’t require a whole rewriting of the system. It’s just a modular expansion.

I think the multimodality roadmap is starting to really shine at the merchant level. Actually, yesterday I was testing 2 lightweight agents. Neither of these is in production, so, full disclosure, the team has them running in shadow. One crawls merchant sites to assess fraud, and it’s relentless—incredibly relentless. The other spots counterfeit products, and it does so literally orders of magnitude better than trained human reviewers that we have at Stripe doing the same thing.

It’ll find that there’s a print shop with thousands of items, and the agent will patiently zero in on the 1 Spider-Gwen sticker—that was an example I was looking at yesterday—with no sign of official licensing. Uh-oh. But then it also knows that this other site—the Canada Goose that’s marked as “with tags”—is secondhand, so it’s actually fair game.

I think that kind of multimodal roadmap is interesting, not for multimodality in and of itself, not for the technology in and of itself, but for where it’s going to unlock real value.

Cool. On the talk-to-your-data thing in particular, that’s something that I think a lot of people have tried to do for themselves, or they’ve tried to use a product to do it. It strikes me that where most people have gotten stuck there is: I was able to get GPT-whatever or Claude-whatever to be pretty good, but it still made some mistakes, and I didn’t really feel like I could confidently give somebody who wasn’t a proper data analyst this tool and be confident that they would get good insights out of it.

So you guys have that problem at maybe the biggest scale in the world. How did you think about what is the right threshold of accuracy for a talk-to-your-data model? I assume you didn’t achieve 100% accuracy on this sort of thing, but what was the threshold that you felt you had to get to, and what was needed to keep dialing in until you actually got over that threshold to where you could deploy?

One of the reasons that this sort of talk-to-your-data was interesting to us in Stripe’s context is that a lot of what a business wants to know is captured in Stripe data: who’s selling what, for how much, to whom; who’s retaining and churning their subscriptions, et cetera. So that’s thing 1.

Then thing 2 is that the data is actually very well structured because it has to be, right? It’s generated from the transactions flowing through Stripe, which are incredibly robust and well documented, and the schemas downstream of that make sense and are well documented as well.

A lot of this talk-to-your-data stuff has the garbage-in, garbage-out problem: my tables aren’t well-labeled, my fields aren’t well-labeled, and maybe the underlying data actually isn’t deduped. So you can’t really tell if the issue was the text-to-SQL or if it was actually that the underlying data was bad and/or the data structure was not understandable. We were kind of able to leapfrog that, which is great.

But still, LLMs—I think you’re referring to our Sigma Assistant—do make mistakes. If we have reasonable confidence, we’ll provide an answer. I don’t know if you’ve ever used it, but we overlay a natural-language explanation of what we’re doing on top.

Say you ask, “How did Black Friday this year compare to Black Friday the last 2 years?” It’ll say, “Okay, these are the dates we used for Black Friday. These are the timestamps we used, because, by the way, most things on Stripe happen in UTC, and many people aren’t reasoning about their business only in UTC. We looked at Black Friday over the last 3 years. Here’s how we computed the percentage growth.”

You’re like, “That’s boring. Doesn’t everyone compute the percentage growth the same way?” That actually allows someone who’s not a data analyst to build comfort in the output versus either YOLOing it—just taking it and running with it—or throwing their hands up and saying, “I can’t trust anything because I don’t know what’s happening under the hood. You just wrote a SQL query for me, but I have no idea how to interpret it.”

When I think about talk-to-your-data, it’s: Is your data interesting to talk to? If yes, make sure it’s well structured and well documented, and if it’s not, invest in that before you invest in the natural-language interface on top. Then just make sure the LLM is explaining what it’s doing, which they’re of course very good at doing now. That allows you to open the aperture a bit in terms of less certain questions you’re willing to answer, because anyone can read the natural language and make a call on whether or not that was the right approach.

For folks who want to do a double-click on the process of getting the data into shape, the episode with the CEO of Illumex was really good on that. Just for what it’s worth, they’ve built basically canonical structures of enterprises across a bunch of different categories—for example, a drug company. They’ve built out a vast representation of data that, in their studied opinion, represents the canonical drug company.

Then, when an actual drug company comes to them, they do this painstaking process of mapping all of its actual data, with all of its idiosyncrasies, onto the canonical version that they’ve made work well. That mapping becomes the cleanup process that gets them the reliability that customers ultimately want.

Pretty interesting.

Now, sustainability.

Yeah.

Yeah. Please.

Well, I was just going to say there’s also an interesting feedback loop here with users, right? If you’re a usage-based billing company, the types of metrics you want to know to reason about your business or to share with your investors are generally very similar to the types of questions that all the other usage-based billing AI startups also want to know.

And so that means that we can really make great the subset of questions that matter in a given domain. But also, forget the natural-language-to-SQL interface, or “talk to your data”—we can just push those commonly asked questions onto the dashboard and even benchmark you.

We have smart benchmarking now—benchmark you on those metrics versus a peer group. And by the way, that smart benchmarking is one of the applications of the Merchant Intelligence service, which is figuring out which websites are like this website in terms of which would be good comps because they have similar user bases and are at a similar stage of their development.

Yeah, cool. There’s a good pattern there as well, for sure. I’ve been thinking about that in the context of agents lately. There’s the choose-your-own-adventure agent, where you give it a bunch of tools—here are some MCPs, whatever—have at it.

And then there’s what’s sometimes better described as a workflow, maybe, with a couple of forking decision points that people also call agents in many cases. I’m starting to see the emerging pattern be: have that choose-your-own-adventure agent sort of at the top level of user interaction, but then, in terms of the things that it’s choosing, make those actually pretty detailed workflows in a lot of cases.

You know that as long as it makes the right choice at a high level, the process that’s going to be kicked off is one that you’ve really deeply understood, dialed in for accuracy, and confirmed for yourself is going to work reliably. So I think that’s another—you’re kind of talking about a push model instead of a pull, but nevertheless, there’s a sort of isomorphism, I think, between those structures.

Explainability is obviously huge. One thing I was interested in asking is, are you doing any mechanistic interpretability? Are there sparse-autoencoder-type things now happening on the foundation model so that you can learn in a semantic way what new features the thing is learning?

Yeah. Not literally. We’re not dissecting individual neurons in the way some research groups are. I think our focus is really on making the outputs self-explaining in a way that we and our users—where it’s user-facing—can actually trust. Mechanistic interpretability is really important when you’re releasing the full open-ended model into the wild.

In our case, we control both the application and the environment, and so our priority is that really practical explainability that’s tailored to the payments application. When the foundation model flags a transaction, it doesn’t just say, “High risk.” It says, “Gibberish email, enumerated name pattern, and device concentration.” That’s actually the layer of explanation that lets the fraud analyst, or even another system like a follow-on agent, act confidently.

And then, as we were talking about a little bit ago, in many of those cases, there’s actually no ground truth for that explainer. That comes up more and more as we expand to new domains. We’re actually detecting fraud further up your customer funnel, all the way to when someone’s creating an account with you, well before they’re entering credit card details.

That’s where things like the LLM-as-a-judge framework are really helpful. It will look at that, the cluster of similar events, and the tag definitions, and then output how confident the LLM is—basically judging how confident it is that the cluster really matches the label.

No, we are not peering in neuron by neuron, but we are focused on interpretability at the output level, and that’s really valuable for us. For example, if you’re in your dashboard and you’re seeing a bunch of suspicious users, you want to know exactly why we’ve flagged them as suspicious so you can decide how to action. In our setting, that’s really what matters most.

Gotcha. Okay. You mentioned usage-based billing, and this just led me to a very practical question around how you would recommend people build on top of Stripe today. 10 years ago or so, when I first became a Stripe customer, it was already a respected company, but not such a foundational part of the economy as it’s become.

We might want to switch off of this one day, or we might—who knows?—have our own database of all the transactions and all that kind of stuff. Stripe, of course, had their view of it, but we’d maintain our view. That was a lot of work then. With usage-based billing, it sounds like an even more challenging project now, especially for your proverbial couple of people who are doing a hackathon and want to get something started.

Yeah. The alternative I have in mind, which I wonder if you ultimately recommend, is: could I just leave all of that to Stripe and basically make nothing but API calls, trust Stripe to be the real-time ground truth across the board, and not even have a sort of financial side to my database, but just purely do real-time API calls?

Totally. Don’t even have it. Stripe’s APIs run at six nines of uptime, right? So they’re safe to use as your system of record for very critical flows. Our usage-based billing APIs process 100,000 events per second, and they’ve got all the built-in monitoring, alerting, and invoicing.

The alternative is also pretty painful, right? Building your own mirror of Stripe’s data is pretty complex. You have to sync across all the events. You have to build your own monitoring systems. You have to keep everything reconciled.

And especially if we’re talking about a startup, that’s just a lot of work that doesn’t create any kind of differentiated value, right? A lot of these companies taking off have 5, 10, 20 employees. They shouldn’t be spending an ounce of that limited capacity on this stuff.

On the flip side, if you treat Stripe as your source of truth, you get real-time signals that you can actually act on in the Stripe ecosystem, right? The billing threshold has been exceeded, or whatever, without having to have this whole parallel system. And we talked about the Sigma system earlier, but with products like Sigma and Stripe Data Pipeline, you can still run all your analytics and all your reporting without doing the job of building your own warehouse.

You might be wondering about the downsides. Historically, the biggest downside of not mirroring—of just leaning into Stripe—was, okay, but what about when I want to join basically Stripe data to my own business objects? Now you actually can. You can extend Stripe’s objects with metadata.

A lot of users will attach their own order ID or shipment ID to an invoice, and for most companies that closes most of the gap. Now, it’s different if you’re a large enterprise and you’ve got a whole bunch of other follow-on systems that are off-Stripe and data sources that are off-Stripe. But for most startups, it’s both simpler and just a lot safer to let Stripe be the system of record.

Yeah, cool. I imagine some companies have gotten pretty big in revenue terms over the last however many months while still doing just that. I don’t know if you would want to highlight any by name or if that’s too secret, but when I see the curves from folks like Lovable, Bolt, and Replit recently—obviously things like Cursor—and the headcounts that they have, I bet a lot of them are probably doing exactly that and just kind of trusting Stripe, which six nines gives you pretty good reason to do.

Yeah, and that’s just for the system of record, right? Lovable is a great example. They did 100 million in ARR in their first 8 months, and their stack is basically a case study in going all-in on Stripe.

So they incorporated the business before they monetized. They incorporated the business with Stripe Atlas. From the very beginning, they used our Optimized Checkout Suite. The front-end, customer-facing service is our Optimized Checkout Suite, which allowed them to localize payments in over 100 countries and get something like 150 payment methods out of the box.

They leaned on Billing for subscriptions, so they didn’t build their own billing system or have to contract with another third party. They leaned on Link, which is our one-click consumer checkout for fast checkout. By the way, nerds love to buy from nerds, so our concentration of AI buyers on Link is very high. They leaned on Radar for fraud prevention and Sigma for analytics.

And so, really, Stripe took care of the financial plumbing, so Lovable was just really focused, with that small team, on product and growth, which of course they nailed. There are smaller ones, right? Retell AI. Have you used them? They’re like

Agents. Yeah.

Yeah, for customer support. And so they launched last year. I think they have over 10 million in ARR in their first year. I mentioned Link concentration.

Link actually powers 38% of their payments. So, 38% of their payments run through our consumer network, where the individual has an identity and their payment methods are saved on file. It’s literally a 1-click checkout for them. They use us for Smart Retries, so when a recurring bill fails, we retry it at the optimal time, which allows them to recover about 60% of their failed charges.

They use us for Stripe Tax, which keeps them compliant in 100 countries. It’s just a great example of how these AI companies—with very lean teams, growing fast, and going global—are really scaling up to look like a much bigger company with Stripe behind them.

I’ve heard you talk a couple of times. I know we don’t have too much more time, so just to hit on a couple of last topics: I’ve heard you talk a couple of times about the time you spend getting new clothes for your kids. That’s mostly something, in all honesty, my wife does in our home.

Lucky.

Yes. I would flatter myself that I do my share in other ways, but she’s definitely better suited to pick out what will make the kids look cute.

What’s interesting? Folks who listen to this podcast will sort of know the basics: Perplexity has a shopping thing and whatever, and we know what MCPs are. Are there any recent developments? Is this really happening, or is it still, from what you’ve seen, kind of the “wouldn’t it be cool if one day this were a real” sort of phase of agentic commerce?

It’s kind of both, right? It’s definitely still early. There’s still a ton we’re sorting out about how this is actually going to work and how quickly it’s going to take off, but we’re seeing meaningful traction.

You mentioned Perplexity, right? You can discover and book hotels directly inside the app. But it’s not just the big guys like Perplexity. Hipcamp is a little site that uses agents with virtual cards to book campsites off-platform. I’m from Montana. It’s impossible to get into Yellowstone National Park. I hate using their website, although I love the park and value that they’re not spending a ton investing in tech, but Hipcamp is actually solving that.

I think it’s easy, when people think about agentic commerce, to think about consumer commerce—buying kids’ clothes—but on the developer side, we’re seeing the same trend. Developers now, in Cursor, can buy Vercel services right inside their editor. That’s a brand-new channel. It’s really embedded commerce directly in the workflow, and Stripe powers those transactions too.

We’re not totally new to this. It was last November when we launched our agent toolkit, but we still have thousands of downloads each week. Looking at the pace of adoption and looking at who’s testing, I think agentic commerce will be a major channel far sooner than most people think.

With that embedded stuff, like Vercel in Cursor, it seems like that’s much more about the connective tissue: the user has an intent, and it’s a question of how it’s going to get executed, as opposed to any sort of autonomous decision-making by the agent or any sort of meaningful delegated discretion to the agent.

Have you seen anything that is really interesting in the, “I’m going to actually trust you to go figure out what to buy and execute on it,” category at this stage? Or has that still not really materialized?

I can’t name names, but this idea of a business in a box—I want to build this business, and I actually don’t know what third-party tools and services I need. I just want the business in a box and to go spin up the business—could be an interesting direction.

That’s not just the payment provider or the front-end service or the bot protection or the HR system. It’s, “Give me my whole business in a box.” I think that could be an interesting direction. Getting that right for the whole world of businesses that might be created is hard. Getting that right for a pretty focused AI wave that’s coming online isn’t a crazy thing to reason about.

I agree with you that the option set in consumer is broader, and so there’s more job to be done for the agent to select from this very broad option set. But SaaS procurement is also very inefficient. Maybe we underestimate how inefficient it is. That’s not just in the selection of vendors; that’s also in the pricing and negotiation with vendors. I don’t think it’ll be tomorrow, but I think there will be a there there.

Cool. Watching out for that. Last question, just about the future of platforms, the future of scale, and the future of market power.

I think back often to the great Anthropic deck from like 2 years ago, where the claim was made by Anthropic: “We believe that the companies that train the best models in 2025 and 2026 may have such an advantage that nobody will be able to catch them from there.” Why? Because presumably the models will help train their successor with all this data filtering, synthetic data, constitutional AI, and whatever.

Once you’ve got Claude 4 contributing to the training of Claude 5, anybody who doesn’t have Claude 4 and is still sourcing everything through Scale AI or whatever is just at a massive disadvantage. It seems like that basically applies to Stripe as well.

Is there any hope for anybody to ever compete with Stripe, given the 1.3% of global GDP flowing through the system and the massive data advantage that already exists? Or are we now sort of in a future where we just need to rely on the goodwill of others to continue to be good actors? It seems like this position is almost unassailable.

I think financial services is a big, broad space, and there are a lot of services that one can provide in that space. In the context of data, 1.3 trillion a year is a lot, right? And volumes are growing at 38% year over year. That’s a massive, growing data set.

The real advantage, I think, isn’t the raw size, though. To your comment earlier, it’s more the compounding loop. In our context, that loop is: the more data we process, the better our models get; the better our models get, the more value we deliver to businesses.

Incentives are super aligned. The more value we deliver to businesses, the more the businesses grow, which means the more transactions they run through Stripe. That loop compounds year after year.

That’s why we talked earlier about why it’s hard to make horizontal bets, but that’s why we can make horizontal bets—not just because we have scale, but because we’re in a position to harness that scale to create even better products, which then is the feedback loop.

We’re pushing this further, right? You may have heard at Sessions last year, we announced a big push for modularity. Now products like Radar, our fraud-prevention product, our billing product, or that optimized checkout suite for your users are available multi-processor. They don’t just work on Stripe transactions. They work on transactions, billing plans, or checkouts that are happening outside of Stripe too.

That actually gives us a window into an even bigger data network and further reinforces that loop. I think there’s a lot to be done in the financial infrastructure space, and I think there will be plenty of players playing important roles there. But I think we are quite differentiated in the intelligence that we can serve to users, and it’s really fun to see how that intelligence, in turn, helps them grow more profitably.

On the other end of that, do you ever think about trying to compete at the foundation-model level? This is something that obviously not many companies are really able to do. But given the depth of machine-learning experience, the unique data set that does exist, and just the reputation of the company, I sort of expect that if there was a special fundraising round to raise $10 billion to go train a Stripe 1 to try to compete with Claude 5 and GPT-whatever, the money would be there.

Do you ever think about going that hard, or how do you think about calibrating just how ambitious to be with the AI investments?

Stripe has always leaned into new technology waves. Back when we were founded, it was the platforms and marketplaces wave that got us a lot of the way here. Today, it’s the AI wave, and our mission is to build the economic infrastructure for AI.

That shows up today in 4 big bets. The first is being the best partner for AI companies: helping them monetize effectively, scale globally, and manage billing, tax, and fraud. Two-thirds of the Forbes AI 50 already run on Stripe, and we’re very focused on co-building with them, whether it’s usage-based billing or whatever the next wave is, and being the best partner.

The second is enabling agentic commerce. We only talked about it briefly, but agents are going to be buying on your behalf, and we want that to work really well for the whole ecosystem: yes, for the consumer; yes, for the seller; and yes, for the platform or commerce facilitator.

The third place we’re really focused, in the world of economic infrastructure for AI, is making Stripe native inside the AI-enabled tools that developers already use, whether that’s Vercel, Replit, Cursor, or Mistral’s Le Chat. Payments should show up right where the work is happening. That’s thing 3.

And then fourth is what we talked about today: deploying our foundation model across the network to improve fraud detection, yes, to boost authorization rates, yes, but also to expand the intelligence layer that we provide to every user.

So those are the 4 big investments. I don't know. I'm not going to say that there could never be a 5th, but today we're really hyperfocused on the economic infrastructure for AI, not being an AI model shop directly.

Gotcha. Cool. This has been excellent. I really appreciate the time and the depth. Anything we didn't touch on that you would want to leave people with, or just any concluding thoughts?

No, super fun. Thanks so much for having me.