← Back to X_TRADER® Help Library

Synthetic Strategy Engine Documentation

Configuration Files for 7.3.X

Configuration Files

After installing the Synthetic SE software, you must configure the tt_sse.ini file, which specifies the TT Gateways to which Synthetic SE will connect, along with their corresponding credentials. You must configure this file for every Synthetic SE Server machine in your network, regardless of which type of network deployment you choose. Additionally, you must configure the rollover settings for the Synthetic SE Fill Server, which are located in the aconfig_local.xml file.

If you deploy Synthetic SE in a multiple-multicast network, you must also configure the following files:

  • ttminclude.cfg, which defines multicast subjects for the TT Gateway Price Servers to which Synthetic SE connects in a multiple-multicast network
  • ttmd.cfg, which controls the TTM Communication Daemon configuration and includes the ttminclude.cfg file.

About the tt_sse.ini File

Synthetic SE uses the tt_sse.ini file, located in <root drive>:ttconfig, to configure credentials for each TT Gateway through which Synthetic SE can submit synthetic orders on behalf of traders. This file contains a series of sections that specify the configuration information for each TT Gateway connection.

tt_sse.ini Parameters

The following table describes the parameters used in the tt_sse.ini file.

tt_sse.ini parameters




Marks the beginning of a TT Gateway connection section and sets the gateway and flavor (e.g. gw-CME-A).

If you plan to connect to pre-7.14 versions of the TT CBOT, or Montreal Gateways, refer to the section called If Synthetic SE Connects to Pre-7.14 TT Gateways.


The TT Synthetic Strategy Engine can connect to a maximum of 50 TT Gateways.




(Required) Provides the Member, Group, and Trader IDs (MGTs) for Synthetic SE to use when logging in to the specified TT Gateway.

For more information, refer to the section called Determining TT Gateway Login Credentials with Dynamic Connections Disabled.


For TTSIM Gateways, you should not use TTADM/XXX/MGR credentials.


(Required) Identifies the primary Synthetic SE in an environment with more than one Synthetic SE for this TT Gateway. In a multiple Synthetic SE environment, the client application (i.e. X_TRADER) routes synthetic orders through the Synthetic SE that enables this parameter.

Possible values include Y and N.

For more information about this parameter, see Multiple Synthetic SE Servers for a TT Gateway.


(Optional) Sets exchange mapping. By setting this parameter equal to the Exchange-Flavor to which you want to map, Synthetic SE routes price subscriptions to that Exchange-Flavor. In the following sample configuration, Synthetic SE routes the price subscriptions to CME through CME-A.








(Conditionally required) Sets the type of unique trader ID that Synthetic SE should send for child orders of staged orders so that you can be in compliance with the exchange regulations for CME, CBOT, eCBOT, and ICE. You must set this parameter for these TT Gateways, but should not use it for any other TT Gateways. Possible values include:

  • Username, to send the trader’s Username
  • RoutingTraderId, to send the Trader ID from the trader’s TT routing credentials
  • ExchangeTraderId, to send the Trader ID from the trader’s exchange credentials

To illustrate, assume a user is configured with the following credentials:

  • Username: BOB
  • TT Routing Credentials:

    Member ID = TTORDAB Group ID = 007 Trader ID = 001

  • Exchange Trader Credentials:

    Member ID = ABC Group ID = DEF Trader ID = GHI

With these credentials, setting the value of this parameter has the following effects:

  • Username: Synthetic SE instructs the TT Gateway to send BOB as the unique trader ID when it routes orders to the Exchange.
  • RoutingTraderID: Synthetic SE instructs the TT Gateway to send 001 as the unique trader ID when it routes orders to the Exchange.
  • ExchangeTraderId: Synthetic SE instructs the TT Gateway to send GHI as the unique trader ID when it routes orders to the Exchange.

For more information about the Exchange requirements, refer to the corresponding TT Gateway System Administration Manual.


