Everyone in banking is talking about artificial intelligence and, more specifically, large language models. However, the more interesting AI shift happening underneath that conversation is the arrival of foundation models that are not built on language at all. Rather, they are built on the structure of the data the bank actually runs on: the relational tables behind every trade, account, and counterparty; and the mix of audio, video, numbers, and text that analysts live in.
There are two classes of these models that matter:
Relational Foundation Models learn directly on the multi-table databases the bank already has, with no manual feature engineering. These models are much closer to production readiness.
Multimodal Financial Foundation Models fuse earnings call audio, policy conference video, financial statements and market data into one model. These models are more ambitious, and still reside largely in the lab.
In 2025, in fact, researchers at Stanford and SAP demonstrated a relational foundation model with 22 million parameters that reached 93 percent of fully supervised performance on classification tasks with no task-specific training, handily beating a general-purpose language model with 27 billion parameters, which reached 84 percent.
The catch is that both types of model only work on a data platform that can serve an entire relational database as a graph and land every modality in one place to support the throughput levels required for training models. That is, both types of models are ideally suited to a platform like the VAST AI OS.
Relational Foundation Models: The Problem They Solve
Almost everything a bank predicts sits in relational databases. Trades, positions, accounts, counterparties, instruments, payments, and customers all live in separate tables joined by keys. Real-world enterprise data such as financial transactions, supply chain records, customer interactions and electronic health records is predominantly stored this way.
Traditional machine learning cannot use that structure directly. A data science team has to flatten the tables into a single training matrix and hand-craft aggregate features - how many trades in the last 30 days, average exposure per counterparty, and so on. That feature engineering is most of the work, it is slow, and it throws away structure.
However, a technique called relational deep learning removes that step by treating the whole database as a single, heterogeneous temporal graph and learning on it directly. This reduces the human effort and engineering complexity of pipelines that rely on manually flattening schemas.
Picture a counterparty-risk or churn use case. The relational foundation model sits next to the bank's existing databases. It ingests the live schema, the transactions table, the accounts table, the counterparty master, and the instrument reference data as a single temporal graph. A risk analyst asks a question by pointing at an entity and a moment in time (“What is the probability this counterparty defaults in the next 90 days?”) and the model answers in one forward pass using the relational context. There is no feature pipeline and no bespoke model build.
There is also research and discussion about the applicability of relational foundation models for trading use cases.
How Relational Deep Learning Works
The key shift with relational deep learning is that the database becomes a graph. Every row is a node, every foreign key is an edge, and time columns make the graph temporal so the model can respect what was known at any given moment.
The reference pipeline looks like this:
This temporal cutoff discipline is built into the benchmark. Models train on data up to a validation timestamp and are tested only on rows after a later cutoff, with future data hidden during inference to prevent leakage. That matters for a bank because point-in-time correctness is the difference between a real backtest and a fantasy one.
Whereas early approaches to relational deep learning used graph neural networks, which struggle with long-range dependencies and complex structure, later approaches use a transformer-based model architecture. The Relational Graph Transformer decomposes each node into five components — features, type, hop distance, time, and local structure — then combines local attention over sampled subgraphs with global attention to a set of learnable centroids that carry database-wide context.
The major performance breakthrough is a model that generalizes across databases with no retraining. The relational transformer model cited above was pretrained on a spread of relational datasets covering tasks such as churn and sales forecasting, then reached its 93 percent of fully supervised AUROC on unseen binary classification tasks in a single forward pass. Fine-tuning then takes it to state-of-the-art level with very few examples. It does this by attending at the cell level to represent foreign-key relationships directly, so it can reason across the whole database without manual aggregation.
Although relational foundation models are just beginning to be commercialized, a related concept, tabular foundation models, are already in the market and proving immensely valuable for more targeted data where the necessary information can all fit in a single table.
Multimodal Financial Foundation Models: The Problem They Solve
A human analyst does not read one data type at a time. They listen to the tone of a CFO on an earnings call, watch a central banker at a policy conference, read the balance sheet, and watch the tape - and then fuse all of it into a single view. Multimodal financial foundation models aim to do the same, combining tabular data such as balance sheets and stock prices along with audio from earnings calls and financial podcasts, charts, video, and more - all in service of applications such as search, robo-advisory, compliance, auditing, and trading.
Picture a research or trade surveillance use case. The model continuously ingests the earnings call audio feed; the policy conference video feed; the fundamentals from filings; and the live market data. It then aligns them on a single timeline, and produces a fused signal, a volatility forecast, a risk flag, or a draft analyst note with the tone and the numbers reconciled. For surveillance and compliance, the same fusion spots a mismatch between what management says and what the tape does (e.g., management sounds upbeat on the call while unusual selling happens around it, suggesting possible insider trading).
How Multimodal Financial Models Work
The general pattern is one encoder per modality feeding a fusion layer. Take the example of the RiskLabs research project, which:
Takes earnings call audio and transcripts, daily news, and time series data.
Encodes each through a dedicated encoder
Extracts audio embeddings with Wav2vec2 passed through a multi-head self-attention layer
Then runs multi-task learning to predict volatility across several horizons, as well as Value at Risk, at the same time.
The video element is real, too, tracing back to work on financial prediction from monetary policy conference videos.
What’s new and interesting over the past year or so is to stop encoding the modalities separately and instead interleave them in one sequence. Recent research shows a model that transforms the inputs into a unified sequence of embeddings, interleaving news articles with time series embeddings spaced by the number of days between events. The model exploits the language model's rotary positional encodings
to reflect the real temporal order rather than bolting on time embeddings at the input. It introduces a pretraining objective called SALMON (salience-aware language modelling over interleaved modalities) and is the closest thing yet to the single unified embedding space.
Notably, however, these models aren’t yet on par with human analysts. What exists today is a set of strong narrow predictors that fuse two or three modalities. A single general model that ingests audio, video, tables and tick data in one embedding space, and reasons like an analyst, is an active research agenda but is not yet a proven product (at the time of writing).
A Side-by-Side Comparison
Relational foundation models | Multimodal foundation models | |
|---|---|---|
Core input | Multi-table relational databases as one temporal graph | Earnings audio, policy video, fundamentals, market data fused on a timeline |
Maturity | Benchmarks, commercial vendors, zero-shot results | Narrow predictors today; general model still in the lab |
Best first use case | Churn, credit and counterparty risk, fraud, next-best-action | Volatility and risk forecasting, research automation, surveillance |
Infrastructure demand | Serve a whole database as a graph, random-access read heavy, synthetic-data pretraining by the vendor, fine-tuning on real data in place | Land every modality in one namespace at training throughput |
Defining the Right Infrastructure for Financial Foundation Models
Both classes of model fail on fragmented storage and both reward a single high-performance substrate. The relational case needs an entire multi-table database held where small subgraphs can be read at low latency and high concurrency while the tables keep updating. Because real financial data cannot leave the building, these models also require that the vendors creating them have the capacity to generate and store large synthetic databases for pretraining - itself a heavy data and compute workload that has to land somewhere.
At runtime, emerging confidential computing frameworks, like the VAST DataEnclave, should offer some relief on that front. Because models run directly on the high-performance clusters where the bank’s data already resides, latency is minimal. Attestation and encryption keep both model weights and data private to the parties (i.e., model vendors and customers, respectively) that own them.
The infrastructure demand for multimodal foundation models is different from the relational case, but points in the same direction. Organizations are landing many heterogeneous, high-volume modalities and feeding them to GPU training and inference at throughput. They have to live in one namespace so the timeline alignment and the fusion are even possible. Fragmented, siloed storage makes this workload impractical before the model is even built.
Generic high-speed “AI storage” won’t cut it because AI workloads are never generic. In the case of the models discussed in this post:
Quants and risk teams are running custom models directly on a bank’s databases and media, so the platform must be able to serve both without sacrificing performance.
Because the data in question is so sensitive and/or valuable, it cannot leave the premises. To maximize both security and performance, AI models should run securely and confidentially within the same platform.
Very likely, there are or will be a team of AI agents accessing sensitive data to execute tasks and/or continuously improve model performance. Agents need systems that can handle many concurrent queries, as well as strong sandboxes to ensure they adhere to policy limitations.
Especially for the banking industry, data freshness is critical to delivering accurate outputs. An AI data platform should be able to execute data pipelines (ingest, sync, transform, and land in the relevant stores) in real time so agents and analysts have immediate access.
These are the types of workloads the VAST AI OS is designed to handle. If you want to learn more, please read the collection of resources below and then reach out. We’re always happy to work with and learn from our customers and the industries we serve.
