Every few years, a new technology promises to change fraud detection forever. Usually it doesn't. So we treat big AI claims with a healthy skepticism, including our own.
Then we ran this experiment.
We took the same kind of model that powers ChatGPT, but instead of training it on text, we trained it on actual card transactions. Then we fed what it learned into the issuing fraud model we already run in production.
That model caught 24% to 35% more fraud than before, at the same share of transactions flagged for high risk. And it did so without ever being shown which past transactions turned out to be fraud.
These results got us excited. But taking a more grounded outlook, there are a few caveats worth flagging, as they pertain to how easy it would be to get the same results in other use cases.
Training a payments foundation model
The idea comes straight from how large language models learn. A model like ChatGPT reads enormous amounts of text and trains on one simple task: look at the words so far and predict the next one. Do that billions of times, and the model builds a deep sense of how language works.
We ran the same play on payments. Each customer's card history becomes a sequence, one transaction after another in the order they happened. We then trained the model to look at a customer's past transactions and predict the next one.
To do that, the model has to read a transaction the way it reads a word. So each transaction gets broken into its parts: who the merchant is, what it sells, how much moved, which channel it came through, and how long since this customer last transacted. Strung together in order, a customer's history becomes something the model can read from start to finish, the same way it would read a sentence.
What it learns from this is the pattern of a person's spending: which merchants they buy from, in what order, how often, and for how much. Repeat this across millions of transactions, and the model builds a detailed sense of what normal looks like for each individual customer.
Note that we never told the model which transactions were fraud. We did that on purpose, because we didn't want it chasing fraud directly. We wanted it to learn what ordinary spending looks like for a given person, so that anything off-pattern would show up against that backdrop on its own.
For any given transaction, the model then produces two things. The first is a compact numerical summary of everything the customer has done up to that point, which in machine learning is called an embedding. The second is a "surprise" score: a measure of how unexpected this particular transaction looks given the customer's history.
It’s also important to note that we did not replace our scoring model with a neural network. Our issuing model already scores every transaction using gradient-boosted decision trees, built with XGBoost, and running on 77 features we've engineered over the years. The new embeddings were simply added to it as extra features alongside the existing 77, and then we retrained the same XGBoost model on the larger set.
The results
Across every threshold we tested, adding the embeddings caught 24% to 35% more fraud. At a common operating point, where the riskiest 1% of transactions get flagged for action, the improvement was 28%.
Measured across all thresholds at once, using a standard ranking metric called AUC-PR that rewards a model for pushing confirmed fraud to the very top of the list, the improvement was 68%.
We also checked how heavily the scoring model actually used the embeddings when calculating the score. Ranked by importance, the embeddings came out among the features the model leaned on most, making up more than half of the top twenty-five.
However, the first version we built actually performed worse than our existing model. Handing a decision-tree model a few hundred unnamed new inputs gives it as much noise to trip over as signal, and it took substantial tuning to get past that. The final model needed close to twice as many decision trees as the baseline to make use of what we'd handed it.
The model also got better the more clients' data we trained it on. Training it across several clients beat training it on any single one by about a third. It learns more about how card spending behaves in general when it sees more transactions, which is the kind of breadth a shared network makes possible.
But the most striking result came from a client we held out entirely from the training set. We took a portfolio whose data had never touched the language model's training, and built its issuing model the way we build every other one. The embeddings improved it by 29%.
The model had learned something general enough about card spending to help a portfolio it had never seen a single transaction from. Interestingly, the improvement was largest among the transactions it was most confident were fraud, the ones most likely to be declined or frozen.
That result has a practical payoff. Because the model learns from plain transaction history rather than fraud labels, a new client doesn't have to wait months for enough confirmed fraud to pile up before it has a model that performs at all. The transaction history the model needs already exists on the day the client onboards.
What drove the performance boost
The result came down to the shape of issuing data, and three things about it in particular.
The first is a long, ordered history. A cardholder uses the same card many times a week for years, so an issuer accumulates a deep record of each customer's behavior. More than 90% of the customers in our test had at least 75 prior transactions on file. That's a lot of signals, and the order of those transactions carries information a simple total never could.
The second is how little an issuer sees about each individual transaction. By the time a card authorization reaches the issuing bank, the merchant and the network have stripped most of the context away. The bank doesn't see the device, the checkout session, or what was actually bought. It sees a card, an amount, a merchant category, and a timestamp.
That's why our issuing model ran on just 77 core features. There was little to build more from. And it's the best possible case for this approach: thin existing features leave the language model room to add something the old ones couldn't reach.
The third reason is that sequences resist being flattened, and flattening is exactly what traditional features do. Count the transactions in the last 30 days. Average the amount. Measure how far this purchase deviates from the customer's usual. Every one of those picks a window, and inside that window the order and rhythm disappear.
Here’s an example to help illustrate the principle: picture a card used in a steady weekday rhythm, coffee near the office each morning, a grocery run on the way home, gas every other Friday. One week, the same card runs three online electronics purchases in a single hour, at merchants it has never touched, in the middle of a workday.
No single rollup is going to catch this: the amounts all fall inside the customer's normal range, the 30-day count looks ordinary, and each merchant on its own is unremarkable. What's off is the sequence, the order of merchant types and the break from a rhythm the customer has kept for months.
A sequence model never has to pick a window. It reads the whole ordered history and works out for itself which past events tell it something about the next one.
It also handles things no feature engineer would think to build. Merchant names are messy. "HARBOR COFFEE #4471" and "Harbor Coffee Co" are the same shop to a person, and two unrelated strings to a computer. A sequence model learns to treat them as one, because purchases at both look alike in the data: similar amounts, similar timing, and the same kinds of transactions around them.
You can of course argue that everything the foundation model produces could, in principle, be engineered by hand. The problem is the cost. It takes months of work from the people who understand both fraud and data, who happen to be the scarcest people on any risk team. And the features still need maintaining long after they're built.
Where we expect it to fall short
The easy conclusion is that foundation models are the future of fraud detection in a broader sense than just for issuing. But the same shape that made issuing work so well is why we're cautious about other use cases.
Two things decide whether reading sequences pays off: how much history you accumulate per account, and how much detail you get with each event. Issuing is the extreme case of deep history and thin detail. But other fraud use cases look nothing like it.
A merchant or an acquirer sees close to the reverse. When someone checks out on an e-commerce site, the merchant sees the device, the session, the items in the basket, the shipping address, and the identity presented at checkout. Those feature sets are already wide and mature. And even if shoppers visit that site often, the number is definitely not close to 75 times on average, so there's very little history to read. Because there's more detail in each event and less history per account, we believe sequential-based foundation models would probably not perform as well on such use cases.
Onboarding and guest checkout are the far end of that. One event, no prior history at all. There's no sequence to read, so there's nothing for this approach to contribute.
Wallets and money movement apps land somewhere in the middle. People transact often enough to build up some history, and the provider sees more of each event than an issuer does.
For the issuing use case, however, this approach works great. It has thin raw data, which supports only a small feature set, so adding a rich new set of features naturally bumps up performance. Where the raw data is already deep and the existing features already capture most of it, the same embeddings have less to add.
From research to production
Two challenges remain to be solved before something like this can run in a live, regulated environment, and they're the ones most likely to decide where it can be deployed at all.
The first is explainability. When a traditional feature drives a decision, you can name it: this transaction got flagged because the amount was ten times the customer's usual. When the thing driving the decision is the 192nd dimension of an embedding, there's nothing to name.
But that number means whatever the model decided it should mean, and humans can’t deduct any meaning from it. In a regulated business, that missing explanation is a show-stopper.
The second is latency. Running a customer's full history through a foundation model at the exact moment a transaction requires real-time execution. That’s not a task foundation models are optimized for. The usual approach is to compute the embeddings ahead of time and store them, which trades a little freshness for a lot of speed. That trade looks affordable here, because one more transaction barely moves a six-month picture of how someone spends.
While we have solid ideas on how to approach these issues, they were purposely left out of the research phase. Now, with the proof of concept successfully built, we’re moving forward with productionalizing it in preparation for live deployment.
Are foundation models the future of fraud detection?
Back to the skepticism we opened with. For issuing, on the evidence we have, this approach earns its place: up to a third more fraud caught, drawn from better inputs to a model you already trust, and with no fraud labels required to get there.
But moving away from issuing, toward richer feature sets and shorter histories, we expect the advantage to shrink, perhaps to nothing. That is research we are still actively pursuing.
So before asking whether a foundation model is the right fit for you, there's a simpler question to answer first: what does your data actually look like?
What you just read is the short version. The full whitepaper, Building a foundation risk model, is written for the teams who have to build this. It lays out the complete method, so your own data scientists can follow it, the full results across every threshold, the analysis of how much history the model actually needs, and a candid account of the open questions, from explainability to latency to the experiments we haven't run yet.
If you're deciding whether an approach like this fits your own organization, you'll find the full details here.