What Is CME iLink?¶
CME iLink is the CME Group's official order entry protocol - used by trading systems to submit, modify, and cancel orders directly into the CME Globex matching engine. It forms the backbone of CME's direct market access (DMA) for futures and options trading.
Note
Since 2025 CME iLink solely supports iLink3 Simple Binary Encoding for communication.
How to use CME iLink and What is Required?¶
To connect to CME iLink and submit orders, the following components are required:
-
Physical or Network Access to CME Aurora DC3
Your trading server must be either:
- Co-located within Aurora DC3, or
- Cross-connected to it via an approved network provider.
-
Certified Trading Application
Your software must:
- Support iLink3 Protocol
- Handle session-level messages (logon, logout, heartbeat)
- Pass CME's iLink3 certification process
-
iLink Session Credentials (assigned via CME Portal)
For each session, CME provides:
Session ID
- unique identifier for the connectionFirm ID
- identifies the trading firmSource IP and Port
- used for outbound messages to CMEDestination IP and Port
- used to receive inbound messages from CME
Info
Check out Nanoconda iLink documentation for more information on how to configure an iLink session, with your credentials.
Each iLink session is tied to a specific Market Segment Gateway (MSGW) or Convenience Gateway (CGW) and must be pre-registered accordingly.
CME iLink archetecture¶
CME maintains 19 Market Segments, each mapped to a dedicated matching engine that handles a subset of instruments (e.g. equities, treasuries, metals, energy).
Each segment is associated with a Market Segment Gateway (MSGW).
There are two ways to route order entry:
-
Convenience Gateway (CGW): One TCP connection, routes to all segments (higher latency)
-
Market Segment Gateway (MSGW): Direct connection to the matching engine of the segment - lowest latency
CME Architecture Diagram¶
Flow chart
stateDiagram-v2
CGW_Customer: CGW Customer
MSGW_1_Customer: MSGW 1 Customer
MSGW_1: MSGW 1
MSGW_2: MSGW 2
MSGW_N: MSGW N
MATCHING_ENGINE_1: Matching Engine 1
MATCHING_ENGINE_2: Matching Engine 2
MATCHING_ENGINE_3: Matching Engine N
CGW_Customer --> CGW
CGW --> MSGW_1
CGW --> MSGW_2
CGW --> MSGW_N
MSGW_1 --> MATCHING_ENGINE_1
MSGW_2 --> MATCHING_ENGINE_2
MSGW_N --> MATCHING_ENGINE_3
MSGW_1_Customer --> MSGW_1
CME Order Entry Service Gateway¶
Each iLink message must include administrative fields that identify the originator (e.g., firm, account, operator). These can be supplied in one of two ways:
1. Pre-Registered Administrative Information (Recommended)¶
For the most latency-efficient message construction, administrative fields are pre-registered with CME through the Order Entry Service Gateway, which is updated weekly.
- Once registered, CME returns a
PartyDetailsDefinitionID
(an integer ID) - This ID is then included in each order message instead of full identifiers
- This reduces message size and parsing time at the exchange
Requirements:¶
- Full iLink certification is required to enable this functionality
- Registration must include all relevant party roles
Common Pre-Registered PartyDetailRoles:¶
Tag 1693 Role | Description |
---|---|
96 | Take-up Firm |
1000 | Take-up Account |
1 | Executing Firm |
118 | Operator (human user ID) |
2. On-Demand Administrative Information¶
Alternatively, administrative fields can be included explicitly in every message, without pre-registration.
- This method is more flexible but increases message size and latency
- Suitable for testing or dynamic account routing scenarios
CME CGW vs MSGW - Latency and Routing¶
Gateway Type | Access | Latency | Monthly Minimums | Inactivity Charge |
---|---|---|---|---|
CGW | All segments via one connection | ~ 60μs overhead | 100 Sides | $100 |
MSGW | Per-segment dedicated connection | Lowest latency | 1000 Sides | $1000 |
More information: 📄 CME iLink Session Policy
What Is the Most Latency-Efficient Setup?¶
For latency-critical trading (e.g., market making, arbitrage), the ideal setup is:
- Use MSGW, not CGW
- Run your application on a co-located server inside CME Aurora DC3
- Avoid unnecessary network hops - your algo, risk checks, and order flow logic should run directly on the same box that connects to CME
- Use low latency software that supports pre-trade risk, such NanoConda API with sub-microsecond rount-trip times, which enables:
- Real-time risk checks without trips to a separate server
- Shared memory access to GUI or algo components
- Direct interaction with iLink TX and RX queues
- Real-time trading oversight for both internal teams and FCMs
This architecture provides the lowest possible wire-to-wire latency from market data to order entry.
Conclusion¶
While CME iLink3 may appear complex at first, it becomes straightforward with the right setup and guidance. Once your sessions are provisioned, your application is certified, and the architecture is in place, the system is highly predictable and efficient.
Most of the complexity lies in the initial configuration - selecting the right gateway, pre-registering party details, and aligning with CME's infrastructure. With a reliable partner that understands iLink, market segments, and low-latency integration, the process becomes much easier.
If your goal is to trade on CME with confidence and speed, the right technical foundation - and the right partner - can get you there quickly.