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

Thanks for having me.

Patio 11.

You said payments infrastructure. We started as payments infrastructure. Absolutely true.

We now build broader programmable financial infrastructure. So in plain terms, we give any business. Right?

It could be a teenager who's selling a Figma template, or it could be, you know, 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. So last year, companies processed $1,400,000,000,000 through Stripe. And we'll talk about AI today.

You know, 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.

Yes. The the gory details are are covered with Patio 11, but it's the checkout UX, fraud prevention, bank routing, retries, even things like, you know, dispute paperwork so that businesses can really keep more of every hard $1, and scale up with very small teams. So we think of the tools we're building as structural growth tailwinds, and we're already seeing it in the data.

I mean, businesses on Stripe grew seven x faster, than the S and P 500 last year.

but, you know, give us more detail on that. Like, what is transaction data when you really get into the weeds of it? Yeah.

And it's a good point. I mean, there's been a ton of coverage of sort of the 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 been really 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, in disputes.

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

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

So there's kind of a syntax to a payment. Right? There's the card bins and the merchant codes and the amounts.

And then there's sort of an analog to semantics, so sort of how a device or card gets reused over time. And so in the same way that, like, language transformers are learning embeddings and words with similar meanings clustered together, so the sort of premise of the payments foundation model is just what if every charge or sequence of charges, and we can talk about that too, had its own vector in a similar space. So the inputs are, you're right, just the raw payment signals as they come in, the card details, the merchant categories, the IPs, but also those sequences.

So what a given card or device or merchant bin or customer has been doing in the last few minutes or the last k transactions. And it's actually that history that turns out to be a huge unlock. And then from those inputs, the model produces an output, which is just a reusable embedding.

Right? It's a it's a dense vector for each payment or short sequence, and then 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.

And I think we'll get to a stage where that can be real time ish as well, but we're not there just yet.

estimates with you on that. Yeah. Your your math is legit.

I'll answer the second question first and that first question second. Yes. Your math is is legit and the data is very different from the free form text that you'd use to, you know, train a model to write like Shakespeare.

Right? So payments data is highly structured and dense, and so we actually build a custom tokenizer that compresses the numeric and categorical signals really efficiently. So, yes, the dataset is big, but it's also packed with kind of this purpose built information that's incredibly rich for the set of tasks that we care about in our context.

You asked about, like, what's hard for a human to eyeball. I think the thing that's hardest for the human to eyeball is the you know, looking across those dimensions, not within any one payment, but within any, you know, combinatorial sequence. So, you know, if you think about it, what you need to look at in order to figure out if, say, 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 a vis the transactions that have come around it.

So you're not looking at, like, a single screen. You're looking at, like, you know, a clip of a movie. But there are a lot of different clips that include that screen that are relevant to look at.

Like, you wanna know what I was doing. You wanna know what the merchant was doing. You wanna know what my card was doing.

You wanna know what my IP was doing. And so that's really where the model sings, making it really efficient, not just to look at the individual payment. Like, it's hard to do with the scale of 50,000 a minute, but, you know, 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 sort of traditional ML approaches where you have to hand engineer features to capture what's happening in each of a range of different sequences. And so in our context, the foundation model pays off dramatically because it expands really three things. One is how much data we can learn from.

Like, 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. Right?

So these dense embeddings capture very subtle interactions that manual feature lists, like counterfeatures, wouldn't capture. And then third, which is more about sort of how we work internally, but it changes how efficiently we can build. Right?

Once you have a shared embedding, then spinning up a new model becomes a weekend project, not a quarter project, and that means we can sort of open the aperture for the types of ML powered solutions we can build.

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, at Palo Alto, not in Boston, and tend to be buying on, you know, things that are totally different from what you suddenly see someone doing in Boston, that's a red flag that that's actually, like, fraudulent use of my card. Or conversely, if you see someone using you know, rotating across a small number of cards to buy thousands of accounts from a given AI provider, maybe the card is truly there, but you're almost certainly gonna see some sort of reseller refund abuse happening where they're trying to steal your compute.

