quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] RV: Overnight Index Future not working

[Esteban L. A. B. <est...@ho...>]

Thanks!

Obtener Outlook para iOS<https://aka.ms/o0ukef>
________________________________
De: Luigi Ballabio <lui...@gm...>
Enviado: Wednesday, July 10, 2024 5:46:33 AM
Para: Esteban López Araiza Bravo <est...@ho...>
Cc: qua...@li... <Qua...@li...>
Asunto: Re: [Quantlib-users] RV: Overnight Index Future not working

Hi Esteban,
    this should be fixed by <https://github.com/lballabio/QuantLib/pull/2013>.  If you have a chance, please try out the release candidate I published yesterday; you can install it with

    pip install -i https://test.pypi.org/simple/ QuantLib==1.35rc0

Thanks,
    Luigi


On Fri, Jun 7, 2024 at 6:53 PM Esteban López Araiza Bravo <est...@ho...<mailto:est...@ho...>> wrote:


Hi Luigi, sorry for the late response, I was confirming wih CME the specifications for the F-TIIE futures.
Regarding your question, yes, It accrues the fixing from April 30th and it works the same for weekends, it will accrue the friday's fixing.  When the maturity is holiday, the current code doesn´t seem to mind.

I will keep in touch.
Thank you

________________________________
De: Luigi Ballabio <lui...@gm...<mailto:lui...@gm...>>
Enviado: jueves, 30 de mayo de 2024 07:36 a. m.
Para: Esteban López Araiza Bravo <est...@ho...<mailto:est...@ho...>>
Cc: Qua...@li...<mailto:Qua...@li...> <Qua...@li...<mailto:Qua...@li...>>
Asunto: Re: [Quantlib-users] Overnight Index Future not working

Hello Esteban,
    when you create the first ql.OvernightIndexFutureRateHelper you're passing May 1st as the start date, and the code assumes that it's a fixing date.  We'll have to add code to manage that case.  How is this supposed to work?  Does the future accrue the fixing from the April 30th for the day between 1st and 2nd May?  And I assume the same happens if the maturity is a holiday, right?

Luigi


On Tue, May 28, 2024 at 6:16 PM Esteban López Araiza Bravo <est...@ho...<mailto:est...@ho...>> wrote:
Hi! I'm having trouble making an OvernightIndexFutureRateHelper. When I try to bootstrap it, the following error arises:

RuntimeError: 1st iteration failed at 1st alive instrument, pillar May 31st 2024 maturity May 31st 2024, reference date May 9th, 2024: missing rate on May 1st 2024 for index TIIE_OISTN Actual/360

But when I try to add the fixing for May 1st 2024, the next error arises:

RuntimeError: At least one invalid fixing provided: Wednesday May 1st 2024, 0.1102

May 1st is a holiday in Mexico, but the future compounds every day of the month, how can I workaround this issue or is there another way to bootstrap this kind of future?

I will attach the code.
Thanks!

Obtener Outlook para iOS<https://aka.ms/o0ukef>
_______________________________________________
QuantLib-users mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-users
_______________________________________________
QuantLib-users mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] RV: Overnight Index Future not working

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

Hi Esteban,
    this should be fixed by <https://github.com/lballabio/QuantLib/pull/2013>.
If you have a chance, please try out the release candidate I published
yesterday; you can install it with

    pip install -i https://test.pypi.org/simple/ QuantLib==1.35rc0

Thanks,
    Luigi


On Fri, Jun 7, 2024 at 6:53 PM Esteban López Araiza Bravo <
est...@ho...> wrote:

>
>
> Hi Luigi, sorry for the late response, I was confirming wih CME the
> specifications for the F-TIIE futures.
> Regarding your question, yes, It accrues the fixing from April 30th and
> it works the same for weekends, it will accrue the friday's fixing.  When
> the maturity is holiday, the current code doesn´t seem to mind.
>
> I will keep in touch.
> Thank you
>
> ------------------------------
> *De:* Luigi Ballabio <lui...@gm...>
> *Enviado:* jueves, 30 de mayo de 2024 07:36 a. m.
> *Para:* Esteban López Araiza Bravo <est...@ho...>
> *Cc:* Qua...@li... <
> Qua...@li...>
> *Asunto:* Re: [Quantlib-users] Overnight Index Future not working
>
> Hello Esteban,
>     when you create the first ql.OvernightIndexFutureRateHelper you're
> passing May 1st as the start date, and the code assumes that it's a fixing
> date.  We'll have to add code to manage that case.  How is this supposed to
> work?  Does the future accrue the fixing from the April 30th for the day
> between 1st and 2nd May?  And I assume the same happens if the maturity is
> a holiday, right?
>
> Luigi
>
>
> On Tue, May 28, 2024 at 6:16 PM Esteban López Araiza Bravo <
> est...@ho...> wrote:
>
> Hi! I'm having trouble making an OvernightIndexFutureRateHelper. When I
> try to bootstrap it, the following error arises:
>
> RuntimeError: 1st iteration failed at 1st alive instrument, pillar May
> 31st 2024 maturity May 31st 2024, reference date May 9th, 2024: missing
> rate on May 1st 2024 for index TIIE_OISTN Actual/360
>
> But when I try to add the fixing for May 1st 2024, the next error arises:
>
> RuntimeError: At least one invalid fixing provided: Wednesday May 1st
> 2024, 0.1102
>
> May 1st is a holiday in Mexico, but the future compounds every day of the
> month, how can I workaround this issue or is there another way to bootstrap
> this kind of future?
>
> I will attach the code.
> Thanks!
>
> Obtener Outlook para iOS <https://aka.ms/o0ukef>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] 1.35 release candidate

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

Prerelease Python wheels are also available from TestPyPi; use

    pip install -i https://test.pypi.org/simple/ QuantLib==1.35rc0

to check it out.  There is also an experimental, no-guarantees nupkg for
C#; see https://int.nugettest.org/packages/QuantLib/1.35.0-rc for info.

    Luigi


On Tue, Jul 9, 2024 at 5:17 PM Luigi Ballabio <lui...@gm...>
wrote:

> Hi all,
>    a release candidate for QuantLib 1.35 is available at <
> https://github.com/lballabio/QuantLib/releases/tag/v1.35rc>.  If you have
> some time, please try it out and report any problems here on the mailing
> list.  Thanks!
>
>     Luigi
>
>

[Quantlib-users] 1.35 release candidate

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

Hi all,
   a release candidate for QuantLib 1.35 is available at <
https://github.com/lballabio/QuantLib/releases/tag/v1.35rc>.  If you have
some time, please try it out and report any problems here on the mailing
list.  Thanks!

    Luigi

Re: [Quantlib-users] Should InterpolatedDiscountCurve register with evaluation date?

[Wei Li <ttl...@gm...>]

Hello Luigi,

Thank you for your kind explanation. What I am trying to do is to calculate
the theta per day for exotic options by bumping the system's evaluation
date one day later. The vol model and class I am using is the
SabrSmileSection and a customized volatility surface class. I am asking
because I discovered three small problems after bumping the date:

1) I am constructing the vol surface with fixed reference date (and fixed
forward dates when calibrating the SABR parameters)  the black variance /
black vol I am getting (by calling BlackVolTermStructure::blackVariance or
BlackVolTermStructure::blackVol) still have the original Time t, not one
day shorter, after I bump the evaluation date. That's because it is using t
= timeFromReference(forwardDate) which always starts from the original
reference date. As a result, the variance is larger than expected.

2) In sabrsmilesection.hpp, the constructor takes an explicitly-passed
forward date but still sets the isFloating_ as true. That's my bad, because
I am still using the 1.23 version and I noticed the new version already
fixed this.

3) And regarding your question, right now I am using the one day later
forward price as the new spot and the discount factor from the bumped date
to the settlement date.

Cheers,
Wei

On Mon, Jun 24, 2024 at 6:00 PM Luigi Ballabio <lui...@gm...>
wrote:

> Hello Wei,
>     that is a known issue but it doesn't have an easy solution.  In short:
> when passing an explicit reference date to PiecewiseYieldCurve, we're
> saying that we want to discount to that date but this doesn't mean it
> should also be taken as the evaluation date; it might be spot, i.e., a
> couple of business days after the evaluation date.
>
> In turn, this means that we can't use the passed reference date to
> calculate the start and end of the swaps contained in the helpers; it must
> still be done using the evaluation date.  So when the evaluation date
> changes, the reference date stays the same but the swaps underlying the
> helpers move their start and end dates.
>
> If you have to move the evaluation date, one thing that might work is
> calling freeze() on the piecewise curve after it's bootstrapped; this tells
> it not to recalculate.
>
> However, I'm not really sure of your use case here.  You're moving the
> evaluation date but you want the discount factors to stay fixed?  What is
> it that you're trying to model?
>
> Hope this helps,
>     Luigi
>
>
>
>
>
> On Fri, Jun 21, 2024 at 3:44 AM Wei Li <ttl...@gm...> wrote:
>
>> Hello Luigi,
>>
>> I get your point, and now I have encountered a new problem (that was the
>> reason I am exploring this piece of code): I am following the example in
>> test-suite\piecewiseyieldcurve.cpp, function
>> tesetiterativeBootstrapRetries(), and I am trying to bootstrap a EUR curve
>> using a USD interpolated discount curve and the EUR/USD swap quotes (with
>> the help of FxSwapRateHelper class). From my understanding, neither USD
>> discount curve (of type InterpolatedDiscountCurve<LogLinear>) and the
>> bootstrapped EUR curve (of type PiecewiseYieldCurve<Discount, LogLinear,
>> IterativeBootstrap>) should change with respect to evaluation date (they
>> all have base class constructors with an explicitly-passed reference date).
>>
>> However, when I am trying to get the discount factors say one year from
>> now on, using both curves, before and after I bump the evaluation date by
>> one day, I see that the discount factor of USD curve remains the same after
>> the evaluation date bump, but the discount factor of bootstrapped EUR curve
>> gets changed. As a result, when I am calculating the forecast fx forward
>> rate by
>>
>> fx_fwd = fx_spot * usd_curve.discount(spot_date) /
>> usd_curve.discount(forward_date) / (eur_curve.discount(spot_date) /
>> eur_curve.discount(forward_date))
>>
>> Before and after I bump the evaluation date it gives different results
>> (not only dfs on spot_date and forward_date get changed, but
>> eur_curve.discount(spot_date) / eur_curve.discount(forward_date) also gets
>> changed)  . But I am expecting the calculated fx_fwd should be the same?
>>
>> What am I missing here?
>>
>> Thank you very much for your help!
>>
>> Cheers,
>> Wei
>>
>> On Thu, Jun 20, 2024 at 4:43 PM Luigi Ballabio <lui...@gm...>
>> wrote:
>>
>>> Hello,
>>>     no, InterpolatedDiscountCurve doesn't change with respect to the
>>> evaluation date.  That's why it's built by explicitly specifying discount
>>> factors at given dates.  If I build a curve saying, for instance,
>>>
>>>     vector<Date> dates = { Date(20, Jun, 2024), Date(29, Jul, 2024),
>>> Date(31, Aug, 2024), Date(30, Sep, 2024) };
>>>     vector<DiscountFactor> dfs = { 1.0000, 0.9999, 0.9993, 0.9988 };
>>>     auto curve = InterpolatedDiscountCurve<LogLinear> >(dates, dfs,
>>> Actual365Fixed());
>>>
>>> that says that the discount on September 30th 2024 is 0.9988, should the
>>> discount for that date change when we move the evaluation date?  And if it
>>> should change, how do we move the dates so that the discount changes?  Do
>>> we shift them like we shifted the evaluation date?  We might not have that
>>> information, we only get notified that the evaluation date changed.
>>>
>>> Currently, we sidestep the whole problem by keeping the curve as it was
>>> specified regardless of the evaluation date.
>>>
>>> Regards,
>>>     Luigi
>>>
>>>
>>>
>>> On Thu, Jun 20, 2024 at 9:33 AM Wei Li <ttl...@gm...> wrote:
>>>
>>>> Dear all,
>>>>
>>>> We are constructing yield curves using bootstrapped date and discount
>>>> factor pairs, i.e., we use the InterpolatedDiscountCurve class. But when I
>>>> am looking at the PUBLIC constructors of this class (all three of them take
>>>> a date vector and a discount factor vector as basic form), I see that they
>>>> all internally call the base class (YieldTermStructure) constructor using
>>>> the first date in the vector (dates.at(0)) as an explicitly-passed
>>>> reference date. It means this class doesn't register with the change of
>>>> QuantLib's evaluation date.
>>>>
>>>> So when I am using these curves like this:
>>>>
>>>> Date delivery = Date (30, September, 2024);
>>>> DiscountFactor df1 = my_curve -> discount(delivery);
>>>>
>>>> Date originalEvalDate = Settings::instance().evaluationDate();
>>>> Settings::instance().evaluationDate() = originalEvalDate + 30;
>>>>
>>>> DiscountFactor df2 = my_curve -> discount(delivery);
>>>>
>>>> I would expect the df2 to be different from df1, but it is not the
>>>> case. Since the reference date of my_curve never got changed, the
>>>> timeFromReference remained the same and hence the discount factor.
>>>>
>>>> Is there some way to construct a discount curve using dates and dfs,
>>>> and the curve would reflect the change of evaluation date, or am I totally
>>>> wrong to expect it would?
>>>>
>>>> Cheers,
>>>> Wei
>>>>
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>

Re: [Quantlib-users] Should InterpolatedDiscountCurve register with evaluation date?

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

Hello Wei,
    that is a known issue but it doesn't have an easy solution.  In short:
when passing an explicit reference date to PiecewiseYieldCurve, we're
saying that we want to discount to that date but this doesn't mean it
should also be taken as the evaluation date; it might be spot, i.e., a
couple of business days after the evaluation date.

In turn, this means that we can't use the passed reference date to
calculate the start and end of the swaps contained in the helpers; it must
still be done using the evaluation date.  So when the evaluation date
changes, the reference date stays the same but the swaps underlying the
helpers move their start and end dates.

If you have to move the evaluation date, one thing that might work is
calling freeze() on the piecewise curve after it's bootstrapped; this tells
it not to recalculate.

However, I'm not really sure of your use case here.  You're moving the
evaluation date but you want the discount factors to stay fixed?  What is
it that you're trying to model?

Hope this helps,
    Luigi





On Fri, Jun 21, 2024 at 3:44 AM Wei Li <ttl...@gm...> wrote:

> Hello Luigi,
>
> I get your point, and now I have encountered a new problem (that was the
> reason I am exploring this piece of code): I am following the example in
> test-suite\piecewiseyieldcurve.cpp, function
> tesetiterativeBootstrapRetries(), and I am trying to bootstrap a EUR curve
> using a USD interpolated discount curve and the EUR/USD swap quotes (with
> the help of FxSwapRateHelper class). From my understanding, neither USD
> discount curve (of type InterpolatedDiscountCurve<LogLinear>) and the
> bootstrapped EUR curve (of type PiecewiseYieldCurve<Discount, LogLinear,
> IterativeBootstrap>) should change with respect to evaluation date (they
> all have base class constructors with an explicitly-passed reference date).
>
> However, when I am trying to get the discount factors say one year from
> now on, using both curves, before and after I bump the evaluation date by
> one day, I see that the discount factor of USD curve remains the same after
> the evaluation date bump, but the discount factor of bootstrapped EUR curve
> gets changed. As a result, when I am calculating the forecast fx forward
> rate by
>
> fx_fwd = fx_spot * usd_curve.discount(spot_date) /
> usd_curve.discount(forward_date) / (eur_curve.discount(spot_date) /
> eur_curve.discount(forward_date))
>
> Before and after I bump the evaluation date it gives different results
> (not only dfs on spot_date and forward_date get changed, but
> eur_curve.discount(spot_date) / eur_curve.discount(forward_date) also gets
> changed)  . But I am expecting the calculated fx_fwd should be the same?
>
> What am I missing here?
>
> Thank you very much for your help!
>
> Cheers,
> Wei
>
> On Thu, Jun 20, 2024 at 4:43 PM Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Hello,
>>     no, InterpolatedDiscountCurve doesn't change with respect to the
>> evaluation date.  That's why it's built by explicitly specifying discount
>> factors at given dates.  If I build a curve saying, for instance,
>>
>>     vector<Date> dates = { Date(20, Jun, 2024), Date(29, Jul, 2024),
>> Date(31, Aug, 2024), Date(30, Sep, 2024) };
>>     vector<DiscountFactor> dfs = { 1.0000, 0.9999, 0.9993, 0.9988 };
>>     auto curve = InterpolatedDiscountCurve<LogLinear> >(dates, dfs,
>> Actual365Fixed());
>>
>> that says that the discount on September 30th 2024 is 0.9988, should the
>> discount for that date change when we move the evaluation date?  And if it
>> should change, how do we move the dates so that the discount changes?  Do
>> we shift them like we shifted the evaluation date?  We might not have that
>> information, we only get notified that the evaluation date changed.
>>
>> Currently, we sidestep the whole problem by keeping the curve as it was
>> specified regardless of the evaluation date.
>>
>> Regards,
>>     Luigi
>>
>>
>>
>> On Thu, Jun 20, 2024 at 9:33 AM Wei Li <ttl...@gm...> wrote:
>>
>>> Dear all,
>>>
>>> We are constructing yield curves using bootstrapped date and discount
>>> factor pairs, i.e., we use the InterpolatedDiscountCurve class. But when I
>>> am looking at the PUBLIC constructors of this class (all three of them take
>>> a date vector and a discount factor vector as basic form), I see that they
>>> all internally call the base class (YieldTermStructure) constructor using
>>> the first date in the vector (dates.at(0)) as an explicitly-passed
>>> reference date. It means this class doesn't register with the change of
>>> QuantLib's evaluation date.
>>>
>>> So when I am using these curves like this:
>>>
>>> Date delivery = Date (30, September, 2024);
>>> DiscountFactor df1 = my_curve -> discount(delivery);
>>>
>>> Date originalEvalDate = Settings::instance().evaluationDate();
>>> Settings::instance().evaluationDate() = originalEvalDate + 30;
>>>
>>> DiscountFactor df2 = my_curve -> discount(delivery);
>>>
>>> I would expect the df2 to be different from df1, but it is not the case.
>>> Since the reference date of my_curve never got changed, the
>>> timeFromReference remained the same and hence the discount factor.
>>>
>>> Is there some way to construct a discount curve using dates and dfs, and
>>> the curve would reflect the change of evaluation date, or am I totally
>>> wrong to expect it would?
>>>
>>> Cheers,
>>> Wei
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] Should InterpolatedDiscountCurve register with evaluation date?

[Wei Li <ttl...@gm...>]

Hello Luigi,

I get your point, and now I have encountered a new problem (that was the
reason I am exploring this piece of code): I am following the example in
test-suite\piecewiseyieldcurve.cpp, function
tesetiterativeBootstrapRetries(), and I am trying to bootstrap a EUR curve
using a USD interpolated discount curve and the EUR/USD swap quotes (with
the help of FxSwapRateHelper class). From my understanding, neither USD
discount curve (of type InterpolatedDiscountCurve<LogLinear>) and the
bootstrapped EUR curve (of type PiecewiseYieldCurve<Discount, LogLinear,
IterativeBootstrap>) should change with respect to evaluation date (they
all have base class constructors with an explicitly-passed reference date).

However, when I am trying to get the discount factors say one year from now
on, using both curves, before and after I bump the evaluation date by one
day, I see that the discount factor of USD curve remains the same after the
evaluation date bump, but the discount factor of bootstrapped EUR curve
gets changed. As a result, when I am calculating the forecast fx forward
rate by

fx_fwd = fx_spot * usd_curve.discount(spot_date) /
usd_curve.discount(forward_date) / (eur_curve.discount(spot_date) /
eur_curve.discount(forward_date))

Before and after I bump the evaluation date it gives different results (not
only dfs on spot_date and forward_date get changed, but
eur_curve.discount(spot_date) / eur_curve.discount(forward_date) also gets
changed)  . But I am expecting the calculated fx_fwd should be the same?

What am I missing here?

Thank you very much for your help!

Cheers,
Wei

On Thu, Jun 20, 2024 at 4:43 PM Luigi Ballabio <lui...@gm...>
wrote:

> Hello,
>     no, InterpolatedDiscountCurve doesn't change with respect to the
> evaluation date.  That's why it's built by explicitly specifying discount
> factors at given dates.  If I build a curve saying, for instance,
>
>     vector<Date> dates = { Date(20, Jun, 2024), Date(29, Jul, 2024),
> Date(31, Aug, 2024), Date(30, Sep, 2024) };
>     vector<DiscountFactor> dfs = { 1.0000, 0.9999, 0.9993, 0.9988 };
>     auto curve = InterpolatedDiscountCurve<LogLinear> >(dates, dfs,
> Actual365Fixed());
>
> that says that the discount on September 30th 2024 is 0.9988, should the
> discount for that date change when we move the evaluation date?  And if it
> should change, how do we move the dates so that the discount changes?  Do
> we shift them like we shifted the evaluation date?  We might not have that
> information, we only get notified that the evaluation date changed.
>
> Currently, we sidestep the whole problem by keeping the curve as it was
> specified regardless of the evaluation date.
>
> Regards,
>     Luigi
>
>
>
> On Thu, Jun 20, 2024 at 9:33 AM Wei Li <ttl...@gm...> wrote:
>
>> Dear all,
>>
>> We are constructing yield curves using bootstrapped date and discount
>> factor pairs, i.e., we use the InterpolatedDiscountCurve class. But when I
>> am looking at the PUBLIC constructors of this class (all three of them take
>> a date vector and a discount factor vector as basic form), I see that they
>> all internally call the base class (YieldTermStructure) constructor using
>> the first date in the vector (dates.at(0)) as an explicitly-passed
>> reference date. It means this class doesn't register with the change of
>> QuantLib's evaluation date.
>>
>> So when I am using these curves like this:
>>
>> Date delivery = Date (30, September, 2024);
>> DiscountFactor df1 = my_curve -> discount(delivery);
>>
>> Date originalEvalDate = Settings::instance().evaluationDate();
>> Settings::instance().evaluationDate() = originalEvalDate + 30;
>>
>> DiscountFactor df2 = my_curve -> discount(delivery);
>>
>> I would expect the df2 to be different from df1, but it is not the case.
>> Since the reference date of my_curve never got changed, the
>> timeFromReference remained the same and hence the discount factor.
>>
>> Is there some way to construct a discount curve using dates and dfs, and
>> the curve would reflect the change of evaluation date, or am I totally
>> wrong to expect it would?
>>
>> Cheers,
>> Wei
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] Should InterpolatedDiscountCurve register with evaluation date?

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

Hello,
    no, InterpolatedDiscountCurve doesn't change with respect to the
evaluation date.  That's why it's built by explicitly specifying discount
factors at given dates.  If I build a curve saying, for instance,

    vector<Date> dates = { Date(20, Jun, 2024), Date(29, Jul, 2024),
Date(31, Aug, 2024), Date(30, Sep, 2024) };
    vector<DiscountFactor> dfs = { 1.0000, 0.9999, 0.9993, 0.9988 };
    auto curve = InterpolatedDiscountCurve<LogLinear> >(dates, dfs,
Actual365Fixed());

that says that the discount on September 30th 2024 is 0.9988, should the
discount for that date change when we move the evaluation date?  And if it
should change, how do we move the dates so that the discount changes?  Do
we shift them like we shifted the evaluation date?  We might not have that
information, we only get notified that the evaluation date changed.

Currently, we sidestep the whole problem by keeping the curve as it was
specified regardless of the evaluation date.

Regards,
    Luigi



On Thu, Jun 20, 2024 at 9:33 AM Wei Li <ttl...@gm...> wrote:

> Dear all,
>
> We are constructing yield curves using bootstrapped date and discount
> factor pairs, i.e., we use the InterpolatedDiscountCurve class. But when I
> am looking at the PUBLIC constructors of this class (all three of them take
> a date vector and a discount factor vector as basic form), I see that they
> all internally call the base class (YieldTermStructure) constructor using
> the first date in the vector (dates.at(0)) as an explicitly-passed
> reference date. It means this class doesn't register with the change of
> QuantLib's evaluation date.
>
> So when I am using these curves like this:
>
> Date delivery = Date (30, September, 2024);
> DiscountFactor df1 = my_curve -> discount(delivery);
>
> Date originalEvalDate = Settings::instance().evaluationDate();
> Settings::instance().evaluationDate() = originalEvalDate + 30;
>
> DiscountFactor df2 = my_curve -> discount(delivery);
>
> I would expect the df2 to be different from df1, but it is not the case.
> Since the reference date of my_curve never got changed, the
> timeFromReference remained the same and hence the discount factor.
>
> Is there some way to construct a discount curve using dates and dfs, and
> the curve would reflect the change of evaluation date, or am I totally
> wrong to expect it would?
>
> Cheers,
> Wei
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Should InterpolatedDiscountCurve register with evaluation date?

[Wei Li <ttl...@gm...>]

Dear all,

We are constructing yield curves using bootstrapped date and discount
factor pairs, i.e., we use the InterpolatedDiscountCurve class. But when I
am looking at the PUBLIC constructors of this class (all three of them take
a date vector and a discount factor vector as basic form), I see that they
all internally call the base class (YieldTermStructure) constructor using
the first date in the vector (dates.at(0)) as an explicitly-passed
reference date. It means this class doesn't register with the change of
QuantLib's evaluation date.

So when I am using these curves like this:

Date delivery = Date (30, September, 2024);
DiscountFactor df1 = my_curve -> discount(delivery);

Date originalEvalDate = Settings::instance().evaluationDate();
Settings::instance().evaluationDate() = originalEvalDate + 30;

DiscountFactor df2 = my_curve -> discount(delivery);

I would expect the df2 to be different from df1, but it is not the case.
Since the reference date of my_curve never got changed, the
timeFromReference remained the same and hence the discount factor.

Is there some way to construct a discount curve using dates and dfs, and
the curve would reflect the change of evaluation date, or am I totally
wrong to expect it would?

Cheers,
Wei

[Quantlib-users] RV: Overnight Index Future not working

[Esteban L. A. B. <est...@ho...>]

Hi Luigi, sorry for the late response, I was confirming wih CME the specifications for the F-TIIE futures.
Regarding your question, yes, It accrues the fixing from April 30th and it works the same for weekends, it will accrue the friday's fixing.  When the maturity is holiday, the current code doesn´t seem to mind.

I will keep in touch.
Thank you

________________________________
De: Luigi Ballabio <lui...@gm...>
Enviado: jueves, 30 de mayo de 2024 07:36 a. m.
Para: Esteban López Araiza Bravo <est...@ho...>
Cc: Qua...@li... <Qua...@li...>
Asunto: Re: [Quantlib-users] Overnight Index Future not working

Hello Esteban,
    when you create the first ql.OvernightIndexFutureRateHelper you're passing May 1st as the start date, and the code assumes that it's a fixing date.  We'll have to add code to manage that case.  How is this supposed to work?  Does the future accrue the fixing from the April 30th for the day between 1st and 2nd May?  And I assume the same happens if the maturity is a holiday, right?

Luigi


On Tue, May 28, 2024 at 6:16 PM Esteban López Araiza Bravo <est...@ho...<mailto:est...@ho...>> wrote:
Hi! I'm having trouble making an OvernightIndexFutureRateHelper. When I try to bootstrap it, the following error arises:

RuntimeError: 1st iteration failed at 1st alive instrument, pillar May 31st 2024 maturity May 31st 2024, reference date May 9th, 2024: missing rate on May 1st 2024 for index TIIE_OISTN Actual/360

But when I try to add the fixing for May 1st 2024, the next error arises:

RuntimeError: At least one invalid fixing provided: Wednesday May 1st 2024, 0.1102

May 1st is a holiday in Mexico, but the future compounds every day of the month, how can I workaround this issue or is there another way to bootstrap this kind of future?

I will attach the code.
Thanks!

Obtener Outlook para iOS<https://aka.ms/o0ukef>
_______________________________________________
QuantLib-users mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] question regarding discount factor interpolation

[Kiki z. <kik...@gm...>]

Thank you Luigi! That's helpful.


On Tue, Jun 4, 2024 at 9:01 AM Luigi Ballabio <lui...@gm...>
wrote:

> Hi, there's not a lot of documentation, I'm afraid.
>
> Things are more flexible in C++, where you can instantiate an
> InterpolatedDiscountCurve with the interpolation you want as a template
> argument.  In Python, we can't export the template directly so it provides
> a number of possible interpolations but not all of them; as of QUantLib
> 1.34, you can see them at  <
> https://github.com/lballabio/QuantLib-SWIG/blob/v1.34/SWIG/discountcurve.i#L57-L64>.
> So for instance, if you want monotonic log-cubic interpolation, you can use
> the second class listed there (MonotonicLogCubicDiscountCurve).  Log-linear
> interpolation used to be the default and got the simpler name,
> DiscountCurve.
>
> All these curves take as input a set of dates and the corresponding
> discounts.  If you want to interpolate between zero rates, you can use one
> of the classes listed at <
> https://github.com/lballabio/QuantLib-SWIG/blob/v1.34/SWIG/zerocurve.i#L59-L67>
> but they need a set of dates and zero rates as inputs.  You can either
> convert your discount factors into zero rates manually, or you could
> instantiate one of the discount curves above and ask them for the zero
> rates at the input dates.
>
> Hope this helps,
>     Luigi
>
>
>
>
>
> On Sat, Jun 1, 2024 at 5:10 AM Kiki zzz <kik...@gm...> wrote:
>
>> hi,
>>>
>>> I'm new to quant lib and I have some basic (or even stupid) questions.
>>> Let's say I have a list of dates and discount factors and I want to
>>> interpolate discount factors between 2 dates.
>>>
>>> - how can I choose different interpolation methods using QuantLib python
>>> interface? (e.g. in zero rate space, or forward rate space. linear or
>>> non-linear, etc)
>>>
>>> - what is the most common interpolation method (or maybe top 2 methods)
>>> used in practice? This question could be subjective or maybe there's a
>>> widely used standard in the fixed income world.
>>>
>>> It will be very helpful if someone can point me to any relevant
>>> documents or tutorial website.
>>>
>>> Really appreciate the help!
>>> Kiki
>>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] question regarding discount factor interpolation

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

Hi, there's not a lot of documentation, I'm afraid.

Things are more flexible in C++, where you can instantiate an
InterpolatedDiscountCurve with the interpolation you want as a template
argument.  In Python, we can't export the template directly so it provides
a number of possible interpolations but not all of them; as of QUantLib
1.34, you can see them at  <
https://github.com/lballabio/QuantLib-SWIG/blob/v1.34/SWIG/discountcurve.i#L57-L64>.
So for instance, if you want monotonic log-cubic interpolation, you can use
the second class listed there (MonotonicLogCubicDiscountCurve).  Log-linear
interpolation used to be the default and got the simpler name,
DiscountCurve.

All these curves take as input a set of dates and the corresponding
discounts.  If you want to interpolate between zero rates, you can use one
of the classes listed at <
https://github.com/lballabio/QuantLib-SWIG/blob/v1.34/SWIG/zerocurve.i#L59-L67>
but they need a set of dates and zero rates as inputs.  You can either
convert your discount factors into zero rates manually, or you could
instantiate one of the discount curves above and ask them for the zero
rates at the input dates.

