Understanding Order Management

Overview

The Order Server connects to the CBOEdirect FIX 2.0 platform. CFE Gateway 7.18 and higher supports the Bats Binary Order Entry (BOE) and Bats FIX protocols.

CFE Gateway 7.18

The following list summarizes CFE Gateway 7.18 Order Server functionality to support CFE Bats:

  • The Order Server uses the FIX protocol for order entry.
  • The GIVEUP field is used for the CMTA number, which is populated in FIX Tag 439.
  • The FFT3 field is used for the “SubAccount” and is populated in Fix Tag 440.
  • If configured in Hostinfo, FFT4 will be used for “SubAccount” instead of FFT3 for customers. If there is no configuration in Hostinfo, FFT3 will be used to populate the "SubAccount."
  • The FFT2 field is used for OnBehalfOfCompID (EFID) and will populate Fix Tag 115. This a mandatory field for order routing.
  • All CFE order types will be supported by the new CFE platform. The permitted order types in the new CFE platform are:
    • Stop Limit Orders
    • Market/Limit Orders
    • DAY
    • GTC
    • IOC
    • FOK
    • Spread Orders
  • The CFE will reset sequence numbers daily, between 4:00 pm and 4:45 pm Central time.
  • Order Entry Operator ID/ ATS Operator ID (tag 25004) and Manual Order indicator ((Tag 1028) will both be required fields.
    • If Manual order indicator (Tag 1028)=Y, then Use TTUS field Operator ID to populate Tag 25004
    • If Manual order indicator (Tag 1028)=N, then use Exchange-2 field ATS Op ID to populate Tag 25004
  • Matched Trade Prevention instructions will be an order-by-order basis. Tag 7928 will be used to populate the instruction.  The user has to enter one letter for each category (3rd category is optional). For example: NF1, OMa, BF, etc.
    • Match Trade prevention has 3 characters
      • 1st character - MTP Modifier
        • N=Cancel Newest
        • O=Cancel Oldest
        • B=Cancel Both
      • 2nd character - Unique ID level
        • F=Prevent Match at CFE Exchange TPH level
        • M=Prevent Match EFID Level
      • 3rd character - Trading Group Level (optional). (TPH Specified alphanumeric level)
  • Spread order entry will be conforming to standard futures pricing.
  • Cancel-Replace/Order update handling will conform to standard FIX handling where an OrderQty delta is calculated and applied to LeavesQty. This leaves the user in total control of contract quantity exposure when the modification request overlaps partial fills for the order.
  • Bandwidth restrictions (orders per second) will be substantially higher, i.e., 3000 msg/sec.
  • Price limits will be in effect during extended trading hours. Orders to buy above the upper limit or to sell below the lower limit will be rejected when the limits are in effect.

Order Server Data Flow

Note

Terminology used in the following data flow matches terminology used in the Gateway System - Logical Architecture diagram. Also, native orders are those orders normally accepted by the exchange's API.

The following is a description of the order connection from the Order Server on the CFE Gateway to the exchange’s trading engine.

  • Upon startup, the Order Server reads any working orders contained in the *_Mode_orders.tbl files into memory.
  • X_TRADER® submits an order to the Order Server.
  • After receipt, the Order Server passes it to the appropriate Order Router.
  • The Order Router assigns a TT Order Number to the order and then updates the Order Book with the new order information. The TT Order Number is not sent to the exchange.
  • The Order Router records the order in its *_Mode_orders.tbl files.
  • The Order Router sends an ACCEPT/Add message to the trader’s Audit Trail (in X_TRADER®).
  • The Order Router sends the order to the CFE host.
  • Upon receipt, the exchange host sends an order confirmation (containing the exchange-provided Trade Number) back to the Order Router.
  • The Order Router updates the Order Book with the exchange’s Trade Numbers to indicate that a confirmation was received, and writes it to its *_Mode_orders.tbl files.
  • The Order Router sends the order confirmation (as an OK/ADD) to the trader’s Audit Trail in X_TRADER®.

Fill Server Data Flow

Note

Terminology used in the following data flow matches terminology used in the Gateway System - Logical Architecture diagram. Also, native orders are those orders normally accepted by the exchange's API.

The Logical Architecture diagram illustrates the following fill flow:

  • The CFE host matches the order.
  • The CFE host sends a fill with an assigned Trade Number (i.e., transaction number) to the Order Router.
  • The Order Router matches the fill to the recorded order in the Order Book and updates the Order Book according to the type of fill received:
    • If the Trade Number for the fill does not match a Trade Number for an order in the Order Book, the Order Router notifies the trader’s and supervisory trader’s Audit Trails that the trader received a fill but that the fill does not match any of the orders in the Order Book. The Order Router then attempts to generate a fill based upon the data received from the exchange.
    • If the fill completes the order, the Order Router removes the order from the Order Book.
    • If the fill does not complete the order (i.e., it is a partial fill), the Order Router updates the Order Book to reflect the partial fill.
  • The Order Router writes order changes to the *_Mode_orders.tbl files and records the fill in its unique fills.tbl file. If counterparty information is available, this is added to the fill record.
    Note

    The Order Server deletes completed orders from its *_Mode_orders.tbl files only when it restarts.

  • Simultaneously, the Order Router:
    • Sends a fill response to X_TRADER®. X_TRADER® displays a fill in the Audit Trail. X_TRADER® updates the relevant files and screens (i.e., if it is a complete fill, the order is removed from the X_TRADER® Order Book).
    • Sends the fill to the Fill Server.
  • X_TRADER® displays the fill in the Fill window.