7x to TT FIX Migration (Order Routing)

jeromehayes created · Jun 08, 2017 at 02:42 PM · edited · Jun 08, 2017 at 02:43 PM

This article is a 2 part series that highlights the major changes to migrate your FIX application from the 7x platform to the new TT platform. Below we will highlight the major changes to migrate your 7x order routing feed to the TT order routing service. Also included are brief introductions to new features only available on the TT order routing FIX service that were not available on our 7x platform. The TT order routing service supports FIX version 4.2 but also includes fields introduced in versions 4.3 through 5.0. Links to our messaging spec have been included for detailed usage of highlighted tags and repeating groups. Please see our 7x drop copy migration guide

We have broken down order routing scenarios into 4 discussion topics:

Account and User Information
Exchange Properties
Instrument Identification
New Features

Account and User Information
Exchange-specific account and user properties live in Setup and vary by exchange. Configuring the exchange-specific properties for accounts and users within Setup offers the following benefits for FIX order routing fields that define account/user information:

The ‘parent account’ and ‘child account’ is a tiered account and sub-account hierarchy that allows risk settings be applied at any level.
The account routed to TT in tag 1 will generally in turn be populated in tag 1 to the exchange.
The tag 1 value routed to TT can alternatively be configured within Setup as an internal sub-account where risk is controlled at both the child and the parent account level and orders are routed to the exchange via the parent account. Trading activity and risk can be tracked and managed per sub-account even though these accounts are never routed to the exchange.
For exchanges that require an account in tag 1, admins can also alternatively override the tag 1 value sent to TT by entering a “Clearing Account Override” value in Setup. A FIX client can route a risk checked account in tag 1 to TT but in turn send a separate non-risk checked account to the exchange.

Exchange Properties
The value of tag 1 from the client request will be returned in tag 1 of the execution report. The remainder of the account and user information as well as the configured exchange properties will be populated in our Parties component block repeating group, PartiesGrp. This will normalize the behavior of these tags across all exchanges where the exchange required fields may differ.

Screen Shot 2017-05-31 at 4.30.31 PM.png

Instrument Identification
When sending the instrument component block in a new order single message, you can specify the instrument in any of the following methods below.

Screen Shot 2017-05-31 at 10.32.33 AM.png

TT FIX added support for routing by alternate IDSource [22] values, such as RIC codes; when routing by SecurityID.

Screen Shot 2017-05-31 at 10.33.56 AM.png

TT FIX added a new implementation for routing by a SecurtiyAltID [455] and a SecurityAltIDSource [456]. This format will support multiple symbol sources for identifying the instrument for order submission.

Screen Shot 2017-05-31 at 10.35.28 AM.png

TT FIX also supports routing by Name when supplying the exchange Symbol [55], MaturityMonthYear [200] or MaturityDate [541], SecurityType [167] and SecurityExchange[207] or ExDestination [100].
Note - TT has modified the exchange symbology from 7x formatting where applicable, for example, ICE Brent Crude futures are defined as 55=BRN instead of 55=IPE e-brent.

New Feature - FIX Algo Order Routing
FIX order routing clients can now access TT Order Types, Autospreader and your ADL algos with your FIX applications to provide order execution functionality beyond those natively supported by exchanges.
If you want to submit orders and receive updates for TT order types, you must use specific parameters necessary for the selected TT order type. Defining the required parameters can be done in 2 methods:

Screen Shot 2017-05-31 at 11.07.08 AM.png

New Feature - Cancel on Disconnect
The COD functionality allows users to define if the working Day order should be automatically canceled upon the loss of session connectivity on a per order basis by setting "18=2 o" on each new order. Upon a session disconnect, the COD functionality will make a one-time attempt to cancel the designated Day orders originated over that connection that are still working while leaving other orders still working. If the COD functionality has successfully canceled the designated working Day orders, the FIX client will receive all cancel acknowledgment messages upon reconnecting.

Note - TT will reject orders with “18=2 o” when the time in force is set to GTC or GTDate.