TradeStation FIX Gateway - Amazon S3 · The TradeStation FIX Gateway is a communication service...

TradeStation FIX Gateway

Programming Reference 1.6

DocuSign Envelope ID: D7C80BF3-713C-4DDC-B92D-50713F330D32

TradeStation Securities, Inc.

FIX Gateway Programming Reference 1.6

Document History

Version Date Comment

1.0 SMatthews First draft Oct 12, 2008

1.1 DHinners Modified criteria New order single, tag 126, 432, added 47and 528. Modified cancel: added tag 1 and 38 as extraneous. Modified C/R & Execution Report: added tag 47 and 528. Added Business Reject Report Message

Jan. 7, 2010

1.2 DHinners Added Closing order functionality (At the Close) 3.5.20 Jan. 27,2010

1.3 DHinners Removed 4.3 references. Modified Archival procedures. July 7,2010

1.4 DHinners Changed password creation reference Feb. 23/2011

1.5 DHinners Addition of contingent order integration (not 5.0 standard). Proprietary integration for OCO, OSO and Bracket (BRK) orders.

Oct. 10/2012

1.6 DHinners Updated Explicit Routes Table (Pending review…) Oct 1/2014

Copyright © 2008 TradeStation Group, Inc. All rights reserved.

TradeStation disclaims any and all warranties relating to products, services, software and systems that

have been described or referenced herein, including warranties of fitness for a particular use or

purpose, and the user expressly assumes all risk of damage, loss and expense that may result from use

of such products, services, software, and systems, or from design flaws, errors or failures or delays of

any kind, regardless of the cause or the persons responsible.

Any third-party product names contained herein are used to identify such products for descriptive purposes only.




Table of Contents 1 Preface .................................................................................................................................................. 5

2 Gateway Operation ............................................................................................................................... 6

2.1 FIX Implementation....................................................................................................................... 6

2.2 Session Hours ................................................................................................................................ 6

2.3 Network Communication .............................................................................................................. 7

2.4 Manual Intervention ..................................................................................................................... 8

2.5 Cross-Client Support ..................................................................................................................... 9

2.6 Getting Started ............................................................................................................................ 11

3 Protocol Reference ............................................................................................................................. 12

3.1 Introduction ................................................................................................................................ 12

3.2 Conventions ................................................................................................................................ 12

3.3 Message Envelope ...................................................................................................................... 13

3.3.1 Standard Header Block........................................................................................................ 14

3.3.2 Standard Trailer Block ......................................................................................................... 14

3.4 Session Protocol .......................................................................................................................... 15

3.4.1 Heartbeat Message ............................................................................................................. 15

3.4.2 Logon Message ................................................................................................................... 15

3.4.3 Test Request Message ........................................................................................................ 15

3.4.4 Resend Request Message ................................................................................................... 16

3.4.5 Message Reject Message .................................................................................................... 16

3.4.6 Sequence Reset Message .................................................................................................... 16

3.4.7 Logout Message .................................................................................................................. 17

3.4.8 Logging On .......................................................................................................................... 17

3.4.9 Explicit Synchronization ...................................................................................................... 17

3.5 Application Protocol.................................................................................................................... 18

3.5.1 Parties Block ........................................................................................................................ 18

3.5.2 Discretion Instructions Block .............................................................................................. 18

3.5.3 Instrument Block ................................................................................................................. 19

3.5.4 PegInstructions Block .......................................................................................................... 19

3.5.5 New Order (Single-Leg) Request Message .......................................................................... 20

3.5.6 Contingent Orders ............................................................................................................... 21




3.5.7 Order Cancel Request Message .......................................................................................... 21

3.5.8 Order Cancel/Replace Request Message ............................................................................ 21

3.5.9 Order Status Request Message ........................................................................................... 22

3.5.10 Execution Report Message ................................................................................................. 22

3.5.11 Cancel Reject Report Message ............................................................................................ 23

3.5.12 Business Reject Report Message ........................................................................................ 24

3.5.13 Request Identification ......................................................................................................... 24

3.5.14 Original Party Identification ................................................................................................ 25

3.5.15 Account Identification ......................................................................................................... 25

3.5.16 Order Transaction Type: Side and Position ........................................................................ 26

3.5.17 Transaction Timestamp ....................................................................................................... 26

3.5.18 Security Identification ......................................................................................................... 27

3.5.19 Order Type and Price Specification ..................................................................................... 29

3.5.20 Contingency Explained ........................................................................................................ 31

3.5.21 Quantity Specification ......................................................................................................... 33

3.5.22 Time-In-Force Specification ................................................................................................ 33

3.5.23 Order Routing ...................................................................................................................... 34

3.5.24 Order Modification ............................................................................................................. 34

3.6 Supported Fields ......................................................................................................................... 35

3.6.1 Compatibility ....................................................................................................................... 35

3.6.2 Schedule of Fields ............................................................................................................... 36

4 Appendix ............................................................................................................................................. 44

4.1 Operating Parameters ................................................................................................................. 44

4.2 Explicit Routes ............................................................................................................................. 44

4.3 Contact Information .................................................................................................................... 45




1 Preface

The TradeStation FIX Gateway is a communication service that provides access to TradeStation’s

network-based order routing system. Prior to creation of the Gateway, only TradeStation developed

applications could efficiently and robustly route orders into a diverse market place. Now, with the

advent of an industry standard FIX Gateway, externally developed client applications can easily tap this

proven technology, saving countless hours of development time.




2 Gateway Operation

2.1 FIX Implementation

Gateway FIX protocol is based on standards 4.2 and 4.4. It is an integrated protocol that merges two

standards into one: earlier standards are extended with certain later features, and later standards are

extended with certain earlier features. Client applications written to any of these standards should have

little trouble adapting to the implementation.

There are two distinct protocol “layers” in every FIX implementation. The common terminology is

“session layer” and “application layer.” The Gateway session layer derives from an open-source

implementation of standard FIX session protocol, while the application layer is a proprietary subset

implementation of standard FIX order-execution protocol.

The session layer is based on QuickFIX 1.12.4 open source FIX engine. Because it is open source, the

base implementation may be examined at any time. Visit the QuickFIX website

http://www.quickfixengine.org for more information.

2.2 Session Hours

Session hours are an important part of FIX protocol because clients and servers are required to reset

their session states at the start of a new session. If either side is unsynchronized or doesn’t adhere to

the reset requirement, communication will fail.

TradeStation FIXGateway offers two options for establishing a FIX session. Individual sessions may recur

on a daily basis or may span a single multi-day period. The default is daily and is most commonly used.

Clients may request start and stop times for session hours, but individual sessions must be contained by

a 24-hour period. A weekly session is also available and spans about six days. Exact hours are provided

in Appendix 4.1.

The Gateway operates on a UTC (Universal Time Coordinated) clock; that is, session hours are posted in

UTC and servers are operated accordingly. UTC is not subject to daylight savings adjustment, so

operators must be aware of local offsets that may vary during the year.

Gateway servers are generally available during standard market hours. Under normal operating

conditions, servers are available outside market hours to account for discrepancies in clock

synchronization. Therefore, session hours are usually extended prior to and after a client’s requested

session times. But client applications should plan to operate well within session hours (standard or

individual) in order to avoid any synchronization issues.


http://www.quickfixengine.org/



After session reset, any unsent execution information is discarded and will no longer be available.

Discarded information pertains to processed but undelivered FIX messages. For example, a FIX session

is available from 6 a.m. to 6 p.m. ET, but the FIX counterpart disconnects at 3:50 p.m. An order from

earlier in the day is filled at 3:55 p.m. The day order information will be available until session reset at 6

p.m. If the FIX session is not re-established prior to that time, the execution report will be discarded

during session reset. GTC order state will be maintained across sessions; however, undelivered reports

will still be discarded across sessions.

Because Gateway servers may operate outside posted session hours, it may be possible for a client

application to establish or maintain a network connection when there is no logical session. This is

especially true for clients that utilize individual sessions. Although there is no significant harm in this,

client applications should be prepared to deal with minor side effects that occur when they connect out

of session.

If a client application connects out of session or maintains a connection beyond end of session, it will

receive an immediate Logout message from the server and the network connection will be terminated.

Any out-of-session activity will cause the persistent session state maintained by the Gateway to reset:

sequence numbers are initialized to one, the message resend cache is deleted and a time stamp is

applied.

Following any out-of-session activity, client applications should expect the first in-session logon attempt

to fail as if it were out of session. The first legitimate (but rejected) logon is required to reset the

persistent session time stamp to a valid session time. After that, a subsequent logon with new sequence

numbers (1, 1) will proceed without issue.

If a client application properly connects and disconnects within session hours, there are no side effects.

2.3 Network Communication

Client applications and Gateway servers communicate over a private network using TCP/IP transport

protocol. The private network may be real or virtual (VPN over public Internet).

TradeStation will provide clients with redundant Gateway server addresses. TCP port numbers vary in

ranges for Production, Simulation and Development environments. Port ranges are indicated in

Appendix 4.1, but clients should discuss exact session values with a FIX support representative.

Client applications will have access to at least four different servers in two different sites. At least two

servers will be assigned from a primary site and two servers will be assigned from a secondary site.

Normally, a client application will connect to one of the primary site servers. However, in the event of

catastrophic failure of the primary site, clients will be notified and instructed to reconnect to the

secondary site.




A client application may connect to either (any) of the provided site servers, but it may connect to only

one at a time. There is no particular preferred connection order. If an application attempts to connect

to more than one server at a time, the previous connection will be terminated.

Given redundant site servers, a client application can implement resilient connectivity. Better client

applications will automatically monitor network connections and heartbeats, switching to an alternate

server when there is a disruption.

Although resilient connectivity is not a requirement, it is highly recommended. Even under normal

operating conditions, Gateway servers temporarily disconnect clients for daily maintenance during off-

peak hours. Maintenance activity rotates through the site, server by server, so alternate servers are

always available. A resilient client application can detect this off-peak condition and switch over

automatically, effectively implementing a continuous session.

2.4 Manual Intervention

FIX applications operate with synchronized persistent session states. They are designed to operate

automatically without issue, but experience shows that occasionally even certified applications will

require manual session intervention. Manual intervention is a coordinated, bilateral operation that

resynchronizes the persistent session states of both sides.

Manual intervention is usually initiated by the client. There are two basic interventions that may be

requested.

First, a client may request that the Gateway increase its message sequence numbers. The Gateway can

increase its incoming sequence number, its outgoing sequence number, or both. This type of

intervention preserves the session message cache, so it is the recommended first step in any attempt to

resynchronize.

Second, a client may request that the Gateway reset its persistent session state. This intervention

deletes the session message cache and resets both sequence numbers to one. Once executed, there is

no chance of resending the deleted messages, so use this intervention as a last resort (note: session

reset does not affect application-level transaction history).

In order for manual intervention to work, the client-side persistent session state must be set to match

the requested Gateway session state. Failure to do so correctly will preclude connection.

Client applications have related capabilities for session management through the FIX session level

protocol. The Gateway’s incoming sequence number can be adjusted using a Sequence Reset message,

and the persistent session may be completely reset by indicating ResetSeqNumFlag [141] in a logon

message. However, the ability to increase the Gateway’s outbound sequence number is only available

through manual intervention.




See Appendix 4.3 for contact information.

2.5 Cross-Client Support

TradeStation accounts can be provisioned to allow access by multiple clients. With proper authorization

and configuration, multiple client applications can monitor and/or trade a common account. FIX

applications may replace, cancel, and query orders submitted by other FIX clients, and they can monitor

orders submitted by other TradeStation client applications. Likewise, native TradeStation client

applications may be able to monitor orders submitted by FIX client applications.

FIX client applications can replace, cancel, and query orders originally submitted by other associated FIX

parties. This capability is useful in certain oversight scenarios. A client application must know the other

party’s SenderCompID [49] and the original ClOrdID [11] in order to code a proper request message. See

“Protocol Reference” for details.

The native TradeStation platform is sometimes used to monitor orders generated through a FIX session.

The platform is generally used in view-only mode; however, in supervisory mode, a FIX session can be

set up to allow interaction with FIX orders. This is considered an adaptation to the system that must be

discussed prior to use. If this adaptation is enabled, TradeStation will allow modification or cancellation

of FIX orders from the TradeStation platform. FIX orders are then updated in a non-standard fashion. If

this functionality is required it should be discussed prior to integration testing.

FIX client applications can also monitor activity on an account shared with native TradeStation clients.

This capability is commonly called “drop-copy” service. FIX drop-copy applications are sometimes called

“one-way” applications because they are typically designed to receive report messages only. Normally,

drop-copy applications are not designed to submit request messages, but there is no inherent reason for

precluding such an application.

As a convenience to existing drop-copy applications, the delivery of standard reports can be restricted

on a per-account basis. Clients may configure their accounts so that only specific reports will be

delivered. Every client that is authorized to monitor an account will receive the same set of reports.

Account filtering is an “opt-out” capability. By default, accounts are configured with no report filtering.

The following table details the filter conditions that can be applied to outbound reports.

Message Condition

Execution Report (MsgType[35] = 8) ExecType[150] = 0 (New)

Execution Report (MsgType[35] = 8) ExecType[150] = 3 (Done For Day)

Execution Report (MsgType[35] = 8) ExecType[150] = 4 (Cancelled)

Execution Report (MsgType[35] = 8) ExecType[150] = 5 (Replaced)

Execution Report (MsgType[35] = 8) ExecType[150] = 6 (Pending Cancel)

Execution Report (MsgType[35] = 8) ExecType[150] = 8 (Rejected)




Execution Report (MsgType[35] = 8) ExecType[150] = C (Expired)

Execution Report (MsgType[35] = 8) ExecType[150] = D (Restated)

Execution Report (MsgType[35] = 8) ExecType[150] = E (Pending Replace)

Execution Report (MsgType[35] = 8) ExecType[150] = F (Trade)

Execution Report (MsgType[35] = 8) ExecType[150] = G (Trade Correct)

Execution Report (MsgType[35] = 8) ExecType[150] =H (Trade Cancel)

Execution Report (MsgType[35] = 8) SecurityType[167] n/a (equity)

Execution Report (MsgType[35] = 8) SecurityType[167] = FUT

Execution Report (MsgType[35] = 8) SecurityType[167] = OPT

Execution Report (MsgType[35] = 8) SecurityType[167] = FOR

Execution Report (MsgType[35] = 8) LeavesQty[151] > 0

Cancel Reject Report (MsgType[35] =9)




2.6 Getting Started

Before connecting to the FIX Gateway, clients must contact TradeStation for the following information:

Network Access – VPN connection parameters or private network requirements.

o VPN or private network must be established prior to procuring production credentials.

o Connectivity to primary and backup locations is recommended.

o The development (UAT) environment may be accessed using open Internet.

Server Assignments – available static server addresses.

CompID – computer identification specified as SenderCompID in request messages and

TargetCompID in report messages.

Session Port

Account Numbers – one or more account identifiers used to track trading activity.

Password – (not required but available).

Clients should be prepared to provide the following information:

Protocol Version – specified in all messages between client application and Gateway, either

“FIX.4.2” or “FIX.4.4”

Session Hours – elect standard hours or specify individual hours

Request Latency – elect standard latency or specify individual latency

Shared Accounts – shared account numbers and associated CompID (optional)

Report Filters – specific report filters (optional)




3 Protocol Reference

3.1 Introduction

This reference details the messaging protocol implemented by TradeStation’s FIX Gateway.

TradeStation’s FIX protocol is based on industry-standard FIX (Financial Information Exchange).

Although FIX has been widely adopted by the financial industry, its extensive scope and inherent

flexibility has led to many and various dialects. TradeStation’s dialect, while conforming to existing FIX

standards, also includes simple and natural extensions that support proprietary features and facilitate

application development.

Given the potential for various conforming FIX dialects, implementers are obliged to provide a

specification of particulars about their implementation. This reference is such a specification. It serves

to resolve the abstract description of standard FIX into a concrete specification of TradeStation FIX.

Standard FIX is an important prerequisite, though. The reader is assumed to be familiar with FIX

protocol, its specification, and its documentation conventions.

FIX specifications are available online at http://www.fixtradingcommunity.org/.

This reference is divided into five sections:

Conventions - survey of terms and usage

Message Envelope – header and trailer formats

Session Protocol - session-level message formats and implementation

Application Protocol – application-level message formats and implementation

Supported Fields – schedule of fields and compatibility

3.2 Conventions

Established conventions are maintained in this reference wherever possible. Where it makes sense to

depart from established conventions, new ones are introduced.

Message and field tables are similar to those found in the standard specification documents. Layout is

similar, and standard names for fields, values, and types are used where they apply. Standard tag values

are always used. Message names are similar or identical.

Supported fields are scheduled by tag, name, and type. The definition of a field is a definition of its

value domain. Value domains may be enumerated or described.

The usual field ordering rules apply. Generally, fields in a message are unordered, but there are

exceptions for particular header and trailer fields, and for lead fields in repeating groups.


http://www.fixtradingcommunity.org/



There is a noticeable departure from convention in the message format tables. The conventional entries

that indicate requirement and provide commentary are replaced in this document by a single regular

syntax specification.