And so it's and and it becomes more complicated when you add more entities like the merchant, where there can actually be internal collusion happening. And so you're exactly right. Like, it's it's not about how any one entity acts in isolation.

It's about, like, an entity is a an individual or a card or a merchant, and then that's, the node. Right? And then the edges are the transactions.

And it's, how how much sense do these edges make in relation to each other and in relation to the combination of edges that we've seen in the past?

so I talked about the scale of the Stripe network. Right? It's like this $1,400,000,000,000.

But it's not just a big network. It's also a very dense network. So for example, 92% of cards that a merchant sees for the first time, Stripe has seen before on another merchant.

So okay. Well, in those cases, you don't have to do very many hops. Although, you do wanna validate that nothing's changed about the card or how the card's being used in the time since.

But fraud and conversion are kind of tail events in some sense too. Right? Like, if you can get 1% more conversion or one or 2% less fraud, that goes a long way.

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

like a masked type situation where you you could you could imagine doing a training setup where it's like mask out whatever kinda randomly and have the model learn to fill in details. Yeah. Exactly.

So our v one did use a sort of BERT style, like, masked modeling setup that you're talking about. And then we paired that with a second stage, which is, like, explicit similarity fine tuning. And so most of the heavy lifting there was like, okay.

Let's curate the right sequences to learn from. Let's build the right encodings. Let's 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 last k transactions rather than the the isolated payment.

Now in the we call it v 1.5, but we're actually moving towards encoder, decoder setups and compressed memory sequence. So, like, a few vectors together, that 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 this, like, comp compact representations. And so, yeah, the mental models like v one, mass modeling, plus similarity training, v 1.5 is compression first with a tight sequence embedding.

And then we can put kinda lightweight task specific heads on top, which are for the charge path use cases. Like, you know, if you think about the charge path, you gotta get the job done in tens of milliseconds at most. And so those lightweight task specific heads are are important for latency and speed.

And, you know, I think when you when you reason about it, like, 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 as they come in, which is a much easier problem than obviously, like, the upfront training.

Yeah. So it sounds like you're Lipping a while, but that's, yeah, that's an interesting that's an interesting analog.

like, very quickly. Like, that that step becomes a rapid iteration step. Yeah.

Exactly. And actually, you know, it can be even simpler, which is so so the embeddings themselves where most people start actually is most most modelers start is just taking the embeddings themselves, which are stored in Shepard, which is our feature engineering platform, and literally just, like, adding them as a feature to existing models, like, those existing models are, and saying, like, is there added signal from these embeddings? And I would say you get some false negatives there where, obviously, just, like, shoving the raw embedding into some number of, you know, SOTA models that have been, you know, iterated on over the last six years isn't gonna produce uplift.

But in other cases where it's sort of a lower priority model that's only in its v one state, like, you actually do get something straight out of the gate, and you can start to reason about, you know, we're we've been talking much about the payments embeddings. Like, how much signal do I get from, like, understanding the payment better? How much signal do I get from understanding the customer better?

How much signal do I get from understanding the merchant better for each of these use cases? And then that's also motivated where folks have kind of for which applications folks have leaned in harder.

Hundreds of production models. Right? Like point point solutions.

we were able to get additional signal. That's, yeah, really interesting. I mean, our This is standout application wasn't that.

Right? It was card testing where we literally, like it was a whole new approach to card testing with the foundation model, which, you know, I think card testing is like, you know, fraudsters trying hundreds of tiny authorizations, of iterating across stolen cards or literally just doing raw enumeration, like trying a bunch of cards. And they bury those attempts inside floods of legitimate traffic.

Right? A big retailer can have hundreds of thousands of charges come through, and then there's, like, a couple 100 or maybe a thousand peppered fraudster charges of, like, 30¢ or 50¢. And, like, classic models couldn't really pick up those kind of needles in the haystack.

And so our first application of the foundation model was just treat those sequences, again, like frames in a movie. Right? And suddenly, these 200 nearly identical requests, like, you know, same low entropy user agent rotating across proxies coming in about every forty seconds, like, they light up as an island in the embedding space and they get blocked.

