quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] MarkovFunctional instantiation error

[Giuseppe T. <tr...@gm...>]

Good evening everyone, Peter,


Thank you for the quick reply! I checked as you suggested, the outcome is
the same. Again, using EuriborSwapIsdaFixA works fine regardless of the
tenor used for the smile calibration. Please find below a small code
example.

I'm on Windows 11, MSVC 143, boost 1.83 (prebuilt binaries, msvc143),
QuantLib 1.31 (Release).


As always, thanks in advance for your time.


#include <ql/models/shortrate/onefactormodels/markovfunctional.hpp>
> #include <ql/indexes/ibor/libor.hpp>
> #include <ql/indexes/swap/euriborswap.hpp>
> #include <ql/termstructures/yield/flatforward.hpp>
> #include <ql/termstructures/volatility/swaption/swaptionconstantvol.hpp>
> #include <ql/quotes/simplequote.hpp>
> #include <ql/time/calendars/unitedstates.hpp>
> #include <ql/time/daycounters/actual360.hpp>
> #include <ql/currencies/america.hpp>
>
> #include <iostream>
> #include <iomanip>
>
> using namespace QuantLib;
>
> int main(int argc, char *argv[]) {
>
>     try {
>
>         Date refDate(31, May, 2023);
>         Settings::instance().evaluationDate() = refDate;
>
>         Real forwardRate = 0.02;
>
>         Handle<Quote> forwardRateQuote(
>             ext::make_shared<SimpleQuote>(forwardRate));
>
>         Calendar calendar = UnitedStates(UnitedStates::SOFR);
>
>         Handle<YieldTermStructure>
> forwardCurve(ext::make_shared<FlatForward>(
>             2, calendar, forwardRateQuote, Actual360()));
>
>
>         Real volLevel = 0.20;
>         Handle<Quote> volQuote(ext::make_shared<SimpleQuote>(volLevel));
>         Handle<SwaptionVolatilityStructure> swaptionVol(
>             ext::make_shared<ConstantSwaptionVolatility>(
>                 2, calendar, ModifiedFollowing, volQuote,
> Actual365Fixed()));
>
>         //ext::shared_ptr<SwapIndex> swapBase =
>         //    ext::make_shared<EuriborSwapIsdaFixA>(
>         //        10 * Years, forwardCurve
>         //    );
>
>
>         ext::shared_ptr<IborIndex> iborIndex =
>             ext::make_shared<Libor>(
>                 "DummyIborIndex", 1 * Years, 2, USDCurrency(), calendar,
> Actual360(), forwardCurve
>             );
>
>
>         ext::shared_ptr<SwapIndex> swapBase =
>             ext::make_shared<SwapIndex>(
>                 "DummySwapIndex", 10 * Years, 2, USDCurrency(), calendar,
> 1 * Years, ModifiedFollowing, Actual360(), iborIndex
>             );
>
>
>         std::vector<Real> sigmas(2, 0.01);
>         Real reversion = 0.05;
>
>         Date exerciseDate = Date(30, May, 2025);
>
>         std::vector<Date> exerciseDates;
>         exerciseDates.push_back(exerciseDate);
>
>         const std::vector<Date> swaptionDates(1, exerciseDate);
>
>         // smileTenors > fixed leg tenor => ERROR
>         std::vector<Period> smileTenors(1, 5 * Years);
>
>         // smileTenors <= fixed leg tenor => NO ERROR
>         //std::vector<Period> smileTenors(1, 1 * Years);
>
>
>         ext::shared_ptr<MarkovFunctional> markov =
>             ext::make_shared<MarkovFunctional>(
>                 forwardCurve, reversion, exerciseDates, sigmas,
> swaptionVol,
>                 swaptionDates, smileTenors, swapBase,
>                 MarkovFunctional::ModelSettings().withYGridPoints(16)
>             );
>
>
>     } catch (const QuantLib::Error& e) {
>         std::cout << "terminated with a ql exception: " << e.what()
>                   << std::endl;
>         return 1;
>     } catch (const std::exception& e) {
>         std::cout << "terminated with a general exception: " << e.what()
>                   << std::endl;
>         return 1;
>     }
> }
>



Il giorno gio 17 ago 2023 alle ore 20:05 Peter Caspers <
pca...@gm...> ha scritto:

