The New Order Cross message submits a Cross on CME Globex, a two-sided order submitted by a single party/broker at the same price and quantity.

The → symbol indicates a repeating tag.

Bolded red text indicates support for EBS Market.




Binary Type

Binary Length




Identifier for a cross order. Must be unique during a given trading day.
Use OrderRequestID to identify a request to enter a cross order. Echoed back on the Execution Report.


  • 0=Automated

  • 1=Manual

Indicates if the message was initially received manually.

'0' indicates the message was generated by automated trading logic.

iLink messages containing a value other than '0' or '1' in this tag will be rejected.

This tag is subject to Rule 536.B.2 Electronic Audit Trail Requirements for Electronic Order Routing/Front-End Systems.


Sequence number assigned to this message.

The max value is 999999999 which is 1 short of 1 billion.


For futures and options markets: represents Operator ID.

For EBS and fixed income markets: represents the Entering Trader. For EBS this value must be 3 characters.

This value represents the individual or team submitting the message and is subject to registration requirements and character limits as required by Rule 576 and the Advisory below:

In FirmSoft and Global Command Center queries for order status and cancellations, this value must be exact.
  • OrdType=2 (Limit order)

Only ‘2’ (limit order) supported.

Constant value.

  • CrossType=3

A cross order which is executed on one side with any unfilled quantity remaining active.

Constant value.

  • CrossPrioritization=0 (None)

Indicates if one side of the cross order should be prioritized.

Constant value.

Conditionally required when tag 40-OrdType=2 (Limit).
For derivatives, a timestamp to indicate when this order was booked with the agent prior to submission to the exchange. Indicates the time at which the order was finalized between the buyer and seller prior to submission. Expressed as nanoseconds since epoch time.
Time when the message is sent. 64-bit integer expressing the number of nanoseconds since midnight January 1, 1970.

ISO identifier of the physical location of the individual or team head trader identified by the tag 5392 (SenderID) in the message.

The first two bytes as per ISO 3166-1, identify the country (e.g., JP = Japan, CN = China).

The next three bytes indicate a comma-delimited state or province code (e.g., CA = California, QC = Quebec).

For valid values, refer to

Market Regulation requires only the submission of the two first characters of tag 9537-Location for all countries with the exception of Canada. For Canada, the 5 bytes including the province code must be submitted.

Note: this field is optional for EBS Market and eFIX Matching Service instruments.


Security ID as defined in the market data Security Definition message.

  • minValue=2
  • maxValue=2

Number of Side repeating group instances.

2=Both Sides


Unique identifier for Order as assigned by the buy side (institution, broker, intermediary, etc.). Uniqueness must be guaranteed within a single trading day.

Firms, particularly those which electronically submit multi-day orders, trade globally, or throughout market close periods, should ensure uniqueness across days; for example, by embedding a date within the ClOrdID field.


The unique identifier of the Party Details Definition Request Acknowledgment associated with this message; this is the value submitted on the inbound message.

For pre-registered messages:

  • Party Details Definition Request Ack message would have been sent beforehand and that unique ID should be provided here
  • PartyDetailsListRequestID≠0.

For on-demand messages:

  • If not registered beforehand through iLink then Party Details Definition Request Ack message will be sent along with the business message and will immediately precede it
  • PartyDetailsListRequestID=0.

Order quantity. Must be the same for both sides.

  • Side=1 (Buy)
  • Side=2 (Sell)
Side of order.
  • SideTimeInForce=0 (Day)
  • SideTimeInForce=3 (FAK)
Indicates how long the order as specified in the side stays in effect. SideTimeInForce allows a two-sided cross order to specify order behavior separately for each side.