Most risk programmes do not fail on the modelling; they fail on the four systems that have to agree before a model can run. The lakehouse pattern - one governed copy of data feeding every workload - is how modern risk platforms end that war.
The pattern that keeps repeating
Every major risk programme we see shares the same failure mode: the models are fine, the data underneath them is not. Market data arrives from one vendor, positions from the trading system, collateral from treasury, all with different schemas, latencies and quality profiles - and the model layer spends its life reconciling instead of computing. The lakehouse pattern exists precisely to end that reconciliation tax.
What a lakehouse actually buys a risk function
A lakehouse (Delta Lake on Databricks, in the configuration we deploy most often) gives risk teams three properties that legacy warehouse architectures struggle to combine:
- One copy of the data, many workloads. The same governed tables feed Monte Carlo simulation, stress testing, regulatory reporting and the dashboards leadership reads. No extracts, no shadow copies, no "whose number is right."
- ACID transactions with time travel. Every table state is versioned. When a supervisor asks "what did your VaR engine consume on 31 March?", the answer is a query, not an archaeology project.
- Separation of compute. A nightly full-revaluation fleet, a real-time streaming cluster for intraday indicators, and ad-hoc analyst SQL each scale independently - one platform, three cost profiles.
Where it shows up in the FRTB world
FRTB is, at its core, a data-granularity regulation. The risk-factor eligibility test, five-year stressed windows and desk-level P&L attribution all demand trade-level lineage from source system to risk factor. Databricks' own financial-services pattern - and its public Value-at-Risk accelerator - demonstrates the shape: positions and market data landed in Delta, risk-factor mapping enforced through Unity Catalog's governance layer, simulation fleets scaled on demand, results written back as queryable, auditable tables. Lakebase extends the pattern toward real-time operational data, closing the gap between the trading system's view of a position and the risk system's.
Governance is the multiplier, not the compute
The banks that get real value from this stack win on governance. Unity Catalog - unified lineage, fine-grained access control and audit across all workspaces - is what turns "we have the data somewhere" into "here is the lineage of the number on the board report." In model-risk terms, it operationalises the 2026 interagency guidance's expectations: documented data lineage, controlled model inputs, reproducible runs.
Our implementation view
We build the risk layer in three tiers: an ingestion tier with schema-enforced, quality-gated pipelines from every source system; a modelling tier where simulation engines run as versioned, parameter-controlled jobs; and a decision tier exposing indicators, limits and KPIs to the business. The lakehouse is the connective tissue - but the architecture only pays off when the data contracts at each tier are explicit. Compute is rented; discipline is built.