> Hi Giuseppe
>
> can you possibly check whether the problem occurs in pure C++ code as well?
>
> Thank you
> Peter
>
>
>
> Giuseppe Trapani <tr...@gm...> schrieb am Do. 17. Aug. 2023 um 18:17:
>
>> Good evening everyone,
>>
>> I am working with QuantLib python (version 1.31 from pypi). I'm trying to
>> instantiate *MarkovFunctional to be calibrated on a single expiry /
>> smile* and I noticed the following RuntimeError:
>>
>> RuntimeError: year 2200 out of bounds. It must be in [1901,2199]
>>
>>
>> The error is raised in the following case:
>>
>>
>>    - The SwapIndex passed to MarkovFunctional has a certain fixed leg
>>    tenor (e.g., 1y)
>>    - The swaptionTenors (that is, the smile to be calibrated to) is
>>    greater than that of the fixed leg tenor of the SwapIndex (from the example
>>    above, > 1y).
>>
>>
>> Notice that *this happens only for SwapIndex with a fixed leg tenor
>> greater or equal than 1y*: if I create a SwapIndex with fixed leg tenor
>> smaller than 1y, the MarkovFunctional object gets instantiated correctly
>> with whatever smile I choose.
>>
>> *Another weird thing*: if I use a standard EuriborSwapIsdaFixA (that has
>> a fixed leg tenor of 1y), I can also correctly instantiate the
>> MarkovFunctional object with whatever smile I choose.
>>
>> Is this behaviour expected? Please, find below a minimum replication code.
>>
>>
>> Thanks in advance for your time and availability.
>>
>>
>>
>> ivol = 0.25
>>>
>>> ivol_quote = ql.SimpleQuote(ivol)
>>>
>>> ln_shift = 0.02
>>>
>>>
>>>> forward_rate = 0.02
>>>
>>> forward_rate_quote = ql.SimpleQuote(forward_rate)
>>>
>>>
>>>> calendar = ql.UnitedStates(ql.UnitedStates.SOFR)
>>>
>>>
>>>> oswp_blackvols = ql.ConstantSwaptionVolatility(2, calendar,
>>>> ql.Following, ql.QuoteHandle(ivol_quote), ql.Actual365Fixed(),
>>>> ql.ShiftedLognormal, ln_shift)
>>>
>>> forward_curve = ql.FlatForward(2, calendar,
>>>> ql.QuoteHandle(forward_rate_quote), ql.Actual360())
>>>
>>>
>>>> #swap_index = ql.EuriborSwapIsdaFixA(
>>>
>>> #    ql.Period("10y"),
>>>
>>> #    ql.YieldTermStructureHandle(forward_curve),
>>>
>>> #    ql.YieldTermStructureHandle(forward_curve)
>>>
>>> #)
>>>
>>>
>>>>
>>>> floating_leg_tenor = ql.Period("6m")
>>>
>>> fixed_leg_tenor = ql.Period("1y")
>>>
>>> ibor_index = ql.Libor("DummyIborIndex", floating_leg_tenor, 2,
>>>> ql.USDCurrency(), calendar, ql.Actual360(),
>>>> ql.YieldTermStructureHandle(forward_curve))
>>>
>>> swap_index = ql.SwapIndex("DummySwapIndex", ql.Period("10y"), 2,
>>>> ql.USDCurrency(), calendar, fixed_leg_tenor, ql.ModifiedFollowing,
>>>> ql.Actual360(), ibor_index)
>>>
>>>
>>>> mean_reversion = 0.05
>>>
>>>
>>>> exercise_dates = [ql.Date(30, 5, 2025)]
>>>
>>> swaption_dates = [ql.Date(30, 5, 2025)]
>>>
>>>
>>>>
>>>> ## smile_tenors > then fixed_leg_tenor => ERROR
>>>
>>> smile_tenors = [ql.Period("5y")]
>>>
>>>
>>>> ## smile_tenors <= fixed_leg_tenor => NO ERROR
>>>
>>> # smile_tenors = [ql.Period("1y")]
>>>
>>>
>>>> mm = ql.MarkovFunctional(
>>>
>>>     ql.YieldTermStructureHandle(forward_curve),
>>>
>>>     mean_reversion,
>>>
>>>     exercise_dates,
>>>
>>>     [0.01, 0.01],
>>>
>>>     ql.SwaptionVolatilityStructureHandle(oswp_blackvols),
>>>
>>>     swaption_dates,
>>>
>>>     smile_tenors,
>>>
>>>     swap_index
>>>
>>> )
>>>
>>>
>>
>>
>>
>> --
>> *Giuseppe Trapani*
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

-- 
*Giuseppe Trapani*

Re: [Quantlib-users] MarkovFunctional instantiation error

[Peter C. <pca...@gm...>]

Hi Giuseppe

can you possibly check whether the problem occurs in pure C++ code as well?

Thank you
Peter



Giuseppe Trapani <tr...@gm...> schrieb am Do. 17. Aug. 2023 um 18:17:

