To trade EBS products on the CME Globex platform customers must implement the order entry functionality described in iLink 3 Binary Order Entry, and, if applicable, the market data functionality described in MDP 3.0. Customers with this functionality in place can refer to the EBS-specific functionality described in this topic. 

Contents

...

• The New York and London regions each support both MSGW and CGW, while the Tokyo location only supports CGW

• The New York and London CGWs route orders to either New York or London

• The Tokyo CGW routes orders to either New York or London

Both EBS CGW and MSGW sessions use the iLink 3 messaging protocol.

EBS Market

EBS Market includes Central Limit Order Book (CLOB) and eFix Matching.

Order Entry Service Gateway

...

• If arriving order is a Good For Session order, and does not fully trade, the remaining quantity will rest on the book at the same price level as the resting order(s). Market data will reflect the crossed book. 
• Clients can configure as many Self-Match Prevention IDs as desired. SMP IDs may be shared across GFIDs only if the GFIDs are part of the same Institutional Group.
• Tag 8000-SelfMatchPreventionInstruction are not supported for EBS SMP.
  • if populated on EBS orders, CME Globex will ignore the value in tag 8000.

...

EBS on CME Globex supports reporting of the liquidity provision indicator via tag 9373-LiquidityFlag in the following Application messages.

...

• If the MQL timer has not expired:
  • CME Globex will queue any order cancels and acknowledge a cancel request with a iLink 3 Execution Report Pending Cancel (tag 39=6 and tag 150=6), and cancel the order at the end of the MQL time limit.
  • CME Globex will queue any order modify requests and acknowledge the modify request with a iLink 3 Execution Report Pending Replace Message (tag 39=E and tag 150=E) and replace the order at the end of the MQL time limit.
  • Pending Execution Reports are not exposed on market data.
• A Pending Cancel Request is always prioritized over a Pending Cancel/Replace Request.
• Cancel on Disconnect (CoD) and Cancel on Conclusion (CoC) can supersede the MQL interval and cancel the resting order with tag 35-MsgType=8 & tag 39-OrdStatus=4 message including tag 378-ExecRestatementReason=100 to indicate CoD/CoC.
  • A Pending Cancel or Pending Cancel/Replace will be rejected with an Order Cancel Replace Reject (tag 35-MsgType=9) message including tag 102-CxlRejReason=2045 and tag 58-Text=<This order is not in the book 'Order: XXX SenderCompID: XXX'>, once the MQL interval is over.

...

Latency Floor functionality is only applicable to EBS Market and all products listed on EBS Market utilize this functionality. The Latency Floor enables broader trading participation and moderates unwanted executions by prioritizing order cancel processing before aggressing order matching. 

For a video overview see Image AddedWatch the Latency Floor: Batching Process in video module within the EBS Market Order Entry video.

With Latency Floor, when an EBS Market order arrives to the MSGW, it is batched with any other orders that have arrived within the same batch window. Each order is assigned to an Institutional Group queue within the Latency Floor batch. The Institutional Group queues are released in random order. The orders within each queue are released in FIFO priority. All Order Cancel messages will be prioritized and released first, in FIFO priority before the institution rows are processed. All remaining orders are then released in a round-robin style (i.e. the first order from the first row is released, the first order from the second row is released, and so on for all rows, then the second order from the first row is released, the second order from the second row is released, and so on until all orders are released).

Latency Floor Examples

Scenario 1 - New Order and Order Cancel within the same Latency Floor (currency pair does not support MQL)

...

• Tag 60-TransactTimerepresents the time when MSGW releases the message from the Latency Floor.
• Tag 7552-DelayToTimeindicates the amount of time that a message was subject to additional processing as a result of Latency Floor.
  • Subtracting this number from tag 60-TransactTime will represent the original received time of in-flight message.

eFix Matching

Orders for e-FIX instruments will be sent as a Good For Session (GFS) limit orders with price = 0 and executed at the fixing price with two Execution Report - Trade Outright messages having different ExecID (tag 17) values. 

...