My own ATS: which subsystem to generate closing order?

V

vincegata

Hello,

I am developing my own ATS which is about 80% done, however, in the current setup for each entry order my Strategies Execution System also (immediately) generates closing Stop Limit and take profit orders. If I do not want such scenario then which system should generate closing orders? at the present Strategies Execution System is not aware of open orders and Order Management System does not get the quotes data.

If you have experience with ATS what is the way to implement order closing?

Here is the scheme, each system is in it's own executable, they communicate through messaging.

Broker's Quotes Server -> (quotes) -> [ Quotes Connector -> (quotes) -> Strategies Execution System -> (order signals) -> Order Management System <-> (order signals) <-> Order Routing System (FIX Engine) ] <-> (order in FIX format) <-> Broker's FIX Server

Thank you in advance.
 
If you are using fixed targets/stops which don't change (or change in a simple fashion such as a percentage trailing stop), then the order management task seems like the most logical alternative.

However if you update your orders by some sort of logic (or even think you might in the future), then I would keep them in the Strategy area.

IMHO, keeping things isolated makes the code cleaner and easier to maintain:
Strategy has anything to do with order generation (even if it's simple like brackets) and Order Management has anything to do with order transmission (including code to work fills, etc).

My $0.02.
 
Quote from southall:

I think you need to describe the new requirements for the closing order functionality a bit more..
More...

What I have now:
Place market order long on BAC + place stop order at market price -$0.50 + place limit order sell at market price+$1. This is all generated by Strategy Execution System now.

What I want is to have a logic in order closing. Hypothetical strategy:
Place market order long on BAC.
Place market sell order when price drops by 5% from 3 hour SMA.
Place market sell order when price rises by 10% and volume drops by 20%.
 
Quote from TheGoonior:

However if you update your orders by some sort of logic (or even think you might in the future), then I would keep them in the Strategy area.
More...

That's what I am trying to have - a logic to close my orders. If to combine SES and OMS into a single code (I had that before redesigning my code) it gets very messy because both SES and OMS are multithreaded.

So SES has to be aware of all open orders so when a new quote arrives, say for BAC, it should check if I have any open orders for BAC and what strategy opened that order and then run the strategy to check if I have to generate Close Order signal. -- Something like that I guess, but like I said, combining SES and OMS is very very messy.

Are there any other ideas?

I have to add I am using C++/Linux.
 
Quote from vincegata:

That's what I am trying to have - a logic to close my orders. If to combine SES and OMS into a single code (I had that before redesigning my code) it gets very messy because both SES and OMS are multithreaded.

So SES has to be aware of all open orders so when a new quote arrives, say for BAC, it should check if I have any open orders for BAC and what strategy opened that order and then run the strategy to check if I have to generate Close Order signal. -- Something like that I guess, but like I said, combining SES and OMS is very very messy.

Are there any other ideas?

I have to add I am using C++/Linux.
More...

What you have here sounds like an application design problem more than anything else, which can be solved by using the object-oriented Strategy design pattern which is easily implementable in C++. Perhaps coupled with the State pattern, ie store the relevant State variables (current price, position price, MA, etc) for each quote and pass the State object as a parameter to the Strategy subclass function to see if any order open/close/modify actions should be taken (different Strategy subclasses will make different decisions at this point). With design patterns your system components will be clean and well-encapsulated.
 
Quote from dazzwater:

What you have here sounds like an application design problem more than anything else, which can be solved by using the object-oriented Strategy design pattern which is easily implementable in C++. Perhaps coupled with the State pattern, ie store the relevant State variables (current price, position price, MA, etc) for each quote and pass the State object as a parameter to the Strategy subclass function to see if any order open/close/modify actions should be taken (different Strategy subclasses will make different decisions at this point). With design patterns your system components will be clean and well-encapsulated.
More...

Design pattern is not going to help here because Strategy Execution and Order Management reside in separate executables.
 
Quote from vincegata:

Design pattern is not going to help here because Strategy Execution and Order Management reside in separate executables.
More...

It still can. Like I said it's best for your sub-components to be well-encapsulated, ie separated and hidden from each other. You've already done that by placing them in separate executables. All you need to do now is redesign the interfaces between QC->SES and SES->OMS so your executables communicate the way I described earlier. I'm assuming you're using price data files for QC->SES and messages for SES->OMS but the type of interface is irrelevant here.
 
Forewarning: I am no rocket scientist here...but, having one process that manages your strategies using "Feed Data Set A" and having your order execution use "Feed Data Set B" can lead to REALLY BAD things. I was a feed systems admin for over 10 years....our OE used the same data as the quote servers...if that makes sense to you...

-G
 
Quote from gastropod:

Forewarning: I am no rocket scientist here...but, having one process that manages your strategies using "Feed Data Set A" and having your order execution use "Feed Data Set B" can lead to REALLY BAD things. I was a feed systems admin for over 10 years....our OE used the same data as the quote servers...if that makes sense to you...

-G
More...

I updated the scheme:

Broker's Quotes Server -> (quotes in broker's format A) -> [ Quotes Connector -> (quotes in my own format B) -> Strategies Execution System -> (order signals in my own format) -> Order Management System <-> (order signals in my own format) <-> Order Routing System (FIX Engine) ] <-> (order in FIX format) <-> Broker's FIX Server

Is that what you mean by A and B?
 
You must log in or register to reply here.
Back
Top