How to Decide Whether to Store Curves

This guide helps you determine whether to store forward-curve snapshots locally or fetch them on demand, depending on your use case and system needs.

Step 1: Clarify your use case

• Are you working with fixed reporting periods? (e.g. end-of-month, quarter, calendar half-year)

• Or do you need arbitrary/ad-hoc ranges? (e.g. 16 Sept to 19 Dec, or variable slices)

---

Step 2: Evaluate pros & cons

Approach	Best for	Pros	Cons
Fetch on demand	Ad-hoc date ranges, always-up-to-date needs	Simpler setup; always current; no storage cost	Depends on API speed; hard to reproduce older curves without logging
Store snapshots	Fixed period reporting; speed; reproducibility	Fast access; easy historical comparisons; better reproducibility for auditing	Requires storage, many unused snapshots if ad-hoc use

---

Step 3: Make decision based on your needs

• If your team relies on consistent periods (e.g., EOM or quarter) and you value reproducibility, go with Stored Snapshots.

• If you need flexibility and minimal infrastructure, go with Fetch on Demand.

---

Quick Examples

• Fixed reporting usage: You always need the forward curve at "Jan-1 end-of-day," "Feb-1," … in a dashboard. Store snapshots on those dates; your dashboard just reads the stored curve.

• Ad-hoc pricing needs: You need a forward curve for dates between 16 Sept and 19 Dec every time. It’s inefficient to store every possible slice — better to fetch it when needed.

---

Implementation hints

• For snapshot storage, keep a table with columns:

  • valuation_timestamp

  • period_start_date / period_end_date

  • index_name

  • forward_rate / discount_factor

  • optionally: snapshot_id,