And the impact of that one was huge. Like, our detection rate of car testing at large merchants went from 59%, which is, you know, not bad, but not great to 97% from that change. But then as we started reasoning about where else could it be useful, yes, just expose the embeddings and let them be added as features to these sort of traditional single task models was was the was the next step.

And that was never intended to be the final state, but it's a way to get signal on where is there sort of incremental value or incremental signal from these embeddings that requires very little lift.

that was basically doing horizontal models. Again, don't know don't know exactly how it worked or the architecture. You know, we're we've been talking about it in the context of payments, but we actually did we've done the same thing over the last year in the merchant space where we have it's called the merchant intelligence team, but it basically has MI serve.

So it it can go out and find anything in the in the web about a merchant and generate embeddings and be used to answer questions. And those merchant embeddings are also features in downstream, for example, merchant risk models. But it's a service where the model owner can ask merchant intelligence, the agent, to come up with a more custom embedding or a more custom insights.

So maybe you wanna know what payment methods the merchant offers or whether they have anything that's counterfeit. And and that's actually been another horizontal layer that's provided a ton of leverage for Stripe. Right?

Because historically, you know, you got a lot of use cases. You wanna know things about the merchant to understand supportability, like, you know, whether they they meet the requirements of the card networks and the issuers and the banks. You wanna know whether or not they're fraudulent.

You wanna know whether they've had an account takeover. You wanna know if they're creditworthy. You wanna know whether or not we should give them Stripe Capital, like, a loan, and you wanna figure out whether you should be going to market with them.

Like, all sorts of things you you wanna know about a merchant. And, historically, teams at Stripe were, you know, when when LLMs hit the scene, like, out building their own sort of custom versions of this. But what we realized is there's actually just, like, one service now that that does that much more efficiently than everyone rolling their own.

set in stone. Like, that's a long process. Right?

So Well, it's a long process if you even get to a definitive answer. But something like card testing, right, like, actually, I said the first thing we did with the foundation model was deploy it for card testing. Actually, the first thing we did for the foundation model is deploy it internally for card testing, pass those labels to internal expert humans, have them go and validate the labels, then feed the validated labels into our traditional ML model for card testing.

And suddenly, our ML model traditional ML don't deploy the foundation model. Our traditional ML model for card testing started doing way better because finally, it had, like, a more comprehensive source of truth for the labels. So it was actually actually the first version, although hadn't hadn't hadn't revealed that fun fact before.

Yes. Attackers iterate and so do their models. And so our job is just to iterate faster.

And we are, and I'll talk about some of the ways we we get around the the late arriving labels or the missing labels altogether. But just to give you a sense of, like, how we're comparing to the fraudsters, like, industry wide, ecommerce fraud is up. I think it's up, like, 15% year on year.

But the dispute rate for the businesses that are running on Stripe are down 17% year on 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, like, new tactic shows up and, like, defenses go and adapt. And that sort of loop shortening is happening in production and in some cases in real time.

So an example, that that our users are getting a ton of value from that we recently released is dynamic risk thresholds. So it's basically like, you know, radar's out. They've got their threshold score.

Block stuff above the threshold. But then when an attack starts, radar learns an attack starts, and it tightens the defenses. Right?

So it it kind of throttles. And that allows, like, okay. You know, revenue is flowing freely when you're not under attack, but then we're much more aggressively blocking when an attack arises because, again, like, an attack is never almost never a single event.

It's almost always like a a true a true cluster. And in that case, like, you know, the the model is learning the policy of how to act. Now it's not learning that policy online just yet, but it's learning the policy of of how to act.

Another powerful tool, and I think, you know, in payments, it's easy to think, like, I put in my credit card and then just, like, an objective decision is made to block me or not, But that's not actually true. And so we've been leaning in harder on what we call soft blocks. So adaptive three d s is an example here.

It, like, applies that three d s authentication. So, like, if you're in The US, most of the time, you don't get you don't get three d s. But we can Can you tell me what that is?

Because I don't feel like it. You might have defined it in the in the complex systems, but if if so, I could use a real question. Yeah.

