ICE-FIX TradeCapture Reference Manual 2 0 30-1

________________________________________________________________
ICE-FIX Trade Capture Reference Manual

FIX Protocol Support Document
Version 2.0.30
November 2012
__________________________________________________________________
This material may not be reproduced or redistributed in whole or in part without the express, prior
written consent of IntercontinentalExchange, Inc.
 Copyright Intercontinental Exchange, Inc. 2012. All Rights Reserved.

www.theice.com
Table of Contents
1 About This Manual................................................................................................................ 6
1.1 Notes and Warnings ........................................................................................................ 6
1.2 Conventions ..................................................................................................................... 6
1.3 Required Tags.................................................................................................................. 6
2 Introduction ........................................................................................................................... 7
2.1 Products Supported.......................................................................................................... 7
2.2 System Architecture ........................................................................................................ 7
2.3 Connectivity Management............................................................................................... 7
2.4 Failover ............................................................................................................................ 8
2.5 FIX Protocol Version Support ......................................................................................... 8
2.6 ICE-FIX Trade Capture application support ................................................................... 9
2.6.1 Reporting and Tracking issues ................................................................................ 9
2.6.2 Contacts ................................................................................................................... 9
3 Session Management ............................................................................................................. 9
3.1 Session Configuration ................................................................................................... 10
3.2 Session Reset ................................................................................................................. 10
3.3 Session Startup .............................................................................................................. 10
3.4 Session Maintenance ..................................................................................................... 10
3.4.1 Logon Request Message ........................................................................................ 11
3.4.2 Logon Response Message ..................................................................................... 11
3.4.3 Reject (Session Level): .......................................................................................... 11
3.4.4 Sequence gaps fill process ..................................................................................... 12
3.4.5 Test Requests and Heartbeats ................................................................................ 12
4 Supported Application Message Types.............................................................................. 12
4.1 News Messages and Throttling Limits .......................................................................... 13
4.1.1 News ...................................................................................................................... 13
4.1.2 Throttling Limits ................................................................................................... 14
4.2 FIX Request Messages .................................................................................................. 14
4.2.1 Security Definition Request................................................................................... 14
4.2.2 Trade Capture Report Request .............................................................................. 15
4.3 FIX Response Messages ................................................................................................ 17
4.3.1 Security Definition Response ................................................................................ 17
4.3.2 Trade Capture Report Request Ack ....................................................................... 21
4.3.3 Trade Capture Report ............................................................................................ 22
5 Common Message Components ......................................................................................... 30
5.1 Message Header............................................................................................................. 30
5.2 Message Trailer ............................................................................................................. 30
6 Custom Field Definitions .................................................................................................... 31
7 Supported Security Types................................................................................................... 33
8 Contract Naming Convention ............................................................................................ 33
Appendix A: Party Role Definitions ......................................................................................... 34
Appendix B: ICE FIX Trade Capture Semantics.................................................................... 37
Appendix C: ICE FIX Trade Capture Request Matrix .......................................................... 38
ICE-FIX Trade Capture Reference Manual – V2.0.30 – Date: November, 2012 Page 2 of 39
www.theice.com
Revisions
Version Date Completed By Description of Changes

1.0.0 09/24/07 André Weathers Initial draft and added session logon.
Added TradeCaptureReportRequest, TradeCaptureReportResponse
1.0.1 10/30/07 Sanjay Rane
and Security Definition message sections
1.0.2 12/11/07 Nathaniel Riley Revised document and modified section 1
1.0.3 12/12.07 Vijaya Manne Added appendix 7 (Java Trade Capture API to FIX Fields Mapping)
1.0.4 12/12/07 Sanjay Rane Revised document and added new sections 2, 3,4,5 and 6
Added TradeCaptureReportRequestAck message section 4.3.2 and
1.0.5 01/03/08 Sanjay Rane
Tag 654 LegRefID on TradeCaptureReport message
Replaced following tags with FIX 4.4 version tags
1. SecurityType (167) - CFICode (461)
2. UnderlyingPutOrCall - UnderlyingCFICode (463)
Added tag
1.0.6 02/15/08 Sanjay Rane
1. LegCFICode(608)
Removed tag
1. PutOrCall (201)
Removed Tag 553 (UserName) from News message and added Tag
1.0.7 02/25/08 Sanjay Rane 58 (Text) in section 4.3.3 - Trade Capture Report message
Updated comments to several fields. Reordered fields in Trade

1.0.8 02/29/08 Alan Mobley Capture Report message to maintain fields in a single component
together.
Added Appendix B: Party Role Definitions
Updated comment for tag 568 TradeRequestID in Trade Capture
1.0.9 04/02/08 Alan Mobley Report Request.
Added explanation of when Trade Capture Report Request Ack
messages are sent.
Edited Tags in Trade Capture Request:
453: added a description
1.0.10 04/25/08 Kristin Werner 461: List values for futures and options
48 and 711: edited description and added a warning about inter-
commodity spreads
Section 4.2.2 Edited Tags in Trade Capture Request:
Section 4.3.1 added tags 916 and 917 start and end date
1.0.11 06/19/08 Kristin Werner
Section 4.3.3 edited the description in tag 48
Appendix B added party roles 57-59
Section 4.3.3 added comments in tag 202
Section 4.3.3 added tag 150 Exec Type
1.0.12 07/28/08 Kristin Werner Appendix A edited tags 9017 and 452
Added supported market types
Appendix B added party role 1
Added Appendix C Symbology
1.0.13 08/14/2008 Kristin Werner Section 4.3.1 added tag 998 Unit of measurement in security
definition response
Section 4.3.1 added tag 9100 Price Unit and tag 9200 Strip type in
security definition response
Section 4.3.1 removed tag 326 security status
Removed section 4.1.2 Security Status
Section 4.3.1 added tag 436 UnderlyingContractMultiplier, tag 9201
1.0.15 12/17/2008 Kristin Werner StripId, and tag 9300 HubId in security definition response
Appendix B Clearing Firm Name
Section 4.3.1 added tag 9085 Granularity in security definition
response
www.theice.com
Section 6 added Price Unit, Strip Type, Strip Id, Hub id, Granularity
Section 7 added Supported Security Types 42 ECX, 43 CCFE, 44
Henry Hub
Added new supported value (“0”) for tag 9200“Strip type” [Section
4.3.1]
Added tag 9085 “Granularity” [Appendix A>Security Definition
Response]
Edited tag 9100 renamed as “PriceDenomination” [Section 4.3.1, 6
and Appendix A>Security Definition Response]
Added supported values for contra trades for TrdTyp (828) [Section
4.3.3]
Deleted “1” as a valid value for tag 828 “TrdType” [Appendix A >
Trade Capture Report Response]
Updated new FIX sample messages for Security Definition request
[Section 4.3.1]
Added following new tags [Section 4.3.1, 6 and Appendix
A>Security Definition Response]:
9062-ProductName.
9101-PriceUnit
1.0.17 02/03/2009 Ashish Gadre 9202-StripName
9301-HubName
9302-HubAlias
Added following new tags [Section 4.3.3, 6]
9020-LegStartDate
9021-LegEndDate
Added new market types [Section 7]:

297-Cleared Cocoa Swap
298-Cleared Coffee C Swap
299-Cleared Sugar No 11 Swap
Added <NestedParties> component block [Section 4.3.3]

539 NoNestedPartyIDs
=> 524 NestedPartyID
=> 525 NestedPartyIDSource
=> 538 NestedPartyRole
Section 4.3.1 added tag 9024 LotSizeMultipler in security definition
response
Section 4.3.3 added tag 9022 NumofCycles, 9023
LegNumofCycles, 9403 Options Symbol in trade capture report
Removed Contract Symbol Structure
Section 4.1.1 News message added values for tag 61
Added new supported strip type for tag 9200 25=Bundle
Section 4.3.1 tag 9024 LotSizeMultipler in security definition
response is optional
Section 6 added LotSizeMultiplier, NumofCycles,
LegNumofCycles, OptionsSymbol
Section 4.3.1, Section 6 and Appendix A removed Currency,