Currently, only the TT CME, CBOT, eCBOT, and ICE Gateways require this field. For these TT Gateways, you must set the value as follows:

  • CME: Match the TT CME Gateway Sendersubid configuration parameter.
  • CBOT: Match the TT CBOT Gateway Sendersubid configuration parameter.
  • eCBOT: Match the TT eCBOT Gateway TRADER_CARD_REF configuration parameter.
  • ICE: Always set the value to RoutingTraderId.

Other TT Gateways use their own criteria for determining which trader ID to send to their corresponding Exchanges.

[Synthetic Engine]

Marks the beginning of the synthetic engine section.


Enables or disables support for order staging and the X_TRADER Avoid orders that cross configuration option. Valid values include:

  • Y:
    • Enables support for order staging
    • Enables support for the X_TRADER Avoid orders that cross configuration option
  • N (default):
    • Disables support for order staging
    • Disables support for the X_TRADER Avoid orders that cross configuration option

Before enabling this parameter:

Multiple Synthetic SE Servers for a TT Gateway

You can use multiple Synthetic SE Servers to support a single TT Gateway to create a more robust environment. For example, you could distribute traders across multiple TT Synthetic SE Servers. You might also want to allow traders to log into multiple Synthetic SE Servers so that they can still access an Synthetic SE Server in the event that one fails.

If you want to allow a trader to log into multiple Synthetic SE Servers that are all configured to connect to the same TT Gateway(s), it is important that one of the Synthetic SE's indicate to client applications, such as X_TRADER, that it is the primary one to be used for a given TT Gateway.

Example: Configuring Multiple Synthetic SE Servers for Failover

In the following example, you configure one Synthetic SE Server (SSE-A) as the primary destination for client applications, such as X_TRADER, to connect to both Synthetic SE Servers to route orders. Then, you configure another Synthetic SE Server (SSE-B) to serve as the secondary, or backup, destination for client applications to use if SSE-A becomes unavailable.

Example tt_sse.ini (for SSE-A)






Example tt_sse.ini (for SSE-B)






In this scenario, if both Synthetic SE Servers are up and the client application is connected to both, all synthetic ICE_IPE orders will be routed to the one designated as the primary (SSE-A). If the primary Synthetic SE Server becomes unavailable, the client application will submit all synthetic ICE_IPE orders to the backup Synthetic SE Server (SSE-B).


Client applications randomly choose from multiple Synthetic SE Servers associated with a TT Gateway in the following circumstances:

  • Multiple Synthetic SE Servers enable the Primary parameter.
  • No Synthetic SE Servers enable the Primary parameter.
  • When three or more Synthetic SE Servers support the TT Gateway and the primary Synthetic SE Server becomes unavailable.
  • Synthetic SE always synthesizes the stop / if-touched portion of a trailing stop / if-touched order.

If Synthetic SE Connects to Pre-7.14 TT Gateways

When a trader submits an order through X_TRADER, X_TRADER needs to determine whether the TT Gateway natively supports the order type so it knows whether to send the order to the TT Gateway or to the TT Synthetic Strategy Engine. In TT Gateways 7.14 or later, X_TRADER can get the supported order types directly from the TT Gateways. For earlier TT Gateway versions, Synthetic SE stores the information for most TT Gateways in corresponding rules files.

However, if Synthetic SE connects to flavors of any of a pre-7.14 TT Montreal Gateway, you must take the following additional steps so that Synthetic SE can provide the information to X_TRADER:

  1. Copy and rename the matching <TT_Root>:ttconfigGW_Name_GatewayRules.xml file.

    For example, if Synthetic SE connects to a version 7.13 TT Montreal-A Gateway, you would copy Montreal_GatewayRules.xml to Montreal-A_GatewayRules.xml.

  2. Change the name of the <Gateway> element in the new file to match the flavor.

You should not edit these rules files in any other manner unless instructed by TT Support personnel.