quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] Swap floating cash flows with negative fwd rates seem wrong

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

Right but say I have a stochastically generated curve whereby the forward rate goes from positive to negative during the life of the floating leg. Using the absolute value of each amount is clearly wrong as the sign could change from one period to the next. Multiplying the sum by swap.Payer or swap.Receiver would multiply a number which is wrong to begin with.


Regards

Philippe Hatstadt
+1-203-252-0408
pha...@ma...
https://www.linkedin.com/in/philippe-hatstadt


> On Jul 13, 2020, at 9:36 AM, Amine Ifri <ami...@gm...> wrote:
> 
> Hi Philippe,
> 
> The discounting price engine for the swap calculates the amount() of each Coupon using a class method called Cashflows::npvbps(….) that computes the absolute values for cashflows depending on their “type” (Ibor coupons, CPI coupons, etc….)
> 
> Once these are calculated, then they get multiplied by the swap::argument::payer[] flag which is set to -1 or 1 depending on the type payer or receiver. I suspect what you are calling is the amount() method on the coupons. The correct flag of the leg is handled after calculation of the absolute amount.
> 
> Hope it helps.
> Amine
> 
> 
>> On 13 Jul 2020, at 11:11, philippe hatstadt <pha...@ma...> wrote:
>> 
>> It’s the underlying swap of a swaption. US curve. Swap starts in 2y and ends in 12y. Semi annual fixed act/act versus USDLibor 3M floating a/360.
>> The Hull White path is harder to share other than by providing daily discount factors.
>> Defining dfs and dfe as the discount factors at 2y and 12y, I was able to get the correct fairRate manually by stating that floating leg NPV is equal to dfs - dfe. swap.fixedLegNPV() is correct but not swap.flioatingLeg.NPV().
>> I used today as evaluation date.
>> As you can see below, the floating leg cash flow amounts never change in sign even when the forward rate does. I realize my graph is the instantaneous forward, but the 3M can easily be calculated from the discount factors.
>> 
>> Regards
>> 
>> Philippe Hatstadt
>> +1-203-252-0408
>> pha...@ma...
>> https://www.linkedin.com/in/philippe-hatstadt
>> 
>> 
>>> On Jul 13, 2020, at 5:57 AM, Amine Ifri <ami...@gm...> wrote:
>>> 
>>> I use the C++ library and never had an issue with swap.fairRate(). It gives me positive as well as negative values depending on the term structures.
>>> 
>>> As far as checking the CPP code, it looks correct to me. Do you mind sharing the swap details you are trying to price/simulate?
>>> 
>>> Amine
>>> 
>>>> On 12 Jul 2020, at 03:02, Philippe Hatstadt <phi...@ex...> wrote:
>>>> 
>>>> I'm using a Hull-White model to generate forward paths of the short rate, from which I then build a discounting curve, from which I compute forward swap values towards Monte-carlo integration of certain path dependent swap rate linked derivatives. Here, I am looking at a 2y into 10y swaption, and for each path, I want to calculate the forward swap rate and the swap NPV.
>>>> My problem is that I have a curve that has negative rates on a certain path, the 2y into 10y forward swap.fairRate() function returns like 94bp. Since all rates are negative, it's pretty clear that fairRate() should be negative, and if I use the curve's discount factors and use the good old approximation for the swap rate with the formula C/2 * Sum_i(FixedLegDiscountFactor(i))/(1-DiscountFactor(TMat)) then I get the correct -250bp forward swap rate (where i=1 to 20 corresponding to 20 forward semi-annual fixed payments).
>>>> So I am wondering if the swap cash flows do not work with negative rates or else, but as it stands right now, the swap.fairRate() function doesn't work at all. I also checked that by solving for the fixed rate that would make the swap net cash-flows to be equal to zero, then I get the value returned by swap.fairRate(). This would further indicate that the latter function is correct, but that the cash flows are not. lastly, whether I select a path with positive or negative forward rates, the cf.amount() is always positive.
>>>> This is the code I use to generate the cash-flows:
>>>> def swap_cash_flows(swap: ql.Swap,
>>>>                     crvh,
>>>>                     ):
>>>>     output_list = []
>>>>     for i, cf in enumerate(swap.leg(0)):
>>>>         dt = cf.date()
>>>>         dfact = crvh.discount(dt)
>>>>         output_list.append(['leg0', cf.date(), dfact, cf.amount()])
>>>>     for i, cf in enumerate(swap.leg(1)):
>>>>         dt = cf.date()
>>>>         dfact = crvh.discount(dt)
>>>>         output_list.append(['leg1', cf.date(), dfact, cf.amount()])
>>>>     df1 = pd.DataFrame(columns=['leg', 'cf_date', 'disc_fact', 'cf_amount'], data=output_list)
>>>>     return df1
>>>> The short-rate path corresponding to the curve handle crvh is as follows:
>>>> <image.png>
>>>> and lastly, this is the table of cash flows, dates and discount factors:
>>>> leg	cf_date	disc_fact	cf_amount
>>>> leg0	2023-01-11	1.031727084	0.004717496
>>>> leg0	2023-07-11	1.044326706	0.004640581
>>>> leg0	2024-01-11	1.056475309	0.004717496
>>>> leg0	2024-07-11	1.067323978	0.004666219
>>>> leg0	2025-01-13	1.080208917	0.004768773
>>>> leg0	2025-07-11	1.095773345	0.004589303
>>>> leg0	2026-01-12	1.107358267	0.004743135
>>>> leg0	2026-07-13	1.119706713	0.004666219
>>>> leg0	2027-01-11	1.134937064	0.004666219
>>>> leg0	2027-07-12	1.148588556	0.004666219
>>>> leg0	2028-01-11	1.164662739	0.004691858
>>>> leg0	2028-07-11	1.184811281	0.004666219
>>>> leg0	2029-01-11	1.202933688	0.004717496
>>>> leg0	2029-07-11	1.22143445	0.004640581
>>>> leg0	2030-01-11	1.244698418	0.004717496
>>>> leg0	2030-07-11	1.268437607	0.004640581
>>>> leg0	2031-01-13	1.289269217	0.004768773
>>>> leg0	2031-07-11	1.310335034	0.004589303
>>>> leg0	2032-01-12	1.330460609	0.004743135
>>>> leg0	2032-07-12	1.351119197	0.004666219
>>>> leg1	2022-10-11	1.025077227	0.000595151
>>>> leg1	2023-01-11	1.031727084	0.000595151
>>>> leg1	2023-04-11	1.037740592	0.000582209
>>>> leg1	2023-07-11	1.044326706	0.00058868
>>>> leg1	2023-10-11	1.050712784	0.001151809
>>>> leg1	2024-01-11	1.056475309	0.001190658
>>>> leg1	2024-04-11	1.062040699	0.001177708
>>>> leg1	2024-07-11	1.067323978	0.001177708
>>>> leg1	2024-10-11	1.073341181	0.001190658
>>>> leg1	2025-01-13	1.080208917	0.001216557
>>>> leg1	2025-04-11	1.087963402	0.00113886
>>>> leg1	2025-07-11	1.095773345	0.001322081
>>>> leg1	2025-10-14	1.102080743	0.002477114
>>>> leg1	2026-01-12	1.107358267	0.002346587
>>>> leg1	2026-04-13	1.112978456	0.002372691
>>>> leg1	2026-07-13	1.119706713	0.002372691
>>>> leg1	2026-10-13	1.127732208	0.002398796
>>>> leg1	2027-01-11	1.134937064	0.002346587
>>>> leg1	2027-04-12	1.141923849	0.002372691
>>>> leg1	2027-07-12	1.148588556	0.002390753
>>>> leg1	2027-10-12	1.155929127	0.002537285
>>>> leg1	2028-01-11	1.164662739	0.002509671
>>>> leg1	2028-04-11	1.174741361	0.002509671
>>>> leg1	2028-07-11	1.184811281	0.002509671
>>>> leg1	2028-10-11	1.194083437	0.002537285
>>>> leg1	2029-01-11	1.202933688	0.002537285
>>>> leg1	2029-04-11	1.211815927	0.002482058
>>>> leg1	2029-07-11	1.22143445	0.002509671
>>>> leg1	2029-10-11	1.232822712	0.002537285
>>>> leg1	2030-01-11	1.244698418	0.002537285
>>>> leg1	2030-04-11	1.256926582	0.002482058
>>>> leg1	2030-07-11	1.268437607	0.003472659
>>>> leg1	2030-10-11	1.278474854	0.004092082
>>>> leg1	2031-01-13	1.289269217	0.004181226
>>>> leg1	2031-04-11	1.299839855	0.003914165
>>>> leg1	2031-07-11	1.310335034	0.004047153
>>>> leg1	2031-10-14	1.320633529	0.004225801
>>>> leg1	2032-01-12	1.330460609	0.004002946
>>>> leg1	2032-04-12	1.340898895	0.004047513
>>>> leg1	2032-07-12	1.351119197	0.004047513
>>>> Regards
>>>> 
>>>> Philippe
>>>> 
>>>> 
>>>> 
>>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>>> _______________________________________________
>>>> 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] Swap floating cash flows with negative fwd rates seem wrong

