Custom Futures Spreader – Case Study
The Client Need
A proprietary trading firm with numerous years of experience trading futures wanted to improve their profitability. They had previously been trading spreads using several popular automated spreading tools. Some of their tools used workstation spreading algorithms while others used server side spreading algorithms.
The client saw a decline in the financial performance of these algorithms and wanted to improve profitability. They believed that latency in the trading was causing some of their financial slippage.
Simple futures spreading is trading two contracts on opposite side of the market at the same time. For example, selling the June contract and buying the September contract in the same commodity. The spread trader is attempting to make a profit by trading the differential price movements between the two contracts.
Spreading comes in many forms as shown in the following table.
|Long June Corn, Short Sept Corn
|Long Corn, Short Wheat
||Intercommodity Spread or Statistical Arbitrage
|Long CBOT June Wheat, Short ICE Canada June Milling Wheat
|Short CME E-Mini June Future, Long EUREX June Mini-DAX Future
||Intermarket Spread or Intermarket Statistical Arbitrage
|Selling One June Future
Selling One September Future
Buying Two December Futures
Exchanges lists spreads as a single tradable instrument. Many traders wish to control their own definition of the spread. This is particularly true for traders trying to exploit statistical arbitrage.
Trading (custom) spreads takes a couple of transactions. Minimally two orders will have to be placed. The transaction pattern typically looks like the following:
- Determine price of first contract
- Determine price of second contract
- If price difference is acceptable then proceed
- Send order(s) for the first contract
- Wait for fill(s)
- Calculate target price for second contract
- Send order(s) for the second contract
- Wait for fill(s)
- Calculate price difference between 1st contract and 2nd contract.
- Evaluate target spread price verses the realized spread price.
Latency is the measurement of how long a financial transaction takes to happen. There are several important latency steps in spread trading.
Market Data Latency
The exchange publishes market data as soon as possible. They publish it from their data center. Latency in market data is from the time that the exchange publishes the data to the time that the computer receiving the market data is able to interpret the market data information.
Order Processing Latency
Order processing latency begins from the time that a decision is made to the time that the exchange receives the order. This includes the pre-trade risk checks that are required by the regulator or exchange. It also includes the creation of the log file entry required by regulations.
Why Latency Matters
Numerous articles indicate that the markets are largely populated by computer algorithms. These algorithms are run by larger financial firms that have invested in low latency solutions. Orders sent from traders to the market are disadvantaged by algorithms that have lower “tick-to-trade” latency. Those algorithms get the best prices first.
In spread trading the latency of the second order is especially important. The second order has a target price that must be filled. Failure to fill the second order at the target price may result in the trade being “legged out” (having an unhedged position.)
The Edge Financial Technologies Solution
Edge has built multiple trading systems, including algorithmic frameworks, exchange gateways, and market data plants many specifically for low latency traders.
We used some of our experience and some of our components to build a custom solution.
We utilized custom built servers with Solarflare network cards utilizing kernal by-pass technology, with solid state hard drives, and with engineered memory to optimize spread trading. These high performance servers were co-located at the CME’s Aurora data center.
We utilized linux operating systems optimized for trading with unnecessary services removed from the system to reduce contention.
We utilized the Edge Multi-legged spreader as a starting component. Enhancements were made to this high performance, multi-threaded application to specifically improve the tick-to-trade performance on spread trading. Regulatory requirements were fully met using the Edge Trading System pre-trade risk software and the CME market gateways. All server software was written in C++.
The client (trader GUI) software was customized in Java utilizing the Edge Trading System components so that the trader is always aware of his or her open orders, position, and status of all components.
The experience of the senior application designers who fully understand trading applications and hardware allowed the the client to have success in the launch of their new trading system.
The spread trading system, deployed in 2016, has a tick-to-trade speed under 50 microseconds. As a result, the client has further rolled out this application to more futures traders needing low latency. Trading profits on spread trading increased significantly.