> Good evening everyone,
>
> I am working with QuantLib python (version 1.31 from pypi). I'm trying to
> instantiate *MarkovFunctional to be calibrated on a single expiry / smile*
> and I noticed the following RuntimeError:
>
> RuntimeError: year 2200 out of bounds. It must be in [1901,2199]
>
>
> The error is raised in the following case:
>
>
>    - The SwapIndex passed to MarkovFunctional has a certain fixed leg
>    tenor (e.g., 1y)
>    - The swaptionTenors (that is, the smile to be calibrated to) is
>    greater than that of the fixed leg tenor of the SwapIndex (from the example
>    above, > 1y).
>
>
> Notice that *this happens only for SwapIndex with a fixed leg tenor
> greater or equal than 1y*: if I create a SwapIndex with fixed leg tenor
> smaller than 1y, the MarkovFunctional object gets instantiated correctly
> with whatever smile I choose.
>
> *Another weird thing*: if I use a standard EuriborSwapIsdaFixA (that has
> a fixed leg tenor of 1y), I can also correctly instantiate the
> MarkovFunctional object with whatever smile I choose.
>
> Is this behaviour expected? Please, find below a minimum replication code.
>
>
> Thanks in advance for your time and availability.
>
>
>
> ivol = 0.25
>>
>> ivol_quote = ql.SimpleQuote(ivol)
>>
>> ln_shift = 0.02
>>
>>
>>> forward_rate = 0.02
>>
>> forward_rate_quote = ql.SimpleQuote(forward_rate)
>>
>>
>>> calendar = ql.UnitedStates(ql.UnitedStates.SOFR)
>>
>>
>>> oswp_blackvols = ql.ConstantSwaptionVolatility(2, calendar,
>>> ql.Following, ql.QuoteHandle(ivol_quote), ql.Actual365Fixed(),
>>> ql.ShiftedLognormal, ln_shift)
>>
>> forward_curve = ql.FlatForward(2, calendar,
>>> ql.QuoteHandle(forward_rate_quote), ql.Actual360())
>>
>>
>>> #swap_index = ql.EuriborSwapIsdaFixA(
>>
>> #    ql.Period("10y"),
>>
>> #    ql.YieldTermStructureHandle(forward_curve),
>>
>> #    ql.YieldTermStructureHandle(forward_curve)
>>
>> #)
>>
>>
>>>
>>> floating_leg_tenor = ql.Period("6m")
>>
>> fixed_leg_tenor = ql.Period("1y")
>>
>> ibor_index = ql.Libor("DummyIborIndex", floating_leg_tenor, 2,
>>> ql.USDCurrency(), calendar, ql.Actual360(),
>>> ql.YieldTermStructureHandle(forward_curve))
>>
>> swap_index = ql.SwapIndex("DummySwapIndex", ql.Period("10y"), 2,
>>> ql.USDCurrency(), calendar, fixed_leg_tenor, ql.ModifiedFollowing,
>>> ql.Actual360(), ibor_index)
>>
>>
>>> mean_reversion = 0.05
>>
>>
>>> exercise_dates = [ql.Date(30, 5, 2025)]
>>
>> swaption_dates = [ql.Date(30, 5, 2025)]
>>
>>
>>>
>>> ## smile_tenors > then fixed_leg_tenor => ERROR
>>
>> smile_tenors = [ql.Period("5y")]
>>
>>
>>> ## smile_tenors <= fixed_leg_tenor => NO ERROR
>>
>> # smile_tenors = [ql.Period("1y")]
>>
>>
>>> mm = ql.MarkovFunctional(
>>
>>     ql.YieldTermStructureHandle(forward_curve),
>>
>>     mean_reversion,
>>
>>     exercise_dates,
>>
>>     [0.01, 0.01],
>>
>>     ql.SwaptionVolatilityStructureHandle(oswp_blackvols),
>>
>>     swaption_dates,
>>
>>     smile_tenors,
>>
>>     swap_index
>>
>> )
>>
>>
>
>
>
> --
> *Giuseppe Trapani*
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

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

[Peter C. <pca...@gm...>]

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
>>
>

[Quantlib-users] MarkovFunctional instantiation error

[Giuseppe T. <tr...@gm...>]

Good evening everyone,

I am working with QuantLib python (version 1.31 from pypi). I'm trying to
instantiate *MarkovFunctional to be calibrated on a single expiry / smile*
and I noticed the following RuntimeError:

RuntimeError: year 2200 out of bounds. It must be in [1901,2199]


The error is raised in the following case:


   - The SwapIndex passed to MarkovFunctional has a certain fixed leg tenor
   (e.g., 1y)
   - The swaptionTenors (that is, the smile to be calibrated to) is greater
   than that of the fixed leg tenor of the SwapIndex (from the example above,
   > 1y).


Notice that *this happens only for SwapIndex with a fixed leg tenor greater
or equal than 1y*: if I create a SwapIndex with fixed leg tenor smaller
than 1y, the MarkovFunctional object gets instantiated correctly with
whatever smile I choose.

*Another weird thing*: if I use a standard EuriborSwapIsdaFixA (that has a
fixed leg tenor of 1y), I can also correctly instantiate the
MarkovFunctional object with whatever smile I choose.

Is this behaviour expected? Please, find below a minimum replication code.


Thanks in advance for your time and availability.



ivol = 0.25
>
> ivol_quote = ql.SimpleQuote(ivol)
>
> ln_shift = 0.02
>
>
>> forward_rate = 0.02
>
> forward_rate_quote = ql.SimpleQuote(forward_rate)
>
>
>> calendar = ql.UnitedStates(ql.UnitedStates.SOFR)
>
>
>> oswp_blackvols = ql.ConstantSwaptionVolatility(2, calendar, ql.Following,
>> ql.QuoteHandle(ivol_quote), ql.Actual365Fixed(), ql.ShiftedLognormal,
>> ln_shift)
>
> forward_curve = ql.FlatForward(2, calendar,
>> ql.QuoteHandle(forward_rate_quote), ql.Actual360())
>
>
>> #swap_index = ql.EuriborSwapIsdaFixA(
>
> #    ql.Period("10y"),
>
> #    ql.YieldTermStructureHandle(forward_curve),
>
> #    ql.YieldTermStructureHandle(forward_curve)
>
> #)
>
>
>>
>> floating_leg_tenor = ql.Period("6m")
>
> fixed_leg_tenor = ql.Period("1y")
>
> ibor_index = ql.Libor("DummyIborIndex", floating_leg_tenor, 2,
>> ql.USDCurrency(), calendar, ql.Actual360(),
>> ql.YieldTermStructureHandle(forward_curve))
>
> swap_index = ql.SwapIndex("DummySwapIndex", ql.Period("10y"), 2,
>> ql.USDCurrency(), calendar, fixed_leg_tenor, ql.ModifiedFollowing,
>> ql.Actual360(), ibor_index)
>
>
>> mean_reversion = 0.05
>
>
>> exercise_dates = [ql.Date(30, 5, 2025)]
>
> swaption_dates = [ql.Date(30, 5, 2025)]
>
>
>>
>> ## smile_tenors > then fixed_leg_tenor => ERROR
>
> smile_tenors = [ql.Period("5y")]
>
>
>> ## smile_tenors <= fixed_leg_tenor => NO ERROR
>
> # smile_tenors = [ql.Period("1y")]
>
>
>> mm = ql.MarkovFunctional(
>
>     ql.YieldTermStructureHandle(forward_curve),
>
>     mean_reversion,
>
>     exercise_dates,
>
>     [0.01, 0.01],
>
>     ql.SwaptionVolatilityStructureHandle(oswp_blackvols),
>
>     swaption_dates,
>
>     smile_tenors,
>
>     swap_index
>
> )
>
>