BaseNumLots, NumBlocks, Cleared Alias, Initial Margin,
LotMultiplier, Product Type, Denominator
Section 4.3.1 added 9025 Clearable 9063ProductDescription
Added Appendices C & D.
Section 7 contents moved to ICE homepage.
Added URL for Contract naming convention doc available on ICE
1.1.21 09/01/09 Ashish Gadre homepage.
Corrected Data type for 9025 from Boolean to Char (Section 6)
Minor corrections, sorted Party Role table (Appendix B), added
more explanation for various tags/messages.
www.theice.com
Section 4.3.1 added NumofCycles tag 9022

Appendix B added Party role 12 Executing Trader and Clearing
Organization tag 21
Section 4.3.3 added No Allocs Tag 78, AllocAccount tag 79,
NoNestedParties2 tag 756, Nested2PartyID tag 757,
Nested2PartyIDSource tag 758 and Nested2PartyRole tag 759
Removed previous Appendix A (Java API to FIX tags mapping)
Appendix B – Added more explanation for “Live” subscription.
Corrected the spec version.on front page.
Section 4.3.1 – Added new StripType 26 (Barge)
2.0.22 03/11/10 Ashish Gadre – Corrected the tag order for security definitions
Section 4.3.3 – Added explanation about deal change/bust behavior
for spread reports.
Section 4.3.3 – Added new tradeType (828) “A”
Other minor updates/corrections.
2.0.23 09/01/10 Kristin Werner Section 4.3.3 added tag 1126= OrigTradeID
Section 4.3.3 – added tag 1017 LegOptionRatio
2.0.23 09/01/10 Ashish Gadre Added section 3.4.5
Other minor updates.
Section 4.3.1 – Added more explanation for tag 542
2.0.24 04/04/11 Ashish Gadre
Section 4.3.3 – Corrected the order of tag 1017
Section 4.3.1 –Added new Strip Type Laycan
Section 4.3.3-Added new Platts fields tag 9510
TermsQualityComments and 9500 NumOfCombiDefinitions and
9501-9505
Section 4.3.3-Added a note for tag 9018
Appendix A- Added values for party role 54
2.0.26 01/05/12 Kristin Werner Section 4.3.3-Added value for tag 828 I- EFM Trade
Section 4.3.1- Added value for 323 and 9200- customBalMonth
2.0.27 03/05/12 Kristin Werner Section 4.3.3- Edited explanation for replace spread trades, added
value for tag 828 Q-EOO trades, added tag 9404 LegOptionSymbol
Added new tag ClientAppType (9413) under following sections:
2.0.28 07/27/12 Ashish Gadre • Section 4.3.3
• Section 6
Section 4.3.3- Added tag 820 TradeLinkID, tag 9414
2.0.29 09/05/12 Kristin Werner TradeLinkMktID, tag 376 ComplianceID, tag 9425 BillingCode
Section 4.3.3 and Section 6 Added tag 9376 LegComplianceID and

2.0.30 11/13/2012 Kristin Werner tag 9426 LegBillingCode
www.theice.com
1 About This Manual

The purpose of this manual is to detail ICE’s Trade Capture functionality via the FIX protocol. Trade
Capture functionality will enable a firm to request live and historical trades in the markets the firm
participates in.
The intended audience of this manual is FIX client developers and other interested parties including project
managers and business development. It will assist developers who need to integrate their FIX client
application with the ICE FIX host and the exchange’s trading platform. Throughout this manual the ICE
FIX system will be referred as FIX host.
1.1 Notes and Warnings
In regards to setting off noteworthy or important text, this manual uses the following convention:
Convention Description
Note: Emphasizes important or essential information
Indicates user must absolutely follow this instruction to prevent a serious

Warning problem such as data loss or program failure
1.2 Conventions
This manual uses a set of terms, symbols, and typographic conventions to categorize specific
information. Familiarity with these conventions will help you use this documentation more effectively:
Convention Use
Bold Indicates FIX message types and other information to highlight the importance.
Courier New, 10pt Sample code, arguments, properties, arguments, methods, events, or anything that
you must type exactly as it appears. When found in the body of the manual (i.e.,
paragraphs), this text is also in bold.
* Denotes multi-use tags.
Tag Id Denotes repeating group inside a message (1 level deep)
Tag Id Denotes repeating group within a repeating group inside a message ( 2 level deep)
1.3 Required Tags
The manual uses the following terminology as to whether particular message requires a certain tags.
You will find these terms in the “Required” column in each message type table:
Always: The FIX message must include this Tag.
www.theice.com
Conditional: If a particular condition is met, then the FIX message must include this Tag.
Optional: Although the FIX message does not require this tag, you can use it to provide any additional
business benefit as needed.
2 Introduction
ICE offers a FIX-based interface for real-time deal capture. This interface enables trading participants
to receive real-time notifications for all trades done by participants in the same firm. It also supports a
request to query historical trades for a given set of markets and time window.
2.1 Products Supported
ICE Futures UK Yes

ICE Futures US Yes
CCFE Futures Yes
Options Yes
OTC Cleared Yes
OTC Bilateral Yes
2.2 System Architecture
The FIX host system consists of multiple FIX engines and each one works independently. There
is no direct communication between each other. A FIX client that wants connect to the FIX hosts they will
get one common IP address and hardware load balancer F5 will manage the connection with one of the FIX
engine. The scenarios about load balancing and failure are described later in this document.
Following figure illustrate high level architecture of the ICE FIX system
FIX FIX
Client 1 Node - 1
FIX
Client 2
TCP/IP Connection FIX ICE Trading

F5 Node - 2 Platform
FIX
Client 3
FIX FIX
Client 4 Node (3...n)
2.3 Connectivity Management
www.theice.com
The ICE system manages and load balances connections based on source IP address. The host
connection IP address and port will be given to a FIX client to use it as target IP and port into their
application. Each FIX client must initiate a TCP/IP socket connection to establish communication link
between their application and with the FIX host. The load balancer will determine which FIX engine node
it should use to connect. Once client establishes a network connection with a particular node it will persist
there, until it is disconnected. The following example explains how connectivity will be handled at FIX
host for a FIX sessions.
Assume Client-1 connects to Node-1; all requests from Client-1 will be forwarded to only Node-1
until FIX session ends or if there is node failure. In short, a FIX client will be served by only one node
during one trading day.
Client connection will be monitored by sending and receiving Heartbeat (Tag 35, MsgType=0)
messages to ensure the connectivity between both parties. Normally Heartbeat message interval is set to 30
seconds however; this can be configured for convenient duration.
NOTE: If client loses TCP/IP connection and reconnects to ICE FIX host, then client
must reset it’s inbound and outbound message sequence numbers to 1 and send next
Logon message with tag 141=Y to reset session on FIX host side.
2.4 Failover
In an incident of a node failure, load balancer will detect that and it will forward all consecutive
messages to next available active node. In this case client has to reset its session and begin communication
as like beginning of the day.
Scenario 1: Session transition during failover
1. Client-1 sends Logon message and F5 forwards that to Node-1.