You're just you're just like you have, like, a second like, a it's sort of like a two factor off that you would have. It's like a two factor off esque experience where you're verifying that to the credit card the bank network or the credit card issuer that it is in fact you. And this is very, very common in Europe, it's very, very common very, very uncommon outside of Europe.

And by the way, when it does happen, it often creates unnecessary friction. And so part of what we do at Stripe is figure out when we need to authenticate and when we don't. But also, with Adaptive three d s, we are pushing for authentication selectively in cases where we have a sense that the charge may not be good.

And so instead of just having this binary decision of block, don't block, you have this other arm you can go down, which is, you know, hit them with three d s. And what ends up happening is the good guys get through the three d s because they're excited to buy the thing and they're legit users, and the bad guys do not. And so a lot of the AI companies are using this.

You know, AI companies being hit with fraud is extra painful because their marginal costs are high, right, unlike for SaaS companies who care a lot care a lot less. And so, like, early adopters of adaptive three d s were, like, 11 and Character AI, and they're able to just dramatically cut down fraudulent disputes without any effect on conversion because, you know, three d s isn't isn't super heavyweight for the end user. In fact, US checkout users so it's it's a little different in Europe because a lot of those folks are already three d s, but US checkout users saw a 30% average drop in fraud, and they just, like, turn this on with a single click in the dashboard.

And then it lets us basically, like, learn the policy of who is worth 3 d s ing to balance conversion and fraud to maximize their profits.

Don't constrain yourself to being a modeler. Like, be a product thinker and go figure out how to get that information. Right?

And the model's really good at deciding, and then that that's not brute force. You don't require that additional information from everybody, but then let the model decide where it needs more information and where it doesn't.

And 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, you know, coming from a small number of attackers or some rotating across IPs or coming from a geography that they haven't seen before. And then once we get signal that, like, looks like there's a slice that's an attack, you can actually, like, start to lower the threshold from that subset for what it takes to block.

but less at the individual transaction level. Like, it's it's basically detecting anomalies in slices of traffic. Right?

So, like, this geo, this these bins, this cart size, like, something anomalous is happening here. That anomalous thing has kind of elevated risk scores. Hey.

Like, it reads a bit like an attack. And, actually, what's interesting I mean, rules are really good in a lot of ways. Right?

And so, you know, maybe another general lesson is, like, rules are good, but they're also blunt. So figure out where you can blend rules with models. I mean, you'd asked earlier when disputes actually come in.

Like, disputes are super lagged. They can take days. They can take months.

Right? I'm the cardholder. I have to, like, see my bill, like, notice I didn't buy the thing, tell my bank.

My bank has to go and, like, file with the network. And so those labels for sure arrive late, but we don't wait. We use proxy signals, and those sort of weak labels show up way earlier all the way to real time issuer feedback.

And it can be very so real time issuer feedback would be like, CVC mismatch. Right? Like, the the CVC code, you know, the the little three, four digit credit card code doesn't match or, like, the the ZIP code doesn't match.

It'd be easy to write, like, a blunt rule that said a CBC doesn't match or if the ZIP code doesn't match, block it. But you'd be blocking a bunch of good revenue because, like, who doesn't sometimes fat finger their CBC or their ZIP code in a hurry or on their phone or whatever. And so 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. So, like, if it's looking marginally risky and the CVC is wrong, for sure block. But if it's like a pretty known good user and they fat fingered a thing, like, let them through.

And I think that blend of rules and models is I think it's easy for modelers to put their nose up at rules, and it's easy for rule makers to put their nose up at models that aren't fully explainable. But in plenty of context, blending the two actually does does far better.

Nathan, like, I, like, 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 legit IP. And, like, I I feel good about you in a lot of ways. And, yeah, the issuer comes back and says, hey.

There's a mismatch. And we say, hey. Let it through.

And then by the way, once we let it through, we also have to get the issuer to let it through. And there, 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, and that motivates them to also pass it through when they when they see our signals. So it's kind of a two step.

mean, this this isn't one for us where it's like there's some magical, you know, reinforcement learning that we need to be implementing online for every single use case. I think it's actually for us been quite context dependent. The things that matter are having enough labels and having good labels and having those labels fast enough.

