Re: [Quantlib-users] Missing sabr interpolation for capfloor vols in both QuantLib and ORE

[Steve H. <war...@gm...>]

Hi Peter
Thanks for the reply. Sorry, I still don’t get it. Allow me to bother you
more. Take an example, the  m*n swaption has m-length option tenor, when
ITM at expiry we will enter into a n-length swap. So the 2nd ibor caplet
can be regarded as an swaption whose option tenor, 3m, and then enter into
a swap with 3m swap tenor.
what I am confused is that the caplet on RFR seems not the case, it has
overlapping option tenor and swap tenor when map to a single period
swaption.

Do I get anything wrong?
Thank your for the help.

Regards,
Steve

On Fri, Aug 18, 2023 at 2:03 AM Peter Caspers <pca...@gm...>
wrote:

> Hi Steve
>
> the standard 1y cap on RFR has
>
> 0m 3m
> 3m 3m
> 6m 3m
> 9m 3m
>
> caplets.
>
> Best
> Peter
>
>
> Steve Hsieh <war...@gm...> schrieb am Do. 17. Aug. 2023 um
> 08:30:
>
>> Hi Peter and Ioannis,
>> I am also interested in this discussion and have one question about the “
>> swaption exercising into a single-period swap.” I am confused by the option
>> tenor in IBOR and RFR world.
>>
>> 1. In a fixing in advance IBOR world:
>> Take one year cap for example, we only have 3 live caplets since first
>> one is fixing on trade day and actually no volatility at all.  Assuming the
>> payment frequency is 3m, then we have:
>>     Caplet2=3m*3m swaption
>>     Caplet3=6m*3m swaption
>>     Caplet4=9m*3m swaption
>>
>> 2. In a fixing in arrear RFR world:
>> we now have 4 caplets,  then we have:
>>     Caplet1=3m*3m swaption
>>     Caplet2=6m*3m swaption
>>     Caplet3=9m*3m swaption
>>     Caplet4=12m*3m swaption
>>
>> Am I correct?
>>
>> Regards,
>> Steve
>>
>>
>>
>>
>>
>> On Mon, Jul 31, 2023 at 3:24 AM Peter Caspers <pca...@gm...>
>> wrote:
>>
>>> Hi Ioannis,
>>>
>>> Yes that makes sense to me, a swaption exercising into a single-period
>>> swap is the same as a (single) caplet / floorlet.
>>>
>>> I am just not sure how practical this approach is, it depends on what
>>> exactly you intend to do.
>>>
>>> By the way - you want to make sure that the conventions of the
>>> swaption are set correctly, e.g. the day counter of the fixed leg of
>>> the swap should be the same as on the floating leg to mimic an
>>> optionlet (e.g. A360 for both sides in the EUR case). And the swaption
>>> should be physically settled.
>>>
>>> This also reminds me of extensions for RFR swaptions we did in
>>> ORE-QuantLib, e.g. the ATM rate calculations for swaptions which is
>>> correct here
>>>
>>>
>>> https://github.com/OpenSourceRisk/QuantLib/blob/116cf704bf6642de824aff035ce9849e1e621fce/ql/termstructures/volatility/swaption/swaptionvolcube.cpp#L91
>>>
>>> but not yet in the original QuantLib. We still have to harmonize that
>>> stuff.
>>>
>>> Thank you
>>> Peter
>>>
>>> On Thu, 27 Jul 2023 at 21:01, Ioannis Rigopoulos <qua...@de...>
>>> wrote:
>>> >
>>> > Thanks Peter for the quick response.
>>> >
>>> > I posed the question because I have received an inquiry from the rates
>>> > option desk of a big Chinese bank, to whom I have already told I am
>>> > using QuantLib and ORE for the analytics part.
>>> >
>>> > Therefore I am really looking forward to any advancement that you could
>>> > possibly make with regard to the SABR calibration in that area.
>>> >
>>> > If you allow me, I would like to draw on to your expertise in this area
>>> > by asking you one quick question:
>>> >
>>> > As you know, both libraries have the ability to use SABR in the context
>>> > of swaptions. Some time ago I had even published the blog
>>> > https://blog.deriscope.com/index.php/en/excel-quantlib-swaption-sabr
>>> > along with a spreadsheet that demonstrates the cubic vol calibration of
>>> > the SABR parameters. Perhaps my thinking is naive, but a capfloor
>>> > consists of optionlets, which in turn are trivial one-period swaptions.
>>> > Since we can imply the optionlet vols by stripping the available
>>> > capfloor market vols, I suspect that we may then treat these implied
>>> > optionlet vols as if they were given swaption vols. Obviously the vols
>>> > manifold in this case will be a surface rather than a cube since all
>>> > swaptions will reference an underlying swap consisting of a single
>>> > period. I am wondering what would happen if I nevertheless run the SABR
>>> > calibration on these swaption vols, just like in the link above.
>>> >
>>> > Do you think such an approach could make sense?
>>> >
>>> > Thanks again for your time and your advice.
>>> >
>>> > Ioannis
>>> >
>>> > On 7/27/2023 9:22 PM, Peter Caspers wrote:
>>> > > Hi Ioannis,
>>> > >
>>> > > I agree with you, SABR is a popular method to model volatility
>>> smiles,
>>> > > especially for rates and we should support it for both swaptions and
>>> > > cap / floors. It's on my personal short list for sure (since a
>>> while!)
>>> > > and also loosely on the ORE roadmap, clients keep asking for this.
>>> > >
>>> > > Actually, it is kind of supported already in QuantExt because you can
>>> > > use SABRInteprolation with the StrippedOptionletAdapter (the version
>>> > > of this class in QuantExt). I never tried this though, and we don't
>>> > > expose this in the OREData curve builder, for a reason:
>>> > >
>>> > > I think there is more work to do, since when you model a whole cap
>>> > > surface or swaption cube with SABR you want to make sure that the
>>> SABR
>>> > > parameters vary smoothly for different expiries (and swap lengths),
>>> > > otherwise your interpolated vols might be useless.
>>> > >
>>> > > We also definitely want to look into arbitrage-free flavours of SABR
>>> > > like we started here
>>> > >
>>> > >
>>> https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/models/normalsabr.hpp#L37
>>> > >
>>> > > Anyway, we'll keep you posted.
>>> > >
>>> > > Thanks
>>> > > Peter
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Thu, 27 Jul 2023 at 15:11, Ioannis Rigopoulos <
>>> qua...@de...> wrote:
>>> > >> Hi Peter,
>>> > >>
>>> > >> I am asking you directly regarding my recent QuantLib inquiry below
>>> > >> because I saw your name as being the last contributor to
>>> > >> strippedoptionletadapter.cpp and I have not received any response
>>> yet.
>>> > >>
>>> > >> Since you also are an expert in the ORE library, I would also like
>>> to
>>> > >> ask you if that library supports the SABR calibration of capfloors.
>>> > >>
>>> > >> Many thanks!
>>> > >>
>>> > >> Ioannis
>>> > >>
>>> > >> On 7/21/2023 9:25 PM, Ioannis Rigopoulos wrote:
>>> > >>> Does anybody know why sabr interpolation of capfloor volatilities
>>> > >>> seems to be unsupported in both quantlib and ore although it is
>>> > >>> apparently common practice in the industry?
>>> > >>>
>>> > >>> More specifically, in strippedoptionletadapter.cpp there is a
>>> > >>> commented out code segment starting with "strikeInterpolations_[i]
>>> =
>>> > >>> ext::shared_ptr<SABRInterpolation>(...)".
>>> > >>>
>>> > >>> Does anybody know why this segment has been commented out?
>>> > >>>
>>> > >>>
>>> > >> --
>>> > >> This email has been checked for viruses by Avast antivirus software.
>>> > >> www.avast.com
>>> >
>>> > --
>>> > This email has been checked for viruses by Avast antivirus software.
>>> > www.avast.com
>>>
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>