Algorithmic and Mechanical Forex Strategies | OneStepRemoved

NinjaTrader Order Methods

by Leave a Comment

Ninjascript, the C# API used for programming strategies in NinjaTrader, attempts to stirke a balance between making the strategy development process as simple as possible while preserving flexibility in the types of strategies that it can support.  It handles these competing requirements by splitting strategies into two types of order methods. Many programmers within the NinjaTrader community also refer to these types as approaches.

Managed approach

The first and most common order method is a managed approach. The managed approach is also the default assumption that NinjaTrader assumes you’re using when writing a strategy.

I backtest strategies this way 90%+ of the time. It’s way easier to write them using a managed approach once all of the variables and properties are set up. NinjaScript makes available a number of methods that all inter-relate. The names and functionality of each is obvious. EnterLong(), for example, enters a long trade.

All of these methods have premapped relationships between each other. When the strategy calls ExitLong(), NinjaTrader takes care of the details such as knowing which long it needs to exit. That seems obvious enough, but many trading applications do not connect the dots so easily between trading functionality. MetaTrader 4 & 5 are good examples of this type of simple functionality not being available.

The ease with which trading decisions are handled makes it ideal for developing quick and dirty code to test simple ideas.  Most of my strategy ideas follow the KISS principle; keep it simple, stupid. It’s usually a very simple development process (10-20 minutes) to program and test a trading idea from the moment it enters my mind. Most ideas don’t work out, but at least I get the satisfaction of knowing the answer quickly.

I discovered the hard way that the managed approach makes assumptions about order handling. EnterLongLimit(), for example, automatically deletes a pending limit order after one bar. I remember spending several hours with a live strategy trying to figure out why so many of my orders entered correctly on tick charts, only to have them disappear on the next tick. Carefully poring over the documentation led me to discover an overloaded method with the liveUntilCandelled parameter.

It’s examples like this pre-programmed functionality that you need to watch out for. This is especially true if you have a bug that doesn’t make sense in the context of your strategy.

Unmanaged approach

An unmanaged approach takes away all of the assumptions that NinjaTrader makes while a strategy runs in real time. This option leaves it up to the coder to store the position status in memory and make appropriate decisions.

Every strategy that we’ve written with unmanaged orders uses pending stop and limit orders. A recent example involves a market making strategy at Interactive Brokers. The strategy is 100% in the market during the US and Asian sessions. We originally started with a managed approach but ran into problems with the commissions and overfills.

The strategy is only trading 2 mini lots during the testing phase, which is the minimum trade size. Although the standard commission of 0.2 pips per side is quite low, the minimum commission is $2.50. That’s relatively high for such a small position size. I noticed on the first day that my client was getting charged commissions for the entry leg and exit leg, respectively.

The first trade entered with 20k. When it came time to exit, the managed approach set an exit limit for 20k and a separate entry limit for another 20k. IB charged commissions twice for both orders, which cost $5 per round turn trade. The trading report looked like:

BOT 20k $2.50

SLD 20k $2.50

SLD 20k $2.50

BOT 20k $2.5o

BOT 20k $2.50

SLD 20k $2.50

BOT 20k $2.50

SLD 20k $2.50

That’s effectively 4 trades at a cost of $20.

Grouping the trades into a single order more or less cut the commissions in half. I found it easier to do with an unmanaged approach because I didn’t have to worry about how the Entry() and Exit() methods would interact. The trade report changed to:

BOT 20k $2.50

SLD 40k $2.50

BOT 40k $2.50

SLD 40k $2.50

BOT 20k $2.50

The same sequence grouped together drops the cost of the 4 trades down to $12.50.  The initial entry and the final exit cost $2.50, but the trades in between only pay $2.50 for the entry and exit combined. When the order size increases to standard lots, the commission savings will dramatically improve the client return.

The other reason that we switched to an unmanaged approach was that NinjaTrader kills a strategy whenever an overfill occurs. An overfill is when a strategy requests cancellation of a pending order, but that pending order gets filled before the cancel request arrives. It then exits the new position at market and turns off the strategy.

I found this nearly intolerable with a market making strategy because an overfill would almost certainly occur at least once daily. Unmanaged orders have the option of disabling an overfill and handling it in whatever manner the trader deems appropriate.  In my case, it was to simply increase the amount of position that the strategy was trying to exit.