2. Node-1 creates sessions for Client-1 as Session1.
3. Node-1 fails and Client-1 loses connectivity.
4. Client-1 sends a logon message and F5 forwards that to Node-2.
5. Node-2 sends a logon response with a sequence number lower than Client-1 expects
6. Client-1 closes the connection because the sequence number is lower than expected
7. Client-1 sends Logon message with MsgSeqNum=1 by resetting their Inbound and
Outbound message sequence number to 1 and setting tag 141 (ResetSeqNumFlag) to "Y".
(As like first time login of the day)
8. Client-1 will now remain on Node-2 until end of the session.
2.5 FIX Protocol Version Support
The FIX host supports a subset of message types and associated tags of the FIX protocol
according to FIX 4.4 specifications (available at http://www.fixprotocol.org) and the rules defined in this
reference manual.
Warning: The ICE FIX host supports the use of only those tags that are described in this manual. Do not
submit additional tags to the FIX host. Doing so can cause unexpected results.
www.theice.com
2.6 ICE-FIX Trade Capture application support
2.6.1 Reporting and Tracking issues
The helpdesk is the first point of contact for any production environment issues. If necessary, issues will be
escalated to the API Development Support Team.
All support requests must be submitted via our support web portal at www.theice.com/integrate.
When you log a ticket within Integrate it is routed directly to the respective Support Team(s) based on the
ticket classification improving response times to your inquiries and issue resolution.
You are required to have a user ID and password for submission via this web portal. In order to
obtain an ID, please send an email to integrate@theice.com requesting an ID and password. We strongly
recommend that all clients establish an ICE Support Email alias on your side that we can link the login ID.
This will help to insure that all members of your team are aware of issues that are being reported and
resolved.
2.6.2 Contacts
ICE-FIX Trade Capture API Production Support
If necessary, issues will be escalated to the API Development Support Team.

Helpdesk - United States Helpdesk - Europe & Asia
(770)738-2101 020 7488 5100
icehelpdesk@theice.com londonhelpdesk@theice.com
8:00pm EST Sunday - 7:00am - 6:00pm GMT
5:30pm EST Friday Monday - Friday
(24 hours per day)
ICE-FIX Trade Capture API Development Support
Please create a support ticket by login on to www.theice.com/integrate

This support site may be used for any issues or queries that may be encountered in the test environments
during the development and testing phase of FIX API applications. Please include as much detail as
possible on the tickets.
You can request a userID and password for the integrate site by send an email to integrate@theice.com
3 Session Management
A FIX session is defined as a bi-directional stream of ordered messages between the ICE FIX host
and FIX clients within continues sequence number series. A FIX client can connect and disconnect multiple
www.theice.com
times while maintaining a single FIX session. Every FIX client will have only one active FIX session and it
will be created based on preconfigured session information.
Warning: If you have multiple FIX sessions to the exchange, please insure that your session logons are
staggered by at least 1 second upon logon to the exchange each day. Failure to do so could result in loss of
messages from the exchange.
3.1 Session Configuration
For new counterparties who want to establish a relationship with ICE FIX, they need to first
complete initial business/legal formalities. Counterparty can request one or many FIX sessions to configure
based on their need. Each FIX session will be identified by required Tag 49 (SenderCompId), Tag 50
(SenderSubId) and Tag 56 (TargetCompId) is always set to ICE. The Other parameters such as
Heartbeat interval are required to configure to manage fix a sessions. If these values are not provided then
they will be set to defaults such as, Tag 108 (HeartBtInt) set to 30 seconds.
3.2 Session Reset
All FIX sessions will be reset by FIX host after every 24 hours i.e. beginning of the next trading day
(during maintenance window between 6:30 PM to 7:30 PM EST/EDT). So every trading day all FIX clients
have to reset their inbound and outbound message sequence numbers to 1. The session can be reset
differently based on individual need e.g. it could be between login and logout or after 24 hours. If clients
want to reset their sessions during the day, they can send Logon message with Tag 141
(ResetSeqNumFlag) set to Y and Tag 34 (MsgSeqNum) set to 1.
3.3 Session Startup
To startup a FIX session, client has to connect to FIX host via TCP/IP by using given IP address and
port. Immediately after establishing the connection, client has to send Logon message with required tags.
FIX host requires user name and password to authenticate the session initiator. So client must send Logon
with Tag 49 (SenderCompId) set to <CompanyID>, Tag 50 (SenderSubID) set to
<senderSubID>, Tag 56 (TargetCompId) set to “ICE”, 553 (UserName) set to <sessionID>
for the Trade Capture logon and Tag 554 set to <password>.
If ICE trading system accepts client’s login request, then in response, FIX host sends FIX Logon
with Tag 108 (HeartBtInt). In case of login failure then, FIX host sends FIX Logout with Tag 58
(Text) set to logon rejection cause.
NOTE: Only ONE SenderSubID can be used at any given time, with a FIX TC user ID. You can’t use a
new SenderSubID for currently logged in FIX TC user, nor can you use a different FIX TC
userID with the same SenderSubID (and compID) as that of any logged in session.
3.4 Session Maintenance
When maintaining a session FIX host supports the use of following Administrative message types:
• Logon Message with Tag 35 (MsgType) set to A
• Heartbeat Message with Tag 35 (MsgType) set to 0
• Logout Message with Tag 35 (MsgType) set to 5
www.theice.com
• Test Request with Tag 35 (MsgType) set to 1

• Resend Request with Tag 35 (MsgType) set to 2
• Reject (Session Level) with Tag 35 (MsgType) set to 3
• Sequence Reset (Gap Fill) with Tag 35 (MsgType) set to 4
3.4.1 Logon Request Message
In order to begin a FIX session communication with the ICE FIX host, client has to initiate a
TCP/IP session to a given IP address and port and send a logon request message to the exchange. There is
a throttle limit of 1 logon request per 15 seconds. Any other logon attempts within those 15 seconds will be
rejected. The client login message must contain standard header and trailer with following tags defined.
Message Direction: FIX Client to FIX Host
Tag # Field Name Required Additional Comments
553 UserName Always User id of a FIX session
554 Password Always Password.
98 EncryptMethod Always Based on the requirement tag can be used to support

different types of encryption.
Default value set to 0 (i.e. clear text)
Indicates both side of a FIX session should reset sequence
141 ResetSeqNumFlag Conditional numbers.
108 HeartbeatInt Always Session heart beat interval, default value 30 seconds.
3.4.2 Logon Response Message

The FIX host sends logon message as a response to the successful login into the ICE trading
platform. The message will have standard header, trailer and other required fields along with application
fields.
Message Direction: FIX Host to FIX Client

98 EncryptMethod Always This is the encryption method sent by the client
108 HeartbeatInt Always This is the heartbeat interval for the session
3.4.3 Reject (Session Level):
The ICE-FIX server sends Reject (Session Level) when a messages is received but cannot be
properly processed due to a session-level rule message violation e.g. if server receive message with invalid
basic data or cannot be parsed or fails to data integrity check, in this cases the ICE-FIX server will reject
the message and reply with session level reject.. In other cases you will receive appropriate rejects based on
www.theice.com
incoming message. The Reject (Session Level) will be sent with Tag 35 (MsgType) set to 3 and
followed with the standard trailer.
45 RefSeqNum Y MsgSeqNum of rejected message
371 RefTagID N The tag number of the FIX-field being referenced

372 RefMsgType
N The MsgType of the FIX message being referenced.
373 SessionRejectReason
N Code to identify reason for a session-level Reject
message.
58 Text
N Reason for rejection
354 EncodedTextLen
N EncodedText field
355 EncodedText
N Encoded (non-ASCII characters) representation of the
Text field in the encoded format specified via the
Message Encoding field.
3.4.4 Sequence gaps fill process
If any message from a FIX client indicates a sequence gap, the FIX host sends a Sequence Resend
message. In response, FIX client has to send requested messages to fill up a gap. Sequence reset message
can be used by client to reset the incoming sequence number on the FIX host side.
3.4.5 Test Requests and Heartbeats

Whenever the FIX host detects that messages were not received within the negotiated heartbeat
interval (tag 108 on logon message) it will send a Test Request message with a TestRequestID (tag 112).
FIX client must respond immediately with a Heartbeat message containing the same tag 112 as received in
the Test Request earlier. FIX Host will terminate the session if it doesn’t receive the expected response
within 4-5 seconds of sending the Test Request message.
4 Supported Application Message Types

This manual discusses only those message types and associated tags (including custom tags) as
supported by the ICE FIX host. Two custom message types are supported by the FIX host to handle
specific requirements.
www.theice.com
The ICE FIX host accepts the following message types (referred to hereafter as outgoing message
Types):
All Administrative messages
Security Definition Request with Tag 35 (MsgType) set to c
Trade Capture Report Request with Tag 35 (MsgType) set to AD
The ICE FIX host sends the following message types (referred to hereafter as incoming message
types). The sequence of fields within all outgoing messages will be the same as they are listed in following
sections.
All Administrative messages

Security Definition with Tag 35 (MsgType) set to d
Trade Capture Report Request Ack with Tag 35 (MsgType) set to AQ
Trade Capture Report with Tag 35 (MsgType) set to AE
Business Message Reject with Tag 35 (MsgType) set to j
o Tag 380 (BusinessRejectReason) may be sent with a value of “9”. Please make a
note of this and add this value to your data dictionary as FIX protocol only
supports till “7”.
News with Tag 35 (MsgType) set to B
For further information on a specific message type, refer to the appropriate section. Each message
starts with the header section and ends with the trailer (see the Chapter “Message Header and Trailer”).
4.1 News Messages and Throttling Limits
4.1.1 News
The ICE FIX host sends this message to inform to a fix client that there is a message from market
servers. This message is prefixed with the standard header and trailer with Tag 35 (MsgType) set to B.
Following fields will be in the message.
148 HeadLine Always Market server message code
61 Urgency Always Priority of the market server notification

0 = Normal
1 = Flash
2 = Background
3 = Error
33 LinesOfText Always Number of message lines
58 Text Conditional Always exist if Tag 33 value > 0
www.theice.com

An array of text messages
Note: In News messages that contain settlement prices, it’s possible to receive “=” characters imbedded in the
messages.
4.1.2 Throttling Limits
The trade capture report request will have throttle limits that are configured on a session-level. If
a trade capture request causes you to exceed your configured throttle limits, then you will receive a
business reject message. The default throttle limits are as follows:
• Trade Capture Report Request – 2000 msg/sec
4.2 FIX Request Messages
4.2.1 Security Definition Request
The security definition request is also supported over order entry sessions. The Security Definition
Request proceeds by a standard header with Tag 35 (MsgType) set to c, and followed with the standard
trailer. The Security Definition Request contains the following FIX tags:
320 SecurityReqID Always Unique Security Definition Request Id.
321 SecurityRequestType Always This field will always be set to 3 (Request List Securities)
48 SecurityID Always Value of this tag is SecurityID or ICE MarketType name to request
security definition. For Valid values please refer
https://www.theice.com/publicdocs/technology/Supported_Market_Types_on_ICE_API.pdf
461 CFICode Always Valid Values

FXXXXX – Futures
OXXXXX - Options
Examples: Security Definition Request.
By number:
8=FIX.4.49=9535=c49=3656=ICE34=15950=252=20090216-
17:05:08.881320=1321=348=2461=FXXXXX10=058
8=FIX.4.49=9535=c49=3656=ICE34=16750=252=20090216-
17:08:20.550320=2321=348=2461=OXXXXX10=059
By name:
www.theice.com
8=FIX.4.49=9735=c49=3656=ICE34=16050=2 52=20090216-
17:05:20.802320=3321=348=Oil461=FXXXXX10=026
8=FIX.4.49=9735=c49=3656=ICE34=16550=252=20090216-
17:07:25.410320=4321=348=Oil461=OXXXXX10=043
4.2.2 Trade Capture Report Request
FIX clients can receive trades snapshot and updates by sending Trade Capture Report
Request.
The ICE-FIX host supports only two days of trade history (Current + previous trading
day). The dates and times sent as tags 75 and 60 must be from the current or previous trading day.
Any other dates sent can result in incomplete data.
For markets that roll intraday and expired markets we recommend that you keep the previous
trading day’s security definition for historical trade capture requests.
The trade capture request message must contain a standard header with MsgType of
‘AD’ and trailer with following tags defined. For a comprehensive list of different scenarios
based on different valid values of the required tags in a FIX Trade Capture Report Request,
please refer Appendix C.
Appendix B gives a schematic representation of the typical subscription model ICE FIX
TradeCapture is based on.
NOTE: If the request failed to process then the FIX host will send a Trade Capture Request Ack
(MsgType=AQ) as a response with tag 749 set to 99.
568 TradeRequestID Always Must be unique, or the ID of previous Trade Capture Report
Request to disable if SubscriptionRequestType =
Unsubscribe (2).
569 TradeRequestType Always Valid values

0 : All trades
263 SubscriptionRequestType Always User can request trade history by sending value 0
(Snapshot). Exchange supports only two days of deal history
(i.e. Current day + previous trading day)
Valid values
0 : Snapshot
1: Snapshot + Updates
2: Unsubscribe
www.theice.com
453 NoPartyIDs Optional Absence of this field is interpreted as subscribe to all

company (s) that user has access to.
448 PartyID Conditional Required if 453 value > 0, can be used to send company ids
to subscribe or unsubscribe markets.
447 PartyIDSource Conditional Required if 453 value > 0, Value can be used as D
452 PartyRole Conditional Required if 453 value > 0, Valid Values

3 – Client ID (i.e. Company ID from ICE system)
461 CFICode Optional Valid Values:

FXXXXX: Futures only
OXXXXX: Options only
Absence of this field is interpreted as FXXXXX and
OXXXXX.
48 SecurityID Optional Value of this tag is SecurityID or ICE MarketType name to

request trade capture reports. For valid values please refer
“Supported Security Types Section 7”.
NOTE: If neither this tag nor 711 is present it is
interpreted as to subscribe to all markets.
A snapshot request is always for “all” markets for the

current company. So this tag is applicable only for live
requests.
711 NoUnderLyings Optional Absence of this field is interpreted as to subscribe to all

symbols/markets that come under given SecurityID.
NOTE: If neither this tag nor 48 is present it is
interpreted as to subscribe to all markets..
A snapshot request is always for “all” markets for the
current company. So this tag is applicable only for live
requests.
311 UnderlyingSymbol Conditional Required if 711 tag value > 0, can be used to subscribe
subset of markets from one market type.
580 NoDates Conditional Required if 263=0

If 263=1 and this field is absent then it is interpreted as
only to subscribe for updates and do not send snapshot.
Number of date ranges provided (must be 1 or 2 if
specified)
NOTE: If 580=1 then snapshot will be sent using
TradeDate and TransactTime as StartDateTime and
current GMT time will be used as EndDateTime.
75 TradeDate Conditional Always required if 580 > 0
www.theice.com

Date should be the same as in Tag 60 in YYYYMMDD
format
60 TransactTime Conditional Always required if 580 > 0

Value should be in GMT date and time
Format YYYYMMDD-HH:mm:SS or YYYYMMDD-
HH:mm:SS.sss
4.3 FIX Response Messages
4.3.1 Security Definition Response
In response to security definition request, the FIX host sends one or more messages to inform all the
securities those can be traded on the ICE trading platform. The Security Definition messages are prefixed
by a standard header with Tag 35 (MsgType) set to d, and suffixed with the standard trailer.
322 SecurityResponseID Always Unique identifier for Security Definition Response
323 SecurityResponseType Always This field will always be set to 4 (List Securities)
when the request has been accepted.
For rejected requests, when you have no permission
to security type, it is set to 5
For rejected requests, it is set to 6 (Can not match
selection criteria)
320 SecurityReqID Always It’s same value that’s received from Security
Definition Request Tag 320
393 TotNoRelatedSym Conditional Total number of securities in this security type unless
security definition requested is invalid.
NOTE: This field is used here by design although
it is not part of the Security Definition Response as
per the FIX protocol.
82 NoRpts Conditional Total count of messages that will be sent as a

response of the request. Always exists if Tag 393
exists.
per the FIX protocol.
67 ListSeqNo Conditional Sequence of the message (i.e. ListSeqNo of NoRpts,
www.theice.com

1 of 10, 2 of 10,...). This field can be used to identify
remaining messages to receive as a part of this
response. Always exists if Tag 393 exists.
per the FIX protocol. Can be used to validate
whether correct number of security def. messages
have been received or not. Last 35=d message
(only when 711>0) should always have tag 82 = tag
67
711 NoUnderlyings Conditional Total number of securities in this security definition

response message. Always exists if Tag 393 exists.
311 UnderlyingSymbol Conditional Contains the MarketID (Symbol) needed to submit

orders. Always exist if Tag 711 value > 0 Value is
market id
NOTE: Contents of this tag can be mapped to the
tag 55 value received in a FIX Trade Capture
report. Hence this tag’s value can be used as a key
while caching security definition information.
309 UnderlyingSecurityID Optional Contract symbol
305 UnderlyingSecurityIDSou Conditional Contract symbol source, Always exist if Tag 309
rce exists
463 UnderlyingCFICode Conditional Valid Values

FXXXXX – Futures
OXXXXX – Options
307 UnderlyingSecurityDes Conditional Always exist if Tag 711 value > 0 Value is market
name
542 UnderlyingMaturityDate Conditional Always exist if Tag 711 value > 0 YYMMDD
NOTE: The options expiry is found in this tag if
CFI code is set to OXXXXX.
436 UnderlyingContractMulti Conditional Always exist if Tag 711 value > 0

plier
9013 IncrementPrice Conditional Always exist if Tag 711 value > 0
9014 IncrementQty Conditional Always exist if Tag 711 value > 0
9017 LotSize Conditional Always exist if Tag 711 value > 0
9022 NumofCycles Optional Remaining days left to a flow contract.
NOTE: For markets that roll intra-day, this field may

be inaccurate after they roll as FIX TC doesn’t get the
roll notification as of now.
www.theice.com
9024 LotSizeMultiplier Optional Clearable products only
9025 Clearable Conditional Y = Clearable

N = Not Clearable
916 StartDate Optional Start Date of the market strip

Please account for this change since this does not
follow the FIX Protocol
NOTE: This field is also available on FIX TC
report message
917 EndDate Optional End Date of the market strip

Please account for this change since this does not
follow the FIX Protocol
NOTE: This field is also available on FIX TC
report message
9201 StripId Conditional Always exist if Tag 711 value > 0
9200 StripType Conditional Always exist if Tag 711 value > 0

0- Hourly
1- Spot
2- Same Day
3- Within Day
4- Next Day
5- Day Ahead
6- Bal Week
7- Next Saturday
8- Next Sunday
9- Weekend
10- Next Week
11- Bal Month
12- Month
13- Custom
14- Period
15- Quarter
16- Year
17- Spread
18- Cash
19- Bal Quarter
20- Bal Year
21- Half Month
www.theice.com

22- Today
23- Tplus
24- Yesterday
25- Bundle
26- Barge
27- Laycan
28- customBalMonth
100- Rolling
9202 StripName Conditional Always exist if Tag 711 value > 0
9300 HubId Conditional Always exist if Tag 711 value > 0
9301 HubName Conditional Always exist if Tag 711 value > 0
9302 HubAlias Conditional Always exist if Tag 711 value > 0
998 UnderlyingUnitOfMeasure Conditional Always exist if Tag 711 value > 0

Physical unit of measure for derivative products
9100 PriceDenomination Conditional Always exist if Tag 711 value > 0
9101 PriceUnit Conditional Always exist if Tag 711 value > 0
9085 Granularity Optional
9083 NumOfDecimalPrice Conditional Always exist if Tag 711 value > 0
9084 NumOfDecimalQty Conditional Always exist if Tag 711 value > 0
9061 ProductId Optional
9062 ProductName Optional
9063 ProductDescription Optional
9032 TickValue Optional
9002 ImpliedType Optional Valid Value:

F – Full Spread
9004 PrimaryLegSymbol Optional Exists for spread products.
9005 SecondaryLegSymbol Optional Exists for spread products.
9400 IncrementStrike Optional Exists for options
www.theice.com
9401 MinStrike Optional Exists for options
9402 MaxStrike Optional Exists for options
58 Text Optional
4.3.2 Trade Capture Report Request Ack
This message is used to provide an acknowledgment to a valid TradeCaptureReport

Request. The Trade Capture Report Ack messages are prefixed by a standard header with Tag 35
(MsgType) set to AQ, and suffixed with the standard trailer.
A Trade Capture Request Ack will be sent immediately after a request is received. The status will
be set to 0 (Accepted) or 2 (Rejected). If rejected, there will be more information in tag 58. Once a request
for snapshot data has been completed a second ack message will be sent with status set to 1 (Completed).
The result may be 0 (Successful) or 99 (Other) if there has been an error while retrieving the snapshot data.
For a request for snapshot + updates, messages received after the second ack message are the updates. For
updates only request, there will be only the initial ack message – no completed ack message.
568 TradeRequestID Always Request ID if the Trade Capture Report is in response to

a Trade Capture Report Request
569 TradeRequestType Always Type of Trade Report, valid values

0 : All Trades
749 TradeRequestResult Always Valid values:

0: Successful
99: Other
750 TradeRequestStatus Always Valid values:

0: Accepted
1: Completed
2: Rejected
461 CFICode Optional Valid Values

FXXXXX – Futures
OXXXXX – Options
48 SecurityID Optional Contract identifier/symbol

Please note we currently do not support symbology for
OTC so you may receive a generic symbol for OTC
www.theice.com

markets
711 NoUnderlyings Always Absence of this field is interpreted as to subscribe to all

symbols/markets that come under given SecurityID.
NOTE: If this tag is absent then tag 48 must exist on
this message.
311 UnderlyingSymbol Conditional Required if 711 tag value > 0, can be used to subscribe
subset of markets from one market type.
58 Text Optional Provides more information if result is unsuccessful or

status is rejected.
4.3.3 Trade Capture Report
Based on market subscription FIX client will receive trade capture reports snapshot and
real time trades thru this FIX message. User will receive one trade capture report for each side of
the deal. Following scenarios will help to understand how reports will be sent for outright and
spread deals
Outright Deals
1. User company is a party on Buy OR Sell side of the deal

• User will receive only one trade capture report with tag 552 (NoSides) = 1
2. User company is a party on both Buy AND Sell of the deal (Self Trading)
• User will receive two trade capture reports with tag 552 (NoSides) = 1 for each
side of the deal
Spread Deals
1. User company is a party on Buy OR Sell side of the deal

• User will receive only one trade capture report with tag 552 (NoSides) = 1 and
tag 555 (NoLegs) = 2 (two spread legs)
• Deal Change
i. If there was a deal change by either the user or the counterparty then the
user will receive FIX TC report for only that part of the spread which
was changed (This is only applicable to live subscription, for snapshots it
will still be one single tradecapture report).
ii. This notification may be sent for just spread or any of the legs depending
on where the change was done. Please test your application’s ability to
handle such messages (separate messages for the spread and its legs).
The spread parent trades will have the same clientOrdID (tag 11) on
them. ExecType will be “5” (150=5) to indicate that the actual trade has
been replaced in some way.
www.theice.com
iii. If only the leg was changed, then a separate FIX TC report for the leg is
sent. You can identify this spread component by matching the
execID(tag 17) on this report with the previously received spread
report’s LegRefIDs(tag 654). Each leg on a spread FIX TC report has its
deal ID under tag 654.
2. User company is a party on both Buy AND Sell side of the deal (Self Trading)
• User will receive two trade capture reports with tag 552 (NoSides) = 1 and tag
555 (NoLegs) = 2 (two spread legs) for each side (tag 54) of the deal .
• For a deal change, the behavior would be same as mentioned above under 1) for
both sides of the deal.
Trade Capture Report (TC report), can be for the snapshot request or for the live
subscription. The two reports can be differentiated by looking at tag 150(ExecType). ExecType is
available “only” on a “live” subscription report (report which is being received as a result of
“live” subscription request).
The Trade Capture Report messages are prefixed by a standard header with Tag 35
(MsgType) set to AE, and suffixed with the standard trailer.
571 TradeReportID Always Unique identifier of trade capture

