Curious if anyone is using this in production yet?

[kszlim]

Just curious if anyone is using this in production yet, the project looks really promising to me!

Also have a list of questions:

• Is there going to be a way to perform portfolio optimization?
• How does this system handle trading multiple strategies together (can you aggregate the trading outputs of multiple strategies into a single trade output if they trade within the same time bucket)?
• What's the expected timeframe for ibkr integration?
• What's the risk management story look like? How would you plug a risk module into a strategy (i looked at an example, and didn't see how to implement risk management)
• How does it handle multi-venue, multi-account stuff?

Thanks!

[cjdsellers]

Hi @kszlim thanks for your interest!

To answer each one:

Is there going to be a way to perform portfolio optimization?

There is a Portfolio component which aggregates some basic information such as the following (from the C typed class definition):

    """If the portfolio is initialized.\n\n:returns: `bool`"""

    cpdef Account account(self, Venue venue)

    cpdef dict balances_locked(self, Venue venue)
    cpdef dict margins_init(self, Venue venue)
    cpdef dict margins_maint(self, Venue venue)
    cpdef dict unrealized_pnls(self, Venue venue)
    cpdef dict net_exposures(self, Venue venue)

    cpdef Money unrealized_pnl(self, InstrumentId instrument_id)
    cpdef Money net_exposure(self, InstrumentId instrument_id)
    cpdef object net_position(self, InstrumentId instrument_id)

    cpdef bint is_net_long(self, InstrumentId instrument_id) except *
    cpdef bint is_net_short(self, InstrumentId instrument_id) except *
    cpdef bint is_flat(self, InstrumentId instrument_id) except *
    cpdef bint is_completely_flat(self) except *

We consider any kind of specific strategy alpha / portfolio optimization as being implementation specific to a user, so its absolutely possible to implement some portfolio optimization logic with this platform, which could actually be achieved in various ways. However its not currently included 'out of the box'.

How does this system handle trading multiple strategies together (can you aggregate the trading outputs of multiple strategies into a single trade output if they trade within the same time bucket)?

Absolutely, the platform is extremely flexible. Instead of submitting orders directly, a strategy could simply publish output of any kind onto a central message bus, which other strategies (or actors, see Actor) could subscribe to. So using a PUB/SUB messaging pattern in this was, you could aggregate many signals at a single 'subscriber' (strategy), and then take further action such as portfolio rebalancing, sending trading commands to submit, modify, cancel orders etc. Indeed the platform from the outset was designed with this sort of flexibility in mind.

What's the expected timeframe for ibkr integration?

As you can see from the issues, it's coming up on the roadmap, we are currently discussing the plan for how we'll be approaching it. Expect some work to begin within the next few weeks to early Jan, however nothing is concrete yet.

What's the risk management story look like? How would you plug a risk module into a strategy (i looked at an example, and didn't see how to implement risk management)

So there is a central RiskEngine which all orders will pass through, and all events also pass through. In this way configurable pre-trade risk checks can achieve a certain level of risk control, however there is much more potential to build up the current functionality further. There is also an extremely performant throttler being used as an order rate limiter as part of this component.

How does it handle multi-venue, multi-account stuff?

Multi-venue is handled through simply adding more data and venues (SimulatedExchange) for backtests, or configuring available adapters for specific trading venues or data providers for live trading with a TradingNode. So multi-venue support was also part of the design from the beginning.

Support for multi-account/sub-accounts is on the near term roadmap and there are plenty of hooks to allow this, however the current assumption is one account per connected venue.

Hope this helps to make things a little clearer! I should say that improving the documentation situation is a priority for me, however I still need to take further action to start building this up.

[kszlim]

Thanks, that sounds great!

Lastly, you didn't answer my main question, do you know of anyone using this in production yet? Thanks for all your work!

[limx0]

@kszlim, I'm a contributor & have been using nautilus in production for sports betting (I wrote the bulk of the Betfair adapter). I run multi-strategy nautilus instance and everything works really well. There's some more functionality I would like to add to the portfolio component, allowing more event/message types around risk management / strategy trade sizing but I think alot of this is very trader specific (although we could make some of these things easier to implement). These things are super easy to prototype with the Actor class - and we could potentially promote them to core nautilus components where it makes sense.

When you speak about risk management - are you referring to more "post trade" risk management (Stop losses / drawdowns)?

Things you would want to improve on if you wanted to run a production setup for crypto / financial markets:

• The account recon needs some love - this doesn't affect me so much in sports betting as the "instruments" expiry daily and I don't often need to recon my positions after a restart / upgrade.

Happy to answer any other questions you have also.

[kszlim]

Thanks! I'm thinking more like stuff like cvar, var, portfolio stop (vs strategy/instrument level stops), margin analysis, etc...

I'm not really expecting for this stuff to be built in, but just wondering whether the framework was designed with plugging in risk modules in mind.

Would also be curious to see an example of how this model handles ML as part of the framework, maybe a daily trained model or something.

[cjdsellers]

Something to bear in mind is that strategies should have no dependence or interaction with each other unless you're specifically publishing strategy data onto the message bus and reading that from another strategy.

So adding a strategy should not turn a 1-minute bar strategy into a 2-minute bar strategy, or block another strategy in any way.

I would need to know more information to be able to help with your setup.

[graceyangfan]

@cjdsellers yes,the strategies will not interaction with each other.In fact these do not always loop one by one,some times them process at the same time,I will do more test to see why sometime it seems that there is a delay on processing bars.

[cjdsellers]

Potentially if you receive a bar and something within your strategy logic blocks the event loop then that could explain the behaviour

[graceyangfan]

Potentially if you receive a bar and something within your strategy logic blocks the event loop then that could explain the behaviour

Ok,the strategy works well,some times it behave like a two minute bar level is because some order is delayed by the risk engine for Duplicate ClientOrderId,The program generated ClientOrderId is too simple,it cannot distinguish different order from two category,I suggest to add stratgy_id in it

[cjdsellers]

Sounds like some good progress has been made. This should actually be handled with the order_id_tag for the strategy config, I think this needs to be improved though as its too easy to make the mistake of identical tags and there's no protection against this yet. I'll add something for this today.