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

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

Hi Peter,

First of all, thank you for asking me for my opinion on your suggested 
course of action even though I do not currently contribute to the ORE 
code base.

But since you asked, my view is that it would be sensible to at least 
change the parameter name "lookback" to something like "obsLag" or 
"obsShift" in the constructor and also all other instances that pass 
this parameter around so that it is clear to developers what is what.

Now regarding the ORE XML there is the serious issue of backward 
compatibility since the text tokens there interface directly with the 
client apps. The decision is then up to you whether you want to carry 
out the change or not. But even if you keep the XML token as "lookback", 
it should nevertheless map to "obs..." in the c++ interfaces. This would 
enhance code clarity and maintenance.

Ioannis

On 10/28/2022 3:02 PM, Peter Caspers wrote:
> Hi Ioannis
>
> thanks. When we implemented this stuff the terminology was not as
> cut-and-dried as it is today. However it is not easy to change the
> names now since they are linked to the ORE trade XML schema on which
> many of our clients depend. I will update the documentation of the C++
> constructors and the description in the user guide though so that it
> is clear how the parameters map to the ISDA definitions. Does that
> make sense?
>
> Thank you
> Peter
>
> On Thu, 27 Oct 2022 at 19:52, Ioannis Rigopoulos <qua...@de...> wrote:
>> 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

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