report
487 TradeReportTransType Always Identifies Trade Report message

transaction type, valid values
0 : New
856 TradeReportType Optional Type of Trade Report, valid

values
0 : Submit
568 TradeRequestID Optional Request ID if the Trade Capture

Report is in response to a Trade
Capture Report Request
828 TrdType Optional Type of trade, valid values

0 : Regular Trade
K: Block Trade
E: EFP Trade
S: EFS Trade
V: Bilateral Off-Exchange Trade
O: NG EFP/EFS Trade
9: CCX EFP Trade
J: EFR Trade
www.theice.com

T – Contra Trade
Y – Cross Contra Trade
F – EFS/EFP Contra Trade
A - Other Clearing Venue
I – EFM Trade
Q- EOO Trade
1126 OrigTradeID Optional Used to preserve original trade

id when original trade is being
referenced in a subsequent
trade transaction .
This ID will be present only on
the trades resulting from
bust/adjust and will contain the
DealID of the original trade
that was bust/adjusted.
NOTE: This is a FIX 5.0 tag
reused in FIX 4.4, hence you’ll
need to add it to FIX 4.4 data
dictionary.
150 ExecType Conditional Describes the reason the trade

capture report is sent.
Please note that this tag will
not be sent on a snapshot report
hence you should refer to
OrdStatus(tag 39) for those.
For update requests, these are
the valid values:
5 = Replace
F = Trade (partial fill or fill)
H = Trade Cancel
***WARNING***: It is
possible to get a duplicate
trade capture report with an
ExecType of 5 even if nothing
has changed on your side of
the trade.
820 TradeLinkID Optional Deal id that links the futures

