Getting Started

FIX Migration Reference

The reference below provides important FIX tag mappings between different exchanges and TT FIX. You can click the name of the exchange listed below to see all mappings specific to that exchange.

Reference by Exchange

Managing FIX Sessions

Operational Notes

FIX services are available 24/7 except during software deployments, which occur Friday evenings approximately every two weeks for UAT environments and monthly for Production environments.

FIX Session Reset Schedules

TT FIX Order Routing sessions are persistent by default and reset on Saturdays
at 22:00 UTC.

Clients may optionally define a custom daily reset time when configuring a FIX
Order Routing session in Setup.

Note: If a FIX client remains connected to a FIX session when either the default or custom scheduled reset time occurs, TT’s FIX engine will send a Logout message.

On-demand Sequence Number Resets

By default, message sequence numbers for FIX sessions are reset when TT resets all FIX sessions. Message sequence numbers can also be reset, when desired, by setting Tag 34 (MsgSeqNum) = 1 and Tag 141 (ResetSeqNumFlag) = Y when sending a Logon (A) message.

ClOrdID Uniqueness

TT FIX will ensure ClOrdID (tag 11) uniqueness for:

For more information, refer to the ClOrdID tag description in the New Order Single (D) message.

Handling Connection Problems

If your FIX client application disconnects and subsequently reconnects, TT’s
FIX engine will perform an internal recovery process to query our cloud based
order book database and will deliver all unsent execution reports by applying
an incremental sequence number that picks up where we left off prior to the
disconnect. The session recovery process can be considered complete in all
cases with a News message [35=B].

This eliminates the requirement for your FIX client application to detect a
gap on the session level and request missed execution reports while
disconnected. This also allows FIX client applications to failover seamlessly
into a different datacenter without sequence number consideration.

Handling Missed Messages

If your FIX client application disconnects and was unable to process
executions prior to the disconnect, TT’s FIX engine supports the standard
message replay mechanism specified by the FIX Protocol by honoring Resend
Request [2] messages received from FIX client applications.

In extreme cases where your FIX client application unexpectedly disconnected
and required intervention on your side to reset sequence numbers that resulted
in a subsequent Logon with 141=Y and 34=1, TT’s FIX engine will still perform
a session recovery process that will query our cloud based order book database
for executions marked as undelivered and apply an incremental sequence number
to each message message. In this case, Logon [34=1], missed executions [34=2,
3, etc]. The session recovery process can be considered complete in all cases
with a News message [35=B].

In the scenario where although TT delivered all relevant execution reports to
your FIX client application, your internal system may have experienced an
issue and was unable to process the messaging. TT’s FIX Engine is aware of
sent messages, but we are unaware of your application’s success or failure to
process them. If your FIX client application also required a sequence number
reset and cannot request a Resend Request [2] message, executions can be
retrieved through our REST API [link to REST].

CME TT Inbound Drop Copy Support

In order to add support CME Drop Copy 4.0 in the TT Inbound Drop Copy service, tags 5024 and 5979 have been added to the TT XML schema Service as shown:

<field number=’5024′ name=’StartSequenceNumber’ type=’SEQNUM’ />
<field number=’5979′ name=’RequestTime’ type=’STRING’ />

These tags will not appear in any messages used by TT standard outbound drop copy service or any other customer-facing FIX interfaces.

No customer action is required regarding these tags.

MockOrderFlag

The FIX schema now includes the optional FIX Tag 18001. This optional tag is available in all order and execution report messages. In addition, these tags will not appear in any current messages in production and are reserved for future use.

Routing “Instrument Not Found” Rejects

FIX Order router now routes “Instrument Not Found” rejects to the Drop Copy session. The message appears in Tag 58 (Text) and includes the instrument lookup field (e.g., instrument_id, Name, Alias, RIC_Code, ect.) and value.

If a valid account and user exist on the order, the FIX Order Router will use those values, otherwise, it will use the Error Account + default user.

IFOA Mitigation for FIX Order Routing

The IFOA mitigation system does the following:

FIX Logon Message Version Validation

FIX tags in Logon messages are validated such that any tags not valid for the FIX version of the Logon message will be rejected. For example, if a customer FIX 4.2 Logon message contains a FIX tag that is valid for FIX 4.4 but not FIX 4.2, that logon will be rejected.

Expired and Canceled Execution Reports

TT receives execution reports (ERs) from multiple exchanges and publishes these to clients via TT FIX Drop Copy. When exchanges send unsolicited ERs in response to an IOC/FOK order, EOD expiration or other exchange-initiated event, some will set ExecType/OrdStatus on such ERs to Canceled (39=4; 150=4), while others set it as Expired (39=C; 150=C), or others may use a mix (39=4; 150=C).

In order to improve consistency across exchanges, TT Order Connectors normalize ExecType and OrdStatus for unsolicited execution reports as follows:

System Overview

The TT FIX service allows customers to receive real-time copies of all of their orders submitted through the TT
platform, along with their corresponding fills. To use this service, customers must develop FIX clients capable
of connecting to and communicating with the TT FIX.

TT FIX supports a subset of the FIX protocol (Version 4.2 with Errata 20010501 and Version 4.4) message types and
tags within its message types. Refer to the website http://www.fixtradingcommunity.org/ for additional FIX tag descriptions and message
definitions.

Identifying the FIX Schema Version

The second line of each TT FIX schema file contains an XML comment that identifies the schema’s publication date
and internal version information, similar to the following.

<!-- TT FIX Version: UAT  10:25:17 Git:16bc4b86e3c94bef40c3dc55c5314c16df9c9930 MD5:998190c7d44e5636f42569d1279400ee -->

FIX Schemas

Both production and UAT versions of the TT FIX schema are available for download at the links below.

Production Version

TT currently supports two formats of the FIX 4.2 (Prod) and FIX 4.4 (Prod) schemas.

All of the Production schemas contain the recent enhancements listed in the release notes.

Legacy Schemas

The Legacy Schemas use the older format while containing the recent enhancements listed in the release notes.

Component Schemas

The new Component Schemas have been redesigned to support a component-based format of the schema. These schemas also contain the recent enhancements listed in the release notes.

This new approach will be available as the default format of the FIX schemas in future releases.

UAT Version

TT currently supports two formats of the FIX 4.2 (UAT) and FIX 4.4 (UAT) schemas.

All of the UAT schemas contain the recent enhancements listed in the release notes.

Legacy Schemas

The Legacy Schemas use the older format while containing the recent enhancements listed in the release notes.

Component Schemas

The new Component Schemas have been redesigned to support a component-based format of the schema. These schemas also contain the recent enhancements listed in the release notes.

This new approach will be available as the default format of the FIX schemas in future releases.