Imported from previous forum
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…
[ original email was from John Harris - john.harris@bondmart.com ]
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…
Hi,
The problem I see (which seems quite relevant to this group) is that you cannot know when sending a message (especially via TCP) precisely how long it will take for that message to reach its ultimate destination.
If you know in advance that an order is very latency sensitive (for example trying to take advantage of on opportunity during a period when a market is very volatile), it might be useful to provide the timeout functionality as an optional restriction that can be applied to the message.
Where the restriction is not specified (which would be the case for most non-high frequency market participants) there would be no impact on performance.
Where it is specified, the performance impact would need to be tested. My guess is that this will IMPROVE matching engine performance. Since it is only likely to be specified at times of high volatility, it could actully reduce the number of orders which are matched, thereby reducing the amount of work that the matching engine needs to do.
I don’t think it could be implemented using the sweep mechanism as that assumes that the order will rest in the book?
Cheers
Nathan
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,
JohnFor 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…
It seems that TIF functionality as it exists now already covers delivery delay. If the order originator wants an order to be valid for 5 minutes, why would the intent change if the order took more than 15 milliseconds to reach the matching engine? I am not sure I see the business case. But if you think that there should be a “start” limit as well as a “stop” limit, it is a matter of adding another timestamp to a TIF order. This is somewhat similar to stop limit orders.
Correct EP100 added valid value A=“Good For Time” to 59 TimeInForce and tag 1629 ExposureDuration. However, it does not solve the problem of clock syncs and the requirement to have the clock start ticking at the submitter’s site. From EP100:
"We will leave it up to bilateral agreement to define where the clock starts ticking, i.e. when the order enters the infrastructure of the marketplace or only when the matching engine starts to process it. In failover situations there might be many seconds between these two points in time and the user might not want the matcher to work on it when he is back up again."
Also, the matching engine would not sweep the book to look for orders that have become stale. It would discard orders that are otherwise qualified as it attempts to carry out a match.
It seems that TIF functionality as it exists now already covers delivery delay. If the order originator wants an order to be valid for 5 minutes, why would the intent change if the order took more than 15 milliseconds to reach the matching engine? I am not sure I see the business case. But if you think that there should be a “start” limit as well as a “stop” limit, it is a matter of adding another timestamp to a TIF order. This is somewhat similar to stop limit orders.