A syntax specification defines the conditions under which a message field may be “required,”

“significant,” or “specified.” Specifications are stated with respect to the server implementation and

convey how the server parses and generates messages. Client request fields are declared using the

terms “required” and “significant” while server report fields are declared using “specified.”

For client requests, if a field is required then the client application must specify the field or the request

will be rejected. If a field is significant, then the application may specify the field, but it is not required.

If a significant field is not specified, a default value is used. If a request field is neither required nor

significant, it is either “extraneous” or “spurious.” Extraneous fields are ignored if specified, but

spurious fields will result in request rejection if specified.

For server reports, if a field is described as specified under some condition, then it will be included in the

message when the condition applies; otherwise, it won’t.

Session-level formats have a dual nature. That is, there is a specification for both parsing and

generation. Parsing specs are consistent with client requests and generation specs are consistent with

server reports.

For all message formats, unlisted fields are not supported. Unsupported fields are implicitly spurious.

Thus, any message that contains an unsupported field will be rejected.

3.3 Message Envelope

Every FIX message contains two components known as Standard Header and Standard Trailer. Logically,

the two components define an “envelope” that surrounds other fields in a message. By convention,

message formats show Header and Trailer components always at the top and bottom of a message.

Technically, only four fields in the envelope are actually assigned definite positions at the beginning or

end of a message; other fields may appear throughout the message.




3.3.1 Standard Header Block

Name Tag Specification BeginString 8 Always required. First field in message.

Always specified. First field in message.

BodyLength 9 Always required. Second field in message.

Always specified. Second field in message.

MsgType 35 Always required. Third field in message.

Always specified. Third field in message.

SenderCompID 49 Always required.

Always specified.

TargetCompID 56 Always required.

Always specified.

MsgSeqNum 34 Always required.

Always specified.

SendingTime 52 Always required.

Always specified.

PossResend 97 Always significant. Default: value = N.

Never specified.

PossDupFlag 43 Always significant. Default: value = N.

Specified if responding to Resend Request message. Value = Y.

OrigSendingTime 122 Required if PossDupFlag[43] = Y, otherwise extraneous.

Specified if PossDupFlag[43] is specified.

3.3.2 Standard Trailer Block

Name Tag Specification

Checksum 10 Always required. Last field in message.

Always specified. Last field in message.




3.4 Session Protocol

Session protocol is a subset of the standard FIX protocol concerned with session administration and

general conduct of a FIX connection. Most aspects of session protocol are described in the standard

specification and in other parts of this document (see “Gateway Operation”). This section contains

actual message formats and coding topics.

Gateway servers are based on QuickFIX 1.12.4 open-source FIX engine. QuickFIX is responsible for

managing the session-level protocol. Because it is open source, the session-level implementation may

be examined at any time. Visit the QuickFIX website http://www.quickfixengine.org for more

information.

3.4.1 Heartbeat Message

Name Tag Specification Standard Header MsgType[35] = 0.

TestReqID 112 Required if responding to Test Request message, otherwise extraneous.

Specified if responding to Test Request message.

Standard Trailer

3.4.2 Logon Message

Name Tag Specification Standard Header MsgType[35] = A

EncryptMethod 98 Always required.

Always specified.

HeartBtInt 108 Always required.

Always specified.

ResetSeqNumFlag 141 Always significant. Default: value = N.

Specified per client Logon message.

Password 554 Always significant. Default: automatic.

Never specified.

Standard Trailer

3.4.3 Test Request Message

Name Tag Specification Standard Header MsgType[35] = 1

TestReqID 112 Always required.

Always specified. Value = “TEST.”


http://www.quickfixengine.org/



Standard Trailer

3.4.4 Resend Request Message


BeginSeqNo 7 Always required.

Always specified.

EndSeqNo 16 Always required.

Always specified.

Standard Trailer

3.4.5 Message Reject Message


RefSeqNum 45 Always required.

Always specified.

RefTagID 371 Always significant. Default: n/a.

Always specified.

RefMsgType 372 Always significant. Default: n/a.

Specified per client message.

SessionRejectReason 373 Always significant. Default: value = 99.

Specified if value is compatible with version.

Text 58 Always significant. Default: n/a.

Always specified.

Standard Trailer

3.4.6 Sequence Reset Message


GapFillFlag 123 Always significant. Default: value = N.

Always specified. Value = Y.

NewSeqNo 36 Always required.

Always specified.

Standard Trailer




3.4.7 Logout Message


Text 58 Always significant. Default: n/a.

Specified under normal termination conditions.

Standard Trailer

3.4.8 Logging On

A client application must send an immediate logon message after connecting to a Gateway server. A

logon message must specify EncryptMethod [98] and HeartBtInt [108]. Password [554] will usually be

specified and ResetSeqNumFlag [141] may be specified.

TradeStation FIX does not support message-level encryption. The only legal value for EncryptMethod

[98] is 0 (None).

Minimum and maximum values for HeartBtInt [108] are defined by TradeStation (see Appendix 4.1). An

invalid value will terminate the client connection. A valid value is acknowledged by the server.

Every SenderCompID [49] has an associated password. Passwords are assigned by TradeStation.

Generally, client applications must specify a correct password in the logon message to avoid immediate

disconnection. In some cases, TradeStation may assign a universal password to a particular

SenderCompID [49] and in those cases only, the client application need not specify Password [554].

Client applications may specify ResetSeqNumFlag [141] = Y. Because sequence numbers are usually

reset automatically based on session times, this is not necessary and generally not recommended.

However, if a client application elects to use this flag, it should take care to follow standard protocol for

restarting a session in this manner.

3.4.9 Explicit Synchronization

A client application may resynchronize its outbound sequence number by coding a Sequence Reset

message with GapFillFlag [123] = N. Under normal circumstances, adjusting sequence numbers in this

manner is not required and is not generally recommended. However, under abnormal circumstances, it

may be necessary to resynchronize client and server to some forward position. In this case, manual

intervention is the recommended alternative (see “Manual Intervention”).




3.5 Application Protocol

Application protocol refers to the subset of standard FIX protocol concerned with order execution.

Standard FIX defines a wide array of order execution messages, but only some are recognized by

TradeStation FIX. Messages documented in this section are the only application-level messages

supported. Unsupported messages are rejected by Gateway servers at the session level.

Application messages are grouped into classes for descriptive purposes. The following classifications are

used:

Request message – initiated by client application; includes New Order (Single-Leg) Request,

Order Cancel Request, Order Cancel/Replace Request, and Order Status Request.

Report message – initiated by Gateway servers; includes Execution Report and Cancel Reject

Report.

Transactional request message – transactional subset; includes New Order (Single-Leg) Request,

Order Cancel Request, Order Cancel/Replace Request.

Collateral request message – referential subset; includes Order Cancel Request, Order

Cancel/Replace Request, and Order Status Request.

Most message formats include references to predefined component blocks. In a departure from

standard convention, component block field specifications are locally complete; that is, they do not

depend on a context expressed in the message format.

3.5.1 Parties Block


NoPartyIDs 453 Always significant. Default: value = 0.

PartyID 448 Required if NoPartyIDs[453] = 1, otherwise spurious.

PartyIDSource 447 Required if PartyID[448] is specified, otherwise spurious.

PartyRole 452 Required if PartyID[448] is specified, otherwise spurious.

3.5.2 Discretion Instructions Block


DiscretionInst 388 Always significant. Default: n/a.

DiscretionOffsetValue 389 Required if DiscretionInst[388] is specified, otherwise extraneous.




3.5.3 Instrument Block


SecurityType 167 Significant if MsgType[35] = {8, D, G}, otherwise extraneous. Default: stock/equity. Stocks and equities are not designated explicitly. Do not specify this field if Symbol[55] or SecurityID[48] identifies a stock or equity.

Symbol 55 Required if MsgType[35] = {8, D, G} and SecurityID is not specified, significant if MsgType[35] = {8, D, G} and SecurityID is specified, otherwise extraneous.

SymbolSfx 65 Significant for equity order if Symbol is specified, otherwise extraneous. Default: n/a.

MaturityMonthYear 200 Required for futures order if MsgType[35] = {8, D, G} and Symbol[55] is specified, required for options order if MsgType[35] = {8, D, G} and Symbol[55] is specified and MaturityDate541] is not specified, otherwise extraneous.

MaturityDay 205 Required for options order if MsgType[35] = {8, D, G} and Symbol[55] is specified and MaturityDate[541] is not specified, otherwise extraneous.

MaturityDate 541 Required for options order if MsgType[35] = { D, G} and Symbol[55] is specified and MaturityMonthYear[200] + MaturityDay[205] is not specified, spurious if MsgType[35] = 8 and BeginString[8] = FIX.4.2, otherwise extraneous.

