iLink 3 Binary Order Entry - Business Layer

Owned by
CME Group
Last updated: yesterday at 4:16 PM
21 min read

iLink 3 allows customers to optimize business message construction by pre-registering administrative information, or by submitting administrative information per message (on-demand) as follows. 

  • Pre-registered administrative information
    • for most efficient business messaging (i.e., New Order Single, Mass Quote), customers pre-register administrative information in the new Service Gateway weekly.
Full iLink 3 certification is required for customers to add this pre-registered administrative information functionality into their systems.
  • On-demand administrative information
    • customers send the administrative information to MSGW with every business message.

iLink 3 business messages always include a reference to the pre-registered or on-demand administrative information.

Administrative information includes: 

  • Information required to accept and match the order on the central limit order book 
    • tag 2362-SelfMatchPreventionID 
    • tag 8000-SelfMatchPreventionInstruction 
  • Information required to clear the trade 
    • tag 1031-CustOrdHandlIngInst
    • tag 1731-AveragePriceGroupID 
    • tag 819-AveragePriceIndicator 
    • tag 1598-ClearingTradePrice
    • tag 9708-CmtaGiveUpCD 

    • tag 5149-Memo 

  • Information required for market regulation compliance 
    • tag 1693-PartyDetailRole=96 (take up firm)
    • tag 1693-PartyDetailRole=1000 (take up account)
    • tag 1693-PartyDetailRole=1 (executing firm)
    • tag 1693-PartyDetailRole=118 (operator) - identifies the person responsible for the party detail information
    • tag 1693-PartyDetailRole=24 (customer account)
    • tag 582-CustOrderCapacity
    • tag 1816-ClearingAccountType

All fields may not be applicable to all messages; for example, Customer Account does not apply to messages such as Request For Quote.

Contents

Order Entry Service Gateway

There will be a new Order Entry Service Gateway (OESGW) for customers to register administrative information.

For the OESGW:

  • No new session will be required; customers can use the same MSGW session to connect.
  • The Service Gateway supports FIXP Party Detail Request messages only; any other messages will be rejected.

Customers will be able to use the same MSGW session to connect to the Service Gateway using FIXP protocol, and submit Party Details Definition Request messages and Party Details List Request messages.

OESGW - SFTP Site Information 

The OESGW configuration information (i.e. market segments and IPs) will be added to the MSGW config file via an SFTP site (sftpng.cmegroup.com) and accessed via a CME Globex network direct connection. This SFTP site contains the configuration files for all environments. The SFTP site is a secure site that requires a user name and password for access.

New Market Segment is defined for each OESGW  as follows:

Market Segment ID

OESGW

Market

6Globex OESGW for all CGWsFutures and Options
8EBS Order Entry Service Gateway for all CGWsEBS
12Order Entry Service GatewayFutures & Options
14BTEC US Order Entry Service GatewayBrokerTec US
16BTEC EU Order Entry Service GatewayBrokerTec EU
18EBS Order Entry Service Gateway for New York MSGWEBS FX Spot and Metals
20EBS Order Entry Service Gateway for London MSGWEBS FX Spot and NDFs

Information applies as follows in the table:

  • Environment - specific environment (i.e. Certification, New Release, Production).

   Note: the AutoCert+ tool will use the NR MSGW config file.

  • Service - the Configuration service.
  • SFTP Site - address of SFTP site.
  • User Name - identifies the user name.
  • Password - identifies the password.
  • Directory Location - identifies the directory.
  • Client System Update Schedule - Client systems should download updates according to the schedule specified.
EnvironmentsServiceSFTP SiteUser NamePasswordDirectoryClient System Update Schedule

Production

Configuration

sftpng.cmegroup.com

cmeconfig

