Interpolation

Table of Contents

Summary

A term structure is only directly observed at its own pillar tenor points — a bootstrapped curve has no market-quoted value for a date that falls between two pillars, yet a consumer (a cash flow landing on an off-pillar date, a broken date a user adds) still needs a value there. Interpolation is the rule that manufactures that value from the surrounding known points. Two families of interpolation method exist — local and non-local — trading off stability against smoothness, and the choice matters beyond aesthetics: different methods produce different forward rates at the same off-pillar date, so every system consuming a given curve must agree on which method that curve uses.

Detail

Why interpolation is needed

A bootstrapped curve fixes a discount factor (or rate) at each of its pillar tenors and nowhere else. Anything that needs a value elsewhere within the pillar range — pricing a cash flow on an arbitrary date, resolving a broken date a user has added to the forward ladder — must derive it from the pillars bracketing it. This is distinct from asking for a value outside the pillar range altogether, which is extrapolation, a related but separate concept with its own conventions.

Local methods

Local methods use only the immediately bracketing pillars; changing one pillar does not affect distant tenors.

  • Log-linear (linear in log-DF): the discount factor changes by a constant ratio every day within an interval, so daily forward rates are constant within each interval. Simple and stable; the industry default for the short end.
  • Zero-linear (linear in zero rate): linear in \(-\ln(DF)/t\). Daily forward rates change at a constant rate within each interval.
  • Flat forward (step function): the forward rate is held exactly constant within an interval and steps discretely at the interval boundary, rather than merely being locally linear. This is the correct method — not just a convenient approximation — wherever the underlying rate is administratively fixed between boundaries, as with a SOFR OIS curve's short end bootstrapped off FOMC dates: the Fed Funds target genuinely does not move between meetings, so a smoother method would misrepresent the instrument, not just over-fit it.

Both log-linear and zero-linear perform well in low-curvature regimes.

Non-local methods

Non-local methods take into account the full shape of the curve, producing smoother results but introducing the risk that changing one pillar affects distant tenors.

  • Cubic spline: a piecewise cubic polynomial fitted globally. Produces smooth forward curves but can generate oscillations and negative forward rates in extreme cases.
  • Monotone spline: a shape-preserving variant of the cubic spline that prevents oscillations while maintaining smoothness.

Mixing methods and the curve split tenor

A single curve may use different interpolation methods at different tenor ranges — e.g. log-linear at the short end, cubic spline beyond 2Y. A curve split tenor (typically 5Y) separates the short-end and long-end spline segments, preventing a change at one end from propagating to the other. The same split-tenor idea recurs on the volatility side: a volatility surface's default 5-year extent, described in Term Structure Extent, is conventionally reused as its own curve split tenor.

The USD SOFR curve is a concrete instance of this split: a flat-forward step function over the FOMC-dated short end, transitioning to a continuous non-local method (log-linear on discount factors, or a spline) over the longer-dated swap pillars. Mixing the two the wrong way round is a real modelling error, not a stylistic choice: a continuous spline between FOMC dates implies the Fed adjusts rates daily (false), while a flat-forward step between long-dated swap pillars produces jagged, arbitrageable forwards.

In code, the curve split tenor is the split_tenor_code column of ir_curve_bootstrap_configs, and the short-end method is the config's interpolation_method (FLAT_FORWARD_THEN_LOG_LINEAR for the FOMC segment) — see Tenor and Curve Bootstrapping Architecture.

Agreement across consuming systems

It is critical that every system consuming the same curve agree on the interpolation method: different methods produce different forward rates at off-pillar dates, so a mismatch between, say, a pricer and a risk engine reading the same nominal curve produces silently inconsistent results rather than an error.

See also

Emacs 29.3 (Org mode 9.6.15)