Imported from previous forum
Do any of the standard third party testing tools handle multi-leg orders or the parent/child relationships in algo trading?
i.e. Can they confirm that an fill for a exchange-side order (that was generated by the algo) is applied to the correct client-side order?
– Scott
third party testing tools handle multi-leg orders or the parent/child relationships in algo trading?
Can only comment regarding the current version of FIXatdl and how we conceptually thought through multi-leg orders. FIXatdl did envision generating as the output a AB NewORderMultileg type order:
MsgType: AB
MessageName: NewOrderMultileg
MessageID: 61
Each multi-leg order requires a CLOrdID
11 ClOrdID String 1 Unique identifier of the order as assigned by institution or by the intermediary with closest association with the investor.
One significant problem faced by the Algo WG was we could not generate direct participation by heavy duty users of order type AB who were willing to donate significant time to FIXatdl development. Some of the challenge areas were:
-
How to draw screens with “n” number of securities with n only being resolved at order entry time. We were having trouble with widgets and panel layouts with so much dynamic drawing of the screens. One multi leg order is 3 securities, the next is 16, some are 32 or even full lists of 500, etc. Designing and describing “generic” screen handling functionality that works for all, yet is highly customizable, so each hard core trader has a wonderful order entry experience was a huge challenge.
-
Really understanding how order type AB was broadly deployed in standard FIX messages right now was illusive. We were looking for a sample of say 100 AB type actual order messages we could look at as illustrative of how that order type actually looks “on the wire” and is actually implemented right today.
-
We only wanted to deal with generating orders in FIXatdl, and totally ignored any type of confirmation or “response back” from the algo provider. We made a dramatic assumption here. The response would be a well known standard FIX message, and the OMS generating the algo order would ALREADY understand any of those standard FIX response messages coming back at it.
As a result FIXatdl may in some instances, enable an OMS to render all the screen side of the AB type order (albeit with some “creativity” in handling “n” securities, known only at new order entry time). That will enable it to correctly put all the parameter into a 100% valid AB type order and send that to target after its been locally validated. However if there is a highly unique way the BD responds to those orders, a plain vanilla OMS is highly likely to “choke” on the response.
To simplify things we envisioned AB orders going in as one message, yet all individual security executions occuring based on that single multileg order instruction to be confirmed back in simple “one security per execution message” type responses. This would enable most OMS systems to be able to 1. send in a valid AB order and 2. not choke on the output since they are all separate and simple. (This however assumes that the OMS isn’t trying to tie out orders to executions -(eg a single AB master order, with all the responses, each leg’s execution report.
We assumed that each execution report would contain the single master CLOrdID and it would also likely contain some link identification that reported which specific leg that execution was for. Beyond that we left it up to the OMS to make sense of those.
Bottom line:
- We copped out of dealing with anything but the original order message only (IE sending a single AB order to a target). We just assumed the response would be something the sender’s OMS could cope with.
- We were fuzzy on rendering the screen for all mult leg order types. We think we have the basics in place but things like specifying lists of securities by their index, creating global defaults that applied to all legs, then being able to override the global defaults with individually set parameter for each row (security) were causing us headaches.
- Since we only had limited industry participation we had to do the best we could with that LIMITED input and agreed to totally refine and add necessary capability in future versions of FIXatdl.
Here were some optional ID’s that might be used to link the individual execution legs to the “master” AB order:
526 SecondaryClOrdID String
583 ClOrdLinkID String
Again, sorry this isn’t directly on topic of testing, however if you find heavy AB users or testing experts invloved with AB we would love to have them participate specifically to look over the AB type order functionality contained in FIXatdl.
Rick
third party testing tools handle multi-leg orders or the parent/child relationships in algo trading?
Can only comment regarding the current version of FIXatdl and how we conceptually thought through multi-leg orders. FIXatdl did envision generating as the output a AB NewORderMultileg type order:
MsgType: AB
MessageName: NewOrderMultileg
MessageID: 61Each multi-leg order requires a CLOrdID
11 ClOrdID String 1 Unique identifier of the order as assigned by institution or by the intermediary with closest association with the investor.
One significant problem faced by the Algo WG was we could not generate direct participation by heavy duty users of order type AB who were willing to donate significant time to FIXatdl development. Some of the challenge areas were:
How to draw screens with “n” number of securities with n only being resolved at order entry time. We were having trouble with widgets and panel layouts with so much dynamic drawing of the screens. One multi leg order is 3 securities, the next is 16, some are 32 or even full lists of 500, etc. Designing and describing “generic” screen handling functionality that works for all, yet is highly customizable, so each hard core trader has a wonderful order entry experience was a huge challenge.
Really understanding how order type AB was broadly deployed in standard FIX messages right now was illusive. We were looking for a sample of say 100 AB type actual order messages we could look at as illustrative of how that order type actually looks “on the wire” and is actually implemented right today.
We only wanted to deal with generating orders in FIXatdl, and totally ignored any type of confirmation or “response back” from the algo provider. We made a dramatic assumption here. The response would be a well known standard FIX message, and the OMS generating the algo order would ALREADY understand any of those standard FIX response messages coming back at it.
As a result FIXatdl may in some instances, enable an OMS to render all the screen side of the AB type order (albeit with some “creativity” in handling “n” securities, known only at new order entry time). That will enable it to correctly put all the parameter into a 100% valid AB type order and send that to target after its been locally validated. However if there is a highly unique way the BD responds to those orders, a plain vanilla OMS is highly likely to “choke” on the response.
To simplify things we envisioned AB orders going in as one message, yet all individual security executions occuring based on that single multileg order instruction to be confirmed back in simple “one security per execution message” type responses. This would enable most OMS systems to be able to 1. send in a valid AB order and 2. not choke on the output since they are all separate and simple. (This however assumes that the OMS isn’t trying to tie out orders to executions -(eg a single AB master order, with all the responses, each leg’s execution report.
We assumed that each execution report would contain the single master CLOrdID and it would also likely contain some link identification that reported which specific leg that execution was for. Beyond that we left it up to the OMS to make sense of those.
Bottom line:
- We copped out of dealing with anything but the original order message only (IE sending a single AB order to a target). We just assumed the response would be something the sender’s OMS could cope with.
- We were fuzzy on rendering the screen for all mult leg order types. We think we have the basics in place but things like specifying lists of securities by their index, creating global defaults that applied to all legs, then being able to override the global defaults with individually set parameter for each row (security) were causing us headaches.
- Since we only had limited industry participation we had to do the best we could with that LIMITED input and agreed to totally refine and add necessary capability in future versions of FIXatdl.
Here were some optional ID’s that might be used to link the individual execution legs to the “master” AB order:
526 SecondaryClOrdID String
583 ClOrdLinkID StringAgain, sorry this isn’t directly on topic of testing, however if you find heavy AB users or testing experts invloved with AB we would love to have them participate specifically to look over the AB type order functionality contained in FIXatdl.
Rick
Hi, just a simple question, if i enter an algo Parent order, lets say Buy 100K IBM US 20% of volume
then i enter out of this Parent order 5 times 20k
what happens, if the system is set up correctly
do i get 20% of volume on 100k or 5 times 20%
which means virtually 100% of volume?
Hi, just a simple question, if i enter an algo Parent order, lets say Buy 100K IBM US 20% of volume
then i enter out of this Parent order 5 times 20k
what happens, if the system is set up correctly
do i get 20% of volume on 100k or 5 times 20%
which means virtually 100% of volume?
First impression
I have to make some assumptions, if you could check them that would be great:
Buyside through their OMS sends an algo order to Sellside as follows:
buy 100k IBM 20% of volume
Buyside understands the algo (which is supplied by sellside) very well. Enters the parameters correctly on their end.
Order transmitted to sellside as a single unit.
Sellside "unpacks" the order and executes it on their end. That is it translates the algo and inbound price/volume feed and translates the "parent" algo order into multiple child orders (each a simple market or limit order) and routes those orders for execution.
As order executes somehow the 20% of volume or 100k shares total is violated
Sellside is sending individual confirms back to buyside as they are executing (I.e. the trade confirms are being sent one-by-one as they occur. Its not batch.)
Impression
Buyside is entitled to a make good, an as-if the algo functioned correctly. That is never exceeded 20% of volume and never exceeded 100k shares.
Sellside responsible.
Buyside SHOULD (out of decency or common courtesy) inform Sell-side the instant they detect (via the inbound trade confirms they are getting) that something appears “amiss” with the algo. However they have no DUTY to monitor, especially in real time. However if it comes to their attention…
Were the situation this cut and dry and an algo malfunctioned on the sellside, the buyside would become skeptical and would likely want a full report of how the algo malfunctioned. External to trading the risk managers at the buyside would want to talk to the risk managers on the sellside and get down to the real nitty gritty of it. The tone of the meeting would be “serious”.
On Second reading
#1> algo Parent order, Buy 100K IBM US 20% of volume
#2> then i enter out of this Parent order 5 times 20k
what happens, if the system is set up correctly
do i get 20% of volume on 100k or 5 times 20%
which means virtually 100% of volume?
Line #1 is clear cut. 100% sufficient and clear (buyside to sellside)
Line #2 is very confusing. Who is doing this? Why wasn’t #1 entirely sufficient?
If the algo is running BUYSIDE, line #1 is never transmitted to sellside
line #2 is different than line one. Lets assume line #1 is NEVER transmitted to sellside, only the 5 “child orders” are sent, each: buy 20K IBM US 20% of volume. And each of the five separate orders are sent individually to the sellside. Then YES buyside has just purchased 100% of IBM for a while. How this “throttles down” is very uncertain. Think of it as 5 agents, each blind to each other. Each “does its thing” seeing only 100% of volume and limiting itself to 20% of that (irregardless of what the other 4 “agents” are doing). If the buyside wanted 20k shares of the first 100% volume, then 20k shares of the next 80% of volume, 20k shares of the next 60% of volume … up to 100k shares, that would require a custom algo that behaved that way. Each of the 5 orders would be released in serial sequence, only upon the execution of the prior one would the next one release.
Rick
Hi, just a simple question, if i enter an algo Parent order, lets say Buy 100K IBM US 20% of volume
then i enter out of this Parent order 5 times 20k
what happens, if the system is set up correctly
do i get 20% of volume on 100k or 5 times 20%
which means virtually 100% of volume?First impression
I have to make some assumptions, if you could check them that would be great:
Buyside through their OMS sends an algo order to Sellside as follows: buy 100k IBM 20% of volume Buyside understands the algo (which is supplied by sellside) very well. Enters the parameters correctly on their end. Order transmitted to sellside as a single unit. Sellside "unpacks" the order and executes it on their end. That is it translates the algo and inbound price/volume feed and translates the "parent" algo order into multiple child orders (each a simple market or limit order) and routes those orders for execution. As order executes somehow the 20% of volume or 100k shares total is violated Sellside is sending individual confirms back to buyside as they are executing (I.e. the trade confirms are being sent one-by-one as they occur. Its not batch.)Impression
Buyside is entitled to a make good, an as-if the algo functioned correctly. That is never exceeded 20% of volume and never exceeded 100k shares.
Sellside responsible.
Buyside SHOULD (out of decency or common courtesy) inform Sell-side the instant they detect (via the inbound trade confirms they are getting) that something appears “amiss” with the algo. However they have no DUTY to monitor, especially in real time. However if it comes to their attention…
Were the situation this cut and dry and an algo malfunctioned on the sellside, the buyside would become skeptical and would likely want a full report of how the algo malfunctioned. External to trading the risk managers at the buyside would want to talk to the risk managers on the sellside and get down to the real nitty gritty of it. The tone of the meeting would be “serious”.
On Second reading
#1> algo Parent order, Buy 100K IBM US 20% of volume#2> then i enter out of this Parent order 5 times 20k
what happens, if the system is set up correctly
do i get 20% of volume on 100k or 5 times 20%
which means virtually 100% of volume?Line #1 is clear cut. 100% sufficient and clear (buyside to sellside)
Line #2 is very confusing. Who is doing this? Why wasn’t #1 entirely sufficient?
If the algo is running BUYSIDE, line #1 is never transmitted to sellside
line #2 is different than line one. Lets assume line #1 is NEVER transmitted to sellside, only the 5 “child orders” are sent, each: buy 20K IBM US 20% of volume. And each of the five separate orders are sent individually to the sellside. Then YES buyside has just purchased 100% of IBM for a while. How this “throttles down” is very uncertain. Think of it as 5 agents, each blind to each other. Each “does its thing” seeing only 100% of volume and limiting itself to 20% of that (irregardless of what the other 4 “agents” are doing). If the buyside wanted 20k shares of the first 100% volume, then 20k shares of the next 80% of volume, 20k shares of the next 60% of volume … up to 100k shares, that would require a custom algo that behaved that way. Each of the 5 orders would be released in serial sequence, only upon the execution of the prior one would the next one release.Rick
the parent order was not send with it, means only the child orders were sent
Radu
the parent order was not send with it, means only the child orders were sent
Radu
O.K., looks to me like 5 independent orders each: BUY 20K IBM US 20% Volume. I see this as 5 agents (human like) each blind to each other. Each with an appetite for 20% of the volume as printed on the tape, each striving hard achieve it’s 20% slice. Each software agent here is “competitive” to all others (including the 4 others from the same Buyside client). Of course on a stock like IBM there are likely hundreds(?) more “agents” active in the market at any point in time, each “ready, willing, and able” to trade INSTANTLY, should their trade parameters be met. Each agent is an island to itself, only looking BACK at what trades printed and each looking FORWARD to a consolidated limit order book.
As trades execute and are reported (near real time but not perfect) each algo looks back to see, “did I get 20% of the volume”? If I did not, I need to juice up my bids going forward. If I got more than 20% of the volume I need to either withdraw from the market until such time as I’m less than 20% of the total volume.
Imagine an apartment with a right-sized furnace, a person comes home and dials the thermostat from 60F to 70F. The system is then left to do the job. Things work normally, the furnace comes on full blast and likely it “overshoots” 70 a bit and then it shuts off. Likely it doesn’t come back on till the temperature drops to perhaps 68-69. Overall the temperature is maintained at 70 with SOME variation. If that “margin” of allowed variation is too thin, the furnace cycles on and off much too frequently, trying to maintain a more “exact” temperature than it was designed, and all the parts fail prematurely.
The furnace is a fixed size (in terms of BTUs). Its state is digital: either ON or OFF. (All algos resolve to either market or limit orders, they are either active in the market (ON) or not (OFF)).
Now imaging the apartment with FIVE full size furnaces and FIVE thermostats. The person comes home and dials all thermostats from 60F to 70F. All five come on. The “overshoot” as all FIVE furnaces charge towards the 70 target is substantial! Once 70 (or so) each separate furnace/thermostat system operates in a somewhat “chaotic” fashion because of minor variation in the thermostats.
The behavior of five Buy 20K IBM limit 20% volume “agents” interacting will likely be chaotic. Each are likely running on the same algo engine as five instances/threads in a time slicing operating system. As a result each agent is not getting the same information at the same time. Orders emanating from the five instances are hitting the downstream order router in a serial cue. Execution reporting to each running instance are also not necessarily in perfect sync.
Additionally, the ability for a High Frequency Trader to FRONT RUN this type of order is child’s play. Even if the algos “back off” a random amount of time its still fairly easy to detect a “net buyer” especially as you go above 20% of the volume.
Rick
line #2 is different than line one. Lets assume line #1 is NEVER transmitted to sellside, only the 5 “child orders” are sent, each: buy 20K IBM US 20% of volume. And each of the five separate orders are sent individually to the sellside. Then YES buyside has just purchased 100% of IBM for a while. How this “throttles down” is very uncertain. Think of it as 5 agents, each blind to each other. Each “does its thing” seeing only 100% of volume and limiting itself to 20% of that (irregardless of what the other 4 “agents” are doing). If the buyside wanted 20k shares of the first 100% volume, then 20k shares of the next 80% of volume, 20k shares of the next 60% of volume … up to 100k shares, that would require a custom algo that behaved that way. Each of the 5 orders would be released in serial sequence, only upon the execution of the prior one would the next one release.