Skip to main content

INTX FIX Common Components

Standard Header

Fields that go at the beginning of every message.

8BeginStringStringYMust be set to FIXT.1.1

Since FIX version 5.0 this field represents the session version. The application version gets specified in Logon message's DefaultApplVerID (1137) tag.
9BodyLengthIntYMessage length in bytes up to the checksum field, must be the second field in message
35MsgTypeStringYThe type of message proceeding the header, must be the third field in the message. Supported values include:

All Sessions
A = Logon
0 = Heartbeat
1 = TestRequest
3 = Reject
5 = Logout

Order Entry
D = NewOrderSingle
F = OrderCancelRequest
G = OrderCancelReplaceRequest
8 = ExecutionReport
9 = OrderCancelReject
F1 = LastExecIDRequest
F2 = LastExecID

Market Data
x = SecurityListRequest
y = SecurityList
d = SecurityDefinition
V = MarketDataRequest
Y = MarketDataRequestReject
W = MarketDataSnapshotFullRefresh
X = MarketDataIncrementalRefresh

Drop Copy
8 = ExecutionReport
F1 = LastExecIDRequest
F2 = LastExecID
F3 = EventResendRequest
F4 = EventResendComplete
F5 = EventResendReject
49SenderCompIDStringYThe API key assigned by the exchange.
56TargetCompIDStringYDefined based on the type of FIX session:

CBINTLOE = Order Entry
CBINTLMD = Market Data
CBINTLDC = Drop Copy
34MsgSeqNumIntYMonotonically increasing sequence number
97PossResendBooleanCIndicates if the message may have already been sent with a different sequence number. This is useful when performing an application level replay on the drop copy session.

N = Original transmission
Y = Possible resend
52SendingTimeUTC timestampYTime the message was transmitted, expressed in UTC, microseconds: YYYYMMDD-HH:MM:SS.ssssss

Standard Trailer

Fields that go at the end of every message

10CheckSumStringYThree byte checksum calculated by summing every byte in the message up to and not including the checksum field itself. This value is then moduloed by 256 and written with prefixed 0s (if necessary) to meet the 3 byte requirement.


A repeating group of identifiers that indicates components of the user model (e.g. portfolio) affiliated with the message.

453NoPartyIDsintCMarks the beginning of the Parties repeating group component. Currently a max of 1 party is supported to specify the portfolio UUID. In the future additional parties may get added.

Supported values:
1 = Specify portfolio UUID or client UUID

If no party is specified the message applies to the default portfolio UUID affiliated with the API key.
→ 448
PartyIDstringCThe unique identifier used to represent the party entry.
→ 452
PartyRoleintCThe type of party entry that the PartyID (448) value represents. Currently supports:

3 = Client ID
24 = Customer account

The Customer Account (24) value indicates the PartyID value contains the UUID of the portfolio affiliated with the message. The Client ID (3) value indicates the PartyID value contains the UUID of a client managed by the broker (only applies to brokers).

Was this helpful?