iLink 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.

• On-demand administrative information:

  • Customers send the administrative information to MSGW with every business message.

iLink 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

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:

Information applies as follows in the table:

View SFTP site access details details for this service (CME Group Login required).

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

• 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.

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 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 Acknowledgment 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.

  • Each FirmID has a limit of 2,500 Party Detail Definition combinations. Submissions that exceed this limit will be rejected.

On-demand administrative information to CGW/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 Messaging Controls is available in the Client Systems Wiki.

On-Demand Party Details

Memo

Tag 5149-Memo value on the Party Details Definition Request Acknowledgment (PDDRA, tag 35-MsgType=CY) will reflect the party details from an Order Mass Action Request and from an unsuccessful Order Cancel Request. 

In the case of a successful Order Cancel, the PDDRA will reflect the party details from the resting order and overrides the memo information from the cancel request.

On-Demand Order Cancel Requests

In the event of a successful Order Cancel, the Party Details Definition Request Acknowledgment (PDDRA, tag 35-MsgType=CY) will reflect the party details from the resting order.

On-Demand Order Cancel Replace

In the event of a successful Order Cancel Replace, the Party Details Definition Request Acknowledgment (PDDRA, tag 35-MsgType=CY) will reflect the party details from the order cancel-replace request.

In the case of an Order cancel-replace request with Negative In Flight Mitigation (IFM) scenario, where IFM cancel/replace quantity is less than that of the filled quantity, CME Globex cancels the order. The PDDRA of an unsolicited Order Cancel will reflect the party details from the resting order.

Good Till Cancel(GTC)/Good Till Date(GTD) orders

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 Execution Report - Confirmation/Acknowledgment (tag 35 - MsgType=8) with the pre-registered tag 1505-PartyDetailsListRequestID for the current week.

If GTC/GTD orders remain working across weeks, CME Globex 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 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 Acknowledgment with tag 1505-PartyDetailsListRequestID=0 + ExecutionReport - Trade with tag 1505-PartyDetailsListRequestID=0 

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). 

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:

• iLink Party Details Definition Request for Buy side of cross

• iLink New Order Cross message

• iLink Party Details Definition Request for Sell side of cross

Party Detail Restrictions

Because Party Details are associated with the CME Globex Firm ID (GFID) and not individiLink Order Mass Action Request and from an unsuccessful iLink Order Cancel Request. ual 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)

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 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

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.

Application Messages

The iLink application layer, entails the business transaction functionality provided by CME Globex. For more information about the business functionality, refer to iLink Binary Order Entry - Futures and Options.

All iLink application messages must contain tag 1505-PartyDetailsListRequestID to reference to the registered or pre-submitted administrative information.

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.

Trade Correction Example