Hope this helps,
    Luigi





On Sat, Jun 1, 2024 at 5:10 AM Kiki zzz <kik...@gm...> wrote:

> hi,
>>
>> I'm new to quant lib and I have some basic (or even stupid) questions.
>> Let's say I have a list of dates and discount factors and I want to
>> interpolate discount factors between 2 dates.
>>
>> - how can I choose different interpolation methods using QuantLib python
>> interface? (e.g. in zero rate space, or forward rate space. linear or
>> non-linear, etc)
>>
>> - what is the most common interpolation method (or maybe top 2 methods)
>> used in practice? This question could be subjective or maybe there's a
>> widely used standard in the fixed income world.
>>
>> It will be very helpful if someone can point me to any relevant documents
>> or tutorial website.
>>
>> Really appreciate the help!
>> Kiki
>>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] question regarding discount factor interpolation

[Kiki z. <kik...@gm...>]

>
> hi,
>
> I'm new to quant lib and I have some basic (or even stupid) questions.
> Let's say I have a list of dates and discount factors and I want to
> interpolate discount factors between 2 dates.
>
> - how can I choose different interpolation methods using QuantLib python
> interface? (e.g. in zero rate space, or forward rate space. linear or
> non-linear, etc)
>
> - what is the most common interpolation method (or maybe top 2 methods)
> used in practice? This question could be subjective or maybe there's a
> widely used standard in the fixed income world.
>
> It will be very helpful if someone can point me to any relevant documents
> or tutorial website.
>
> Really appreciate the help!
> Kiki
>

[Quantlib-users] ORE v12 released

[Lichters, R. <Rol...@ls...>]

Hi all,

We are happy to announce our next release of ORE on https://github.com/OpenSourceRisk with a range of new features

  *   several new instruments again, including American Swaptions, Flexi Swaps, formula-based legs
  *   using QuantLib’s finite difference framework in Swaptions and Scripted Trades
  *   adding Market Risk analytics including P&L, P&L Explain, Historical Simulation VaR, stress testing in the par-rate domain, XVA stress testing and sensitivity
  *   using AAD for t0 sensitivity and XVA sensitivity
  *   using GPUs to parallelize calculations

Please check it out: Install the ORE Python package with “pip install open-source-risk-engine” or clone the repo at https://github.com/OpenSourceRisk/Engine). To get started with using ORE, see the new user guide at https://opensourcerisk.org/documentation and the examples described there.

Best wishes,
Roland
------------------------------------------------------------------------------------------------------------
 
Please read these warnings and restrictions:
This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information.
The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence.
If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000.
LSEG may collect, process and retain your personal information for its business purposes. For more information please see our Privacy Policy.
We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail.
E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. 
Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities.
For more details on the LSEG group of companies click here 
London Stock Exchange Group plc
10 Paternoster Square
London 
EC4M 7LS
Registered in England and Wales No 05369106
 
------------------------------------------------------------------------------------------------------------

[Quantlib-users] Workshop Invite: Ultra-fast, AAD-enabled QuantLib in Python

[Dmitri G. <dm...@ma...>]

Dear Community,

We'd like to invite you to a free webinar:

Webinar: Supercharge your Quant Models: Unlock Python's Potential for
Production
<https://www.meetup.com/level39-onecanadasquare/events/300168248/>
When: Wed, Jun 12, 2024, 6:00 PM BST / 1:00 PM EST

In this workshop, we will demonstrate a practical plug-and-play solution
that turns QuantLib into a production-grade Live Risk server. We will also
show how other use cases, including model calibration and curve
bootstrapping, can be accelerated and enabled with AAD.

You will learn how to run your Python code at bare metal speeds, achieving
>1000x acceleration for simulation-based analytics, enabling Automated
Adjoint Differentiation, and serialising the workloads for cloud execution!

With MatLogica
<https://matlogica.com/matlogica-python-accelerator.php?ID=QuantLib> you
can record a computation graph defined across language boundaries
(Python -> C++ -> Callbacks into Python etc.), then compile it into
super-efficient, parallelizable, and serializable machine code kernels -
opening unprecedented opportunities to bridge the gap between prototyping
and production, running your hybrid code at bare metal speeds.

We are looking forward to seeing you at the event!

Kind regards,
Dmitri Goloubentsev
Head of Automatic Adjoint Differentiation,
Matlogica LTD
http://matlogica.com +447378414528
See my schedule and book <https://calendly.com/matlogica> a meeting with me

Re: [Quantlib-users] Overnight Index Future not working

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

Hello Esteban,
    when you create the first ql.OvernightIndexFutureRateHelper you're
passing May 1st as the start date, and the code assumes that it's a fixing
date.  We'll have to add code to manage that case.  How is this supposed to
work?  Does the future accrue the fixing from the April 30th for the day
between 1st and 2nd May?  And I assume the same happens if the maturity is
a holiday, right?

Luigi


On Tue, May 28, 2024 at 6:16 PM Esteban López Araiza Bravo <
est...@ho...> wrote:

> Hi! I'm having trouble making an OvernightIndexFutureRateHelper. When I
> try to bootstrap it, the following error arises:
>
> RuntimeError: 1st iteration failed at 1st alive instrument, pillar May
> 31st 2024 maturity May 31st 2024, reference date May 9th, 2024: missing
> rate on May 1st 2024 for index TIIE_OISTN Actual/360
>
> But when I try to add the fixing for May 1st 2024, the next error arises:
>
> RuntimeError: At least one invalid fixing provided: Wednesday May 1st
> 2024, 0.1102
>
> May 1st is a holiday in Mexico, but the future compounds every day of the
> month, how can I workaround this issue or is there another way to bootstrap
> this kind of future?
>
> I will attach the code.
> Thanks!
>
> Obtener Outlook para iOS <https://aka.ms/o0ukef>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Overnight Index Future not working

[Esteban L. A. B. <est...@ho...>]

Hi! I'm having trouble making an OvernightIndexFutureRateHelper. When I try to bootstrap it, the following error arises:

RuntimeError: 1st iteration failed at 1st alive instrument, pillar May 31st 2024 maturity May 31st 2024, reference date May 9th, 2024: missing rate on May 1st 2024 for index TIIE_OISTN Actual/360

But when I try to add the fixing for May 1st 2024, the next error arises:

RuntimeError: At least one invalid fixing provided: Wednesday May 1st 2024, 0.1102

May 1st is a holiday in Mexico, but the future compounds every day of the month, how can I workaround this issue or is there another way to bootstrap this kind of future?

I will attach the code.
Thanks!

Obtener Outlook para iOS<https://aka.ms/o0ukef>

[Quantlib-users] Quant conference in London 5th June

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

Dear all,

there will be a gathering on 5th June in London where we will discuss
recent developments in ORE

https://www.acadia.inc/quant-summit-london-2024

As we all know, QuantLib is an essential part of ORE and so it seems
okay to announce this here. We will discuss AAD for T0 sensis and XVA
and how the ORE approach compares to other approaches that were
implemented for QuantLib, how we offload work to GPUs, how we
integrate QuantLib's finite-difference framework into Bermudan
Swaption and Scripted Trade pricing, new features around rate curve
building based off QuantLib classes, how we handle stress testing in
par and zero space, how we wrap the libraries into a restful API, and
much more.

There are still a couple of seats left (actually not so many I
believe), so feel free to register.

Best
Peter

Re: [Quantlib-users] Discount Method

