Re: [Quantlib-users] Qurious finding in ORE code

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

Hi Jacek,

I don't think it is at the moment. Even GSR won't work properly for
OvernightIndexedCoupon.

Thank you
Peter

On Mon, 9 Jan 2023 at 18:08, Jacek Bator <jac...@gm...> wrote:
>
> Hi Peter,
> Is this formula implemented in Quantlib as well? I'm trying to price RFR caps, but couldn't find suitable classes. Is gsr the only option?
>
> Jacek
>
> pon., 9 sty 2023, 17:35 użytkownik Peter Caspers <pca...@gm...> napisał:
>>
>> Thanks Ioannis!
>>
>> OvernightIndexedCoupon is always backward looking. We model forward
>> looking term rates using the TermRateIndex class (derived from
>> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
>> other IborIndex - based classes.
>>
>> Does that make sense?
>>
>> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos <qua...@de...> wrote:
>> >
>> > Hi Peter,
>> >
>> > Yes. This now makes sense. I was not aware of this formula. Thank you
>> > for sharing the paper as it helped me understand the details of
>> > overnight index cap/floor pricing.
>> >
>> > Thanks to ORE, I completed a sofr cap pricing for a client and
>> > everything went very smoothly. So, kudos for the excellent work! I do
>> > mention of course that the analytics come from ORE/Acadia.
>> >
>> > Just parenthetically, I noticed that the
>> > QuantExt::OvernightIndexedCoupon does not distinguish between forward
>> > and backward looking term rates, which is fine for linear contracts, but
>> > not so for caps or swaptions because a backward looking rate exhibits
>> > higher variance than its forward looking counterpart. Your formulas
>> > imply that you treat the OvernightIndexedCoupon as if it were backward
>> > looking. I would be curious to know if you plan to add a corresponding
>> > boolean flag in the OvernightIndexedCoupon constructor and adjust the
>> > vol code discussed here to account for both forward and backward looking
>> > cases.
>> >
>> > Ioannis
>> >
>> > On 1/5/2023 10:38 AM, Peter Caspers wrote:
>> > > Hi Ioannis
>> > >
>> > > this is a typo, the line should actually be
>> > >
>> > >              T += std::pow(fixingEndTime - T, 3.0) /
>> > > std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
>> > >
>> > > This corresponds to the formula for v_j^B at the end of section 6.3 in
>> > > https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
>> > >
>> > > We will fix this shortly.
>> > >
>> > > Thank you
>> > > Peter
>> > >
>> > > On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos <qua...@de...> wrote:
>> > >> Does anyone have a clue on why the statement (found in
>> > >> blackovernightindexedcouponpricer.cpp)
>> > >>
>> > >> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T, 2.0)
>> > >> / 3.0;
>> > >>
>> > >> is not coded much more simply as
>> > >>
>> > >> T +=( fixingEndTime - T ) / 3.0;
>> > >>
>> > >> The two variables T and fixingEndTime  are both double.
>> > >>
>> > >> I am only asking in case there is some sort of sophisticated trick that
>> > >> I am missing.
>> > >>
>> > >> 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
>> >
>> > --
>> > 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
>>