And, actually, like, you can get pretty creative about what the label is. We talked about some examples. We also talked about human generated labels.

But another thing that we've been leaning into is LLMs as a judge. So especially for context where there actually is is no source of truth. So a simple example, we've been talking a bunch about fraudulent disputes, but there's a lot of suspicious payments that never result in a fraudulent dispute.

Right? Maybe the person starts a free trial and then they cancel, or they ask for a refund, or they, you know, just spin up a bot account but never even get to the checkout page. That type of friendly fraud is actually really costly to businesses, and it's like almost half a business.

Think 47% of businesses say friendly fraud, which is a total misnomer because it's not friendly, hurts them more, hurts their business more than sort of stolen card credentials or what most people think of as fraud. And that's actually you know, there's a lot of AI companies running on Stripe. That cost of friendly fraud is particularly true for these AI companies.

Right? Very different than SaaS. Again, they have they have inference costs.

They have compute costs. Therefore, they have, like, very high marginal costs. And so when someone is engaging in free trial abuse or reseller abuse or refund abuse, it's super expensive to their their unit economics.

Anyway, so built on the foundation model, we now have these suspicious payments that we identify. So these are fraudulent e things, but not in the traditional going to result in a fraudulent dispute sense. And when we pass those over, for example, to the AI companies, we wanna be able to describe to them why they're flagged as suspicious.

So, oh, it has an enumerated email or it is, like, cycling through small number of IP addresses or whatever. So those labels are so sort of those explainers are generated by the foundation model. But then the question, of course, is like, well, how do you know if they're right?

And so we have this, like, LLM as a judge that sits on top that 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? And what ends up happening is that there's, you know, a a large share of labels that are good enough, trustworthy enough that we pass them over to name AI company du jour to decision on. And there's some small number that are, like, too noisy, and we're like, okay.

Like, we gotta go work a little bit to make that label stronger. But I call out that example because these are like there's no source of truth. Like, I like, could I mean, you and I could manually go through, I guess, but at the transaction level, we're not going to.

And so it's been really helpful to have LLMs kind of as a judge where there's where there's no where there's no clear north star.

A couple a couple thoughts. So one is we expose capabilities through products and APIs to our users, not through raw weights. So for sure, anybody can try a payment and test and see if they can do a workaround.

But just to be clear, like, we're not actually exposing the model for them to for them to, you know, have an attack surface against. Right? So, I think that the products and the APIs actually better meet the user needs, and they also kind of narrow the potential attack surface.

So just clarification one. I think for you know, it's it's interesting to think, like, what's the relevant alternative? Like, what is fraudster's job?

Fraudster's job is, like, find loopholes and exploit the system. Like, that's that's what they make their money on. And so the relevant alternative isn't, you know, perfectly airtight.

The relevant alternative is, like, baseline approaches. And, actually, when you start to think about foundation models or LMs, they you know, the payments foundation model, for example, like, it's actually a lot more nuanced, the the type of information that it's using to decision versus, like, you could think of, an early an early transaction fraud model that's using, like, last seven day counters. And, like, the fraudster figures out that, like, as long as I'm eight days out, I'm safe.

I'm just gonna do everything, like, on day eight and then hit them hard and then go seven days back. So so to some extent, I think sort of traditional ML is is easier to get around, whereas the the founder's model is more comprehensive. But the other thing that we certainly have long done and continue to do is a layered approach.

So it is not there's not just a single set of defenses. There's a set of model defenses. There's a set of rule based defenses.

There's the soft blocks I mentioned. There's the user's own defense set, which can also vary, like, all the way to to how they treat you at sign up or how they block bots at sign up. And so, fortunately, for us, unfortunately, for the fraudsters, they're not fighting against, like, one model.

They're fighting against a whole system that is, I guess, until I said it, opaque to them.

Yeah. I mean, we've we've talked a lot about sort of transaction level understanding and, you know, the the path there, if you think about, like, modality, like, it's it's mostly payments plus text. You have these, like, structured payment signals with and then, like, language using contrastive learning, and you align the two, and you got the text decoder and whatever else.