-- 
*Giuseppe Trapani*

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

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

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
>

Re: [Quantlib-users] ORE v10 released

[Forde S. <for...@gm...>]

Hi,

Resending as I had to resubscribe.

Thanks again to Roland and his team for their continued support of ORE.

I am assessing ORE for a client, and as part of this, I am compiling a list
of the major enhancements required to close regulatory gaps.

Could you review and comment on this initial text, which will be expanded
into a more comprehensive analysis?

ORE is an extremely powerful engine to either complement the internal model
team or provide the basis of a CCR platform for smaller institutions. It is
highly extensible and configurable.It has a tremendous foundation of data
handling, market and curve building, and analytic capabilities,
complemented by a comprehensive test suite. ORE focuses on market and
counterparty credit risk analytics and includes key aspects of the Basel
III framework, but it does not have all aspects, e.g., FRTB-specific
enhancements.

 There are some key functional and non-functional gaps and considerations
to address (not in order of priority), including:

   1.

   SA-CCR (Standardised Approach for Counterparty Credit Risk):While there
   are references in the user guide (page 4) to a future release of SA-CCR,
   the timing and commitment to this is unclear.
   2.

   ES (Expected Shortfall):With FRTB's introduction under Basel III,
   Expected Shortfall (ES) replaced VaR as the primary risk measure for the
   internal models approach. While VaR is still an important risk metric,
   implementing ES requires capturing the tail risk and different liquidity
   horizons for various asset classes and risk factors. There is a need to
   consider backtesting requirements, as ES introduces its challenges in that
   realm. ES means not just changing the formulae but also adopting a new risk
   mindset, focusing on tail risks and severe market shocks.
   3.

   SA-CVA (Standardised Approach for Credit Valuation Adjustment
   Risk):ORE's emphasis on xVA calculations provides a strong foundation, but
   the transition from a basic approach (e.g. KVA is calculated using the
   limited version fo BA-CVA) to a standardised approach like SA-CVA can be
   intricate. The details of risk factor modellability and NMRFs are
   fundamental to FRTB and will require a deep integration into ORE’s
   calculation mechanics. It's also worth noting that SA-CVA will require
   banks to possess a more granular level of data on their counterparties and
   credit risk mitigants.
   4.

   Enhanced data quality and traceability requirements. FRTB places a
   strong emphasis on data quality, and institutions are required to
   demonstrate the traceability of their risk data. This could necessitate not
   only infrastructure upgrades but also potential enhancements to ORE's data
   intake and validation processes. Additionally, there might be a need for
   more robust reporting functionalities to satisfy regulatory inquiries and
   audits.
   5.

   Scalability and Performance. Given the complexity of Basel III
   calculations, especially under approaches like SA-CCR or IMA of FRTB,
   there's a need for high computational efficiency. ORE's ability to scale
   and perform under these demands might be a consideration.
   6.

   Integration with other systems: If ORE is to be the foundation of a CCR
   platform, its ability to integrate with other bank systems (e.g., front
   office, collateral management, settlement, market data, broader risk
   systems, accounting systems) is crucial. The flow of data between these
   systems must be seamless. Capital markets are slowly standardising
   reporting (e.g. ISDA CRIF AND CDM) and there is a need to map the future
   direction against ORE’s capabilities.
   7.

   User Interface and Reporting: The system's ability to generate detailed
   reports, both for internal risk management and regulatory reporting, is
   vital. ORE's user interface might require enhancements to accommodate the
   added complexities of FRTB and SA-CCR.
   8.

   Future-proofing: Regulatory landscapes continue to evolve. Ensure any
   extensions built upon ORE are designed in a modular fashion, allowing for
   easier upgrades or adjustments as regulations change.

Thank you,

Forde




On Thu, 22 Jun 2023 at 20:29, Roland Lichters via QuantLib-users <
qua...@li...> wrote:

> Dear all,
>
>
>
> The 10th ORE release is out on https://github.com/OpenSourceRisk
>
>
>
> As announced, we have rolled out a range of hybrid products this time:
>
>    - Composite trades
>    - Collateralized Bond Obligations
>    - Generic Total Return Swaps and Contracts For Difference (CFDs)
>    accepting almost arbitrary underlying baskets
>    - Convertible Bonds and Asset Swapped Convertible Option Transactions
>    (ASCOTs)
>
>
>
> Moreover, we added to the analytics scope:
>
>    - ISDA's Standard Initial Margin Model (SIMM) with all versions from
>    inception to the most recent
>    - a proof-of-concept Credit Portfolio Model to construct portfolio
>    loss distributions due to credit migration, credit default and market moves
>    across cash products and derivatives
>
>
>
> See the release notes in
> https://github.com/OpenSourceRisk/Engine/blob/v1.8.10.0/News.txt
>
> or in the userguide.pdf at
> https://github.com/OpenSourceRisk/Engine/releases/tag/v1.8.10.0 for
> references to the related examples.
>
>
>
> And finally, the ORE Python module has been updated and can be installed
> with
>
>
>
> pip install open-source-risk-engine
>
>
>
> Please explore, all feedback is welcome!
>
>
>
> Best wishes,
>
> Roland
>
>
>
>
>
> *Roland Lichters*
>
> *Quantitative Services*
>
> [image: Logo Description automatically generated]
>
> Maurenbrecherstrasse 16, 47803 Krefeld, Deutschland
>
> office *+49* *2151 9284800 *mobile* +49 172 9985795*
>
> *rol...@ac... <rol...@ac...>*
>
> *acadia.inc <https://acadia.inc/>*
>
>
> [image: signature_2811593998]
> <https://www.youtube.com/channel/UCsMyFt94Jyfwo-ecLBpy5xw>[image:
> signature_1151196288] <https://twitter.com/AcadiaSoft_>[image:
> signature_3977098555] <https://www.linkedin.com/company/acadiasoft-inc>
>
>
>
>
>
>
>
> The information contained in this e-mail, and any attachment, is
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any
> information contained therein, by any other person is not authorized. If
> you are not the intended recipient please return the e-mail to the sender
> and delete it from your computer. The acadia.inc privacy policy is
> available on our website.
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] ORE v10 released

[Forde S. <for...@gm...>]

I am assessing ORE for a client, and as part of this, I am compiling a list
of the major enhancements required to close regulatory gaps.

Could you review and comment on this initial text, which will be expanded
into a more comprehensive analysis?

ORE is an extremely powerful engine to either complement the internal model
team or provide the basis of a CCR platform for smaller institutions. It is
highly extensible and configurable.It has a tremendous foundation of data
handling, market and curve building, and analytic capabilities,
complemented by a comprehensive test suite. ORE focuses on market and
counterparty credit risk analytics and includes key aspects of the Basel
III framework, but it does not have all aspects, e.g., FRTB-specific
enhancements.

 There are some key functional and non-functional gaps and considerations
to address (not in order of priority), including:

   1.

   SA-CCR (Standardised Approach for Counterparty Credit Risk):While there
   are references in the user guide (page 4) to a future release of SA-CCR,
   the timing and commitment to this is unclear.
   2.

   ES (Expected Shortfall):With FRTB's introduction under Basel III,
   Expected Shortfall (ES) replaced VaR as the primary risk measure for the
   internal models approach. While VaR is still an important risk metric,
   implementing ES requires capturing the tail risk and different liquidity
   horizons for various asset classes and risk factors. There is a need to
   consider backtesting requirements, as ES introduces its challenges in that
   realm. ES means not just changing the formulae but also adopting a new risk
   mindset, focusing on tail risks and severe market shocks.
   3.

   SA-CVA (Standardised Approach for Credit Valuation Adjustment
   Risk):ORE's emphasis on xVA calculations provides a strong foundation, but
   the transition from a basic approach (e.g. KVA is calculated using the
   limited version fo BA-CVA) to a standardised approach like SA-CVA can be
   intricate. The details of risk factor modellability and NMRFs are
   fundamental to FRTB and will require a deep integration into ORE’s
   calculation mechanics. It's also worth noting that SA-CVA will require
   banks to possess a more granular level of data on their counterparties and
   credit risk mitigants.
   4.

   Enhanced data quality and traceability requirements. FRTB places a
   strong emphasis on data quality, and institutions are required to
   demonstrate the traceability of their risk data. This could necessitate not
   only infrastructure upgrades but also potential enhancements to ORE's data
   intake and validation processes. Additionally, there might be a need for
   more robust reporting functionalities to satisfy regulatory inquiries and
   audits.
   5.

   Scalability and Performance. Given the complexity of Basel III
   calculations, especially under approaches like SA-CCR or IMA of FRTB,
   there's a need for high computational efficiency. ORE's ability to scale
   and perform under these demands might be a consideration.
   6.

   Integration with other systems: If ORE is to be the foundation of a CCR
   platform, its ability to integrate with other bank systems (e.g., front
   office, collateral management, settlement, market data, broader risk
   systems, accounting systems) is crucial. The flow of data between these
   systems must be seamless. Capital markets are slowly standardising
   reporting (e.g. ISDA CRIF AND CDM) and there is a need to map the future
   direction against ORE’s capabilities.
   7.

   User Interface and Reporting: The system's ability to generate detailed
   reports, both for internal risk management and regulatory reporting, is
   vital. ORE's user interface might require enhancements to accommodate the
   added complexities of FRTB and SA-CCR.
   8.

   Future-proofing: Regulatory landscapes continue to evolve. Ensure any
   extensions built upon ORE are designed in a modular fashion, allowing for
   easier upgrades or adjustments as regulations change.

