One Shared Brain, Plus Specialists: What Revolut’s PRAGMA Means for Banking

PRAGMA is a foundation model Revolut and NVIDIA built to replace dozens of separate hand built feature tables with one shared encoder trained on raw, timestamped banking events across 26 million records. It learns general behavioural patterns through masked prediction, then gets cheaply adapted with LoRA for tasks like credit scoring, fraud detection, and product recommendation, showing the largest gains on rare event prediction.

A plain English guide to the largest published encoder model for consumer banking event data: what it is, how it works, and why it should be on your roadmap conversation.

1. The problem every bank already has

Walk into any retail bank’s data science function and you will find something like six separate models running in parallel: one for credit scoring, one for card fraud, one for churn, one for cross sell, one for AML monitoring and one for collections propensity, each with its own team or at the very least its own backlog. Underneath every one of them sits an artefact shaped rather like a spreadsheet, called a feature table, made up of hundreds of columns built by hand with names like average balance over the last 90 days, count of declined transactions in the last week, or ratio of ATM to card spend.

Those columns are built by people, and by capable people at that, working over a period of months and using their judgment about what probably matters. The uncomfortable part is that each team builds its own set from the same underlying transaction data, which means most of them are reinventing the same wheel in parallel.

It is worth thinking of this as a police force that hires a separate detective for every category of crime and then forbids them from comparing notes. Each detective develops a private filing system and a private set of instincts, none of them benefits from what the others have learned, and when a new category of crime appears the only available move is to hire another detective who starts from nothing.

In April 2026, Revolut Research and NVIDIA published a paper describing the alternative, which is to train one detective who has read every case file in the city and then give that detective a short briefing for each crime type as it comes up. They called the result PRAGMA, and the detective analogy is worth holding onto, because the most interesting part of the paper turns out to be the point at which the analogy stops working.

2. What PRAGMA actually is

PRAGMA is a foundation model for banking events, and both halves of that phrase need unpacking before the rest of the paper makes sense.

2.1 “Foundation model”: the apprentice who read everything

You already know what a foundation model is even if you have not used the term, because ChatGPT is one, and the recipe behind it never really changes. You take an enormous pile of raw data and train a model to fill in blanks in that data, without asking it to perform any useful task at all, since the only job is predicting what has been hidden. Do this at sufficient scale and something genuinely surprising happens, in that the model develops a general understanding of the domain, picking up grammar, facts, cause and effect, and tone without anyone having taught it any of those things explicitly.

The payoff comes later, because when you want the model to do a specific job you no longer start from scratch. You add a small amount of training aimed at that particular task on top of what the model already knows, which turns a project measured in years into one measured in weeks.

Foundation models already exist for text, images, audio and code, and PRAGMA is an attempt to answer the obvious next question, which is why there should not be one for money.

2.2 “Banking events”: the raw diary rather than the summary

This is where the crucial design decision sits, because PRAGMA does not consume feature tables at all. What it consumes is the raw diary of what a customer actually did, in order, with timestamps attached:

Card payment, R280, merchant Spotify, 19:20 on Tuesday. Opened the app. Viewed the savings tab. Received a push notification. Transferred R2,000 to a savings pot. Card declined, R6,400, merchant unfamiliar, 03:12 on Saturday.

Notice that this diary includes app navigation, trading activity and communications rather than transactions alone, which means PRAGMA is reading the customer’s behaviour and not merely their money movement. That distinction matters enormously, and it is one of the things that separates PRAGMA from the comparable work published elsewhere, most of which covers transactions and nothing else.

2.3 The scale involved

The corpus used for pretraining covers 26 million user records, where a record is a pseudonymised event history tied to a particular evaluation point rather than a distinct human being, so the figure is not quite the same thing as 26 million customers. Those records contain 24 billion events, which become 207 billion tokens once encoded, and they span 111 countries over a window of 25 months running from 2023 to 2025.

Three model sizes were built from the same underlying design, at 10 million, 100 million and 1 billion parameters. The compute ladder between them is worth understanding, because it is less smooth than the headline suggests: the 10 million parameter model took roughly two days on 16 NVIDIA H100s, whereas both the 100 million and the 1 billion versions took approximately two weeks each, the former on 16 GPUs and the latter on 32. There is no cheap rung sitting between tiny and serious.

