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

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

Hi Peter,

Great information indeed. I am looking forward to work more in depth 
with the classes you mentioned, provided I get the stimulus and ongoing 
feedback from my client. I will let you know on this thread as soon as I 
reach concrete results regarding the calibration smoothness.

Regarding the QuantLib-ORE convergence I am wondering if setting up the 
qle folder under QuantLib could be a practical step toward this 
direction. I mean, moving the whole qle folder as it currently stands 
with its QuantExt namespace, in a way similar to the existing 
experimental folder. The rest of ORE folders could stay in the ORE 
repository. This would disentangle ORE and QuantLib releases as it would 
remove the need for linking each ORE release to an edited fork of the 
QuantLib code. The problem with the tweaked code inside the forked 
QuantLib could be resolved by some run time constant in settings.hpp or 
compile time constant in qldefines.hpp so that the QuantLib code would 
consist of two alternative versions according to the selected constant. 
At any case, having the ORE's non-portfolio analytics in the QuantLib 
repository would be a great move towards a subsequent real merger of the 
two libraries.

Thanks

Ioannis

On 7/30/2023 9:23 PM, Peter Caspers 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

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com