SOFR Weekend Fixings and Curve Calendar Alignment in rateslib
Summary
The question reports that a rateslib SOFR curve calibration fails when weekend dates lack fixings, even though SOFR is not published on weekends. The answer offers a small demonstration using a floating accrual period and two otherwise similar curves: one without a calendar and one configured with a New York calendar. The contrast points to calendar handling in the curve as the issue to investigate when the fixing table requests a weekend date.
This is a diagnostic example rather than a complete explanation of the STIR future failure. It does not provide the resulting fixing tables, a full working calibration, or a general rule for every rateslib specification. The original questioner's observation that adding weekend values removes the error is not evidence that those values are market fixings. Users should verify how the chosen curve calendar and period conventions generate fixing dates before changing the SOFR data.
Key ideas
- A missing weekend date in a SOFR fixing series can trigger a curve calibration error.
- The answer demonstrates that curve calendar configuration changes the fixing table for a floating period.
- The example compares a curve without an explicit calendar to one using a New York calendar.
- The response diagnoses calendar alignment but does not provide a complete STIR future calibration solution.
- Weekend values added only to suppress an error should not be treated as actual SOFR fixings.
Tags
Full text
# Answer by Attack68 (score 2)
# rateslib STIRFuture throws “RFRs could not be calculated” if SOFR weekend fixings are missing — shouldn’t weekends be skipped?
I’m using rateslib 2.0.0 to calibrate a SOFR curve with a stack of STIRFuture contracts (“usd_stir” & “usd_stir1” specs). When my evaluation date is 2025-06-08 or later, the solver fails with:
ValueError: RFRs could not be calculated, have you missed providing fixings or does the Curve begin after the start of a FloatPeriod including the method_param adjustment?
The first SR-1 future (M5) accrues 2025-06-01 → 2025-07-01. My SOFR fixing series contains every business day up to Wednesday 2025-06-11. Because SOFR is not published on weekends, 2025-06-07 (Sat) and 2025-06-08 (Sun) are missing which should be ok.
However, I am also getting the warning: UserWarning: fixings has missed a calendar value (2025-06-07 00:00:00) which may be set to zero on a LineCurve or error on a Curve. Subsequent fixings have been detected warnings.warn(
If I artificially add fixings for those two weekend days the error disappears, but that conflicts with how SOFR is actually defined.
Is there a way to tell rateslib that SOFR accrues only on business days (i.e., skip weekends) so the engine won’t require weekend fixings? Or am I missing a flag / different spec that already handles this?
## Answer by Attack68 (score 2)
https://quant.stackexchange.com/a/83632
Further to my comment this is probably the easiest way to demonstrate what I think your issue is:
```
from rateslib import Curve, FloatPeriod # rateslib 2.0, python 3.12
wrong_curve = Curve({dt(2025, 6, 13): 1.0, dt(2025, 7, 13): 0.995})
right_curve = Curve({dt(2025, 6, 13): 1.0, dt(2025, 7, 13): 0.995}, calendar="nyc")
period = FloatPeriod(dt(2025, 6, 13), dt(2025, 6, 27), dt(2025, 6, 27), "A")
>>> period.fixings_table(wrong_curve)
>>> period.fixings_table(right_curve)
```Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.