Thank you,

Forde





On Thu, 22 Jun 2023 at 20:29, Roland Lichters via QuantLib-users <
qua...@li...> wrote:

> Dear all,
>
>
>
> The 10th ORE release is out on https://github.com/OpenSourceRisk
>
>
>
> As announced, we have rolled out a range of hybrid products this time:
>
>    - Composite trades
>    - Collateralized Bond Obligations
>    - Generic Total Return Swaps and Contracts For Difference (CFDs)
>    accepting almost arbitrary underlying baskets
>    - Convertible Bonds and Asset Swapped Convertible Option Transactions
>    (ASCOTs)
>
>
>
> Moreover, we added to the analytics scope:
>
>    - ISDA's Standard Initial Margin Model (SIMM) with all versions from
>    inception to the most recent
>    - a proof-of-concept Credit Portfolio Model to construct portfolio
>    loss distributions due to credit migration, credit default and market moves
>    across cash products and derivatives
>
>
>
> See the release notes in
> https://github.com/OpenSourceRisk/Engine/blob/v1.8.10.0/News.txt
>
> or in the userguide.pdf at
> https://github.com/OpenSourceRisk/Engine/releases/tag/v1.8.10.0 for
> references to the related examples.
>
>
>
> And finally, the ORE Python module has been updated and can be installed
> with
>
>
>
> pip install open-source-risk-engine
>
>
>
> Please explore, all feedback is welcome!
>
>
>
> Best wishes,
>
> Roland
>
>
>
>
>
> *Roland Lichters*
>
> *Quantitative Services*
>
> [image: Logo Description automatically generated]
>
> Maurenbrecherstrasse 16, 47803 Krefeld, Deutschland
>
> office *+49* *2151 9284800 *mobile* +49 172 9985795*
>
> *rol...@ac... <rol...@ac...>*
>
> *acadia.inc <https://acadia.inc/>*
>
>
> [image: signature_2811593998]
> <https://www.youtube.com/channel/UCsMyFt94Jyfwo-ecLBpy5xw>[image:
> signature_1151196288] <https://twitter.com/AcadiaSoft_>[image:
> signature_3977098555] <https://www.linkedin.com/company/acadiasoft-inc>
>
>
>
>
>
>
>
> The information contained in this e-mail, and any attachment, is
> confidential and is intended solely for the use of the intended recipient.
> Access, copying or re-use of the e-mail or any attachment, or any
> information contained therein, by any other person is not authorized. If
> you are not the intended recipient please return the e-mail to the sender
> and delete it from your computer. The acadia.inc privacy policy is
> available on our website.
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] is there a way to set endOfMonth for a swapindex?

[Arkadiy N. <ark...@gm...>]

I wanted to create a GH issue (to suggest adding the parameter to SwapIndex
signature),  but want to make sure I am not missing anything

https://github.com/lballabio/QuantLib/blob/520d62fdec38bfd0269f111ff0f7b04b24a4d56a/ql/indexes/swapindex.hpp#L41
I thought that perhaps it inherits from the reference iBORIndex, but that
does not seem to be the case - a one-payment swap vs an  iBOR with
identical characteristics would generate identical fixings, until iBOR's
endOfMonth is set to "True"

Thank you!

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

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

[Peter C. <pca...@gm...>]

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

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

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

[Peter C. <pca...@gm...>]

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

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

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

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

[Quantlib-users] m over n callable convertible bond pricing

[thanatos <tha...@gm...>]

Hi there,

I'm new to QuantLib and was trying to price a convertible bond with
QuantLib.

I saw a example in
https://github.com/lballabio/QuantLib/blob/master/Examples/ConvertibleBonds/ConvertibleBonds.cpp,
which implements 2 Soft Call in second/fourth year with 1.2 trigger.
However, I'm facing a different soft call situation, say

>From 2rd to 4th year, any m(20) days over n(30) days, price is above the
trigger(1.2), then we do the soft call.

Can I implemented this situation with QuantLib? Any help is appreciate.

Eric

[Quantlib-users] QuantLib 1.31.1 released

[Luigi B. <lui...@gm...>]

QuantLib 1.31.1 has been released and is available for download at <
https://www.quantlib.org/download.shtml>.  It fixes a regression in version
1.31.

The short list of changes for this release is at <
https://www.quantlib.org/reference/history.html>.

If you have any problems with this release, please report them here on the
QuantLib mailing list (<qua...@li...>), or open a
GitHub issue at <https://github.com/lballabio/quantlib/issues>.

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

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

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

Re: [Quantlib-users] QuantLib 1.31 released

[Luigi B. <lui...@gm...>]

I'd follow the instructions at https://www.quantlib.org/install/macosx.shtml,
except that:

-  if you want Boost to be in that directory as well, don't use brew; see
https://www.boost.org/doc/libs/1_82_0/more/getting_started/unix-variants.html
instead.  A header-only installation should be enough.
- when you run ./configure inside QuantLib, instead
of --prefix=${HOME}/local/
use --prefix=/Users/XXX/Library/CloudStorage/Dropbox/QL_Work and if you
installed Boost in a custom location, also change --with-boost-include
accordingly.

