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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Peter,

Apologies for the delayed response.

I have little expertise on the current practices around cap pricing, but 
I asked around and I can confirm what you wrote, albeit only for front 
desk trading.

Risk management applications often need to take into account ATM vols, 
mainly because the regulators demand it.

It is also true that ATM vols are generally published - for example in 
regular Bloomberg screens -, which implies that there must be some use 
for it.

The good news is that I have managed to bootstrap the ATM vols 
successfully in ORE by means of the sparse table using the class 
CapFloorTermVolSurfaceSparse

Ioannis

On 1/11/2023 12:44 PM, Peter Caspers wrote:
> Hi Ioannis
>
> no it is not possible at the moment to include ATM quotes, unfortunately.
>
> By the way what is your general view on this, i.e. is it useful to
> include ATM quotes? Sometimes I hear these are not traded much and
> therefore you might be better off building the surface from fixed
> strike quotes.
>
> Thanks
> Peter
>
> On Tue, 10 Jan 2023 at 21:18, Ioannis Rigopoulos <qua...@de...> wrote:
>> Peter,
>>
>> I don't know if what I describe below relates to what you wrote about
>> IborCoupon  versus OvernightIndexedCoupon.
>>
>> While my bootstraping of a strike/tenor vol matrix runs smoothly, I
>> encounter a serious problem when I tried to bootstrap the combination
>> consisting of an atm tenor-only vol vector and a strike/tenor vol matrix.
>>
>> The current code for the method
>> OptionletStripperWithAtm<TimeInterpolator,
>> SmileInterpolator>::performCalculations() contains the following:
>>
>> if (isOis) {
>>
>>       QL_FAIL("OIS cap vol stripping with ATM not yet supported.");
>>
>> }
>>
>> I tried to add my own code in that place, but I realized that the whole
>> logic in OptionletStripperWithAtm is based on instruments of type
>> QuantLib::CapFloor which cannot process correctly oi term rates.
>>
>> Is there any way to solve this problem in the current ORE version?
>>
>> In the mean time I will be trying to use the type
>> CapFloorTermVolSurfaceSparse after having calculated manually the atm
>> strikes of the caps in the atm vol vector. Hopefully this would work!
>>
>> Ioannis
>>
>> On 1/10/2023 1:12 PM, Ioannis Rigopoulos wrote:
>>> Let me also share one more thought regarding IborIndex and IborCoupon.
>>>
>>> I understand these two types are used almost everywhere in QuantLib
>>> for good historical reasons and is therefore reasonable to elevate the
>>> concept represented by IborIndex to include special types of term
>>> rates, such as average overnight rates.
>>>
>>> I would then find it practical to enhance a bit the definition of
>>> TermRateIndex with a boolean flag so that it captures both types of
>>> averages, the forward looking average and the backward looking average.
>>>
>>> This would make the overall code smaller and simpler since the
>>> IborCoupon would then represent both types of average and would also
>>> make the OvernightIndexedCoupon redundant.
>>>
>>> Ioannis
>>>
>>> On 1/9/2023 9:23 PM, Ioannis Rigopoulos wrote:
>>>> Hi Peter,
>>>>
>>>> Thanks for letting me know that forward looking oi coupons are
>>>> modeled through IborCoupon. It does make sense since the IborCoupon
>>>> referencing a non-RFR ibor rate has always been forward looking.
>>>>
>>>> I will make the link to QuantLib::CapFloor and test how it will work.
>>>>
>>>> Ioannis
>>>>
>>>> On 1/9/2023 7:20 PM, Peter Caspers wrote:
>>>>> 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
>>>>>>>
>>>
>>> _______________________________________________
>>> 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