-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential Issue: missing rate on June 19th, 2024 for index SOFRON Actual/360 #1999
Comments
Thanks for posting! It might take a while before we look at your issue, so don't worry if there seems to be no feedback. We'll get to it. |
Hi—that error comes from the bootstrapping of the SOFR curve. Can you post at least the evaluation date and the dates of the helpers you're using to create the curve? |
Hi @lballabio Thank you for your reply. Sure.
And the evaluation date is I build the helpers like
|
This code should reproduce the issue in C++. I adapted it from
When I try to run it I get
I was not able to spot something off with my fixings or sofr quotes, but they are retrieved automatically so it could be I am not seeing something. |
Thanks, yes, I can reproduce it. I'll try to have a look next week. |
The startDate of the SOFR Future 2024-09 is determined to be 2024-06-19 (3rd Wed of 3rd month preceding delivery month consistent with the specs here: https://www.cmegroup.com/markets/interest-rates/stirs/three-month-sofr.contractSpecs.html). But then here https://github.com/lballabio/QuantLib/blob/master/ql/instruments/overnightindexfuture.cpp#L83 (and similar for averaged futures) we read the SOFR fixing on 2024-06-19 which leads to the error. I can't find the definite convention to apply, but I would assume that the SOFR rate from the preceding business day is used on the holiday. |
For background, we are hit by this issue as well. |
I see—so maybe it's already fixed by #1996? (It will be in 1.35) |
Unless it's not a real fix because the start date should indeed be June 19th. In that case, yes, we should accrue the previous fixing for that day. |
I was going to say that. :-) So you are saying #1996 is actually not correct and should be rolled back (that's what I am thinking anyway). |
I don't know. I guess the question is: does https://www.cmegroup.com/markets/interest-rates/stirs/three-month-sofr.contractSpecs.html not mention holidays because the only possible case is Juneteenth and this was written before it was declared a holiday? (In which case #1996 might be right.). Or is this on purpose, in which case we roll back #1996 and fix https://github.com/lballabio/QuantLib/blob/master/ql/instruments/overnightindexfuture.cpp#L81-L89 so that it accounts for the start date being a holiday? Do you have access to the corresponding market data? |
I see yes. I'll try to find out! |
The example in https://www.cmegroup.com/education/files/sofr-futures-settlement-calculation-methodologies.pdf suggests that at least 1M futures can start on a holiday. I'd expect 3M to do the same. |
Probably. Although 1M had holidays at start / end all along. But they would have updated the 3M specs I think. Still trying to confirm, but I'd go for that as well. |
I can not get a definite confirmation. I would suggest to take their spec seriously and assume no adjustment of the reference period. |
If you want I can submit a PR for this, we need to fix this anyhow in the short term. |
If you have a PR ready, please go ahead—otherwise let me know and I'll do it. |
I haven't started, so if you can take this that'd be great too! |
It should be fixed in #2013 — please have a look. |
@pcaspers @lballabio thank you a lot for your help with the issue! |
QuantLib Version: 1.33
I am trying to build a SOFR index in Python but I get the error
RuntimeError: 1st iteration: failed at 3rd alive instrument, pillar September 18th, 2024, maturity September 18th, 2024, reference date June 27th, 2024: missing rate on June 19th, 2024 for index SOFRON Actual/360
Which does not make sense as the date is a holiday for the SOFR calendar (and every other QuantLib calendar except NERC, as verified using
holidayList
). In fact, if I attempt to add the date I expectedly getRuntimeError: At least one invalid fixing provided: Wednesday June 19th, 2024, 0.0532
So it seems to raise an error whether the date is provided or not. Could there be an issue with the library that causes this?
(It appears that in
ql/instruments/overnightfutures.cpp
the lineDate d2 = calendar.advance(d1, 1, Days);
hits a holiday somehow, but I have not gotten around to seeing the details in a debugger.)(While I cannot share the direct code, what I do is comparable to the test in
sofrfutures.cpp
)The text was updated successfully, but these errors were encountered: