Help Center Blog Open An Account

E-mini Order Execution Issues



I’ve developed a scalping strategy for the S&P 500 e-mini. Through extensive backtesting and walkforward analysis the algorithm theoretically performs well with a solid Sharpe ratio and manageable drawdowns. However, during live operation I’m having difficulty getting limit orders executed at the price levels I need. Thousands of contracts are being executed at the prices I’m targeting but I just can’t get seem to get filled.

My current setup is MultiCharts (chosen for prototyping), Rithmic data feed and Wedbush FCM. While I’m not attempting HFT, the strategy trades frequently with an average hold time of seconds and ‘works’ across multiple tick intervals. I’m using relatively small position sizes of 2-10 contracts.

From what I understand the e-mini’s matching algorithm is FIFO. I’m based in Europe so latency is likely a factor and MultiCharts PowerLanguage is most likely a lot slower to execute than a low-level language. As such, I’m considering porting my code to C/C++ and integrating with R|Diamond API using proximity hosting in Aurora to see if it solves this issue.

Has anyone implemented a similar stack to the above, and did it offer a significant performance improvement?



Recoding your algorithm in another language takes time and effort and can introduce bugs. Before you walk that path, given that you run MC on a machine located more than 3000 miles from Aurora, IL (which is where the CME’s matching engine software runs), you might consider reducing your latency first by running MC on a machine that is located in the CME’s data center in Aurora, Il or nearby in Chicago. Your latency should drop by at least 60 milliseconds and it should be easy to see if such a latency reduction makes a difference.

If MC provides timestamps on market data and order status messages you can compile tick to trade stats. If you move MC as described above, you can then get an objective reading on stats from that setup and see (1) that there really was a reduction in latency, and (2) whether or not you got filled at your price more than before. Further latency reductions are possible but none such as large as the UK – USA move and none that do not involve coding.

We hope this helps.

Optimus Futures