It is worth converting those figures into money, because “32 H100s for two weeks” means very little to most people reading a roadmap document. Sixteen GPUs running for two days comes to roughly 770 GPU hours, while 32 GPUs running for a fortnight comes to somewhere near 10,750. At the specialist GPU cloud rates prevailing in 2026, which sit in the region of two to three dollars per GPU hour, that puts the smallest model in the low thousands of dollars and the largest somewhere in the twenty to thirty thousand range, with the hyperscalers charging perhaps half again as much. Those are startlingly modest numbers for the headline results attached to them, and they are also thoroughly misleading, because the compute was never the expensive part. The expensive part is assembling, cleaning and governing 24 billion events into a form a model can read, and no cloud invoice will tell you what that costs.

One small honesty note before moving on, which is that the paper never actually says what PRAGMA stands for. Commentary elsewhere has guessed at expansions along the lines of “pretrained banking model,” but the authors themselves do not tell us.

3. How it works, step by step

3.1 Turning a transaction into a language

A language model reads text as tokens, which are roughly word fragments, so that “unbelievable” might arrive as “un / believ / able” and the model learns which fragments tend to follow which others.

A transaction is not a sentence, though. It is a structured record consisting of a currency, an amount, a merchant, a category and a timestamp, and the naive approach of dumping that record into JSON and letting a text tokeniser chew on it fails for reasons the paper explains clearly. The tokeniser wastes most of its budget on brackets and key names, and rather more seriously it shreds “14.99” into “14”, “.” and “99”, which destroys any sense that this is a small amount, and for a credit model magnitude is close to the entire point.

PRAGMA therefore encodes each field as a triple made up of what kind of thing it is, what its value is, and when it happened. The key, meaning the description of what kind of thing this is, always gets exactly one token, and there are only around 60 keys in the whole vocabulary, covering fields such as Currency, Amount, Merchant and Channel. Values are handled according to type. Numbers become percentile buckets, so that rather than learning the digits “14.99” the model learns that this sits in the bottom fifth of spending amounts, much as you might record which decile of the field a runner finished in rather than their time to the millisecond. Categorical values get a single token each, with the boundary between categorical and free text decided by how many unique values a field contains, and free text receives the same treatment by word fragment that a language model would apply.

Time is encoded twice over, which is the more elegant half of the design. It appears once as the elapsed time since the most recent event in the history, squeezed through a logarithmic transform so that intervals of three seconds and three years can both sit on the same ruler while retaining useful precision at the recent end. It appears again as a position within the calendar cycle, covering hour of day, day of week and day of month as repeating waves whose periods are fixed to real calendar cycles rather than learned from scratch, which is how the model comes to understand that a transaction at three in the morning is unusual and that the twenty fifth of the month carries payday behaviour.

What all of this produces is a vocabulary of roughly 28,000 possible value tokens sitting alongside 60 keys, which is both compact and faithful to magnitude in a way that a text tokeniser would not be.

3.2 Two kinds of knowing, held in two branches

PRAGMA divides each customer into two things that it reads separately from one another.

The first is who you are, covering account tenure, plan type, region and onboarding characteristics, all of which are facts that move slowly if at all, and all of which are handled by a dedicated profile encoder.

The second is what you have been doing, meaning the event stream itself, which passes first through an event encoder that reads each event in isolation and then through a history encoder that reads the full sequence of events together with the profile summary and fuses the two into a single representation.

The comparison worth making is to a good relationship manager, who holds two things in mind simultaneously: the client’s standing file and this month’s activity, neither of which tells you very much on its own. PRAGMA’s architecture makes that separation explicit, which as we will see allows it to lean heavily on the standing file for some questions while quietly ignoring it for others.

3.3 Learning by filling in blanks

PRAGMA is trained the way BERT was rather than the way ChatGPT was, and this distinction deserves a paragraph of its own because it tends to get waved through when it should not be.