market trade to the OTC market
trade.
NOTE: The TransactTime (tag
60) for both the futures and OTC
trade will be the same.
9414 TradeLinkMktID Optional Market id that links the futures

market to the OTC market
www.theice.com
17 ExecID Always Exchange Deal ID

NOTE: This value is unique per
day/mkt/side and hence can be
reported more than once on a
given day for a company.
39 OrdStatus Optional Identifies current status of order,

valid values
2 : Filled
4 : Canceled
570 PreviouslyReported Always Indicates if the trade capture report

was previously reported to the
counterparty. Valid values
N : not reported to counterparty
Y : previously reported to
counterparty
NOTE: If tag 487 value = 0 then
value of this tag will be always
set to N otherwise it will be Y
55 Symbol Always Market Id
48 SecurityID Optional Contract identifier/symbol

Please note we currently do not
support symbology for OTC so
you may receive a generic symbol
for OTC markets
22 SecurityIDSource Conditional Exist only if 48 exists, valid value

8: ExchSymb
461 CFICode Always Valid values

FXXXXX – Futures
OPXXXX – Put
OCXXXX - Call
202 StrikePrice Conditional Required if value of tag 461 is

O*XXXX, i.e. the trade is in an
options market
9403 OptionsSymbol Optional Trades in predefined option