StrikePrice 202 Required for options order if MsgType[35] = {8, D, G} and Symbol[55] is specified, otherwise extraneous.

PutOrCall 201 Required for options order if MsgType[35] = {8, D, G} and Symbol[55] is specified, otherwise extraneous.

SecurityID 48 Required if MsgType[35] = {8, D, G} and Symbol[55] is not specified, significant if MsgType[35] = {8, D, G} and Symbol[55] is specified, otherwise extraneous.

SecurityIDSource 22 Required if SecurityID[48] is specified, otherwise extraneous.

3.5.4 PegInstructions Block


PegOffsetValue 211 Significant if OrdType[40] = {2, P}, otherwise extraneous. Default: value = 0.

PegMoveType 835 Significant if OrdType[40] = {2, P}, otherwise extraneous. Default: value = Floating.

PegOffsetType 836 Significant if OrdType[40] = {2, P}, otherwise extraneous. Default: value = Price.




3.5.5 New Order (Single-Leg) Request Message

Name Tag Specification Standard Header MsgType[35] = D.

TransactTime 60 Always required.

CIOrdID 11 Always required.

Account 1 Always significant. Default: automatic.

Side 54 Always required.

PositionEffect 77 Required if SecurityType[167] = OPT, otherwise extraneous.

HandlInst 21 Always significant. Default: value = 1.

Instrument See named component.

OrdType 40 Always required.

ExecInst 18 Required if OrdType[40] = P, otherwise significant. Default: n/a.

Price 44 Required if OrdType[40] = {2, 4}, otherwise extraneous.

StopPx 99 Required if OrdType[40] = {3, 4, J}, otherwise extraneous.

PegInstructions See named component.

DiscretionInstructions See named component.

Rule80A 47 Always significant. Default: value=A

OrderCapacity 528 Always significant. Default: value=A

OrderQty 38 Always required.

MaxFloor 111 Always significant. Default: n/a.

TimeInForce 59 Always significant. Default: value = 0.

EffectiveTime 168 Significant if TimeInForce[59] = {0, 1, 6}, otherwise extraneous. Default: n/a

ExpireTime 126 Significant if TimeInForce[59] = {0, 1, 6}, otherwise extraneous. Default: n/a.

ExpireDate 432 Required if TimeInForce[59] = 6, otherwise extraneous.

NoTradingSessions 386 Always significant. Default: TradingSessionID[336] = P.

TradingSessionID 336 Required if NoTradingSessions[386] = 1, otherwise spurious.

ExDestination 100 Always significant. Default: automatic.

Standard Trailer




3.5.6 Contingent Orders


ListID 66 Required for linked child orders and should specify ClOrdID or OrderID of parent when submitting an OSO; required in all linked orders when specifying OCO or Bracket (BRK) orders; however; may be a user defined ID.

ContingencyType 1385 Significant if submitting an OCO, OSO or Bracket (BRK) order where multiple orders will be linked.

3.5.7 Order Cancel Request Message

Name Tag Specification Standard Header MsgType[35] = F.



OrigClOrdID 41 Always required.

Account 1 Always extraneous.

OrderQty 38 Always extraneous.

Side 54 Always extraneous.

ClientID 109 Always significant. Default: n/a.

Parties See named component.


Standard Trailer

3.5.8 Order Cancel/Replace Request Message

Name Tag Specification Standard Header MsgType[35] = G.



OrigClOrdID 41 Always required.



Account 1 Copy original request, no change allowed.

Side 54 Copy original request, no change allowed.

PositionEffect 77 Copy original request, no change allowed.

HandlInst 21 Always significant. Default: value = 1.

Instrument Copy original request, no change allowed.

OrdType 40 Always required. Change allowed to 1=Market only.




Name Tag Specification ExecInst 18 Required if OrdType[40] = P, otherwise significant. Default: n/a.

Price 44 Required if OrdType[40] = {2, 4}, otherwise extraneous.

StopPx 99 Required if OrdType[40] = {3, 4, J}, otherwise extraneous.

PegInstructions See named component.

DiscretionInstructions See named component.

Rule80A 47 Copy original request, no change allowed.

OrderCapacity 528 Copy original request, no change allowed.

OrderQty 38 Always required.

MaxFloor 111 Always significant. Default: n/a.

TimeInForce 59 Copy original request, no change allowed.

EffectiveTime 168 Copy original request, no change allowed.

ExpireTime 126 Copy original request, no change allowed.

ExpireDate 432 Copy original request, no change allowed.

NoTradingSessions 386 Copy original request, no change allowed.

TradingSessionID 336 Copy original request, no change allowed.

ExDestination 100 Copy original request, no change allowed.

Standard Trailer

3.5.9 Order Status Request Message

Name Tag Specification Standard Header MsgType[35] = H.


OrdStatusReqID 790 Always significant. Default: n/a.



Side 54 Always extraneous.


Standard Trailer

3.5.10 Execution Report Message


TransactTime 60 Always specified.

ExecID 17 Always specified.

ExecRefID 19 Specified if ExecType[150] = { G,H } or ExecTransType[20] = {1, 2}.

CIOrdID 11 Always specified.

OrigClOrdID 41 Specified per reference request .

OrdStatusReqID 790 Specified per Order Status Request if responding to same.

Order ID 37 Always specified.

Account 1 Specified per reference request, default value may apply.

ExecType 150 Always specified.




Name Tag Specification ExecTransType 20 Specified if BeginString[8] = FIX.4.2.

OrdStatus 39 Always specified.

OrdRejReason 103 Specified if ExecType[150] = 8 and value is compatible with version.

ExecRestatementReason 378 Specified if ExecType[150] = D and value is compatible with version.

Text 58 Specified if ExecType[150] = 8.

LastQty 32 Specified if BeginString[8]=FIX.4.2 or if ExecType[150] = { 1, 2, F, G, H }.

LastPx 31 Specified if BeginString[8]=FIX.4.2 or if ExecType[150] = { 1, 2, F, G, H }.

LastMkt 30 Specified per reference request ExDestination[100].

LeavesQty 151 Always specified.

CumQty 14 Always specified.

AvgPx 6 Always specified.

Side 54 Specified per reference request.

PositionEffect 77 Specified per reference request.

Instrument Specified per reference request.

OrderQty 38 Always specified.

MaxFloor 111 Specified per reference request.

OrdType 40 Always specified.

ExecInst 18 Specified per reference request.

Rule80A 47 Specified per reference request if BeginString[8]=FIX.4.2, default value may apply.

OrderCapacity 528 Specified per reference request if BeginString[8]={FIX.4.3,FIX.4.4}, default value may apply.

Price 44 Specified per reference request.

StopPx 99 Specified per reference request.

PegInstructions Specified per reference request.

DiscretionInstructions Specified per reference request.

TimeInForce 59 Specified per reference request, default value may apply.

EffectiveTime 168 Specified per reference request.

ExpireTime 126 Specified per reference request.

ExpireDate 432 Specified per reference request.

TradingSessionID 336 Specified per reference request, default value may apply.

Standard Trailer

3.5.11 Cancel Reject Report Message


TransactTime 60 Always specified.

CIOrdID 11 Always specified.

OrigClOrdID 41 Specified per reference request.

Order ID 37 Always specified.

Account 1 Specified per reference request, default value may apply.

OrdStatus 39 Always specified.

CxlRejResponseTo 434 Always specified.

CxlRejReason 102 Specified if value is compatible with version.

Text 58 Always specified.




Name Tag Specification Standard Trailer

3.5.12 Business Reject Report Message

Name Tag Specification Standard Header MsgType[35] = j.

RefSeqNum 45 Always specified.

RefMsgType 372 Always specified.

BusinessRejectReason 380 Always specified.

Text 58 Always specified.

Standard Trailer

3.5.13 Request Identification

Client request messages are identified by ClOrdID [11]. Generally, ClOrdID [11] defines a new identifier

that binds to the request that contains it. However, in an Order Status Request message, ClOrdID [11] is

used to reference a previously defined request; it does not define a new identifier.

Values for ClOrdID [11] are determined by the client application. TradeStation only requires that the

value be no more than 26 characters and that it be unique. Length and uniqueness are verified by the

Gateway. If a request specifies an identifier that is too long or not unique, it is rejected.

In actual practice, client request identifiers do not have to be unique forever. However, TradeStation

recommends that they be unique for at least six months. Normal operating procedures may make it

possible to submit a request with an identifier that recycles after one day, but there is no guarantee that

this will work consistently.

Normally, requests associated with closed orders are archived on a daily basis. Archiving affects request

identification in two ways. First, an archived request cannot be referenced. Thus, a collateral request

that references an archived original request will be rejected. Second, archived request identifiers do not

