[This message was posted by John Harris of BondMart Technologies, Inc. <[email protected]> to the "4.4 Changes" discussion forum at http://fixprotocol.org/discuss/17. You can reply to it on-line at http://fixprotocol.org/discuss/read/d07c3396 - PLEASE DO NOT REPLY BY MAIL.]
Interesting question...yes, I'm lurking, too :-) Taking your hypothetical literally (entity receives iceberg order with instructions to send the order to a specific venue that does not support iceberg orders), I might have made a different business decision with respect to order handling. I would wonder, "Does the sender fail to understand that his intended destination provides no support for these order types or did he simply specify the wrong destination, intending this order instead for a venue that does support iceberg orders?" Further, as the SOR operator, I would be concerned about exercising discretion not granted to me. Simulating the behavior of an iceberg at the SOR level may produce different business results than would be obtained were the order handled as instructed. For example, what if the undisplayed liquidity counts toward a liquidity-provision requirement that would not be satisfied by the drip handling of the SOR. My inclination would be to reject an order that cannot be handled as instructed, providing an appropriate reject code. Just another perspective... Best, John > As this is a favorite topic of mine, I'll stop lurking and respond. > > It is a highly complex issue to identify which FIX tags will determine > whether an order is a "smart" or not. > > Let me give an example: > > Q. An entity receives an iceberg (display qty < order quantity) order with > instructions to forward it to a specific execution venue. Should the > receiving entity route this order to its SOR (Smart Order Router) or should > it route the order directly to the specified execution venue? > > A. Depends. If the execution venue doesn't support iceberg orders, you > should route it to the SOR. A decent SOR will simulate iceberg orders by > sending a child order to the specified execution venue with the child order > qty = parent order display qty. When the child order is fully filled, the > SOR should then send another child order with order qty = parent order > display qty, continuing until the parent order qty is exhausted. (A good SOR > will randomize child order qty and even execution venue in order to avoid > being picked off). > > So my answer to the original question is: Only knowledge of the requirements > and capabilities of the SOR and execution venue can help you decide whether > an order is a smart order or not. Ultimately this does indeed translate into > looking into the FIX tags on the order, but this could be a very large and > varied set of tags. > > In the Lava ColorBook SOR, there is a logic engine with many rules to decide > whether the order is smart or not. The rules change frequently, depending on > upgrades to the SOR's intelligence as well as the ever changing landscape of > execution venue capabilities. > > I hope this helps. > > JohnP > > > > > Which tag in FIX 4.4 can be used to decide if the order needs to be > > > routed to Smart Order Routing or exchange? [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.
