Try TT Now

Understanding ETI Order Management

Overview

The Eurex Enhanced Trading Interface (ETI) is a session-oriented order management interface. Members (participants) receive information on orders, quotes, and executions entered in their own session. Unique, exchange-provided routing session IDs are required for trading via ETI.The Eurex Gateway connects to the new trading platform through connection gateways and application gateways that host sessions. A Eurex ETI session may be shared by several participants belonging to the same business unit. Traders may login to the new trading architecture via all sessions belonging to their business unit.

ETI Order Server Logon

At start-up, the Order Server on the Eurex Gateway establishes a TCP/IP connection to ETI as part of a three-step logon process:

  • Request assigned application gateway: The Order Server opens a TCP/IP session to the Eurex Connection Gateway (IP and port numbers provided by exchange), and requests a primary and secondary application gateway IP address.
  • Session logon: Once the TCP/IP connection is established, the Order Server initiates a connection to the exchange for each configured session. Each ETI session is hosted by an application gateway at an Access Point within the Eurex network. The Access Points provide connectivity to the Eurex exchange host and matching engine.
  • Trader logon: The Order Server requests user (trader) authentication from the exchange based on the exchange-provided User ID. The User ID is mapped to the Operator ID downloaded from TT User Setup for each trader MGT. The Order Server uses the Operator ID (User ID) to log in traders and route orders to the exchange via ETI.

ETI Sessions

The ETI (Enhanced Trading Interface) introduces three different types of sessions:

  • low-frequency (LF)
  • low-frequency full (LF full)
  • high-frequency (HF)
  • high-frequency light (HF light)
Note

To operate, the Eurex Gateway needs at least one low-frequency session for each exchange membership configured on the gateway.

Both of the high-frequency sessions only support Lean order types (refer to Lean Orders). These sessions also have a higher throughput and are designed specifically for automated trading. HF sessions do not have any recoverability mechanism in place for orders or fills. For example, after a session disconnect, it is not possible to inquire or replay the missed executions through an HF session. GTD orders are most likely routed through HF sessions.

Low Frequency sessions support lean, non-persistent, and persistent orders. LF sessions have a much lower throughput as compared to HF sessions, and allow all orders and fills to be recovered across a participant's ETI sessions. However, low-frequency full (LF full) sessions support up to 150 TPS vs. 50 TPS for low-frequency sessions (LF).

If an ETI session gets disconnected, the Order Server will delete all working non-persistent orders for that session based on how the users of that session are configured in TT User Setup.

All exchange-supported order types can be routed through LF sessions; HF sessions only support GTD orders.

Transaction Limit

Eurex defines transaction per second limits on high-frequency, high-frequency light, and low-frequency sessions. When the limits are exceeded, the exchange disconnects the session and sends a message to the gateway, which writes the message to the Order Server logs and forwards it to X_TRADER. Traders can view the message in the Audit Trail.

The limit for an HF session is 150 TPS. For LF sessions and HF Light sessions, the limit is 50 TPS. For LF full sessions, the limit is 150 TPS.

Lean Orders

Overview

Eurex added the “lean order” attribute for ETI as a way to improve throughput and reduce latency for high-frequency trading. When an order is flagged as “lean” by the Eurex Gateway and routed to the exchange, Eurex processes the order without persisting order event messages or broadcasting the messages to all listening ETI sessions.

Lean Order Routing

Users do not specify whether an order is lean or standard (non-lean). The gateway sets the lean order flag based on the Time-in-Force order qualifier submitted by the client trading application in conjunction with the TT User Setup configuration of the user. By default, the gateway flags all GTD orders as lean orders, and flags all GTC/GTDate orders as standard orders.

Lean orders are routed through both LF and HF sessions. An HF session only routes lean orders, which are not available via the exchange GUI. An LF session routes both lean and standard orders, but lean orders may be processed slower on LF sessions as compared to lean order processing on HF sessions. For more information about how the gateway routes orders for ETI, refer to Gateway Order Routing .

Lean Orders, Standard Orders, and Order Persistence

By default, the gateway sends all lean orders as “non-persistent” (all standard orders are flagged as “persistent”). GTD orders are always flagged as lean and non-persistent by the Eurex Gateway unless the user submitting the order is configured in TT User Setup to send all orders as persistent. In this case, the gateway flags the GTD order as “standard” and “persistent” and routes it via an LF session.

The gateway does not flag any orders as “standard and non-persistent” or “lean and persistent” as these are not supported by the exchange for ETI. Persistent standard orders will appear in the Exchange GUI.

The exchange deletes all lean (i.e., all non-persistent) orders in the event of a session disconnect regardless of the reason: exchange host failure, network outage, exchange event, or normal gateway shutdown. For more details about how the gateway handles order persistence, refer to Persistent and Non-Persistent Order Types: ETI.

Gateway Order Routing

The following table shows the default gateway behavior for routing orders flagged as lean, standard, persistent, and non-persistent for ETI.

ETI Order Routing
Order Submitted by ClientFlagged by the Eurex Gateway as...Routed via LF SessionsRouted via HF SessionsVisible in Exchange GUI
LeanStandardPersistentNon-Persistent
GTDxxx (if no HF sessions are configured)x
GTCxxxx
GTDatexxxx
GTD (Persist) x xx x
Notes:
  • Each order submitted by the client trading application has a Time in Force (TIF) qualifier of GTD, GTC, or GTDate.
  • Based on the TIF qualifier, the Eurex Gateway flags the order as either “lean” or “standard”.
  • Based on the lean/standard flag, the Eurex Gateway sets the “persistent” or “non-persistent” flag. The gateway only flags lean orders as “non-persistent”.
  • An LF session routes both lean and standard orders, but lean orders may be processed slower on LF sessions as compared to lean order processing on HF sessions.
  • An HF session only routes lean orders.
  • Orders flagged by the gateway as “lean” are not available via the exchange GUI.
  • The gateway does not flag any orders as “standard and non-persistent” or “lean and persistent” as these are not supported by the exchange for ETI.
  • GTD orders submitted by a user with order persistence configured in TT User Setup are flagged as “standard” persistent orders by the gateway and routed through LF sessions only.

Load balancing of HF and LF sessions is dependent on your trading style and volume. To route orders among the different sessions, the gateway uses round-robin order routing. For more information about configuring the gateway for round-robin order routing, refer to Configuring Round- Robin Order Routing.

GTC/GTDate Order Routing

GTC and GTDate orders only route through an LF session by default. If there are more than one LF session configured, the Eurex Gateway will use the round-robin approach to order routing, which means it will route to the session with the fewest working orders and pending requests. There is no dependency on the order of the sessions configured in hostinfo.cfg.

GTD Order Routing

GTD (day) orders can route through both LF and HF sessions. When the Eurex Gateway routes a GTD order and there are HF and LF sessions configured, the gateway uses round-robin order routing for the HF sessions only. That is, it will route the GTD through the HF session with the fewest working orders or pending requests. An LF session will not be selected unless it is the only session configured on the Eurex Gateway.

Trade Book Files

The Order Server uses the *_*_mode_fills.tbl file located in <root drive>:ttdatfiles to help manage and track all fills that the host sends to the Eurex Gateway. The filename contains the Session ID or Session Name provided by the exchange. The Order Server reads this file to memory and updates it whenever fills are received. The rest of this manual refers to this file as the fills.tbl file.

The Fill Server uses the *_*_mode_bof.tbl file located in <root drive>:ttdatfiles to record all fills sent to the Eurex Gateway and their status. The rest of this manual refers to this file as the bof.tbl file.

For detailed information on how the Eurex Gateway uses these files to reconstruct the Trade Book during disaster recovery, refer to Gateway Software Recovery.

X_TRADER® uses the Trade Book files to populate its Fill window whenever it connects to the Eurex Gateway.

Order Book Files

To manage ETI order data, the Order Server creates an Eurex_sessions.dat file in the <root drive>:ttdatfiles directory.

This Order Book file stores all orders and their associated status. This file stores each order action (i.e., adds, deletes, etc.) as they occur. When the Order Server restarts, the Gateway trims the Order Book file by removing any completed order transactions.

Order Book Sharing

In an ETI session, two traders from the same group can share an order book and act on each other’s orders, e.g., ABCDE M 1 and ABCDE M 2. To share an order book using ETI sessions, both of the traders have to be set up as head traders. The configuration of the users should be updated as needed through the Eurex Admin GUI.

Passwords used on the current sysytem need to be re-created for ETI, as they will expire upon the first login to the GUI. According to Eurex, the default configuration of all users after the migration to T7 will be “head trader”.

API Mapping to X_TRADER® and Eurex Admin/Trader GUI

Traders can view order and trade status in their client trading application (e.g., X_TRADER) or the Eurex Admin GUI regardless of which one was used to enter the order action via the Eurex Gateway. The following table shows how order and account information in X_TRADER and the Eurex Admin GUI or Eurex Trader GUI is mapped to the Eurex exchange API for orders entered through the Enhanced Trading Interface (ETI).

Eurex Admin/Trader GUI and X_TRADER Mapping to the ETI API
Eurex Admin/Trader GUI FieldX_TRADER FieldExchange API Field for ETI

Text1

FFT3

TT FFT3 or “Free Text”

Text2

Account#TT Account# or “Exchange Clearing Account”

Text3

FFT2

TT FFT2 or “Exchange Sub Account”

Account Types-CTI/Origin Codes

The Eurex Gateway maps only natively supported Account Codes, and will reject any orders placed with an unsupported account (e.g. U1). The Eurex Gateway maps the following Account Code values which are not configurable.

Account Codes: Eurex Gateway
Account Type CodeAccount TypeActivity

A1-A9

Agent accounts

Clients only

G1

Pre-designated Give-Up

Without the member ID of the receiving Clearing Member

G2

Designated Give-Up

With the member ID of the receiving Clearing Member

P1, P2

Proprietary

Own account

M1, M2

Market Maker

Quotes

Note

Detailed account structure information can be found on the Eurex website at http://www.eurexchange.com/trading/market_model/account_structure_en.html http://www.eurexchange.com/trading/market_model/account_structure_en.html