FRTB in the EU: Preparing for the 1 January 2027 Market-Risk Go-Live

The one-year deferral of FRTB is being read across trading-book firms as a reprieve. It is nothing of the sort. It is a data and calculation programme with a fixed end date, and the clock is already running.

The European Commission has postponed the point at which own-funds requirements for market risk start to bind, and the new date is 1 January 2027. Most of the commentary treats that as breathing room. The honest reading is narrower: the policy argument is over, the go-live is fixed, and everything between here and there is engineering. If your firm has a trading book of any size, the work the deferral buys you is not lobbying time. It is the time you need to source the sensitivities, map the risk factors, prove the numbers reconcile, and stand up the reporting the requirement will demand from day one.

What actually moves on 1 January 2027

The Fundamental Review of the Trading Book has been present in EU law for years, but only as a reporting obligation. Under the previous regime, firms computed FRTB figures under the alternative standardised approach and reported them; the numbers did not set capital. What changes at go-live is that market-risk own-funds requirements start to bind. The same calculation that has been a reporting artefact becomes a capital number a supervisor will hold you to.

The chronology matters, because it tells you how firm the date is. CRR3 — the banking package, Regulation (EU) 2024/1623 — set the application of the market-risk own-funds requirements and gave the Commission a delegated power, under Article 461a, to postpone or adjust them for a limited period to protect the international level playing field. The Commission used that power once to move the date to 1 January 2026, then again to move it by a further year to 1 January 2027. Then, on 4 June 2026, it did something different. Rather than delay a third time, it adopted a delegated regulation introducing a targeted multiplier and a set of operational relief measures that apply for three years, from 1 January 2027 to 31 December 2029, designed to hold EU market-risk capital close to pre-FRTB levels while other major jurisdictions catch up.

Read that carefully. The date did not move again. The relief changes the calibration — how large the resulting capital number is — not the requirement to produce a defensible number in the first place. A firm that cannot calculate the charge cannot benefit from a multiplier that scales it. The build is unavoidable, and it now belongs on the 2026 board technology risk register as a dated delivery, not a watching brief.

The data is the hard part, not the formula

The alternative standardised approach is built on the sensitivities-based method. For every position, you compute sensitivities to prescribed risk factors — delta for first-order exposure, vega for volatility, curvature for the second-order move — then weight, bucket and aggregate them. The aggregation is deterministic. Anyone can code it in an afternoon. That is not where firms fail.

They fail on the inputs. Each sensitivity has to be attached to the correct risk factor, that risk factor mapped to the prescribed bucket, and that bucket assigned the prescribed risk weight. The sensitivities have to be sourced consistently across every desk, reconciled against front-office pricing, and traceable back to the position that produced them. This is a lineage problem before it is a capital problem: you are asserting a regulatory number, and you have to be able to show where each component came from and that it means the same thing on Monday as it did on Friday. Firms that run several pricing libraries across desks, or that compute sensitivities inconsistently between the front office and the risk engine, discover the gap late — usually when the two numbers refuse to reconcile in a dry run. Sourcing and reconciling that data across the trading estate is the critical path, and it is measured in quarters, not weeks.

The calculation logic, made concrete

The mechanics are worth making explicit, because they tell you what the data has to support. Within a bucket, you combine the weighted sensitivities using a prescribed intra-bucket correlation; across buckets, you combine the bucket-level charges using a prescribed cross-bucket correlation. Both aggregations sit under a square root, and the regulation prescribes a fallback where the term under the root turns negative. The skeleton below shows the delta risk charge for a single risk class. It is deliberately un-calibrated — the risk weights and correlations are placeholders — because the structure is the point, and the official tables are what you plug in once the data feeding it is trustworthy.

"""
Sensitivities-based method (SbM): delta risk-charge skeleton.
Illustrative structure for one risk class under the FRTB standardised
approach. Risk weights and correlations here are placeholders — plug in
the calibrated regulatory tables before this feeds anything that binds.
"""
from math import sqrt
from itertools import combinations
from collections import defaultdict


class Sensitivity:
    def __init__(self, bucket, risk_factor, s_k, rw_k):
        self.bucket = bucket            # prescribed bucket the factor maps to
        self.risk_factor = risk_factor  # e.g. a specific tenor on a curve
        self.s_k = s_k                  # net delta sensitivity
        self.rw_k = rw_k                # prescribed risk weight

    @property
    def ws(self):
        # Weighted sensitivity WS_k = RW_k * s_k
        return self.rw_k * self.s_k


