This article is by Gabriel Kan & Hideaki Sano.
In our previous post, we discussed how each queue can be classified in one of the four cases, depending on how it starts and ends:
- New Level to New Level (Price penetration ↗↗)
- New Level to Old Level (Price reversion ↗↘)
- Old Level to New Level (Price reversion ↘↗)
- Old Level to Old Level (Price penetration ↘↘)
For each case, we study its lifecycle by looking at the average quote size at start time, end time, and when the queue size is at its maximum.
Queues during price reversion have a significantly shorter duration (~30 sec) compared to queues during price penetration (~1 min). New-Level-to-New-Level queues take much longer to stabilize in size — it takes 35 sec to attain the maximum size, while the other cases take only about 5 sec. In this case, it is important to actively monitor the passive orders for a longer period to anticipate the longer queue building process. We also observe that queue size is constantly changing, and the magnitude depends on the queue type. A typical New-Level-to-New-Level queue will have a maximum size equal to 14 times the starting size.
Figure 1: lifecycle of queues that start at the old price level
Figure 2: lifecycle of queues that start at the new price level
Consider the case where ten orders are queued at the best bid with 1000 shares each, and we are the first order in the queue, i.e. we are 10% of the queue size. Then sell pressure comes in and the first five orders are executed, including ours. Assume that the remaining queued orders are withdrawn from the queue due to the sell pressure. In this case, we would have traded 20% of the market volume, but not 10%.
In another scenario, assume that no orders were withdrawn from the queue, but another five new orders with 1000 shares each come to join the queue. If all orders are executed, we will be only 6.7% of the market volume, but not 10%.
The above examples illustrate the challenge of target participation by queuing orders. If we are in the front of the queue, order withdrawal by others can lead to over-trading (first example) while order replenishing can lead to under-trading (second example). Overall, we found that traded shares equal only 75% of the average queue size, or 48% of the maximum queue size. In other words, typically not the full queue will be executed.
Drilling down into different queue cases, the results heavily depend on whether there are residual orders in the queue when it ends. If the queue ends with no residual orders (New-Level-to-Old-Level ↗↘ or Old-Level-to-Old-Level ↘↘), the maximum queue size is a good proxy for the market volume in the queue life cycle: Traded volume is 118% and 95% of the maximum queue size of a new queue and old queue respectively.
On the other hand, if the queue ends with residual orders (New-Level-to-New-Level ↗↗ or Old-Level-to-New-Level ↘↗), only the tip of the queue will be executed; traded volume is only 15% and 8% of the maximum queue size of a new queue and old queue respectively. Traded volume of New-Level-to-New-Level queue (↗↗) is almost twice of Old-Level-to-New-Level queue (↘↗). One reason is that traders are more reluctant to create price penetration, and the time that stays at a New-Level-to-New-Level queue (↗↗) is doubled that of an Old-Level-to-New-Level queue (↘↗). Thus, it leads to more orders being executed.
Figure 3: total traded shares vs. average and maximum queue size
In order to correctly anticipate the market volume, one needs to take the queue dynamics into account. As we have shown, predicting the queue ending scenario, particularly whether there are residual orders when it ends, is critical in estimating the actual volume executed from the queue. Queue building process, buy-sell pressure, and order imbalance are also important factors to be considered.
Furthermore, one can directly predict the market volume and use it as a guideline to avoid severe over-trade or under-trade. For example, if the predicted volume of the next 5 min is only 1000 shares, we can cap the order size to 100 shares when the target participation is 10%. This would work as a safety for mistakenly predicting the queuing process.