[Quantlib-users] Wrong interpretation of the lookback period in AverageONIndexedCoupon

[Ioannis R. <qua...@de...>]

Hi Peter and Roland,

Optimally I would have added my correction in the ORE repository rather 
than sending this email, but I will rather wait until ORE has been 
brought back to the usual link with QuantLib, which is within your plans 
away.

But I do send this email because I think the lookback feature of OIS is 
quite important as OIS are ubiquitous these days due to Libor cessation.

It is clearly documented in various sites that a lookback period has no 
effect on the accrual period of the floating leg. It only changes the 
way the applicable overnight rate is calculated. Documentation examples are:

https://www.isda.org/a/alEgE/A40393158-v18.0-ISDA_Memorandum_Compounding-RFRs-under-2006-Definitions.pdf

https://www.newyorkfed.org/medialibrary/Microsites/arrc/files/2021/users-guide-to-sofr2021-update.pdf

But the AverageONIndexedCoupon constructor has the two lines:

         valueStart = 
overnightIndex->fixingCalendar().advance(valueStart, -lookback, bdc);
         valueEnd = overnightIndex->fixingCalendar().advance(valueEnd, 
-lookback, bdc);

that lead to a modification of the accrual period [valueStart  , valueEnd]

It turns out that the current ORE implementation treats the formal 
constructor parameter lookback as if it were what the market understands 
as "observation shift" or "observation lag". I prefer the "lag" over 
"shift" because it makes more clear the time direction associated with a 
positive value.

Further on, the above constructor takes an argument called fixingDays, 
which is treated as if it were what the market understands as "lookback".

As you see, technically speaking, this situation is not wrong per se, as 
the constructor does its job correctly, provided one feeds it with the 
correctly interpreted input, in the sense that one must supply the 
"observation lag" market value for the formal lookback parameter and the 
"lookback" market value for the formal fixingDays parameter.

Nevertheless, it would be better if the formal parameter names are 
changed to reflect their actual meaning in order to avoid unintended 
wrong usage.

regards,

Ioannis


-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com