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

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

Oh and Luigi, is it okay that we keep hijacking your list for
questions on ORE ... :-) ?

On Fri, 28 Oct 2022 at 15:02, Peter Caspers <pca...@gm...> 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