Take the 2-minute tour ×

I am currently developing a commercial automated trading program in which users can write their own proprietary code and develop strategies, like in NinjaTrader, MetaTrader etc. Right now I am working on the order handling part, which is really important. I can not figure out how to reference the orders entered during the execution of a strategy.

Suppose in a strategy, there is this piece of code:


My problem is some_condition can be set to true several times, which results in generating several buy orders. Somehow I have to provide the ability for users to modify or cancel some of these orders.

NinjaTrader, for example, has a feature called EntriesPerDirection, which limits the entry number for a direction (long or short). So you can have a certain number of order objects (or an array of orders) that are returned by order entry functions and say order1.Cancel(); However, this does not make any sense for an iceberging strategy in which thousands of orders could be generated. Both programs enable the user to iterate over the orders that have not led to a transaction yet. This again could be painful for iceberging purposes. I think those two programs are not specifically built for handling large numbers of orders or for developing execution algorithms (e.g., VWAP, Arrival Price, Implementation Shortfall) which are widely used among buy-side firms.

Also both NT and MT have events (OnOrderUpdate, OnExecution, OnTrade) that are fired when the status of an order is changed. This is a good idea, but I am not sure it is the best solution.

Are there any approaches or methodologies addressing my problem that are commonly used by other automated trading software?

share|improve this question
add comment

4 Answers

up vote 11 down vote accepted

Regarding your order management issue, every order should have a unique identifier that the user can reference; in FIX, this is the ClOrdID. The parameters of every order the user requests should be stored in a table keyed by this identifier.

If your goal is to prevent duplicate orders from going out, consider having a trade volume limit per each symbol. That way, subsequent order requests will be rejected by your order manager even if the condition has passed. A trade volume limit is also desirable to prevent moving the market (especially when coupled with a position limit) and can act as a safety mechanism if things get out of hand (we call this the blowout preventer at my current firm).


Event-driven programming makes real-time trading much more manageable. This paradigm is known as "complex event processing" and is quite common in institutional trading.

I think those two programs are not spesifically built for handling large number of orders ...

That's because they were designed for day traders who want to pretend they're quants. No institutional trader would ever use those software packages.

share|improve this answer
@chrisaycock: Let's say the user is executing a VWAP strategy. In the last minute of a 30 minutes period, if the strategy falls behind its target volume, the user may want to rush things and adjust some of the early partially filled orders allowing them filled at current merket price by proper writing code. Iterating over the all orders entered in that strategy is the only thing comes to my mind. How do the trading institutions handle these type of situations at runtime? Or do they provide a UI that user can play with the orders manually? –  ali_bahoo Feb 17 '11 at 13:10
@sad_man Both options are available: automated and manual override. Any algo you create, whether market making or stat arb or VWAP or whatever should be able to handle "disruptions" like halted trading, lost connections to the ticker plant, etc. But there should also be an interface for a human operator to suspend trading, liquidate positions, etc. (Example: if my strategies lose the data feed connection, they cancel open orders, leave filled orders untouched, and then page the main people in the company via SMS so we can look at the situation manually.) –  chrisaycock Feb 17 '11 at 14:38
@chrisaycock: I see. So spesifically for my scenario described above, what would you expect from a trading platform besides a UI to enable you to change some of a large number of orders selectively? –  ali_bahoo Feb 17 '11 at 15:43
@sad_man What do you mean? The GUI is the primary point for manually overriding the parameters, etc. –  chrisaycock Feb 17 '11 at 16:35
@chrisaycock: I mean rather programatically, not manually. –  ali_bahoo Feb 17 '11 at 16:59
show 1 more comment

What I've done in the past is create an OnOrderSubmit event/method that fires when an order is placed. Use set a semaphore in that method so that your tick/analytical method ignores order placement instructions until an execution occurs or a timer expires. Then flip the semaphore.

(If you're using multiple threads you want to make sure to serialize access to each thread by symbol.)

share|improve this answer
add comment

Instead of sending orders each time condition is met, try to set "wanted holding" in the trade logic thread. Trade execution will then make sure (issue sufficient number of orders) to achieve your wanted holding.... For example, the first time signal happens, you sent wanted holding to 100 shares the next time it happens you only confirm that you want 100 shares - you do not send the order!

Some other class/thread is looking after actual order management... Not trading logic

share|improve this answer
add comment

You need to track your current position for each stock in the software. You need a process to find out when an order is executed, and update your position for the appropriate stock. This process is separate from sending orders to the market.

share|improve this answer
Hi B Seven, welcome to quant.SE and thanks for contributing your answer! –  Tal Fishman Sep 22 '11 at 14:08
Hi Tal, I think it is wonderful to be able to participate in Quant SE. It is wonderful to collaborate on such a challenging and interesting topic. –  B Seven Sep 22 '11 at 17:08
add comment

Your Answer


