How exchange trades flow
Before getting into the specifics around the CME, it helps to look at how trade data moves in any exchange environment. A trader uses an Order Management System (OMS) to send a buy or sell order to the exchange. The exchange’s matching engine pairs that order with another trader’s order, which creates a trade.
The trade data then moves to the clearinghouse for risk checks. Once cleared, the data goes to the Futures Clearing Merchant (FCM), which handles margin and fees. Finally, the data becomes available through the CME STP API, where the trading firm’s software collects it and updates the risk system. All of this happens in milliseconds.
The manual alternative still exists, typing in the trade by hand.
A primer on CME Markets
CME trades happen in three ways: on the floor, electronically, or through a mix of both.
- Floor (Open Outcry): Before electronic trading, trades happened face-to-face with shouting and hand signals. Some floor trading still exists, mainly for rates and agricultural products.
- Globex (Electronic Marketplace): CME’s electronic platform. It runs almost around the clock. Trades happen through screen clicks or automated algorithms.
- Clearport: Handles OTC trades that are later sent to CME for clearing. It allows firms to trade outside the exchange but still clear through the same risk process.
After Globex launched in 1992, most of the trading went electronic. Now Globex covers almost everything you can trade on CME, whereas open outcry is limited to rates and agricultural products
CME futures and options are listed across four main exchanges:
- CME: Chicago Mercantile Exchange (FX, Financial Indices)
- CBOT: Chicago Board of Trade (Agriculture)
- NYMEX: New York Mercantile Exchange (Energy)
- COMEX: Commodities Exchange (Metals)
All of these are part of the CME Group. Products can be traded electronically on Globex or OTC through Clearport. OTC trades include types such as block trades, EFS, and EFRP. These happen outside the exchange but are then cleared through CME.
Data as Lego
All this under the hood complexity must mean that data is complex too, right? Nope. Despite all the moving parts, CME data is structured in a clear and consistent way.
When you connect to the STP API, you get organized data that identifies trade types and venues. All trades, whether futures or options, use a standard format. Think of them as identical building blocks that fit together easily. This makes it easier to manage and store trade data, even when traders use complex strategies.
There are two other broad data structures that can come through CME STP. One is for Fixed Income trades via Brokertec. The other is for Bilateral trades that you could ask your broker to send via STP. This way, you can get all your trades through a single pipe. If your company trades these products, you will need to take a step to normalize everything so you can…you guessed it…stack the legos.
Representing data in a standardized way means you can easily handle complexity. Traders can execute a structured strategy trade composed of multiple futures and options, but the data from STP flows with each individual piece of that trade as a single future or option. You can unite them with data, like a common trade ID.
The STP API does allow firms to request a single trade message for complex trades instead of the broken out standard components. Usually, this is because some traders are used to seeing things that way. If you ask your tech teams to follow suit, you can expect delays every time a new lego shape comes through the API, or traders will be asked to only trade the structures that have already been coded for.
It is hard to stack custom lego shapes. Rectangles and circles are your friends.
So the data is straightforward. How about the data plumbing?
Whereas most trade data plumbing runs on the FIX protocol, the STP API is a simple https/REST API with data in an XML message (FIXML to be specific). This is the same kind of modern technology footprint you might use to get records from Salesforce.
Wait…futures trading just got a modern facelift? Kind of. Except we are in a world of large firms i.e. banks, that have invested heavily in the FIX Protocol, which is the only on-ramp they have for ingesting trades to their systems.
So the CME Group fronted STPs REST API with a FIX protocol layer and everyone was happy. However, it is yet another step in the process and adds complexity to workflows. Most of the issues we have seen with home-grown and vendor CME trade feeds comes down to using the FIX layer instead of the simple REST API.
Common Issues and Fixes
Trades arriving as amendments: If you see a trade marked as an amendment the first time, it is likely from an OMS hosted by an FCM. The trade was executed under the broker’s name and later allocated to your firm’s clearing account, hence, the first time you see them, they have an amended status (TransTy = 2).
Duplicate trades: If your system receives multiple identical trades where no data has changed, it may be because the STP API will serve up all exchange and clearinghouse events, if your FCMs have any processes “touching” trade data, or moving between internal accounts, those actions will all generate a message on the STP API.You need controls to prevent duplicates.
Missing or old trades: If you experience technical issues, CME STP allows you to request up to 31 days of trade history. This is really helpful in case of issues or if your tech teams need to test something against real production data.
Parallel feeds: You can make parallel API calls from a test environment using your production credentials.
FCM setup: Your FCM must register your clearing accounts in the CME Account Manager for trades to flow through the STP API.
Learn more about BroadPeak Trade Capture →
