[This message was posted by Richard Labs of CL&B Capital Management, LLC <[email protected]> to the "Algorithmic Trading" discussion forum at http://fixprotocol.org/discuss/31. You can reply to it on-line at http://fixprotocol.org/discuss/read/728af9ea - PLEASE DO NOT REPLY BY MAIL.]
>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: 1. 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. 2. 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. 3. 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: 1. 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. 2. 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. 3. 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 [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
