Quantitative Finance Stack Exchange is a question and answer site for finance professionals and academics. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A simple and lazy approach to implementing an order and position management (OPM) component in a (semi-)automated trading system: leave most OPM to counter party (broker/exchange). Even then funds and positions need to be checked once orders are supposed to be dispatched. Else it is unkown whether one has funds or already the intended position in a symbol.

  1. Certainly such requests/responses do not fit ultra high frequency trading (uhft), or are optimistic approaches with respect to order execution used? If not, what is the uhft OPM [software] design approach?
  2. Is the lazy approach good enough for lower frequency trading? Or are other [software] design patterns favorable? Which and why?

Although the title What approaches are there to order handling in automated trading? is promising, answers were geared towards a specific difficulty. The references for developing an automated trading system do not discuss OPM in detail.

A refined OPM component should reflect almost all account details (funds, transmitted orders, fills) reliably. I believe software design patterns of banking/exchange platforms should apply. References for reliable messaging/databases accessible to the non-expert developer would be nice.

share|improve this question
up vote 4 down vote accepted

Regardless of frequency, every firm should track its own fills to ensure that the exchange's drop copy is accurate. Now it is true that the positions can be stored in a simple database for later retrieval if real-time execution isn't a goal. But it is extremely dangerous (and fiduciary irresponsible) to just "take the counter-party's word for it".

share|improve this answer
Simple database: save sent orders, save broker/exchange response, i.e. logging. Positions are deduced from responses. History and currently active orders/positions should be separated (flag as active). Maybe I overcomplicated by thinking about design patterns. – Konsta Oct 17 '12 at 22:14

1) The uhf/hf approach is to run dedicated order management modules, position managers, and risk checks in dedicated processes in-house and NEVER rely for any of this on outside applications. For uhf some or all of those processes may run on hardware chips, but most on the hf side and lower frequency side runs within software modules that are dedicated to only manage orders, only manage risk, only manage positions.

2) No, its not enough. Example: You submit an order, you get the acknowledgement of the receipt of the order and then your app or connection to the broker goes down. Fact is that you have submitted an order and fact is that your broker received the order and confirmed it. You must account for that submitted order yourself before your app reconnects or before you get any fill confirmation at a later point. Just one of the many tons of issues that may go wrong or occur and which may be completely outside of your control. Even if everything goes as planned its standard practice to run your own OMS and other components and to frequently sync it with what your execution partners show. If there is a misalignment then something is wrong and thats exactly what you want, the knowledge of something being wrong. Or would you like to continuously shoot orders into the market and get filled in size that you never anticipated just because your broker does not send you fills for whatever reason?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.