Creating a FIX Inbound Drop Copy session
FIX client drop-copy import applications connect to TT FIX services through a FIX Inbound Drop Copy session.
Use the FIX sessions window to add FIX sessions to your company and configure them for third-party
FIX client access.
Refer to the Adding and Configuring a Fix Session Help Library page for steps on using the TT platform to monitor Execution Report
(8) messages from an inbound Drop Copy source.
FIX Session Management
TT FIX Inbound Drop Copy client applications require a FIX session to be created in Setup in order to connect to TT FIX servers. Client applications should be designed with the following session management considerations in mind:
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 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:
- All orders entered since the last session reset (Saturday @ 22:00 UTC by default or per custom schedule in Setup)
- All GTC / GTDate orders entered in previous sessions that were still working at the start of the current sesssion.
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].
Primary and Backup Locations for Exchange Drop Copies
TT networking has specific locations designated for connectivity from TT to specific exchange drop copy services. FIX
Inbound Drop Copy (IBDC) sessions should be configured in the Setup application with the Primary Data Center
location noted below.
| Inbound Drop Copy (IBDC) Sub Type | Primary Data Center | Backup Data Center |
|---|---|---|
| ASX Drop Copy | Sydney | Singapore |
| CME (Drop Copy) | New York | Chicago |
| CME STP | New York | Chicago |
| Euronext Drop Copy | Frankfurt | London |
| Generic FIX, Persistent Session | Varies by client | Varies by client |
| ICE | Chicago | New York |
| MX Drop Copy | New York | Chicago |
| SGX GIFT City | Singapore | Sydney |
The Backup location is available for use in case of an extended loss of connectivity between the exchange’s primary
location and TT.
To switch to the backup data center location on an active FIX Inbound Drop Copy (IBDC) Session:
-
In Setup, press More in the left-hand navigation and select FIX Sessions.
-
Select the desired FIX session.
-
Check the Inactive checkbox in the Status section to disable the FIX Session. Press the Save Changes button.
-
In the Data Center drop-down, select the Backup data center location for the Sub Type as shown in the table above. Press the Save Changes button
-
Wait 30 seconds. Then uncheck the Inactive checkbox to set the FIX Session to active and press the Save Changes button
The session will immediately reconnect, resynchronize FIX message sequence numbers and request resend of any missed
messages as oer the exchange’s FIX RoE to resume processing incoming messages.
TT FIX Inbound Drop Copy overview
TT FIX Inbound Drop Copy service enables traders with FIX-based client applications to:
- Receive execution notifications (NoE).
- Receive full order audit trail including order acknowledgements.
- Maintain an integrated view of both TT and non-TT trading activity for risk management and monitoring.
- Integrate non-TT trading activity for market compliance analysis by TT Score.
- Import trades from multiple platforms into TT allowing users to export a normalized and comprehensive audit trail via TT FIX Drop Copy.
Getting Started
To begin creating an inbound drop copy application using TT FIX, you will need to:
- Download the TT FIX 4.2 and 4.4 schemas. This schema summarizes the supported FIX messages and tags.
- Create a FIX Session in Setup. The FIX session is used by the client application to connect to the TT FIX Order Routing service.
- Configure client connectivity. Create and configure client connection to TT FIX Order Routing services via the Internet or Stunnel.
TT FIX schema
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. Both production and UAT versions of the TT FIX schema are available for download at the following link:
https://library.tradingtechnologies.com/tt-fix/general/System_Overview.html#fix-schemas
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 2025-08-01 Git:16bc4b86e3c94bef40c3dc55c5314c16df9c9930 MD5:998190c7d44e5636f42569d1279400ee -->
Note: TT FIX supports only those messages and tags described in this document. Do not submit other messages or tags to TT FIX, as doing so can produce unexpected results.