Multicurve Management

A currency's full interest-rate picture is a curve family: one Funding Curve and a discrete set of Projection Curves, each independently bootstrapped. Reviewing such a family is a distinct activity from constructing one, and it has its own character, independent of how any particular interface might realise it.

Central to that activity is joint visibility: every curve belonging to one family is examined together, in a single view, rather than reconstructed mentally by visiting each constituent curve in turn. Reviewing is also kept apart from constructing. Bootstrapping — selecting pillar instruments, resolving day-count conventions, choosing an interpolation method (see Interest Rate Curves and Interpolation) — is a separate activity with its own inputs and its own failure modes; a review of curves that already exist is a read-only concern, and conflating it with the stateful, error-prone business of construction would blur two activities that are better kept distinct.

Because a party typically holds curve families for many currencies at once, review also extends one level above the family itself: families are grouped for display — by desk, region, or similar operational criteria — without altering the internal structure of any individual family. This grouping concerns families, not the curves within a family, and is therefore orthogonal to how any one family is itself presented.

Finally, each curve's provenance remains inspectable throughout review. This has two parts. The first is the specific set of instruments and parameters used to bootstrap the curve — its curve template, the same pillar-instrument selection introduced in Interest Rate Curves's discussion of pillar instruments and bootstrapping segments, here considered a named, inspectable artefact rather than a one-off input to a bootstrapping run. The second is the curve's full revision history, including time-travel to a prior state and diff-against-previous-version comparison. Absent either part, a reviewer can see a curve's current values but cannot account for why they take those values or how they have changed.

A grid such as the following provides the necessary structure: a two-dimensional lookup with tenor on one axis and curve identity on the other:

┌───────┬──────────────────────┬─────────────────────────┬─────────────┬─────┐
│       │  Discount Rate       │  Collateralised Curve   │  Euribor    │ ... │
│ Tenor │  Date  │  Rate       │  Date   │  Rate         │ Date │ Rate │ ... │
├───────┼────────┼─────────────┼─────────┼───────────────┼──────┼──────┼─────┤
│ S/N   │        │             │         │               │      │      │     │
│ 1W    │        │             │         │               │      │      │     │
│ 1M    │        │             │         │               │      │      │     │
│ ...   │        │             │         │               │      │      │     │
└───────┴────────┴─────────────┴─────────┴───────────────┴──────┴──────┴─────┘

Each row is a tenor label; each column is a curve identity — Funding, Collateralised, EURIBOR, and so on — with one column per curve in the family. Each cell holds an independent (Date, Rate) pair looked up by the (tenor, curve identity) coordinate; no interpolation is implied between columns, so the grid is properly a lookup structure, not a continuous field. This distinction matters for the same reason a curve family itself is not a mathematical surface: curve identity is a discrete, enumerable label, not a second continuous axis alongside tenor. For reviewing a single curve rather than a whole family, the same idea reduces to a plain tenor-indexed table with one (Date, Rate) column, the degenerate case of the grid above.

The family's curves populate the grid's columns, so reviewing the family is reviewing one screen rather than a sequence of screens — joint visibility follows from the layout itself. The grid, as such, exposes no editing or bootstrapping affordance of its own; construction, where it is reachable at all from a surface built on this pattern, sits behind a separate, dedicated workflow rather than behind an editable cell in the grid, keeping review and construction apart. Grouping families for display by desk, region, or similar criteria operates one level above any single family's grid, independently of how that grid is laid out, so the two concerns do not need to know about each other. And a curve template and a full revision history attach to each curve the grid displays, rather than to the grid as a whole, since provenance is a property of a curve — the grid's role is only to make that per-curve property reachable from a family-level view.