Hope this helps,
    Luigi


On Wed, Jul 19, 2023 at 7:13 PM Brian Smith <bri...@gm...>
wrote:

> Hi,
>
> I am wondering if it is possible to install quanlib and its all
> dependencies in a specific folder for
> e.g. /Users/XXX/Library/CloudStorage/Dropbox/QL_Work
>
> My OS is macOS High Sierra
>
> Are there any specific configuration I need to follow?
>
> A detailed instruction will be very helpful.
>
> Thanks for your time.
>
> On Tue, 18 Jul 2023 at 18:38, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> QuantLib 1.31 has been released and is available for download at <
>> https://www.quantlib.org/download.shtml>.
>>
>> The list of changes for this release is at <
>> https://www.quantlib.org/reference/history.html>.
>>
>> If you have any problems with this release, please report them here on
>> the QuantLib mailing list (<qua...@li...>), or
>> open a GitHub issue at <https://github.com/lballabio/quantlib/issues>.
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] QuantLib 1.31 released

[Brian S. <bri...@gm...>]

Hi,

I am wondering if it is possible to install quanlib and its all
dependencies in a specific folder for
e.g. /Users/XXX/Library/CloudStorage/Dropbox/QL_Work

My OS is macOS High Sierra

Are there any specific configuration I need to follow?

A detailed instruction will be very helpful.

Thanks for your time.

On Tue, 18 Jul 2023 at 18:38, Luigi Ballabio <lui...@gm...>
wrote:

> QuantLib 1.31 has been released and is available for download at <
> https://www.quantlib.org/download.shtml>.
>
> The list of changes for this release is at <
> https://www.quantlib.org/reference/history.html>.
>
> If you have any problems with this release, please report them here on the
> QuantLib mailing list (<qua...@li...>), or open a
> GitHub issue at <https://github.com/lballabio/quantlib/issues>.
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves

[Luigi B. <lui...@gm...>]

Hi Norbert,
    the IborIborBasisSwapRateHelper is a relatively recent addition to the
library.  QuantLibXL hasn't been updated in a while, and I'm afraid I have
no idea if a release is on the horizon.  In any case, you can find
workarounds in Ametrano and Bianchetti (
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2219548) who also use
basis swaps in their calibration sets.

Hope this helps,
    Luigi


On Tue, Jul 18, 2023 at 11:11 AM Patzschke, Norbert <
nor...@fi...> wrote:

> I have the following situation:
>
>
>
> Discounting curve = ESTR
>
> Basis curve = Eonia-6m
>
> Forward curve = Eonia-1m, given by basis swaps (Eonia-6m vs Eonia-1m) with
> spreads
>
>
>
> The curves ESTR and Eonia-6m can be generated in QuantlibXL. But how can I
> create the curve Eonia-1m in QuantlibXL? In the Quantlib there is
> IborIborBasisSwapRateHelper for this purpose. Is there a corresponding
> function in QuantlibXL?
>
>
>
> Regards,
>
> Norbert
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves

[Ben W. <ben...@ma...>]

You can always make the rate zero you will have a pure basis curve.

Quantlib does not connect curves directly. You can simulate connected
curves by sharing quote objects between curves.


On Wed, 19 July 2023, 9:37 pm Patzschke, Norbert, <
nor...@fi...> wrote:

> Thanks for your quick answer. qlSwapHelper2 builts a vanilla swap with a
> fixed leg paying *Rate* and a floating leg paying *IborIndex*. It is not
> possible to use an Euribor object as *Rate*.
>
>
>
> PS
>
> There was a typo in my question. It should of course be Euribor-1m and
> Euribor-6m.
>
>
>
> *Von:* Ben Watson <ben...@ma...>
> *Gesendet:* Dienstag, 18. Juli 2023 11:55
> *An:* Patzschke, Norbert <nor...@fi...>;
> qua...@li...
> *Betreff:* RE: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves
>
>
>
> WARNUNG: Diese Email stammt von einem externen Absender! Bitte gehen Sie
> mit den in dieser Nachricht enthaltenen Dateien und Links vorsichtig um!
>
>
>
> Easy….
>
>
>
> qlSwapRateHelper2(
>
>         string ObjectId
>
>         string Rate                                           This is
> EURIBOR 6m as a Quoteobject
>
>         long SettlDays
>
>         string Tenor
>
>         string Calendar
>
>         string FixedLegFrequency
>
>         string FixedLegConvention
>
>         string FixedLegDayCounter
>
>         string IborIndex
>
>         string Spread                                       This is 6s/1s
> basis as a Quoteobject
>
>         string ForwardStart
>
>         string DiscountingCurve
>
>         string PillarDate
>
>         long CustomPillarDate
>
>         bool Permanent
>
>         any Trigger
>
>         bool Overwrite)
>
>
>
> Ben
>
>
>
> *From:* Patzschke, Norbert <nor...@fi...>
> *Sent:* Tuesday, July 18, 2023 6:35 PM
> *To:* qua...@li...
> *Subject:* [Quantlib-users] QuantlibXL: Bootstrapping multiple curves
>
>
>
> I have the following situation:
>
>
>
> Discounting curve = ESTR
>
> Basis curve = Eonia-6m
>
> Forward curve = Eonia-1m, given by basis swaps (Eonia-6m vs Eonia-1m) with
> spreads
>
>
>
> The curves ESTR and Eonia-6m can be generated in QuantlibXL. But how can I
> create the curve Eonia-1m in QuantlibXL? In the Quantlib there is
> IborIborBasisSwapRateHelper for this purpose. Is there a corresponding
> function in QuantlibXL?
>
>
>
> Regards,
>
> Norbert
>