But payments plus text is, like, only the start. Right? So the system's actually designed so that new modalities are just considered, like, tools that the router on top can invoke.

And so, like, 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. Right?

It doesn't require, like, a whole kind of rewriting of the system. It's just like a modular expansion. And I think the multimodality like, I'm starting to see it really shine at the merchant level.

So, actually, yesterday, I was testing two lightweight agents. Neither of these are in production. So, well, you know, just just full disclosure.

But, like, the team, has them in shadow, and one crawls merchant sites to assess fraud, and it's relentless, like, incredibly relentless. The other spots counterfeit products, and it just does so, like, literal orders of magnitude better than trained human reviewers that we have at Stripe doing the same thing. So it'll find, like, there's a print shop and there's thousands of items in the print shop and the agent will, like, patiently zero in on, like, the one, like, spider Gwen sticker was, like, an example I was staring at yesterday with, like, no sign of of official licensing, like, rut rut.

Then it also knows, like, oh, this this other site, the Canada Goose, that's, like, marked as with tags is secondhand, and so it's actually it's actually fair game. So I think that kind of, like, that kind of multimodal road map is is interesting. Not for a multimodal in and of itself, not for the technology in and of itself, but for where it's, like, gonna unlock gonna unlock real value.

one of the reasons that, you know, this sort of talk to your data was interesting to us in Stripe's context is, like, a lot of what a business wants to know is captured in Stripe data. Like, you know, who's selling what, for how much, to whom, like, who's retaining and churning their subscriptions, etcetera. And so that's thing one.

Then thing two is the data is actually, like, very well structured because it it has to be. Right? Like, it's it's generated, you know, from the transactions that are flowing through Stripe that are incredibly, like, robust and well documented, and the schemas downstream of that make sense and are well documented as well.

And so, you know, a lot of this talk to your data stuff, it's like the garbage in garbage out problem where, like, my my tables aren't well labeled, my fields aren't well labeled, maybe, like, the underlying data actually isn't deduped. And so you can't really tell if the issue was, like, that sort of text to SQL or if it was actually, like, the underlying data was bad and or the data structure was not understandable. So we kind of were able to, like, leapfrog that, which is great.

But still, LLMs so you're I think you're referring to our Sigma system. LMs do make mistakes. And so our approach there is actually, like, if we have reasonable confidence, we'll provide it, but we I don't know if you've ever used it.

We overlay on top a natural language explanation of what we're doing. So, like, we thought you wanted to know whatever. You asked, like, you know, how did Black Friday this year compare to Black Friday the last two years?

And then they'll be like, okay. These are the dates we use for Black Friday. These are the time stamps we use.

Because by the way, like, most things on Stripe happen in UTC, and many people aren't reasoning about their business only in only in UTC. We looked at Black Friday over the last three years. Here's how we computed the percentage growth.

Like, you're like, that's boring. Doesn't everyone compute the percentage growth the same way? But that actually allows someone who's not a data analyst to build comfort in in in the output versus saying, like, either YOLO ing it, just like taking it and running with it, or throwing their hands up and saying, can't I can't trust anything because I don't know what's happening under the hood.

Like, you just wrote a SQL query for me, but I have no idea how to interpret it. So, you know, I think when I think about Talk to Your Data, it's like, well, is your data interesting to talk to? If yes, like, make sure it is well structured, well documented.

And if it's not, invest in that before you invest in, like, you know, the natural language interface on top, and then just make sure the natural that the LLM is, like, explaining what it's doing with which they're, of course, very good at doing now. And that allows you to open the aperture a bit in terms of, like, less certain questions you're willing to answer because you know anyone can read the natural language and make a call on on whether or not that was the the right approach.

there's also kind of an interesting feedback loop here with users. Right? So if you're a usage based billing company, the types of metrics you wanna 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 wanna know.

And so that both means that we can really make great the subset of questions that matter in a given domain. But, also, you know, forget the natural language to SQL interface or talk to your data. We can just push those commonly asked questions over 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, like, figure out which websites are like this website in terms of would be good comps because have similar have similar user bases and are at a similar stage of their development.

