Menu
▾
▴
Re: [Quantlib-users] Missing sabr interpolation for capfloor vols in both QuantLib and ORE
|
From: Peter C. <pca...@gm...> - 2023-08-18 07:15:13
|
I am sorry for the confusion: The equivalence of single period swaption / caplet holds for forward-looking rates only, i.e. the old Ibors and forward looking RFR term rates. For backward looking RFR rates there is no such translation because of the different option exercise date. Thank you Peter On Fri, 18 Aug 2023 at 04:13, Steve Hsieh <war...@gm...> wrote: > > 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 |
