Imported from previous forum
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
I posted a question to the List Trading about suppressing fills on a list http://www.fixprotocol.org/discuss/read/3ade5f09
The same sort of logic applies for an Algo order - have any of the Algo brokers thought about a parameter “Suppress Fills” to allow buy-sides to work around the limitations of their OMS???
I am just thinking is this a desirable feature? The buy side places an order with Sell side and they have a mutual agreement to “throttle” fills. Now if Buy side wants to Cancel-Replace the order to reduce quantity, the buy side has no way of knowing how much is already executed. What the buy side has as option is to cancel the oustanding order and place a new order, but the buy side does not know the quantity of the new order until the cancel for the original order is processed by sell side.
There are other cases I can think of where the Buy side may prefer to receive the Executions as they occur in the market. When a market order is placed and if the buy side does not receive Executions in real time, then it has no way of knowing the average price until the throttle is reached and the Sell side sends a “Cumulative execution report”. So the buy side trader cannot track the performance of the order in real time and would not be in a position to pull out the order from the market depending on Execution by Execution movement. Suppressing Fills would lead to buy side losing control on the order once it hits the market.
If I were writing a computer program to trade based on an Artificial Intelligence algorithim, then I would like to provide it “more” info than “less”, just my two cents. My algorithim would prefer to know where its objects in the markets stand in real time, and I as a programmer believe this ability is required for successful algorithimic trading.
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Well, I think that it’s fair to say that it’s not desirable. But my question was about a workaround for certain well known limitations of buy side OMSs. All of the business logic reasons you state are valid, but this is not about logic, it’s about dealing withe the existing state of the world.
I am just thinking is this a desirable feature? The buy side places an
order with Sell side and they have a mutual agreement to “throttle”
fills. Now if Buy side wants to Cancel-Replace the order to reduce
quantity, the buy side has no way of knowing how much is already
executed. What the buy side has as option is to cancel the oustanding
order and place a new order, but the buy side does not know the quantity
of the new order until the cancel for the original order is processed by
sell side.There are other cases I can think of where the Buy side may prefer to
receive the Executions as they occur in the market. When a market order
is placed and if the buy side does not receive Executions in real time,
then it has no way of knowing the average price until the throttle is
reached and the Sell side sends a “Cumulative execution report”. So the
buy side trader cannot track the performance of the order in real time
and would not be in a position to pull out the order from the market
depending on Execution by Execution movement. Suppressing Fills would
lead to buy side losing control on the order once it hits the market.If I were writing a computer program to trade based on an Artificial
Intelligence algorithim, then I would like to provide it “more” info
than “less”, just my two cents. My algorithim would prefer to know where
its objects in the markets stand in real time, and I as a programmer
believe this ability is required for successful algorithimic trading.
The Algorithmic Trading Work Group a few years ago looked into algos being able to publish various event streams, such that an OMS could subscribe to a custom stream of events best suited to its needs. The streams could drive various blotter grid controls and dashboards showing how the algo was progressing against its goals and other specific events. Likewise, when the initial order was sent, the OMS could instruct the algo to send back every fill in “real time” or to batch them together and send only aggregates.
We quickly discovered that any changes to how executions are reported are very delicate. Everything prior to the execution falls on the order side of things, where everything tends to be very fluid. From the point where the trade actually occurs, things get a whole lot more serious from an accounting and auditing standpoint. The asset has indeed changed hands and the final settlement process is kicked into play including liability for cash payment, ownership change, margin requirements, etc. Execution fill reports also drive real time profit and loss accounting and margin limits.
If each sell-side algo maker published its own concept of execution events quite a bit of chaos might be introduced, particularly at the OMS level and downstream from there. So, for Version 1.0 of FIXatd, we decided to not to even consider tampering with execution reporting, as it now exists at FIX.
For in process monitoring of algo executions, dashboards, etc. we envisioned that a trader would probably shell out to a standard web browser over a SSL link to connect to web services offered by the sell side that would provide unlimited real time monitoring capability of what was going on with algos in a very much “free form” environment. This world might include all types of high-resolution graphics, very advanced visualizations, three-dimensional animations, etc. none of which is well suited to standing FIX communications infrastructure. Various scenarios might be presented including recommendations for a cancel/replace of an algo that is currently executing. From that standard web service environment it would be quite easy for the OMS system to import the recommended new algo order (or cancel/replace order), which would be expressed in standard FIXatdl xml embedded in the returned web page. From that web document, extracting the standard FIXatdl order and importing it into the OMS would be trivial. The trader would then hit send and that new order would then go out on the standard FIX pipes. Also that order would be fully understood by the OMS and all the downstream systems from there.
That’s not to say that FIX should not look at updating the way the entire industry reports fills. As some point a “publish and subscribe” event model would make a lot of sense, and be much more flexible. However, the accountants, attorneys and regulators are all involved in this type of thing. You are impacting the formal accounting system, compliance with regulatory requirements, auditing, real time profit and loss, cash management, real time risk management systems, etc.) You can imagine with an impacted audience of all those groups change is apt to take a while.
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
All fair points but I would humbly suggest that you are somewhat over-thinking the problem. The issue is that certain specific buy-side OMSs cannot handle lots of fills and crash. Unless brokers aggregate fills the buy-sides cannot deal algos. It’s not anywhere near as clever as you are suggesting in your very detailed and nuanced response.
Already many brokers aggregate fills for program trades for the same reason.
Drop me a line outside of this forum and I’ll fill you in on the details if you are interested.
The Algorithmic Trading Work Group a few years ago looked into algos
being able to publish various event streams, such that an OMS could
subscribe to a custom stream of events best suited to its needs. The
streams could drive various blotter grid controls and dashboards showing
how the algo was progressing against its goals and other specific
events. Likewise, when the initial order was sent, the OMS could
instruct the algo to send back every fill in “real time” or to batch
them together and send only aggregates.We quickly discovered that any changes to how executions are reported
are very delicate. Everything prior to the execution falls on the order
side of things, where everything tends to be very fluid. From the point
where the trade actually occurs, things get a whole lot more serious
from an accounting and auditing standpoint. The asset has indeed changed
hands and the final settlement process is kicked into play including
liability for cash payment, ownership change, margin requirements, etc.
Execution fill reports also drive real time profit and loss accounting
and margin limits.If each sell-side algo maker published its own concept of execution
events quite a bit of chaos might be introduced, particularly at the OMS
level and downstream from there. So, for Version 1.0 of FIXatd, we
decided to not to even consider tampering with execution reporting, as
it now exists at FIX.For in process monitoring of algo executions, dashboards, etc. we
envisioned that a trader would probably shell out to a standard web
browser over a SSL link to connect to web services offered by the sell
side that would provide unlimited real time monitoring capability of
what was going on with algos in a very much “free form” environment.
This world might include all types of high-resolution graphics, very
advanced visualizations, three-dimensional animations, etc. none of
which is well suited to standing FIX communications infrastructure.
Various scenarios might be presented including recommendations for a
cancel/replace of an algo that is currently executing. From that
standard web service environment it would be quite easy for the OMS
system to import the recommended new algo order (or cancel/replace
order), which would be expressed in standard FIXatdl xml embedded in the
returned web page. From that web document, extracting the standard
FIXatdl order and importing it into the OMS would be trivial. The trader
would then hit send and that new order would then go out on the standard
FIX pipes. Also that order would be fully understood by the OMS and all
the downstream systems from there.That’s not to say that FIX should not look at updating the way the
entire industry reports fills. As some point a “publish and subscribe”
event model would make a lot of sense, and be much more flexible.
However, the accountants, attorneys and regulators are all involved in
this type of thing. You are impacting the formal accounting system,
compliance with regulatory requirements, auditing, real time profit and
loss, cash management, real time risk management systems, etc.) You can
imagine with an impacted audience of all those groups change is apt to
take a while.