From research to real time: Scaling a foundation model for structured data in production

Presented at NVIDIA GTC Berlin by Head of Revolut Research Anton Repushko and Lead Data Scientist Amey Baokar

Just eight months ago at NVIDIA GTC 2026, Revolut introduced PRAGMA – a family of encoder foundation models for banking event sequences, pre-trained on 26 million anonymised user histories, developed in collaboration with NVIDIA.

At the time, it was a research breakthrough: a single pre-trained backbone proving relative gains across six downstream tasks compared to task-specific baselines. However, the immediate question from industry peers wasn't about the model architecture. It was: How do you actually run a foundation model over tens of millions of users, in real time, under strict banking regulations?

Since then, transaction foundation models have moved from research curiosity to industry imperative. Major financial institutions and tech platforms have begun building their own. Yet, the gap between a leaderboard paper and an enterprise production system remains significant.

This blog will set out how Revolut is closing that gap: the data platform we built, the GPU serving stack we optimised, how we navigate compliance necessities, and where the paradigm requires hybrid approaches.

Why you can't just deploy the checkpoint

A traditional production machine learning (ML) model processes a fixed feature vector and outputs a score. Swapping out the model rarely changes the broader software integration surface.

A foundation model operating on event histories is fundamentally different: every inference request requires assembling a user's recent activity across multiple systems, in the exact canonical representation used during training, within milliseconds.

While batch scoring overnight works for daily decisions, online scoring inside transaction-time paths (such as fraud detection and instant credit) demands an entirely different engineering discipline. Three main bottlenecks separate a research checkpoint from a production engine:

• Data delivery: Ingesting and serving tokenised histories at ultra-low latency.
• Serving economics: Making GPU inference fast and cost-effective across dozens of tasks.
• Regulatory governance: Providing immutability, auditability, and fallback guarantees.

Problem 1: Ingesting and serving the canonical representation

PRAGMA was trained on activity originating from half a dozen underlying systems: mutable core ledgers emitting partial events, immutable frontend telemetry, daily warehouse exports, and periodic user snapshots.

Tokenising this data on the fly at inference time – as LLMs or tabular foundation models do – buys flexibility at the cost of high latency. Inside a transaction's critical path, that latency penalty is unacceptable.

To solve this, we built a dedicated internal data platform that ingests customer activity asynchronously, normalises it into PRAGMA’s canonical schema, reconstructs mutable transactions into complete states, and pre-tokenises the history.

By pushing per-user data preparation out of the request path, scoring time becomes trivial: look up the user, fetch their pre-tokenised sequence, and run inference.

Key engineering decisions

