|
High Performance Interface WG
< Previous Next >
Re: New Program Trading message types for batching
Hanno Klein / Deutsche Börse Systems <>
18 Jan 2011 9:50AM ET I agree to some extent. I would not call it "batching" of ERs because only executions of a single order in a single transaction qualify for the <FillsGrp>. It is still a single order. The same would apply to multiple modifications of the SAME order. I doubt that there is a use case for this. It would rather be a new MassOrderCancelReplace message what you are aiming at. This could have a repeating group of orders. This is similar to a MassQuote where many series can be modified at the same time. We will be looking to add a QuoteExecutionReport to FIX to avoid having to send individual ERs for every quote that gets executed. The key is that <Instrument> needs to be part of a repeating group and the standard ER has it on the root level. We will not change the structure of the standard ER, i.e. only a new message could cover that. More generically, it would be a MassExecutionReport if you want to apply the concept for orders and quotes. We only need it for quotes as this is a single matching event. For orders it would delay the receipt of an ER if the matching engine would wait for more than one order from one and the same submitter until sending him information back. I believe it needs to be aligned with the transaction boundaries of the matching engine, i.e. MassQuote is a single transaction whereas orders (still) hit the engine one by one.
True batching is more like FAST where you send multiple similar logical messages in a single physical message (UDP packet) and can omit repetitive information across messages. However, the main point is that FAST is unknown to the FIX application level. It happens on a lower level. I agree if we look at similar options for HFT, i.e. the encoder batches a number of FIX messages but the decoder on the other end already resolves that and the application level sees individual, complete FIX messages.
> 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
Hanno Klein / Deutsche Börse Systems 18 Jan 2011 9:50AM ET
|
@FIXProtocol
