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

[Ioannis R. <qua...@de...>]

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