Curves, clocks and conventions

Interest-rate option API

Design rates option records around the actual product, reference period, quotation scale, curves and volatility conventions.

Bond and rate option API conventions in rainbow fintech typography, branded OptionAPI.com.
Editorial illustration. Figures in artwork are not live quotes.

A rate is not every price on the screen

CME’s Three-Month SOFR overview describes a futures quotation based on 100 minus a relevant rate. This is one specific example of why quotation conventions must be explicit. Do not interpret every fixed-income field as a percentage or a cash-bond price based on its apparent magnitude.

Preserve the reference period

Keep expiry, underlying maturity, reference-period boundaries and applicable schedules distinct. Record the precision your source provides and the calendar version used for derived timestamps. A one-year label needs an axis: an option expiry and an underlying tenor are different quantities.

Treat curves as versioned inputs

Store observed curve inputs separately from constructed points, with interpolation and extrapolation choices documented. A model should identify exactly which curve and volatility convention it used. If an input is missing, report an explicit failure or degraded status instead of silently updating only the easiest fields.

Compare outputs only after units align

Risk and volatility labels need scaling, sign conventions and calculation context. Keep provider analytics distinct from internally calculated analytics. The related article offers dimension and reproducibility tests; it does not provide a universal valuation model or claim that a rate-data feed authorizes a trade.

Read the record.
Build with clarity.

Go from a market label to a field you can explain. Start with the guides, then inspect the local JSON examples.