belong to the same unique key set as open request identifiers. Thus, identifiers that have been archived

may be reused.

GT orders may remain open for several months. While GT orders are open, associated request

identifiers are active and unique.

A request will not be archived until all related reports have been delivered to all recipients.




3.5.14 Original Party Identification

TradeStation FIX supports the ability to reference requests that were originally submitted in another

session by another party. This ability is useful in certain oversight scenarios and requires prior

authorization. See “Getting Started” for details.

A client application that needs to cross reference requests must know the original party’s

SenderCompID [49] and the original request ClOrdID [11].

Only collateral request messages may contain an original party specification. An original party is

identified by its SenderCompID [49]. There are two alternate ways to specify an original party.

The simplest way to specify an original party is to use ClientID [109]. In this case, ClientID [109] directly

specifies the SenderCompID [49] used by the original party.

An alternate way to specify an original party is to use a Party Block. In standard FIX, a Party Block may

be used to specify multiple identifiers, but in TradeStation FIX a Party Block may be used to specify only

one original party. PartyID [448] is used to specify the original party’s SenderCompID [49] and all other

fields in the block are “hard coded.”

A client application may choose either method of specification. TradeStation FIX supports both

specifications in all versions. Party Block was not available in standard FIX version 4.2, and ClientID [109]

was deprecated in standard FIX version 4.3. If both specifications are used, ClientID [109] prevails and

Party Block is ignored.

For most collateral messages, when an original party is specified, OrigClOrdID [41] identifies a request in

the original party’s session. In the case of Order Status Request messages, ClOrdID [11] identifies the

original party’s request.

3.5.15 Account Identification

Trading activity is recorded in server-managed accounts. Account identifiers are provided by

TradeStation. Accounts are generally restricted to certain security types or certain kinds of trades and

the client application is responsible for knowing which accounts can be traded under what conditions.

Generally, a New Order Request message will contain an account specification. Use Account [1] to

identify the correct account.

In lieu of an explicit account specification, some client applications may elect to use default account

assignments. Default account assignments are based on security type and are not appropriate in all

cases. See “Getting Started” for more information.




If Account [1] is not specified in a New Order Request, the Gateway will attempt to resolve a default

account. If no default is available, the request will be rejected.

Account identification cannot be changed in an Order Cancel/Replace Request message. If Account [1]

was specified in an original New Order Request, it must be specified again in the subsequent replace

message. Likewise, if Account [1] was originally unspecified, it must not be specified in a subsequent

replace message. Explicit specification cannot follow non-specification, and non-specification cannot

follow explicit specification, even if both resolve to the same account.

3.5.16 Order Transaction Type: Side and Position

Order transaction type defines which side of a trade to take and the effect it has on position. In most

cases, order transaction type is sufficiently specified using Side [54]. However, for option orders,

PositionEffect [77] must also be specified.

To specify an order transaction type for non-option orders, use Side [54]. To open a long position,

specify one of the values {1=Buy, 3=Buy Minus}. To close a long position, specify one of the values

{2=Sell, 4=Sell Plus}. To open a short position, specify one of the values {5=Sell Short, 6=Sell Short

Exempt}. To close a short position, specify {c=Buy to Cover}.

To specify an order transaction type for option orders, use Side [54] and PositionEffect [77]. Only two

Side [54] values are legal. Choose one of the values {1=Buy, 2=Sell} in combination with one of the

PositionEffect [77] values {O=Open, C=Close}. There are four possible transaction types: “Buy to open,”

“Sell to close,” “Sell to open” and “Buy to close.”

Standard FIX requires specification of Side [54] in Order Cancel Request and Order Status Request

messages, but specification is extraneous in TradeStation FIX. A client application may choose not to

specify Side [54] or may choose to specify Side [54] =0 (N/A) as a way to guarantee that every Execution

Report includes a Side [54] specification. An extraneous Side [54] value is copied if and only if an Order

Status Request references an unknown original request.

3.5.17 Transaction Time Stamp

Several application messages must specify TransactTime [60]. Unlike SendingTime [52], which is

determined by the session layer when a message is transmitted, TransactTime [60] is determined by the

application layer when a message is generated.

TransactTime [60] is used to detect stale transactions. Gateway servers compare TransactTime [60] to

current server time as request messages are received. The difference in current server time and




TransactTime [60] is called “request latency.” If request latency exceeds a certain allowance, the

request is rejected.

A standard value for maximum request latency has been defined by TradeStation (see Appendix 4.1).

The standard value may be superseded in individual sessions (see “Getting Started”).

3.5.18 Security Identification

Client applications must have access to externally published data to properly identify a security. A

particular security may be identified using either public exchange identifiers or proprietary TradeStation

identifiers.

Identification generally depends on security type. SecurityType [167] is used to specify type. If

exchange published data is being used, SecurityType [167] controls which identification fields are

significant. If TradeStation data is being used, SecurityType [167] must agree with the identified

security. If SecurityType [167] is not specified, equity identification is assumed.

In the absence of TradeStation proprietary data, exchange-published data must be used to identify the

security. Symbol [55] is used to specify the primary (root) symbol only. Other identification fields are

significant depending on the implicit or explicit value of SecurityType [167], including: SymbolSfx [65],

MaturityMonthYear [200], MaturityDay [205], MaturityDate [541], StrikePrice [202], and PutOrCall

[201].

If TradeStation proprietary data is available, SecurityID [48] and SecurityIDSource [22] should be used to

identify the security. SecurityID [48] is necessary and sufficient for proper identification, but

SecurityIDSource [22] must also be specified to comply with standard FIX. TradeStation data is

referenced by a proprietary SecurityID [22] value “100.” Systems should have the ability to negotiate

proprietary values. Execution reports are generally delivered with reference to TradeStation symbology.

*Note: At this time, TradeStation does not support an API for streaming data delivery. Check with your

TradeStation representative for updates.

Client applications will usually choose one identification method or the other; however, it is not an error

to use both. Dual identifications must resolve to the same security. Server-initiated report messages

always use dual identifications.

Supported identification forms are tabulated below.

Equity Using TradeStation Identifier

Name Tag Value

SecurityID 48 TradeStation-defined identifier

SecurityIDSource 22 100=Private(TradeStation)




Non-equity Using TradeStation Identifier

Name Tag Value

SecurityType 167 { FUT,OPT,FOR}

SecurityID 48 TradeStation defined identifier

SecurityIDSource 22 100=Private(TradeStation)

Common Equity Using Standard Identifier

Name Tag Value

Symbol 55 Exchange listed symbol

Non-common Equity Using Standard Identifier

Name Tag Value

Symbol 55 Exchange listed root symbol

SymbolSfx 65 SIAC defined suffix

Futures Contract Using Standard Identifier

Name Tag Value

SecurityType 167 FUT


MaturityMonthYear 200

Options Contract Using Standard Identifier, Form 1

Name Tag Value

SecurityType 167 OPT


MaturityMonthYear 200

MaturityDay 205

StrikePrice 202

PutOrCall 201 { 0=Put, 1=Call }

Options Contract Using Standard Identifier, Form 2

Name Tag Value

SecurityType 167 OPT


MaturityDate 541

StrikePrice 202




PutOrCall 201 { 0=Put, 1=Call }

Forex Using Standard Identifiers

Name Tag Value

SecurityType 167 FOR

Symbol 55 ISO symbol pair ( / is optional )

3.5.19 Order Type and Price Specification

OrdType[40] specifies an “execution principle” that controls and defines how prices are specified or

calculated. Depending on the value of OrdType [40], the prices specified or calculated may include trade

(buy/sell) prices, reference (peg) prices, and activation (stop) prices.

Supported type and price forms are tabulated below.

Basic Market Order

Name Tag Value

OrdType 40 1 = Market

Basic Limit Order

Name Tag Value

OrdType 40 2 = Limit

Price 44 variable limit price

Discretionary Limit Order

Name Tag Value



DiscretionInst 388 0 = Related to displayed price

DiscretionOffsetValue 389 variable price offset

Stop Market Order

Name Tag Value

OrdType 40 3 = Stop

StopPx 99 variable stop price




Stop Limit Order

Name Tag Value

OrdType 40 4 = Stop Limit


StopPx 99 variable stop price

Market If Touched Order

Name Tag Value

OrdType 40 J = MIT

StopPx 99 variable stop (activation) price

Trailing Stop Order

Name Tag Value

OrdType 40 P = Pegged

ExecInst 18 a = Trailing Stop Peg

PegOffsetValue 211 variable trailing offset, price or tick

PegOffsetType 836 0 = Price 2 = Ticks

Fixed Peg Limit Order

Name Tag Value



ExecInst 18 R =Primary Peg M = Mid-Price Peg P = Market Peg