[Amine I. <ami...@gm...>]

Hi Philippe,

The discounting price engine for the swap calculates the amount() of each Coupon using a class method called Cashflows::npvbps(….) that computes the absolute values for cashflows depending on their “type” (Ibor coupons, CPI coupons, etc….)

Once these are calculated, then they get multiplied by the swap::argument::payer[] flag which is set to -1 or 1 depending on the type payer or receiver. I suspect what you are calling is the amount() method on the coupons. The correct flag of the leg is handled after calculation of the absolute amount.

Hope it helps.
Amine


> On 13 Jul 2020, at 11:11, philippe hatstadt <pha...@ma...> wrote:
> 
> It’s the underlying swap of a swaption. US curve. Swap starts in 2y and ends in 12y. Semi annual fixed act/act versus USDLibor 3M floating a/360.
> The Hull White path is harder to share other than by providing daily discount factors.
> Defining dfs and dfe as the discount factors at 2y and 12y, I was able to get the correct fairRate manually by stating that floating leg NPV is equal to dfs - dfe. swap.fixedLegNPV() is correct but not swap.flioatingLeg.NPV().
> I used today as evaluation date.
> As you can see below, the floating leg cash flow amounts never change in sign even when the forward rate does. I realize my graph is the instantaneous forward, but the 3M can easily be calculated from the discount factors.
> 
> Regards
> 
> Philippe Hatstadt
> +1-203-252-0408
> pha...@ma...
> https://www.linkedin.com/in/philippe-hatstadt
> 
> 
>> On Jul 13, 2020, at 5:57 AM, Amine Ifri <ami...@gm...> wrote:
>> 
>> I use the C++ library and never had an issue with swap.fairRate(). It gives me positive as well as negative values depending on the term structures.
>> 
>> As far as checking the CPP code, it looks correct to me. Do you mind sharing the swap details you are trying to price/simulate?
>> 
>> Amine
>> 
>>> On 12 Jul 2020, at 03:02, Philippe Hatstadt <phi...@ex... <mailto:phi...@ex...>> wrote:
>>> 
>>> I'm using a Hull-White model to generate forward paths of the short rate, from which I then build a discounting curve, from which I compute forward swap values towards Monte-carlo integration of certain path dependent swap rate linked derivatives. Here, I am looking at a 2y into 10y swaption, and for each path, I want to calculate the forward swap rate and the swap NPV.
>>> My problem is that I have a curve that has negative rates on a certain path, the 2y into 10y forward swap.fairRate() function returns like 94bp. Since all rates are negative, it's pretty clear that fairRate() should be negative, and if I use the curve's discount factors and use the good old approximation for the swap rate with the formula C/2 * Sum_i(FixedLegDiscountFactor(i))/(1-DiscountFactor(TMat)) then I get the correct -250bp forward swap rate (where i=1 to 20 corresponding to 20 forward semi-annual fixed payments).
>>> So I am wondering if the swap cash flows do not work with negative rates or else, but as it stands right now, the swap.fairRate() function doesn't work at all. I also checked that by solving for the fixed rate that would make the swap net cash-flows to be equal to zero, then I get the value returned by swap.fairRate(). This would further indicate that the latter function is correct, but that the cash flows are not. lastly, whether I select a path with positive or negative forward rates, the cf.amount() is always positive.
>>> This is the code I use to generate the cash-flows:
>>> def swap_cash_flows(swap: ql.Swap,
>>>                     crvh,
>>>                     ):
>>>     output_list = []
>>>     for i, cf in enumerate(swap.leg(0)):
>>>         dt = cf.date()
>>>         dfact = crvh.discount(dt)
>>>         output_list.append(['leg0', cf.date(), dfact, cf.amount()])
>>>     for i, cf in enumerate(swap.leg(1)):
>>>         dt = cf.date()
>>>         dfact = crvh.discount(dt)
>>>         output_list.append(['leg1', cf.date(), dfact, cf.amount()])
>>>     df1 = pd.DataFrame(columns=['leg', 'cf_date', 'disc_fact', 'cf_amount'], data=output_list)
>>>     return df1
>>> The short-rate path corresponding to the curve handle crvh is as follows:
>>> <image.png>
>>> and lastly, this is the table of cash flows, dates and discount factors:
>>> leg	cf_date	disc_fact	cf_amount
>>> leg0	2023-01-11	1.031727084	0.004717496
>>> leg0	2023-07-11	1.044326706	0.004640581
>>> leg0	2024-01-11	1.056475309	0.004717496
>>> leg0	2024-07-11	1.067323978	0.004666219
>>> leg0	2025-01-13	1.080208917	0.004768773
>>> leg0	2025-07-11	1.095773345	0.004589303
>>> leg0	2026-01-12	1.107358267	0.004743135
>>> leg0	2026-07-13	1.119706713	0.004666219
>>> leg0	2027-01-11	1.134937064	0.004666219
>>> leg0	2027-07-12	1.148588556	0.004666219
>>> leg0	2028-01-11	1.164662739	0.004691858
>>> leg0	2028-07-11	1.184811281	0.004666219
>>> leg0	2029-01-11	1.202933688	0.004717496
>>> leg0	2029-07-11	1.22143445	0.004640581
>>> leg0	2030-01-11	1.244698418	0.004717496
>>> leg0	2030-07-11	1.268437607	0.004640581
>>> leg0	2031-01-13	1.289269217	0.004768773
>>> leg0	2031-07-11	1.310335034	0.004589303
>>> leg0	2032-01-12	1.330460609	0.004743135
>>> leg0	2032-07-12	1.351119197	0.004666219
>>> leg1	2022-10-11	1.025077227	0.000595151
>>> leg1	2023-01-11	1.031727084	0.000595151
>>> leg1	2023-04-11	1.037740592	0.000582209
>>> leg1	2023-07-11	1.044326706	0.00058868
>>> leg1	2023-10-11	1.050712784	0.001151809
>>> leg1	2024-01-11	1.056475309	0.001190658
>>> leg1	2024-04-11	1.062040699	0.001177708
>>> leg1	2024-07-11	1.067323978	0.001177708
>>> leg1	2024-10-11	1.073341181	0.001190658
>>> leg1	2025-01-13	1.080208917	0.001216557
>>> leg1	2025-04-11	1.087963402	0.00113886
>>> leg1	2025-07-11	1.095773345	0.001322081
>>> leg1	2025-10-14	1.102080743	0.002477114
>>> leg1	2026-01-12	1.107358267	0.002346587
>>> leg1	2026-04-13	1.112978456	0.002372691
>>> leg1	2026-07-13	1.119706713	0.002372691
>>> leg1	2026-10-13	1.127732208	0.002398796
>>> leg1	2027-01-11	1.134937064	0.002346587
>>> leg1	2027-04-12	1.141923849	0.002372691
>>> leg1	2027-07-12	1.148588556	0.002390753
>>> leg1	2027-10-12	1.155929127	0.002537285
>>> leg1	2028-01-11	1.164662739	0.002509671
>>> leg1	2028-04-11	1.174741361	0.002509671
>>> leg1	2028-07-11	1.184811281	0.002509671
>>> leg1	2028-10-11	1.194083437	0.002537285
>>> leg1	2029-01-11	1.202933688	0.002537285
>>> leg1	2029-04-11	1.211815927	0.002482058
>>> leg1	2029-07-11	1.22143445	0.002509671
>>> leg1	2029-10-11	1.232822712	0.002537285
>>> leg1	2030-01-11	1.244698418	0.002537285
>>> leg1	2030-04-11	1.256926582	0.002482058
>>> leg1	2030-07-11	1.268437607	0.003472659
>>> leg1	2030-10-11	1.278474854	0.004092082
>>> leg1	2031-01-13	1.289269217	0.004181226
>>> leg1	2031-04-11	1.299839855	0.003914165
>>> leg1	2031-07-11	1.310335034	0.004047153
>>> leg1	2031-10-14	1.320633529	0.004225801
>>> leg1	2032-01-12	1.330460609	0.004002946
>>> leg1	2032-04-12	1.340898895	0.004047513
>>> leg1	2032-07-12	1.351119197	0.004047513
>>> Regards
>>> 
>>> Philippe
>>> 
>>> 
>>> 
>>> Brokerage services offered through Exos Securities LLC, member of SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important disclosures, click here <https://www.exosfinancial.com/disclosures>. 
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li... <mailto: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] Swap floating cash flows with negative fwd rates seem wrong

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