[philippe h. <pha...@ma...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Well technically spread 01 is not constant so you’re supposed to solve for the oas spread with path wise discounting.<div>Your question about scenario probabilities is not QuantLib specific. If you want market implied (treasury swaption vol surface) then you won’t get an exact number. A better approach is to define scenarios as combinations of parallel shift plus slope shift plus concavity change across the 3-5y point. Then from a calibrated MC model, sort of “cluster” the outcomes across the 3 principal components above form which you can derive some probabilities and correlations. But then you might as well use the MC model and forget about specific scenarios. My understanding is that mortgage desks tee hat do not use stochastic rate models set their own probabilities “somehow” but they don’t follow risk neutral because if you use risk neutral scenarios you need to do it consistently. There are also ways to adjust the drift of a stochastic process to go from Q-measure (risk neutral) to P-measure (real world) and if you want to do your own then might be better to do that.<br><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Regards<div><br></div><div>Philippe Hatstadt</div><div>+1-203-252-0408</div><div><br></div></div><div dir="ltr"><br><blockquote type="cite">On May 20, 2024, at 2:57 PM, Michael (DataDriven portal) &lt;mi...@da...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi Luigi/Philippe:<br><br>Thanks a lot for your very valuable feedback!&nbsp;<div><br></div><div>We have implemented scenario based OAS calculations as follows:<br><br>1. A user selects a number of interest rate scenarios (e.g. base, 2 rally, 2 selloff, etc)<br>2. For each scenario (in step 1) we calculate a bond Future Price (using a prepayment vector that corresponds to an interest&nbsp;rate scenario)<div>3. Scenario Based OAS = (Expected Price (across Future Prices in 2) - Initial Price)/Spread01<br><br>We are not sure how to calculate probabilities for the user input scenarios (in step 1) though that would reflect implied&nbsp;volatilities. <br><br>What would be the best way to do this in QuantLib?<br><br>Thanks,&nbsp;<br><br>Michael&nbsp;<br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2024 at 9:33 AM Philippe Hatstadt &lt;<a href="mailto:pha...@ma...">pha...@ma...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div>A few things:<br></div><div>1. For scenario based OAS, speed is really not an issue as you are un likely to compute more than a few dozens or even hundred prices per iteration of the OAS solver (also see my point below about massive increase on OAS solving algo)<br></div><div>2. For Monte-Carlo, speed obviously matters more. If you calibrate a stochastic model to swaption (or treasury swaptions as I've seen it called, deriving UST bond option volatility surface for SOFR swaption surface) then you don't need to compute path probabilities as they are equal under the RN measure.<br></div><div>3. As far as QL utilities to build curves from a given stochastic path and discount a given cash flow path, there are no such utilities. If you use a log-linear discount factor curve, you can get speed by only storing the x-y coordinates (monthly). Then use standard QL objects to discount the cash flows once generated.<br></div><div>4. One trick you can use for OAS speed is to consider that exp((-rf+ oas)(T-t)) = exp(-rf(T-t)) * exp(oas(T-t)). In turn, for each path, you can pre-calculate all cash flow vectors CF(T-t) on the risk-free curve, and for each iteration of OAS, only recompute exp(oas(T-t)) vectors and apply them to the more complex pre-computed CF(T-t) vectors. This "orthogonalization" is legit, because your prepayment model should only depend on the risk-free curve for a given path, and usually, the prepayment calculations are slow. Stated differently, you only need to apply the prepayment model once for each path and there is no need to call it again for other intermediate oas guess values.<br></div><div>5. Which brings us to the OAS discussion. If you feel comfortable (I do not) using a one factor model, then you should be able to find both the engine and the calibration routines in QL (HW 1F as suggested by Luigi). However, the slope of the curve is considered important, so a two-factor model is needed. The only one I am aware of in QL is the G2++ model, but unfortunately, there is no time-tested calibration routine for it, as the renowned quant who built it passed away and sadly never got to finish it. Luigi has a Python PR outstanding to verify the input compatibility of some calibration routines (which I do not have enough time to address - apologies Luigi). So as long as you are comfortable with a one factor model for the stochastic part of your endeavor, you should be ok, otherwise, not sure there is an easy approach unless you go to C++ and dig deep into existing calibration routines for g2++ which may or not have been tested.<br></div><div><br></div><div>

Philippe Hatstadt<br></div><div><br></div></div><blockquote type="cite"><div>On May 20, 2024, at 4:49 AM, Luigi Ballabio &lt;<a href="mailto:lui...@gm..." target="_blank">lui...@gm...</a>&gt; wrote:<br></div><div><br></div><div><br></div><div><div dir="ltr"><div>Hi Michael,<br></div><div><br></div><div>1. a very interesting question but I'm not sure of the answer.&nbsp; I'm guessing you could use a root solver for the spread given the prices implied by the new curves, but I'm probably missing a lot of details.<br></div><div>2. I think the closest we have is the possibility to generate future interest-rate paths via Monte Carlo given a Hull-White process (which in turn would be calibrated from a volatility surface).<br></div><div>3. At the moment, I guess the best way would be to extend the swig wrappers and recompile the wheel to add a call taking a list of dates and this moving the loop to C++.&nbsp; I don't know how feasible that is for you, though...<br></div><div><br></div><div>Luigi<br></div><div><br></div></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2024 at 3:53 PM Michael (DataDriven portal) &lt;<a href="mailto:mi...@da..." target="_blank">mi...@da...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hi Luigi:<br></div><div><br></div><div>Thanks for getting back to me!<br></div></div><div><br></div><div><div>To be specific, we use QuantLib for mortgage&nbsp;bond pricing e.g. calculate yields, spreads, durations given mortgage performance inputs (e.g. prepayments or default vectors). This works quite well for static metrics that&nbsp;rely on a single yield curve input. But we also would like to calculate option adjusted measures (e.g. OAS - option adjusted spread) that require inputs of many yield curves (e.g. with high/lower rates leves, flatter/steeper curve shapes). <br></div><div><br></div><div>So a few specific questions I have are as follows:<br></div><div><br></div><div>1. What is the best way to generate option adjusted&nbsp;metrics (e.g. OAS) in QuantLib if user inputs yield curves with associated&nbsp;probabilities?&nbsp;&nbsp;<br></div></div><div>2. Can QuantLIb generate future yield curves with associated probabilities based on current structure of term structure of interest rates and volatility surface?&nbsp;<br></div><div>3. What is the best way to retrieve the yield curve details for cash flows calculations&nbsp;(e.g. monthly discount factors for 360 months which is a typical number of cash flows for a mortgage bond)? We tried a <i>discount</i> method for each month separately but it takes too long.<br></div><div><br></div><div><div>Thanks,&nbsp;<br></div><div><br></div><div>Michael&nbsp;&nbsp;<br></div></div></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2024 at 4:06 AM Luigi Ballabio &lt;<a href="mailto:lui...@gm..." target="_blank">lui...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi&nbsp;Michael, apologies&nbsp;for the delay. I'm not sure what's the most effective way to do this.&nbsp; Well, no, scratch that—the most efficient way would be to do it in C++.&nbsp; From Python, if you have a process available (such as HullWhiteProcess, for instance) you can use the available PathGenerator class.&nbsp; What kind of simulation do you have in mind?<br></div><div><br></div><div>Luigi<br></div><div><br></div></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 20, 2024 at 5:49 PM Michael (DataDriven portal) &lt;<a href="mailto:mi...@da..." target="_blank">mi...@da...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Luigi:<br></div><div><br></div><div>Thank you for getting back to me! <br></div><div><br></div><div>What is the most efficient way to do Monte Carlo simulations in QuantLib when I need to obtain multiple paths of yield curves for different scenarios (they do not have to be vectors of DFs but could be FRAs or any other rate metrics)?<br></div><div><br></div><div>Thanks,&nbsp;<br></div><div><br></div><div>Michael&nbsp;<br></div></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 20, 2024 at 10:59 AM Luigi Ballabio &lt;<a href="mailto:lui...@gm..." target="_blank">lui...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello Michael,<br></div><div>&nbsp; &nbsp; no, I'm afraid vector methods are not available.<br></div><div><br></div><div>Luigi<br></div><div><br></div></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 14, 2024 at 8:30 PM Michael (DataDriven portal) &lt;<a href="mailto:mi...@da..." target="_blank">mi...@da...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi All,&nbsp;<br></div><div><br></div><div>I am using a <i>discount</i> method on a curve to get a discount factor for a given maturity (like in shown in the Cookbook below). But I need to output discount factors for all monthly cash flows of a bond (in my case 360 cash flows) so it is time consuming to&nbsp;call the <i>discount</i>&nbsp;method 360 times.<br></div><div><div><br></div><div>Is there a way to get all discount factors (for all cash flows - 360 in my case) in a single&nbsp;call to a curve by passing all maturity&nbsp;dates (e.g. in a list) to speed up the calculations?<br></div><div><br></div><div>Thanks,&nbsp;<br></div><div><br></div><div>Michael&nbsp;<br></div></div><div><br></div><div><span>&lt;image.png&gt;</span><br></div></div><div>_______________________________________________<br></div><div> QuantLib-users mailing list<br></div><div> <a href="mailto:Qua...@li..." target="_blank">Qua...@li...</a><br></div><div> <a href="https://lists.sourceforge.net/lists/listinfo/quantlib-users" rel="noopener noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/quantlib-users</a><br></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div><div><div>Content-Type: text/plain; charset="us-ascii"<br></div><div>MIME-Version: 1.0<br></div><div>Content-Transfer-Encoding: 7bit<br></div><div>Content-Disposition: inline<br></div></div><div><span>&lt;untitled attachment&gt;</span><br></div></div></blockquote></div><div><br></div></div></blockquote></div>
</div></blockquote></div></div></body></html>

Re: [Quantlib-users] Discount Method

[Michael (D. portal) <mi...@da...>]

Hi Luigi/Philippe:

Thanks a lot for your very valuable feedback!

We have implemented scenario based OAS calculations as follows:

1. A user selects a number of interest rate scenarios (e.g. base, 2 rally,
2 selloff, etc)
2. For each scenario (in step 1) we calculate a bond Future Price (using a
prepayment vector that corresponds to an interest rate scenario)
3. Scenario Based OAS = (Expected Price (across Future Prices in 2) -
Initial Price)/Spread01

We are not sure how to calculate probabilities for the user input scenarios
(in step 1) though that would reflect implied volatilities.

What would be the best way to do this in QuantLib?

Thanks,

Michael


On Mon, May 20, 2024 at 9:33 AM Philippe Hatstadt <pha...@ma...> wrote:

> A few things:
> 1. For scenario based OAS, speed is really not an issue as you are un
> likely to compute more than a few dozens or even hundred prices per
> iteration of the OAS solver (also see my point below about massive increase
> on OAS solving algo)
> 2. For Monte-Carlo, speed obviously matters more. If you calibrate a
> stochastic model to swaption (or treasury swaptions as I've seen it called,
> deriving UST bond option volatility surface for SOFR swaption surface) then
> you don't need to compute path probabilities as they are equal under the RN
> measure.
> 3. As far as QL utilities to build curves from a given stochastic path and
> discount a given cash flow path, there are no such utilities. If you use a
> log-linear discount factor curve, you can get speed by only storing the x-y
> coordinates (monthly). Then use standard QL objects to discount the cash
> flows once generated.
> 4. One trick you can use for OAS speed is to consider that exp((-rf+
> oas)(T-t)) = exp(-rf(T-t)) * exp(oas(T-t)). In turn, for each path, you can
> pre-calculate all cash flow vectors CF(T-t) on the risk-free curve, and for
> each iteration of OAS, only recompute exp(oas(T-t)) vectors and apply them
> to the more complex pre-computed CF(T-t) vectors. This "orthogonalization"
> is legit, because your prepayment model should only depend on the risk-free
> curve for a given path, and usually, the prepayment calculations are slow.
> Stated differently, you only need to apply the prepayment model once for
> each path and there is no need to call it again for other intermediate oas
> guess values.
> 5. Which brings us to the OAS discussion. If you feel comfortable (I do
> not) using a one factor model, then you should be able to find both the
> engine and the calibration routines in QL (HW 1F as suggested by Luigi).
> However, the slope of the curve is considered important, so a two-factor
> model is needed. The only one I am aware of in QL is the G2++ model, but
> unfortunately, there is no time-tested calibration routine for it, as the
> renowned quant who built it passed away and sadly never got to finish it.
> Luigi has a Python PR outstanding to verify the input compatibility of some
> calibration routines (which I do not have enough time to address -
> apologies Luigi). So as long as you are comfortable with a one factor model
> for the stochastic part of your endeavor, you should be ok, otherwise, not
> sure there is an easy approach unless you go to C++ and dig deep into
> existing calibration routines for g2++ which may or not have been tested.
>
> Philippe Hatstadt
>
> On May 20, 2024, at 4:49 AM, Luigi Ballabio <lui...@gm...>
> wrote:
>
>
> Hi Michael,
>
> 1. a very interesting question but I'm not sure of the answer.  I'm
> guessing you could use a root solver for the spread given the prices
> implied by the new curves, but I'm probably missing a lot of details.
> 2. I think the closest we have is the possibility to generate future
> interest-rate paths via Monte Carlo given a Hull-White process (which in
> turn would be calibrated from a volatility surface).
> 3. At the moment, I guess the best way would be to extend the swig
> wrappers and recompile the wheel to add a call taking a list of dates and
> this moving the loop to C++.  I don't know how feasible that is for you,
> though...
>
> Luigi
>
>
> On Fri, May 3, 2024 at 3:53 PM Michael (DataDriven portal) <
> mi...@da...> wrote:
>
>> Hi Luigi:
>>
>> Thanks for getting back to me!
>>
>> To be specific, we use QuantLib for mortgage bond pricing e.g. calculate
>> yields, spreads, durations given mortgage performance inputs (e.g.
>> prepayments or default vectors). This works quite well for static metrics
>> that rely on a single yield curve input. But we also would like to
>> calculate option adjusted measures (e.g. OAS - option adjusted spread) that
>> require inputs of many yield curves (e.g. with high/lower rates leves,
>> flatter/steeper curve shapes).
>>
>> So a few specific questions I have are as follows:
>>
>> 1. What is the best way to generate option adjusted metrics (e.g. OAS) in
>> QuantLib if user inputs yield curves with associated probabilities?
>> 2. Can QuantLIb generate future yield curves with associated
>> probabilities based on current structure of term structure of interest
>> rates and volatility surface?
>> 3. What is the best way to retrieve the yield curve details for cash
>> flows calculations (e.g. monthly discount factors for 360 months which is a
>> typical number of cash flows for a mortgage bond)? We tried a *discount*
>> method for each month separately but it takes too long.
>>
>> Thanks,
>>
>> Michael
>>
>> On Fri, May 3, 2024 at 4:06 AM Luigi Ballabio <lui...@gm...>
>> wrote:
>>
>>> Hi Michael, apologies for the delay. I'm not sure what's the most
>>> effective way to do this.  Well, no, scratch that—the most efficient way
>>> would be to do it in C++.  From Python, if you have a process available
>>> (such as HullWhiteProcess, for instance) you can use the available
>>> PathGenerator class.  What kind of simulation do you have in mind?
>>>
>>> Luigi
>>>
>>>
>>> On Sat, Apr 20, 2024 at 5:49 PM Michael (DataDriven portal) <
>>> mi...@da...> wrote:
>>>
>>>> Hi Luigi:
>>>>
>>>> Thank you for getting back to me!
>>>>
>>>> What is the most efficient way to do Monte Carlo simulations in
>>>> QuantLib when I need to obtain multiple paths of yield curves for different
>>>> scenarios (they do not have to be vectors of DFs but could be FRAs or any
>>>> other rate metrics)?
>>>>
>>>> Thanks,
>>>>
>>>> Michael
>>>>
>>>> On Sat, Apr 20, 2024 at 10:59 AM Luigi Ballabio <
>>>> lui...@gm...> wrote:
>>>>
>>>>> Hello Michael,
>>>>>     no, I'm afraid vector methods are not available.
>>>>>
>>>>> Luigi
>>>>>
>>>>>
>>>>> On Sun, Apr 14, 2024 at 8:30 PM Michael (DataDriven portal) <
>>>>> mi...@da...> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I am using a *discount* method on a curve to get a discount factor
>>>>>> for a given maturity (like in shown in the Cookbook below). But I need to
>>>>>> output discount factors for all monthly cash flows of a bond (in my case
>>>>>> 360 cash flows) so it is time consuming to call the *discount* method
>>>>>> 360 times.
>>>>>>
>>>>>> Is there a way to get all discount factors (for all cash flows - 360
>>>>>> in my case) in a single call to a curve by passing all maturity dates (e.g.
>>>>>> in a list) to speed up the calculations?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>> <image.png>
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>
>>>>> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> <untitled attachment>
>
>
>

Re: [Quantlib-users] Arguments for ql.ConstNotionalCrossCurrencyBasisSwapRateHelper()

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

Explanation at 
https://www.deriscope.com/products/Key_Yield_Curve_Fxb__Spot.html

It describes the spot rate input in the construction of a curve out of 
xccy basis spreads.

In effect, any assumed spot rate cancels out due to for any given two 
currencies SRC and TGT, the corresponding legs in a currency swap have 
differing notionals Nˢʳᶜ and Nᵗᵍᵗ that satisfy:
Nˢʳᶜ/Nᵗᵍᵗ = s := spot fx rate TGT/SRC

On 5/18/2024 6:41 PM, Quant wrote:
> Hi Peter,
>
> No, the spot fx is not declared anywhere in the bootstrapping hence my 
> first question was why we don’t have an argument for the quote FX rate 
> which would be used as the implied notional. Not sure if it’s 
> making sense.
>
> Thanks & regards,
> Nk
>
> On Sat, 18 May 2024 at 18:28, Peter Caspers <pca...@gm...> 
> wrote:
>
>     I guess spot fx is somewhat implicit in the (initial) notionals of
>     the two legs?
>     Peter
>
>     On Fri, 17 May 2024 at 03:34, Ben Watson
>     <ben...@ma...> wrote:
>     >
>     > cross currency basis is a spread over a floating index. We use
>     this to bootstrap curves. It is a direct quote, and no need for a
>     spot FX rate.
>     >
>     > The contrast is when we imply a basis over a floating index from
>     forward fx pips. In this case we need spot fx.
>     >
>     > Ben
>     >
>     > On Fri, 17 May 2024, 6:16 am Quant, <qua...@gm...>
>     wrote:
>     >>
>     >> Hi Quantlib users,
>     >>
>     >> When using ql.ConstNotionalCrossCurrencySwapRateHelper() shown
>     below, are we not supposed to have an argument for the quote FX
>     rate? If not how do we adjust for the spot FX rate when
>     bootstrapping the basis adjusted discount curve? Not sure if my
>     question makes sense
>     >>
>     >>
>     https://rkapl123.github.io/QLAnnotatedSource/d6/d3d/class_quant_lib_1_1_const_notional_cross_currency_basis_swap_rate_helper.html
>     >>
>     >> Thanks & regards,
>     >> Nk
>     >> _______________________________________________
>     >> QuantLib-users mailing list
>     >> Qua...@li...
>     >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>     >
>     > _______________________________________________
>     > QuantLib-users mailing list
>     > Qua...@li...
>     > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

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

Re: [Quantlib-users] Discount Method

[Philippe H. <pha...@ma...>]

A few things: 1. For scenario based OAS, speed is really not an issue as you are un likely to compute more than a few dozens or even hundred prices per iteration of the OAS solver (also see my point below about massive increase on OAS solving algo) 2. For Monte-Carlo, speed obviously matters more. If you calibrate a stochastic model to swaption (or treasury swaptions as I've seen it called, deriving UST bond option volatility surface for SOFR swaption surface) then you don't need to compute path probabilities as they are equal under the RN measure. 3. As far as QL utilities to build curves from a given stochastic path and discount a given cash flow path, there are no such utilities. If you use a log-linear discount factor curve, you can get speed by only storing the x-y coordinates (monthly). Then use standard QL objects to discount the cash flows once generated. 4. One trick you can use for OAS speed is to consider that exp((-rf+ oas)(T-t)) = exp(-rf(T-t)) * exp(oas(T-t)). In turn, for each path, you can pre-calculate all cash flow vectors CF(T-t) on the risk-free curve, and for each iteration of OAS, only recompute exp(oas(T-t)) vectors and apply them to the more complex pre-computed CF(T-t) vectors. This "orthogonalization" is legit, because your prepayment model should only depend on the risk-free curve for a given path, and usually, the prepayment calculations are slow. Stated differently, you only need to apply the prepayment model once for each path and there is no need to call it again for other intermediate oas guess values. 5. Which brings us to the OAS discussion. If you feel comfortable (I do not) using a one factor model, then you should be able to find both the engine and the calibration routines in QL (HW 1F as suggested by Luigi). However, the slope of the curve is considered important, so a two-factor model is needed. The only one I am aware of in QL is the G2++ model, but unfortunately, there is no time-tested calibration routine for it, as the renowned quant who built it passed away and sadly never got to finish it. Luigi has a Python PR outstanding to verify the input compatibility of some calibration routines (which I do not have enough time to address - apologies Luigi). So as long as you are comfortable with a one factor model for the stochastic part of your endeavor, you should be ok, otherwise, not sure there is an easy approach unless you go to C++ and dig deep into existing calibration routines for g2++ which may or not have been tested. Philippe Hatstadt On May 20, 2024, at 4:49 AM, Luigi Ballabio <lui...@gm...> wrote: Hi Michael, 1. a very interesting question but I'm not sure of the answer. I'm guessing you could use a root solver for the spread given the prices implied by the new curves, but I'm probably missing a lot of details. 2. I think the closest we have is the possibility to generate future interest-rate paths via Monte Carlo given a Hull-White process (which in turn would be calibrated from a volatility surface). 3. At the moment, I guess the best way would be to extend the swig wrappers and recompile the wheel to add a call taking a list of dates and this moving the loop to C++. I don't know how feasible that is for you, though... Luigi On Fri, May 3, 2024 at 3:53 PM Michael (DataDriven portal) < mi...@da... > wrote: Hi Luigi: Thanks for getting back to me! To be specific, we use QuantLib for mortgage bond pricing e.g. calculate yields, spreads, durations given mortgage performance inputs (e.g. prepayments or default vectors). This works quite well for static metrics that rely on a single yield curve input. But we also would like to calculate option adjusted measures (e.g. OAS - option adjusted spread) that require inputs of many yield curves (e.g. with high/lower rates leves, flatter/steeper curve shapes). So a few specific questions I have are as follows: 1. What is the best way to generate option adjusted metrics (e.g. OAS) in QuantLib if user inputs yield curves with associated probabilities? 2. Can QuantLIb generate future yield curves with associated probabilities based on current structure of term structure of interest rates and volatility surface? 3. What is the best way to retrieve the yield curve details for cash flows calculations (e.g. monthly discount factors for 360 months which is a typical number of cash flows for a mortgage bond)? We tried a discount method for each month separately but it takes too long. Thanks, Michael On Fri, May 3, 2024 at 4:06 AM Luigi Ballabio < lui...@gm... > wrote: Hi Michael, apologies for the delay. I'm not sure what's the most effective way to do this. Well, no, scratch that—the most efficient way would be to do it in C++. From Python, if you have a process available (such as HullWhiteProcess, for instance) you can use the available PathGenerator class. What kind of simulation do you have in mind? Luigi On Sat, Apr 20, 2024 at 5:49 PM Michael (DataDriven portal) < mi...@da... > wrote: Hi Luigi: Thank you for getting back to me! What is the most efficient way to do Monte Carlo simulations in QuantLib when I need to obtain multiple paths of yield curves for different scenarios (they do not have to be vectors of DFs but could be FRAs or any other rate metrics)? Thanks, Michael On Sat, Apr 20, 2024 at 10:59 AM Luigi Ballabio < lui...@gm... > wrote: Hello Michael, no, I'm afraid vector methods are not available. Luigi On Sun, Apr 14, 2024 at 8:30 PM Michael (DataDriven portal) < mi...@da... > wrote: Hi All, I am using a discount method on a curve to get a discount factor for a given maturity (like in shown in the Cookbook below). But I need to output discount factors for all monthly cash flows of a bond (in my case 360 cash flows) so it is time consuming to call the discount method 360 times. Is there a way to get all discount factors (for all cash flows - 360 in my case) in a single call to a curve by passing all maturity dates (e.g. in a list) to speed up the calculations? Thanks, Michael <image.png> _______________________________________________ QuantLib-users mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-users Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline <untitled attachment>

Re: [Quantlib-users] Arguments for ql.ConstNotionalCrossCurrencyBasisSwapRateHelper()

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

Agreed.  May you open an issue on GitHub?  It's the best way to ensure this
stays on people's radars.

Thanks,
    Luigi


On Sat, May 18, 2024 at 10:45 PM Quant <qua...@gm...> wrote:

> Hi Marcin,
>
> It worked, thanks. I did make two proxy Ibor indices which I then used in
> my bootstrapping process as shown below:
>
> sofr_3m = ql.IborIndex('SOFR', ql.Period('3m'), 0, ql.USDCurrency(),
>                        ql.UnitedStates(ql.UnitedStates.FederalReserve), ql.Following, False, ql.Actual360(),
>                        sofr_ts)
>
> sonia_3m = ql.IborIndex('SONIA', ql.Period('3m'), 0, ql.GBPCurrency(), ql.UnitedKingdom(),
>                         ql.Following, False, ql.Actual365Fixed(), sonia_ts)
>
> ccbs_helpers = [
>     ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(ql.QuoteHandle(ql.SimpleQuote(basis / 10000)), ql.Period(*tenor),
>                                                      2, calendar, ql.Following, False,
>                                                      sofr_3m, sonia_3m, sofr_ts, True,
>                                                      False)
>     for basis, tenor in [(-5.375, (3, ql.Months)), (-6.875, (6, ql.Months)),
>                          (-13.375, (9, ql.Months)), (-12.75, (1, ql.Years)),
>                          (-14.875, (2, ql.Years)), (-17.25, (3, ql.Years)),
>                          (-19.25, (4, ql.Years)), (-20.25, (5, ql.Years)),
>                          (-20.625, (6, ql.Years)), (-20.75, (7, ql.Years)),
>                          (-20.75, (8, ql.Years)), (-20.875, (9, ql.Years)),
>                          (-21, (10, ql.Years)), (-21.75, (12, ql.Years)),
>                          (-24.625, (15, ql.Years)), (-30, (20, ql.Years)),
>                          (-36.25, (30, ql.Years)), (-38.75, (40, ql.Years)),
>                          (-37.75, (50, ql.Years))]]
>
> basis_adj_sonia_curve = ql.YieldTermStructureHandle(
>     ql.PiecewiseLogCubicDiscount(0, calendar, ccbs_helpers, day_counter))
>
> basis_adj_sonia_curve.enableExtrapolation()
>
>
> Thanks all for the help and contribution. I do agree that we need to
> consider improving the helpers
> ql.ConstNotionalCrossCurrencyBasisSwapRateHelper and
> ql.MtMCrossCurrencyBasisSwapRateHelper
>
> Cheers,
> Nk
>
> On Sat, May 18, 2024 at 9:39 PM Marcin Rybacki <mry...@gm...>
> wrote:
>
>> Hi everyone,
>>
>> As already pointed out by Peter and Ioannis, the helper utilizes the fact
>> that, for a par instrument, the ratio of foreign vs domestic notionals is
>> equal to the market spot rate. Hence, they cancel each other out and the FX
>> spot rate is not really needed.
>>
>> Nk, to make your example work for a SOFR-SONIA swap you will have to
>> create two proxy Ibor indices (instead of using overnight ones) with 3m
>> period each for SOFR and SONIA, respectively. Given that both SOFR and
>> SONIA legs use compounded rate averaging, they collapse to Ibor-type
>> coupons anyway - this property will apply to coupons that have not started
>> accruing yet, which for a par instrument applies to all. This should result
>> in a GBP curve under USD collateralization you’re looking for.
>>
>> We might consider improving the helper by adding a constructor that takes
>> an overnight index and payment frequency as parameters.
>>
>> Hope this helps.
>>
>> Regards,
>> Marcin
>>
>> On Sat, 18 May 2024 at 21:08, Ioannis Rigopoulos <qua...@de...>
>> wrote:
>>
>>> The baseCurrencyIndex and quoteCurrencyIndex imply the frequency per
>>> each floating leg.
>>> On 5/18/2024 8:53 PM, Quant wrote:
>>>
>>> Thanks loannis, what about the payment frequency is it not required in
>>> ql.ConstNotionalCrossCurrencyBasisSwapRateHelper() for bootstrapping?
>>>
>>> Thanks,
>>> Nk
>>>
>>> On Sat, 18 May 2024 at 20:25, Ioannis Rigopoulos <qua...@de...>
>>> wrote:
>>>
>>>> Hi Peter and NK
>>>>
>>>> For some reason, the email I sent quite some time ago did not go
>>>> through. Perhaps because of the link insertion. I repeat it below:
>>>>
>>>> The spot rate is not needed. Explanation at
>>>> https://www.deriscope.com/products/Key_Yield_Curve_Fxb__Spot.html that
>>>> describes the spot rate input in the construction of a curve out of xccy
>>>> basis spreads.
>>>> In effect, any assumed spot rate cancels out due to for any given two
>>>> currencies SRC and TGT, the corresponding legs in a currency swap have
>>>> differing notionals Nˢʳᶜ and Nᵗᵍᵗ that satisfy:
>>>>
>>>> Nˢʳᶜ/Nᵗᵍᵗ = s := spot fx rate TGT/SRC
>>>>
>>>> Ioannis
>>>> On 5/18/2024 8:12 PM, Quant wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> So do you agree that we need to have the following additional arguments
>>>> in
>>>> ql.ConstNotionalCrossCurrencyBasisSwapRateHelper();
>>>>
>>>> 1. quote FX rate - so that 1 is used as the notional of one leg and the
>>>> quote FX rate is used as notional on the other leg
>>>>
>>>> 2. payment frequency - so that the number of payment frequency is known
>>>> for each leg during the bootstrapping process.
>>>>
>>>> Happy to get your opinion on this.
>>>>
>>>> Thanks & regards,
>>>> Nk
>>>>
>>>> On Sat, 18 May 2024 at 19:57, Peter Caspers <pca...@gm...>
>>>> wrote:
>>>>
>>>>> It does make sense, I was confused as well.
>>>>>
>>>>> I think both the domestic and foreign leg are set up with the same
>>>>> notional 1.0. I.e. the conversion of the foreign leg’s npv to domestic
>>>>> currency is done implicitly by using identical nationals. I.e. we exploit
>>>>> the fact that the fx spot rate is the same as the ratio of nationals of the
>>>>> two legs. Therefore the fx spot is not needed to set up the helper. Smart.
>>>>>
>>>>> On 18. May 2024, at 18:41, Quant <qua...@gm...> wrote:
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> No, the spot fx is not declared anywhere in the bootstrapping hence my
>>>>> first question was why we don’t have an argument for the quote FX rate
>>>>> which would be used as the implied notional. Not sure if it’s making sense.
>>>>>
>>>>> Thanks & regards,
>>>>> Nk
>>>>>
>>>>> On Sat, 18 May 2024 at 18:28, Peter Caspers <pca...@gm...>
>>>>> wrote:
>>>>>
>>>>>> I guess spot fx is somewhat implicit in the (initial) notionals of
>>>>>> the two legs?
>>>>>> Peter
>>>>>>
>>>>>> On Fri, 17 May 2024 at 03:34, Ben Watson <
>>>>>> ben...@ma...> wrote:
>>>>>> >
>>>>>> > cross currency basis is a spread over a floating index. We use this
>>>>>> to bootstrap curves. It is a direct quote, and no need for a spot FX rate.
>>>>>> >
>>>>>> > The contrast is when we imply a basis over a floating index from
>>>>>> forward fx pips. In this case we need spot fx.
>>>>>> >
>>>>>> > Ben
>>>>>> >
>>>>>> > On Fri, 17 May 2024, 6:16 am Quant, <qua...@gm...>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Hi Quantlib users,
>>>>>> >>
>>>>>> >> When using ql.ConstNotionalCrossCurrencySwapRateHelper() shown
>>>>>> below, are we not supposed to have an argument for the quote FX rate? If
>>>>>> not how do we adjust for the spot FX rate when bootstrapping the basis
>>>>>> adjusted discount curve? Not sure if my question makes sense
>>>>>> >>
>>>>>> >>
>>>>>> https://rkapl123.github.io/QLAnnotatedSource/d6/d3d/class_quant_lib_1_1_const_notional_cross_currency_basis_swap_rate_helper.html
>>>>>> >>
>>>>>> >> Thanks & regards,
>>>>>> >> Nk
>>>>>> >> _______________________________________________
>>>>>> >> QuantLib-users mailing list
>>>>>> >> Qua...@li...
>>>>>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > QuantLib-users mailing list
>>>>>> > Qua...@li...
>>>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> QuantLib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>> Virus-free.www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>> <#m_4982175542612521208_m_5754262361892313513_m_-1964979119827994335_m_4381154520716188394_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Discount Method

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

Hi Michael,

1. a very interesting question but I'm not sure of the answer.  I'm
guessing you could use a root solver for the spread given the prices
implied by the new curves, but I'm probably missing a lot of details.
2. I think the closest we have is the possibility to generate future
interest-rate paths via Monte Carlo given a Hull-White process (which in
turn would be calibrated from a volatility surface).
3. At the moment, I guess the best way would be to extend the swig wrappers
and recompile the wheel to add a call taking a list of dates and this
moving the loop to C++.  I don't know how feasible that is for you,
though...

Luigi


On Fri, May 3, 2024 at 3:53 PM Michael (DataDriven portal) <
mi...@da...> wrote:

> Hi Luigi:
>
> Thanks for getting back to me!
>
> To be specific, we use QuantLib for mortgage bond pricing e.g. calculate
> yields, spreads, durations given mortgage performance inputs (e.g.
> prepayments or default vectors). This works quite well for static metrics
> that rely on a single yield curve input. But we also would like to
> calculate option adjusted measures (e.g. OAS - option adjusted spread) that
> require inputs of many yield curves (e.g. with high/lower rates leves,
> flatter/steeper curve shapes).
>
> So a few specific questions I have are as follows:
>
> 1. What is the best way to generate option adjusted metrics (e.g. OAS) in
> QuantLib if user inputs yield curves with associated probabilities?
> 2. Can QuantLIb generate future yield curves with associated probabilities
> based on current structure of term structure of interest rates and
> volatility surface?
> 3. What is the best way to retrieve the yield curve details for cash flows
> calculations (e.g. monthly discount factors for 360 months which is a
> typical number of cash flows for a mortgage bond)? We tried a *discount*
> method for each month separately but it takes too long.
>
> Thanks,
>
> Michael
>
> On Fri, May 3, 2024 at 4:06 AM Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Hi Michael, apologies for the delay. I'm not sure what's the most
>> effective way to do this.  Well, no, scratch that—the most efficient way
>> would be to do it in C++.  From Python, if you have a process available
>> (such as HullWhiteProcess, for instance) you can use the available
>> PathGenerator class.  What kind of simulation do you have in mind?
>>
>> Luigi
>>
>>
>> On Sat, Apr 20, 2024 at 5:49 PM Michael (DataDriven portal) <
>> mi...@da...> wrote:
>>
>>> Hi Luigi:
>>>
>>> Thank you for getting back to me!
>>>
>>> What is the most efficient way to do Monte Carlo simulations in QuantLib
>>> when I need to obtain multiple paths of yield curves for different
>>> scenarios (they do not have to be vectors of DFs but could be FRAs or any
>>> other rate metrics)?
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>> On Sat, Apr 20, 2024 at 10:59 AM Luigi Ballabio <
>>> lui...@gm...> wrote:
>>>
>>>> Hello Michael,
>>>>     no, I'm afraid vector methods are not available.
>>>>
>>>> Luigi
>>>>
>>>>
>>>> On Sun, Apr 14, 2024 at 8:30 PM Michael (DataDriven portal) <
>>>> mi...@da...> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I am using a *discount* method on a curve to get a discount factor
>>>>> for a given maturity (like in shown in the Cookbook below). But I need to
>>>>> output discount factors for all monthly cash flows of a bond (in my case
>>>>> 360 cash flows) so it is time consuming to call the *discount* method
>>>>> 360 times.
>>>>>
>>>>> Is there a way to get all discount factors (for all cash flows - 360
>>>>> in my case) in a single call to a curve by passing all maturity dates (e.g.
>>>>> in a list) to speed up the calculations?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael
>>>>>
>>>>> [image: image.png]
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>>>

Re: [Quantlib-users] Arguments for ql.ConstNotionalCrossCurrencyBasisSwapRateHelper()

[Quant <qua...@gm...>]

Hi Marcin,

It worked, thanks. I did make two proxy Ibor indices which I then used in
my bootstrapping process as shown below:

sofr_3m = ql.IborIndex('SOFR', ql.Period('3m'), 0, ql.USDCurrency(),

ql.UnitedStates(ql.UnitedStates.FederalReserve), ql.Following, False,
ql.Actual360(),
                       sofr_ts)

sonia_3m = ql.IborIndex('SONIA', ql.Period('3m'), 0, ql.GBPCurrency(),
ql.UnitedKingdom(),
                        ql.Following, False, ql.Actual365Fixed(), sonia_ts)

ccbs_helpers = [
    ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(ql.QuoteHandle(ql.SimpleQuote(basis
/ 10000)), ql.Period(*tenor),
                                                     2, calendar,
ql.Following, False,
                                                     sofr_3m,
sonia_3m, sofr_ts, True,
                                                     False)
    for basis, tenor in [(-5.375, (3, ql.Months)), (-6.875, (6, ql.Months)),
                         (-13.375, (9, ql.Months)), (-12.75, (1, ql.Years)),
                         (-14.875, (2, ql.Years)), (-17.25, (3, ql.Years)),
                         (-19.25, (4, ql.Years)), (-20.25, (5, ql.Years)),
                         (-20.625, (6, ql.Years)), (-20.75, (7, ql.Years)),
                         (-20.75, (8, ql.Years)), (-20.875, (9, ql.Years)),
                         (-21, (10, ql.Years)), (-21.75, (12, ql.Years)),
                         (-24.625, (15, ql.Years)), (-30, (20, ql.Years)),
                         (-36.25, (30, ql.Years)), (-38.75, (40, ql.Years)),
                         (-37.75, (50, ql.Years))]]

basis_adj_sonia_curve = ql.YieldTermStructureHandle(
    ql.PiecewiseLogCubicDiscount(0, calendar, ccbs_helpers, day_counter))

basis_adj_sonia_curve.enableExtrapolation()


Thanks all for the help and contribution. I do agree that we need to
consider improving the helpers
ql.ConstNotionalCrossCurrencyBasisSwapRateHelper and
ql.MtMCrossCurrencyBasisSwapRateHelper

Cheers,
Nk

On Sat, May 18, 2024 at 9:39 PM Marcin Rybacki <mry...@gm...> wrote:

> Hi everyone,
>
> As already pointed out by Peter and Ioannis, the helper utilizes the fact
> that, for a par instrument, the ratio of foreign vs domestic notionals is
> equal to the market spot rate. Hence, they cancel each other out and the FX
> spot rate is not really needed.
>
> Nk, to make your example work for a SOFR-SONIA swap you will have to
> create two proxy Ibor indices (instead of using overnight ones) with 3m
> period each for SOFR and SONIA, respectively. Given that both SOFR and
> SONIA legs use compounded rate averaging, they collapse to Ibor-type
> coupons anyway - this property will apply to coupons that have not started
> accruing yet, which for a par instrument applies to all. This should result
> in a GBP curve under USD collateralization you’re looking for.
>
> We might consider improving the helper by adding a constructor that takes
> an overnight index and payment frequency as parameters.
>
> Hope this helps.
>
> Regards,
> Marcin
>
> On Sat, 18 May 2024 at 21:08, Ioannis Rigopoulos <qua...@de...>
> wrote:
>
>> The baseCurrencyIndex and quoteCurrencyIndex imply the frequency per each
>> floating leg.
>> On 5/18/2024 8:53 PM, Quant wrote:
>>
>> Thanks loannis, what about the payment frequency is it not required in
>> ql.ConstNotionalCrossCurrencyBasisSwapRateHelper() for bootstrapping?
>>
>> Thanks,
>> Nk
>>
>> On Sat, 18 May 2024 at 20:25, Ioannis Rigopoulos <qua...@de...>
>> wrote:
>>
>>> Hi Peter and NK
>>>
>>> For some reason, the email I sent quite some time ago did not go
>>> through. Perhaps because of the link insertion. I repeat it below:
>>>
>>> The spot rate is not needed. Explanation at
>>> https://www.deriscope.com/products/Key_Yield_Curve_Fxb__Spot.html that
>>> describes the spot rate input in the construction of a curve out of xccy
>>> basis spreads.
>>> In effect, any assumed spot rate cancels out due to for any given two
>>> currencies SRC and TGT, the corresponding legs in a currency swap have
>>> differing notionals Nˢʳᶜ and Nᵗᵍᵗ that satisfy:
>>>
>>> Nˢʳᶜ/Nᵗᵍᵗ = s := spot fx rate TGT/SRC
>>>
>>> Ioannis
>>> On 5/18/2024 8:12 PM, Quant wrote:
>>>
>>> Hi Peter,
>>>
>>> So do you agree that we need to have the following additional arguments
>>> in
>>> ql.ConstNotionalCrossCurrencyBasisSwapRateHelper();
>>>
>>> 1. quote FX rate - so that 1 is used as the notional of one leg and the
>>> quote FX rate is used as notional on the other leg
>>>
>>> 2. payment frequency - so that the number of payment frequency is known
>>> for each leg during the bootstrapping process.
>>>
>>> Happy to get your opinion on this.
>>>
>>> Thanks & regards,
>>> Nk
>>>
>>> On Sat, 18 May 2024 at 19:57, Peter Caspers <pca...@gm...>
>>> wrote:
>>>
>>>> It does make sense, I was confused as well.
>>>>
>>>> I think both the domestic and foreign leg are set up with the same
>>>> notional 1.0. I.e. the conversion of the foreign leg’s npv to domestic
>>>> currency is done implicitly by using identical nationals. I.e. we exploit
>>>> the fact that the fx spot rate is the same as the ratio of nationals of the
>>>> two legs. Therefore the fx spot is not needed to set up the helper. Smart.
>>>>
>>>> On 18. May 2024, at 18:41, Quant <qua...@gm...> wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> No, the spot fx is not declared anywhere in the bootstrapping hence my
>>>> first question was why we don’t have an argument for the quote FX rate
>>>> which would be used as the implied notional. Not sure if it’s making sense.
>>>>
>>>> Thanks & regards,
>>>> Nk
>>>>
>>>> On Sat, 18 May 2024 at 18:28, Peter Caspers <pca...@gm...>
>>>> wrote:
>>>>
>>>>> I guess spot fx is somewhat implicit in the (initial) notionals of the
>>>>> two legs?
>>>>> Peter
>>>>>
>>>>> On Fri, 17 May 2024 at 03:34, Ben Watson <
>>>>> ben...@ma...> wrote:
>>>>> >
>>>>> > cross currency basis is a spread over a floating index. We use this
>>>>> to bootstrap curves. It is a direct quote, and no need for a spot FX rate.
>>>>> >
>>>>> > The contrast is when we imply a basis over a floating index from
>>>>> forward fx pips. In this case we need spot fx.
>>>>> >
>>>>> > Ben
>>>>> >
>>>>> > On Fri, 17 May 2024, 6:16 am Quant, <qua...@gm...>
>>>>> wrote:
>>>>> >>
>>>>> >> Hi Quantlib users,
>>>>> >>
>>>>> >> When using ql.ConstNotionalCrossCurrencySwapRateHelper() shown
>>>>> below, are we not supposed to have an argument for the quote FX rate? If
>>>>> not how do we adjust for the spot FX rate when bootstrapping the basis
>>>>> adjusted discount curve? Not sure if my question makes sense
>>>>> >>
>>>>> >>
>>>>> https://rkapl123.github.io/QLAnnotatedSource/d6/d3d/class_quant_lib_1_1_const_notional_cross_currency_basis_swap_rate_helper.html
>>>>> >>
>>>>> >> Thanks & regards,
>>>>> >> Nk
>>>>> >> _______________________________________________
>>>>> >> QuantLib-users mailing list
>>>>> >> Qua...@li...
>>>>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>> >
>>>>> > _______________________________________________
>>>>> > QuantLib-users mailing list
>>>>> > Qua...@li...
>>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> QuantLib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>> Virus-free.www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>> <#m_5754262361892313513_m_-1964979119827994335_m_4381154520716188394_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>