Major implementation change for ibor_swap? A notebook example doesn't tie out anymore. about financepy HOT 12 CLOSED

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

from financepy.

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.

from financepy.

from financepy.

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

from financepy.

Apparently the float_leg issue was introduced in commit 2d43d10.

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

from financepy.

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 ?

from financepy.

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.

from financepy.

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

from financepy.

OK. Thanks.

from financepy.

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

from financepy.

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.

from financepy.

from financepy.