It’s the underlying swap of a swaption. US curve. Swap starts in 2y and ends in 12y. Semi annual fixed act/act versus USDLibor 3M floating a/360.
The Hull White path is harder to share other than by providing daily discount factors.
Defining dfs and dfe as the discount factors at 2y and 12y, I was able to get the correct fairRate manually by stating that floating leg NPV is equal to dfs - dfe. swap.fixedLegNPV() is correct but not swap.flioatingLeg.NPV().
I used today as evaluation date.
As you can see below, the floating leg cash flow amounts never change in sign even when the forward rate does. I realize my graph is the instantaneous forward, but the 3M can easily be calculated from the discount factors.

Regards

Philippe Hatstadt
+1-203-252-0408
pha...@ma...
https://www.linkedin.com/in/philippe-hatstadt


> On Jul 13, 2020, at 5:57 AM, Amine Ifri <ami...@gm...> wrote:
> 
> I use the C++ library and never had an issue with swap.fairRate(). It gives me positive as well as negative values depending on the term structures.
> 
> As far as checking the CPP code, it looks correct to me. Do you mind sharing the swap details you are trying to price/simulate?
> 
> Amine
> 
>> On 12 Jul 2020, at 03:02, Philippe Hatstadt <phi...@ex...> wrote:
>> 
>> I'm using a Hull-White model to generate forward paths of the short rate, from which I then build a discounting curve, from which I compute forward swap values towards Monte-carlo integration of certain path dependent swap rate linked derivatives. Here, I am looking at a 2y into 10y swaption, and for each path, I want to calculate the forward swap rate and the swap NPV.
>> My problem is that I have a curve that has negative rates on a certain path, the 2y into 10y forward swap.fairRate() function returns like 94bp. Since all rates are negative, it's pretty clear that fairRate() should be negative, and if I use the curve's discount factors and use the good old approximation for the swap rate with the formula C/2 * Sum_i(FixedLegDiscountFactor(i))/(1-DiscountFactor(TMat)) then I get the correct -250bp forward swap rate (where i=1 to 20 corresponding to 20 forward semi-annual fixed payments).
>> So I am wondering if the swap cash flows do not work with negative rates or else, but as it stands right now, the swap.fairRate() function doesn't work at all. I also checked that by solving for the fixed rate that would make the swap net cash-flows to be equal to zero, then I get the value returned by swap.fairRate(). This would further indicate that the latter function is correct, but that the cash flows are not. lastly, whether I select a path with positive or negative forward rates, the cf.amount() is always positive.
>> This is the code I use to generate the cash-flows:
>> def swap_cash_flows(swap: ql.Swap,
>>                     crvh,
>>                     ):
>>     output_list = []
>>     for i, cf in enumerate(swap.leg(0)):
>>         dt = cf.date()
>>         dfact = crvh.discount(dt)
>>         output_list.append(['leg0', cf.date(), dfact, cf.amount()])
>>     for i, cf in enumerate(swap.leg(1)):
>>         dt = cf.date()
>>         dfact = crvh.discount(dt)
>>         output_list.append(['leg1', cf.date(), dfact, cf.amount()])
>>     df1 = pd.DataFrame(columns=['leg', 'cf_date', 'disc_fact', 'cf_amount'], data=output_list)
>>     return df1
>> The short-rate path corresponding to the curve handle crvh is as follows:
>> <image.png>
>> and lastly, this is the table of cash flows, dates and discount factors:
>> leg	cf_date	disc_fact	cf_amount
>> leg0	2023-01-11	1.031727084	0.004717496
>> leg0	2023-07-11	1.044326706	0.004640581
>> leg0	2024-01-11	1.056475309	0.004717496
>> leg0	2024-07-11	1.067323978	0.004666219
>> leg0	2025-01-13	1.080208917	0.004768773
>> leg0	2025-07-11	1.095773345	0.004589303
>> leg0	2026-01-12	1.107358267	0.004743135
>> leg0	2026-07-13	1.119706713	0.004666219
>> leg0	2027-01-11	1.134937064	0.004666219
>> leg0	2027-07-12	1.148588556	0.004666219
>> leg0	2028-01-11	1.164662739	0.004691858
>> leg0	2028-07-11	1.184811281	0.004666219
>> leg0	2029-01-11	1.202933688	0.004717496
>> leg0	2029-07-11	1.22143445	0.004640581
>> leg0	2030-01-11	1.244698418	0.004717496
>> leg0	2030-07-11	1.268437607	0.004640581
>> leg0	2031-01-13	1.289269217	0.004768773
>> leg0	2031-07-11	1.310335034	0.004589303
>> leg0	2032-01-12	1.330460609	0.004743135
>> leg0	2032-07-12	1.351119197	0.004666219
>> leg1	2022-10-11	1.025077227	0.000595151
>> leg1	2023-01-11	1.031727084	0.000595151
>> leg1	2023-04-11	1.037740592	0.000582209
>> leg1	2023-07-11	1.044326706	0.00058868
>> leg1	2023-10-11	1.050712784	0.001151809
>> leg1	2024-01-11	1.056475309	0.001190658
>> leg1	2024-04-11	1.062040699	0.001177708
>> leg1	2024-07-11	1.067323978	0.001177708
>> leg1	2024-10-11	1.073341181	0.001190658
>> leg1	2025-01-13	1.080208917	0.001216557
>> leg1	2025-04-11	1.087963402	0.00113886
>> leg1	2025-07-11	1.095773345	0.001322081
>> leg1	2025-10-14	1.102080743	0.002477114
>> leg1	2026-01-12	1.107358267	0.002346587
>> leg1	2026-04-13	1.112978456	0.002372691
>> leg1	2026-07-13	1.119706713	0.002372691
>> leg1	2026-10-13	1.127732208	0.002398796
>> leg1	2027-01-11	1.134937064	0.002346587
>> leg1	2027-04-12	1.141923849	0.002372691
>> leg1	2027-07-12	1.148588556	0.002390753
>> leg1	2027-10-12	1.155929127	0.002537285
>> leg1	2028-01-11	1.164662739	0.002509671
>> leg1	2028-04-11	1.174741361	0.002509671
>> leg1	2028-07-11	1.184811281	0.002509671
>> leg1	2028-10-11	1.194083437	0.002537285
>> leg1	2029-01-11	1.202933688	0.002537285
>> leg1	2029-04-11	1.211815927	0.002482058
>> leg1	2029-07-11	1.22143445	0.002509671
>> leg1	2029-10-11	1.232822712	0.002537285
>> leg1	2030-01-11	1.244698418	0.002537285
>> leg1	2030-04-11	1.256926582	0.002482058
>> leg1	2030-07-11	1.268437607	0.003472659
>> leg1	2030-10-11	1.278474854	0.004092082
>> leg1	2031-01-13	1.289269217	0.004181226
>> leg1	2031-04-11	1.299839855	0.003914165
>> leg1	2031-07-11	1.310335034	0.004047153
>> leg1	2031-10-14	1.320633529	0.004225801
>> leg1	2032-01-12	1.330460609	0.004002946
>> leg1	2032-04-12	1.340898895	0.004047513
>> leg1	2032-07-12	1.351119197	0.004047513
>> Regards
>> 
>> Philippe
>> 
>> 
>> 
>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>> _______________________________________________
>> 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] Swap floating cash flows with negative fwd rates seem wrong

[Amine I. <ami...@gm...>]

I use the C++ library and never had an issue with swap.fairRate(). It gives me positive as well as negative values depending on the term structures.

As far as checking the CPP code, it looks correct to me. Do you mind sharing the swap details you are trying to price/simulate?

Amine

