Skip to content

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:

  1. 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.
  2. Certified Trading Application

    Your software must:

    • Support iLink3 Protocol
    • Handle session-level messages (logon, logout, heartbeat)
    • Pass CME's iLink3 certification process
  3. iLink Session Credentials (assigned via CME Portal)

    For each session, CME provides:

    • Session ID - unique identifier for the connection
    • Firm ID - identifies the trading firm
    • Source IP and Port - used for outbound messages to CME
    • Destination 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:

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.