def bucket_charge(sensitivities, rho):
    """
    Within-bucket aggregation:
        K_b = sqrt( max(0, sum WS_k^2 + sum_{k!=l} rho_kl * WS_k * WS_l) )
    Also returns S_b, the simple sum of weighted sensitivities in the bucket.
    """
    total = sum(s.ws ** 2 for s in sensitivities)
    for a, b in combinations(sensitivities, 2):
        total += 2 * rho(a, b) * a.ws * b.ws
    return sqrt(max(0.0, total)), sum(s.ws for s in sensitivities)


def delta_charge(sensitivities, rho, gamma):
    """
    Across-bucket aggregation:
        Delta = sqrt( sum K_b^2 + sum_{b!=c} gamma_bc * S_b * S_c )
    When the term under the root is negative, the regulation prescribes an
    alternative in which each S_b is capped to the interval [-K_b, K_b].
    """
    by_bucket = defaultdict(list)
    for s in sensitivities:
        by_bucket[s.bucket].append(s)

    K, S = {}, {}
    for bucket, items in by_bucket.items():
        K[bucket], S[bucket] = bucket_charge(items, rho)

    buckets = list(by_bucket)

    def aggregate(s_vals):
        total = sum(K[b] ** 2 for b in buckets)
        for b, c in combinations(buckets, 2):
            total += 2 * gamma(b, c) * s_vals[b] * s_vals[c]
        return total

    total = aggregate(S)
    if total < 0.0:
        # Fallback: cap each S_b to [-K_b, K_b] and recompute.
        S = {b: max(-K[b], min(K[b], S[b])) for b in buckets}
        total = aggregate(S)

    return sqrt(max(0.0, total))


if __name__ == "__main__":
    # Toy portfolio — three net sensitivities across two buckets.
    book = [
        Sensitivity(1, "EUR-2Y", 12000.0, 0.017),
        Sensitivity(1, "EUR-5Y", -8000.0, 0.015),
        Sensitivity(2, "USD-5Y", 5000.0, 0.015),
    ]

    # Prescribed correlations — placeholders standing in for the tables.
    def rho(a, b):
        return 1.0 if a.risk_factor == b.risk_factor else 0.60

    def gamma(b, c):
        return 0.50

    print(f"Delta risk charge: {delta_charge(book, rho, gamma):,.2f}")

Nothing in that is exotic. That is exactly the point. The engineering effort does not go into the arithmetic; it goes into guaranteeing that every Sensitivity handed to it is correct, complete and reconciled. Get the objects right and the number falls out. Get them wrong and you have a precise answer to the wrong question.

Where the internal-model firms fail

Firms fall into three camps. The simplified standardised approach is open to smaller trading books below the prescribed size thresholds. The alternative standardised approach is the workhorse. The alternative internal model approach is available only with supervisory permission, and it carries the tests that sink programmes. Two matter most. The profit-and-loss attribution test asks whether the risk model’s P&L tracks the front office’s actual P&L closely enough; desks that fail it lose model approval and fall back to the standardised charge, often at materially higher capital. The risk-factor eligibility test asks whether each risk factor has enough real, observable price data to be modelled at all; factors that fail become non-modellable and attract a punitive add-on. The June 2026 relief softened both tests for the transitional period, but softened is not removed — the data-quality bar behind them is still the thing you cannot fake in the final quarter.

The practical consequence is that even a firm with no intention of seeking internal-model permission still has to build and run the standardised calculation for every desk, and a firm that does seek it has to prove, with historical data, that its desks pass tests it may only be able to fail once before losing approval. Neither is a year-end exercise.

Using the runway

The firms that will be comfortable in January 2027 are the ones treating the second half of 2026 as the data build, not the deadline. That means a complete inventory of trading-book risk factors and their bucket mappings; a single, reconciled source of sensitivities across desks; a dry run of the full charge against a live book, with the reconciliation breaks logged and chased; and a reporting path that produces the number on the regulatory cadence rather than heroically each quarter-end. The output has to survive the same scrutiny as any other board-level risk report — traceable, repeatable, and explicable to someone who did not build it. Where the programme touches the board’s stated tolerance for model and data risk, it should be read against the firm’s technology risk appetite, not treated as a purely technical delivery.

The multiplier and the relief measures are a gift the Commission handed EU banks to soften the capital impact. They do nothing for the firm that arrives at go-live unable to produce a clean number. A deferral spent debating the calibration rather than building the data is not runway. It is the same cliff, one year closer.