Decoder models, of which ChatGPT and Claude are examples, are trained to predict what comes next, reading left to right, and they are built in order to generate. Encoder models, of which BERT and PRAGMA are examples, are instead trained to fill in blanks anywhere in the middle of a sequence using context drawn from both directions, and they are built in order to understand and classify rather than to generate anything.

Since every question Revolut wants answered downstream is a classification question, asking whether this customer will default within twelve months, whether this transaction is fraudulent, or whether this person will take up this product, the choice of architecture follows fairly directly. What you want is not a model that writes plausible looking transactions but one that reads a history and forms a judgment about it, and that is what an encoder gives you.

The blanking out itself happens in three ways blended together. Fifteen percent of individual tokens are hidden, so that the model has to guess a merchant category or a bucketed amount from what surrounds it. Ten percent of whole events are hidden, meaning an entire transaction vanishes from the sequence and has to be inferred from the events on either side of it. Finally, ten percent of the time a whole field type is hidden, so that every single amount in the history disappears at once and the model must predict them given nothing but the field name and everything else it can still see.

That third variant is the clever one as far as banking is concerned, because teaching a model that the amount is often inferable when you can see the merchant, the time and the surrounding behavioural pattern is precisely the reasoning a fraud analyst performs by hand. It is exactly the bias you would want to install, and it arrives free of charge from the training objective rather than having to be built by a feature engineer.

3.4 Adapting the model to a job, cheaply

Once the backbone exists there are two ways to put it to work, and the paper evaluates both.

The cheap route runs a customer through the frozen model and takes the numerical summary that comes out the other side, which is called an embedding and is best thought of as a rich behavioural fingerprint of somewhere between 192 and roughly 2,000 numbers depending on the model size, capturing a great deal of what the model has understood about this person. You then train a simple logistic regression on top of that fingerprint, which fits in a couple of minutes. Revolut frames this as the tool for rapid experimentation, to be used before committing to anything more expensive.

The better route is LoRA, short for Low Rank Adaptation, which avoids retraining the whole billion parameter model for each task by freezing almost all of it and adding small trainable adjustments to the attention and feedforward layers, updating only two to four percent of the weights in the process. The analogy is that you do not educate a specialist all over again from scratch in order to hand them a new category of case; you give them a briefing document and let them adjust their existing expertise accordingly. Fine tuning this way took roughly an eighth of the wall clock time that pretraining had required, which worked out at somewhere between twelve hours and a few days.

LoRA beat the frozen embedding approach on every single task measured, by as much as 73 percent on some of them and by well under one percent on others. The frozen embeddings still worked, though, which matters a great deal if your compute budget is a real constraint rather than a rounding error.

4. The numbers

The headline results below come from PRAGMA Large with LoRA fine tuning, measured against Revolut’s own internal models built for each individual task. Every figure is a relative lift, since the absolute scores were withheld as commercially sensitive.

The final pair of rows deserves attention, because two metrics computed on the same uplift experiment disagree with each other by more than an order of magnitude, which is a useful reminder that no single number in this table should be read without its metric definition close at hand.

Three broader patterns emerge from the results. The first is that the wins cluster heavily on rare events, because PR AUC and recall are the metrics that matter when the thing you are hunting is scarce, whether that means defaulters, fraudsters, or the small minority of people who open a follow up message. That is where PRAGMA performs spectacularly, whereas on tasks where the signal is dense and the underlying pattern is simple, such as whether a given transaction recurs monthly, it sits at roughly parity, which is both honest and entirely unsurprising, since your existing model was probably already competent at that.

The second pattern is that pretraining genuinely transfers, and this is the finding that carries the most weight even though it is the least exciting to look at. The relevant experiment compares PRAGMA fine tuned with LoRA against the identical architecture trained from scratch on the same task data, and at the 100 million parameter size credit scoring gained 13 percent PR AUC purely from having been pretrained beforehand, while communication engagement gained 18.6 percent and product recommendation gained 10.3 percent, with no task regressing anywhere. The paper does not run this comparison at the 1 billion parameter scale, so we cannot say whether the transfer benefit grows or shrinks as models get larger. This is nonetheless where the business case lives, because if pretraining did not transfer then the entire infrastructure investment would be theatre.