The main disadvantage to unmanaged orders is that everything is tracked internally. If you need to disable a strategy to change the settings or lose the broker connection, the code is probably not going to interact very well with positions that are already open.  Whatever IOrder objects were stored in the memory, which is how the strategy knows what positions are open, disappear whenever the strategy is removed from a chart.

Unmanaged strategies also take a lot more time to test. The amount of code involved does not differ dramatically from managed orders. It’s larger, but not grotesquely so. The reason that it takes more time is that the interaction between the order types is not polished like it is in managed orders. The programmer must write everything from scratch, which invariably means that the strategy will suffer from many more initial bugs, especially in a live environment.

Strategies that rely on market orders do not need to consider this approach in my opinion. It causes a lot more work and I have yet to encounter a situation where it makes sense. More importantly, I can’t think of a hypothetical situation where it would make sense either.

High Frequency NinjaTrader Strategy

by 7 Comments

I’ve been working on a high frequency trading system for NinjaTrader on behalf of a long term client. My live account is with MB Trading. Rather than placing market orders and paying a commission, I changed the order types to limit orders. We want to receive a small commission for the market making strategy rather than paying a commission to accept the displayed prices.

MetaTrader suffers two major disadvantages that make NinjaTrader a superior option for high-frequency trading. MT4 does not offer charts lower than the M1 time frame and the trade context is busy error prevents multiple charts from running simultaneously. NinjaTrader is complex enough to where I can control most details, but simple enough that I don’t need to invest hundreds of hours to test an idea. After extensively testing the strategy on M1 charts as a price taker, I feel very confident that the strategy is sound. The only issue now is determining whether or not whether taking a passive (i.e., market making) approach will result in enough fills to make the strategy worthwhile.

The first issue that I came across wasn’t with NinjaTrader; it was with MB Trading’s API. The strategy worked fine on the simulation account, which only routes orders to NinjaTrader (NT). NT then makes guesses when fills would occur. The goal of that phase was not to test the strategy. I only wanted to test the programming to make sure that it worked properly.

100 trades went off without a hitch in the Sim account. The strategy only made it through 2-3 microlot trades on the live account before the pending orders hung. NinjaTrader pending orders pass through 3 states before they actually hit the market. For the programmers out there, these are the OrderState properties of IOrder objects.

  1. Pending submit – the strategy sent the order to the broker and is waiting to hear back
  2. Accepted – the broker acknowledges receipt of the order, but is still placing the order into the market
  3. Working – the order is available for others to trade

The strategy updated orders on every tick. What often happened was that the pace would go far too quickly, creating a major communications backlog during fast markets. NinjaTrader never threw an exception. The only evidence of a problem was that I would see a hanging order with the PendingChange property. The inconvenient solution was to exit NinjaTrader and reload everything.

I figured that perhaps that the managed order state caused the issue. I changed my approach to unmanaged orders, but that did not make a difference. I eventually came to the realization that the MB Trading API cannot handle more than one order every few seconds.

The strategy found the sweet spot after changing from tick to second charts. Updates of 6 seconds or longer seem to give the MB Trading API enough time to update wihle still preserving something of a high frequency approach. Any trades that need to run faster than that threshold at MB Trading need to use the FIX protocol.

The other element that drove me crazy is that NinjaTrader limit orders automatically delete themselves once per bar. I nearly tore my hair out, and I don’t have all that much hair, for several hours trying to figure out why orders deleted themselves automatically. Many people identify with the school of hard knocks approach to learning. I’m as thick headed as most. I figured out the cause when I revisitied NinjaTrader’s online documentation and discovered a limit entry method that allows good till cancelled (GTC) orders.

The speed problem also manifested with overfills. An overfill is when a strategy requests to cancel a pending order, but the broker fills the order before the cancellation takes effect. The biggest concern with overfills is that NinjaTrader automatically disables a strategy and exits positions at market when an overfill occurs. The only way to programmatically prevent this is to change the entry methods to an unmanaged approach.

The easiest way to develop for a high frequency strategy in NinjaTrader (but not ultra-high frequency) is to use managed orders. Whenever an exit is needed, place the limit entry in the opposite direction. NinjaTrader takes care of placing the exit order for the open market positoin. Limit the updates to every handful of seconds. It allows the broker API to catch up and helps avoid the problem of overfills.