Correlation management

Table of Contents

Summary

Correlations are the inputs that turn two driver-leg vols into a derived cross volatility (they play no part in the spot level, which is deterministic — see volatility surface driving). A correlation factor is the per-tenor \(\rho\) between two driver legs sharing a correlation currency (the pivot); with the two leg vols it fully determines the cross ATM vol via \(\sigma_{cross}^2 = \sigma_1^2 + \sigma_2^2 + 2 s \rho \sigma_1 \sigma_2\). Correlations are always held as discrete points and never interpolated — the ATM vols they drive are interpolated, the correlations are not. They are owned and managed in ores.marketdata alongside the CRM.

Detail

  • Role: a correlation \(\rho\) per tenor, between two driver legs that share a correlation currency (the same hub role the pivot plays for spot triangulation). It is supplied at the cross level.
  • Determines the cross vol: with the two driver-leg vols \(\sigma_1, \sigma_2\), \(\sigma_{cross}^2 = \sigma_1^2 + \sigma_2^2 + 2 s \rho \sigma_1 \sigma_2\) (\(s = \pm 1\) per how the shared currency cancels — product vs ratio). Higher correlation can raise or lower the cross vol accordingly.
  • Discrete, never interpolated: this is the load-bearing invariant. Interpolating a correlation has no clean parameter-space meaning, so the system interpolates the ATM vols across tenor but holds the correlations as fixed discrete points. Adding/deleting a driver point propagates to derived pairs; the correlations themselves stay discrete.
  • Ownership: correlations (and the derived vol surfaces they feed) are managed in ores.marketdata — the same authority that owns the CRM. A future correlation-management surface is a sibling of CRM management, sharing the driver/derived graph discipline (cycle detection, no both-ends edits).

See also

Emacs 29.3 (Org mode 9.6.15)