Market risk · Systems

FRTB for Engineers: What a Market Risk Capital Engine Actually Computes

A systems view of the Fundamental Review of the Trading Book: Expected Shortfall with liquidity horizons, NMRF stress scenarios, the Default Risk Charge, the Sensitivities-Based Method, and the PLA and backtesting tests that decide whether a desk may use its internal model.

Shreejit Verma · · 11 min read

The Fundamental Review of the Trading Book (FRTB) is the Basel Committee's rewrite of how banks capitalize market risk. It is part of the Basel III final reforms that the industry usually calls Basel IV, and it is codified in the MAR chapters of the consolidated Basel Framework. Most explanations are written for risk managers. This one is written for the engineers who have to build the engine: what it computes, why each piece is expensive, and where the hard problems are.

Everything here comes from the public Basel text. It describes the regulation, not any particular bank's implementation.

Two approaches, both mandatory to compute

FRTB gives banks two ways to compute capital for each trading desk:

From an engineering standpoint this means two engines with very different shapes. SA is a large, deterministic aggregation problem. IMA is a scenario revaluation problem followed by many tail-statistic aggregations. Both run daily, both must be reproducible for audit, and the eligibility tests tie IMA output back to front office P&L.

The Standardised Approach: three charges

SA capital is the sum of three components.

1. Sensitivities-Based Method (SBM)

SBM covers seven risk classes: general interest rate risk (GIRR), credit spread risk for non-securitisations, for securitisations outside the correlation trading portfolio, and for the correlation trading portfolio, plus equity, commodity, and FX. Within each class there are three risk measures: delta, vega, and curvature.

The computation is a fixed hierarchy:

  1. Compute each sensitivity to the prescribed risk factors (for GIRR, a set of tenors per curve and currency).
  2. Multiply by the prescribed risk weight to get a weighted sensitivity.
  3. Aggregate within each bucket using prescribed correlations: roughly K_b = sqrt(max(0, sum_k WS_k^2 + sum_k sum_l rho_kl WS_k WS_l)).
  4. Aggregate across buckets with cross-bucket correlations gamma_bc.
  5. Repeat the whole aggregation under three correlation scenarios: medium (the prescribed values), high (correlations scaled by 1.25 and capped at 1), and low (max(2 rho - 1, 0.75 rho)). The charge is the largest of the three totals.

Curvature adds an up-shock and a down-shock full revaluation per risk factor, minus the delta-implied move, so it is the one SBM piece that needs pricing calls rather than just sensitivities.

Why it is hard: the arithmetic is simple, but the volume is not. A large bank produces millions of sensitivities per day, and the correlation structure means every bucket is a dense quadratic form. The work is dominated by data movement: grouping sensitivities by risk class, bucket, and risk factor, building or caching the correlation matrices, and evaluating three scenarios. The productive design choices are a columnar layout keyed by (risk class, bucket, factor), computing all three correlation scenarios in a single pass over the data instead of three, and a fixed reduction order so the same inputs always produce bit-identical capital.

2. Default Risk Charge (DRC)

The SA DRC captures jump-to-default risk on credit and equity positions. For each position the engine computes a gross jump-to-default (JTD) amount from loss-given-default, notional, and current P&L. Longs and shorts are then netted per obligor subject to seniority and maturity rules, and the net amounts are aggregated by bucket with a hedge benefit ratio that limits how much shorts can offset longs. Credit-quality-based risk weights convert net JTD into capital.

3. Residual Risk Add-On (RRAO)

RRAO is a deliberately blunt charge for risks the sensitivities do not capture: 1.0% of gross notional for instruments with exotic underlyings, and 0.1% for instruments with other residual risks such as certain path-dependent or multi-underlying payoffs. The computation is trivial. The engineering problem is classification: deciding, instrument by instrument and auditably, which bucket applies.

The Internal Models Approach

Expected Shortfall with liquidity horizons

