Order Management with Unique IDs, Limits, and Target Positions
Summary
The discussion addresses how an automated strategy can manage repeated order signals, including cases where execution algorithms generate many child orders. It recommends assigning each requested order a unique identifier and storing its parameters against that identifier, so users or the order manager can refer to individual orders. A per-symbol trade-volume limit, potentially combined with a position limit, can reject excess requests and help contain unintended activity.
Other responses describe separating strategy intent from execution: strategy logic can update a desired holding, while a distinct execution component sends orders to reach it and maintains positions from execution reports. Event-driven order updates are presented as a practical way to manage real-time state; a semaphore or timer can suppress repeated submissions while an order is pending. The answers offer architectural suggestions, not comparative performance evidence. They do not detail reconciliation, partial fills, persistence, or the precise semantics of cancellation, so those design choices remain open.
Key ideas
- Give each order a unique identifier and store its requested parameters for later management.
- Per-symbol volume limits and position limits can block excessive order requests.
- Separate desired holdings in strategy logic from the execution process that works toward them.
- Use order and execution events to update order state and positions.
- Serialize order-related state by symbol when concurrent threads could otherwise conflict.
Tags
Full text
# What approaches are there to order handling in automated trading?
# What approaches are there to order handling in automated trading?
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:
```
if(some_condition)
EnterLong("IBM",100)
```
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?
## Answer by chrisaycock (score 11, accepted)
https://quant.stackexchange.com/a/495
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).
> ... both NT and MT have events (OnOrderUpdate, OnExecution, OnTrade) that are fired when the status of an order is changed.
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.
## Answer by glyphard (score 4)
https://quant.stackexchange.com/a/494
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.)
## Answer by user40 (score 3)
https://quant.stackexchange.com/a/498
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
## Answer by B Seven (score 3)
https://quant.stackexchange.com/a/1978
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.Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.