Understanding Order Management
Order Server Data Flow
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 Feed connection from the Order Server on the BrokerTec Gateway to the Exchange.
- The Order Server starts up and creates the Order Server log file.
- The Order Server queries hostinfo.cfg for all connectivity information (i.e., connection IP address, user names, password, etc.).
- Trader logs into X_TRADER® and submits an order.
- The Order Server assigns an order key,
- The Order Server writes the order information to the Order Server log file. The order is then submitted to the first available TTO unless that TT Order Key has already been sent to a TTO via a previous order.
- The TTO verifies that the order is a supported order type and that the price it has is valid. If the order is supported and is valid, the TTO sends the order to the Exchange.
- The Exchange receives the order and sends a confirmation to the TTO. The confirmation contains the order number.
- The TTO writes the order number to the Order Server log file.
- The Order Server sends an Ok/Add to the Audit Trail, publishes order data to the Order Book and writes the order information to the Order Server log file.
Fill Server Data Flow
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 Exchange matches the order and sends fill data with the assigned order number to the TTF on the BrokerTec Gateway.
- The TTF validates the fill against the Order Book in RAM
memory and notifies the client of trades that occurred in the marketplace.
The client is notified through BD1 messages and BD6 messages. A
BD1 message is immediate, but is a preliminary unconfirmed message.
A BD6 messages carries definitive summary information regarding
the trades that were executed. The following activities outline
the process by which these messages are sent and received:
- For every transaction that occurs during a workup a BD1 message is received. At the conclusion of workup, a BD6 message is received summarizing the activity of the workup for each trader.
- For every BD1 that is received a fill is generated and sent out. These fills are partitioned and stored per trader. When the BD6 message arrives, the BD1 messages contained in the summary are collected and sent out as confirmed fills.
- If a BD6 message arrives before all of its constituent BD1 messages, the BD6 message is stored until sufficient BD1 messages arrive. When sufficient BD1 messages populate the BD6 message, then the BD1 messages are sent out as confirmed.
- If a BD1 message has not been confirmed it is stored to a file, so that it can be retrieved. In the instance of an Order Server going down, the stored BD1s are sent out when the BD6s are queried upon the next startup.
- In the event that a BD1 message is missed, or if the corresponding BD6 message does not have enough BD1 messages to satisfy being sent, it does not wait to be sent. After a set amount of time, a makeup fill is generated from the BD6, until the quantity is fully resolved. These makeup fills, lacking information from the order, are made up only of information that is stored at the Exchange and lack the correct account information.
- The TTF sends the fill to the Fill Server and the Order Server.
- The Order Server sends an Ok/Fill to the Audit Trail.
- The Fill Server writes the fill data to the bof.tbl file.
- The Fill Server sends the fill data to the Fill Window.