Tracking Trade Data from an Order to Instant Risk/PnL
Part Two of Five
In this second post in our series of blogs discussing the futures and options trading environment, we look at how to track ICE trade data as it flows from a trader’s buy/sell clicks on screen to the exchange to the trader’s clearing account, the ICE Trade Capture API, and finally the trading company’s risk system.
You can review Part 1 for the distilled checklist on trade data automation, scalability, and regulatory compliance no matter how you execute trades by clicking here.
Must-Have Glossary for Futures Trades
As you read below, refer to the links here for insights on industry jargon:
- Order Management System (OMS) – Software that “screens” traders’ use to interact with the exchange.
- Futures Exchange – Marketplace for trading futures and options. For example, ICE, CME, Nodal, EEX, Eurex, Euronext, and more.
- Clearinghouse – Risk shock absorber for the market in case participants have financial stress.
- Clearing Broker (a.k.a. Futures Clearing Merchant or FCM) – An entity that collects margin from participants on behalf of the clearinghouse. For example, Mizuho, ABN AMRO, Wells Fargo, JP Morgan and others.
- ICE Trade Capture API (TC API) – Technology that allows participants to receive a feed of their trading activity.
- Trading Risk Management system (ETRM, CTRM, TRM) – Enterprise software used by various trading firm groups to manage a trade from start to finish. Examples include Openlink Endur, Triplepoint, Allegro, Molecule, Eka, Brady and countless others.
- Counterparty – The other side of a trade the buyer to the seller or the buyer for the seller.
Unlike the world of retail stocks, futures traders at large companies use one system to execute trades and another to value their trades and manage risk. Those two software systems need to talk to each other.
Between those two systems is a data supply chain of complexity. Below we lay out the types of companies and systems in the supply chain and highlight where you can adjust settings to ensure you receive all your trades on ICE markets.
Let’s start with what it means to “lose” a trade. A trader executes a trade and it doesn’t show up in the risk system.
Depending on whom you ask, the “why” varies.
- Ask a trader and you hear, “I don’t know, it’s something technical. Ask IT.”
- Ask an FCM and they say, “It’s all set up, I am not sure what else could be wrong.”
- Ask an IT person and it’s usually, “I don’t know. The traders are always doing weird things.”
The truth is that it takes a holistic view of the system settings to play air traffic controller for trades in the futures markets. It is complex and evolving.
Here is a general diagram of the Trade Data Supply Chain for futures and options.
Refer back to the glossary above as needed.
The blue circles are technologies being used. The green circles are companies involved.
The trade data supply chain starts when a trader creates an order to buy or sell on their OMS of choice. ICE provides an OMS called WebICE.
When the trader clicks on WebICE an order flows to the exchange’s matching engine. There, buy and sell orders from different companies are matched, resulting in a trade.
Trade data then flows from the exchange to the clearinghouse where risk checks are performed.
Then the trade makes it to the trader’s account at the Futures Clearing Merchant (FCM) who will collect margin and fees from the trader’s firm.
Trade data is finally sent via the ICE Trade Capture API (TC API) to a risk system at the trader’s company.
All this happens in milliseconds.
By the time the trader moves eyes from the OMS to their internal risk system, their position is updated. Ok, truth be told…there can be hiccups in the supply chain.
Everything up to the TC API is part of the exchange’s standard setup. The last mile from the TC API to a company’s risk system varies by company.
This is where the baton is handed to internal tech teams to manage the last mile. And those teams have to handle multiple batons of various shapes and sizes for all the exchanges on which a firm trades. It gets complex quickly.
Companies use software to connect to the TC API and save trade data to their risk systems. Without software, traders manually enter trades into their systems. Yes, this still happens in 2021.
Let’s dive into those hiccups. Some exist around the vanilla scenario we just covered, but largely they stem from complexity with intermediaries in the data supply chain.
Strap in.
1. The OMS
The OMS logs into the exchange and is how a trader sends in buy and sell orders. Traders can use WebICE as above, or they may prefer to use an exchange agnostic OMS like TT or CQG, which are provided by the FCM. This lets a trader access multiple markets with a single screen.
They tend to be a little more fancy in the kinds of functionality they provide traders. With that fancy tech comes a fancy problem. They need serious technical operations and thus are usually run by FCMs as a client service.
Except an FCM-provided OMS will execute trades in the FCM’s name by default.
Later, the FCM will assign or “allocate” the trades to the end trading company. This causes hiccups in the data flows. You can solve them, but like real hiccups, knowledge of folk remedies is required.
PRO TIP:
If your company uses FCM-provided OMSs, mandate that the “sessions into the exchange are established in your trading firm’s name and not in the FCM’s name.
SUPER PRO TIP:
This also benefits your compliance coverage for surveillance and recordkeeping purposes.
2. The FCM
The FCM is the intermediary between the exchange/clearinghouse and trading firms. They do a lot, but here let’s just cover how they are the gatekeeper for trade data flows.
A firm’s trades are segregated into different clearing accounts. The FCM helps manage how trades flow in and out of these accounts.
We already covered how an FCM-hosted OMS requires additional setup so trades go directly into a traders clearing account. This then automates the flow downstream to the TC API.
The same is true for trades that are executed through a broker, as opposed to being traded “on-screen” using an OMS.
Traders looking to buy and sell where there is low activity may go to a broker to find a counterparty. Brokers may also be able to find a better price or trade very large quantities efficiently (block trades).
Brokers first execute in their own name and then “give up” or “allocate” trades to the end trader’s clearing account.
Firms must ask FCMs to enable automation for each broker their traders deal with. When asked which brokers they use, traders will often say something generic like “ICAP”. That’s not enough info here. FCMs need the specific legal entity otherwise everyone will be running in circles.
PRO TIP:
Ask your FCMs to enable allocations in the ICE Credit system for each combination of broker, legal entity, and clearing account.
3. The Tech
So far we’ve mostly discussed settings and checkboxes that are common to any trading participant on ICE. Now let’s cover the tech from the TC API to a company’s risk system.
Assuming a firm already has software in place to enable straight-through processing for ICE trades, there are some additional changes to handle broker-allocated trades.
First, the software must indicate that it would like to start receiving allocation messages with a parameter on logon to the TC API.
Second, the software must be able to handle the flood of messages that will start flowing. Unlike a regular trade, where only a final message is sent, ICE allocations have a workflow where brokers allocate a trade which is then reviewed and finally approved by traders before becoming finalized. These interim states also generate data that is interesting for oversight but not useful in a risk system.
Lastly, software must shape the allocations data to look like a normal listed future.
We’ve talked about this before and won’t repeat it here. Long story short…roll up your sleeves.
Here to Help
Office Hours with Vivek
Sign up now for a complimentary meeting with our ICE trade expert for real-time TRM help.
Vivek Pathak in
Chief Operating Officer
Vivek is the Chief Operating Officer and Founder of BroadPeak Partners. He is the titanium backbone behind BroadPeak’s efficient operations and absolute champion of efficient operations & development. Prior to BroadPeak, Vivek was COO at Barclays and Lehman Brothers where he drove efficiency and PMO for highly complex fixed income, FX and commodity software projects. Mr. Pathak began his career in a Big 5 Consulting firm as a Project Manager and worked with large companies such as AGL, Duke Energy and UBS. He trained as a Chemical Engineer and graduated with a B.Sc from the University of Alberta. Vivek lives in New York City with his wife and 2 children.