markets
916 StartDate Optional In format, YYYYMMDD, used to

report custom strips on bilateral
trades
www.theice.com
917 EndDate Optional In format, YYYYMMDD, used to

report custom strips on bilateral
trades
32 LastQty Always Always value of trade quantity
31 LastPx Always Price of this (last) fill.
9018 NumOfLots Always Trade quantity represented in

number of lots
Note: This tag should be ignored
for spread trades
9022 NumOfCycles Always Remaining days left to a flow

contract
75 TradeDate Always Indicates date of trade occurred

YYYYMMDD
60 TransactTime Always Indicates time of trade occurred

HH:MI:SS.000
9413 ClientAppType Identifies the source which

Always
generated the current FIXTC
report.
Following are the valid values:

0 - WEBICE
1 - FIXOS
2 - FIXML
3 - YJBLOCK
4 - OTHER
5 - FPML
6 - UPS
7 - MOBILE
8 - POF
9 - YJISV
9500 NumOfCombiDefinitions Optional Repeating group used to convey

Platts specific fields
9501 CombiPercentage Optional Returns what percentage of the

combi is assigned to if more than 1
combi is used
9502 CombiPriceBasis Optional Returns the pricing basis for Platts

combi deals
www.theice.com
9503 CombiPriceBasisPeriod Optional Returns the Platts basis period ex:

Full month, quarter, 5 days, etc
9504 CombiPriceBasisSubLevel Optional Returns the selected sub level
9505 CombiLegPrice Optional Returns the price of the combi leg
9510 TermsQualityComments Optional Terms of Platts deal
552 NoSide Always Total number of sides will be

always 1.
54 Side Always Trade side
37 OrderID Always Exchange OrderID
11 ClOrdID Optional Client OrderID
453 NoPartyIDs Optional Repeating group represents

information about entities such as
counterparty, clearing firm,
clearing account etc.
448 PartyID Conditional Required if 453 > 0
447 PartyIDSource Conditional Required if 453 > 0 Always set to

D
452 PartyRole Conditional Required if 453 > 0,

See Appendix A for valid values.
376 ComplianceID Optional Unique Swap Identifier
9425 BillingCode Optional The billing code is used to mark

deals with a numerical value that
determines how a counterparty
will be billed. This is only
applicable to Griffin market types.
Will always be set to “1”
58 Text Optional
78 NoAllocs Optional Always 1
79 AllocAccount Conditional Allocation Account

Only if 78>0
NOTE: Value will default to

"N/A" if left blank while
submitting the order
www.theice.com
756 NoNested2PartyIDS Conditional Valid values 1 or 2

Only if 78>0
757 Nested2PartyID Conditional Valid values:

A or G, if 759=62
Clearing firm name if 759=4
Only if 756>0
758 Nested2PartyIDSource Conditional Always D= Proprietary/Custom

Code.
Only if 756>0
759 Nested2PartyRole Conditional Clearing firm = 4

Give up type = 62
Only if 756>0
555 NoLegs Optional Total number of trade spread legs

added into this report
600 LegSymbol Conditional Required if 555 value is > 0
602 LegSecurityID Optional Contract identifier/symbol

Exist only for Options and
Bilateral custom strip trades
603 LegSecurityIDSource Optional
608 LegCFICode Always Valid values

FXXXXX – Futures
OPXXXX – Put
OCXXXX - Call
612 LegStrikePrice Optional Exist only if this leg is option leg
9404 LegOptionSymbol Optional Exist only if this leg is option leg
624 LegSide Conditional Required if 555 value is > 0
637 LegLastPx Conditional Required if 555 value is > 0
687 LegQty Conditional Required if 555 value is > 0
1017 LegOptionRatio Optional Contains the hedge ratio value in

percentage.
e.g., If the hedge ratio for the
futures on the UDS is 20% (1017=
20) and the options qty is 200 lots,
you would get 40 Futures as your
www.theice.com

