CRM risk: recentering and artefacts

Table of Contents

Summary

A cross-rates matrix is not a flat table of independent quotes but a graph of derived dependencies, and that graph topology has a consequence that is easy to overlook until it produces a wrong-looking risk number: no rate in the matrix can be bumped in isolation, because every rate reachable from it through the graph moves with it. Standard regulatory practice for FX risk factors builds on a closely related idea: the ISDA SIMM methodology defines the FX delta risk factor as the relative change of a foreign-domestic spot rate against a single base currency, so that every foreign-foreign rate is represented as the ratio of two such rates (see ISDA SIMM Methodology v2.2ยง2, "FX Risk"). ORE Studio recenters its own cross-rates matrix into that same star shape around the aggregation currency, and this note works through what that recentering buys, what it costs, and where its side-effects surface downstream in a book's risk report.

Detail

Why a single bumped rate is never local

The trouble starts from the CRM's graph structure itself: a cross rate is a derived quantity, computed as a ratio or product of other rates rather than quoted independently, so a bump to one pair necessarily implies bumps to every other pair reachable through it in the graph. Running risk "by crosses" – bumping each quoted cross rate directly, in the order the market happens to quote them – therefore moves many pairs at once for every single bump, which hides how much of, say, an overall USD delta is really attributable to any one cross rather than to the graph coupling between crosses. The fine-grained, per-pair view that a trader actually wants requires switching off the CRM's own spot-rates graph so that a single cross can be moved in genuine isolation; running the two modes side by side and comparing them is itself informative, since the difference between them is exactly the cross-effect the graph coupling was responsible for.

Star-shaping around the aggregation currency

The fix for this coupling is topological rather than numerical: recenter the CRM so that every currency in the matrix connects directly to the aggregation currency, forming a star rather than an arbitrary graph. In a star, bumping the rate on one spoke leaves every other spoke undisturbed, which is exactly the property "per-pair risk" requires and the ungraphed matrix does not have. A cyclic graph cannot be reduced to this shape automatically – there is no general rule for which edges to prune from a cycle without losing information – so the spanning tree has to be constructed deliberately with the aggregation currency as its root, rather than discovered after the fact – unlike the data-driven, unrooted minimal spanning trees academic work on FX network structure fits to observed correlations, where reducing a dense correlation structure to a tree is itself what exposes a market's hierarchical structure to inspection in the first place (see Minimal Spanning Tree graphs and power-like scaling in FOREX networks); the CRM's star is a deliberately-imposed structure rather than a discovered one, but the same principle – that a tree representation is what makes a dense, cyclic correlation structure tractable – motivates both. Once the star is built, a Greek's market movement is simply the percentage move of the ratio (Greek currency)/(presentation currency) between two dates – \(\frac{D_1 - D_0}{D_0}\) – and this can look surprising at first glance: for a EUR/USD deal aggregated in GBP, the movement driving the reported P&L comes from EUR/GBP and USD/GBP, not from EUR/USD directly, because GBP is now the hub every spoke is measured against. A further consequence of the star shape is that deltas sum to zero across currencies: bumping every cross in the star also bumps the aggregation currency itself, so for a EUR/USD deal the USD delta is arithmetically equal to the sum of the GBP delta and the EUR delta, a triangulation identity rather than a coincidence.

Spurious sensitivities from multi-hop spot-date mismatch

Star-shaping removes the coupling problem but does not remove every artefact the underlying graph can introduce. A derived rate may still route through more than two drivers, each with its own spot date, and reconciling those mismatched dates requires interest-rate interpolation along the path rather than a single clean conversion. When a spot-date mismatch survives along a multi-hop path, it can surface as a P&L or interest-rate sensitivity on a currency that has no genuine relationship to the deal at all – a NOK Rho appearing on a SEK deal is the canonical example. This is a wiring artefact of the CRM's own path structure, not a real sensitivity: for Bump & Run or Reset revaluation there is no economic spot-date exposure to speak of, so the sensitivity has to be recognised for what it is and, where attribution requires a clean answer, suppressed rather than reported as if it were real risk.

Theta on the spot roll

Aggregation-currency conversion introduces one further, related artefact once time itself moves rather than a rate. As spot rolls forward day to day, interest accrues on settled cash, and the spot rate used to convert that cash back into the aggregation currency changes with it, so a book can show a P&L difference purely from the passage of time – a genuine theta, but one generated by the aggregation-currency conversion of settled cash rather than by any position decay in the usual sense. This theta on the spot roll is present under a Forward Spot Roll convention, where the settlement date genuinely advances each day, but absent under a Fixed Roll, where it does not; distinguishing the two roll conventions is therefore a prerequisite for attributing this theta correctly rather than folding it into some other Greek.

Risk routing to the right desk

Recentering answers where a rate's risk is measured from; it does not by itself answer which desk within the firm that risk should be sent to. Crosses are conventionally split against whichever currency is more liquid at a given tenor – a choice that can differ between spot and forward tenors for the very same pair – mirroring the CRM's own triangulation paths rather than following the star-shaping recentering directly. A SEK/NOK cross, for instance, is conventionally split by the Forward Desk into its EUR legs but by the Spot Desk into its USD legs, because liquidity conventions differ by desk and by tenor even for the same underlying pair. These routing rules are what ultimately decide whether a given trade's risk lands with a G10 desk or an emerging-markets desk (see currency conventions for the G10/EM distinction the routing rules themselves are built on).

See also

Emacs 29.3 (Org mode 9.6.15)