Imported from previous forum
[ original email was from Vivien Lee - vivien.wm.lee@ing-barings.com ]
Hi there,
What exactly is the diffent between Pending New and New?
By sending a OrderStatus="NEW" does it mean broker receive the message. Or it actually means the Stock Exchange receive the order?
Regards,
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Hi there,
>
> What exactly is the diffent between Pending New and New?
> By sending a OrderStatus="NEW" does it mean broker receive the message. Or it actually means the Stock Exchange receive the order?
The definition of New isn’t really well-defined.
Everyone seems to agree on the basic premise that a valid order should transition to New at some point prior to it trading, and that the transition should be relatively soon after the order is placed. However, the exact time that the transition occurs is a business decision for firms to choose.
Some firms have the front-end FIX engine report New immediately. Others pass it on to a business server, and the business server reports New there. Others route it to a destination, wait for the destination to respond, and then send the New to the client.
This illustrates why order ack time is a rather meaningless measure of overall performance when comparing two systems because it doesn’t necessarily measure the full round-trip path the order must take so it can trade. Moving the ack generation closer to the client gives better perceived ack time performance, even though the time for the stock to trade doesn’t change one bit. This is why time for an order to trade, assuming the order is executed immediately, is a much better indication of comparing two different systems than ack times.
Personally, I think that having the system responsible for executing the order generating the ack is the best way to do things. It lays everything out in the open, and seems to be the most honest for the broker’s customer.
For example, assume an ECN that consists of a FIX front end and a matching engine. Assume that during the open, the link between the FIX front end and matching engine becomes clogged, or the matching engine becomes bogged down. If acks are generated at the FIX front end, the client has no direct knowledge of the problem, but his orders are executed more slowly. If acks are generated by the matching engine, then the client can see ack times increasing beyond their normal levels, will know something is wrong with that ECN, and can call to complain or can decide to route order flow to another competing ECN until the problem is resolved.
The same argument could be applied to an executing broker taking FIX orders and routing to DOT. They might ack at their FIX engine, at their central OMS or business server, or when NYSE acks via CMS. Assume the broker’s CMS lines become clogged. The customer has no way of knowing this if acks are generated by the front end or OMS. But the customer will know about the problem if NYSE’s CMS ack triggers the FIX ack.
Moving ack generation further from the FIX engine also helps locate lost orders in a more timely fashion. If the sell-side loses an order, and ack generation happens at the execution point, then the client will see no FIX ack for the order and will likely pick up the phone to call the sell-side’s trade desk. If the ack is generated immediately at the FIX engine, the client has no way of knowing the order is lost. Regardless of who bears responsibility for the lost order, it is in everyone’s best interest for the situation to be discovered and remedied as quickly as possible.