Help Center Blog Open An Account

STOP Orders fills & SLIPPAGE in fast markets between Aurora vs. Cermak servers

latency
trading-execution
slippage

#1

Hello,
I would like to find out what would be the difference in potential price fills in fast markets
between STOP ORDERS which would be sent at the same time and same price between
Aurora based server (like Rithmic) and Cermak based server (like GainCapital/CQG).

Which of these could have a chance for potentially smaller slippage in case of fast market
(see Gold Futures example below) for the already placed server-side STOP ORDERS before the event
took place. I wasn’t trading this scenario but was curious what potential fills could be expected?

What could have happened, If I had a series of STOP orders between 1293 & 1297 price levels for /GC, could I expect that I was filled at the levels of the ORDERS or just next 1 or 2 ticks worse, or would I be filled in a cluster fill at the top (no vol climax anywhere during the first 5 seconds “the oval drawing area”?

Is there a way to anticipate the smaller slippage by the proximity of the data feed server to the exchange/matching engines or should the slippage be identical or very similar since the order is already server-side and the connectivity between the trader and server is irrelevant in this example, IMO.

How would the pre placed STOPS differ in general for the fills on:
ES, CL, GC and 6E contracts in the above scenario?

P.S. *Correction re: the chart below. There was “no” massive buying, as the volume was normal, but
rather the amount of buying quickly exhausted the available Offers liquidity (some of those orders could
have been my STOPS. So I am still trying to understand if I am to expect slippage or not too much
for my server-side orders in the order book.

Thanks a lot.

Best Regards,

  • P11


#2

I think the way to look at this is by time. How much longer would it take for your stop to get from the Rithmic or the Gain server to the exchange given that (a) the Rithmic server is in Aurora, (b) the Gain server is in Chicago and © the stop is released based upon receipt of an execution report? Assume it takes 500 microseconds for data to get from Aurora to Cermak. The stop in Aurora will be released virtually immediately and the stop in Cermak will be released about 500 microseconds later and then will have to travel for about 500 microseconds to get to Aurora for a total time difference of 1 millisecond. So the question then becomes how much slippage can happen in 1 millisecond? In my opinion, the answer to that question will vary based upon the instrument of the order, and the activity at the time the order is presented to the exchange. It can be none to a lot.

Another thing to consider is the location of the Rithmic and CQG servers. A number of years ago a prospect approached us inquiring about the route our data took. He claimed that the route that CQG’s market data took, was from Aurora to Nebraska or to Kansas and then to the end user. Such a route would add about 10 milliseconds to the time the data would take from Aurora to the end users. If the orders and execution reports travel such a route then the time taken for the stop order to be released will increase significantly.


#3

@Rithmic, thanks very much for your answer!

So, I still have the following unclear:

  1. Are the Stops (sent prior to the fast market event) already cleared with my FCM risk control and hence sitting already server-side in Aurora (Rithmic) or CQG/Gain (Cermak) and now pending CME’s Order Book (also in Aurora?) to travel/hit either Rithmic’ or CQG’ server once the market “touched” the STOP OFFER or STOP BID and is this communication between CME’s Order Book/Server back to Rithmic’s or CQG’s server could cause the time fill difference and also due to your average quoted 500 microseconds delay?

  2. Lets say that first priority would be to get the best STOP fill and the report back to the trader being secondary, is it fair to assume that the STOPS already cleared for risk and sitting on Rythmic’ server versus say CQG’ might actually receive similar fill or the delay in distance still applies?

  3. Finally, since the 2 identical orders, placed on two different severs will arrive at a miniscule time difference (even though those were send from the same location, same time by an algo, but FIFO would most likely cause the earlier to fill first, obviously).

Thanks for shedding some tech light on this.
I very much appreciate that.

Best Regards,

  • P11

#4

@Rithmic
I researched it a bit further and realized that the STOP MARKET orders (for ES) have
I believe a 2 point max slippage distance (coded by the exchange at this time) where if I understood correctly, a normal STOP MARKET order would NOT get filled if the slippage would be more then 2 ES points and the previous STOP MARKET order would be replaced with a new LIMIT resting order
(plus 2 points for STOP MARKET BUYS and minus 2 points for STOP MARKET SELLS points from the original STOP MARKET price).

If anyone from the community has any experience or further knowledge on this I would love to hear and collaborate further.

Regards,

  • P11

#5

https://www.cmegroup.com/confluence/plugins/servlet/mobile?contentId=78447015#iLinkOrderTypes-StopOrder

Above link specifies the STOP and MARKET orders with protection.

Regards,

  • P11

#6

When the Rithmic system receives a stop order, it checks the order for credit, among other things, and then sends the order to the exchange. The order does not reside on our servers unless so directed as part of the order (say release at a specified time) or unless the exchange does not support stop orders.


#7

@Rithmic,
Thanks a lot for the clarification.
So, after the credit order check with the FCM, the STOP orders are effectively a residing order
on the CME order book and subject to fills based on market activity.

Best Regards,

  • P11