hedge.
Type: int
NOTE: This is a FIX 5.0 tag
reused in FIX 4.4, hence you’ll
need to add it to FIX 4.4 data
dictionary. Also please note that
datatype has been customized to
be an “int” instead of a “float”
654 LegRefID Conditional Required if 555 value is > 0, this is

leg TradeID
9019 LegNumOfLots Conditional Required if 555 value is > 0

Spread leg quantity represented in
number of lots
9023 LegNumOfCycles Conditional Required if 555 value is > 0
9020 LegStartDate Conditional Required if 555 value is > 0

Start date for the leg markets
9021 LegEndDate Conditional Required if 555 value is > 0

End date for the leg markets
539 NoNestedPartyIDs Optional Repeating group used to convey

liquidity information for the legs
Required if 539 > 0.
524 NestedPartyID Conditional Same values as in 448
525 NestedPartyIDSource Conditional Required if 539 > 0.

Always set to D
538 NestedPartyRole Conditional Required if 539 > 0.

Same values as that in
Partyrole<452>.
See Appendix A for valid values.
9376 LegComplianceID Optional
9426 LegBillingCode Optional
www.theice.com
5 Common Message Components

Every message sent to a FIX client will have some of the common message fields. Instead of
repeating these tags in each section of this document, those are added here later reference.
5.1 Message Header
This is the common message header for all supported messages. It must be exist in both incoming
and outgoing message types.
8 Begin String Always
9 Body Length Always
35 MsgType Always
49 SenderCompID Always Company ID value
56 TargetCompID Always Always set to ICE
34 MsgSeqNum Always
50 SenderSubId Always Configured value in FIX adapter (Provided by ICE).

SenderSubIDs are unique per SenderCompID, meaning
two users can’t use the same SenderSubID with a given
SenderCompID, in parallel.
43 PossDupFlag Conditional Required for resent messages
122 OrigSendingTime Never We don’t send the original sending time.
52 SendingTime Always
5.2 Message Trailer
This is the common message trailer for all supported messages. It must be exist in both incoming
and outgoing message types.
10 CheckSum Always
www.theice.com
6 Custom Field Definitions

This section provides detail information of each custom field that is used by the ICE FIX host.
Following field definition can be used to understand usage of the field and your application.
Tag # Field Name Data Additional Comments

Type
9002 ImpliedType char Valid Value:

F – Full Spread
9003 ImpliedIndicator char Valid values:

Y – Yes
N – No
9004 PrimaryLegSymbol string Contains the primary month MarketId, or symbol, for spread
products.
9005 SecondaryLegSymbol string Contains the secondary month MarketId, or symbol, for spread
products.
9061 ProductId int Unique product id
9013 IncrementPrice float The minimum increment price for this market
9014 IncrementQty float The minimum increment quantity for this market
9017 LotSize int The lot size is minimum size of contracts in lots. It is multiplier to
determine the total lots
9018 NumOfLots int Trade quantity represented in number of lots
9019 LegNumOfLots int Spread leg quantity represented in number of lots
9020 LegStartDate LocalMkD Start date for the leg markets

ate
9021 LegEndDate LocalMkD End date for the leg markets

ate
9025 Clearable Char Tells whether a market is Cleared or Bilateral. Possible values are
‘Y’ and ‘N’. This tag will return “Y” even if the market is
“Cleared or Bilateral”. Please note that for such markets (“Cleared
or Bilateral” and 9025=Y) you might receive a deal done
bilaterally.
9083 NumOfDecimalPrice int Number of decimals to display on price for this product (non-
options)
9084 NumOfDecimalQty int Number of decimals to display on qty for this product (non-
options)
9032 TickValue float
www.theice.com

Type
9400 IncrementStrike Price
9401 MinStrike Price
9402 MaxStrike Price
9100 PriceDenomination string It’s the denomination the contract trades in e.g., USD, GB pence,
USD cents
9101 PriceUnit string It’s the denomination per unit for the price, e.g. USD/bbl.
9200 StripType int
9201 StripId int
9300 HubId int
9085 Granularity string
9062 ProductName string
9063 ProductDescription string
9202 StripName string
9301 HubName string
9302 HubAlias string
9376 LegComplianceId string
9022 NumofCycles int
9023 LegNumofCycles int
9024 LotSizeMultiplier float
9403 OptionsSymbol string
9413 ClientAppType int Used to indicate the source application for the deal. Can be used to
differentiate WebICE deals from FIXOS deals.
9414 TradeLinkMktID int Market id that links the futures market to the OTC market
9425 BillingCode int
9426 LegBillingCode int
9500 NumofCombiDefinitions NumInGro Repeating group used to convey Platts specific fields
up
www.theice.com

Type
9501 CombiPercentage int Platts specific field: Returns what percentage of the combi is
assigned to if more than 1 combi is used
9502 CombiPriceBasis string Platts specific field: Returns the pricing basis for Platts combi
deals
9503 CombiPriceBasisPeriod string Platts specific field: Returns the Platts basis period ex: Full month,
quarter, 5 days, etc
9504 CombiPriceBasisSubLev string Platts specific field: Returns the selected sub level
el
9505 CombiLegPrice Price Platts specific field: Returns the price of the combi leg
9510 TermsQualityComments string Platts specific field: Terms of Platts deal
7 Supported Security Types

This section provides security types that ICE supports. The values from this table can be
used in Security Definition Request message for Tag 48 (SecurityID).
Contents of this section are now available under following URL on ICE website:
https://www.theice.com/publicdocs/technology/Supported_Market_Types_on_ICE_API.pdf
8 Contract Naming Convention

Latest ICE contract naming convention document can be accessed at following URL:
https://www.theice.com/publicdocs/technology/Instrument_Naming_Convention.pdf
www.theice.com
Appendix A: Party Role Definitions

The following table provides a description of the various party roles that may be included
in the PartyIDs repeating group and when each can be used.
For cleared trades there is a distinction between a locally-managed account (LMA) and a
system-managed account (SMA). To trade on the ICE platform a user needs to have an individual
trader mnemonic (ITM), i.e. locally-managed account, or a clearing account, i.e. system-managed
account. The ITM is set-up while creating a user profile and traderID by ICE User
Administration. The clearing account is setup by the clearing firm and associated to the trader by
the member firm.
Party Role Description Usage
1 = Executing Firm Name of firm executing Trades executed by a broker company on

the trade behalf of the originating firm
4 = Clearing Firm ID of clearing firm All cleared trades using SMA

used for this trade
11 = Order Origination User ID of trader who Always

Trader submitted order for
side being reported
12 = Executing Trader User ID of the trader The executing broker in non-ICE Block
entering the trade broker-enabled markets.
13 = Order Origination Firm Name of order Always

origination trader’s
company
17 = Contra Firm Name of counterparty Bilateral trades

trader’s company
21 = Clearing Organization Clearing Destination Broker enabled markets
35 = Liquidity Provider ID of company who Only on orders that added liquidity to

submitted order that market. This is the originator on the deal.
added liquidity to
market
37 = Contra Trader User ID of counterparty Bilateral trades

trader
50 = Contra Firm ID ID of counterparty Bilateral trades

trader’s company
51 = Clearing Account ID Clearing Account ID All cleared trades using SMA

used for this trade
52 = CTI Code Customer Type Indicator Cleared trades using LMA in ICE Futures US
Code and Canada markets.
www.theice.com

Valid values in corresponding PartyID field:
1 - Broker/trader trading for own account.
2 - Broker/trader trading for house or prop
account.
3 - Broker/trader trading for the account of
another broker/trader.
4 – Broker/trader trading for any other
customer’s account that does not have direct
trading access.
53 = House Number House Number Cleared trades using LMA in ICE Futures US
and Canada markets
54 = Account Code Segregation Type All cleared trades.

Valid values in corresponding PartyID field:
For trading ICE Futures:
S - Segregated
N - Non-segregated
H - House
L - Local
D - Default
A - Allocated
* - Split
U - Unassigned
G - Gas associate
F = US-Customer Futures
W = US-Customer Swaps
Z = US-Customer “Foreign Board of Trade”
or “FBOT”
For trading ICE Futures US or ICE Futures

Canada:
H – House
C – Customer
55 = Account ID ID of locally managed All cleared trades using LMA

account
56 = Order Origination Firm ID of order origination Always

ID trader’s company
57 = OnBehalfOfCompID Value sent in tag 115 All trades submitted through FIX
of FIX order
All trades submitted through FIX
58 = Value sent in tag 116
OnBehalfOfSubID of FIX order
www.theice.com
59 = Value sent in tag 144 All trades submitted through FIX

OnBehalfOfLocationID of FIX order
60 = Clearing Firm Name Clearing Firm used for All cleared trades using SMA
this trade
61 = ExecutingFirmID Firm ID executing the Trades executed by a broker company on

trade behalf of the originating firm
www.theice.com
Appendix B: ICE FIX Trade Capture Semantics
• A “Live” subscription means that the FIX TC users will be getting real time deal updates. They’ll
receive a FIX TC report as soon as a deal is done in a market which the FIX TC user has permissions
for.
• FIX TC users need to explicitly send a request for receiving the trades either “Live” or for “Snapshots”.
• A “Live” subscription remains valid till either the FIX TC user disconnects or an unsubscribe request is
sent.
• Trade Capture reports will only be sent if there are any trades in the system.
• It’s not mandatory for FIX TC users to send security def. requests before FIX TC report requests. It’s
just a mechanism by which they can download market specific static data for caching it.
www.theice.com
Appendix C: ICE FIX Trade Capture Request Matrix

Following matrix depicts the required tag values for a typical FIX TC report request and
the expected response based on these values.
TAGS in the FIX TC request

Description
580 263 60 75 60 75
0 0 Date- Date Date- Date2 This means I am requesting for a snapshot update without
time time2 specifying a Start and End Date (580=0), hence despite
specifying dates in 60-75 tags no reports will be
returned. Dates are ignored when 580=0
0 1 Date- Date Date- Date2 This means I am requesting a live+snapshot update
time time2 without specifying a Start and End Date (580=0).
Consequently despite specifying dates in 60, 75 tags no
snapshot reports will be returned and only LIVE part
of subscription will be honored.
0 0 -- -- -- -- No reports will be sent.
0 1 -- -- -- -- No snapshot reports will be returned and only LIVE
part of subscription will be honored.
This is a typical “LIVE-only” update subscription
request and all the live updates will be sent.
1 0 Date- Date -- -- This means I am requesting a snapshot request for all the
time trades that happened since StartDate (& time)= “Date” and
“Date-time” till the time of request. If deals exist then the
reports will be sent.
1 0 Date- Date Date- Date2 This means I am requesting for a snapshot update for all
time time2 the trades that happened since StartDate (& time)= “Date”
and “Date-time” till the time of request (“Date2” and
“Date-time2” will be ignored since 580=1). If deals exist
then the reports will be sent for the snapshot.
1 0 -- -- -- -- Request rejected. Need to specify at least one set of date
tags (60,75)
1 1 -- -- -- -- No snapshot reports will be returned and only LIVE part
1 1 Date- Date -- -- This means I am requesting a live+snapshot update for all
time the trades that happened since StartDate (& time)= “Date”
and “Date-time” till the time of request. If deals exist
then the reports will be sent for the snapshot. Live
subscription is accepted.
1 1 Date- Date Date- Date2 This means I am requesting a live+snapshot update for all
time time2 the trades that happened since StartDate (& time)= “Date”
and “Date-time” till the time of request (“Date2” and
“Date-time2” will be ignored since 580=1).. If deals
exist then the reports will be sent for the snapshot.
Live subscription is accepted.
www.theice.com
2 0 Date- Date Date- Date2 This means I am requesting for a snapshot update for all
time time2 the trades that happened between StartDate (& time)=
“Date” and “Date-time” AND “Date2” and “Date-time2”.
If deals exist then the reports will be sent for the
snapshot.
2 0 -- -- -- -- Request rejected. Need to specify at least one set of date
tags (60,75)
2 1 Date- Date Date- Date2 This means I am requesting for a live+snapshot update
time time2 for all the trades that happened between StartDate (&
time)= “Date” and “Date-time” AND “Date2” and “Date-
time2”. If deals exist then the reports will be sent for
the snapshot. Live subscription is accepted.
2 1 -- -- -- -- No snapshot reports will be returned and only LIVE part

ICE-FIX TradeCapture Reference Manual 2 0 30-1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ICE-FIX TradeCapture Reference Manual 2 0 30-1

Uploaded by

Copyright:

Available Formats

________________________________________________________________

ICE-FIX Trade Capture Reference Manual

 Copyright Intercontinental Exchange, Inc. 2012. All Rights Reserved.

Version Date Completed By Description of Changes

Updated comments to several fields. Reordered fields in Trade

Added new market types [Section 7]:

Added <NestedParties> component block [Section 4.3.3]

Section 4.3.1, Section 6 and Appendix A removed Currency,

Section 4.3.1 added NumofCycles tag 9022

Section 4.3.3 and Section 6 Added tag 9376 LegComplianceID and

1 About This Manual

1.1 Notes and Warnings

Note: Emphasizes important or essential information

Indicates user must absolutely follow this instruction to prevent a serious

* Denotes multi-use tags.

Tag Id Denotes repeating group inside a message (1 level deep)

1.3 Required Tags

Always: The FIX message must include this Tag.

2.1 Products Supported

ICE Futures UK Yes

2.2 System Architecture

TCP/IP Connection FIX ICE Trading

2.3 Connectivity Management

Scenario 1: Session transition during failover

1. Client-1 sends Logon message and F5 forwards that to Node-1.

2.5 FIX Protocol Version Support

2.6 ICE-FIX Trade Capture application support

2.6.1 Reporting and Tracking issues

ICE-FIX Trade Capture API Production Support

If necessary, issues will be escalated to the API Development Support Team.

ICE-FIX Trade Capture API Development Support

Please create a support ticket by login on to www.theice.com/integrate

3.1 Session Configuration

3.2 Session Reset

3.3 Session Startup

3.4 Session Maintenance

• Test Request with Tag 35 (MsgType) set to 1

3.4.1 Logon Request Message

Message Direction: FIX Client to FIX Host

Tag # Field Name Required Additional Comments

553 UserName Always User id of a FIX session

554 Password Always Password.

98 EncryptMethod Always Based on the requirement tag can be used to support

3.4.2 Logon Response Message

Message Direction: FIX Host to FIX Client

98 EncryptMethod Always This is the encryption method sent by the client

3.4.3 Reject (Session Level):

Message Direction: FIX Host to FIX Client

Tag # Field Name Required Additional Comments

45 RefSeqNum Y MsgSeqNum of rejected message

371 RefTagID N The tag number of the FIX-field being referenced

3.4.4 Sequence gaps fill process

3.4.5 Test Requests and Heartbeats

4 Supported Application Message Types

All Administrative messages

4.1 News Messages and Throttling Limits

Tag # Field Name Required Additional Comments

148 HeadLine Always Market server message code

61 Urgency Always Priority of the market server notification

33 LinesOfText Always Number of message lines

58 Text Conditional Always exist if Tag 33 value > 0

Tag # Field Name Required Additional Comments

4.1.2 Throttling Limits

• Trade Capture Report Request – 2000 msg/sec