{"id":7074,"date":"2025-08-28T22:35:58","date_gmt":"2025-08-29T03:35:58","guid":{"rendered":"https:\/\/librarytestdev.wpenginepowered.com\/?post_type=doc&#038;p=7074"},"modified":"2026-03-24T06:40:59","modified_gmt":"2026-03-24T11:40:59","slug":"operational-notes","status":"publish","type":"doc","link":"https:\/\/library-staging.tradingtechnologies.com\/tt-fix\/tt-fix-general\/getting-started-tt-fix-general\/operational-notes\/","title":{"rendered":"Operational Notes"},"content":{"rendered":"\n<h2 class=\"wp-block-heading MapTitle\" id=\"Operational-Notes\">Operational Notes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fix-session-reset-schedules\">FIX Session Reset Schedules<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">\n  TT FIX Order Routing sessions are persistent by default and reset on Saturdays\n  at 22:00 UTC.\n<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\n  Clients may optionally define a custom daily reset time when configuring a FIX\n  Order Routing session in <a href=\"\/user-setup\/fxs-adding-and-configuring-a-fix-session.html\">Setup<\/a>.\n<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><span class=\"label label-info\"><strong>Note<\/strong><\/span><strong>:<\/strong> If a FIX client remains connected to a FIX session when either the default or custom scheduled reset time occurs, TT\u2019s FIX engine will send a Logout message.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"sequence-number-resets\">On-demand Sequence Number Resets<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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 <a href=\"\/tt-fix\/general\/Msg_Logon_A.html\">Logon (A)<\/a> message.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"clordid-uniqueness\">ClOrdID Uniqueness<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">TT FIX will ensure ClOrdID (tag 11) uniqueness for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>All orders entered since the last session reset (Saturday @ 22:00 UTC by default or per custom schedule in Setup)<\/li>\n\n\n\n<li>All GTC \/ GTDate orders entered in previous sessions that were still working at the start of the current sesssion.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">For more information, refer to the <a href=\"\/tt-fix\/order-routing\/Msg_NewOrderSingle_D.html#tag11\">ClOrdID tag description<\/a> in the New Order Single (D) message.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"handling-connection-problems\">Handling Connection Problems<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">\n  If your FIX client application disconnects and subsequently reconnects, TT\u2019s\n  FIX engine will perform an internal recovery process to query our cloud based\n  order book database and will deliver all unsent execution reports by applying\n  an incremental sequence number that picks up where we left off prior to the\n  disconnect. The session recovery process can be considered complete in all\n  cases with a News message [35=B].\n<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\n  This eliminates the requirement for your FIX client application to detect a\n  gap on the session level and request missed execution reports while\n  disconnected. This also allows FIX client applications to failover seamlessly\n  into a different datacenter without sequence number consideration.\n<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"handling-missed-messages\">Handling Missed Messages<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">\n  If your FIX client application disconnects and was unable to process\n  executions prior to the disconnect, TT\u2019s FIX engine supports the standard\n  message replay mechanism specified by the FIX Protocol by honoring Resend\n  Request [2] messages received from FIX client applications.\n<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\n  In extreme cases where your FIX client application unexpectedly disconnected\n  and required intervention on your side to reset sequence numbers that resulted\n  in a subsequent Logon with 141=Y and 34=1, TT\u2019s FIX engine will still perform\n  a session recovery process that will query our cloud based order book database\n  for executions marked as undelivered and apply an incremental sequence number\n  to each message message. In this case, Logon [34=1], missed executions [34=2,\n  3, etc]. The session recovery process can be considered complete in all cases\n  with a News message [35=B].\n<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\n  In the scenario where although TT delivered all relevant execution reports to\n  your FIX client application, your internal system may have experienced an\n  issue and was unable to process the messaging. TT\u2019s FIX Engine is aware of\n  sent messages, but we are unaware of your application&#8217;s success or failure to\n  process them. If your FIX client application also required a sequence number\n  reset and cannot request a Resend Request [2] message, executions can be\n  retrieved through our REST API [link to REST].\n<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">CME TT Inbound Drop Copy Support<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\n      &lt;field number=&#8217;5024&#8242; name=&#8217;StartSequenceNumber&#8217; type=&#8217;SEQNUM&#8217; \/&gt; <br>\n      &lt;field number=&#8217;5979&#8242; name=&#8217;RequestTime&#8217; type=&#8217;STRING&#8217; \/&gt; \n  <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">These tags will not appear in any messages used by TT standard outbound drop copy service or any other customer-facing FIX interfaces. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No customer action is required regarding these tags. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"mockorderflag\">MockOrderFlag<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"instrument-not-found\">Routing &#8220;Instrument Not Found&#8221; Rejects<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">FIX Order router now routes &#8220;Instrument Not Found&#8221; 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">IFOA Mitigation for FIX Order Routing<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The IFOA mitigation system does the following:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>After an IFOA timeout (currently 30 seconds), the account, market, and connection are suspected of having broken\/unresponsive components. No new orders are allowed on that tuple until a test request sent for the connection on that account and market is responded to successfully. Blocked tuples are retested periodically.<\/li>\n\n\n\n<li>Orders on broken routes are queried against Bookie for status periodically until either a definitive status result is received or the order is considered stale by the Order Connector, after which the order is reported dead\/rejected.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fix-logon-validation\">FIX Logon Message Version Validation<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"expired-and-canceled-execution-reports\">Expired and Canceled Execution Reports<a href=\"\/tt-fix\/general\/Operational_Notes.html#expired-and-canceled-execution-reports\"><\/a><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In order to improve consistency across exchanges, TT Order Connectors normalize ExecType and OrdStatus for unsolicited execution reports as follows:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Canceled \u2192 For unsolicited cancellations due to IOC or FOK.\n<ul class=\"wp-block-list\">\n<li>The status of the order on TT GUI is CANCELED.<\/li>\n\n\n\n<li>FIX tags are reported as (39=4; 150=4).<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Expired \u2192 For all other unsolicited cancellations, including SMP-related cancellations.\n<ul class=\"wp-block-list\">\n<li>The status of the order on TT GUI is EXPIRED.<\/li>\n\n\n\n<li>FIX tags are reported as (39=4; 150=C).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Operational Notes FIX services are available 24\/7 except during software deployments, which occur Friday eveni [&hellip;]<\/p>\n","protected":false},"author":2,"template":"","meta":{"_acf_changed":false,"footnotes":""},"docs-category":[453],"class_list":["post-7074","doc","type-doc","status-publish","hentry","docs-category-getting-started-tt-fix-general"],"acf":[],"_links":{"self":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/doc\/7074","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/doc"}],"about":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/types\/doc"}],"author":[{"embeddable":true,"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/users\/2"}],"version-history":[{"count":0,"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/doc\/7074\/revisions"}],"wp:attachment":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/media?parent=7074"}],"wp:term":[{"taxonomy":"docs-category","embeddable":true,"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/docs-category?post=7074"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}