Extrapolation

Table of Contents

Summary

Where interpolation fills a gap between two known term structure points, extrapolation answers a request for a date outside the range those points cover altogether — before the first pillar, or beyond the last. A defined policy for both directions is necessary because a term structure's pillar range is finite by construction (see Term Structure Extent for how far it goes by curve type), while requests for a value can, in principle, fall anywhere. The two directions are treated asymmetrically: before the start, genuine extrapolation is used; beyond the end, the system flattens — holds the last known value constant — rather than extrapolating, and only extrapolates beyond the end in rare, explicitly justified cases.

Detail

Why a policy is needed at all

A term structure is constructed from a finite set of pillar points and has no market-observed value outside that range. Left undefined, a request for such a value would either fail outright or silently return an arbitrary result depending on whichever code path happened to handle it. Neither is acceptable: the system must have an explicit, documented answer for "what happens if someone asks for a point before the curve starts, or after it ends" — the same way interpolation gives an explicit answer for a point falling between two known ones.

Before the start: extrapolate

For a date earlier than the term structure's first pillar, the convention is to extrapolate — derive a value by continuing the curve's near-end behaviour backward. This is the more permissive of the two directions, reflecting that requests for very-near-term values (e.g. today, or a date just before the first liquid pillar) are routine rather than exceptional.

Beyond the end: flatten, not extrapolate

For a date beyond the term structure's last pillar, the default is to flatten — hold the last known value constant — rather than to extrapolate. Genuine extrapolation beyond the end is reserved for rare, explicitly justified cases, not applied by default. This asymmetry is deliberate: extrapolating forward from a curve's long end would manufacture a value with no basis in any observed point, which is a materially different risk from extending near-term behaviour backward by a short distance. Flattening does not fail the request and does not fabricate a trend — it is the conservative middle ground between refusing to answer and inventing an answer. See Term Structure Extent for the concrete curve-type-specific ceilings (30Y for interest rate curves, a 5Y default for volatility surfaces, open-ended for CDS) this policy applies beyond.

Tracking which regime applies

Whether a given point was interpolated, extrapolated, or flattened should be part of that point's provenance — the same proposed record that would also track whether a point was rejected, back-filled, or overridden. A consumer reading a curve value should be able to tell which of the three regimes produced it, rather than treating every returned value as equally observed.

See also

Emacs 29.3 (Org mode 9.6.15)