Continuous futures instrument

[thetradingflow]

Hello,

I've looked through the code and docs but haven't found anything related to continuous futures, so I'll start the discussion here. Sorry if it's not the right place!

Many futures traders rely on continuous futures instruments instead of the whole futures chain. Doing so greatly simplifies the simulation of strategies since rollovers are automatically handled, and historical prices are generally back-adjusted with the difference or ratio method so that they represent a continuous return/price stream. In general these continuous futures are built first, and then provided to the simulation engine which is ignorant about the rollovers (except for the costs).

Given nautilus_trader's architecture, I believe these instruments would need to be created on the fly as data events are received, ie they would resemble a strategy with its own roll rules and data recording methods (ie, adjusted historical prices). Then these instruments would be made available to the actual strategies that generate orders.

Is there any example of using continuous futures in nautilus_trader? Do you have any advice on how best to implement such an approach?

FYI I run a daily futures program at IB using my own infrastructure and am considering using nautilus to expand my operations to intraday trading. I'd be happy to help implement and check/report that my program produces the same results as nautilus if that's helpful to you.

Thank you!

[limx0]

Hey @thetradingflow - nothing like this exists currently, but I agree it would be nice to have something like this implemented in Nautilus from a usability perspective. For context, I come from an options trading background so quite familiar with your request.

I'll let @cjdsellers jump in here also, but my first thought is that should most likely be handled by some sort of component or Actor that can add this layer of abstraction for the user, without making too many low level changes; market data is received and orders sent in real futures, things that a trading strategy has to deal with.

Concretely; I would probably suggest creating an Actor (the base class of a Strategy), which can publish/subscribe to any instruments/data or custom data types

• Create a custom data type to publish to your strategy "ContinuousFuture(n=1)`
• Actor could subscribe to raw futures data and publish data for ContinuousFuture, handling rolling etc.
• Attach the current active instrument to ContinuousFuture, which your trading strategy could use to submit orders against / manage positions.

One of the largest benefits (and sometimes hurdles) of Nautilus is the backtest/live parity. The differences between live and backtest data are very thin, which might make this solution seem awkward at first, but it does mean it will translate effectively to live trading.

Hope this helps as an initial comment.

[rterbush]

Greetings, just stepped into the discussion here as I try to get my head around importing a large amount of futures tick data. My goal is to evaluate using Nautilus for my intraday futures trading platform, so I too will be very keen on figuring out how to build continuous futures data off of the imported and live data.

For purposes of requirements gathering, I'd like to offer that there are several ways to build continuous futures data and would hope that we can support all of the following methods.

• Backward/Forward (Panama)
• Proportional
• Rollover/Perpetual

Happy to help make this happen however I can.

[cjdsellers]

Hi @thetradingflow and @rterbush

Thanks for reaching out on this. This is definitely something we'd like to support, the only question is how.

I basically agree with @limx0's initial intuition on this, and would say there's two main parts to implement:

1. How to build and represent the continuous contract data stream
2. How to handle execution and rollover of the underlying products/contracts

In general these continuous futures are built first, and then provided to the simulation engine which is ignorant about the rollovers (except for the costs).

So this relates to 1, and indeed you could pre-process the data based on your own continuous contract rules, assigning a symbol like ES.0 or similar to represent say the front month contract. When this is added to the backtest engine, your strategy could subscribe to this data, then only execution needs to be handled (implemented in the strategy).

Expanding on this, we could also get the platform to construct this contract on the fly (so then live trading on the same logic would be possible), so as Brad suggests, implementing an Actor which holds some sort of ContinuousContract component. It would know how to subscribe to the necessary native underlying contract feeds (say all or some of the ES contracts), and aggregate these into a continuous contract based on whatever rules are programmed (TBD). It could then publish the data to the message bus, which other actors or strategies could subscribe to and act on.

So that would look something like:
[ DataClient ] <---> [ DataEngine] <--> [ Actor: Builds CC] --> ES.0 [ MessageBus ] --> [ Strategy ]

This leaves 2, the execution. We'd need an order management helper (function/component) which knows how to automatically roll positions into the next contract according to some rule (TBD), so that would look something like.
[ Actor Builds CC] -> [ MessageBus ] --> ES.0 [ Strategy ] --> ESH3 [ RiskEngine ] (for execution) -->

These are just some initial ideas.

So at this point I would ask, where are you at @thetradingflow and @rterbush with your understanding of the platform currently? and your capacity/bandwidth to help with an implementation?

[rterbush]

@cjdsellers I'm currently way down the curve on getting my head around NT. Just coming out of the year end fog to start working on this again.

One of my first tasks is to figure out how to import the historical data I have and then to figure out how to either use some of the other supported live data or find a way to get us an IQ feed DataClient.

Your vision as I understand it seems reasonable. It seems it would be nice to be able to use tick data and transform on the fly to whatever continuous methodology in order to avoid the data storage requirements for these larger tick datasets, but of course that would come at a cost of time spent when transforming and backtesting which your suggestion of pre-processing avoids.