PegMoveType 1 = Fixed

PegOffsetValue 211 variable peg offset, price or tick

PegOffsetType 836 0 = Price 2 = Ticks

Floating Peg (Limit) Order

Name Tag Value

OrdType 40 P = Pegged

ExecInst 18 R = Primary Peg M = Mid-Price Peg P = Market Peg

PegMoveType 0 = Floating

PegOffsetValue 211 variable peg offset, price only




Continent Order

Name Tag Value

OrdType 40 2 = Limit 4 = Stop Limit


ListID 66 If OSO must be the ClOrdID of parent order in group, if OCO or BRK then may be a user defined value

ContingencyType 1385 1 = One Cancels the Other (OCO) 2 = One Sends the Other (OSO) 3 = TradeStation Bracket Order

3.5.20 Contingency Explained

TradeStation offers a proprietary method for submission of contingent orders. There are three types of

continent orders offered via the TradeStation FIX engine. Order Cancels All (OCA), Order Sends Order

(OSO) and Bracket orders (similar to FIX protocols OUO –One updates the other) are considered

contingent orders because one order’s events directly affect the status and action on another.

An OCA (also known as Order Cancels Order – OCO) order is an order whose execution results in

the immediate cancellation of another order linked to it. Cancellation of the Contingent Order

happens on a best-efforts basis. In an OCO case, both orders are live in the marketplace at the

same time. The execution of either order triggers an attempt to cancel the unexecuted order.

Partial executions will also trigger an attempt to cancel the other order. When submitting an

OCA order to TradeStation, the ListID(66) should be a unique value shared by all orders in the

group accompanied by ContingencyType(1385) = 1.

Example of a TradeStation OCA Order

8=FIX.4.2^9=188^35=D^49=999999^56=TRAD^34=2035^52=20120927-

18:10:40.086^1385=1^66=Linked_22470^11=4876944008622471^21=1^55=IBM^54=1^60=20120927-

18:10:40.086^38=250^40=2^44=.001^59=1^168=20120927-18:11:22^10=060^

8=FIX.4.2^9=176^35=D^49=999999^56=TRAD^34=2036^52=20120927-

18:10:40.187^1385=1^66=Linked_22470^11=4876944018722472^21=1^55=IBM^22=100^54=1^60=20120927-

18:10:40.187^38=1000^40=2^44=0.0002^59=1^10=187^

8=FIX.4.2^9=176^35=D^49=999999^56=TRAD^34=2037^52=20120927-

18:10:40.288^1385=1^66=Linked_22470^11=4876944028822473^21=1^55=IBM^22=100^54=1^60=20120927-

18:10:40.288^38=1000^40=2^44=0.0002^59=1^10=195^




An OSO order involves two (or more) orders: a primary order and a secondary order. The

primary order is a live order generated to the market. The secondary order is held separately

until triggered by action on the first. It is not a market order. If the primary order executes in

full, the secondary order is sent to the market and becomes live. An OSO order can be made up

of stock orders, option orders, or a combination of both. When submitting an OSO order to

TradeStation, the ListID(66) should reference the ClOrdID of the parent order in the group

accompanied by ContingencyType(1385) = 2.

Example of a TradeStation OSO Order

8=FIX.4.2^9=165^35=D^49=999999^56=TRAD^34=2039^52=20120927-

18:10:40.491^11=4876944049122475^21=1^55=IBM^54=1^60=20120927-

18:10:40.491^38=250^40=2^44=.001^59=1^168=20120927-18:11:22^10=160^

8=FIX.4.2^9=180^35=D^49=999999^56=TRAD^34=2040^52=20120927-

18:10:40.592^1385=2^66=4876944049122475^11=4876944059222476^21=1^55=IBM^22=100^54=1^60=20120927-

18:10:40.592^38=1000^40=2^44=0.0002^59=1^10=077^

8=FIX.4.2^9=180^35=D^49=999999^56=TRAD^34=2041^52=20120927-

18:10:40.693^1385=2^66=4876944049122475^11=4876944069322477^21=1^55=IBM^22=100^54=1^60=20120927-

18:10:40.693^38=1000^40=2^44=0.0002^59=1^10=085^

*Notice that in an OSO order the parent order in the group does not contain ListID[66] or ContinencyType[1385]. In

the child orders the ListID is that of the parent ClOrdID.

A Bracket (BRK) order is a contingent order whose execution results in the immediate reduction of quantity in another order linked to it in the order list. The quantity reduction happens on a best-efforts basis. The bracket order is very similar to FIX Protocols OUO – Order Updates Other. Bracket orders are live at the same time. The execution of any of the orders in the order list triggers an attempt to reduce the remaining quantity of the other order(s), partial executions included. Absolute quantity reduction… (means)...instead of canceling the other Contingent Order(s), their quantity is reduced with the same partially filled value. When submitting a BRK order to TradeStation, the ListID(66) should be a unique value shared by all orders in the group accompanied by ContingencyType(1385) = 3. Example of a TradeStation Bracket (BRK) Order 8=FIX.4.2^9=188^35=D^49=999999^56=TRAD^34=2042^52=20120927-

18:10:40.794^1385=3^66=Linked_22478^11=4876944079422479^21=1^55=IBM^54=1^60=20120927-

18:10:40.794^38=250^40=2^44=.001^59=1^168=20120927-18:11:22^10=094^

8=FIX.4.2^9=176^35=D^49=999999^56=TRAD^34=2043^52=20120927-

18:10:40.895^1385=3^66=Linked_22478^11=4876944089522480^21=1^55=IBM^22=100^54=1^60=20120927-

18:10:40.895^38=1000^40=2^44=0.0002^59=1^10=212^

As previously mentioned, TradeStation handles contingent orders in a proprietary manner by utilizing ListID(66) and FIX 5.0 tag ContingencyType(1385) to specify and link New Order Single messages. The New Order Single (35=D) message is used in conjunction with ContingencyType (1385) to indicate OCO,




OSO or BRK type. Orders in a contingency group will use ListID to indicate the ClOrdID of the parent order in the group or a unique list identifier depending on the ContingencyType. All linked messages must contain ContingencyType (1385). The type of continent order must be the same in each subsequent order within in a group. Any order within a continent group may be cancelled at any time.

3.5.21 Quantity Specification

Generally, a quantity specification is a two-part specification that defines (1) how many security units

(shares or contracts) to buy or sell, and (2) what portion of the total should be displayed to the market.

The total number of units to buy or sell is specified by OrderQty [38]. Every New Order Request and

Order Cancel/Replace Request must include an OrderQty [38] specification. Only limit orders

(controlled by OrdType [40]) may specify a display quantity using MaxFloor [111]. If MaxFloor [111] is

not specified (always true for market orders), the total quantity is displayed.

An Order Cancel Request automatically cancels the entire open quantity. To cancel only a portion of the

open quantity, use an Order Cancel/Replace Request.

3.5.22 Time-In-Force Specification

A Time-In-Force (TIF) specification defines an order’s duration. In general, a TIF specification controls

how many days the order will be maintained and the hours it will be worked.

A TIF specification is optional. By default, an order will endure for one day and will be worked during

the course of a nominal “primary” or “regular” session.

The essential field that controls a TIF specification is TimeInForce [59]. Depending on the value specified

for TimeInForce [59], other fields may be significant, including ExpireDate [432], EffectiveTime [168],

ExpireTime [126], and TradingSessionID [ 336].

Several TimeInForce [59] values stand alone and constitute a complete TIF specification. If TimeInForce

[59] is one of the values {2=At the Opening, 3=Immediate or Cancel, 4=Fill or Kill, 7=At the Close}, then

further specification is extraneous.

Closing (CLO) orders may be specified utilizing two variations of FIX tags. FIX Protocol’s initial

introduction for trades entered during an exchange closing session was to introduce a new order type of

Market on Close (5). At a later date, to enhance this order feature, Limit on Close (B) was added to

include Limit functionality. The Protocol eventually rectified the ambiguity by adding a new TimeInForce

[59] = At the Close (7) for this trading duration. TradeStation will accept closing orders with TimeInForce




[59] = 7 (At the Close) and either OrdType [40] = 1 (Market) or 2 (Limit). Alternatively if OrdType [40] is

specified as Market on Close (5), or Limit on Close (B), then orders will be treated as closing orders and

any TIF will be extraneous and ignored.

If TimeInForce [59] is one of the values {0=Day, 1=Good ‘Til Cancel, 6=Good ‘Til Date }, then fields that

specify working hours are significant. The working hour fields are TradingSessionID [336], EffectiveTime

[168], and ExpireTime [126].

If TimeInForce [59] is {6=Good ‘Til Date} then ExpireDate [432] is significant and required.