> On 12 Jul 2020, at 03:02, Philippe Hatstadt <phi...@ex...> wrote:
> 
> I'm using a Hull-White model to generate forward paths of the short rate, from which I then build a discounting curve, from which I compute forward swap values towards Monte-carlo integration of certain path dependent swap rate linked derivatives. Here, I am looking at a 2y into 10y swaption, and for each path, I want to calculate the forward swap rate and the swap NPV.
> My problem is that I have a curve that has negative rates on a certain path, the 2y into 10y forward swap.fairRate() function returns like 94bp. Since all rates are negative, it's pretty clear that fairRate() should be negative, and if I use the curve's discount factors and use the good old approximation for the swap rate with the formula C/2 * Sum_i(FixedLegDiscountFactor(i))/(1-DiscountFactor(TMat)) then I get the correct -250bp forward swap rate (where i=1 to 20 corresponding to 20 forward semi-annual fixed payments).
> So I am wondering if the swap cash flows do not work with negative rates or else, but as it stands right now, the swap.fairRate() function doesn't work at all. I also checked that by solving for the fixed rate that would make the swap net cash-flows to be equal to zero, then I get the value returned by swap.fairRate(). This would further indicate that the latter function is correct, but that the cash flows are not. lastly, whether I select a path with positive or negative forward rates, the cf.amount() is always positive.
> This is the code I use to generate the cash-flows:
> def swap_cash_flows(swap: ql.Swap,
>                     crvh,
>                     ):
>     output_list = []
>     for i, cf in enumerate(swap.leg(0)):
>         dt = cf.date()
>         dfact = crvh.discount(dt)
>         output_list.append(['leg0', cf.date(), dfact, cf.amount()])
>     for i, cf in enumerate(swap.leg(1)):
>         dt = cf.date()
>         dfact = crvh.discount(dt)
>         output_list.append(['leg1', cf.date(), dfact, cf.amount()])
>     df1 = pd.DataFrame(columns=['leg', 'cf_date', 'disc_fact', 'cf_amount'], data=output_list)
>     return df1
> The short-rate path corresponding to the curve handle crvh is as follows:
> <image.png>
> and lastly, this is the table of cash flows, dates and discount factors:
> leg	cf_date	disc_fact	cf_amount
> leg0	2023-01-11	1.031727084	0.004717496
> leg0	2023-07-11	1.044326706	0.004640581
> leg0	2024-01-11	1.056475309	0.004717496
> leg0	2024-07-11	1.067323978	0.004666219
> leg0	2025-01-13	1.080208917	0.004768773
> leg0	2025-07-11	1.095773345	0.004589303
> leg0	2026-01-12	1.107358267	0.004743135
> leg0	2026-07-13	1.119706713	0.004666219
> leg0	2027-01-11	1.134937064	0.004666219
> leg0	2027-07-12	1.148588556	0.004666219
> leg0	2028-01-11	1.164662739	0.004691858
> leg0	2028-07-11	1.184811281	0.004666219
> leg0	2029-01-11	1.202933688	0.004717496
> leg0	2029-07-11	1.22143445	0.004640581
> leg0	2030-01-11	1.244698418	0.004717496
> leg0	2030-07-11	1.268437607	0.004640581
> leg0	2031-01-13	1.289269217	0.004768773
> leg0	2031-07-11	1.310335034	0.004589303
> leg0	2032-01-12	1.330460609	0.004743135
> leg0	2032-07-12	1.351119197	0.004666219
> leg1	2022-10-11	1.025077227	0.000595151
> leg1	2023-01-11	1.031727084	0.000595151
> leg1	2023-04-11	1.037740592	0.000582209
> leg1	2023-07-11	1.044326706	0.00058868
> leg1	2023-10-11	1.050712784	0.001151809
> leg1	2024-01-11	1.056475309	0.001190658
> leg1	2024-04-11	1.062040699	0.001177708
> leg1	2024-07-11	1.067323978	0.001177708
> leg1	2024-10-11	1.073341181	0.001190658
> leg1	2025-01-13	1.080208917	0.001216557
> leg1	2025-04-11	1.087963402	0.00113886
> leg1	2025-07-11	1.095773345	0.001322081
> leg1	2025-10-14	1.102080743	0.002477114
> leg1	2026-01-12	1.107358267	0.002346587
> leg1	2026-04-13	1.112978456	0.002372691
> leg1	2026-07-13	1.119706713	0.002372691
> leg1	2026-10-13	1.127732208	0.002398796
> leg1	2027-01-11	1.134937064	0.002346587
> leg1	2027-04-12	1.141923849	0.002372691
> leg1	2027-07-12	1.148588556	0.002390753
> leg1	2027-10-12	1.155929127	0.002537285
> leg1	2028-01-11	1.164662739	0.002509671
> leg1	2028-04-11	1.174741361	0.002509671
> leg1	2028-07-11	1.184811281	0.002509671
> leg1	2028-10-11	1.194083437	0.002537285
> leg1	2029-01-11	1.202933688	0.002537285
> leg1	2029-04-11	1.211815927	0.002482058
> leg1	2029-07-11	1.22143445	0.002509671
> leg1	2029-10-11	1.232822712	0.002537285
> leg1	2030-01-11	1.244698418	0.002537285
> leg1	2030-04-11	1.256926582	0.002482058
> leg1	2030-07-11	1.268437607	0.003472659
> leg1	2030-10-11	1.278474854	0.004092082
> leg1	2031-01-13	1.289269217	0.004181226
> leg1	2031-04-11	1.299839855	0.003914165
> leg1	2031-07-11	1.310335034	0.004047153
> leg1	2031-10-14	1.320633529	0.004225801
> leg1	2032-01-12	1.330460609	0.004002946
> leg1	2032-04-12	1.340898895	0.004047513
> leg1	2032-07-12	1.351119197	0.004047513
> Regards
> 
> Philippe
> 
> 
> 
> Brokerage services offered through Exos Securities LLC, member of SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important disclosures, click here <https://www.exosfinancial.com/disclosures>. 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-users] Swap floating cash flows with negative fwd rates seem wrong

[Philippe H. <phi...@ex...>]

I'm using a Hull-White model to generate forward paths of the short rate,
from which I then build a discounting curve, from which I compute forward
swap values towards Monte-carlo integration of certain path dependent swap
rate linked derivatives. Here, I am looking at a 2y into 10y swaption, and
for each path, I want to calculate the forward swap rate and the swap NPV.
My problem is that I have a curve that has negative rates on a certain
path, the 2y into 10y forward swap.fairRate() function returns like 94bp.
Since all rates are negative, it's pretty clear that fairRate() should be
negative, and if I use the curve's discount factors and use the good old
approximation for the swap rate with the formula C/2 *
Sum_i(FixedLegDiscountFactor(i))/(1-DiscountFactor(TMat)) then I get the
correct -250bp forward swap rate (where i=1 to 20 corresponding to 20
forward semi-annual fixed payments).
So I am wondering if the swap cash flows do not work with negative rates or
else, but as it stands right now, the swap.fairRate() function doesn't
work at all. I also checked that by solving for the fixed rate that would
make the swap net cash-flows to be equal to zero, then I get the value
returned by swap.fairRate(). This would further indicate that the latter
function is correct, but that the cash flows are not. lastly, whether I
select a path with positive or negative forward rates, the cf.amount() is
always positive.
This is the code I use to generate the cash-flows:

def swap_cash_flows(swap: ql.Swap,
                    crvh,
                    ):
    output_list = []
    for i, cf in enumerate(swap.leg(0)):
        dt = cf.date()
        dfact = crvh.discount(dt)
        output_list.append(['leg0', cf.date(), dfact, cf.amount()])
    for i, cf in enumerate(swap.leg(1)):
        dt = cf.date()
        dfact = crvh.discount(dt)
        output_list.append(['leg1', cf.date(), dfact, cf.amount()])
    df1 = pd.DataFrame(columns=['leg', 'cf_date', 'disc_fact',
'cf_amount'], data=output_list)
    return df1

The short-rate path corresponding to the curve handle crvh is as follows:
[image: image.png]
and lastly, this is the table of cash flows, dates and discount factors:
leg cf_date disc_fact cf_amount
leg0 2023-01-11 1.031727084 0.004717496
leg0 2023-07-11 1.044326706 0.004640581
leg0 2024-01-11 1.056475309 0.004717496
leg0 2024-07-11 1.067323978 0.004666219
leg0 2025-01-13 1.080208917 0.004768773
leg0 2025-07-11 1.095773345 0.004589303
leg0 2026-01-12 1.107358267 0.004743135
leg0 2026-07-13 1.119706713 0.004666219
leg0 2027-01-11 1.134937064 0.004666219
leg0 2027-07-12 1.148588556 0.004666219
leg0 2028-01-11 1.164662739 0.004691858
leg0 2028-07-11 1.184811281 0.004666219
leg0 2029-01-11 1.202933688 0.004717496
leg0 2029-07-11 1.22143445 0.004640581
leg0 2030-01-11 1.244698418 0.004717496
leg0 2030-07-11 1.268437607 0.004640581
leg0 2031-01-13 1.289269217 0.004768773
leg0 2031-07-11 1.310335034 0.004589303
leg0 2032-01-12 1.330460609 0.004743135
leg0 2032-07-12 1.351119197 0.004666219
leg1 2022-10-11 1.025077227 0.000595151
leg1 2023-01-11 1.031727084 0.000595151
leg1 2023-04-11 1.037740592 0.000582209
leg1 2023-07-11 1.044326706 0.00058868
leg1 2023-10-11 1.050712784 0.001151809
leg1 2024-01-11 1.056475309 0.001190658
leg1 2024-04-11 1.062040699 0.001177708
leg1 2024-07-11 1.067323978 0.001177708
leg1 2024-10-11 1.073341181 0.001190658
leg1 2025-01-13 1.080208917 0.001216557
leg1 2025-04-11 1.087963402 0.00113886
leg1 2025-07-11 1.095773345 0.001322081
leg1 2025-10-14 1.102080743 0.002477114
leg1 2026-01-12 1.107358267 0.002346587
leg1 2026-04-13 1.112978456 0.002372691
leg1 2026-07-13 1.119706713 0.002372691
leg1 2026-10-13 1.127732208 0.002398796
leg1 2027-01-11 1.134937064 0.002346587
leg1 2027-04-12 1.141923849 0.002372691
leg1 2027-07-12 1.148588556 0.002390753
leg1 2027-10-12 1.155929127 0.002537285
leg1 2028-01-11 1.164662739 0.002509671
leg1 2028-04-11 1.174741361 0.002509671
leg1 2028-07-11 1.184811281 0.002509671
leg1 2028-10-11 1.194083437 0.002537285
leg1 2029-01-11 1.202933688 0.002537285
leg1 2029-04-11 1.211815927 0.002482058
leg1 2029-07-11 1.22143445 0.002509671
leg1 2029-10-11 1.232822712 0.002537285
leg1 2030-01-11 1.244698418 0.002537285
leg1 2030-04-11 1.256926582 0.002482058
leg1 2030-07-11 1.268437607 0.003472659
leg1 2030-10-11 1.278474854 0.004092082
leg1 2031-01-13 1.289269217 0.004181226
leg1 2031-04-11 1.299839855 0.003914165
leg1 2031-07-11 1.310335034 0.004047153
leg1 2031-10-14 1.320633529 0.004225801
leg1 2032-01-12 1.330460609 0.004002946
leg1 2032-04-12 1.340898895 0.004047513
leg1 2032-07-12 1.351119197 0.004047513
Regards

