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

[Peter C. <pca...@gm...>]

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