Re: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves

[Patzschke, N. <nor...@fi...>]

Thanks for your quick answer. qlSwapHelper2 builts a vanilla swap with a fixed leg paying Rate and a floating leg paying IborIndex. It is not possible to use an Euribor object as Rate.

PS
There was a typo in my question. It should of course be Euribor-1m and Euribor-6m.

Von: Ben Watson <ben...@ma...>
Gesendet: Dienstag, 18. Juli 2023 11:55
An: Patzschke, Norbert <nor...@fi...>; qua...@li...
Betreff: RE: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves

WARNUNG: Diese Email stammt von einem externen Absender! Bitte gehen Sie mit den in dieser Nachricht enthaltenen Dateien und Links vorsichtig um!

Easy....

qlSwapRateHelper2(
        string ObjectId
        string Rate                                           This is EURIBOR 6m as a Quoteobject
        long SettlDays
        string Tenor
        string Calendar
        string FixedLegFrequency
        string FixedLegConvention
        string FixedLegDayCounter
        string IborIndex
        string Spread                                       This is 6s/1s basis as a Quoteobject
        string ForwardStart
        string DiscountingCurve
        string PillarDate
        long CustomPillarDate
        bool Permanent
        any Trigger
        bool Overwrite)

Ben

From: Patzschke, Norbert <nor...@fi...<mailto:nor...@fi...>>
Sent: Tuesday, July 18, 2023 6:35 PM
To: qua...@li...<mailto:qua...@li...>
Subject: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves

I have the following situation:

Discounting curve = ESTR
Basis curve = Eonia-6m
Forward curve = Eonia-1m, given by basis swaps (Eonia-6m vs Eonia-1m) with spreads

The curves ESTR and Eonia-6m can be generated in QuantlibXL. But how can I create the curve Eonia-1m in QuantlibXL? In the Quantlib there is IborIborBasisSwapRateHelper for this purpose. Is there a corresponding function in QuantlibXL?

Regards,
Norbert

[Quantlib-users] QuantLib 1.31 released

[Luigi B. <lui...@gm...>]

QuantLib 1.31 has been released and is available for download at <
https://www.quantlib.org/download.shtml>.

The list of changes for this release is at <
https://www.quantlib.org/reference/history.html>.

If you have any problems with this release, please report them here on the
QuantLib mailing list (<qua...@li...>), or open a
GitHub issue at <https://github.com/lballabio/quantlib/issues>.

Re: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves

[Ben W. <ben...@ma...>]

Easy..

 

qlSwapRateHelper2(

        string ObjectId

        string Rate                                           This is
EURIBOR 6m as a Quoteobject

        long SettlDays

        string Tenor

        string Calendar

        string FixedLegFrequency

        string FixedLegConvention

        string FixedLegDayCounter

        string IborIndex

        string Spread                                       This is 6s/1s
basis as a Quoteobject

        string ForwardStart

        string DiscountingCurve

        string PillarDate

        long CustomPillarDate

        bool Permanent

        any Trigger

        bool Overwrite)

 

Ben

 

From: Patzschke, Norbert <nor...@fi...> 
Sent: Tuesday, July 18, 2023 6:35 PM
To: qua...@li...
Subject: [Quantlib-users] QuantlibXL: Bootstrapping multiple curves

 

I have the following situation:

 

Discounting curve = ESTR

Basis curve = Eonia-6m

Forward curve = Eonia-1m, given by basis swaps (Eonia-6m vs Eonia-1m) with
spreads

 

The curves ESTR and Eonia-6m can be generated in QuantlibXL. But how can I
create the curve Eonia-1m in QuantlibXL? In the Quantlib there is
IborIborBasisSwapRateHelper for this purpose. Is there a corresponding
function in QuantlibXL?

 

Regards,

Norbert

[Quantlib-users] QuantlibXL: Bootstrapping multiple curves

[Patzschke, N. <nor...@fi...>]

I have the following situation:

Discounting curve = ESTR
Basis curve = Eonia-6m
Forward curve = Eonia-1m, given by basis swaps (Eonia-6m vs Eonia-1m) with spreads

The curves ESTR and Eonia-6m can be generated in QuantlibXL. But how can I create the curve Eonia-1m in QuantlibXL? In the Quantlib there is IborIborBasisSwapRateHelper for this purpose. Is there a corresponding function in QuantlibXL?

Regards,
Norbert

[Quantlib-users] Second release candidate for version 1.31

[Luigi B. <lui...@gm...>]

Hello everybody,
    a second release candidate addressing some performance problems is
available at <https://github.com/lballabio/QuantLib/releases/tag/1.31rc2>.
If you have time, please try it out and report here on the mailing list.
Prerelease Python wheels can be installed from TestPyPI by running

    python3 -m pip install -U -i https://test.pypi.org/simple/ --pre
QuantLib

Thanks!

    Luigi