Philippe

-- 








Brokerage services offered through Exos Securities LLC, member of 
SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important 
disclosures, click here <https://www.exosfinancial.com/disclosures>. 

Re: [Quantlib-users] FD Greeks computation when the calculated NPV value is too close to the spot value

[Prasanna K. <pk...@ku...>]

I just realized that I mis-stated the question (the condition is NOT meant to skip when the computed option NPV is too close to the spot price….it is meant to skip when the underlying times the tolerance (1.0e-5) is is less than the option NPV).  Can someone please explain how this condition was arrived at OR why it is necessary?  And, if there is a way to work around this?  Thanks.

> On Jul 9, 2020, at 9:47 PM, Prasanna Katta <pk...@ku...> wrote:
> 
> Hello,
> In the European and American options test suite, there are tests for validating the computation of FD Greeks.  In the tests there is this condition:
>  "if(value > spot->value() * 1.0e-5)”
> 
> The goal of this condition seems to be to skip the computation/testing of FD greeks when the computed option NPV is too close to the spot price.   The computed greeks in this scenario have errors that are more than the acceptable tolerance.
> 
> Does this mean no analytical greeks can be computed when the option NPV is too close to the spot price?  Is there a way around this limitation?
> 
> Thanks.

[Quantlib-users] FD Greeks computation when the calculated NPV value is too close to the spot value

[Prasanna K. <pk...@ku...>]

Hello,
In the European and American options test suite, there are tests for validating the computation of FD Greeks.  In the tests there is this condition:
 "if(value > spot->value() * 1.0e-5)”

The goal of this condition seems to be to skip the computation/testing of FD greeks when the computed option NPV is too close to the spot price.   The computed greeks in this scenario have errors that are more than the acceptable tolerance.

Does this mean no analytical greeks can be computed when the option NPV is too close to the spot price?  Is there a way around this limitation?

Thanks.

Re: [Quantlib-users] DiscountBondOption pricers for QuantLib models

[Amine I. <ami...@gm...>]

Thanks David, I am running C++
I am running an old QL version (1.9.2) thats probably why.

Thanks!

> On 9 Jul 2020, at 21:32, David Duarte <nh...@gm...> wrote:
> 
> Are you referring to C++ or Python?
> 
> Has been supported for some time (version) in C++ and was recently added to the python module.
> 
> Here is an example:
> 
> period = ql.Period('2y')
> quote = ql.QuoteHandle(ql.SimpleQuote(0.55))
> today = ql.Date().todaysDate()
> yts = ql.YieldTermStructureHandle(ql.FlatForward(today, 0.02, ql.Actual360()))
> index = ql.Euribor6M(yts)
> 
> helper = ql.CapHelper(period, quote, index, ql.Semiannual, ql.Actual360(), False, yts, ql.BlackCalibrationHelper.RelativePriceError, ql.Normal)
> 
> Regards,
> David
> 
> 
> 
> On Thu, 9 Jul 2020 at 21:14, Amine Ifri <ami...@gm... <mailto:ami...@gm...>> wrote:
> Hi Luigi, all,
> 
> Hope you are well. Just wanted to check whether Swaption calibration helpers in Quantlib support both normal and log-normal volatilities, whereas Cap Helpers only support Log normal vols.
> 
> Thanks for confirming,
> Amine
> 
> 
> 
> 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li... <mailto:Qua...@li...>
> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>

Re: [Quantlib-users] DiscountBondOption pricers for QuantLib models

[David D. <nh...@gm...>]

Are you referring to C++ or Python?

Has been supported for some time (version) in C++ and was recently added to
the python module.

Here is an example:

period = ql.Period('2y')
quote = ql.QuoteHandle(ql.SimpleQuote(0.55))
today = ql.Date().todaysDate()
yts = ql.YieldTermStructureHandle(ql.FlatForward(today, 0.02,
ql.Actual360()))
index = ql.Euribor6M(yts)

helper = ql.CapHelper(period, quote, index, ql.Semiannual, ql.Actual360(),
False, yts, ql.BlackCalibrationHelper.RelativePriceError, ql.Normal)

Regards,
David



On Thu, 9 Jul 2020 at 21:14, Amine Ifri <ami...@gm...> wrote:

> Hi Luigi, all,
>
> Hope you are well. Just wanted to check whether Swaption calibration
> helpers in Quantlib support both normal and log-normal volatilities,
> whereas Cap Helpers only support Log normal vols.
>
> Thanks for confirming,
> Amine
>
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] DiscountBondOption pricers for QuantLib models

[Amine I. <ami...@gm...>]

Hi Luigi, all,

Hope you are well. Just wanted to check whether Swaption calibration helpers in Quantlib support both normal and log-normal volatilities, whereas Cap Helpers only support Log normal vols.

Thanks for confirming,
Amine

Re: [Quantlib-users] Boost error when compiling Quantlib C++

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

Hello Jussi,
    I think you're compiling in strict C++20 mode and the sources are not
ready for that yet.  May you check your settings and see if you can tell
the compiler to use at most C++17?

Luigi


On Mon, Jul 6, 2020 at 7:40 PM Jussi Kettu <ker...@gm...> wrote:

> When compiling Quantlib C++ in Visual Studio 2019 with boost 1.72 (and
> some example projects) I keep getting this error:
>
> bind.hpp(75,25): error C2039: 'result_type': is not a member of
> 'std::multiplies<QuantLib::Real>' (compiling source file
> ql\experimental\credit\gaussianlhplossmodel.cpp)
>
> Why do I get this error and how could I fix this error? I googled about it
> and tried many things but did not find a solution yet.
>
> Thank you
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Boost error when compiling Quantlib C++

[Jussi K. <ker...@gm...>]

When compiling Quantlib C++ in Visual Studio 2019 with boost 1.72 (and some
example projects) I keep getting this error:

bind.hpp(75,25): error C2039: 'result_type': is not a member of
'std::multiplies<QuantLib::Real>' (compiling source file
ql\experimental\credit\gaussianlhplossmodel.cpp)

Why do I get this error and how could I fix this error? I googled about it
and tried many things but did not find a solution yet.

Thank you

Re: [Quantlib-users] Calibration classes for G2 model parameters on SwaptionHelpers

[Amine I. <ami...@gm...>]

Thanks Luigi & all,

Been trying to get my calibration to run on a G2 model where I only calibrate the volatility params, so I specify that fixedparameter vector for those two parameters is set to false. However, they remain unchanged.

Any idea as to what I may be doing wrong? Below are the snippets of code I used.

Thanks,
Amine

void calibrateModel(ShortRateModel& model, const std::vector<boost::shared_ptr<CalibrationHelper>> &helpers,
                    const std::vector<Real>& weights, const std::vector<bool>& fixParameters)
{
    LevenbergMarquardt om;
    EndCriteria stop(400, 100, 1.0e-5, 1.0e-7, 1.0e-5);
    model.calibrate(helpers, om, stop, Constraint(), weights, fixParameters);
    return;
}


// Calibrate and log calibrated parameters
    Real correls[] = {-0.9, -0.5, -0.2 };
    Real a = 0.8, sigma1 = 0.01, b = 0.15, eta = 0.0085, rho = correls[0];

    boost::shared_ptr<ShortRateModel> modelG2 =
            boost::make_shared<G2>(Handle<YieldTermStructure>(yieldCurveInput), a, sigma1, b, eta, rho);

    auto modelG2Params = modelG2->params();
    std::vector<bool> nonFreeModelG2Params(modelG2Params.size());
    nonFreeModelG2Params[0] = true; nonFreeModelG2Params[1]=false;
    nonFreeModelG2Params[2] = true; nonFreeModelG2Params[3]=false; // <== modelG2 parameters that will be calibrated (i.e, non fixed)
    nonFreeModelG2Params[4] = true;

    calibrateModel(*modelG2, swaptionhelpers, std::vector<Real>(), nonFreeModelG2Params);
    std::cout << "\nCalibrated G2 model parameters: " << "\n\n";
    auto calibratedParams=modelG2->params();

    for(auto i=0; i<calibratedParams.size(); ++i)
        std::cout << calibratedParams[i] << "\n";


> On 3 Jul 2020, at 14:08, Luigi Ballabio <lui...@gm...> wrote:
> 
> Hello,
>     see Examples/BermudanSwaption/BermudanSwaption.cpp.
> 
> Luigi
> 
> 
> On Fri, Jul 3, 2020 at 2:50 PM Amine Ifri <ami...@gm... <mailto:ami...@gm...>> wrote:
> Hi all,
> 
> Looking to calibrate model parameters of a G2 model for rates on a set of swaption volatilities, is there a class in QuantLib that does just that, or does one need to write it from scratch?
> 
> Thanks,
> Amine
> 

Re: [Quantlib-users] Calibration classes for G2 model parameters on SwaptionHelpers

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

Hello,
    see Examples/BermudanSwaption/BermudanSwaption.cpp.

Luigi


On Fri, Jul 3, 2020 at 2:50 PM Amine Ifri <ami...@gm...> wrote:

> Hi all,
>
> Looking to calibrate model parameters of a G2 model for rates on a set of
> swaption volatilities, is there a class in QuantLib that does just that, or
> does one need to write it from scratch?
>
> Thanks,
> Amine
>
>

[Quantlib-users] Calibration classes for G2 model parameters on SwaptionHelpers

[Amine I. <ami...@gm...>]

Hi all,

Looking to calibrate model parameters of a G2 model for rates on a set of swaption volatilities, is there a class in QuantLib that does just that, or does one need to write it from scratch?

Thanks,
Amine

[Quantlib-users] Release candidates for 1.19

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

Hello everybody,
    I uploaded release candidates for QuantLib 1.19 to <
https://bintray.com/beta/#/quantlib/prerelease/QuantLib/1.19-rc?tab=overview
>.

If you have some time and nothing better to do, please try building them
and tell me if there are any problems.

Thanks,
    Luigi

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Shenze W. <she...@da...>]

Hi Klaus & Luigi,

Thanks a lot for your explanations and referring to the papers. They are very helpful and I learnt a lot.

After studying the paper Back to basic, I believe the dividend model in that paper (Spot model in QuantLib) is good model with the correct assumption about the process of the underlying, when there are dividends. We’ll probably go with this one.

I also think it’s a good idea disable the Escrowed model for path dependent options.

Here is one observations about Escrowed model.
Even for European options, FdBalckScholesVanilaEngine with Escrowed model and AnalyticDividendEuropeanEngine will give wrong or poor results when the dividend is huge, as shown in the following screen shot. This call option has a big dividend right before expiry and a strike price of 0. You may argue that this is a wired option. But actually you can consider this option as the equity part in the Merton’s model of credit risk. The reason is that in Escrowed model, the dividend part of the underlying price has 0 volatility.
Here is one thought about the impliedVolatility.
I agree that FdBalckScholesVanilaEngine is a good default engine when calculating ivol for American options. But it would be really nice if I can specify the parameters of this engine when using impliedVolatility(). Because for options with strike far from spot, the results of FdBalckScholesVanilaEngine with default grid_points are not accurate enough. I can use a larger grid_points when calculating the price, but not the impliedVolatility for now. A $30 strike put on a $300 underlying stock is not rare in the market.

Here is one more questions.
When the stock price is lower than the dividend on the dividend date, what is current behavior of the FdBalckScholesVanilaEngine. Will it pay a dividend equal to the current stock price, or will it pay nothing at all?

Thanks again.


Best,
Shenze

On Jun 26, 2020, 8:30 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> Hi Shenze,
> I think, we have a naming clash here. The implementation of the escrowed dividend models follows chapter 9.1.1 "The Escrowed Dividend Model" in E. Haug's "Guide to Option Pricing Formulas", quote "...can be priced by the BSM formula, by simple replacing S with S minus the present value of the dividends". As we've said before and also stated in Haug's book, in this form the model is not really appicable for American/Bermudan options.
> The escrowed model was added lately to FdBlackScholesVanillaEngine mainly, to have a dividend model, which is compatible with the AnalyticDividendEuropeanEngine (for the spot adjustment, see line 50ff in analyticdividendeuropeanengine.cpp).
> Sure, one can extend the original model definition from Haug's book by
> > The process should follow S_t = 10 * x_t + GBM(90), in which 10 is the present value of dividends, and x_t is 1 before the dividend and 0 after the dividend.
> and this will improve American/Bermudan pricing.
> Looking at your explanations below, you should be fine with the default dividend model. Just to be precise, for your example the default model will start a GBM at 100 and adds a deterministic down jump at every dividend date. The default model also covers the case S < D.
> hope that helps, regards
> Klaus
> On Freitag, 26. Juni 2020 22:48:17 CEST Shenze Wang wrote:
> Hi,
>
> A correction for the last email.
>
> About the Escrowed dividend model, I think:
> The process should follow S_t = 10 * x_t + GBM(90), in which 10 is the present value of dividends, and x_t is 1 before the dividend and 0 after the dividend.
>
>
> Best,
> Shenze
> On Jun 26, 2020, 4:43 PM -0400, Shenze Wang <she...@da...>, wrote:
> Hi Klaus,
>
> I think I have a different understanding about Escrowed dividend model from you.
>
> Let GBM(S_0) represents a Geometric Brownian motion with initial price S_0. In the previous example, with Escrowed dividend model,
>
> • You think, the process of the stock S = GBM(90);
> • However, I think, the process should follow S = 10 + GBM(90), in which 10 is the present value of dividends;
>
> The paper Back to Basics proposes that S = GBM(100), but with proper adjustment or assumption when S < D at dividend time.
>
> If the Spot dividend model is following that paper, then the difference between the Spot and Escrowed should be that Spot handles the situation when S<D, while Escrowed does not. I do not think throwing away the dividend totally from the process of the price is the right way. If the Escrowed dividend is programmed by my understanding, I believe it also can provide fairly accurate results as long as the dividend is not huge compared to the stock price.
>
> Some other things:
>
> 1. The option mentioned in my previous email will be always exercised on 30.12.2020, right before the dividend, because it’s an American call.
> 2. I think the old FDDividendAmericanEngine does not provide the same results as the Escrowed model in the new engine. Codes and results are in attached files.
>
>
>
> Best,
> Shenze

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Klaus S. <kl...@sp...>]

Hi Shenze,

I think, we have a naming clash here. The implementation of the escrowed dividend models follows chapter 9.1.1 "The Escrowed Dividend Model" in E. Haug's "Guide to Option Pricing Formulas", quote "...can be priced by the BSM formula, by simple replacing S with S minus the present value of the dividends". As we've said before and also stated in Haug's book, in this form the model is not really appicable for American/Bermudan options.

The escrowed model was added lately to FdBlackScholesVanillaEngine mainly, to have a dividend  model, which is compatible with the AnalyticDividendEuropeanEngine (for the spot adjustment, see line 50ff in analyticdividendeuropeanengine.cpp).

Sure, one can extend the original model definition from Haug's book by 
> The process should follow *S_t = 10 * x_t + GBM(90)*, in which 10 is the present value of dividends, and x_t is 1 before the dividend and 0 after the dividend.
and this will improve American/Bermudan pricing.

Looking at your explanations below, you should be fine with the default dividend model. Just to be precise, for your example the default model will start a GBM at 100 and adds a deterministic down jump at every dividend date. The default model also covers the case S < D.


hope that helps, regards
Klaus

On Freitag, 26. Juni 2020 22:48:17 CEST Shenze Wang wrote:


Hi, 


A correction for the last email.


About the Escrowed dividend model, I think:
The process should follow *S_t = 10 * x_t + GBM(90)*, in which 10 is the present value of dividends, and x_t is 1 before the dividend and 0 after the dividend.






Best,
Shenze
On Jun 26, 2020, 4:43 PM -0400, Shenze Wang <she...@da...>, wrote:


Hi Klaus,  


I think I have a different understanding about Escrowed dividend model from you. 


Let GBM(S_0) represents a Geometric Brownian motion with initial price S_0. In the previous example, with Escrowed dividend model, 
     *  You think, the process of the stock *S = GBM(90)*;


     *  However, I think, the process should follow *S = 10 + GBM(90)*, in which 10 is the present value of dividends;
The paper /Back to Basics/ proposes that *S = GBM(100)*, but with proper adjustment or assumption when* *S < D at dividend time.