The third pattern is that the design with two branches earns its keep, and the ablation that demonstrates this was run at the 10 million parameter size. Compared against a version that reads events only, with the profile branch stripped out entirely, the full model scores 31.8 percent higher on credit scoring PR AUC and 85.6 percent higher on fraud recall, which makes sense given that tenure and onboarding signals are how you identify the rare defaulter in the first place. On communication engagement, however, the version reading events only actually performs better, with the full model coming in 3.0 percent lower on PR AUC, because whether somebody comes back is a story about their behaviour in the period just before they dropped off rather than a story about who they are. The architecture leans on the standing file where it helps and shrugs it off where it does not.

5. What it can be used for

The paper covers credit risk, external fraud, product recommendation, marketing uplift and targeting, lifetime value and the detection of recurring payments directly, but the more interesting framing is the one Revolut uses themselves, which is consolidation, meaning a single backbone carrying many lightweight heads. The implications for a bank’s operating model run considerably wider than any individual metric.

Experimentation becomes substantially cheaper, though not in the way people sometimes assume. You still need labels, because a frozen embedding cannot conjure a target variable out of nothing, but what disappears is the feature engineering step, which is where most of the elapsed months actually go. Revolut’s own framing is that the embedding probe is what you reach for in order to establish whether a task is worth pursuing at all, before committing to a full round of fine tuning.

Maintenance also collapses in a fairly dramatic way, since instead of six feature pipelines drifting independently of one another you are left with a single backbone to monitor alongside a set of small adapters to retrain. Revolut flags this explicitly as the production prize, describing it as the consolidation of multiple independent models, each demanding constant upkeep, into one shared system.

Behavioural signal becomes usable for the first time in many institutions, because app navigation and messaging response are sitting right there in the sequence. Most banks’ feature tables ignore this data completely, not because it lacks value but because nobody has ever had the time to engineer features out of a clickstream.

Small models turn out to be viable as well, since the 10 million parameter version is described as a possible efficiency sweet spot for transactional work and for lifetime value, and it trained in two days. It still required 16 H100s, though, so the floor here is lower than the headline figures suggest rather than absent altogether.

6. Why this matters most for fraud and credit

Two of those use cases deserve considerably more than a paragraph, because credit and fraud are where a transactional timeline does something that neither bureau data nor a rule written by an expert can do at all. It is not that the model is a better version of the existing tool. It is that it answers a different question, and in both cases the question it answers is closer to the one you actually care about.

6.1 What a bureau record tells you, and what it leaves out

A bureau record is a shared summary of how somebody has serviced other institutions’ credit in the past. It is enormously valuable and it is also, structurally, three things at once: lagging, sparse and coarse. It lags because it updates monthly at best and reflects obligations that were entered into weeks or months before that. It is sparse because it only knows about credit products, so a customer who has never borrowed is close to invisible in it. It is coarse because a tradeline records that a payment was made or missed, without any of the surrounding circumstance that would tell you which of those two outcomes was a near miss and which was comfortable.

The consequence in a mass market book is that a large share of customers arrive either thin or blank at the bureau, and the traditional answer has been either to decline them or to price for the uncertainty. Both responses are expensive, and both are responses to missing information rather than to genuine risk.

A transactional timeline inverts every one of those three properties. It is current rather than lagging, since it updates the moment money moves. It exists for every customer who has ever transacted, whether or not they have ever borrowed, which is exactly the population the bureau cannot see. And it is fine grained to the second, carrying not just what happened but the order in which it happened.

6.2 The timeline as a fingerprint of the ability to service credit

The question a credit model is really asking is whether this person will still be able to meet an obligation in eighteen months’ time. A bureau score answers a proxy for that, namely whether they met other obligations before. A transactional history speaks to it far more directly, because the ability to service credit shows up in a timeline as a set of patterns that no single feature captures.

Income regularity is visible, and so is its opposite. Two customers can report the same annual income while one receives twelve stable deposits from one payer and the other receives forty irregular deposits from six. Those are entirely different risks and the bureau cannot tell them apart. The timeline also carries the stability of the pay date, changes in the paying entity that suggest a change of employer, and the trajectory of income rather than merely its level.

