Add "grace" period to CalendarRollFinder and VolumeRollFinder

[bmpalatiello]

Currently the CalendarRollFinder rolls contracts based on x-days to auto-close(which I take to be expiration though it would be more helpful generally to use the first notice date). However, just to make an extreme example, if you set the roll to be 5-days to auto-close and today is 6-days to auto-close and your position(%) goes from 5% to -50% realistically you would want to sell 5% of the near contract and sell 50% worth of the far contract(as opposed to selling 55% of the near contract today and then having to roll that whole position the following day). So in this example we would need to specify the general x-days(5) to auto-close for a full roll(or whatever I have remaining in the near contract) and then specify a period of x-days prior to auto-close(must be greater than the full roll days, or x>5 in our example) where if a situation like above occurs we begin transacting in the next contract. I have a lot of these types of scenarios if interested further.

This same logic can be applied to the VolumeRollFinder. The general roll can be applied when the far contract breaches the liquidity of the near contract however lets take the scenario above. Since I believe it's currently volume based, if the position changes from 5% to -50% and the volume of the far contract is 95% of the near contract, you'd probably want to begin transacting in the far contract, or sell 5% of the near contract and sell 50% worth of the far contract.

Obviously there are a bunch of nuances and extensions associated with all of this(and with the great minds over there you've probably run through all these things, just thought I'd point these out in case!). Like a step beyond this for CalendarRollFinder would be if you are within the grace period and decide to begin transacting in the far contract, it still may not be that liquid yet, so the logic would become "if in_grace_period and far_is_liquid" then you can begin transacting in the far contract, if not, continue in nearby.

[jmccorriston]

@bmpalatiello are your comments directed at moving a position from one contract to the next in your portfolio?

The roll attribute of ContinuousFutures specifies the method for determining the current active contract of a particular continuous future. It does not define an automatic roll of a position from one contract to the next. Instead, an algorithm can move from one contract to another whenever it wants (assuming sufficient volume). This process must be handled manually.

Going forward, we would like to add more functionality around actually rolling from one contract to the next, but for now, it's a manual process. If I missed the mark your request, let me know.

[bmpalatiello]

You'll come across this as it matures. Rolling in general is tricky to automate, but I'm not even talking about explicitly "rolling" this is more concerned with automated execution or making the research environment as realistic as possible. Maybe I'm not completely understanding the current functionality, but to to the extent that futures trading plans to be automated this is something you will confront eventually.

[jmccorriston]

Agreed on the fact that rolling is tricky to automate. The thing to remember with what's available in research is that continuous futures are not tradable assets. They are a tool that can be used to maintain a continuous reference to an underlying asset. The roll functionality of a continuous future does not actually have any impact on your portfolio. Instead, the roll defines how the continuous future should define the current 'active' contract for the sake of historical lookback windows.

Of course, being able to define a custom roll logic even for historical lookback windows could be useful. We might want to add something like that in the future.

[bmpalatiello]

I know, they're just generic price indices. But the roll logic, while most of the time is miniscule, does have an impact on the returns. VIX futures are one example where roll logic can have a bigger effect. In real trading the scenario above does have a real economic impact in terms of costs. So, while maybe trivial when backtesting a strategy, when actually trading, the roll logic and having an appropriate "grace" period are aspects that need to be taken into account. So when someone submits a strategy to you and you trade it with your capital these are things that are important to automated trading that the "public" needs to be fully aware of, because whether big or small, they are things that impact a strategy.

[jmccorriston]

Ok, after speaking with one of our engineers, I think I have a much better understanding of what you're asking now. It sounds like you would like continuous futures in research to be a better indication of what an algo might look like that has a different roll logic than either of the builtins.

Right now, research is essentially a way to look at pricing data, while backtesting involves more execution and scheduling working on top of that. There's definitely a gap between research and backtesting and you're correct in that it can mean that you can't always get a perfect prediction from research.

Being able to set custom roll rules on continuous futures would help to reduce this gap. We'd like to add the option to set custom rules. It's not on the near term list but it is on the list of features to add.

Thanks for your request!

[jmccorriston]

By the way, I failed to respond to your assumption about the auto_close_date. It's set to 2 trading days prior to the earlier of the end_date or notice_date.

roughly:

min(`end_date`, `notice_date`) - 2 trading days