If the Spot dividend model is following that paper, then the difference between the Spot and Escrowed should be that Spot handles the situation when S<D, while Escrowed does not. I do not think throwing away the dividend totally from the process of the price is the right way. If the Escrowed dividend is programmed by my understanding, I believe it also can provide fairly accurate results as long as the dividend is not huge compared to the stock price.


Some other things:
     1. The option mentioned in my previous email will be always exercised on 30.12.2020, right before the dividend, because it’s an American call.
     2. I think the old FDDividendAmericanEngine does not provide the same results as the Escrowed model in the new engine. Codes and results are in attached files.




Best,
Shenze

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Shenze W. <she...@da...>]

Hi Klaus,

I think I have a different understanding about Escrowed dividend model from you.

Let GBM(S_0) represents a Geometric Brownian motion with initial price S_0. In the previous example, with Escrowed dividend model,

• You think, the process of the stock S = GBM(90);
• However, I think, the process should follow S = 10 + GBM(90), in which 10 is the present value of dividends;

The paper Back to Basics proposes that S = GBM(100), but with proper adjustment or assumption when S < D at dividend time.

If the Spot dividend model is following that paper, then the difference between the Spot and Escrowed should be that Spot handles the situation when S<D, while Escrowed does not. I do not think throwing away the dividend totally from the process of the price is the right way. If the Escrowed dividend is programmed by my understanding, I believe it also can provide fairly accurate results as long as the dividend is not huge compared to the stock price.

Some other things:

1. The option mentioned in my previous email will be always exercised on 30.12.2020, right before the dividend, because it’s an American call.
2. I think the old FDDividendAmericanEngine does not provide the same results as the Escrowed model in the new engine. Codes and results are in attached files.



Best,
Shenze

On Jun 26, 2020, 3:59 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> Hi Shenze,
>
> thanks for the example, it nicely highlights the importance of dividend modelling for equity option.
>
> Within the spot dividend model the dividend of 10 is substracted from the equity process on the 31.12.2020. The option will be early exercised somewhere between today and the 30.12.2020 to earn the intrinsic value of 10, hence this model gives the expected result.
>
> The escrowed dividend model substracts the net dividend payment from the start value of 100 and starts a geometric brownian motion at S(t=0) = S - D = 90. As the volatility is almost zero this process ends at 90 on maturity and the american option expires worthless. Both engine, the old FDDividendAmericanEngine and the FdBlackScholesVanillaEngine produce this result. The numerics is ok but the model is not appicable for this problem and delivers results, which look "a little wired" to say the least;-).
>
> best
> Klaus
>
> On Freitag, 26. Juni 2020 20:50:54 CEST Shenze Wang wrote:
> > Hi Klaus,
> >
> > I understand that different dividend models have different assumptions about the underlying process of the stock price. So, the pricing results will be different.
> >
> > But could you please help me check the pricing results in the following screenshot? It is an American call option with extremely low volatility and a dividend right before the expiry date. S = 100 and K =90. I think the value of this option should be very close to 10, which matches the result of the Spot dividend model. However, the pricing result from Escrowed dividend model is 0, which looks a little wired.
> >
> > Thanks a lot for your patience.
> >
> >
> >
> > Best,
> > Shenze
> >
> >
> > On Jun 26, 2020, 1:32 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> > > Hi
> > > Spot dividend and escrowed dividend model are different models and are supposed to give different results for the same parameter set. An implied volatility calculated with the escrowed dividend model will not give the same price back when used in a spot dividend model because the underlying stochastic differential equations are different.
> > > best regards
> > > Klaus
> > > On Freitag, 26. Juni 2020 17:34:57 CEST Shenze Wang wrote:
> > > Hi Klaus,
> > >
> > > Thanks a lot for you explanations.
> > >
> > > I made more calculations. It seems that the differences between Spot dividend model and Escrowed dividend model are not only for pathologic cases. And also a greater number of time steps and grid points do not help. The calculation results are attached. So I guess that there may be something goes wrong with Spot dividend model.
> > >
> > > The difference between the two dividend model also causes another bug in impliedVolatility. Because for American options, FdBlackScholesVanillaEngine with Spot dividend model is always being used, when calculating ivol. Here is the issue I opened, https://github.com/lballabio/QuantLib/issues/850.
> > >
> > > I think maybe it is necessary to take a closer look at the two dividend models.
> > >
> > >
> > > Best,
> > > Shenze
> > > _______________________________________________
> > > QuantLib-users mailing list
> > > Qua...@li...
> > > https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
>
>
>
>

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Shenze W. <she...@da...>]

Hi,

A correction for the last email.

About the Escrowed dividend model, I think:
The process should follow S_t = 10 * x_t + GBM(90), in which 10 is the present value of dividends, and x_t is 1 before the dividend and 0 after the dividend.


Best,
Shenze
On Jun 26, 2020, 4:43 PM -0400, Shenze Wang <she...@da...>, wrote:
> Hi Klaus,
>
> I think I have a different understanding about Escrowed dividend model from you.
>
> Let GBM(S_0) represents a Geometric Brownian motion with initial price S_0. In the previous example, with Escrowed dividend model,
>
> • You think, the process of the stock S = GBM(90);
> • However, I think, the process should follow S = 10 + GBM(90), in which 10 is the present value of dividends;
>
> The paper Back to Basics proposes that S = GBM(100), but with proper adjustment or assumption when S < D at dividend time.
>
> If the Spot dividend model is following that paper, then the difference between the Spot and Escrowed should be that Spot handles the situation when S<D, while Escrowed does not. I do not think throwing away the dividend totally from the process of the price is the right way. If the Escrowed dividend is programmed by my understanding, I believe it also can provide fairly accurate results as long as the dividend is not huge compared to the stock price.
>
> Some other things:
>
> 1. The option mentioned in my previous email will be always exercised on 30.12.2020, right before the dividend, because it’s an American call.
> 2. I think the old FDDividendAmericanEngine does not provide the same results as the Escrowed model in the new engine. Codes and results are in attached files.
>
>
>
> Best,
> Shenze
>
> On Jun 26, 2020, 3:59 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> > Hi Shenze,
> >
> > thanks for the example, it nicely highlights the importance of dividend modelling for equity option.
> >
> > Within the spot dividend model the dividend of 10 is substracted from the equity process on the 31.12.2020. The option will be early exercised somewhere between today and the 30.12.2020 to earn the intrinsic value of 10, hence this model gives the expected result.
> >
> > The escrowed dividend model substracts the net dividend payment from the start value of 100 and starts a geometric brownian motion at S(t=0) = S - D = 90. As the volatility is almost zero this process ends at 90 on maturity and the american option expires worthless. Both engine, the old FDDividendAmericanEngine and the FdBlackScholesVanillaEngine produce this result. The numerics is ok but the model is not appicable for this problem and delivers results, which look "a little wired" to say the least;-).
> >
> > best
> > Klaus
> >
> > On Freitag, 26. Juni 2020 20:50:54 CEST Shenze Wang wrote:
> > > Hi Klaus,
> > >
> > > I understand that different dividend models have different assumptions about the underlying process of the stock price. So, the pricing results will be different.
> > >
> > > But could you please help me check the pricing results in the following screenshot? It is an American call option with extremely low volatility and a dividend right before the expiry date. S = 100 and K =90. I think the value of this option should be very close to 10, which matches the result of the Spot dividend model. However, the pricing result from Escrowed dividend model is 0, which looks a little wired.
> > >
> > > Thanks a lot for your patience.
> > >
> > >
> > >
> > > Best,
> > > Shenze
> > >
> > >
> > > On Jun 26, 2020, 1:32 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> > > > Hi
> > > > Spot dividend and escrowed dividend model are different models and are supposed to give different results for the same parameter set. An implied volatility calculated with the escrowed dividend model will not give the same price back when used in a spot dividend model because the underlying stochastic differential equations are different.
> > > > best regards
> > > > Klaus
> > > > On Freitag, 26. Juni 2020 17:34:57 CEST Shenze Wang wrote:
> > > > Hi Klaus,
> > > >
> > > > Thanks a lot for you explanations.
> > > >
> > > > I made more calculations. It seems that the differences between Spot dividend model and Escrowed dividend model are not only for pathologic cases. And also a greater number of time steps and grid points do not help. The calculation results are attached. So I guess that there may be something goes wrong with Spot dividend model.
> > > >
> > > > The difference between the two dividend model also causes another bug in impliedVolatility. Because for American options, FdBlackScholesVanillaEngine with Spot dividend model is always being used, when calculating ivol. Here is the issue I opened, https://github.com/lballabio/QuantLib/issues/850.
> > > >
> > > > I think maybe it is necessary to take a closer look at the two dividend models.
> > > >
> > > >
> > > > Best,
> > > > Shenze
> > > > _______________________________________________
> > > > QuantLib-users mailing list
> > > > Qua...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/quantlib-users
> > >
> >
> >
> >
> >

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Klaus S. <kl...@sp...>]

Hi Shenze,