TradingSessionID [336] specifies working hours in terms of a nominal session period. Only two periods

are available: primary (regular) and extended. The actual hours that an order will be worked depend on

the execution venue and/or security being traded.

Formally, TradingSessionID [336] is a repeating group field. If TradingSessionID [336] is specified, then

NoTradingSessions [386] must also be specified. Only one session identifier may be specified, so

NoTradingSessions [386] is always one.

EffectiveTime [168] and ExpireTime [126] specify exact times for working an order. EffectiveTime [168]

specifies a daily start time, while ExpireTime [126] specifies a daily end time. The date parts of these

fields are syntactically significant but logically insignificant. By convention, the date part must equal the

order transaction date.

3.5.23 Order Routing

TradeStation servers are capable of automatically routing orders to various markets for execution.

Occasionally, however, a client application may want to specify an explicit destination market. An

explicit destination market can be specified using ExDestination [100].

Not every order can be explicitly routed. Currently, only certain routes for equities and options are

supported. See Appendix 4.2 for a list of supported routes.

An application may specify a destination using either FIX defined codes or ISO defined codes.

In Execution Reports, explicit routes are echoed in LastMkt [30].

3.5.24 Order Modification

An open order can be modified using an Order Cancel/Replace Request message, but only certain

changes are allowed. Generally, an order’s type cannot change unless it is changed to a simple market




type. A change in price specification is allowed for non-market orders and a change in quantity

specification is allowed for any order. Other changes are not allowed.

3.6 Supported Fields

3.6.1 Compatibility

TradeStation’s FIX implementation is based on the 4.4 standard, but support for earlier standard 4.2 is

also provided. Client applications based on 4.2 can incorporate newer fields and values by extension of

the earlier standard. Similarly, earlier fields and values that are obsolete in later standards can still be

used by extension of the later standard. Currently, there are no custom or proprietary fields

implemented in any version; however, there are a few cases where standard fields have been extended

with TradeStation proprietary values.

Generally, if a client application utilizes extended fields or values in a request message, it should be

prepared to handle the same fields and values in a server generated report message. Standard

applications may need less adaptation because Gateway servers will not utilize extensions unless they

are initiated by the client.

In the Schedule of Fields that follows, fields and values that aren’t universal are flagged. A field or value

marked by a numeric superscript indicates a specific compatibility condition. Indicators and conditions

are tabulated below.

Indicator Condition

1 Field added in 4.3

2 Field removed in 4.3

3 Value added in 4.3

4 Value removed in 4.3

5 Field added in 4.4

6 Field removed in 4.4

7 Value added in 4.4

8 Value removed in 4.4

9 TradeStation proprietary value

Given some base standard, an indicated field or value is an extension to that standard if it is added to a

later standard or removed from an earlier standard. A proprietary value is an extension to every

standard.

Unscheduled fields are not supported. If an unsupported field is coded in a message, the message will

be rejected by the session layer.




3.6.2 Schedule of Fields

Tag Name Type Definition

1 Account String Identifies an account. Values are provided by TradeStation.

6 AvgPx Price Specifies average fill price for one order. Value is calculated from cumulative trades.

7 BeginSeqNo SeqNum Specifies a message sequence number. Value identifies first message in a contiguous resend batch.

8 BeginString String Delimits and labels a message. FIX.4.2 FIX.4.4 Must be first field in message.

9 BodyLength Length Specifies a nominal message length. Value equals total number of bytes in all fields between BodyLength[9] and CheckSum[10] (exclusive). Must be second field in message.

10 CheckSum String Delimits and validates a message. Value is 3 digit modulo sum calculated per FIX specification.

11 ClOrdID String Identifies a request message. Value is determined by client. It must be unique to client for recommended period of six months. Maximum length is 26 characters. When specified in a request message, value is definitive. When specified in a report message, value is referential. For cross-client applications, value = NONE in a report message indicates there is no corresponding FIX request.

14 CumQty Qty Specifies sum of shares or contracts filled for one order. Value is calculated from cumulative trades.

16 EndSeqNo SeqNum Specifies a message sequence number. Value identifies last message in a contiguous resend batch. Value = 0 means infinity, i.e. batch includes all messages beyond and including the one identified by BeginSeqNo[7].

17 ExecID String Identifies a report message. Value is determined by server. TradeStation value is internally unique forever. Value = 0 for status reports. (ExecType[150] = I).

18 ExecInst MultiValueString Specifies one or more order execution modes. G = All or None M = Mid Price Peg P = Market Peg R = Primary Peg a = Trailing Stop Peg

7

f = Intermarket Sweep 7

{a, R, M, P} are mutually exclusive.





19 ExecRefID String Identifies a report message. Value references a prior report on the same order. Used to report a cancelled or corrected trade.

20 ExecTransType 2

char Specifies a type of execution report. 0 = New 1 = Trade cancelled 2 = Trade corrected 3 = Status

21 HandlInst Char Specifies broker handling instructions. 1 = Automated Execution Order (Private)

22 SecurityIDSource String Specifies a source for SecurityID[48]. 100 = Private (TradeStation)

30 LastMkt Exchange Specifies execution venue where order was routed or filled. See Appendix for supported values.

31 LastPx Price Specifies a fill price. Value is fill price for a reported trade (ExecType[150] = {1, 2, F, G, H}).

32 LastQty (aka LastShares)

Qty Specifies a number of shares or contracts filled. Value is fill quantity for a reported trade (ExecType[150] = {1, 2, F, G, H}).

34 MsgSeqNum SeqNum Defines ordinal position of message in session. Values start at one and increment during the course of a session.

35 MsgType String Specifies a message type. 0 = Heartbeat 1 = Test Request 2 = Resend Request 3 = Message Reject 4 = Sequence Reset 5 = Logout 8 = Execution Report 9= Cancel Reject Report A = Logon D = New Order (Single-Leg) Request F = Order Cancel Request G = Order Cancel/Replace Request H = Order Status Request Must be third field in message.

36 NewSeqNo SeqNum Specifies a message sequence number. Value must be greater than the current expected sequence number for a given logical sequence (see GapFillFlag[123]).

37 OrderID String Identifies an internal order record. Value is determined by server. TradeStation value is internally unique forever. Value = NONE can be used to satisfy syntax requirement when field is semantically void.

38 OrderQty Qty Specifies requested number of shares or contracts.





39 OrdStatus Char Specifies current state of an order. 0 = New 1 = Partially Filled 2 = Filled 3 = Done for Day 4 = Cancelled 5 = Replaced

4

6 = Pending Cancel 8 = Rejected A = Pending New C = Expired E = Pending Replace

40 OrdType Char Specifies a pricing principle (order type). 1 = Market 2 = Limit 3 = Stop 4 = Stop Limit 5 = Market on close B = Limit on close J = Market if touched

3

P = Pegged Type controls price specification.

41 OrigClOrdID String Identifies a request message. Value references a prior request on the same order. Used to request cancellation or replacement of the order.

43 PossDupFlag Boolean Indicates a duplicate message. Y = Possible duplicate N = Original transmission Y indicates that a message is being retransmitted with original sequence number and may duplicate a message already received in the same session.

44 Price Price Specifies a limit price.

45 RefSeqNum SeqNum Identifies a rejected message. Value is copied from MsgSeqNum[34] of rejected message.

47 Rule80A 2 Char Identifies order type with respect to SEC rules.

A=Agency single order

48 SecurityID String Identifies a security. Values are defined by TradeStation. Specification is case sensitive.

49 SenderCompID String Identifies a client session Value is provided by TradeStation.

52 SendingTime UTC Timestamp Specifies message transmit time. Value is determined by sender when message is transmitted.





54 Side Char Specifies an order transaction type. 0 = N/A

9

1 = Buy 2 = Sell 3 = Buy Minus 4 = Sell Plus 5 = Sell Short 6 = Sell Short Exempt c = Buy to Cover

9

Value = 0 can be used to satisfy syntax requirement when field is semantically extraneous.

55 Symbol String Specifies a security’s primary symbol. Values are defined by listing exchange. Specification is case sensitive.

56 TargetCompID String Identifies a receiving firm. Value = TRAD.

58 Text String Explains reason for rejection. Value determined by sender.

59 TimeInForce Char Specifies duration of an order. 0 = Day 1 = Good ‘Til Cancel (GTC) 2 = At The Opening 3 = Immediate or Cancel (IOC) 4 = Fill or Kill (FOK) 6 = Good Till Date (GTD) 7 = At The Close

60 TransactTime UTC Timestamp Specifies message origination time. Value is determined by sender when message is generated.

65 SymbolSfx String Specifies an equity class suffix. Values are defined by listing exchange. Punctuation, if any, is explicit

