Strategic Runs FAQ
In (Hasbrouck, Joel, and Gideon Saar, 2013, Low-latency trading, Journal of Financial Markets 16, 646-679.) we define a measure of algorithmic activity called "Strategic Runs".
The following notes address some queries that we've encountered.
In the first step, you use the reference number to unambiguously link those messages with the following orders: Submissions—Cancellation/Execution; And then you infer if a subsequent submission can be linked to the previous cancellation, by timing, direction, and order size. Then the total length of these orders is the length of the run. However, since you measure low-latency activities, in the very first step where those linked orders via reference numbers are identified. Did you apply a filter to them based on speed? Say, ONLY include those ‘Submissions – Cancellation’ IF THEY OCCUR WITHIN 100ms(or whatever), OR did you include all messages even if ‘Submissions – Cancellation’ occur in minutes??
We do NOT apply a filter on submission-to-cancellation or submission-to-execution durations. Low-latency is distinctive in the response to changes in market conditions or new information. If there were to be no change in the book or the market over many minutes, there would be no need to revise an order. In fact doing so would have a substantial cost, namely, the loss of time priority.
I have several questions on how exactly the measure is constructed. For a message sequence:
Do you consider it is a strategic run? I look at the definition and I think it is, and I guess that you call it passive execution run. However, how long is the time interval of the run? Do you think it is a run of 15 minutes?
The time interval of a run is start to finish - in this case, 15 minutes.
When you calculate strategic run, do you delete the messages when you find that it is in a run? If I locate a strategic run with 100 messages, should I delete the messages and then try to find another strategic run with remaining messages?
Messages are not reused in the run construction process. We start with the first submission, track it forward, however long it takes, and then mark them so they aren't used in other runs. Then on to the next submission (after the first).
The sequence can be quite complex in the ITCH data. For example, the sequence can be 10 consecutive deletions and then followed by 10 consecutive additions. In that case, are you calculating strategic run by assuming that the first deletion is followed by the first addition, and the second deletion is followed by second addition?
We do assume that the run messages are consecutive. That is, a run has to be add, cancel, add, cancel ... If there are 10 consecutive deletions followed by 10 consecutive additions, there must be at least ten runs.
The final question is about the algorithm to search for strategic run. Because there are many messages in the ITCH data, do you start to link the data through the deletion message and examine whether it is linked with a resubmission within 100 milliseconds or you start from the addition message and try to track the life of each additions?
We build one run at a time. Starting with the first submission message, We follow the cancel/resubmit/execute links forward as far as we can. All the linked messages are tagged so that they aren't used in later runs. Then back to the start of day. Look forward for the first untagged submission. And so on.
Have you released the code?
The code is in Java. It makes extensive use of the Java Collections framework. And it is neither documented, nor is it packaged so that it can be easily run outside of Stern, we're reluctant to release it. If we start getting many requests we'll put together a package, but the labor involved would be substantial.