Buffer behaviour is visible, meaning what the balance does in the days before money arrives. Whether it approaches zero, whether it goes below zero, how many days each month are spent close to the edge, and whether that margin is widening or narrowing over the last six months. This is one of the most predictive things about a person’s financial resilience and it appears nowhere in a bureau file.

Revealed priority is visible, which may be the single most interesting signal in the whole set. When there is not enough money to go around, the order in which somebody pays things tells you what they will protect. A customer who lets discretionary spending collapse but never misses a debit order is behaving differently from one who keeps spending and lets the debit order bounce, and both of those may currently score identically.

Reliance on expensive short term credit is visible as inbound flows and their repayment, often before it ever reaches a bureau file, which makes it a leading indicator of distress rather than a lagging record of it.

None of these are new ideas, and this is worth being clear about. Analysts have built features like these by hand for years, and lenders already read bank statements to assess affordability. The change PRAGMA points at is not the discovery of these signals but the removal of the requirement that somebody think of them first. The model is trained to reconstruct hidden parts of a customer’s history, which forces it to learn the regularities in how money moves through a life, including a great many that no analyst has enumerated and some that would be very hard to write down. The paper’s credit scoring result, a lift of 130.2 percent in PR AUC over an internal baseline, is what that looks like when the target is the rare defaulter, and the ablation showing the profile branch contributing 31.8 percent on the same metric confirms that tenure and onboarding context are doing real work alongside the sequence.

6.3 Redefining “unusual” for fraud, one customer at a time

Fraud is where the conceptual shift is sharpest, because a rule written by an expert and a bureau score share a hidden assumption: they define normal as a property of the population. A rule that flags any card transaction above a set amount in a country the customer has not visited applies the same threshold to a pensioner and to a contractor who buys materials in bulk. The threshold is a compromise between them, which means it is wrong for both, and the cost of that compromise is paid in false positives on one side and missed fraud on the other.

A model pretrained on sequences defines normal as a property of the person. A payment of R6,400 at three in the morning is unremarkable for somebody whose history contains hundreds of late night transactions and genuinely alarming for somebody whose history does not, and the model holds both of those judgments simultaneously without anybody having to write either of them down. This is what the masking objective is quietly training for, since a model that has learned to predict a hidden amount from the merchant, the hour and the surrounding pattern is by construction a model that knows what this particular customer’s next transaction ought to look like. A large gap between what it expected and what arrived is an anomaly score calibrated to one individual rather than to an average.

The behavioural sources widen this considerably. Because app navigation sits in the same sequence as the payments, the model sees the journey and not just the destination. A genuine large payment is usually preceded by a plausible sequence of screens, whereas an account takeover often carries a distinctive signature, perhaps a credential change, then a new beneficiary, then a limit increase, then a transfer, compressed into a few minutes. A rule engine can catch that only if somebody anticipated the exact pattern and wrote it down, by which point the fraudsters have moved on. Rules are also probed and learned by the people they are meant to stop, in a way that a representation of individual behaviour is much harder to reverse engineer.

The paper’s fraud numbers are worth reading closely for one specific reason. Recall improved 64.7 percent and precision improved 16.7 percent at the same time, and these two normally trade against each other, so a threshold change cannot explain both moving in the same direction. That pattern is the signature of a model that has genuinely separated the classes better rather than one that has simply been retuned. The profile branch again matters a great deal here, contributing 85.6 percent on recall in the ablation, which suggests that knowing how long somebody has been a customer and how they were onboarded is central to judging whether their current behaviour is out of character.

There is an operational dimension too. Fraud patterns move faster than any other risk in a bank, and a LoRA adapter can be retrained in twelve hours to a few days on a backbone that already understands transactional behaviour, rather than requiring a fresh cycle of feature engineering every time a new attack appears.

6.4 Where this argument has to stay honest

Three qualifications belong with all of the above, and they matter.

The paper does not compare PRAGMA to bureau data, and it does not disclose which features its internal baselines used. Those baselines were built by a bank for credit scoring, so they very probably contained bureau signal already, in which case the reported lift sits on top of the bureau rather than instead of it. That reading is actually more useful than the alternative, but it is an inference and not something the paper states.

