What PRAGMA Is
In April 2026, Revolut Research published PRAGMA on arXiv, a family of encoder-style foundation models built specifically for banking event sequences rather than text. Where a language model learns to predict the next word, PRAGMA learns to predict what a customer's financial behaviour implies, trained on roughly 25 to 26 million users across 111 countries, drawing on approximately 40 billion financial events and 207 billion tokens.
The architecture is deliberately not a chatbot. It tokenises each financial event as a triple, a semantic key, a typed value, and a temporal coordinate, then fuses a profile-state encoder with an event encoder through a shared history encoder. The model family scales from 10 million to 1 billion parameters, and Revolut reports it running in production on more than 200 NVIDIA H100 GPUs.
What matters for governance is not the architecture, it is the paper's own list of downstream tasks the single backbone is evaluated against: credit scoring, fraud detection, customer lifetime value prediction, communication engagement, recurrent transaction detection, and product recommendation. One pre-trained representation, six distinct decision types, each with a different regulatory profile.
Everything past this point is regulatory and structural analysis of what that scope implies. It is not a claim about what Revolut has built internally to govern it.
One Backbone, Six Decisions
Most financial institutions run task-specific models: one for fraud, one for credit risk, one for churn. Each sits in its own governance lane, its own risk assessment, its own sign-off. PRAGMA's stated architecture collapses that separation. A single shared embedding, the model's internal representation of a customer's financial behaviour, feeds all six tasks at once.
That is a structurally different governance problem, not merely a larger one. If a bias or a data quality issue enters the shared embedding layer, it does not stay contained to one function the way it would in a task-specific system. It potentially propagates into every downstream decision built on top of it, credit scoring and fraud detection and product recommendation simultaneously, through a single point of failure that none of the six task-level teams individually owns.
This is the question a governance framework has to answer for a system like this, and it is a genuine open design choice, not something the paper itself addresses: does accountability get assigned once, at the shared backbone, or separately, at each of the six downstream tasks. Assign it only at the task level and the backbone itself, the thing six decisions actually depend on, has no single owner. Assign it only at the backbone level and task-specific risks, credit scoring's Annex III obligations look nothing like product recommendation's, get flattened into one generic sign-off that fits none of them well.
Where Regulatory Triggers Attach
Mapping PRAGMA's own confirmed task list against the frameworks that would apply to an EU-regulated fintech operating it produces a concrete, checkable picture, not a hypothetical one.
| PRAGMA Task (per Revolut's paper) | Regulatory Trigger | What It Requires |
|---|---|---|
| Credit scoring | EU AI Act, Annex III | High-risk classification: conformity assessment, quality management system, logging. In force from 2 August 2026. |
| Credit scoring, fraud detection | GDPR, Article 22 | Right to human review of decisions with legal or similarly significant effect on the individual. |
| All six tasks, at the operating entity level | DORA | ICT risk management, resilience testing, and incident reporting obligations for the regulated entity running the model. |
| All six tasks, at the embedding layer | GDPR, Articles 5 & 25 | Data minimisation and privacy-by-design obligations apply to the shared representation itself, not only to each task's output. |
The last row is the one worth sitting with. Data minimisation and privacy-by-design are usually assessed per use case, what does this specific product need to know. A shared embedding trained across transactions, app navigation, trading activity, and support interactions for six different downstream purposes complicates that assessment structurally, the representation itself carries more information than any single task strictly requires, by design.
Applying the Accountability Conditions
A useful way to think about what a compliant structure for a system like this would need is the same three conditions that apply to any AI system operating in a regulated product: design-time authority, monitoring mandate, and evidentiary chain.
Design-time authority asks who had standing to decide the backbone's scope, that a single representation would serve credit, fraud, and marketing simultaneously, before it was built. For a shared-backbone model, that decision sits upstream of any single product team, and it is a decision no task-level owner is positioned to make alone.
Monitoring mandate asks who owns watching the backbone itself for drift or bias, as distinct from watching each downstream task's output. A fraud team monitoring fraud outcomes will not necessarily see a bias forming in the shared embedding that has not yet surfaced in fraud metrics but is already present in the credit-scoring output.
Evidentiary chain asks what gets logged to prove, after the fact, that a specific decision, a declined loan, a flagged transaction, was defensible. For a shared-backbone system, that logging arguably needs to trace two layers, what the backbone's representation contained at inference time, and what the downstream task did with it, not just the second layer alone.
None of this is a claim that Revolut lacks these structures. It is a claim about what the structure of a shared-backbone foundation model, as PRAGMA is described in Revolut's own paper, requires of any institution operating one, regardless of who that institution is.
What This Article Confirms, and What It Does Not Claim
References
1. Revolut Research. "PRAGMA: A Foundation Model for Banking." arXiv:2604.08649, April 2026.
arxiv.org
2. Revolut. Written evidence submitted to the UK Parliament inquiry on AI in Financial Services (AIFS0018).
committees.parliament.uk
3. European Union. Regulation (EU) 2024/1689 (EU AI Act), Annex III and Article 5.
4. European Union. General Data Protection Regulation, Articles 5, 22, and 25.
5. European Union. Regulation (EU) 2022/2554 (DORA), ICT risk management provisions.
This article is part of 4iGov's Product Security in AI Agentic Development series. It does not constitute legal or compliance advice, and it makes no claim about Revolut's actual internal AI governance practices, which are not public information. Every figure above is sourced to Revolut's own published paper or its own written evidence to a public body.