Aggregation Currency

An EUR/USD trade sitting in a book whose aggregation currency is GBP will show a GBP FX delta and a GBP interest-rate delta purely as a consequence of the aggregation step itself, not because the trade was ever exposed to GBP in any direct sense. This is treated as a desirable side-effect rather than an artefact to be suppressed: it keeps traders aware of the FX exposure that aggregating across currencies necessarily creates, since that exposure is real and will need to be hedged like any other. CRM risk: recentering and artefacts works through the mechanics in full – recentering the cross-rates matrix into a star shape around the aggregation currency so that a single rate can move without disturbing every other rate reachable through it, the resulting rule that deltas sum to zero across currencies, and the spurious sensitivities and theta effects that the recentering itself can introduce.

That the conversion "generates real risk" is not just an operational observation; it can be made precise. Consider a portfolio holding positions of value \(\theta_i(t)\) denominated in currencies \(C_i\), for \(i = 1, \dots, N\), and let \(C_{\mathrm{agg}}\) be the chosen aggregation currency, with \(S_i(t)\) the stochastic spot rate translating \(C_i\) into \(C_{\mathrm{agg}}\). The portfolio's value in the aggregation currency is

\begin{equation} V_{\mathrm{agg}}(t) = \sum_{i=1}^{N} \theta_i(t)\, S_i(t). \end{equation}

Because each \(S_i(t)\) is itself a stochastic process, any risk metric computed on \(V_{\mathrm{agg}}(t)\) inherits a direct sensitivity to the volatility and correlation structure of the aggregation currency's own FX pairs – an FX delta of \(\partial V_{\mathrm{agg}} / \partial S_i = \theta_i\) for every foreign currency in the book, plus the cross-currency volatility spreads between them. Antal & Koch-Medina push this further, past a first-order sensitivity, to a sharper non-neutrality result that cuts differently across risk measures: for a multi-currency capital position, the sign of Value-at-Risk – and hence the pass/fail outcome of a capital-adequacy test built on it – is invariant to the choice of aggregation currency, but the sign of Expected Shortfall is not, and can flip depending on which currency the position is aggregated in. The asymmetry matters precisely because it is easy to assume the two measures behave alike here; they do not, and a capital-adequacy framework built on Expected Shortfall needs to treat aggregation currency as a genuine methodological choice rather than an arbitrary convention (see Antal & Koch-Medina, "Value-at-Risk vs. Expected Shortfall: Beware of the Aggregation Currency!", SSRN, 2014). A related applied study works through the same dependency for multi-currency Expected Shortfall frameworks directly, comparing how a portfolio's risk transforms under a localised aggregation currency against a centralised one (see UCT Financial Mathematics Team Challenge Research Reports, 2014). The choice of aggregation currency is therefore not an implementation detail free of consequence: it is a genuine methodological parameter of the risk measure itself.

Aggregation currency is normally set equal to a book's functional currency. If a book's traders have hedged their FX exposure correctly, keeping the two aligned keeps the resulting P&L-adjustment noise small, since the risk the aggregation conversion itself generates is then largely offset by hedges already in place for the same functional-currency translation functional currency's own Ledger Sweep performs.

Aggregation currency is not confined to market-risk Greeks, nor is the practice unique to bespoke risk engines: enterprise financial systems build the same target-currency conversion into their core data architecture. Oracle's JD Edwards EnterpriseOne, for instance, exposes an explicit currency-processing API whose AggregationInfo.CurrencyProcessing class defines a static target conversion currency that every calculation over a set of multi-currency fields is compiled against before aggregation, precisely so that rounding and numerical integrity survive the conversion step (see Oracle JD Edwards EnterpriseOne Tools: Currency Processing & Data Aggregation API). SAP's treasury and risk management architecture draws the same distinction at the desk level that this note draws at the book level: local transaction currencies are kept separate from a centralised analytical layer specifically so that FX translation risk can be isolated from operational risk, with local exposures converted into the functional or aggregation currency before consolidated hedging proposals and portfolio VaR are computed (see SAP S/4HANA Cloud for Treasury and Risk Management). Within ORE Studio's own domain, credit exposure profiles are converted to a single accounting currency (GBP in the canonical examples) to measure exposure on a consistent basis across counterparties denominated in different currencies, and cross-currency swap Monte Carlo valuation converts each leg's value to the accounting currency at simulated FX rates to produce one consolidated mark-to-market figure rather than two figures in two currencies that cannot simply be added together.

Reports expose both display currency and aggregation currency as independent, separately-configurable parameters: display currency affects only presentation, while aggregation currency affects the actual risk figures computed. See Presentation Currency for why the two are nonetheless best kept equal in practice, even though nothing enforces that they must be.