Driver and derived rates
Table of Contents
Summary
The cross-rates matrix distinguishes two roles. A driver is a rate set directly — an independent input. A derived rate is computed from drivers via triangulation; it is a proxy of its driver(s). (Industry synonyms: primary/replica; proxy for derived market data generally.) Drivers should be the most liquid crosses — they have the most accurate, most frequently updated quotes — centred on hub currencies (USD as the universal pivot; EUR for European crosses; JPY for Asia). The single most important rule is the invariant below.
Detail
Choosing the drivers
- Drivers = the most liquid currency crosses (most accurate, most frequently updated), so deriving everything from them keeps the whole matrix accurate.
- Centred on hubs: USD (universal pivot), EUR, JPY, etc.
- Inputs are simple to store:
Currency 1,Currency 2,spot rate,dates.
The invariant: never set both sides
- Users must not set a derived rate directly, nor set a rate in a way that creates a cycle. Editing both a driver and its derived value independently produces an inconsistent graph.
- The system must detect cycles and block their creation.
- Otherwise there is no restriction on which pairs are drivers vs derived — a pair can be a driver for some relationships and derived for others, as long as the overall graph stays a spanning tree (acyclic).
Typed modelling
The driver/derived/proxy relationship — and the per-variant parameters it carries — is the typed-variant case in Polymorphic types over NATS: model each concrete relationship as a typed struct, with a discriminator on the containing entity; never an untyped blob.
See also
- Cross-rates matrix (CRM) — the hub.
- Triangulation and cross rates — how derived rates are computed.
- Volatility surface driving — the same driver/derived pattern for vol.
- Polymorphic types over NATS — typed representation of variants.