Bureau data also does one thing a transactional timeline structurally cannot, which is see obligations held at other institutions. Your own feed shows a debit order leaving, but it cannot tell you the size of the facility behind it, and it cannot see a loan taken out elsewhere last week and not yet drawn against. Total indebtedness is a property of the network of lenders, and a single institution’s view of one customer is blind to it in precisely the way section 7 describes PRAGMA being blind to money laundering networks. The bureau is the closest thing the credit system has to that missing network view, which makes the two sources complements rather than competitors.

Finally, transaction based credit decisioning carries a governance risk that bureau based decisioning does not, and it is more serious than the general explainability problem. Spending patterns correlate with protected characteristics in ways that credit tradelines largely do not, since merchant level detail can act as a proxy for religion, health status, pregnancy, disability or sexuality without anybody intending it to. A model free to learn any regularity in the sequence is free to learn those, and it will not announce that it has. Any serious use of this approach in credit needs proxy discrimination testing built in from the start rather than added when somebody asks, and that requirement is not a reason to avoid the idea but it is a reason not to open with credit decisioning.

7. Where it fails, and why that is the most useful part of the paper

PRAGMA scored 47.1 percent worse on F0.5 than the existing production baseline when applied to money laundering detection, and the authors publish this plainly while offering two reasons for it.

The first reason is that the AML dataset was simply large enough that pretraining contributed nothing, because with abundant labels available the baseline built for that task could learn robust representations entirely on its own. This is the caveat about foundation models that tends to get forgotten, namely that their advantage is largest precisely where labels are scarce, and that a well tuned specialist remains hard to beat wherever you already hold millions of labelled examples.

The second reason, which the authors describe as the more important of the two, is that AML is fundamentally a relational problem. Money laundering is not a pattern living inside one person’s history but a pattern spread across accounts, showing up as circular flows, mule networks, or structuring split deliberately between several parties. The production baseline draws on features computed across records that capture this signal at the level of the network, whereas PRAGMA as published reads each customer’s history in isolation and has no idea that the other accounts even exist. This is where the detective analogy from the opening finally breaks down, because PRAGMA is a superb reader of individual diaries and money laundering is a conspiracy, and you cannot detect a conspiracy by reading one diary very carefully, however skilled a reader you happen to be.

Two things about how that number was produced are worth carrying forward. It came from a frozen linear probe on PRAGMA L embeddings rather than the LoRA fine tuning that generated every win discussed above, and since LoRA beats frozen embeddings by up to 73 percent elsewhere in the same paper, the AML comparison is not being measured on the same footing as the rest. The metric also matters, because F0.5 deliberately weights precision above recall, which means the gap of 47.1 percent describes a model that is worse at flagging cases cleanly rather than one that is necessarily missing more laundering overall.

The authors’ stated remedy is to extend PRAGMA itself so that it captures interactions across records, and they name this as a key direction for future work. Either way the practical reading is the same, in that anybody who finishes this paper believing they have found one model to rule them all has read it incorrectly, because a sequence model that reads one customer at a time is not the right instrument for a network problem.

8. The question the paper does not answer

There is a silence running through all forty or so pages of this paper that anybody working inside a regulated bank will notice immediately, and it concerns governance.

The headline use case here is credit scoring, which means a model of a billion parameters producing predictions about whether a customer will default. In most institutions that is not primarily a modelling problem at all; it is a problem of model risk and explainability, and it is one that has killed a great many technically excellent projects. If a declined applicant asks why they were declined, somebody has to answer, and in a number of jurisdictions they have a legal right to that answer. If the model risk committee asks which factors drive the score and how stable those factors are across protected groups, somebody has to answer that too. Neither question is comfortable to face holding an embedding of 1,024 numbers and a transformer someone has fine tuned.

The paper says essentially nothing about any of this. It contains a single line confirming that all data used was fully anonymised and free of personally identifiable information, and one further acknowledgement in the introduction that practical deployments must operate under privacy and regulatory constraints which limit both what can be reported and which features may be used for certain decisions. Beyond those two sentences there is no discussion of feature attribution, no reasoning about adverse action, no testing for fairness or disparate impact, and no reference to any framework for model risk governance whatsoever.

