Fast Market on CME ES: Market or Marketable Limit?

[Bad_Badness]

Perhaps someone knowledge of the CME Futures matching engine could answer.

In a very very fast market, which will fill first:

Market order or marketable Limit?

Background: After the LBros, BearS, meltdown, I tried to cover 5 contracts of ES. It took over 20 minutes to get a fill (at IB). The Market orders were placed 30 minutes before the Open (actually 20 hours before).

So I wonder if a market able limit (e.g. 30-40 ticks above the last, after the first 15 seconds) would have worked better. The primary goal was to get an execution, at ANY price.

I am assuming there is an absence of sellers, and air gaps in this scenario. I know there are several additional factors in play, hence the question.

Thanks in advance. And any pointers to reading material at the CME Globex for INDEX futures, is appreciated. Here is where I am looking: https://www.cmegroup.com/education/...ect=/education/cme-globex-order-pathways.html
and https://www.cmegroup.com/confluence/display/EPICSANDBOX/Order+Management

But no joy so far...

 

[Robert Morse]

You should ask them. Global Command Center, GCC@cmegroup.com.

 

[rb7]

Perhaps someone knowledge of the CME Futures matching engine could answer.

In a very very fast market, which will fill first:

Market order or marketable Limit?

Background: After the LBros, BearS, meltdown, I tried to cover 5 contracts of ES. It took over 20 minutes to get a fill (at IB). The Market orders were placed 30 minutes before the Open (actually 20 hours before).

So I wonder if a market able limit (e.g. 30-40 ticks above the last, after the first 15 seconds) would have worked better. The primary goal was to get an execution, at ANY price.

I am assuming there is an absence of sellers, and air gaps in this scenario. I know there are several additional factors in play, hence the question.

Thanks in advance. And any pointers to reading material at the CME for INDEX futures, is appreciated.

Since it's FIFO, it doesn't matter. The first order received by the CME will gets filled. There is no such thing as 'this type of order will be processed before another one'.

 

[schizo]

So what do you think?

 

[Robert Morse]

https://www.cmegroup.com/education/...-trading-cme-futures/futures-order-types.html

 

[Bad_Badness]

Thanks all for the replies. Indeed the various order types, MIT, MTL, MOO, MCO, FOK, and FIFO etc. dynamics have been "noted", and are understood. The question is more about the CME Globex matching engine.

Perhaps the original question can be restated in a BUY example.:

If there is a FAST disorderly market and one places a BUY market order it should get matched in this sequence until filled:
1) other Sell market orders.
2) oldest (first in), limit Sell orders on the books.

But if there are no Sell market orders on the other side, temporarily?

Would a Buy Limit order OVER the ask (over by 2X-3X the spread) on the books, match another limit order first, BEFORE another Buy Market?

It seems like the order engine, would simultaneously be chewing through the FIFO sell limit orders using the market buy orders, and matching limit orders also that are further away from the current-bid ask. I.e. matching in two ways not just one because its goal is to fill order at "best prices" for the client.

In practice, I try to stay away from these situations, but sometime there is no choice with an open position then an event driven closed market or lock limit pause, and then a reopening. Orders are deeply backed up, and sometimes the spread becomes erratic, air pockets ensue etc. I.e. a disorderly market on the initial reopening, but while I still need to execute. An uncommon event, but probably also inevitable.



Of course, other things would help: co-located servers, fewer compliance checks, direct api calls, etc,

Thanks, and I will ask the CME directly and post any useful answers.

 

[rb7]

Thanks all for the replies. Indeed the various order types, MIT, MTL, MOO, MCO, FOK, and FIFO etc. dynamics have been "noted", and are understood. The question is more about the CME Globex matching engine.

Perhaps the original question can be restated in a BUY example.:

If there is a FAST disorderly market and one places a BUY market order it should get matched in this sequence until filled:
1) other Sell market orders.
2) oldest (first in), limit Sell orders on the books.

But if there are no Sell market orders on the other side, temporarily?

Would a Buy Limit order OVER the ask on the books, match another limit order first, BEFORE another Buy Market?

In practice, I try to stay away from these situations, but sometime there is no choice with an open position then an event driven closed market or lock limit pause, and then a reopening. Orders are deeply backed up, and sometimes the spread becomes erratic, air pockets ensue etc. I.e. a disorderly market on the initial reopening, but while I still need to execute. An uncommon event, but probably also inevitable.

Of course, other things would help: co-located servers, fewer compliance checks, direct api calls, etc,

Thanks, and I will ask the CME directly and post any useful answers.

Market orders don't sit in the order book. You cannot have a sell market order waiting to be filled. Market orders (buy and sell) are matched against orders in the book.
This situation is only when the market is opened.
When the market is closed, there is an auction mechanism that take place for the opening. In this case, it's not FIFO. It uses an algo that usually maximizes the number of traded contract.

 

[Databento]

Since it's FIFO, it doesn't matter. The first order received by the CME will gets filled. There is no such thing as 'this type of order will be processed before another one'.

This is the correct answer.

HOWEVER, the market order has the potential to be slightly faster on client side because:
- tag 44 is not required, reducing 8 bytes of serialization latency (switch, NIC etc.) in the path.
- Likewise, you might bypass any application logic with price-related calculations that you might've have used for populating tag 44.

You'll be surprised how 8 bytes of serialization latency matters a lot to some firms. Back in the iLink 2 days, one firm we were acquainted with would send out an incomplete SenderLocationID field (2 bytes) on TAS markets to gain a latency advantage, then modify the order after it got posted to retroactively ensure it had the correct value. (Don't try shenanigans like this - it got them fined.)

This is if you're managing your own iLink session. If you're submitting it to a broker/ISV's (IB in this case) order gateway, there's no telling what the vendor might do differently in its path. There's a small chance an ISV might do something more 'stateful' with your marketable limit order synchronously before sending it off, since they might decide to do their own bookkeeping of any passive order first. Or the ISV may do no bookkeeping until the execution report comes back. There's also a chance the ISV uses drop copy to carry out the bookkeeping ex post of the order posting.

In your case it's likely that it doesn't matter because you have much lower hanging fruit for the next marginal reduction in latency and the price protection (of the marketable limit) has so much more intrinsic value than any latency cost.

 

[Overnight]

...

If you're submitting it to a broker/ISV's (IB in this case) order gateway, there's no telling what the vendor might do differently in its path. There's a small chance an ISV might do something more 'stateful' with your marketable limit order synchronously before sending it off, since they might decide to do their own bookkeeping of any passive order first. Or the ISV may do no bookkeeping until the execution report comes back. There's also a chance the ISV uses drop copy to carry out the bookkeeping ex post of the order posting.

In your case it's likely that it doesn't matter because you have much lower hanging fruit for the next marginal reduction in latency and the price protection (of the marketable limit) has so much more intrinsic value than any latency cost.

Hahah, sorry man, but your post made me lol because it correlated my thoughts on reading this thread with this little bit from Colbert when he was explaining LOTR...