Every few months the financial industry gets a new AI acronym, and most of them deserve the eye-roll they get. Transaction models are an exception. The largest payment networks call their versions Large Transaction Models (LTMs), while smaller, institution-scale variants are sometimes called Small Transaction Models (STMs). The idea behind them is simple, borrowed directly from large language models, and it solves real problems that have dogged fraud and anti-money-laundering teams for decades.

The core idea: commerce has a grammar

A large language model learns language by doing one deceptively simple thing billions of times: predicting the next word. In the process, it is forced to internalize grammar, context, and meaning, because you cannot predict the next word well without them.

A transaction model applies the same trick to money movement. Instead of words, the tokens are events: an account opens, a salary lands, a card is tapped at a coffee shop, a transfer goes out to a new beneficiary. Train a transformer to predict the next event across billions of account histories and it is forced to learn the grammar of legitimate financial life. It learns the rhythms of payday and rent, the way a plane ticket foreshadows a hotel booking, and the fact that a new account usually spends small before it spends big.

Fraud, in this framing, is a grammatical error. Consider a freshly opened account with thin identity verification that sits dormant for a week, receives a tiny test deposit, immediately sends a matching test payment out, then receives a large external transfer and fans it out to three brand-new beneficiaries within minutes before draining to zero. That sequence is as jarring to a well-trained transaction model as a sentence with its words shuffled is to a language model. It does not match any pattern of how real people actually use accounts. It is, incidentally, the classic signature of a mule account, and exactly the kind of multi-step, time-sensitive pattern that older tools struggle to see as a whole.

Why this beats what came before

Fraud detection has been machine-learning-driven for years, so the fair question is: what do transaction models add?

The workhorses of the industry have been gradient-boosted trees (GBTs) and recurrent neural networks (RNNs). GBTs score transactions using hand-engineered features such as averages, counts, and ratios that analysts define in advance, like “average spend over the last 30 days.” They are fast, robust, and deployable, but they can only see the patterns someone thought to encode as a feature. Criminals, inconveniently, specialize in inventing patterns nobody thought of yet.

RNNs improved on this by reading sequences directly, but they process events one step at a time and their memory of earlier events decays over long histories. A signal from three months ago, say an address change that only becomes suspicious in light of today’s activity, tends to fade before it can matter.

Transformers, the architecture behind both LLMs and transaction models, attend to an entire history at once. Long-range dependencies stop being a weakness and become the whole point: the model can connect a subtle event from months back to a transaction happening right now. Just as importantly, transformers scale. More data and more parameters keep buying more accuracy, where RNNs plateau. One major payment network has reported that a proof-of-concept transaction model, trained across a consortium of card data, caught more than five times the fraud value of a production GBT model at the same false-positive ratio. Even discounting for vendor enthusiasm, that is the kind of gap that changes roadmaps.

Embeddings: the quietly radical output

The most underrated part of the transaction-model story is not the risk score. It is that these models’ native output is an embedding: a rich numerical representation of a transaction or an account that encodes its relationship to past behavior and to the broader patterns of commerce.

That matters for three practical reasons.

First, embeddings supercharge existing systems rather than replacing them. You can feed them into the GBT models and rule engines you already run in production as a powerful new feature set, and both fraud catch rates and false-positive rates improve. No rip-and-replace, and no regulatory re-approval of an entirely new decisioning stack.

Second, embeddings enable behavioral linkage. Traditional AML linkage finds fraud rings through shared entities: same device, same address, same beneficiary. Embeddings co-locate accounts that behave similarly even when they share nothing on paper, which is precisely how professional mule networks are built. Hundreds of accounts, no common identifiers, identical choreography. Behavioral similarity finds the ring that graph analysis misses.

Third, embeddings are reusable. The same pretrained representations transfer to credit-default prediction, churn modeling, authentication step-up decisions, and expenditure forecasting. One expensive pretraining run yields many downstream wins. The foundation-model economics that made LLMs transformative apply here too.

The false-positive dividend

It is worth dwelling on false positives, because they are the silent tax of fraud prevention. Every legitimate customer whose payment gets declined or whose account gets frozen is a support call, a churn risk, and, at scale, a real revenue problem. Rules and shallow models are blunt: to catch more fraud, they flag more good customers.

Context is what breaks that trade-off. A large transfer to a new beneficiary is suspicious in isolation. In the context of an account that just received a bonus, has a ten-year history, and made the transfer from a known device at a normal hour, it is obviously fine. Because transaction models score events against the full behavioral context of the account, they can be simultaneously more aggressive on genuine fraud and more forgiving of unusual-but-legitimate activity. Catching more fraud while declining fewer good customers is the rare improvement that makes the fraud team, the customer-experience team, and the CFO happy at the same time.

You do not need network-scale data to benefit

Payment networks train their transaction models on hundreds of billions of transactions, and network-scale players will always have a data advantage for network-scale patterns. But the architecture is not gated by scale. An institution can train a small transaction model, with a few million parameters and a vocabulary of a few hundred event types, on its own account histories and get most of the benefits for its own use cases: mule detection, account-takeover signals, and anomaly scoring against its own customer base.

Small models bring an additional advantage that is easy to miss: interpretability. Techniques from the mechanistic-interpretability world, such as sparse autoencoders and transcoders, can decompose a small model’s internals into human-readable features like “rapid pass-through of funds” or “fan-out to multiple new beneficiaries.” When the model flags an account, an investigator can see exactly which behavioral features fired and where in the history. In a regulated industry where every suspicious-activity report needs a narrative and every model needs validation, an explainable model is not a nice-to-have. It is the difference between a tool compliance will approve and one it will not.

The honest caveats

Transaction models are genuinely useful, not magically so. They demand large volumes of high-quality data, real GPU infrastructure, and expertise to deploy without adding latency to authorization flows. Labels in fraud are noisy and late. And no model, however large, replaces the fundamentals: good KYC, sensible rules, human investigators, and information sharing across institutions. The right framing is that these models supercharge existing fraud strategies rather than replace them.

But that is exactly why the technology deserves to be taken seriously. It is not a bet on ripping out what works. It is a new layer that learned the grammar of money, and once you can read the grammar, the forgeries stand out.