66 ListID Introduced for support of OCO, OSO and Bracket orders with contingent relationships. For OSO orders must reference the ClOrdID of the primary/parent order in the group.

77 PositionEffect (aka OpenClose)

Char Specifies transaction effect on option position. O = Open C = Close

97 PossResend Boolean Indicates a redundant message. Y = Possible resend N = Original transmission Y indicates that a message is being retransmitted with a new sequence number and may duplicate a message already received in the same session.

98 EncryptMethod Int Specifies an encryption method. 0 = None

99 StopPx Price Specifies a stop price.

100 ExDestination Exchange Specifies an execution venue. See Appendix for supported values.





102 CxlRejReason Int Specifies a reason for request rejection. 0 = Too late 1 = Unknown order 3 = Previous request is pending 6 = Duplicate ClOrdID

3

99 = Other 7

Used to reject a cancel or cancel/replace request. There may be other reasons for rejection not enumerated by this field. Text[58] always explains these reasons and others.

103 OrdRejReason Int Specifies a reason for request rejection. 5 = Unknown order 6 = Duplicate ClOrdID 8 = Stale order 99 = Other

7

Used to reject a new order request. There may be other reasons for rejection not enumerated by this field. Text[58] always explains these reasons and others.

108 HeartBtInt Int Specifies a minimum message transmission interval. Value range is defined by TradeStation. See Appendix for details.

109 ClientID 2 String Identifies party that originally submitted a request.

Value is SenderCompID[49] of original party. May be used instead of PartyID[448].

111 MaxFloor Qty Specifies a maximum order display quantity. If value = 0, the order will not be displayed.

112 TestReqID String Identifies a Test Request message. Value determined by sender.

122 OrigSendingTime UTC Timestamp Specifies original message transmit time. Value copied from original message SendingTime[52]. May use current SendingTime[52] in lieu of original value.

123 GapFillFlag Boolean Indicates a skip in resend sequence number. Y = This is a gap fill, skip resend sequence number N = This is not a gap fill, skip session sequence number.

126 ExpireTime UTC Timestamp Specifies daily order deactivation time. Date part must equal transaction date. Value is significant to the minute; seconds are ignored (truncated).

141 ResetSeqNumFlag Boolean Indicates that message sequence numbers should be reset during logon. Y = do reset N = do not reset





150 ExecType Char Specifies a type of execution report. 0 = New order acknowledge 1 = Partial fill

4

2 = Fill 4

3 = Done for Day 4 = Order cancelled 5 = Order replaced 6 = Cancel request pending 8 = Order rejected A = New order pending C = Order expired D = Restatement E = Replace request pending F = Trade made

3

G = Trade corrected 3

H = Trade cancelled 3

I = Status 3

151 LeavesQty Qty Specifies number of shares or contracts that remain to be filled. Value generally expresses difference between OrderQty[38] and CumQty[14]. However, for closed orders, value= 0.

167 SecurityType String Specifies a type of security. FUT = Future OPT = Option FOR = Foreign Exchange Contract

168 EffectiveTime UTC Timestamp Specifies a daily order activation time. Date part must equal transaction date. Value is significant to the minute; seconds are ignored (truncated).

200 MaturityMonthYear MonthYear Specifies a month and year of maturity for futures and options.

201 PutOrCall Int Specifies an option type. 0 = Put 1 = Call

202 StrikePrice Price Specifies a strike price for options.

205 MaturityDay DayofMonth Specifies a day of maturity for options.

211 PegOffsetValue ( aka PegDifference)

Float Specifies a reference price (peg) offset amount. Value is constrained by transaction type (see Side[54]).

336 TradingSessionID String Specifies a nominal trading session P = primary (regular) X = extended

371 RefTagID Integer Identifies a rejected field. Value is a field tag number.

372 RefMsgType String Specifies type of rejected message. Value is copied from rejected message MsgType[35].





373 SessionRejectReason Integer Specifies a reason for message rejection. 0 = Invalid tag number 1 = Required tag missing 2 = Tag not defined for this message type 3 = Undefined Tag 4 = Tag specified without a value 5 = Value is incorrect (out of range) for this tag 6 = Incorrect data format for value 7 = Decryption problem 8 = Signature problem 9 = CompID problem 10 = SendingTime accuracy problem 11 = Invalid MsgType 12 = XML Validation error

3

13 = Tag appears more than once 3

14 = Tag specified out of required order 3

15 = Repeating group fields out of order 3

16 = Incorrect NumInGroup count for repeating group 3

17 = Non “data” value includes field delimiter 3

99 = Other 7

378 ExecRestatementReason Integer Specifies a reason for restatement. 1 = GT renewal 99 = Other

7

380 BusinessRejectReason Integer Specifies a reason for business rejection. 3 = Unsupported message type 4 = Application not available

386 NoTradingSessions NumInGroup Cues TradingSessionID[336] repeating group. Value: { 0, 1 }

388 DiscretionInst Char Enables limit order price discretion. 0 = Related to displayed price

389 DiscretionOffsetValue Float Specifies a discretion amount. Value cannot be zero. Sign of value is constrained by transaction type (see Side[54]).

432 ExpireDate LocalMktDate Specifies date that order expires.

434 CxlRejResponseTo Char Specifies a type of cancel reject report. 1 = Cancel 2 = Cancel/Replace

447 PartyIDSource 1 Char Specifies a source for PartyID[448].

D = Proprietary code (TradeStation)

448 PartyID 1 String Identifies party that originally submitted a request.

Value is SenderCompID[49] of original party. May be used instead of ClientID[109]

452 PartyRole 1 Int Specifies a type for PartyID[448].

3 = Client ID

453 NoPartyIDs 1 NumInGroup Cues PartyID[448] repeating group.

Value: { 0, 1 }

528 OrderCapacity 1 Char Designates capacity of firm placing order.

A=Agency

541 MaturityDate 1 LocalMktDate Specifies a date of maturity for options.

554 Password 1 String Specifies a session password. Value provided by

TradeStation.





790 OrdStatusReqID 5 String Identifies a status request message.

Value determined by client.

835 PegMoveType 5 Integer Specifies a price calculation method.

0 =Floating 1 = Fixed

836 PegOffsetType 5 Integer Specifies units for PegOffsetValue[211].

0 = Price 2 = Ticks

1385 ContingencyType 1 = One Cancels the Other (OCO) 2 = One Sends the Other (OSO) * 3 = TradeStation Bracket Order (BRK)

*Must be combined with ListID[66], where ListID is the ClOrdID of the parent order in the contingent order group for

OSO orders.




4 Appendix

4.1 Operating Parameters

Parameter Value

Weekly Standard Session Hours Start: Sunday, 17:00 UTC Stop: Saturday, 13:00 UTC

Standard Max Transaction Latency 20 seconds

Heartbeat Interval Range { 15, …, 180} seconds

Production TCP/IP Port 11030 - 11099

SIM TCP/IP Port 11100 – 11119

UAT TCP/IP Port 10980 - 10989

4.2 Explicit Routes

Entity Security Type FIX Code ISO Code TradeStation Code

American Stock Exchange EQU N XNYS AMEX

American Stock Exchange OPT 1 N XNYS AMOP

BATS Exchange EQU 54 BATS BATS

BATS Exchange OPT 54 BATO BAOP

Bloomberg TradeBook EQU 31 BLTD BTRD

Boston Options Exchange OPT 60 XBOX BOX

C2 OPT (n/a) C2OX C2

Chicago Board of Options Exchange OPT W XCBO CBOE

Credit Suisse EQU n/a CRED CSFB

Direct Edge ECN EQU 57 EDGA EDGA

Direct Edge ECN EQU 56 EDGX EDGX

GFLO EQU (n/a) GFLO* GFLO

GMNI OPT (n/a) GMNI GMNI

IEX EQU (n/a) IEXG IEXG

International Securities Exchange OPT Y XISX ISE

Knight Capital Markets EQU (n/a) KNIG NITE

Miami OPT (n/a) XMIO MIAX

NASDAQ EQU OQ XNAS XNDQ

NASDAQ BX EQU OQ XNAS NQBX

NASDAQ Options NOM OPT OQ XNAS NOBO

New York Stock Exchange EQU N XNYS NYSE

NYSE ARCA EQU N XNYS ARCA

NYSE ARCA OPT N XNYS NYOP

Philadelphia Options Exchange OPT X XPHO PHLX




4.3 Contact Information

FIX API Emergency and Support

(954) 652-7660 1 (800) 328-5242 [email protected]


mailto:[email protected]

TradeStation FIX Gateway - Amazon S3 · The TradeStation FIX Gateway is a communication service...

Documents

Transcript of TradeStation FIX Gateway - Amazon S3 · The TradeStation FIX Gateway is a communication service...