FRTB capital does not add up
The charge is the highest of three totals, low, medium and high correlation, summed across every risk class in the trading book. That choice is made at the top node, and everything below it is conditional on it. A desk's standalone number is not its contribution. The capital cost of a hedge is not a property of the hedge. Hedge across buckets and the low-correlation total rises whatever the sign of the trade; if low binds, the hedge cuts risk and costs capital.
Most firms find this out when the monthly per-desk figure lands. The trade is done and the question has moved on. That is what we built ARMS RiskEye to change.
One memory
Everything that produces the number lives in one memory: positions, market data, the ARMS pricing and risk engine, front office sensitivities and FRTB classifications including DRC, and the hierarchy they hang on. Aggregation platforms hold the sensitivities. RiskEye holds the positions that produced them, so a what-if is a repricing, not a rescaling of yesterday's vector. Change size, maturity, strike, currency, bucket, anything, and the FRTB metrics are recomputed for that position and re-aggregated. The tree graph re-aggregates only the nodes the change touches, which is what makes a non-additive firm-wide measure interactive.
Three trees, one top node
RiskEye computes all three correlation trees in full. The top node picks the live one. Drill into any node and you see the binding figure and, beside it, the two that are not. If a what-if flips the top, every node re-bases and you see the new tree at once. A few percent between the binding scenario and the runner-up means the firm is one trade from re-basing; a desk that can see that margin trades differently. Curvature, with its sign function and its dependency on full up and down repricing, gets the same treatment because the repricing happens in the same memory.
The rulebook applies at any node of any hierarchy. Legal entity, desk, book, trader, product, or a grouping you invent for the question in front of you. Same aggregation, same maximum, in as many dimensions as you need.
Aggregator, engine, or both
Where your systems deliver, RiskEye is a regulatory aggregator and nothing more: it applies the rules to the sensitivities your front office already stands behind. Where the delivery is incomplete in FRTB terms, and one always is, ARMS calculates the missing sensitivities from the positions and its own market data and fills the gap in the same tree. FRTB programmes are gated by their slowest upstream system. One asset class that cannot produce vega at the required granularity holds up the number the whole firm owes. That gap closes in the aggregation layer, without a project. And because the engine is independent, PV, VaR and scenarios on ARMS market data come with it, as a challenger to the front office figures.
Why now
Go-live is 1 January 2027, four months out. The Commission's June delegated act adds a multiplier and operational relief for three years, after which the rules are revisited. The UK goes live in January with internal models pushed back a year; the US has a proposal and no date. A hardcoded 2019 rulebook is now a version per jurisdiction with an expiry date on each. Rules applied at aggregation time, configurably, are the only implementation that reaches 2030 without a rewrite.
Where to start
Take a hedge you are considering this week. Ask what it does to your FRTB capital and time the answer. Not the batch: the interval between the question and a figure you would defend to your CRO with the market still open. If that interval is days, FRTB is reporting your capital. It is not helping you manage it.