• State reconstruction before tokenisation: Core ledger events arrive as partial diffs. Tokenising diffs directly would make model inputs dangerously sensitive to event delivery timing. Our dedicated platform maintains the latest complete state per transaction in an operational store, applying deterministic merge rules before tokenisation occurs.
• Per-channel freshness budgets: Rather than enforcing a single monolithic SLA, which would cause constant pipeline failures, this internal platform sources advance on independent progress markers (e.g., card transactions visible within seconds; user profile changes exports within hours). Lag in one channel never silently corrupts another.
• Ablated hot windows: The platform also maintains a multi-month hot history. Ablation experiments proved that serving a 6-month window versus a full multi-year history produced no material drop in model quality, giving us a mathematically defensible capacity boundary.
• Hard latency SLAs: A scoring request fetches the event timeline and profile snapshot (up to ~1,300 tokens per channel). Our platform targets a double digit millisecond p99 read SLA within a sub-second end-to-end inference budget.
• Behavioural immutability: Tokeniser logic is versioned and immutable. Serving data is physically partitioned by tokeniser version; new versions are backfilled in parallel, validated for parity, and activated via pointer alias.
• Explicit context validation: If required context channels are missing, the system fails fast rather than serving a silently truncated sequence. (For transaction-scoped scoring, the gateway tokenises only the incoming trigger event on the fly and appends it to the user's fetched history).

Today this dedicated internal platform serves an initial footprint of 80M customers, engineered to scale 3×, supporting up to 10,000 events per customer.

Problem 2: High-efficiency GPU serving

Because PRAGMA processes variable-length multi-channel sequences through multi-stage encoder stacks, efficient GPU utilisation requires a dedicated serving fleet decoupled from calling applications. Three core optimisations keep operating costs sustainable:

1. Ad-hoc Low-Rank Adapter (LoRA) swapping

Every downstream task runs on the same shared core backbone, paired with a task-specific LoRA. Because these adapters adjust only 2-4% of the core parameters, they are inexpensive to train, store, and swap on demand. The backbone stays resident in GPU memory; launching or updating a task requires loading a lightweight adapter rather than deploying an entire model instance.

2. Multi-user dynamic batching

GPU utilisation on sequence workloads scales directly with batch size. Our serving layer groups requests to process multi-user batches (e.g., 40 users per execution request). Revolut systems’s read contracts were built natively to handle multi-user batch fetches, serving thousands of batched requests per second smoothly.

3. Automated deployment (AutoDL)

We streamlined downstream model lifecycle management into a standardised experimentation loop: comparing frozen embeddings with linear heads against LoRA fine-tuning across model sizes. The winning configuration deploys directly to the unified infrastructure without custom pipeline engineering.

This infrastructure underpins AutoDL – an internal, self-service platform, enabling teams to handle dataset selection, fine-tuning, evaluation, and deployment on the shared backbone without managing underlying ML infrastructure.

Problem 3: Regulatory compliance and interpretability

Deploying foundation models in regulated financial environments understandably requires deliberate risk stratification:

1. Deploying where ready: We prioritise high-impact operational domains with immediate feedback loops – such as real-time subscription detection, card abuse prevention, and personalised in-app recommendations.
2. Deterministic foundations: For high-stakes decisions, regulatory approval demands strict reproducibility. Versioned tokenisers, immutable input states, full decision audit trails, and per-feature attribution are built directly into the platform. Additionally, using frozen backbone embeddings paired with linear decision heads yields an inherently interpretable shallow classification layer.

Production impact and multi-model paradigms

While in production, PRAGMA currently powers multiple live services:

• Real-time subscription and recurring-payment detection inside card processing flows
• Instant credit decisioning
• In-app product recommendations, moving from offline batch scoring to real-time ranking

Knowing where the paradigm ends: Hybrid modelling

While event-sequence models excel at capturing historical behavioural patterns, they encounter clear boundaries in scenarios such as cold-start users (new applicants with no history) and non-sequential tabular data (such as external credit bureau records).

To solve this, we complement PRAGMA with STRIDER, developed in cooperation with The Banking Analytics Lab, at Western University and the University of Southampton. STRIDER is an internal tabular foundation model pre-trained purely on structured data, primarily from Revolut datasets across multiple countries with a primary focus on credit risk and fraud tasks.

When benchmarking credit decisioning performance across thin-history users, combining representations yielded clear performance gains. By combining event-sequence representations with tabular foundation models, the system models internal behavioural context alongside external credit structures without forcing a single architecture to handle both.

Five key lessons for production foundation models

1. A foundation model in production is a data platform first, and a model second. The majority of production engineering goes into state reconstruction, token caching, and serving pipelines.
2. Tokenise once, serve everywhere. Push all non-decision-dependent per-user transformations out of the real-time request path.
3. Behavioural immutability is mandatory. Immutable tokeniser versions and deterministic input pipelines are prerequisites for regulated decision-making.
4. Adapter-based serving drives sustainable economics. A single resident backbone with hot-swappable 2-4% adapters drastically lowers the marginal cost of adding new use cases.
5. Embrace multi-model architectures. Sequence models, tabular models, and graph networks each have distinct strengths. Combine model families rather than stretching one backbone beyond its natural design boundaries.