Major implementation change for ibor_swap? A notebook example doesn't tie out anymore.

[YimingZhang07]

Hello,

I looked at the ibor_swap implementation. And noticed an example in FINIBORSWAP_ComparisonWithQLExample.ipynb, which I believe was trying to convince the results tie to the Quant Lib implementation.

This notebook ran with version 0.184, and the results matched perfectly. However, with the latest version, the difference enlarged significantly.

The fixed leg has no problem. The floating leg was 2292441.20, but now it turns to be 2318923.97 mainly due to the change in rate calculations on index curve. The change seems nontrivial.

I am not sure if this notebook should be updated, and most importantly, we could not tie anymore, so either one must have a problem.

BTW, the print_valuation function in swap_float_leg instrument will call print_payments as well, creating visual verbose including duplicate tables and info, maybe this could be improved this as well. (this is also a new problem in latest version).

Thanks,

[domokane]

Thanks. I will look into this. I have not had time to push the most recent changes. Maybe this weekend.

[nashquant]

Hi Professor, I've probably introduced the changes related to the swap legs, so happy to pick up this review this weekend if you are ok with it.

[domokane]

OK. That would be good thanks.

------ Original Message ------ From "Matheus Pires" @.> To "domokane/FinancePy" @.> Cc "domokane" @.>; "Comment" @.> Date 07/07/2023 17:39:21 Subject Re: [domokane/FinancePy] Major implementation change for ibor_swap? A notebook example doesn't tie out anymore. (Issue #188)

Hi Professor, I've probably introduced the changes related to the swap legs, so happy to pick up this review this weekend if you are ok with it.

— Reply to this email directly, view it on GitHub https://github.com/domokane/FinancePy/issues/188#issuecomment-1625597177, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ73PLRXZTSWVCJSCNUJUTXPAUSTANCNFSM6AAAAAA2A7LDYA. You are receiving this because you commented.Message ID: @.***>

[nashquant]

Alright, I started looking into this.

1) Formatting: Indeed the choice I made to include print_payments within print_valuation wasn't good, what if I refactored the valuation table schema like the image below + remove print_payments from it? I.e. Upside: Quite concise table, with all relevant info / Downside: User would need to print_payments to check Start/End Accrual valuation dates, otherwise the table would be too long to display. Let me know if you have a better idea!

2) Values not matching: I suspect that this isn't related to my change, but of course gonna keep debugging this. Looking at the notebook @ version 0.184, noticed the column "Rate/IBOR" used to derive the cashflows are quite different (e.g. comparing the two images, for 1st payment, it is 2.005 in one,and 1.97758 in the other, which explains the final difference). Nevertheless, the logic to derive the rates shown wasn't changed in my PR, @domokane are you aware of any change that might be related to this?

I'll take a look again later

Cheers, Matheus

[nashquant]

Apparently the float_leg issue was introduced in commit 2d43d10780dcb9afbcefee805c2660c26da08ab9.

If you look at the changes in swap_float_leg.py, you'll notice fwd_rate calculation changed to use index_alpha instead of pay_alpha, which explains the IBOR Rate change I highlighted above.

Professor, do you recall why this was necessary?

PS: For the 1st payment in the example above, we have: Pay_alpha == 0.2555555 Index_alpha == 0.2520547

Which is explained by Index being in Act_365F day count, whereas Pay_alpha is ACT_360 - the two account for 92 days of accrual.

Thanks

[domokane]

Hi - I believe I did this as it seemed appropriate to separate the choice of accrual method for the index from the choice of accrual method for the payment leg. Perhaps I have mispecified the index accrual method in the example - it should be the same as the payment method ? Would that fix the problem ?

[nashquant]

Hi @domokane, thanks for your reply.

• I don't think you mispecified the index accrual method. The example setup is in accordance to the one for QL: http://gouthamanbalaraman.com/blog/interest-rate-swap-quantlib-python.html (Libor is in Act/365F, whereas swap is in Act/360)
• It is possible that the new/current result for float_leg is right - although I haven't given too much though on that yet, I think your change is appropriate.

[nashquant]

After giving it some thought, I'm quite confident that the updated value for the float leg is the right one - the changes you've made look good to me. Besides that, considering that we're setting Libor rate at a flat 2%, the figures above tell us that in version 0.184 (which matches the results in the blog), the Libor rate was off a bit, coming in at 1.97%.

[domokane]

OK. Thanks.

[nashquant]

Thank you, when I find sometime I'll create a PR for the formatting fix.

[YimingZhang07]

Thanks for looking at this. If we confirm the current methodology is right, I strongly recommend refreshing the related notebooks too see the impacts if possible. As I see, the valuation difference can be as large as 15-20% for example in FINIBORSWAP_DefiningAFixedFloatingSwap.ipynb. What's more, since swap is fundamental in building curves, e.g. in CDS valuation, I wonder if our results could still tie with Markit.

I am willing to help on this as well, but in coming weeks.

[domokane]

That's fine. I will look at it too. I have some deadlines but in a week or two I should have time.

------ Original Message ------ From "YimingZhang07" @.> To "domokane/FinancePy" @.> Cc "domokane" @.>; "State change" @.> Date 10/07/2023 16:02:32 Subject Re: [domokane/FinancePy] Major implementation change for ibor_swap? A notebook example doesn't tie out anymore. (Issue #188)

Thanks for looking at this. If we confirm the current methodology is right, I strongly recommend refreshing the related notebooks too see the impacts if possible. As I see, the valuation difference can be as large as 15-20% for example in FINIBORSWAP_DefiningAFixedFloatingSwap.ipynb. What's more, since swap is fundamental in building curves, e.g. in CDS valuation, I wonder if our results could still tie with Markit.

I am willing to help on this as well, but in coming weeks.

— Reply to this email directly, view it on GitHub https://github.com/domokane/FinancePy/issues/188#issuecomment-1629032331, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ73PK2GSLORQFIZMTD64DXPQDPRANCNFSM6AAAAAA2A7LDYA. You are receiving this because you modified the open/close state.Message ID: @.***>