Interest Rate Curve Families

Table of Contents

This is the hub note for interest rate curve families. Each linked note is a single focused concept; start here and follow the links.

Summary

A single currency's post-2008 interest-rate picture is rarely one curve: it is a family — one Funding Curve (the discounting anchor) plus a discrete set of Projection Curves, one per floating index tenor. Building that family is not order-free: the Funding Curve must exist before any Projection Curve can be repriced, which is the direct legacy of the pre-/post-2008 split between discounting and projection. Separately, a family is typically stored as one grouped set of time series, displayed as a tenor-by-curve-type grid, and — for onshore-restricted currencies — namespaced by booking jurisdiction rather than by tenor at all. This cluster covers what a currency's full curve picture is, as distinct from how a single curve gets built.

Detail

Concept map

  • The family itselfFunding and Projection Curves (Funding Curve + per-tenor Projection Curves; why curve identity is discrete, not a continuous axis).
  • Benchmark typesInterest Rate Benchmark Types: IBOR vs. RFR (the two kinds of index a Projection Curve can reference, and why the distinction forced multi-curve construction).
  • How you get thereMulti-Curve Construction (single-curve pre-2008 → dual-/multi-curve post-2008; the Funding-Curve-first build order).
  • StorageCurve Sets (Storage Grouping) (grouping small related time series into one series group).
  • A multicurve UIMulticurve Management (a description of a multicurve UI: the requirement that a family be presentable as one whole, and a tenor × curve-identity lookup grid attested elsewhere as one solution to it — not functionality ORE Studio currently implements).
  • Jurisdictional splitOnshore/Offshore Curve Namespacing (pseudo-currency curves, e.g. onshore vs. offshore USD).
  • Single-curve mechanics (companion doc) → Interest Rate Curves (day-count conventions, pillar instruments, interpolation — what each curve in a family individually is).
  • Tenor labelsTime Structures and Tenors.

"Multi-curve" vs. "curve family": methodology vs. object

These two terms are related but not interchangeable, and the cluster uses both deliberately:

  • Multi-curve is the real, external industry term for a methodology — the post-2008 practice of building more than one curve (splitting discounting from projection) rather than one curve doing both jobs. It is an adjective describing an approach: "multi-curve construction", "multi-curve framework", "multi-curve bootstrapping". This is the term used in the academic and practitioner literature (see Further reading below), and this cluster keeps it wherever it names that methodology, so a reader can connect these notes to the papers that define it.
  • Curve family is this cluster's own noun for the object the methodology produces — the specific Funding Curve + Projection Curves bundle for one currency, described in Funding and Projection Curves.

So: you follow the multi-curve methodology (documented in Multi-Curve Construction) to construct a curve family, which Multicurve Management then covers presenting to a user. One is a practice, the second is what that practice builds, the third is how it is reviewed. Within that third page, "Multi Curve Grid" names one specific attested solution, quoting the literal heading on the source screen it was observed on ("Multi Curve") — a proper noun for that one pattern, not a fourth meaning to reconcile with the other two.

Further reading

The papers that define and extend the multi-curve methodology, roughly in the order a reader should approach them:

See also

Emacs 29.3 (Org mode 9.6.15)