thanks for the example, it nicely highlights the importance of dividend modelling for equity option.

Within the spot dividend model the dividend of 10 is substracted from the equity process on the 31.12.2020. The option will be early exercised somewhere between today and the 30.12.2020 to earn the intrinsic value of 10, hence this model gives the expected result.

The escrowed dividend model substracts the net dividend payment from the start value of 100 and starts a geometric brownian motion at S(t=0) = S - D = 90. As the volatility is almost zero this process ends at 90 on maturity and the american option expires worthless. Both engine, the old FDDividendAmericanEngine and the FdBlackScholesVanillaEngine produce this result. The numerics is ok but the model is not appicable for this problem and delivers results, which look "a little wired" to say the least;-).

best 
Klaus

On Freitag, 26. Juni 2020 20:50:54 CEST Shenze Wang wrote:
> Hi Klaus,
> 
> I understand that different dividend models have different assumptions about the underlying process of the stock price. So, the pricing results will be different.
> 
> But could you please help me check the pricing results in the following screenshot? It is an American call option with extremely low volatility and a dividend right before the expiry date. S = 100 and K =90. I think the value of this option should be very close to 10, which matches the result of the Spot dividend model. However, the pricing result from Escrowed dividend model is 0, which looks a little wired.
> 
> Thanks a lot for your patience.
> 
> 
> 
> Best,
> Shenze
> 
> 
> On Jun 26, 2020, 1:32 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> > Hi
> > Spot dividend and escrowed dividend model are different models and are supposed to give different results for the same parameter set. An implied volatility calculated with the escrowed dividend model will not give the same price back when used in a spot dividend model because the underlying stochastic differential equations are different.
> > best regards
> > Klaus
> > On Freitag, 26. Juni 2020 17:34:57 CEST Shenze Wang wrote:
> > Hi Klaus,
> >
> > Thanks a lot for you explanations.
> >
> > I made more calculations. It seems that the differences between Spot dividend model and Escrowed dividend model are not only for pathologic cases. And also a greater number of time steps and grid points do not help. The calculation results are attached. So I guess that there may be something goes wrong with Spot dividend model.
> >
> > The difference between the two dividend model also causes another bug in impliedVolatility. Because for American options, FdBlackScholesVanillaEngine with Spot dividend model is always being used, when calculating ivol. Here is the issue I opened, https://github.com/lballabio/QuantLib/issues/850.
> >
> > I think maybe it is necessary to take a closer look at the two dividend models.
> >
> >
> > Best,
> > Shenze
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
> 

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Shenze W. <she...@da...>]

Hi Klaus,

I understand that different dividend models have different assumptions about the underlying process of the stock price. So, the pricing results will be different.

But could you please help me check the pricing results in the following screenshot? It is an American call option with extremely low volatility and a dividend right before the expiry date. S = 100 and K =90. I think the value of this option should be very close to 10, which matches the result of the Spot dividend model. However, the pricing result from Escrowed dividend model is 0, which looks a little wired.

Thanks a lot for your patience.



Best,
Shenze


On Jun 26, 2020, 1:32 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> Hi
> Spot dividend and escrowed dividend model are different models and are supposed to give different results for the same parameter set. An implied volatility calculated with the escrowed dividend model will not give the same price back when used in a spot dividend model because the underlying stochastic differential equations are different.
> best regards
> Klaus
> On Freitag, 26. Juni 2020 17:34:57 CEST Shenze Wang wrote:
> Hi Klaus,
>
> Thanks a lot for you explanations.
>
> I made more calculations. It seems that the differences between Spot dividend model and Escrowed dividend model are not only for pathologic cases. And also a greater number of time steps and grid points do not help. The calculation results are attached. So I guess that there may be something goes wrong with Spot dividend model.
>
> The difference between the two dividend model also causes another bug in impliedVolatility. Because for American options, FdBlackScholesVanillaEngine with Spot dividend model is always being used, when calculating ivol. Here is the issue I opened, https://github.com/lballabio/QuantLib/issues/850.
>
> I think maybe it is necessary to take a closer look at the two dividend models.
>
>
> Best,
> Shenze
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Klaus S. <kl...@sp...>]

Hi

Spot dividend and escrowed dividend model are different models and are supposed to give different results for the same parameter set. An implied volatility calculated with the escrowed dividend model will not give the same price back when used in a spot dividend model because the underlying stochastic differential equations are different. 

best regards
Klaus

On Freitag, 26. Juni 2020 17:34:57 CEST Shenze Wang wrote:


Hi Klaus,  


Thanks a lot for you explanations.


I made more calculations. It seems that the differences between Spot dividend model and Escrowed dividend model are not only for pathologic cases. And also a greater number of time steps and grid points do not help. The calculation results are attached. So I guess that there may be something goes wrong with Spot dividend model.


The difference between the two dividend model also causes another bug in impliedVolatility. Because for American options, FdBlackScholesVanillaEngine with Spot dividend model is always being used, when calculating ivol. Here is the issue I opened, https://github.com/lballabio/QuantLib/issues/850[1].


I think maybe it is necessary to take a closer look at the two dividend models.




Best,
Shenze


--------
[1] https://github.com/lballabio/QuantLib/issues/850

Re: [Quantlib-users] The reason of differences between `FDDividendAmericanEngine` of QuantLib 1.12 and `FdBlackScholesVanillaEngine` of QuantLib 1.18

[Shenze W. <she...@da...>]

Hi Klaus,

Thanks a lot for you explanations.

I made more calculations. It seems that the differences between Spot dividend model and Escrowed dividend model are not only for pathologic cases. And also a greater number of time steps and grid points do not help. The calculation results are attached. So I guess that there may be something goes wrong with Spot dividend model.

The difference between the two dividend model also causes another bug in impliedVolatility. Because for American options, FdBlackScholesVanillaEngine with Spot dividend model is always being used, when calculating ivol. Here is the issue I opened, https://github.com/lballabio/QuantLib/issues/850.

I think maybe it is necessary to take a closer look at the two dividend models.


Best,
Shenze
On Jun 25, 2020, 11:49 PM -0400, Klaus Spanderen <kl...@sp...>, wrote:
> please ignore my comment on "Observation 1 on Case 2", it is wrong,
>
> On Donnerstag, 25. Juni 2020 22:45:18 CEST Klaus Spanderen wrote:
> > Hi,
> >
> > thanks for sharing your results.
> >
> > W.r.t. your questions
> > 1. Douglas and Crank-Nicolson scheme are exactly the same for one-dimensional problems like the Black-Scholes equation. In higher dimensions operator splitting schemes like Douglas or Craig-Sneyd are better suited than Crank-Nicolson, hence there wasn't really a need to implement it (even though for the sake of completeness the Crank-Nicolson scheme has been added with the 1.18 release in C++).
> > 2. The spot dividend model is described e.q. in "Back to Basics: a new approach to the discrete dividend problem". People might argue that the spot dividend process is more realistic for path dependent options like barrier options or structured equity notes.
> > 3. As far as I know there is no general and meaningful algorithm for this problem, which is as easy as for Monte-Carlo.
> >
> > Observation 1 on Case 2. If I remember correctly then there was subtle difference between interest rate treatment for discrete dividents between the FDDividendAmericanEngine on the one side and AnalyticDividendEuropeanEngine,FdBlackScholesVanillaEngine on the other side.
> > Observation 2: For these pathologic cases the default number of S grid steps is too small. In general I'd use 500 or more S grid steps.
> >
> > best regards
> > Klaus
> >
> >
> >
> >
> > _______________________________________________
> > 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] Open Source Risk Engine (ORE) 1.8.5.0 released

[Roland L. <rol...@qu...>]

Dear all,

we have published the 5th release of ORE and ORE-SWIG this week, see  opensourcerisk.org <http://opensourcerisk.org/> and github.com/opensourcerisk <http://github.com/opensourcerisk>.

Changes include
Products: Added Inflation Caps/Floors, Forward Bonds, American Commodity Options, reference data support for Bond products
Markets: Extended currency, calendar and index coverage
Term structures: Basic ESTER/SOFR curve building, fitted Bond curve support, more robust CDS curve building, Equity volatility surface stripping from option premia, Equity forward curve stripping from option premia using put/call parity, enhanced Cap/Floor optionlet stripping, extended CDS volatility configuration, added Commodity basis price and average basis price curves
Tests: Extended range of unit tests across the three libraries
Build systems: Discontinued the automake build system maintenance, after introducing CMake in the 4th release
Python/Java language bindings: Migrated ORE SWIG to work with ORE 1.8.5.0 and QuantLib/QuantLib-SWIG 1.18
and various changes listed in the frelease notes (see News.txt or the user guide’s section 2 at https://www.opensourcerisk.org/documentation <https://www.opensourcerisk.org/documentation>) which have inflated the codebase by about 30%  since the last release.
If you have a chance, please clone the repositories, build and test – all feedback is welcome!

Best regards,
Roland