G3t(0nnect3d


/MSGW/Production/Configuration


daily


Certification

/MSGW/Cert/Configuration


daily

New Release Certification

/MSGW/NRCert/Configuration

daily

In addition to the generic User Name/Password, client systems can connect using the same credential currently used for CME SFTP site. Additional information pertaining to the CME Secure SFTP site is available in CME Clearing Advisory Notice 15-105.

Party Details

Party details will consist of administrative information to facilitate business message processing.

Party Detail Role

The Parties block allows many different types of entities to be expressed through use of the PartyDetailRole <1693> field and identifies the Parties reference data through the PartyDetailID <1691>. 

This table lists all the relevant Party Roles that will be used in the Party Detail messages:

  • PartyDetailsDefinitionRequest 
  • PartyDetailsDefinitionRequestAck 
  • PartyDetailsListReport 

Party Detail Role

Description

1Executing Firm
24Customer Account
96Take Up Firm
118Operator
1000Take Up Account

Party Details Definition Messaging

This section describes message processing for customers pre-registering administrative information. 

Party Details Definition Request

The new Party Details Definition Request message (tag 35-MsgType=CX) defines all customer administrative information i.e. clearing instructions, order source, self match parameters, etc.  The Party Details Definition Request message can be sent  to both Service Gateway and MSGW.   

Pre-register administrative information in the new Service Gateway

  • Customer sends Party Details Definition Request to the new Service Gateway beforehand (recommend beginning of the week on Sunday) with unique value in Party Details List RequestID (duplicate values will be rejected for that FirmID).
    • Party Detail Definitions are valid only for the week and must be resubmitted at the start of each week on Sunday.
    • Customer assigns tag 1505-PartyDetailsListRequestID when submitting the Party Details Definition Request message to CME.
      • A single tag 1505-PartyDetailsListRequestID is able to use across all  MSGW instances.
      • Tag 1505-PartyDetailsListRequestID cannot be equal to 0 when pre-registering administrative information on the Service Gateway.
    • Modification and Deletion of existing Party Details Definition messages are not allowed.
  • Customer receives Party Details Definition Request Ack Message (tag 35-MsgType=CY) and can cross-reference tag 1505-PartyDetailsListRequestID in any subsequent business message sent to MSGW.
    • Any business message sent with an unknown or invalid tag 1505-PartyDetailsList RequestID will be rejected.
    • There will be a limit of 2500 Party Detail Definition combinations allowed for each FirmID beyond which further submissions will be rejected.

On-demand administrative information to MSGW

  • If the customer opts not to pre-register their administrative information, they MUST send a Party Details Definition Request message directly preceding each business message.
  • The Party Details Definition Request MUST have tag 1505-PartyDetailsListRequestID=0, else it will be rejected.
  • Deletions of Party Details Definition messages are not available since they are for single use only.
  • There will be no limit on the number of Party Detail Definition combinations allowed for each FirmID.

With on-demand administrative information, the Party Detail Definition Request message sent directly preceding each business message will be counted towards the messaging thresholds. More information on iLink 3 Messaging Controls is available in the Client Systems Wiki.

Scenario

Messages sent from Client Systems to MSGW

Message Count toward the Messaging Threshold

Pre-registered Messaging

New Order

1

On-demand Messaging

PartyDetailsDefinitionRequest + New Order

2

Example -  Customers submit orders to MSGW:

When the customer submits Good ‘Till Cancel (GTC) and/or Good ‘Till Date (GTD) orders using the pre-registered administrative information, CME Globex will respond with: 

  • the Execution Report - Confirmation/Acknowledgment (tag 35 - MsgType=8) for the current week.
  • the Party Details Definition Request Acknowledgment message before every Execution Report - Confirmation/Acknowledgment (tag 35 - MsgType=8) for the following weeks.

This is applied to Order Status Request and Mass Order Status Request for GTC/GTD orders as well. 

For example: 

Week1 

  • Customer sends GTC orders using the pre-registered administrative information with tag 1505-PartyDetailsListRequestID=1 for Account=123
  • CME returns ExecutionReport - New Order with tag 1505-PartyDetailsListRequestID=1

Week2 

  • Customer sends Party Details Definition Request to the new Service Gateway with tag 1505-PartyDetailsList RequestID=1 for Account = 456
  • CME returns the subsequent fill: Party Details Definition Request Ack with tag 1505-PartyDetailsListRequestID=0 + ExecutionReport - Trade with tag 1505-PartyDetailsListRequestID=0 

For unsolicited quote cancels:

CME Globex will return the Party Details Definition Request Acknowledgment message with tag 1505-PartyDetailsListRequestID=0 before every Quote Cancel Acknowledgment message (tag 35-MsgType = b, tag 297-QuoteStatus = 1,3,4,100).

This is applied to unsolicited cancels from CME One (tag 378-ExecRestatementReason=105). 

For the New Order Cross: 

Pre-registered party information – Client registers party information in the Service Gateway in advance; in the New Order Cross message, the client identifies the party detail ID for each side in tag 1505-PartyDetailsListReqID.

On-demand party information – to submit a Cross, send the following messages to the MSGW:

The New Order Cross message will not be sent to the trading engine until the second Party Details Definition is processed by the Market Segment Gateway.

Party Details Message Sequence

The process for pre-registering administrative information in the new Service Gateway and submitting business messages to MSGW is shown below.

On-Demand Messaging Scenarios

For non–pre-registered clients, message processing follows the sequence shown in the following scenarios.

On Demand - Accepted

In this scenario the Party Details Request message is submitted and accepted prior to the New Order - Single message is submitted and accepted. Upon acceptance of the New Order -Single message, CME Globex sends the Party Definition Request Acknowledgment then the Execution Report - New Order messages.

On-Demand Party Details Request Accepted, New Order Rejected

In this scenario the Party Details Request message is accepted but the subsequent New Order -Single rejected with a Business Reject message.

On-Demand Party Details Definition Request - Message Out of Sequence

In this scenario the Party Details Definition Request is submitted with a higher than expected sequence number.

On-Demand New Order - Invalid Party Details ID

In this scenario a New Order message is submitted with the PartyDetailListReqID not equal to zero.

Pre-Registered Messaging Scenarios

Pre-Registered Party Details Definition Request - Message Out of Sequence

In this scenario the Party Details Definition Request is submitted with a higher than expected sequence number.

Pre-Registered New Order - Invalid Party Details ID

In this scenario a New Order message is submitted with the PartyDetailListReqID not equal to zero.

Party Details List Request

The new Party Details List Request message (tag 35-MsgType=CF) is used to request all of the Party Details Definition information for a particular Firm ID.

  • Party Details List Request message should be sent only to the Service Gateway.
  • Party Details List Request message can be used to request all Party Details Definitions for a firm or specific Party Details Definitions belonging to that firm 
  • Customers can submit a Party Details List Request message and receive the Party Details List Report message (tag 35-MsgType=CG) detailing active Party Detail Definitions.
  • The Party Details List Request message should be used in these circumstances:
    • To confirm submission of Party Details Definition messages sent earlier to the Service Gateway. This can be done:
      • Sunday at the beginning of the week before the start of trading but after Party Details Definition messages have been sent earlier in the day
      • Before the start of each trading session
      • After the close of each trading session
      • Anytime there is a need to confirm which Party Details Definitions have been registered with CME
  • There are two types of the Party Details List request:
    1.  by Executing Firm - Request all Party Details for a single firm using tag 1657- NoRequestingPartyIDs repeating group
    2.  by PartyID - Request specific Party Details  using tag 453-NoPartyIDs repeating group

Customers can submit a Party Details List Request message either by Executing Firm or PartyID. Both types cannot be presented in the same Party Details List request message.

Drop Copy message payloads will have full details of both administrative and business information regardless if the party details were pre-registered or sent prior to the business message, e.g. New Order Single, Order Cancel Replace Request, etc.

Each Party Details List RequestID will be unique per firm. If a firm is hosted on more than one session, the same Party Details List Request ID can be used across all sessions.

For Example: Executing Firm="123" is hosted both Session ID = "ABC" and  Session  ID = "XYZ".  PartyDetailsListRequestID = "1001", created by session ABC,  can be used on both sessions.

All tags in Party Details Definition may not be applicable to all messages; for example:

  • tag 2362-SelfMatchPreventionID is not applicable for cross orders, and account number is not applicable for Mass Quote Cancels
  • tag 8000-SelfMatchPreventionInstruction does not apply for Mass Quote 

Restrictions

Because Party Details are associated with the CME Globex Firm ID (GFID) and not individual sessions:

  • A GFID cannot support duplicate Party Detail ID  (i.e. tag 1505-PartyDetailsListRequestID)
  • GFIDs that share a session cannot use the same Party Detail ID (i.e. tag 1505-PartyDetailsListRequestID)

iLink 3 Order Types and Order Type Qualifiers

For iLink 3 order entry, the following order types and order type qualifiers are supported:

Order Types (tag 40-OrderType)

  • OrderType=1 (Market order with protection)
  • OrderType=2 (Limit order)
  • OrderType=3 (Stop order with protection)
  • OrderType=4 (Stop limit order)
  • OrderType=K (Market limit order)

Order Type Qualifiers

Time In Force (tag 59-TimeInForce)

  • TimeInForce=0 (Day)
  • TimeInForce=1 (GTC)
  • TimeInForce=3 (FAK)
  • TimeInForce=6 (GTD)

Minimum Quantity (tag 110-MinQty)

Used in combination with tag 59-TimeInForce=3 (FAK) as the minimum quantity for immediate execution.

Display Quantity (tag 1138-DisplayQty)

Display quantity for the order to show on the order book at any given time. When the quantity of the order shown on the book reaches zero, the quantity will be reinstated as this value at the bottom of the order book until the entire quantity is filled.

Detailed information on supported order types and qualifiers is available in iLink Order Management.

The iLink 3 Order Entry Application layer, entails the business transaction functionality provided by CME Globex. For more information about the business functionality, refer to iLink 2 Order Entry - Business Layer.

A resting display quantity order (tag 1138-DisplayQuantity >0) cannot be modified to a non-display quantity (tag 1138-DisplayQuantity=0), and vice versa.

iLink 3 Messaging Impacts

All iLink 3 business messages must contain tag 1505-PartyDetailsListRequestID.

Messaging Changes for iLink 3

Changes from iLink 2 to iLink 3 messages include:

  • No Standard FIX header and Trailer
    • Header tag 50-SenderSubID is replaced with new tag 5392-SenderID
    • Header tag 57-TaregetSubID is replaced with new tag 5392-SenderID
    • Header tag 142-SenderLocationID is replaced with new tag 9537-Location 
    • Header tag 143-TargetLocationID is replaced with new tag 9537-Location 
    • Tag 39006-Session ID is used only when Negotiating/Establishing the TCP connection
    • No market segment ID specified
  • Tag 9726-SequenceNumber is referred to in FIXP messages as NextSeqNo
    • To facilitate sequence number gap detection of messages from CME, the following FIXP tags will be added to the outbound messages:
      • Tag 39001-CurrentUUID
      • Tag 39015 -PreviousUUID
      • Tag 39021-PreviousSequenceNo

PreviousUUID and PreviousSeqNo are not the last UUID and last SeqNo sent by the Client System to CME Globex. They refer to the last UUID and last SeqNo sent by CME Globex to Client System.

  • Tag 52-SendingTime, timestamp at the time of message processing, is now user defined field; i.e. tag 5297-SendingTimeEpoch
  • Tag 60-TransactTime will be expressed as nanoseconds since epoch time
    • Tag 5979-RequestTime is replaced with tag 60-TransactTime on outbound messages from CME Globex to Client System 
    • Tag 60-TransactTime is deprecated from inbound messages from Client System to CME Globex 
  • Tag 9717-CorrelationCIOrdID is deprecated
    • Tag 2422-OrderRequestID will be leveraged to tie back responses to requests
    • Tag 11-ClOrdID is to be used only as an entity identifier of an order in so that customers could provide their own order ID but not as a message identifier
      • Tag 11 value can remain the same through the life of an order
  • Tag 107-SecurityDesc is replaced with tag 48-SecurityID for instrument identification
  • Fields related to clearing instructions, account number, account type, self match prevention, etc. have been moved to the Party Details Definition Request message
    • tag 1693-PartyDetailRole=96 (take up firm)
    • tag 1693-PartyDetailRole=1000 (take up account)
    • tag 1693-PartyDetailRole=1 (executing firm)
    • tag 1693-PartyDetailRole=118 (operator) identifies the person responsible for the party detail information
    • tag 1693-PartyDetailRole=24 (customer account)
    • tag 582-CustOrderCapacity
    • tag 1816-ClearingAccountType
    • tag 2362-SelfMatchPreventionID 
    • tag 8000-SelfMatchPreventionInstruction 
    • tag 1031-CustOrdHandlInstruction 
    • tag 1731-AveragePriceGroupID 
    • tag 819-AveragePriceIndicator 
    • tag 1598-ClearingTradePrice
    • tag 9708-CmtaGiveUpCD 

    • tag 5149-Memo 

Good ‘Till Cancel (GTC) and Good ‘Till Date (GTD) orders

When iLink 2 sessions migrate to iLink 3 sessions,  Good ‘Till Cancel (GTC) and Good ‘Till Date (GTD) orders on the migrated market segments will reflect the following messaging changes:

  • CME will return the Party Details Definition Request Acknowledgment message with tag 1505-PartyDetailsListRequestID=0 before every Execution Report - Confirmation/Acknowledgment (tag 35 - MsgType=8)
  • For iLink 3 Application messages from CME Globex to Client System,
    • tag 2422 - OrderRequestID will be set to 0
    • tag 9537-Location will contain the truncated 5 bytes from the right of iLink 2 tag 142-SenderLocationID from the GT order
    • tag 527-SecondaryExecId and tag 1506-SideTradeID will contain Trade Number  on tag 17-ExecID, except the spread leg trade execution.  To enable client systems to link the spread instrument with each component leg, Execution Report - Trade Spread Leg will contain the same tag 527 value as  Execution Report - Trade Spread

For example, a calendar spread trade: 6BM7-6BJ7

iLink 3 Execution Report -Trade

Tag 17

Tag 527- SecondaryExecId

Tag 1506- SideTradeID

Spread: 6BM7-6BJ7


5081:M:45601TN0000007

7

7

Spread Leg 1: 6BM7

5081:M:45601TN0000014

7

14

Spread Leg 2: 6BJ7

5081:M:45601TN0000025

7

25

  •  The following iLink 2 tags will be deprecated and will not be present on iLink 3 outbound messages
    • tag 20-ExecTransType
    • tag 41-OrigClOrdID
    • tag-50-SenderSubID contains Market Segment ID.
    • tag 55-Symbol
    • tag 107-SecurityDesc
    • tag 167-SecurityType
    • tag 819-AveragePriceIndicator
    • tag 1731-AveragePriceGroupID
    • tag 9717- CorrelationClOrdID

Order Cancel and Cancel-Replace Requests by ClOrdID

Order Cancel and Cancel-Replace Requests by ClOrdID is a risk management feature that allows clients to cancel and modify resting orders using FIX tag 11-ClOrdID without providing tag 37-OrderID.

Order Cancel and Cancel/Replace Requests by ClOrdID functionality is only available for iLink 3 sessions. However, iLink 2 sessions are also impacted. Please see iLink - Rejects for Tag 11-ClOrdID Uniqueness for details.

As a reminder, CME Group strongly recommends that clients do not change the ClOrdID value on a working order to prevent unexpected results on regulatory, support, and order status tools.

All iLink 3 sessions for futures, options on futures, and EBS Market on CME Globex sessions are enabled for Order Cancel and Cancel/Replace by ClOrdID functionality.

Clients intending to use this feature must complete an AutoCert+ certification before using the functionality.

Rejects for ClOrdID (tag 11) Uniqueness

To support order cancellation and order modification by tag 11-CIOrdID, this value must be unique per SenderComp (Session ID + Firm ID) for all working orders on a single market segment.

For an iLink 3 New Order tag 11-ClOrdID:

  • CME Globex will reject an order having the same ClOrdID and SenderComp as a currently working order on the given market segment. A duplicate ClOrdID will generate an iLink 3 Business Reject (tag 35-MsgType=j) message with tag 380-BusinessRejectReason = 133 and tag 58-Text = Duplicate ClOrdID: X not allowed.

A ClOrdID value can be re-used on the same Market Segment only when the prior order is no longer resting, for instance:

  • the prior order has been completely filled, or
  • the prior order has been cancelled, or
  • the prior order has been eliminated.

Processing for ClOrdID and OrderID Values

Effective with iLink 3 schema v8, FIX tag 37-OrderID is an optional tag in iLink 3 Order Cancel Request and iLink 3 Order Cancel/Replace Request messages for CME Group Futures and Options on Futures markets.

  • If an Order Cancel Request or Order Cancel Replace Request contains both CIOrdID and OrderID, then the OrderID will be used to look up the original order.
  • If a ClOrdID in an Order Cancel Request or Order Cancel/Replace Request is changed from what was in the original order,
    • the client should send an Order Cancel Request or Order Cancel/Replace Request with the latest CIOrdID accepted by CME Globex.
    • the client sending an Order Cancel Request or Order Cancel/Replace Request with the previous CIOrdID must provide an OrderID as well; otherwise, the Order Cancel/Replace Request will be rejected as order not found.
  • An Execution Report - Cancel and Execution Report - Modify message will return both ClOrdID and OrderID values.
  • An Order Cancel Reject and Order Cancel Replace Reject message will return both ClOrdID and OrderID values.

Summary of FIX Tag Changes from iLink 2 to iLink 3

This table shows iLink 2 tags that have been migrated and deprecated for inbound and outbound messages.

From Client System to CME Globex:

iLink 2
iLink 3
Inbound

tag 50-SenderSubID

Convert





tag 5392-SenderID
tag 142-SenderLocationIDtag 9537-Location
tag 52-SendingTimetag 5297-SendingTimeEpoch

tag 34-MsgSeqNum

tag 9726-SequenceNumber
tag 210-MaxShowtag 1138-DisplayQty
tag 55-Symboltag 1151-SecurityGroup
tag 9707-GiveUp Firm

Moved to:

Party Details Definition Request














tag 1693-PartyDetailRole=96 (take up firm)
tag 79-AllocAccounttag 1693-PartyDetailRole=1000 (take up account)

tag 49-SenderCompID (i.e. Firm ID)

tag 1693-PartyDetailRole=1 (executing firm)

tag 1-Account

tag 9771-MMAccount

tag 1693-PartyDetailRole=24 (customer account)
tag 9702-CTICodetag 582-CustOrderCapacity
tag 204-CustomerOrFirmtag 1816-ClearingAccountType
tag 7928-SelfMatchPreventionIDtag 2362-SelfMatchPreventionID
tag 8000-SelfMatchPreventionInstruction
tag 1031-CustOrdHandlInstruction
tag 1731-AveragePriceGroupID
tag 819-AveragePriceIndicator

tag 1598-ClearingTradePrice


tag 9708-CumtaGiveUpCD
tag 5149-Memo
n/atag 1693-PartyDetailRole=118 (operator)
tag 21-HandInstDelete

Deprecated

tag 78-NoAllocs
tag 60-TransactTime
tag 107-SecurityDesc
tag 9717-CorrelationCIOrdID

From CME Globex to Client System:

iLink 2
iLink 3
Outbound

tag 57-TargetSubIDConvert





tag 5392-SenderID
tag 143-TargetLocationIDtag 9537-Location
tag 52-SendingTimetag 5297-SendingTimeEpoch
tag 5979-RequestTime

tag 60-TransactTime

Note - the following application messages will continue to use tag 5979:

tag 34-MsgSeqNum

tag 9726-SequenceNumber
tag 210-MaxShowtag 1138-DisplayQty
tag 55-Symboltag 1151-SecurityGroup
tag 5904-DelayDurationtag 7552-DelayToTime
tag 79-AllocAccount

Moved to:

Party Details Definition Request Acknowledgment














tag 1693-PartyDetailRole=1000 (take up account)

tag 56-SenderCompID (i.e. Firm ID)

tag 1693-PartyDetailRole=1 (executing firm)

tag 1-Account

tag 9771-MMAccount

tag 1693-PartyDetailRole=24 (customer account)
tag 7928-SelfMatchPreventionIDtag 2362-SelfMatchPreventionID
tag 8000-SelfMatchPreventionInstruction
tag 1031-CustOrdHandlInstruction
tag 1731-AveragePriceGroupID
tag 819-AveragePriceIndicator

tag 1598-ClearingTradePrice


tag 5149-Memo
n/atag 1693-PartyDetailRole=118 (operator)
n/atag 1693-PartyDetailRole=96 (take up firm)
n/atag 9708-CumtaGiveUpCD
n/atag 582-CustOrderCapacity
n/atag 1816-ClearingAccountType
tag 6-AvgPxDelete




Deprecated




tag 20-ExecTransType
tag 78-NoAllocs
tag 107-SecurityDesc
tag 337-ContraTrader
tag 375-ContraBroker
tag 442-MultiLegReportingType
tag 9717-CorrelationCIOrdID
All fields may not be applicable to all messages for example tag 8000-SelfMatchPreventionInstruction may or may not be used on a particular order.

Application Messages

All iLink application messages always include a reference to the registered or pre-submitted administrative information (i.e. Party Details List Request ID).

The iLink 3 Order Entry Application layer, entails the business transaction functionality provided by CME Globex. For more information about the business functionality, refer to iLink 2 Order Entry - Business Layer.

From Client System to CME Globex

Only the following iLink 3 application messages may be sent to CME Globex:

Message Name Message Level ChangesGateway

New Order Single

Sent by customers wishing to enter an order in the system; the behavior of an order can be affected by many parameters such as order type and validity.MSGW
iLink 3 Order Cancel Replace Request

Sent by a customer wishing to replace an existing order in the system; an order is typically modified a number of times during its life-cycle with the caution that various order characteristics (e.g. priority) behave differently with regard to modification.

  • Some characteristics cannot be modified such as: Side, OFM (Once Set) and Instrument.
  • Others can be altered subject to market rules such as: Price (Limit and Stop Limit), Stop Trigger Price, Quantity, account, PartyDetailListRequestID, etc.
MSGW
iLink 3 Order Cancel Request 

Sent by a customer wishing to cancel an existing order in the system; an order may be cancelled by referencing the Order ID.

MSGW
iLink 3 Mass Quote

Authorized  market makers use Mass Quoting to submit bid/ask pairs and generate two-sided markets for multiple options instruments.

Remove repeating group tag 296-NoQuoteSets.

Add repeating group tag 295-NoQuoteEntries:

  • Tag 132-BidPx
  • Tag 133-OfferPx
  • Tag 299-QuoteEntryID
  • Tag 48-SecurityID
  • Tag 134-BidSize
  • Tag 135-OfferSize
  • Tag 309-UnderlyingSecurityID
  • Tag 302-QuoteSetID
MSGW

Quote Cancel Message

The Quote Cancel message is used by a market maker to cancel all quotes or a partial set of quotes submitted during a specific session:

  • Cancel all active quotes
    • Cancel all active quotes for a Product Group
      • Cancel individual quotes for an instrument
      • Cancel all active quotes for a Quote Set per side
      • Quote Cancel messages are processed upon receipt by CME regardless of whether the corresponding resting quotes are completely or partially filled

Add repeating group tag 296-NoQuoteEntries:

  • Tag 134-BidSize
  • Tag 135-OfferSize
  • Tag 302-QuoteSetID

Update repeating group tag 295-NoQuoteEntries:

  • Tag 48-SecurityID  is used for instrument identification, no tag 107-SecurityDesc used
  • Tag 55-Symbol is replaced with tag 1151-SecurityGroup align with MDP 3.0
MSGW
iLink 3 Order Status Request

The message is submitted by clients to obtain the current status of a specific order:

  • CME returns the order status in an Execution Report with status indicated in tag 39-OrdStatus field
    • New tag 790-OrdStatusReqID added to correlate Order Status Request with response
      • Deprecated the use of tag 11-CIOrdID and tag 9717-CorrelationCIOrdID for order status
    • Tag 37-OrderID is used for order identification; no tag 107-SecurityDesc and tag 167-SecurityType used
      • If tag 37 is not available, then Order Mass Status Request can be leveraged

Minimum set of required fields for order status;  no need to send all of the order fields again such as :

  • Tag 54-Side
  • Tag 48-SecurityID
MSGW
iLink 3 Order Mass Action Request

An Order Mass Action Request is sent by customers to cancel working orders for a given Executing Firm.

  • Customers can request the cancellation of all of the remaining quantity of a group of orders matching criteria specified within the request.
    • This message can only be used to cancel orders and is not applicable to Mass Quotes.
      • The scope of the mass cancel will be restricted to all orders for a particular market segment ID.
      • Tag 55-Symbol is replaced with tag 1151-SecurityGroup to align with MDP 3.0  for cancelling by product group.
      • Tag 48-SecurityID  is used for instrument identification, no tag 107-SecurityDesc used.
      • New tag 2422-OrderRequestID added to correlate Order Mass Action Request with Order Mass Action Report instead of tag 11-CIOrdID.
MSGW
iLink 3 Order Mass Status Request

The Order Mass Status Request message requests the status for orders matching criteria specified within the request.

  • A Mass Status Request is assigned a Mass Status Request ID and is treated as a separate identifier.
    • Tag 55-Symbol is replaced with tag 1151-SecurityGroup align with MDP 3.0.
    • Tag 37-OrderID is used for order identification; no tag 107-SecurityDesc used.
MSGW
iLink 3 New Order Cross

The cross order contains two order sides (buy and sell), each containing information about that side, including buyer, seller and ClOrdID field.

  • Each side is called a leg of the cross order.
  • The cross order is identified by the tag 548-CrossID.
MSGW
iLink 3 Request for Quote

Customers who wish to trade an instrument for which the order book is blank or stale can request a quote to create the book using a quote request message.

  • An accepted quote request is acknowledged with a quote acknowledgment and disseminated to the market with the market data quote request message.
  • Once the market data quote request message is disseminated, market makers can respond with a mass quote message and market participants can submit a new order message to populate the book.

Tag 9943-QuoteType is deprecated.

MSGW
iLink 3 Security Definition Request

User-Defined Spreads provide users the ability to create spreads composed of their choice of leg instruments, leg ratio, and leg side.

New tags:

  • Tag 916-StartDate
  • Tag 917-EndDate
  • Tag 37714-MoneyOrPar
  • Tag 37715-MaxNoOfSubstitutions
  • Tag 541-MaturityDate

Update repeating group tag 555-NoLegs:

  • Add tag 602-LegSecurityID is used for spread leg identification
  • Remove tag 600-NoLegSymbol, tag 608-LegCFICode, and tag 620-LegSecurityDesc 

New repeating group tag 711-NoUnderlyings:

  • Tag 458-NoUnderlyingAltID
  • Tag 459-NoUnderlyingAltIDSource
MSGW
iLink 3 Party Details Definition Request

The Party Details Definition Request message (35=CX) is used to define all of the customer administrative information; e.g. clearing instructions, order source, self match parameters, etc.

SGW / MSGW
iLink 3 Party Details List Request

The Party Details List Request message (35=CF) is used to request all of the PartyDetailsDefinition information for a particular firm ID.

Only one Party Details List Request is allowed at a time and the earlier one must be processed completely before a later request is allowed.

SGW
iLink 3 Execution AcknowledgmentThe Execution Report Acknowledgment message is an optional message that provides dual functionality to notify CME that an electronically received execution has either been accepted or rejected.MSGW

From CME Globex to Client System

Only the following iLink application messages will be received from CME Globex:

Message NameMessage Level ChangesGateway
iLink 3 Business Reject 

The Business Message Reject message notifies customers a message has failed application-level business validation.

Business Reject message will be used in these scenarios:

  • Rejection of incoming message due to:
    • Blocked trading due to Kill Switch Activation
    • Blocked trading due to Risk Management API 
    • Restricted from trading Deliverable Swap Futures
    • Restricted from trading Interest Rate Swaps
    • Blocked trading due to CME Globex Credit Controls
    • Blocked trading due to Inline Credit Controls
    • Exceeding Volume Control thresholds
    • Failure to decode message
  • Rejection of incoming message due to invalid SecurityID
  • Rejection of incoming message due to invalid PartyDetailsListReqID
  • FIX field of the wrong type (sending a STRING for an INTEGER field, for example)
  • Tag value is all spaces
  • Missing required fields
  • Using invalid combination of fields such as:
    • Missing expire date tag for GTD orders
    • Including expire date tag on non-GTD orders
    • Using FAK/FOK with iceberg orders
    • Using FAK/FOK with stop orders
    • Including price (tag 44) with market orders
    • Missing stop price (tag 99) on stop orders
    • Including stop price (tag 99) on non-stop orders
    • Iceberg quantity greater than total quantity
    • Minimum quantity greater than total quantity
    • Order quantity greater than total quantity
MSGW
Execution Report - New

Execution Report - New is sent in response to New Order Single as well as activation of stop orders.

Tag 2422-OrderRequestID is used to tie responses to requests.

Execution Report - New message does not contain these fields:

  • Tag 6-AvgPx
  • Tag 14-CumQty
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
  • Tag 151-LeavesQty 
MSGW
iLink 3 Execution Report - Modify

Execution Report - Modify message is sent in response to Order Cancel Replace Request.

  • Modification order will be represented by tag 39-OrderStatus = 5 and tag 150-ExecType 150=5.
  • Tag 2422-OrderRequestID  is used to tie back responses to requests.

Execution Report - Modify message does not contain these fields:

  • Tag 6-AvgPx
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
MSGW
iLink 3 Execution Report - Cancel

Execution Report - Cancel message is sent in response to Order Cancel Request as well as to report unsolicited cancellation of orders due to:

  • Market Operations
  • Cancel On Disconnect
  • Self-Match Prevention
  • CME Globex Credit Controls
  • Risk Management API
  • CME One

Tag 2422-OrderRequestID is used to tie back responses to request.

Execution Report - New message does not contain these fields:

  • Tag 6-AvgPx
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
  • Tag 151-LeavesQty 
MSGW
iLink 3 Execution Report - Status

Execution Report - Status message is sent in response to Order Status Request or Order Mass Status Request.

  • Tag 790-OrdStatusReqID is used to correlate Order Status Request with response.

To make the exchange FIX compliant, now current state of the order will be represented by tag 39-OrderStatus and the specific type of event will be represented in tag 150-ExecType.

  • Order status response will be 39=0, 1, 2, 4, 5, C and 8 and 150=I.

Execution Report - Status message does not contain these fields:

  • Tag 6-AvgPx
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
MSGW
iLink 3 Execution Report - Trade Outright 

The Execution Report - Trade (Outright/Spread/Leg) messages are sent upon fill or partial fill of client order:

  • Fill Execution Report only for outright, spread, and spread leg instruments.

To make the exchange FIX compliant, now current state of the order will be represented by tag 39-OrderStatus and the specific type of event will be represented in tag 150-ExecType.

  • Fill message will contain 39=1 or 2 and 150=F.
  • Trade number now in its separate field called tag 1506-SideTradeID instead of embedding in tag 17-ExecID.

Execution Report - Trade (Outright/Spread/Leg) messages  does not contain these fields:

  • Tag 6-AvgPx
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
  • Tag 337-ContraTrader 
  • Tag 375-ContraBroker
  • Tag 442-MultiLegReportingType 

Execution Report - Trade Spread Leg message does not contain these fields:

  • Tag 38-OrderQuantity 
  • Tag 44-Price 
  • Tag 59-TimeInForce 
  • Tag 99-Stop Price 
  • Tag 110-MinQty 
  • Tag 151-LeavesQty
  • Tag 548-CrossID
  • Tag 549-CrossType
  • Tag 1057 AggressorIndicator 
  • Tag 1138-DisplayQty
  • Tag 2422-OrderRequestID 
  • Tag 37711-MDTradeEntryID
MSGW
iLink 3 Execution Report - Trade Spread MSGW
iLink 3 Execution Report - Trade Spread Leg MSGW
iLink 3 Execution Report - Elimination

The Execution Report - Elimination message is sent at order elimination.

Execution Report - Elimination message does not contain these fields.

  • Tag 6-AvgPx
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
  • Tag 151-LeavesQty
MSGW
iLink 3 Execution Report - Reject

The Execution Report - Reject message notifies client system of rejected order.

  • Tag 2422-OrderRequestID  is used to tie back responses to requests.

Execution Report - Reject message does not contain these fields:

  • Tag 6-AvgPx
  • Tag 14-CumQty
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
  • Tag 151-LeavesQty
MSGW
iLink 3 Execution Report - Trade Addendum Outright

The Execution Report - Trade Addendum (Outright/Spread/Leg) message notifies client system of trade cancellation or correction for outright, spread, and leg.

  • Trade number in separate tag 1506-SideTradeID.
  • For Trade Cancel:
    • iLink 2 tag 19-ExecRefID, replaced with iLink 3 tag 1506-SideTradeID.
    • Client systems can use tag 48-SecurityID and tag 527-SecondaryExecID to correlate between Trade Execution Report and Trade Cancellation Execution Reports.
  • For Trade Correction:
    • iLink 2 tag 19-ExecRefID replaced with iLink 3 tag 1507-OrigSideTradeID.
    • Client can use tag 48-SecurityID and tag 1507-OriginalSideTradeID in Trade Adjustment Execution Reports to reference back to the original tag 48-SecurityID and tag 1506-SideTradeID in Trade Execution Report for each outright, spread, and spread leg trade. (See example below.)

Example:


Spread Trade Event

Spread Trade Correction


17

5271506

17

52715061507

ExecID

SecExecIDSideTradeID

ExecID

SecExecIDSideTradeIDOriginalSideTradeID
ZTM4-ZTU4 sell17=98101:M:691TN00000022217=98101:M:694TN0000003332
ZTM4 sell leg 117=98101:M:692TN00000042417=98101:M:696TN0000005354
ZTU4 buy leg 217=98101:M:693TN0000003,2317=98101:M:697TN0000004343
ZTM4-ZTU4 buy17=98101:M:688TN00000022217=98101:M:695TN0000003332
ZTM4 buy leg 117=98101:M:689TN0000004,2417=98101:M:698TN0000005354
ZTU4 sell leg 217=98101:M:690TN0000003,2317=98101:M:699TN0000004343
  • Tag 32-LastQty value will be the quantity of canceled trade.

Execution Report - Trade Addendum Outright/Spread/Legs message does not contain these fields:

  • Tag 6-AvgPx
  • Tag 20-TransType
  • Tag 41-OrigClOrdID
  • Tag 14-CumulativeQty 
  • Tag 38-OrderQuantity 
  • Tag 110-MinQty 
  • Tag 1138-DisplayQty 
  • Tag 40-OrderType
  • Tag 44-Price 
  • Tag 99-StopPrice 
  • Tag 59-TimeInForce 
  • Tag 151-LeavesQuantity 
  • Tag 2422-OrderRequestID 
  • Tag 432-ExpireDate  
  • Tag 1057-AggressorIndicator 

Execution Report - Trade Addendum Spread Leg does not contain these fields: 

  • Tag 810-UnderlyingPx
  • Tag 811-PriceDelta
  • Tag 1188-Volatility
  • Tag 1189-TimeToExpiration
  • Tag 1190-RiskFreeRate
  • Tag 337-ContraTrader 
  • Tag 375-ContraBroker
  • Tag 432-ExpireDate 
  • Tag 442-MultiLegReportingType 
  • Tag 548-CrossID 
  • Tag 549-CrossType 
  • Tag 961-HostCrossID
  • Tag 1028-ManualOrderIndicator
  • Tag 37711-MDTradeEntryID
MSGW
iLink 3 Execution Report - Trade Addendum SpreadMSGW

iLink 3 Execution Report - Trade Addendum Spread Leg

MSGW

iLink 3 Order Cancel Reject

The Order Cancel Reject message is issued upon receipt of a cancel request message, which cannot be honored, and a rejected cancellation will generate an Order Cancel Reject message.

  • Tag 2422-OrderRequestID is used to tie back responses to requests.

State of the cancel/modification will be represented by tag 39-OrderStatus & tag 434-CxlRejResponseTo:

  • Rejection of cancel will be tag 39=U & tag 434=1
  • Rejection of modification will be tag 39=U & tag 434 =2

Execution Report - Order Cancel  and Cancel Replace Reject messages do not contain does not contain tag 41-OrigCIOrdID.

MSGW

iLink 3 Order Cancel Replace Reject

MSGW
iLink 3 Security Definition Response

This message is sent in response to an attempt to create a new security definition.

The Security Definition message is used for the following:

  • Accept the security defined in a Security Definition Request message
  • Accept the security defined in a Security Definition Request message with changes to the definition and/or identity of the security
  • Reject the security requested in a Security Definition Request message

Tag 602-LegSecurityID is used for spread leg identification.

The following tags are no longer being used:

  • Tag 600-NoLegSymbol
  • Tag 620-LegSecurityDesc
  • Tag 608-LegCFICode 
  • Tag 612-LegStrikePrice
  • Tag 610-LegMaturityMonthYear
  • Tag 942-LegStrikeCurrency
MSGW

iLink 3 Mass Quote Acknowledgment

The Mass Quote Acknowledgment message is used as the response to a Mass Quote to notify customers of accepted and rejected quotes.

The Mass Quote Acknowledgment message contains the number of successfully processed quotes and a list of rejected quotes identified by tag 299-QuoteEntryID.

Only one quote set allowed per message to avoid nested repeating groups—this means that quote set itself is not represented as a repeating group.

MSGW

iLink 3 Request for Quote Acknowledgment

Request for Quote Ack message is used in response to a Request for Quote message to either accept it or reject it.

MSGW

iLink 3 Quote Cancel Acknowledgment

Quote Cancel Ack message is used in response to a Quote Cancel message to either accept it or reject it.

For quote eliminations, customers will receive the Party Details Definition Request Acknowledgment message before the Quote Cancel Acknowledgment message regardless of whether they were sent in using the pre-registered or on-demand administrative information.

  • Party Details Definition Request Ack with tag 1505-PartyDetailListRequestID=0 + Quote Cancel Ack
MSGW

iLink 3 Order Mass Action Report

An Order Mass Action Report is used to acknowledge an Order Mass Action Request and is sent by CME back to the customer since it is meant to verify that CME has successfully received and processed the Order Mass Action Request.MSGW

iLink 3 Party Details Definition Request Acknowledgment

Used to respond to the Party Details Definition Request message indicating whether the request has been accepted.

  • Rejects will be communicated using the Business Reject.

The Party Details Definition Request Acknowledgment message will be sent by CME via:

  • New Service Gateway for pre-registering administrative information 
  • MSGW for On-demand administrative information

Only one party update allowed per message to avoid nested repeating groups.

Customer and Account classification fields will be included to facilitate risk management functions via Drop Copy:

  • Tag 582-CustOrderCapacity 
  • Tag 1816-ClearingAccountType 
  • Tag 1693-PartyDetailRole=96 (take up firm)
  • Tag 1693-PartyDetailRole=1000 (take up account)

Also depending upon the type of message the amount of information contained in the Party Details Definition Request Acknowledgment could vary; for example:

  • On-demand Business Reject: the Party Details Definition Request Acknowledgment that is sent with Business Reject has the least amount of information; i.e. only the Executing Firm PartyDetailRole and Memo will be present.
  • On-demand Execution Report: the Party Details Definition Request Acknowledgment that is being sent with Execution Report has a lot more information but it will still not be complete and will be missing fields such as CustOrderCapacity, ClearingAccountType, CmtaGiveUpCD, and Take-Up Firm PartyDetailRole.
  • On-Demand Order Cancel Reject/Order Cancel Replace Reject: the Party Details Definition Request Acknowledgment that is being sent with Order Cancel Reject/Order Cancel Replace Reject: has only some information present and other fields will not be present; for example Executing Firm, Customer Account and Take-Up Account PartyDetailRole, Memo and CustOrderHandlingInst will be present.

Tag 1691-PartyDetaiID values on the following Party Detail Roles will be truncated  to the required length from the right:

TAG 1693 - PARTY DETAIL ROLE  REQUIRED LENGTH
24 (customer account)12
1000 (take up account)11
96 (take up firm)3


SGW/MSGW

iLink 3 Party Details List Report

Used to replay all of the Party Details Definition information such as clearing instructions, order source, self match parameters, etc., for a particular firm ID.

Each Party Details Definition will be returned as a separate Party Details List Report message.

  • Tag 1512-TotNoParties will indicate the total number of Party Details List Report messages being returned.
  • Tag 893-LastFragment will indicate when the last Party Details List Report message has been sent

Tag 1691-PartyDetaiID values on the following Party Detail Roles will be truncated  to the required length from the right:

TAG 1693 - PARTY DETAIL ROLE  REQUIRED LENGTH
24 (customer account)12
1000 (take up account)11
96 (take up firm)3
SGW

Order Request Identifier

Tag 2422-OrderRequestID will serve as a Request message identifier. Customer can use tag 2422 to identify a request to enter, modify, or delete an order. CME Gobex will echo this value on the corresponding Execution Report.

Scenario 1 - Cancel/Replace Accepted the Fill

This example shows the behavior of tag 2422-OrderRequestID in a scenario where Client System 2 submits an Order Cancel Replace Request and the modified order matches.

Scenario 2 - Cancel/Replace Rejected then Fill

This example shows the behavior of tag 2422-OrderRequestID in a scenario where Client System 2 submits an Order Cancel Replace Request that is rejected and the original order matches.



How was your Client Systems Wiki Experience? Submit Feedback

Copyright © 2024 CME Group Inc. All rights reserved.