That silence should be read carefully rather than as an oversight, because it is a research paper and not a deployment document, and none of those omissions is a defect in the work itself. The silence does, however, tell you exactly where the unfinished business sits, and it goes some way towards explaining why the paper reports no production deployment. It also suggests a sensible sequencing for anyone tempted to follow this recipe internally, which is to prove the idea somewhere the explainability burden is light, whether that means fraud triage, marketing targeting, servicing prioritisation or the detection of recurring payments, rather than opening on credit decisioning, where the governance conversation will consume more calendar time than the modelling ever did.

9. Caveats worth carrying into any internal conversation

It is worth being the slightly annoying colleague on four points in particular.

Every result in the paper is offline, which is to say a backtest against internal baselines, with no A/B test and no reported production outcome anywhere, since the paper simply does not tell us whether PRAGMA is running in anger. The nearest comparison available is Nubank’s nuFormer, published in July 2025, which reported a far more modest 1.25 percent lift in test AUC on a single recommendation task but paired it with a 4.4 percent churn reduction observed in production. Even that needs qualifying, because Nubank state explicitly that they could not A/B test every variant, which makes the 4.4 percent a comparison of before and after in production with hedged attribution rather than a controlled experiment. Neither paper clears the bar you would ideally want cleared, and it is worth noticing that the two papers also disagree on almost every design decision, in that Revolut built an encoder spanning multiple event sources with an explicit profile branch, while Nubank built a decoder over transactions alone.

Every figure is also relative, with the absolutes redacted, so a 130 percent lift on PR AUC tells you nothing whatsoever about whether the starting point was strong or weak to begin with.

Neither paper announces a release of the weights, meaning there is no public checkpoint on offer and no way to download PRAGMA and run it against your own book. What you can do instead is read the recipe, and the recipe happens to be specified in unusual detail, right down to the optimiser and the hardware.

Finally, the binding constraint here is the corpus rather than the code, because 26 million user records spanning 111 countries constitutes a genuine moat. The architecture is reproducible by anyone with the patience; the data is not.

10. The part that actually matters

Strip away the architectural debate and what remains is two independent teams, working at two of the world’s more aggressive digital banks, publishing the same finding eight months apart: learning without labels on raw event sequences substantially reduces the need for features built by hand, and doing so produces material lifts on real banking problems.

The word doing the work in that sentence is reduces. Neither paper claims outright replacement, and Nubank’s headline result is explicitly a fusion, combining transformer embeddings with the existing tabular features rather than discarding them. The honest version of the claim is that the raw sequence contains signal your feature table is currently throwing away, which is a rather different proposition from the idea that your feature table is worthless. Two teams who agree on nothing else architecturally have landed on that same conclusion independently, which is a stronger signal than either paper’s headline percentage.

The reason this took so long has never been a shortage of data, since banks hold sequential behavioural data of extraordinary richness, arguably richer than anything outside of search. What was missing was the coincidence of available GPUs and internal mandate arriving at the same moment, and that coincidence is now happening often enough for the recipes to be published rather than merely rumoured.

The question facing any bank reading this is not whether to go and build a model of a billion parameters, which is both the wrong question and an unanswerable one. It is something narrower and considerably more tractable: do we have a task where the thing we are hunting is rare, where our current model leans on features built by hand, where years of raw event history are sitting unused in a warehouse somewhere, and where the explainability burden is light enough that a win would actually be allowed to ship? If the answer to all four is yes, then the 10 million parameter version of this idea is a scoped experiment with a published recipe rather than a moonshot.

11. Sources

1. PRAGMA: Revolut Foundation Model, Revolut Research and NVIDIA, arXiv:2604.08649, April 2026
2. Inside PRAGMA: Revolut’s Foundation Model for Banking, Philipp D. Dubach, whose framing of the nuFormer comparison and of the constraint being the corpus rather than the code informed parts of the argument here
3. Deep Dive: Revolut’s PRAGMA, The Transaction Foundation Model, Sam Boboev, Finextra
4. nuFormer, Nubank, arXiv:2507.23267, July 2025