|
High Performance Interface WG
< Previous Next >
Re: New Program Trading message types for batching
Donald Mendelson / CME Group <>
18 Jan 2011 9:24AM ET It is quite common for high frequency traders to enter, modify or cancel multiple orders, all triggered by the same market data event. It could be more efficient to encode, route and deliver those requests in a batch as opposed to multiple individual messages. For one thing, duplication of party identifiers could be eliminated or reduced. For another, at a network level, the latency of routing and delivering the data in one packet (assuming a very efficient encoding) could be less than routing multiple packets. Furthermore, acknowledgement by the receiver could be done at a batch level as well.
Agreed that existing list order messages were designed for basket trading, not for the high frequency trading scenario. We should craft something new rather than abuse an existing message type. The new facility could either be defined as an application message or as part of a session protocol.
Hanno pointed out that a message block already exists for a batch of execution reports in FIX 5.0 SP1. A similar facility for orders and modifications would be desirable.
> I am not sure about this approach. It blurs the lines between application and session level. NewOrderList is not a batching facility for arbitrary orders. All orders in such a list are linked to each other in a business sense. For example, a basket order for an index consisting of one order per index constituent. Contingent orders are another example where you have only 2 orders (e.g. one cancel the other). The concept of List orders is to enter them in bulk and then to use ListExecute, ListStatus etc. to work on the entire list. Order modifications are done on individual orders with the standard OrderCancelReplace which carries tag 66 ListID to optionally reference a list.
> Batching is a different requirement in order to reduce message overhead. It should be hidden from the application level which should only deal with FIX messages. I cannot say whether it is worth the extra processing of the recipient to unpack the batch message. FIXML has a concept of batching built into the message as XML element. But FIXML is not used for HFT.
> Regards,
> Hanno.
>
> > The current NewOrderList (35=E) message doesn’t support modifies.
> > As a result, customers need to cancel and then send a new order list for a modify. It would be more efficient if HFTs were allowed to send only modifies.
> >
> > What I propose is that HFTs should be able to modify/cancel any subset or all orders in a list.
> > In order to provide this batching capability, it would be needed to create some new ProgramTrading message types.
> >
> > Regards,
> > Enio
Re: New Program Trading message types for batching
Donald Mendelson / CME Group 18 Jan 2011 9:24AM ET
|
@FIXProtocol
