extend OvernightIndexedCoupon and OvernightLeg

[klin333]

trafficstars

extend OvernightIndexedCoupon and OvernightLeg with fixing days, observation shift, lockout and no payment lag on final payment

I am not a professionaly trained C++ programmer... Also, i'm not set up to compile the whole QuantLib. I've only tested this code by overriding these two files while linking to QuantLib 1.25. I've checked with Bloomberg for only the interest accrued values for a few overnight indexed bonds.

This is more of a draft to get feedback. tries to solve #1422

Fixing Days

• the implementation for fixing days is similar to IborIndex

Observation Shift

• observation shift is needed for most SOFR floating rate bond, this is where the daily schedule, used to calculate the number of calendar days each SOFR rate applies, is also shifted by fixing days.
• i'm not sure whether this can be done by simply shifting valueDates_. Currently valueDates_ is used for telescopic calculations, which i don't understand enough to touch, so i created a third vector called accrualDates_. Note that this cannot be implemented by shifting the startDate and endDate used to instantiate OvernightIndexedCoupon, because that messes up accrualPeriod() and accruedPeriod().
• Also i fixed an inconsistency in the pricer averageRate. we should not use coupon_->accruedPeriod(date) in averageRate because accruedPeriod() uses the coupon daycounter which is used to compute interest accrued and coupon payments. However for averageRate, the day counter used should always be the index day counter because that is how dt_ is calculated. Of course, maybe the better fix is to calculate dt_ and averageRate using coupon day counter, not sure. probably doesn't matter much as most floaters would use same day counter as the index. But code change was required anyway to handle observationShift.

Lockout

• Currently buggy because BondFunctions::accruedAmount finds the wrong coupon. I think hasOccurred() looks at payment dates, which because is lagged, retrieves the wrong coupon in a bond's cashflow, given a settlement date
• currently incorrect for accruedAmount. in an eg 2 day lockout coupon with no fixing days lag, for any date, there will be unknown but needed index fixings. Bloomberg help page states that for bond interest accrued, when a required fixing is not yet known, the latest available fixing should be used. this needs to be handled in the pricer averageRate, based on evaluationDate. ie fixings that are not available, but not available as of evaluationDate should be masked and filled. this actually requires an extra field in OvernightIndex, to state the day lag in fixing availability, eg SOFR has a 1 day publication lag, which is conceptually different to settlements aka fixing days, and is currently unavailable in OvernightIndex class.

[boring-cyborg[bot]]

Thanks for opening this pull request! It might take a while before we look at it, so don't worry if there seems to be no feedback. We'll get to it.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Kai Lin seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sweemer]

Hi @klin333 it would be good to see some test cases for these new features. You can add it to the existing https://github.com/lballabio/QuantLib/blob/master/test-suite/overnightindexedcoupon.hpp file, and you can compare the results against known good values from Bloomberg.

What's the error you get when trying to compile QuantLib? I can help to get you set up with compiling the project in order to test your changes.

[klin333]

ok managed to compile QuantLib. i'll make some tests soon and amend this pull request

[github-actions[bot]]

This PR was automatically marked as stale because it has been open 60 days with no activity. Remove stale label or comment, or this will be closed in two weeks.

[github-actions[bot]]

This PR was automatically marked as stale because it has been open 60 days with no activity. Remove stale label or comment, or this will be closed in two weeks.

[github-actions[bot]]

This PR was automatically closed because it has been stalled for two weeks with no further activity.