like, individual neurons in the way some research groups are. I think our focus is really on making the outputs self explaining in the way that we and our users, where it's user facing, can actually trust. And so, you know, mechanistic interpretability is really important when, like, you're releasing the full open ended model into the wild.

In our case, we control both application and the environment, and so our priority is, like, that really practical explainability that's tailored to the payments application. So, like, when the foundation model flags a transaction, it doesn't just say high risk. It says, you know, gibberish email and enumerated name pattern and device concentration.

And 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're talking about a little bit ago, like, in many of those cases, there's actually no ground truth for that explainer. And that comes up more and more as we expand to new domains.

Like, oh, we're we're actually detecting fraud further up your customer funnel, all the way when someone's, like, creating an account on you and well before they're entering credit card details. And so that's where things like the LLM as a judge framework are really helpful. So it'll, like, look at that and the cluster of similar events and the tag definitions and then output, like, how confident is the LLM basically judging how confident is it that the cluster really matches the label.

So, no, we are not, like, peering in neuron by neuron, but we are focused on interpretability at the output level, and that's really valuable for us. And then, you know, for example, like, you're in your dashboard and you're seeing a bunch of suspicious users, you wanna know exactly why we flagged them as suspicious so you can decide how to action. And so in our setting, that's that's really what matters most.

Totally. Totally. Don't even have it.

Like, Stripe's Stripe's APIs run at six nines of uptime. Right? So they are safe to use as your system of record for, like, very critical flows.

Our usage based billing APIs process 100,000 events per second, and they've got all the built in monitoring and alerting and invoicing. The alternative is also, like, pretty painful. Right?

Like, building if you're gonna, like, build your own mirror of Stripe's data, it's pretty complex. You gotta sync across all the events. You gotta build your own monitoring systems.

You gotta keep everything reconciled. And especially if we're talking about, like, a start up, that's just, like, a lot of work that doesn't create any kind of differentiated value. Right?

A lot of these companies are taking off have, like, five, ten, 20 employees. Like, they shouldn't be spending an ounce of that of that limited capacity on this stuff. And then on the flip side, you know, if you 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? Like, the, like, the billing threshold has been exceeded or whatever without having to have this whole parallel system. And we talked about Sigma system earlier, but with products like Sigma and Stripe data pipeline, you can still run all your analytics and all your reporting sort of without doing the job of of building your own your own warehouse.

You know, you you might be wondering about the downsides. Like, historically, the biggest downside of not mirroring, of like, just leaning into Stripe was, okay, but what about when I wanna join, basically, Stripe data to, like, my own business objects? And now you actually can.

So you can actually extend Stripe's objects with metadata. So, like, a lot of users will whatever. They'll, like, attach their own order ID or shipment ID to an invoice.

And for, you know, 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.

trusting, which six nines gives you pretty good reason to trust. Yeah. And, you know, that's just for the system of record.

Right? So Lovable, it's a great example. They hit a 100,000,000 in ARR in their first eight months, and their stack is basically a a case study in all in on Stripe.

Right? So they they incorporated the business. Before they monetized, they incorporated the business with Stripe Atlas.

They, from the very beginning, used our optimized checkout suite. So, like, the the front end customer facing services is our optimized checkout suite, which allowed them to localize payments in over a 100 countries and get something like a 150 payment methods out of the box. They leaned on billing for subscriptions, so they didn't build their own billing system or, you know, have to contract with another third party.

They leaned on Link, which is like our our one click consumer checkout for fast checkout. By the way, nerds love to buy from nerds. So, like, our concentration, on Link of AI buyers is is very, very high.

They leaned on Radar for fraud prevention. They leaned on Sigma for analytics. And so, really, like, Stripe took care of the financial plumbing and so that Lovable is just really focused with that small team on on product and growth, which, of course, they nailed.

But there's, like, small there's smaller ones. Right? Retail AI, they build, have you used them?

They're like CallAgents. Yep. Yeah.

For customer support. And so they launched last year. I think they have, like, you know, over 10,000,000 in ARR in their first year.

We 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, and it's literally a one click checkout for them.

They use us for smart retries. So, like, you know, when the transaction, usually, recurring bill fails, like, 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 a 100 countries.

And so it's just a great example of how these AI companies, very lean teams, growing fast, going global, and really just, like, scaling up to look like a much bigger company was right behind them.

It's kind of both. Right? Like, it's definitely still early.

There's still a ton we're sorting out about how's this actually gonna work and how quickly is it gonna take off. But and we're seeing meaningful traction. You mentioned Perplexity rates.

You can, like, discover and book hotels, you know, directly inside the app. But it's it's not just, like, big guys like Perplexity. Like, Hipcamp is a little site that uses agents with virtual cards to book campsites off platform.

I'm from Montana. It's, like, 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 in tech.

But Hipcamp is, like, actually solving that. And then, you know, I think it's easy when people think about a gen to commerce to think about commerce buying kids clothes consumer. But on the developer side, we're seeing the same trend.

Right? So developers now in Cursor can buy Vercel services right inside their editor. That's a brand new channel.

Right? Like, this really embedded commerce directly in the workflow, and and Stripe powers those transactions too. So, you know, we're not totally new to this.

Like, it was it was last November when we launched our agent toolkit, but we still have thousands of downloads each week. And I think just looking at the pace of adoption and looking at who's testing, I think agent commerce will be a major channel far sooner than than most people think.

I'm gonna actually trust you to go figure out what to buy and and execute on it at this stage, or is is that still not really materialized? Yeah. So so I can't name names, but this idea of, like, a business in a box.

Like, I wanna 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 go spin up the business. And that's not just the payment provider or the front end service or the, you know, bot protection or the, you know, HR system.

But, like, give me my whole business in a box, I think, could be an interesting direction. Now getting that right for the whole world of businesses that might be created is hard. Getting that right for, you know, a pretty focused AI wave that's coming online isn't isn't a crazy thing isn't a crazy thing to about.

So I agree with you that sort of the option sets 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, like, SaaS procurement is also very inefficient. Maybe we underestimate how inefficient it is, and that's not just in the selection of vendors.

That's also in, like, the pricing and negotiation with vendors. And so I don't think it'll be tomorrow, but I think there will be a there there.

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, the 1,300,000,000,000.0 a year is a lot.

Right? And volumes grow growing, like, 38% year over year. That's like a massive growing dataset.

The real advantage, I think, isn't the raw size, though. To your comment earlier, it's more the compounding loop. And in our context, that loop is the more data we process, the better 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, and kind of that loop compounds year after year.

And, you know, obviously, 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, it's because we're in a position to harness that scale to create even better products, which then is is the feedback loop. And we're pushing this further.

Right? You may have heard at Sessions last year, we announced a big push for modularity. And so now products like Radar, our fraud prevention product, or our billing product, or that optimized checkout suite for your users are available multiprocessors.

So they don't just work on Stripe transactions. They work on transactions or on billing plans or on checkouts that are happening outside of Stripe too. And that actually gives us window into an even bigger data network and kind of further reinforces that loop.

So, you know, 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 just really fun to see how that intelligence in turn helps them grow more profitably.

Yeah. I mean, Stripe has always leaned into new technology ways. Like, 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 in today for big bets being the best partner for AI companies. So just helping them monetize effectively and scale globally and manage billing and manage tax and manage fraud.

And, you know, two thirds of the Forbes AI 50 already run on Stripe, and we're very focused on co building, whether it's usage based building or whatever the next wave is, co building with them, and and being the best partner. The second is enabling agentic commerce. So we only talked about it briefly, but, like, 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 or commerce facilitator.

The third place we're really focused in 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 or Replit or Cursor or Mistral's LeChat. Right? Like, payments should show up right where the work is happening.

So that's thing three. And then fourth is what we talked about today, which is, you know, deploying our foundation model across the network to improve fraud detection, yes, to boost authorization rates, yes, but also expanding the intelligence layer that we provide to every user. So those are the four big investments.

I don't know. I'm not gonna say that there could never be a fifth, but today, we're really hyper focused on on the economic infrastructure for AI, not being an AI model shop directly.

Thanks so much.