IMA replaces Value-at-Risk with Expected Shortfall (ES) at 97.5%, calibrated to a period of significant stress. Every risk factor is assigned a liquidity horizon of 10, 20, 40, 60, or 120 days, reflecting how long it would take to exit or hedge the exposure. ES is computed on a 10-day base horizon and then scaled by a cascade over the horizons:

ES = sqrt( ES_T(P)^2 + sum_{j>=2} ( ES_T(P, j) * sqrt((LH_j - LH_{j-1}) / T) )^2 )

T          = 10 days (base horizon)
ES_T(P)    = ES with all risk factors shocked
ES_T(P, j) = ES with only factors whose liquidity horizon is at least LH_j shocked

Stress calibration adds a second layer. The bank picks a reduced set of risk factors that has a long enough history to cover the stress period and that explains at least 75% of the full model's ES. ES is then computed on the reduced set over the stress period and scaled up by the ratio of full-set to reduced-set ES over the current period, with that ratio floored at 1.

Finally, ES is computed both on the whole portfolio and separately per broad risk class with no diversification across classes, and the two are blended 50/50. Count the runs: five liquidity-horizon subsets, times three calibrations (reduced set in stress, reduced set now, full set now), times the unconstrained portfolio plus five risk classes. That is on the order of ninety ES evaluations per desk per day, before any what-if analysis.

Why it is hard, and how to make it cheap: each ES evaluation needs a P&L vector across the scenarios, and producing those vectors means revaluing the portfolio under each scenario. Revaluation is the expensive part, and it should happen once. If the engine stores a P&L vector per position (or per position and risk factor subset) for each scenario set, every one of the ninety ES numbers becomes an aggregation: sum the right vectors, then average the tail. With a few hundred scenarios the tail itself is a handful of observations, so a selection algorithm such as std::nth_element beats a full sort, and the whole aggregation layer becomes memory-bandwidth bound rather than compute bound. Grid compute belongs on the revaluation side; the aggregation side wants contiguous float vectors, SIMD-friendly loops, and no per-scenario allocation.

Non-Modellable Risk Factors (NMRF)

A risk factor may only enter the ES model if it passes the Risk Factor Eligibility Test (RFET): at least 24 real price observations over the previous 12 months with no 90-day window containing fewer than four, or at least 100 observations over the 12 months. Factors that fail are non-modellable and are capitalized separately through a stressed scenario per factor. Idiosyncratic credit and equity NMRFs aggregate with zero correlation; the rest aggregate with a correlation of 0.6.

Why it is hard: RFET is a data-engineering problem, not a modeling one. It needs an observation history per risk factor built from trades, committed quotes, and vendor data, mapped consistently onto the bank's risk factor taxonomy, and recomputed as the window rolls. A time-series store designed for tick data (kdb+ is common here) and a careful definition of what counts as a real price do most of the work. The capital impact of a factor flipping between modellable and non-modellable can be large, so the lineage behind each observation has to be inspectable.

The IMA Default Risk Charge

Under IMA, default risk is a separate model: a one-year, 99.9% Value-at-Risk of default losses, simulated with correlated defaults driven by at least two types of systematic factors, with a probability-of-default floor of 0.03%. Structurally it is a Monte Carlo credit portfolio model, and it is usually the most compute-hungry single piece of the IMA stack.

Staying eligible: backtesting and P&L attribution

IMA approval is conditional. Each desk is tested on its last 250 trading days.

Why it is hard: PLA is where the architecture shows. RTPL and HPL only line up when the risk engine and front office price the same positions off the same market data snapshot, the same curves, and compatible models. Every difference in interpolation, cut time, or risk factor mapping shows up as an attribution break. The engineering that keeps desks green is mostly plumbing: shared market data snapshots with explicit timestamps, a single risk factor taxonomy, and break-explain tooling that can decompose a gap between RTPL and HPL by risk factor so it can be fixed instead of argued about.

Design principles that survive an audit

FRTB is often described as a modeling change. For the people building it, it is just as much a systems change: more scenarios, more aggregation, stricter reproducibility, and a hard link between risk and front office P&L. That combination rewards the same instincts as low-latency trading systems: know where the time goes, keep data contiguous, and make the fast path boring.

References