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

[Luigi B. <lui...@gm...>]

The ORE forum would of course be best, but they're at least
QuantLib-adjacent :)


On Fri, Oct 28, 2022 at 3:07 PM Peter Caspers <pca...@gm...>
wrote:

> 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
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>