You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We tried the objectlabkit library and we advised an inconsistency regarding how to manage “xM” tenors. Our conclusion is that it is necessary to add a rule about 'xM' tenors in the mentioned library.
The reason behind this is that, in order to deal with “xM” tenors properly, the new rule added should take into account that if the spot date is the last working day of the month, the next 'xM' tenors should be the last working days for each months.
Hi All.
We tried the objectlabkit library and we advised an inconsistency regarding how to manage “xM” tenors. Our conclusion is that it is necessary to add a rule about 'xM' tenors in the mentioned library.
The reason behind this is that, in order to deal with “xM” tenors properly, the new rule added should take into account that if the spot date is the last working day of the month, the next 'xM' tenors should be the last working days for each months.
For example.
Pair: EUR.USD
Trade date: 2016-04-27
Spot date : 2016-04-29
1M : 2016-05-31
2M : 2016-06-30
3M : 2016-07-29
4M : 2016-08-31
....
Library return:
Pair: EUR.USD
Trade date: 2016-04-27
Spot date : 2016-04-29
1M : 2016-05-31
2M : 2016-06-29
3M : 2016-07-29
On the other hand, we think that another rule needs to be added in any case:
'xM' should be (x+spotMonth). In other words, it is mandatory to have at least a 'xM' tenor for each month.
For example:
Trade date: 2017-01-26
Spot date: 2017-01-30
1M: 2017-02-28
2M: 2017-03-30
3M: 2017-03-28
4M: 2017-05-30
....
Regards
The text was updated successfully, but these errors were encountered: