Re: Business level functionality for consideration: ability to define message timeout for latency sensitive messages
John Harris / BondMart Technologies, Inc.
12 Jan 2011 9:54AM ET
Nathan,
I agree that enabling the message sender to determine the TIF of an order would be nice, but am doubtful that such a regime is feasible (granting in advance that I am no expert on the subject of clock synchronization).
I would think that in order for such a regime to work, the order would have a timestamp. On receipt by the matching engine (the definition of such act being non-trivial), the matching engine would have to compare that timestamp with its own clock, evaluate the TIF instruction, and decide whether to discard the order.
Presumably, this regime would have to apply to all inbound orders. The operation takes time and thus each inbound order would be taxed with some marginal delay, even when the owners of those orders do not wish to avail themselves of the feature.
In essence, this regime adds complexity to the matching process and the cost of that complexity would be socialized.
I stand to be corrected on my analysis, but to the extent it is valid, I would prefer for matching engines to play god on TIF instructions. On some type of cycle (probably determined by the OS), books can be swept for TIF validity. I think that is the most efficient, least complex approach.
Best,
John
> For example, we might want to allow a client application to specify on an order message, that if the message does not reach the matching engine within 15ms of the sending time, the matching engine should discard the message.
>
> It could be seen as a high resolution extension to the current time in force logic, or as a new type of more generic message restriction that can be applied where supported.
>
> Downside is that it would require clocks to be kept tightly in sync. That could possibly be established during session initialisation however....
@FIXProtocol
