Fix-5.0 SP1 Vol-1

FINANCIAL INFORMATION
EXCHANGE PROTOCOL
(FIX)
Version 5.0 Service Pack 1
VOLUME 1 – INTRODUCTION TO THE FIX PROTOCOL
March 2008
Copyright, 2007-2008, FIX Protocol, Limited

Version 5.0 Service Pack 1 − VOLUME 1 March 2008
DISCLAIMER
THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE

PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR
ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY,
EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE
USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY
DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES
DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF
OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY
THE USER.
NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR
DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY
USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT,
INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA,
LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC
LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR
OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR
OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES.
No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein),
except as expressly set out in FIX Protocol Limited's Copyright and Acceptable Use Policy..
© Copyright 2003-2008 FIX Protocol Limited, all rights reserved
REPRODUCTION
FIX Protocol Limited grants permission to print in hard copy form or reproduce the FIX Protocol specification in
its entirety provided that the duplicated pages retain the “Copyright FIX Protocol Limited” statement at the
bottom of the page.
Portions of the FIX Protocol specification may be extracted or cited in other documents (such as a document
which describes one’s implementation of the FIX Protocol) provided that one reference the origin of the FIX
Protocol specification ( http://www.fixprotocol.org ) and that the specification itself is “Copyright FIX
HTU UTH
Protocol Limited”.
FIX Protocol Limited claims no intellectual property over one’s implementation (programming code) of an
application which implements the behavior and details from the FIX Protocol specification.
Copyright, 2007-2008, FIX Protocol, Limited Page 2 of 144

PREFACE
The Financial Information eXchange (FIX) effort was initiated in 1992 by a group of institutions and brokers
interested in streamlining their trading processes. These firms felt that they, and the industry as a whole, could
benefit from efficiencies derived through the electronic communication of indications, orders and executions. The
result is FIX, an open message standard controlled by no single entity, that can be structured to match the business
requirements of each firm. The benefits are:
• From the business flow perspective, FIX provides institutions, brokers, and other market participants a means
of reducing the clutter of unnecessary telephone calls and scraps of paper, and facilitates targeting high
quality information to specific individuals.
• For technologists, FIX provides an open standard that leverages the development effort so that they can
efficiently create links with a wide range of counter-parties.
• For vendors, FIX provides ready access to the industry, with the incumbent reduction in marketing effort and
increase in potential client base.
Openness has been the key to FIX's success. For that reason, while encouraging vendors to participate with the
standard, FIX has remained vendor neutral. Similarly, FIX avoids over-standardization. It does not demand a
single type of carrier (e.g., it will work with leased lines, frame relay, Internet, etc.), nor a single security
protocol. It leaves many of these decisions to the individual firms that are using it. We do expect that, over time,
the rules of engagement in these non-standardized areas will converge as technologies mature.
FIX is now used by a variety of firms and vendors. It has clearly emerged as the inter-firm messaging protocol of
choice. FIX has grown from its original buyside-to-sellside equity trading roots. It is now used by markets
(exchanges, “ECNs”, etc) and other market participants. In addition to equities, FIX currently supports four other
products: Collective Investment Vehicles (CIVs), Derivatives, Fixed Income, and Foreign Exchange. The process
for modifications to the specification is very open with input and feedback encouraged from the community.
Those interested in providing input to the protocol are encouraged use the FIX website Discussion section or
contact the FIX Global Technical Committee Chairpersons, Kevin Houstoun, HSBC, or Matt Simpson, Chicago
HH
Mercantile Exchange. The FIX website at http://www.fixprotocol.org is the main source of information,
HTU UTH
discussion, and notification of FIX-related events.

We look forward to your participation.
FIX Protocol Ltd March 2008

About FIX Protocol Limited
FIX Protocol Limited (FPL) ( http://www.fixprotocol.org ) oversees and manages the development of the FIX
HTU UTH
Protocol specification and encourages its use throughout the industry. FPL is open to due paying members
representing business and technology professionals interested in guiding the growth and adoption of the FIX
Protocol that work for: Buy-side Firms, Sell-side Firms, Exchanges, ECNs/ATSs, Utilities, Vendors, and Other
Associations. For more information about membership please visit http://www.fixprotocol.org/join/ .
HTU UTH
FIX Protocol Limited is represented by the following high-level organization structure:
Global Steering Committee

(GSC)
Global Technical
Global Global
Americas Asia/Pac EMEA Japan Global
Fixed Foreign
Region Region Region Region Derivatives
Income Exchange
Global Education & Marketing
• Global Steering Committee comprised of the FPL Committee Chairs

• Global Technical and Global Education & Marketing comprised of Product/Region Committee
Representatives
For a current list of FPL Member firms, visit:
TUhttp://www.fixprotocol.org/members/
H UTH
For a current list of active FPL Working Groups, visit:

TUhttp://www.fixprotocol.org/working_groups/
H UTH
Links to Product and Regional Committees' web pages are at:

TUhttp://www.fixprotocol.org/committees/
H UTH

VOLUME INDEX
VOLUME 1 - INTRODUCTION
U
VOLUME INDEX
INTRODUCTION
DOCUMENT NAVIGATION
FIX PROTOCOL SYNTAX
COMMON COMPONENTS OF APPLICATION MESSAGES
COMMON APPLICATION MESSAGES
GLOSSARY
VOLUME 2 - TRANSPORT PROTOCOLS

U
INTRODUCTION
TRANSPORT INDEPENDENCE (TI) FRAMEWORK
TRANSPORT PROTOCOLS
VOLUME 3 -FIX APPLICATION MESSAGES: PRE-TRADE

U
CATEGORY: INDICATION
CATEGORY: EVENT COMMUNICATION
CATEGORY: QUOTATION / NEGOTIATION
CATEGORY: MARKET DATA
CATEGORY: MARKET STRUCTURE
CATEGORY: REFERENCE DATA
VOLUME 4 -FIX APPLICATION MESSAGES: ORDERS AND EXECUTIONS (TRADE)

U
CATEGORY: SINGLE/GENERAL ORDER HANDLING

CATEGORY: CROSS ORDERS
CATEGORY: MULTILEG ORDERS (SWAPS, OPTION STRATEGIES, ETC)
CATEGORY: LIST/PROGRAM/BASKET TRADING

VOLUME 5 - FIX APPLICATION MESSAGES: POST-TRADE

U
CATEGORY: ALLOCATION AND READY-TO-BOOK

CATEGORY: SETTLEMENT INSTRUCTIONS
CATEGORY: TRADE CAPTURE ("STREETSIDE") REPORTING
CATEGORY: REGISTRATION INSTRUCTIONS
CATEGORY: POSITIONS MAINTENANCE
CATEGORY: COLLATERAL MANAGEMENT
VOLUME 6 - FIX DATA DICTIONARY

U
FIELD DEFINITIONS
APPENDIX 6-A - VALID CURRENCY CODES
APPENDIX 6-B - FIX FIELDS BASED UPON OTHER STANDARDS
APPENDIX 6-C - EXCHANGE CODES - ISO 10383 MARKET IDENTIFIER CODE (MIC)
APPENDIX 6-D - CFICODE USAGE - ISO 10962 CLASSIFICATION OF FINANCIAL
INSTRUMENTS (CFI CODE)
APPENDIX 6-E - DEPRECATED (PHASED-OUT) FEATURES AND SUPPORTED APPROACH
APPENDIX 6-F - REPLACED FEATURES AND SUPPORTED APPROACH
APPENDIX 6-G - USE OF <PARTIES> COMPONENT BLOCK
APPENDIX 6-H - USE OF <SETTLINSTRUCTIONS> COMPONENT BLOCK
VOLUME 7 - FIX USAGE NOTES

U
PRODUCT: COLLECTIVE INVESTMENT VEHICLES (CIV)

PRODUCT: LISTED DERIVATIVES (FUTURES & OPTIONS)
PRODUCT: EQUITIES
PRODUCT: FIXED INCOME
PRODUCT: FOREIGN EXCHANGE
USER GROUP: EXCHANGES AND MARKETS

Contents – Volume 1
DISCLAIMER...............................................................................................................................................................2
REPRODUCTION........................................................................................................................................................2
PREFACE......................................................................................................................................................................3
ABOUT FIX PROTOCOL LIMITED.......................................................................................................................4
VOLUME INDEX.........................................................................................................................................................5
INTRODUCTION.........................................................................................................................................................8
DOCUMENT NAVIGATION.....................................................................................................................................8
OVERVIEW OF MAJOR CHANGES IN FIX 5.0...................................................................................................8
FIX PROTOCOL SYNTAX......................................................................................................................................12
COMMON COMPONENTS OF APPLICATION MESSAGES - COMPONENT BLOCKS (INCLUDED IN

PRE-TRADE, TRADE, AND POST-TRADE MESSAGES).................................................................................50
COMMON APPLICATION MESSAGES (APPLY TO PRE-TRADE, TRADE, AND POST-TRADE).......99
GLOSSARY...............................................................................................................................................................119
APPENDIX 1-A: ABBREVIATIONS USED WITHIN FIXML........................................................................140

FINANCIAL INFORMATION EXCHANGE PROTOCOL
INTRODUCTION
The Financial Information Exchange (FIX) Protocol is a message standard developed to facilitate the electronic
exchange of information related to securities transactions. It is intended for use between trading partners wishing
to automate communications.
The message protocol, as defined, will support a variety of business functions. FIX was originally defined for use
in supporting US domestic equity trading with message traffic flowing directly between principals. As the
protocol evolved, a number of fields were added to support cross-border trading, derivatives, fixed income, and
other products. Similarly, the protocol was expanded to allow third parties to participate in the delivery of
messages between trading partners. As subsequent versions of FIX are released, it is expected that functionality
will continue to expand.
The protocol is defined at two levels: session and application. The session level is concerned with the delivery of
data while the application level defines business related data content. This document is divided into volumes and
organized to reflect the distinction.
DOCUMENT NAVIGATION
One useful tip when navigating within a volume is to take advantage of the fact that each document contains
“bookmarks” to its main sections. You can use the word processor’s “Goto” function (i.e. Ctrl-G) to quickly
navigate from one key section or appendix to another.
Third parties or volunteers have historically built useful utilities “generated” using the specification document as
their basis which provide cross-reference and lookup capabilities. Such free utilities are available via the FIX
website.
OVERVIEW OF MAJOR CHANGES IN FIX 5.0

With the release of FIX 5.0 in October 2006, the FPL Global Technical Committee (GTC) introduced a new
framework, the transport independence (TI) framework, which separated the FIX Session Protocol from the FIX
Application Protocol. Under the TI framework the application protocol messages can be sent over any suitable
session transport technology (e.g. WS-RX, MQ, publish/subscribe message bus), where the FIX Session Protocol
is one of the available options as a session transport for FIX application messages. From this release forward the
FIX Application layer and the FIX Session layer will have their own versioning moniker. The FIX Application
layer will retain the traditional version moniker of "FIX x.y" while the FIX Session layer will utilize a new
version moniker of "FIXT x.y" (note that the version numbers will be independent of each other). The diagram
below illustrates how previously the FIX Session layer was tighly coupled to the Application layer. With the
advent of Application Versioning and Transport Independence, the FIX Session and Application layers have been
decoupled and are now independent.

Transport Independence (TI) Framework

The transport independence (TI) framework separates the previously coupled FIX Session layer from the FIX
Application layer. Under this framework the FIX Application Protocol can use any transport technology in
addition to the FIX Session Protocol. The diagram below illustrates how various transport mechanisms, including
the FIX Session layer, can be used to carry the full suite of FIX Application versions.
To support this framework a key new field has been added called ApplVerID (application version ID, tag 1128).
Depending on the use case ApplVerID may be optional or required. Additionally, the FIX field BeginString will
no longer identify the FIX application version, but identifies the FIX Session Protocol version. The sections
below discusses the four main uses cases supported by the TI framework.

Application Versioning
Application Versioning allows extensions to the current base application version to be applied using a formal
release process. Extension Packs represent the individual gap analysis proposals submitted to the GTC for review
and approval. Extension Packs are grouped into Service Packs and are applied to the base application version,
usually the most current FIX application version. A new application version is formed when a new Service Pack
is applied to a base version. In the diagram below, FIX 4.4 has been extended via Service Pack 0, forming a new
application version called FIX 5.0. As new Extension Packs are approved they will be grouped into Service Pack
1 which is then released to form the next application version identified as FIX 5.0 SP1. These application
versions are expressed using the new tag ApplVerID.
Service Pack Release
Process
Service Service
Pack0 Pack1
Extension Extension
Pack Pack
Extension Base Release Extension

FIX 4.4 Pack Pack FIX 5.0 SP1
FIX 5.0
Extension Extension
Pack Pack
Extension Extension
Pack Pack
Service Pack Mangement

ApplVerID is an enumerated field. These enumerations are used to express prior versions of FIX inclusive of FIX
4.0, 4.1, 4.2, 4.3 and 4.4 as well as the most recent version, FIX 5.0. Going forward, service packs will be applied
to the base version, in this case FIX 5.0, and will be identified as FIX Version + Service Pack . This means that
FIX 5.0 will be represented as an enumeration (7) rather than as an actual value in the ApplVerID field. Service
Pack identifiers will consist of the base FIX version, the service pack number for that version, and the date the
service pack was released. For example, the assigned value for service pack 1 may be “FIX 5.0 SP1 June 30,
2007”.
Extension Pack Mangement

Extension Packs are the building blocks of a Service Pack and represent specific functional proposals that have
been presented to the GTC. Prior to the release of a Service Pack, Extension Packs are applied to the most recent
version of the repository so that they can be used at the point they become available. Extension Packs are applied
to the repository in a cumulative manner and will at some point culminate in a Service Pack release. Extension
Packs management will be conducted as follows:
1. Extension Packs will be assigned a unique, sequential number at the point they are approved by the GTC
2. Extension Packs are applied to the most recent version of the repository and may be inclusive of prior
Extension Packs
3. At the pont an Extension Pack has been applied, the updated repository, schema, and message tables will
be available

4. When implementing a specific Extension Pack, the field CustomApplVerID (1129) will be used to
specify the Extension Pack Identifier
5. User’s of an Extension Pack need not implement other Extension Packs present in the repository. Rules
of engagement need to be bilaterally agreed on.
Flexibility Provided by FIX 5.0

This is the ‘GTC approved’ approach which separates the FIX session layer from the application layer, provides
support for application versioning, and creates a platform for transport independence. This approach will treat the
FIX session like ‘any other’ transport and allow the unambiguous use of any application version via the
ApplVerID field. A value of FIXT.1.1 in the BeginString of the FIX Session will indicate that application
versioning is in effect and the version should be determined either through the Logon's NoMsgType repeating
group or the AppVerID field. Future extensions to the session layer or application layer will be supported
independent of each other as point releases to BeginString and ApplVerID, respectively. Major Tags describing the
session and application versions are: BeginString=FIXT.1.1 (or later versions) and ApplVerID=FIX.5.0 1 (or later T T
versions). A BeginString=FIX.5.0 (or later versions) will not be valid.

The diagram below illustrates how the new FIXT.1.1 Session layer can be used to transport makes use of the
ApplVerID in the Application layer in order to support a broad set of application versions. 2 T T
FIX Application Layer

Buy Side Sell Side
FIX.4.0
ApplVerID = FIX.4.0 New Order
Single
ApplVerID = FIX.4.1 FIX.4.1

Quote
FIX Session Layer

FIX Session Layer FIX.4.2
ApplVerID = FIX.4.2
Market Data BeginString =
BeginString = FIXT.1.1
FIXT.1.1
FIX.4.4
ApplVerID = FIX.4.4 Allocation
Instruction
FIX.5.0
ApplVerID = FIX.5.0 TradeCapture
Report
FIX Application Layer
1 TT The value FIX.5.0 will be represented using enumeration 7

2 TT FIX.4.0, FIX.4.1, FIX.4.2, FIX.4.3, FIX.4.4, FIX.5.0 are represented using enumerations

FIX PROTOCOL SYNTAX

The FIX Protocol currently exists in two syntaxes:
1. “Tag=Value” syntax
2. FIXML syntax
The same business message flow applies to either syntax. A specific syntax is simply a slightly different way to
represent the same thing in much the same way that “3” and “three” represent the same thing.
COMMON FIX SYNTAX RULES

The following section summarizes general specifications for constructing FIX messages which are applicable to
both “Tag=Value” and FIXML syntaxes.
Data Types:
Data types (with the exception of those of type "data") are mapped to ASCII strings as follows:
int Sequence of digits without commas or decimals and optional sign character (ASCII characters "-"
and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is
"-99999"). Note that int values may contain leading zeros (e.g. “00023” = “23”).
Examples:
723 in field 21 would be mapped int as |21=723|.
-723 in field 12 would be mapped int as |12=-723|
The following data types are based on int.
Length int field representing the length in bytes. Value must be positive.
TagNum int field representing a field's tag number when using FIX "Tag=Value"
syntax. Value must be positive and may not contain leading zeros.
SeqNum int field representing a message sequence number. Value must be positive.
NumInGroup int field representing the number of entries in a repeating group. Value
must be positive.
DayOfMonth int field representing a day during a particular monthy (values 1 to 31).
float Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9"
and "."); the absence of the decimal point within the string will be interpreted as the float
representation of an integer value. All float fields must accommodate up to fifteen significant
digits. The number of decimal places used should be a factor of business/market needs and mutual
agreement between counterparties. Note that float values may contain leading zeros (e.g.
“00023.23” = “23.23”) and may contain or omit trailing zeros after the decimal point (e.g. “23.0” =
“23.0000” = “23” = "23.").
Note that fields which are derived from float may contain negative values unless explicitly specified
otherwise. The following data types are based on float.
Qty float field capable of storing either a whole number (no decimal places) of
“shares” (securities denominated in whole units) or a decimal value
containing decimal places for non-share quantity asset classes (securities
denominated in fractional units).
Price float field representing a price. Note the number of decimal places may
vary. For certain asset classes prices may be negative values. For example,

prices for options strategies can be negative under certain market

conditions. Refer to Volume 7: FIX Usage by Product for asset classes that
support negative price values.
PriceOffset float field representing a price offset, which can be mathematically added to
a "Price". Note the number of decimal places may vary and some fields
such as LastForwardPoints may be negative.
Amt float field typically representing a Price times a Qty
Percentage float field representing a percentage (e.g. 0.05 represents 5% and 0.9525
represents 95.25%). Note the number of decimal places may vary.
char Single character value, can include any alphanumeric character or punctuation except the delimiter.
All char fields are case sensitive (i.e. m != M).
The following fields are based on char.
Boolean char field containing one of two values:
'Y' = True/Yes
'N' = False/No
String Alpha-numeric free format strings, can include any character or punctuation except the delimiter.
All String fields are case sensitive (i.e. morstatt != Morstatt).
MultipleCharValue string field containing one or more space delimited single character values
(e.g. |18=2 A F| ).
MultipleStringValu string field containing one or more space delimited multiple character
e values (e.g. |277=AV AN A| ).
Country string field representing a country using ISO 3166 Country code (2
character) values (see Appendix 6-B).
Currency string field representing a currency type using ISO 4217 Currency code (3
character) values (see Appendix 6-A).
Exchange string field representing a market or exchange using ISO 10383 Market
Identifier Code (MIC) values (see"Appendix 6-C).
MonthYear string field representing month of a year. An optional day of the month can
be appended or an optional week code.
Valid formats:
YYYYMM
YYYYMMDD
YYYYMMWW
Valid values:
YYYY = 0000-9999; MM = 01-12; DD = 01-31; WW = w1, w2, w3,
w4, w5.
UTCTimestamp string field representing Time/date combination represented in UTC
(Universal Time Coordinated, also known as “GMT”) in either
YYYYMMDD-HH:MM:SS (whole seconds) or YYYYMMDD-
HH:MM:SS.sss (milliseconds) format, colons, dash, and period required.
Valid values:
* YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM =
00-59, SS = 00-60 (60 only if UTC leap second) (without milliseconds).
* YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM =

00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating

milliseconds).
Leap Seconds: Note that UTC includes corrections for leap seconds, which
are inserted to account for slowing of the rotation of the earth. Leap second
insertion is declared by the International Earth Rotation Service (IERS) and
has, since 1972, only occurred on the night of Dec. 31 or Jun 30. The IERS
considers March 31 and September 30 as secondary dates for leap second
insertion, but has never utilized these dates. During a leap second insertion,
a UTCTimestamp field may read "19981231-23:59:59", "19981231-
23:59:60", "19990101-00:00:00". (see
http://tycho.usno.navy.mil/leapsec.html)
UTCTimeOnly string field representing Time-only represented in UTC (Universal Time

Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds)
or HH:MM:SS.sss (milliseconds) format, colons, and period required. This
special-purpose field is paired with UTCDateOnly to form a proper
UTCTimestamp for bandwidth-sensitive messages.
Valid values:
HH = 00-23, MM = 00-60 (60 only if UTC leap second), SS = 00-59.
(without milliseconds)
HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second),
sss=000-999 (indicating milliseconds).
UTCDateOnly string field representing Date represented in UTC (Universal Time

Coordinated, also known as “GMT”) in YYYYMMDD format. This special-
purpose field is paired with UTCTimeOnly to form a proper
UTCTimestamp for bandwidth-sensitive messages.
Valid values:
YYYY = 0000-9999, MM = 01-12, DD = 01-31.
LocalMktDate string field represening a Date of Local Market (as oppose to UTC) in
YYYYMMDD format. This is the “normal” date field used by the FIX
Protocol.
Valid values:
YYYY = 0000-9999, MM = 01-12, DD = 01-31.
TZTimeOnly string field representing the time represented based on ISO 8601. This is the
time with a UTC offset to allow identification of local time and timezone of
that time.
Format is HH:MM[:SS][Z | [ + | - hh[:mm]]] where HH = 00-23 hours, MM
= 00-59 minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59
offset minutes.
Example: 07:39Z is 07:39 UTC
Example: 02:39-05 is five hours behind UTC, thus Eastern Time
Example: 15:39+08 is eight hours ahead of UTC, Hong Kong/Singapore
time

Example: 13:09+05:30 is 5.5 hours ahead of UTC, India time

TZTimestamp string field representing a time/date combination representing local time
with an offset to UTC to allow identification of local time and timezone
offset of that time. The representation is based on ISO 8601.
Format is YYYYMMDD-HH:MM:SS[Z | [ + | - hh[:mm]]] where YYYY =
0000 to 9999, MM = 01-12, DD = 01-31 HH = 00-23 hours, MM = 00-59
minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59 offset
minutes
Example: 20060901-07:39Z is 07:39 UTC on 1st of September 2006
Example: 20060901-02:39-05 is five hours behind UTC, thus Eastern Time
on 1st of September 2006
Example: 20060901-15:39+08 is eight hours ahead of UTC, Hong
Kong/Singapore time on 1st of September 2006
Example: 20060901-13:09+05:30 is 5.5 hours ahead of UTC, India time on
1st of September 2006
data string field containing raw data with no format or content restrictions. Data
fields are always immediately preceded by a length field. The length field
should specify the number of bytes of the value of the data field (up to but
not including the terminating SOH).
Caution: the value of one of these fields may contain the delimiter (SOH)
character. Note that the value specified for this field should be followed by
the delimiter (SOH) character as all fields are terminated with an “SOH”.
XMLData Contains an XML document raw data with no format or content restrictions.
XMLData fields are always immediately preceded by a length field. The
length field should specify the number of bytes of the value of the data field
(up to but not including the terminating SOH).
Pattern Used to build on and provide some restrictions on what is allowed as valid values in fields that uses
a base FIX data type and a pattern data type. The universe of allowable valid values for the field
would then be the union of the base set of valid values and what is defined by the pattern data type.
The pattern data type used by the field will retain its base FIX data type (e.g. String, int, char).
Tenor used to allow the expression of FX standard tenors in addition to the base
valid enumerations defined for the field that uses this pattern data type.
This pattern data type is defined as follows:
Dx = tenor expression for "days", e.g. "D5", where "x" is any integer > 0
Mx = tenor expression for "months", e.g. "M3", where "x" is any integer > 0
Wx = tenor expression for "weeks", e.g. "W13", where "x" is any integer >
0
Yx = tenor expression for "years", e.g. "Y1", where "x" is any integer > 0
Reserved100Plus Values "100" and above are reserved for bilaterally agreed upon user
defined enumerations.
Required Fields:

Each message within the protocol is comprised of required, optional and conditionally required (fields which
are required based on the presence or value of other fields) fields. Systems should be designed to operate
when only the required and conditionally required fields are present.

FIX “Tag=Value” SYNTAX

The following section summarizes general specifications for constructing FIX messages in “Tag=Value” syntax.
Message Format
The general format of a FIX message is a standard header followed by the message body fields and
terminated with a standard trailer.
Each message is constructed of a stream of <tag>=<value> fields with a field delimiter between fields in the
stream. Tags are of data type TagNum. All tags must have a value specified. Optional fields without
values should simply not be specified in the FIX message. A Reject message is the appropriate response
to a tag with no value.
Except where noted, fields within a message can be defined in any sequence (Relative position of a field
within a message is inconsequential.) The exceptions to this rule are:
1. General message format is composed of the standard header followed by the body followed by
the standard trailer.
2. The first three fields in the standard header are BeginString (tag #8) followed by BodyLength
(tag #9) followed by MsgType (tag #35).
3. The last field in the standard trailer is the CheckSum (tag #10).
4. Fields within repeating data groups must be specified in the order that the fields are specified
in the message definition within the FIX specification document. The NoXXX field where XXX is
the field being counted specifies the number of repeating group instances that must immediately
precede the repeating group contents.
5. A tag number (field) should only appear in a message once. If it appears more than once in the
message it should be considered an error with the specification document. The error should be
pointed out to the FIX Global Technical Committee.
In addition, certain fields of the data type MultipleCharValue can contain multiple individual values separated
by a space within the "value" portion of that field followed by a single "SOH" character (e.g. "18=2 9
C<SOH>" represents 3 individual values: '2', '9', and 'C'). Fields of the data type MultipleStringValue can
contain multiple values that consists of string values separated by a space within the "value" portion of that
field followed by a single "SOH" character (e.g. "277=AA I AJ<SOH>" represents 3 values: 'AA', 'I', 'AJ').
It is also possible for a field to be contained in both the clear text portion and the encrypted data sections of
the same message. This is normally used for validation and verification. For example, sending the
SenderCompID in the encrypted data section can be used as a rudimentary validation technique. In the cases
where the clear text data differs from the encrypted data, the encrypted data should be considered more
reliable. (A security warning should be generated).
Field Delimiter:
All fields (including those of data type data e.g. SecureData, RawData, SignatureData, XmlData, etc.) in a
FIX message are terminated by a delimiter character. The non-printing, ASCII "SOH" (#001, hex: 0x01,
referred to in this document as <SOH>), is used for field termination. Messages are delimited by the “SOH”
character following the CheckSum field. All messages begin with the “8=FIX.x.y<SOH>” string and
terminate with “10=nnn<SOH>“.
There shall be no embedded delimiter characters within fields except for data type data.

Repeating Groups:
It is permissible for fields to be repeated within a repeating group (e.g.
"384=2<SOH>372=6<SOH>385=R<SOH>372=7<SOH>385=R<SOH>" represents a repeating group
with two repeating instances “delimited” by tag 372 (first field in the repeating group.)).
• If the repeating group is used, the first field of the repeating group is required. This allows
implementations of the protocol to use the first field as a "delimiter" indicating a new repeating
group entry. The first field listed after the NoXXX, then becomes conditionally required if the
NoXXX field is greater than zero.
• The NoXXX field (for example: NoTradingSessions, NoAllocs) which specifies the number of
repeating group instances occurs once for a repeating group and must immediately precede the
repeating group contents.
• The NoXXX field is required if one of the fields in the repeating group is required. If all
members of a repeating group are optional, then the NoXXX field should also be optional.
• If a repeating group field is listed as required, then it must appear in every repeated instance of
that repeating group.
• Repeating groups are designated within the message definition via indentation and the 
symbol.
Some repeating groups are nested within another repeating group (potentially more than one level of nesting).
• Nested repeating groups are designated within the message definition via indentation and the 
symbol followed by another  symbol.
• If a nested repeating group is used, then the outer repeating group must be specified
Example of a repeating group:
Part of message
215 NoRoutingIDs N Required if any RoutingType and RoutingIDs are
specified. Indicates the number within repeating
group.
 216 RoutingType N Indicates type of RoutingID. Required if
NoRoutingIDs is > 0.
 217 RoutingID N Identifies routing destination. Required if
NoRoutingIDs is > 0.
Rest of the message not shown
Example of nested repeating group
Portion of New Order - List message showing a nested repeating group for allocations for each
order. Note the NoAllocs repeating group is nested within the NoOrders repeating group and as such
each instance of the orders repeating group may contain a repeating group of allocations.
73 NoOrders Y Number of orders in this message (number of
repeating groups to follow)
 11 ClOrdID Y Must be the first field in the repeating group.
 526 SecondaryClOrdID N
 67 ListSeqNo Y Order number within the list
 583 ClOrdLinkID N

 160 SettlInstMode N
 component block <Parties> N Insert here the set of "Parties" (firm identification)
fields defined in "COMMON COMPONENTS OF
APPLICATION MESSAGES"
 229 TradeOriginationDate N
 1 Account N
 581 AccountType N
 589 DayBookingInst N
 590 BookingUnit N
 591 PreallocMethod N
 78 NoAllocs N Indicates number of pre-trade allocation
accounts to follow
  79 AllocAccount N Required if NoAllocs > 0. Must be the first
field in the repeating group.
  467 IndividualAllocID N
  component block N Insert here the set of "Nested Parties" (firm
<NestedParties> identification "nested" within additional
repeating group) fields defined in "COMMON
COMPONENTS OF APPLICATION
MESSAGES"
  80 AllocQty N
 63 SettlmntTyp N
 64 FutSettDate N Takes precedence over SettlmntTyp value and
conditionally required/omitted for specific
SettlmntTyp values.
Rest of the message not shown
User Defined Fields:

In order to provide maximum flexibility for its users, the FIX protocol accommodates User Defined Fields.
These fields are intended to be implemented between consenting trading partners and should be used with
caution to avoid conflicts, which will arise as multiple parties begin implementation of the protocol. It is
suggested that if trading partners find that particular User Defined Fields add value, they should be
recommended to the FIX Global Technical Committee for inclusion in a future FIX version.
The tag numbers 5000 to 9999 have been reserved for use with user defined fields, which are used as part of
inter-firm communcation. These tags can be registered/reserved via the FIX website.
The tag numbers greater than or equal to 10000 have been reserved for internal use (within a single firm) and
do not need to be registered/reserved via the FIX website.

Example Usage of Encoded Fields For non-ASCII Language Support

The examples below illustrates how the MessageEncoding (347) field is used in conjunction with the various
available encoded fields in FIX.
Example 1 - Specify the ASCII/English value as Issuer plus Japanese character set as EncodedIssuer
Tag Field Name Value

…Other Standard Header fields
347 MessageEncoding Shift_JIS
…Other Message Body fields
106 Issuer HITACHI
348 EncodedIssuerLen 10
349 EncodedIssuer
Example 2 - Specify the ASCII/English value as Issuer plus Japanese character set as EncodedIssuer.
Specify the ASCII/English value as Text plus Japanese character set as EncodedText.
Tag Field Name Value

347 MessageEncoding Shift_JIS
106 Issuer HITACHI
348 EncodedIssuerLen 10
349 EncodedIssuer

58 Text This is a test
356 EncodedTextLen 17
357 EncodedText
Precautions when using UNICODE

There is the possibility that an SOH may be included in the character data when using UNICODE encoding. To
avoid parsing problems, a FIX engine should use the EncodedLen value to extract the proper number of bytes.

FIXML SYNTAX
FIXML Highlights
• FIXML is the XML vocabulary for creating FIX messages.
• Uses the same FIX data dictionary and business logic.
• Focuses primarily on the FIX Application Messages and does not provide a session layer.
• Can be encapsulated within the FIX Session Protocol or within another protocol like, MQ Series, TIBCO,
SOAP, etc.
Background
The FPL FIXML Working Group began investigating the XML format in 1998 and published a White Paper
supporting an evolutionary approach to migrating the FIX Protocol to an XML format. The working group
released an intial version of the FIXML DTDs on January 15th, 1999. There are currently DTDs based on FIX
Protocol versions 4.1, 4.2 and 4.3. A FIXML Schema based version of FIXML was released following the release
of FIX 4.4.
The FIXML language is in a state of transition. It has been four years since the initial release of FIXML. XML
technology has advanced considerably in those four years. FPL committed to deliver an XML Schema
representation for FIXML starting with FIX 4.3. Issues confronting FIXML users in the derivatives post trade area
preempted release of the FIXML Schema for FIX 4.3. Instead the effort shifted to attempts to exploit the
capabilities available in XML Schema to define a version of FIXML that was optimized to reduce message size.
This version of FIXML was referred to as Transport Optimized FIXML during its development. The Global
Technical Committee chose to release the transport optimizations in two phases.
The FIX 4.4 DTD Version was released with FIX 4.4 Eintroduced standardized abbreviations for field names and
removal of container elements used to represent repeating groups and component blocks. This version has been
replaced by the FIX 4.4 Schema Version and should no longer be used.
The FIX 4.4 Schema Version was released as part of FIX 4.4 Errata release. The FIX 4.4 Schema Version
exploits the enhanced capabilities of XML Schema to further optimize FIXML message size by introducing the
use of attributes to represent fields.
FIXML for FIX 5.0 is defined by an XML Schema based upon the work done for FIX 4.4.
FIX and FIXML Version and Comparison using New Order Single Message
The following section compares the implementation of the same FIX new order single message in FIX 4.2
tag=value format, FIXML 4.2 DTD version, and FIXML Schema Version.
FIX tag=value Version

The following is a FIX 4.2 New Order Single message in classic tag-value pair format:
8=FIX.4.2^9=251^35=D^49=AFUNDMGR^56=ABROKER^34=2^52=20030615-
01:14:49^11=12345^1=111111^63=0^64=20030621^21=3^110=1000^111=50000^55=IBM^48=459200
101^22=1^54=1^60=2003061501:14:49 38=5000^40=1^44=15.75^15=USD^59=0^10=127
NOTE: ^ represents the SOH separator.

The message is 195 bytes in length.

FIXML 4.2 Version

The following is a roughly equivalent FIXML 4.2 DTD-based message:
<FIXML>
<FIXMLMessage>
<Header>
<PossDupFlag Value="N" />
<PossResend Value="N" />
<SendingTime>20020103-12:00:01</SendingTime>
<Sender>
<CompID>AFUNDMGR</CompID>
</Sender>
<Target>
<CompID>ABROKER</CompID>
</Target>
</Header>
<ApplicationMessage>
<Order>
<ClOrdID>1968</ClOrdID>
<Account>4130287</Account>
<HandlInst Value="1" />
<ExDestination Value="L" />
<Instrument>
<Symbol>IBM</Symbol>
<SecurityID>459200101</SecurityID>
<SecurityIDSource Value="1" />
</Instrument>
<Side Value="2" />
<TransactTime>20021120-12:13:12</TransactTime>
<OrderQtyData>
<OrderQty>1000</OrderQty>
</OrderQtyData>
<OrdType Value="2" />
<Price>93.25</Price>
<Currency Value="USD" />
</Order>
</ApplicationMessage>
</FIXMLMessage>
</FIXML>
This message is 684 bytes; over three times the message size of the raw FIX tav=value message. In practice,
FIXML messages could be 3-5 times their FIX tag=value equivalents.
FIXML 4.4 Schema Version

The following is a New Order Single message based on the FIXML 4.4 Schema.
<FIXML>
<Order ClOrdID="123456"
Side="2"
TransactTm="2001-09-11T09:30:47-05:00"
OrdTyp="2"
Px="93.25"
Acct="26522154">
<Hdr Snt="2001-09-11T09:30:47-05:00"
PosDup="N"
PosRsnd="N"
SeqNum="521">

<Sndr ID="AFUNDMGR"/>
<Tgt ID="ABROKER"/>
</Hdr>
<Instrmt Sym="IBM"
ID="459200101"
IDSrc="1"/>
<OrdQty Qty="1000"/>
</Order>
</FIXML>
NOTE: The XML attributes in the message have been placed on separate lines to aid readability
This message is 348 bytes in length; approximately 70% larger than the raw FIX tag=value message, but
roughly half the size of the previous FIXML format without significant loss in readability.
Sample Message Content

The following table is included to help clarify the message content shown above
Tag/Attribute Meaning
<FIXML> Root element
<Order New order
ClOrdID="123456" Client’s order ID
Side="2" Sell order
TransactTm="2001-09-11T09:30:47-05:00" Transaction time
OrdTyp="2" Limit order
Px="93.25" Limit price
Acct="26522154"> Customer’s account
<Instrmt Sym="IBM" Stock symbol
ID="459200101" Stock CUSIP
IDSrc="1"/> (ID source=CUSIP)
<OrdQty Qty="1000"/> Order quantity
</Order> Close of order
</FIXML> Close root element
FIXML Transition to Schema

FIXML was initiated at a time when the only mechanism available to define and validate an XML syntax was the
Document Type Definition (DTD) originally created as part of the Standardized General Markup Language
(SGML). The DTD provided only minimal ability to define XML syntax.
Since then, the World Wide Web Consortium ( http://www.w3c.org ) adopted XML Schema as a way of
T H H
representing the format of XML messages using XML syntax. Document Type Definitions (DTDs), which were
originally part of XML, have limited syntax and capabilities for defining XML syntax. XML Schema was
designed to address many of the deficiencies of DTDs. The FPL Global Technical Committee has received
numerous requests from FIX users for an XML Schema representation of the FIX Protocol and believes that a
version of FIXML defined using XML Schema will provide a more robust, optimized message format and provide
a better environment for users implementin g FIXML applications.
T
The following limitations of DTDs determined much of the FIXML implementation;

Meta data could not be included in the DTD - so attributes were used for meta-data.
Attributes could not be "typed" so this restricted datatyping to elements. Many XML syntax's then relied heavily
on elements for data, attributes for meta-data. This is the approach taken for FIXML up through the FIX 4.4 Errata
20030618 release.
Since the initial release of FIXML in 1999, XML technology has advanced. The primary advancement has been in
the area of standards that are used to define XML based languages. First among these is XML Schema - which has
been adopted as a standard by the W3C. XML Schema addresses many of the limitations in DTDs, including:

Advanced datatyping, including datatyping for attributes.

Ability to include user defined meta-data in addition to standardized annotation and documentation.
XML Schema is written in XML, permitting manipulation by XML tools, such as XSLT, Xpath, etc.
FIXML 4.4 Schema Version Enhancements
The Schema version introduces the following enhancements
• Incorporated further transport optimizations
• Adoption of attributes
• Contextual Abbreviations – further reducing field names
• Addressed component blocks built around limitations of FIX tag=value by using consistent field names
across component blocks
• InstrumentLeg, NestedParties, Nested2Parties,UnderlyingInstrument
• Develop XML Schema Design Approach
• Leverage work already done by ISO/XML and FpML
• Design to support extensibility (customization) capabilities provided by FIX tag=value syntax
FIXML 4.4 Schema Version Design Objectives

Design objectives for FIXML messages (instance documents)
These design objectives refer to the FIXML instance documents. Instance documents are the actual FIXML
messages.
• FIXML implementation shall adhere to XML technology standards as specified by the W3C.
• FIXML implementation shall be suitable implementation for use in high volume transaction
scenarios. Target applications:
• Order Routing
• Trade Reporting and Post Trade Processing
• Distribution of product (instrument) information
• Market making for lower volume applications
• FIXML implementation shall minimize bandwidth consumption (reduced message size). The goal is
to have FIXML messages be less than 1.5 X the size of an equivalent FIX tag=value message.
• FIXML implementation shall maintain human readability of FIXML message, while still adhering to
performance goals.
• FIXML implementation shall support integration of FpML product specifications within the FIXML
message in an equivalent manner to FIX 4.4 tag=value. This integration should use commonly
agreed upon, de facto standard XML design patterns.
• FIXML implementation shall support a ready translation to and from FIX tag=value messages.
• FIXML implementation shall provide a cross-reference to ISO 15022 repository for each message,
element, and component.
• FIXML implementation shall maintain the extensibility and customization available via the FIX
tag=value message format, including:
• Ability to add custom messages,
• Ability to add custom fields to messages, component blocks, and repeating groups.
• FIXML Implementation shall provide full transport level independence.

• FIXML Implementation shall support version identification.
Design Objectives for the Schema Document

• FIXML Schema shall be implemented using the current de facto industry best practices for XML
Schema usage.
• FIXML Schema shall be implemented in such a way as to fully support the FIXML 4.4 "Schema
Version" Instance Requirements defined above.
• FIXML Schema shall support version identification.
• FIXML Schema shall provide meta-data sufficient to identify the FIX field name, component type,
tag number, ISO 15022 repository cross-reference.
• FIXML Schema shall be interoperable and compatible with the FpML schema.
• The FIXML Schema shall be based upon and be compatible with the current version of XML
schema: http://www.w3.org/2001/XMLSchema
H H
FIXML Design Rules
The following design guidelines were created to meet the design objectives for the FIXML Schema and the
FIXML instance documents defined above.
1. Use meaningful abbreviations for element and attribute names wherever possible. Use standard
abbreviations for common words (e.g., Price = Px, Currency = Ccy, etc.).
2. FIX Messages shall be implemented as XML Elements.
3. Individual, non-repeating fields shall be implemented as attributes of FIX Message elements.
4. FIX Component Blocks shall be implemented as an XML element.
5. Component blocks that were duplicated within FIX to circumvent tag=value requirements for
uniqueness across fields and tag numbers, such as the Parties, NestedParties, NestedParties2 component
blocks, shall use common naming in FIXML. The datatypes for each of the ComponentTypes will
provide the mapping back to FIX tag=value format.
6. Non-repeating fields belonging to a FIX component block shall be implemented as attributes.
7. Repeating groups shall be implemented as XML elements.
8. Non-repeating fields belonging to a repeating group shall be implemented as attributes.
9. Identical repeating groups that occur across FIX messages will be identified as implicit components
and reused across messages.
10. Field name prefixes that were used in FIX tag=value format for uniqueness shall be removed – thus
creating a contextual abbreviation.
11. FIX datatypes will be mapped to the closest XML Schema datatype whenever possible, thus making
FIXML more compatible with standard XML toolsets.
FIXML Schema Root Element

The FIXML Schema root element has been expanded to include the ability to include a batch of FIXML
application messages. Batch capability was provided to deliver groups of messages, such as post trade
confirms or position reports at the end of a trading session. Single message capability is still supported. Note
that the headres are optional.

Batc
0..1 h 0..1 Batch
FIXML (HeaderType) Header
Element
0..1 0..n
Messag
(
e
MessageTyp 0..1 Hdr
e (Header)
abstract)
Batch Message Usage
Single Message Usage
<FIXML>
<FIXML> <Batch>
<Order> <Hdr/>
<Hdr/> <Order>
</Order> <Hdr/>
</FIXML> </Order>
<Order>
<Hdr/>
</Order>
</Batch>
</FIXML>
An Example FIXML Single Message

The following is a New Order Single FIXML Schema message sent individually.
<FIXML v="4.4" r="20030618" s="20040109">

<Order ClOrdID="123456" Side="2" TransactTm="2001-09-11T09:30:47-05:00"
OrdTyp="2" Px="93.25" Acct="26522154">
<Instrmt Sym="IBM" ID="459200101" IDSrc="1"/>
<OrdQty Qty="1000"/>
</Order>
</FIXML>
An Example FIXML Batch Message

The following example shows a batch of position reports.
Note that the header is provided for the entire batch of messages.
<FIXML v="4.4" r="20030618" s="20031030">
<Batch>
<Hdr Snt="2001-12-17T09:30:47-05:00">
<Sndr ID="OCC"/>
<Tgt ID="Firm"/>
</Hdr>
<PosRpt RptID="541386431" Rslt="0" BizDt="2003-09-10T00:00:00" Acct="1"
AcctTyp="1" SetPx="0.00" SetPxTyp="1" PriSetPx="0.00" ReqTyp="0" Ccy="USD">
<Pty ID="OCC" Role="21"/>
<Pty ID="99999" Role="4"/>
<Pty ID="C" Role="38">

<PtySub SubID="ZZZ" SubIDTyp="2"/>

</Pty>
<Qty Typ="SOD" Long="35" Short="0"/>
<Qty Typ="FIN" Long="20" Short="10"/>
<Qty Typ="IAS" Long="10"/>
<Amt Typ="FMTM" Amt="0.00"/>
<Instrmt Sym="AOL" ID="KW" IDSrc="J" CFI="OCASPS"
MMY="20031122" Mat="2003-11-22T00:00:00" Strk="47.50" StrkCcy="USD" Mult="100"/>
</PosRpt>
<Pty ID="99999" Role="4"/>
</Pty>
</PosRpt>
<Pty ID="99999" Role="4"/>
</Pty>
</PosRpt>
</Batch>
</FIXML>
Version Identification
FIXML versions are identified explicitly in the schema file names and also with constant attribute values
defined in the fixml-component-base schema file.
FIXML Schema File Versioning

FIXML Schema employed the file naming convention developed for FpML. The major and minor version
numbers of the FIX version represented by the schema are appended to all FIXML schema file names. This
approach was taken to explicitly force users to recognize when counterparties have changed their version of
the schema.
FIXML Message Versioning

The FIXML root element <FIXML> contains three attributes that define the version of the message. The
FIXML root element is defined in the fixml-components-base schema file.
Attribute Description Format Example

v FIX Version N.N 4.4
r FIX Version release date (used to YYYYMMDD 20030618

designate errata releases between
FIX versions)
s Schema Release (used to YYYYMMDD 20031030
designate schema releases
between errata releases)
Example:
<FIXML v=”5.0” r=”20061024” s=”20061026”> </FIXML>
For FIX 5.0 changes have been made for versioning in order to be compatible with changes to support
transport independence.
Version FIXML Field Abbreviation FIX FIX Field Name Discussion
Tag
FIX.4.4 Version v 8 BeginString Version of FIX
FIX.4.4 Release r Release date of FIX
FIX.4.4 SchemaRelease s Release date of the Schema
FIX.4.4 Extension Version xv Extension version
FIX.4.4 Extension Release xr Extension release date
New fields in the standard header
FIX.5.0 v 1128 ApplVerID Indicates application version
using a service pack identifier.
The ApplVerID applies to a
specific message
FIX.5.0 r deprecated can be used to provide the
version release date
FIX.5.0 xv 1129 CstmApplVerID Used to support bilaterally
agreed custom functionality
FIX.5.0 xr deprecated can be used to provide a
release date for the extended
version
FIXML Schema File Structure

Organization of files was driven largely by the requirement to support customization of the FIXML Schema
per the requirements set forth by the FIXML Schema Working Group.
The basic organization of the schema has the datatypes used by the fields maintained in a separate file. FIX
fields are defined in the shared file. Components and the FIXML root element are defined in the component
files. FIXML messages are defined within separate category files.

Extensibility Design Pattern

Much of the design work that went into the FIXML Schema was done to permit counterparties to further
refine the FIXML language either by restriction or extension.
A possible scenario for restriction would be a market place that only supports a subset of the enumerations
available for OrdType (tag=39). The exchange can override the OrdType_t FIXML datatype in the fixml-
shared-impl-M-N.xsd file to restrict the set of possible values to only those supported by the market place.
An example ofextension would be counterparties that require an additional custom field to be added to a new
message.
In order to provide a uniform method in defining customizations that could be readily absorbed by
counterparties an extensibility design pattern was developed that defines how the FIXML definition was
partitioned and organized within separate schema files.
Each level of schema file (with the exception of datatypes) provides a base definition file that defines the
standard (default) FIXML language. Redefining this base file an implementation file (“impl”) is provided that
by default simply references the base definition.


Subsequent levels of the schema reference the impl from the previous level – thus providing a customization
entry point at the field level, component level, and message level.
FIXML Schema file naming conventions

FIXML file naming conventions are shown in the followin illustration.
All filenames begin with lowercase “fixml-“
“-“ is used to separate portions of the filename
The type of the schema file is identified in the second component of the file name. The datatypes file
contains the basic datatypes used within FIXML. The shared files contain the definitions for FIX fields. The
components file contains definitions for FIXML components (as defined in Volume 1 of the specification,
additional components identified while defining the FIXML schema, and the outer elements for FIX.

Files are either a base file or an implementation (impl). Base files define the standard FIXML language. Impl
files are used to extend or restrict the base FIXML language.
Refer to the FIXML Schema File Summary section for a complete list of schema files used in FIXML as of
FIX release 4.4.
Datatypes schema file

A decision was made to use native XML Schema datatypes wherever possible. Many of the XML Schema
standards are based upon ISO standard datatypes. This means that the FIX representation of UTCTimestamp
is different from the FIXML representation. The FIXML Schema working group felt it more important to be
compatible with XML and as a result XML toolsets. The requirement for conversion between FIX tag=value
datatypes and XML is left to implementors.
The fixml-datatypes schema file contains definitions for the FIXML datatypes.
FIX 5.0 introduces pattern datatypes that are used to appropriately support customization of enumerations
and also to support types that require both enumerations and specific patterns, such as the SettlementType
field. The <xs:union> element is used to combine an enumerated type with a pattern type in the fixml-fields-
impl-M-N.xsd file..

The following patterns have been created to support validation of user defined enumeration values and
extended patterns.
Tenor Pattern <xs:simpleType Currently used to support the
name="Tenor"><xs:restriction SettlementType which can be
base="xs:string"> <xs:pattern either an enumeration or a tenor
value="[DMWY](\d)+"/> </xs:restriction> pattern, such as M6 (six
</xs:simpleType> month).
Reserved100Plus Pattern <xs:simpleType Used for enumerated fields that
name="Reserved100Plus"><xs:restriction permit user defined values of
base="xs:integer"> <xs:minInclusive 100 and greater.
value="100"/> </xs:restriction>
</xs:simpleType>
base="xs:integer"> <xs:minInclusive 1000 and greater.
</xs:simpleType>
base="xs:integer"> <xs:minInclusive 4000 and great.
</xs:simpleType>
Example union types from fixml-fields-impl-M-N.xsd:
<xs:simpleType name="SettlType_t"> The Settlement type is a union of the settlement
type enumerations and the Tenor type described
<xs:union memberTypes="SettlType_enum_t Tenor"/>
above
</xs:simpleType>
<xs:simpleType name="OrdRejReason_t"> The OrderRejectReason field is a union of the
OrderReject Reason enumerations and can also
<xs:union memberTypes="OrdRejReason_enum_t be extended with user defined values of 100 or
Reserved100Plus"/>
greater.
</xs:simpleType>
Fields schema files

• Fields schema file (fixml-fields-*-M-N.xsd)
• Fields base file (fixml-fields-base-M-N.xsd)
The fixml-fields-base file contains simple type definitions for all FIX application level fields and
session level fields that are used as part of the FIXML header. All fields are defined as simple types. The
simple type name is derived from the full FIX field name appended with a “_t”. All fields with enumerations
are defined as simple types. The enumeration simple type name is derived from the full FIX field name
appended with a “enum_t”.

Field definition examples

An example of a field definition for the AvgPx (tag=6) field:
<xs:simpleType name="AvgPx_t">
<xs:annotation>
<xs:documentation xml:lang="en">Calculated average price of all
fills on this order For Fixed Income trades AvgPx is always expressed
as percent of par regardless of the PriceType 423 of LastPx 3 I e
AvgPx will contain an average of percent of par values see LastParPx 669
for issues traded in Yield Spread or Discount
</xs:documentation>
<xs:appinfo xmlns:x="http://www.fixprotocol.org/fixml/metadata.xsd">
<xs:Xref Protocol="FIX" name="AvgPx" tag="6" datatype="Price"
ComponentType="Field"/>
<xs:Xref Protocol="ISO_15022_XML"/>
</xs:appinfo>
</xs:annotation>
<xs:restriction base="Price"/>
</xs:simpleType>
An example of an enumerated field:

<xs:simpleType name="CommType_enum_t">
<xs:annotation>
<xs:documentation xml:lang="en">Commission type Valid values: = per
unit implying shares par currency etc 2 = percentage 3 = absolute
total monetary amount 4 = for CIV buy orders percentage waived cash
discount 5 = for CIV buy orders percentage waived enhanced units 6 =
points per bond or or contract Supply ContractMultiplier 23 in the
Instrument component block if the object security is denominated in a
size other than the industry default 000 par for bonds
</xs:documentation>
<xs:Xref Protocol="FIX" name="CommType" tag="13" datatype="char"
ComponentType="Field"/>
</xs:appinfo>
<x:EnumDoc value="1" desc="PerShare"/>
<x:EnumDoc value="2" desc="Percent"/>
<x:EnumDoc value="3" desc="Absolute"/>
<x:EnumDoc value="4" desc="PctWaivedCshDisc"/>
<x:EnumDoc value="5" desc="PctWaivedEnUnits"/>
<x:EnumDoc value="6" desc="PerBond"/>
</xs:appinfo>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="1"/>
</xs:restriction>
</xs:simpleType>

Fields implementation file (fixml-fields-impl-M-N.xsd)

One of the more convoluted constructs used was the need to place the field level definitions for enumerated
types in the fixml-fields-impl file. As shown above, the fixml-fields-base file defines each
enumerated field as a simple type named fieldname_enum_t. This enumerated type is then used to
define a corresponding field type in the fixml-fields-impl schema file named fieldname_t. It is this
fieldname_t type that is referenced in subsequent schema files (fixml-components and the message
category schema files). This construct was required to provide a mechanism to extend enumerations. The
fieldname_t can be modified in the fixml-fields-impl file to include additional enumerations. The
fieldname_t can be restricted by redefining the fieldname_enum_t simple type within the fixed-
shared-impl file.
Components (fixml-components-*-M-N.xsd)
Component files are used to define the reusable components that are used across FIX messages. The FIXML
root element and headers are defined in the components file, as well.
Components base file (fixml-components-base-M-N.xsd

The fixml-components-base file contains the definitions for all FIX component blocks defined in volume 1
of the FIX specification. The FIXML root element, FIXML headers, the batch element, and the abstract
message type are also defined within this file.
Components (and messages) are defined using element groups and attribute groups. The advantage of these
groups is that you can redefine the groups (using either restriction or extension) to change the overall
structure of the component (or message).
These groups are defined for each component and message.
componentOrMessageNameElements Contains a list of elements contained in the
component.
componentOrMessageNameAttributes Contains a list of Attributes contained in the
component.

The Parties Component block is shown below. Notice the overall definition pattern. This pattern is followed
for all component blocks and message definitions.
<xs:group name="PartiesElementsRequired">
<xs:sequence/>
</xs:group>
<xs:group name="PartiesElementsOptional">
<xs:sequence>
<xs:element name="PtySub" type="PtysSubGrp_Block_t" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<xs:group name="PartiesElementsCustom">
<xs:sequence/>
</xs:group>
<xs:attributeGroup name="PartiesAttributesRequired">
</xs:attributeGroup>
<xs:attributeGroup name="PartiesAttributesOptional">
<xs:attribute name="ID" type="PartyID_t" use="optional"/>
<xs:attribute name="IDSrc" type="PartyIDSource_t" use="optional"/>
<xs:attribute name="Role" type="PartyRole_t" use="optional"/>
<xs:attributeGroup name="PartiesAttributesCustom"/>
<xs:complexType name="Parties_Block_t" final="#all">

<xs:annotation>
<xs:documentation xml:lang="en">**Desc**
</xs:documentation>
<xs:appinfo>
<fm:Xref Protocol="FIX" name="Parties"
ComponentType="BlockRepeating"/>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:group ref="PartiesElementsRequired"/>
<xs:group ref="PartiesElementsOptional"/>
<xs:group ref="PartiesElementsCustom"/>
</xs:sequence>
<xs:attributeGroup ref="PartiesAttributesRequired"/>
<xs:attributeGroup ref="PartiesAttributesOptional"/>
<xs:attributeGroup ref="PartiesAttributesCustom"/>
</xs:complexType>
Components implementation file (fixml-components-impl-M-N.xsd)

The default version fixml-components-impl file simply redefines the components-base file. This is the file
where modifications (restrictions or extensions) would be made to component blocks used in the FIX
protocol.

Categories (fixml-categoryName-base-M-N.xsd)
Each message category defined within the FIX specification has its own schema file. This provides a granular
level of usage for applications only requiring access to one message categoryThe message category schema
files contain the component and message definitions that belong to a specific message category defined
within the FIX Protocol. Examples of message categories include: Indications, Market Data, Positions,
Allocation. . A complete list of the category files for FIXML is provided in the FIXML Schema File
Summary section.
Category messages and components are defined following the same pattern defined above for components.
The following defines the New Order Single message from the fixml-categoryOrder-5-0.xsd:
<xs:group name="NewOrderSingleElementsRequired">
<xs:sequence>
<xs:element name="Instrmt" type="Instrument_Block_t" minOccurs="1"
maxOccurs="1"/>
<xs:element name="OrdQty" type="OrderQtyData_Block_t" minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
</xs:group>
<xs:group name="NewOrderSingleElementsOptional">
<xs:sequence>
<xs:element name="Pty" type="Parties_Block_t" minOccurs="0"
<xs:element name="Stip" type="Stipulations_Block_t" minOccurs="0"
<xs:element name="FinDetls" type="FinancingDetails_Block_t" minOccurs="0"
maxOccurs="1"/>
<xs:element name="SprdBnchmkCurve"
type="SpreadOrBenchmarkCurveData_Block_t" minOccurs="0" maxOccurs="1"/>
<xs:element name="Yield" type="YieldData_Block_t" minOccurs="0"
maxOccurs="1"/>
<xs:element name="Comm" type="CommissionData_Block_t" minOccurs="0"
maxOccurs="1"/>
<xs:element name="PegInstr" type="PegInstructions_Block_t" minOccurs="0"
maxOccurs="1"/>
<xs:element name="DiscInstr" type="DiscretionInstructions_Block_t"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PreAll" type="PreAllocGrp_Block_t" minOccurs="0"
<xs:element name="TrdSes" type="TrdgSesGrp_Block_t" minOccurs="0"
<xs:element name="Undl" type="UndInstrmtGrp_Block_t" minOccurs="0"
</xs:sequence>
</xs:group>
<xs:group name="NewOrderSingleElementsCustom">
<xs:sequence/>
</xs:group>
<xs:attributeGroup name="NewOrderSingleAttributesRequired">
<xs:attribute name="ClOrdID" type="ClOrdID_t" use="required"/>
<xs:attribute name="Side" type="Side_t" use="required"/>
<xs:attribute name="TransactTm" type="TransactTime_t" use="required"/>
<xs:attribute name="OrdTyp" type="OrdType_t" use="required"/>
<xs:attributeGroup name="NewOrderSingleAttributesOptional">
<xs:attribute name="ScndClOrdID" type="SecondaryClOrdID_t"
use="optional"/>
<xs:attribute name="ClOrdLinkID" type="ClOrdLinkID_t" use="optional"/>
<xs:attribute name="TrdOrigntnDt" type="TradeOriginationDate_t"
use="optional"/>
<xs:attribute name="TrdDt" type="TradeDate_t" use="optional"/>

<xs:attribute name="Acct" type="Account_t" use="optional"/>

<xs:attribute name="AcctIDSrc" type="AcctIDSource_t" use="optional"/>
<xs:attribute name="AcctTyp" type="AccountType_t" use="optional"/>
<xs:attribute name="DayBkngInst" type="DayBookingInst_t" use="optional"/>
<xs:attribute name="BkngUnit" type="BookingUnit_t" use="optional"/>
<xs:attribute name="PreallocMethod" type="PreallocMethod_t"
use="optional"/>
<xs:attribute name="AllocID" type="AllocID_t" use="optional"/>
<xs:attribute name="SettlTyp" type="SettlType_t" use="optional"/>
<xs:attribute name="SettlDt" type="SettlDate_t" use="optional"/>
<xs:attribute name="CshMgn" type="CashMargin_t" use="optional"/>
<xs:attribute name="ClrngFeeInd" type="ClearingFeeIndicator_t"
use="optional"/>
<xs:attribute name="HandlInst" type="HandlInst_t" use="optional"/>
<xs:attribute name="ExecInst" type="ExecInst_t" use="optional"/>
<xs:attribute name="MinQty" type="MinQty_t" use="optional"/>
<xs:attribute name="MaxFloor" type="MaxFloor_t" use="optional"/>
<xs:attribute name="ExDest" type="ExDestination_t" use="optional"/>
<xs:attribute name="ProcCode" type="ProcessCode_t" use="optional"/>
<xs:attribute name="PrevClsPx" type="PrevClosePx_t" use="optional"/>
<xs:attribute name="LocReqd" type="LocateReqd_t" use="optional"/>
<xs:attribute name="QtyTyp" type="QtyType_t" use="optional"/>
<xs:attribute name="PxTyp" type="PriceType_t" use="optional"/>
<xs:attribute name="Px" type="Price_t" use="optional"/>
<xs:attribute name="StopPx" type="StopPx_t" use="optional"/>
<xs:attribute name="Ccy" type="Currency_t" use="optional"/>
<xs:attribute name="ComplianceID" type="ComplianceID_t" use="optional"/>
<xs:attribute name="SolFlag" type="SolicitedFlag_t" use="optional"/>
<xs:attribute name="IOIID" type="IOIID_t" use="optional"/>
<xs:attribute name="QID" type="QuoteID_t" use="optional"/>
<xs:attribute name="TmInForce" type="TimeInForce_t" use="optional"/>
<xs:attribute name="EfctvTm" type="EffectiveTime_t" use="optional"/>
<xs:attribute name="ExpireDt" type="ExpireDate_t" use="optional"/>
<xs:attribute name="ExpireTm" type="ExpireTime_t" use="optional"/>
<xs:attribute name="GTBkngInst" type="GTBookingInst_t" use="optional"/>
<xs:attribute name="Cpcty" type="OrderCapacity_t" use="optional"/>
<xs:attribute name="Rstctions" type="OrderRestrictions_t"
use="optional"/>
<xs:attribute name="CustOrdCpcty" type="CustOrderCapacity_t"
use="optional"/>
<xs:attribute name="ForexReq" type="ForexReq_t" use="optional"/>
<xs:attribute name="SettlCcy" type="SettlCurrency_t" use="optional"/>
<xs:attribute name="BkngTyp" type="BookingType_t" use="optional"/>
<xs:attribute name="Txt" type="Text_t" use="optional"/>
<xs:attribute name="EncTxtLen" type="EncodedTextLen_t" use="optional"/>
<xs:attribute name="EncTxt" type="EncodedText_t" use="optional"/>
<xs:attribute name="SettlDt2" type="SettlDate2_t" use="optional"/>
<xs:attribute name="Qty2" type="OrderQty2_t" use="optional"/>
<xs:attribute name="Px2" type="Price2_t" use="optional"/>
<xs:attribute name="PosEfct" type="PositionEffect_t" use="optional"/>
<xs:attribute name="CoveredOrUncovered" type="CoveredOrUncovered_t"
use="optional"/>
<xs:attribute name="MaxShow" type="MaxShow_t" use="optional"/>
<xs:attribute name="TgtStrategy" type="TargetStrategy_t" use="optional"/>
<xs:attribute name="TgtStrategyParameters"
type="TargetStrategyParameters_t" use="optional"/>
<xs:attribute name="ParticipationRt" type="ParticipationRate_t"
use="optional"/>
<xs:attribute name="CxllationRights" type="CancellationRights_t"
use="optional"/>
<xs:attribute name="MnyLaunderingStat" type="MoneyLaunderingStatus_t"
use="optional"/>

<xs:attribute name="RegistID" type="RegistID_t" use="optional"/>

<xs:attribute name="Designation" type="Designation_t" use="optional"/>
<xs:attributeGroup name="NewOrderSingleAttributesCustom"/>
<xs:complexType name="NewOrderSingle_message_t" final="#all">

<xs:complexContent>
<xs:extension base="Abstract_message_t">
<xs:sequence>
<xs:group ref="NewOrderSingleElementsRequired"/>
<xs:group ref="NewOrderSingleElementsOptional"/>
<xs:group ref="NewOrderSingleElementsCustom"/>
</xs:sequence>
<xs:attributeGroup ref="NewOrderSingleAttributesRequired"/>
<xs:attributeGroup ref="NewOrderSingleAttributesOptional"/>
<xs:attributeGroup ref="NewOrderSingleAttributesCustom"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="NewOrdSingle" type="NewOrderSingle_message_t"

substitutionGroup="Message" final="#all"/>
Categories (fixml-categoryName-impl-M-N.xsd)
Each message category defined within the FIX specification has its own schema file. This provides a granular
level of usage for applications only requiring access to one message category. A complete list of the category
files for FIXML is provided below in the FIXML File Summary table.
Trading Life Cycle files

Convenience files are provided with the FIXML schema version that includes the message categories for each
of the trade life cycles (pre-trade, trade, post-trade) used by FIX. These files are provided to make it easier for
applications that require access to multiple message categories within one of the trading life cycles.
Pretrade file (fixml-pretrade-M-N.xsd)

Includes the pre-trade message category implementation files.
Trade file (fixml-trade-M-N.xsd)

Includes the trade message category implementation files.
Post trade file (fixml-trade-M-N.xsd)

Includes the post trade message category implementation files.
Main (fixml-main-M-N.xsd)
A main schema file is included that pulls in the pretrade, trade, and post trade schema files. This is provided
for applications that require access to the full suite of FIX messages.
Customization

The FIXML Schema files have been organized to permit extensibility. Implementation versions of each
schema file (with the exception of the datatypes file) are provided to permit users to redefine the base FIXML
Schema version, as defined in the base files. This section provides guidelines for customizing the FIXML
syntax. Even though a considerable amount of work has gone into making FIXML extensible, users are
strongly encouraged to minimize modifications, in order to promote more consistent usage of the FIXML
syntax within the industry. Obviously, the less customization, the easier it is to connect to counterparties. If
customization is required, you are encouraged to communicate your requirements that are not being met by
FIX to the FPL Global Technical Committee. There you may find out that there is a technique to meet your
business requirement. Or, you may find that the Technical Committee has already addressed the issue for a
planned future release. At a minimum you will receive coaching and assistance in how to extend FIXML in
such a way as to make the new feature a part of a future version of FIX.
Defining a custom field

New fields are defined as an XML SimpleType in the fixml-shared-impl-N-N.xsd file. You are recommended
to add the file to the end of the schema document. You also are strongly encouraged to include XML
comments to define the reason for the field.
The field should then be added to the component or message where it will be used, once the field is defined in
the fixml-shared-impl schema file.
If the field will be added to a component contained in fixml-components-base-N-N.xsd, you must now
redefine that component in the fixml-components-impl-N-N.xsd file.
Adding a field to a component or message contained in one of the message categories is done in the same way
you modify the components schema file. You need to redefine the portion of the message in the
implementation version of the file.
You are encouraged to follow the same procedure for procuring new custom field names as is done for the
FIX tag=value version of FIX. The FIX website provides a web page of custom fields and a form to submit
requests for additional custom fields.
Restricting enumeration values for a FIX field

Restricting enumeration values is done by modifying the type definition in the fixml-shared-impl schema file.
Extending enumeration values for a FIX field

Extending enumeration values is done by creating a union of the original enumeration type definition with
new enumeration values.
Making an optional field required

Making an optional field required is done by redefining the optional attribute group, modifying the usage of
the field from “optional” to “required”. This redefinition is done within the implementation file for either the
components or a particular message category.
Making a required field optional

It is not possible to make a required field optional without modifying the original required element or
attribute group. Making required fields optional does go against the standard base definition of FIX and
should be avoided.
Adding a custom message

Custom messages are added by creating a message structure within the category to which the custom message
belongs. Required and optional element and attribute groups should be created for the custom message.
FIXML Schema Version Datatypes

Type BaseT FIXML Implementation Example
ype
int Use builtin type: xs:integer
Length int <xs:simpleType name="Length">
<xs:restriction
base="xs:nonNegativeInteger">
</xs:restriction> </xs:simpleType>
TagNum int NOT REQUIRED IN FIXML
SeqNum int <xs:simpleType name="SeqNum">
<xs:restriction
base="xs:positiveInteger">
NumInGroup int NOT REQUIRED IN FIXML
DayOfMonth int NOT REQUIRED IN FIXML
float Use builtin type: xs:decimal
Qty float <xs:simpleType name="Qty">
<xs:restriction base="xs:decimal">
Price float <xs:simpleType name="Price"> Strk="47.50"
PriceOffset float <xs:simpleType name="PriceOffset">
Amt float <xs:simpleType name="Amt"> Amt="6847.00"
Percentage float <xs:simpleType name="Percentage">
char <xs:simpleType name="xs:string">
<xs:restriction base=""> <xs:pattern
value=".{1}"/> </xs:restriction>
</xs:simpleType>
Boolean char <xs:simpleType name="Boolean">
<xs:pattern value="[YN]{1}"/>
String Use builtin type: xs:string
MultipleCharValue String <xs:simpleType
name="MultipleCharValue">
<xs:pattern value="[A-Za-z0-9](\s[A-Za-


ype
z0-9])*"/> </xs:restriction>
</xs:simpleType>
MultipleStringValue String <xs:simpleType
name="MultipleStringValue">
<xs:pattern value=".+(\s.+)*"/>
Country String <xs:simpleType name="Country">
<xs:pattern value=".{2}"/>
Currency String <xs:simpleType name="Currency"> StrkCcy="USD"
<xs:pattern value=".{3}"/>
Exchange String <xs:simpleType name="Exchange">
<xs:pattern value=".*"/>
MonthYear String <xs:simpleType name="MonthYear"> MonthYear="200303",
<xs:restriction base="xs:string"> MonthYear="20030320",
<xs:pattern value="\d{4}(0|1)\d([0- MonthYear="200303w2"
3wW]\d)?"/> </xs:restriction>
</xs:simpleType>
UTCTimestamp String <xs:simpleType TransactTm="2001-12-
name="UTCTimestamp"> <xs:restriction 17T09:30:47-05:00"
base="xs:dateTime"> </xs:restriction>
</xs:simpleType>
UTCTimeOnly String <xs:simpleType MDEntryTime="13:20:00.000-
name="UTCTimeOnly"> <xs:restriction 05:00"
base="xs:time"> </xs:restriction>
</xs:simpleType>
UTCDateOnly String <xs:simpleType name="UTCDateOnly"> MDEntryDate="2003-09-10"
<xs:restriction base="xs:date">
LocalMktDate String <xs:simpleType name="LocalMktDate"> BizDate="2003-09-10"
<xs:restriction base="xs:date">
TZTimeOnly String <xs:simpleType name="TZTimeOnly">
<xs:restriction base="xs:time">
TZTimestamp String <xs:simpleType name="TZTimestamp">
<xs:restriction base="xs:dateTime">
data String <xs:simpleType name="data">


ype
XMLData String <xs:simpleType name="XMLData">
Pattern NOT REQUIRED IN FIXML
Tenor Pattern <xs:simpleType name="Tenor">
<xs:pattern value="[DMWY](\d)+"/>
Reserved100Plus Pattern <xs:simpleType
name="Reserved100Plus">
<xs:restriction base="xs:integer">
<xs:minInclusive value="100"/>
FIXML Schema File Summary
File Name Description
Fixml-datatypes-5-0-SP1.xsd Defines the base data types that are to be used in other fixml schema
files. These fixml base data types are based on simple types built into
XML Schema.
Fixml-session-base-5-0-SP1.xsd Includes Fixml--base-5-0-SP1.xsd. Defines Session messages:

Heartbeat
Logon
Logout
Reject
ResendRequest
SequenceReset
TestRequest
XML_non_FIX
Fixml-indications-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines Indication

messages:
Advertisement
IOI

Fixml-indications-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the Indication message category.
Fixml-order-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

SingleGeneralOrderHandling messages:
DontKnowTradeDK
ExecutionAcknowledgement
ExecutionReport
NewOrderSingle
OrderCancelReject
OrderCancelReplaceRequest
OrderCancelRequest
OrderStatusRequest
Fixml-order-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the SingleGeneralOrderHandling message category.
Fixml-newsevents-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

EventCommunication messages:
Email
News
Fixml-newsevents-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the EventCommunication message category.
Fixml-listorders-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines ProgramTrading

messages:
BidRequest
BidResponse
ListCancelRequest
ListExecute
ListStatus
ListStatusRequest
ListStrikePrice
NewOrderList
Fixml-listorders-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the ProgramTrading message category.
Fixml-ordermasshandling-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

OrderMassHandling messages:
OrderMassActionReport
OrderMassActionRequest
OrderMassCancelReport
OrderMassCancelRequest
OrderMassStatusRequest
Fixml-ordermasshandling-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the OrderMassHandling message category.

Fixml-allocation-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines Allocation

messages:
AllocationInstruction
AllocationInstructionAck
AllocationInstructionAlert
AllocationReport
AllocationReportAck
Fixml-allocation-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the Allocation message category.
Fixml-quotation-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

QuotationNegotiation messages:
MassQuote
MassQuoteAcknowledgement
Quote
QuoteCancel
QuoteRequest
QuoteRequestReject
QuoteResponse
QuoteStatusReport
QuoteStatusRequest
RFQRequest
Fixml-quotation-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the QuotationNegotiation message category.
Fixml-settlement-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

SettlementInstruction messages:
SettlementInstructionRequest
SettlementInstructions
SettlementObligationReport
Fixml-settlement-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the SettlementInstruction message category.
Fixml-marketdata-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines MarketData

messages:
MarketDataIncrementalRefresh
MarketDataRequest
MarketDataRequestReject
MarketDataSnapshotFullRefresh
Fixml-marketdata-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the MarketData message category.
Fixml-marketstructure-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines MarketStructure

messages:
MarketDefinition
MarketDefinitionRequest
MarketDefinitionUpdateReport

TradingSessionList
TradingSessionListRequest
TradingSessionListUpdateReport
TradingSessionStatus
TradingSessionStatusRequest
Fixml-marketstructure-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the MarketStructure message category.
Fixml-referencedata-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines ReferenceData

messages:
DerivativeSecurityList
DerivativeSecurityListRequest
DerivativeSecurityListUpdateReport
SecurityDefinition
SecurityDefinitionRequest
SecurityDefinitionUpdateReport
SecurityList
SecurityListRequest
SecurityListUpdateReport
SecurityStatus
SecurityStatusRequest
SecurityTypeRequest
SecurityTypes
Fixml-referencedata-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the ReferenceData message category.
Fixml-components-base-5-0-SP1.xsd Includes Fixml-fields-base-5-0-SP1.xsd. Defines Common messages:
Fixml-components-impl-5-0-SP1.xsd Includes FIX50-fields-impl-5-0-SP1.xsd.

Used to customise the Common message category.
Fixml-registration-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

RegistrationInstruction messages:
RegistrationInstructions
RegistrationInstructionsResponse
Fixml-registration-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the RegistrationInstruction message category.
Fixml-crossorders-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines CrossOrders

messages:
CrossOrderCancelReplaceRequest
CrossOrderCancelRequest
NewOrderCross
Fixml-crossorders-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the CrossOrders message category.

Fixml-multilegorders-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines MultilegOrders

messages:
MultilegOrderCancelReplace
NewOrderMultileg
Fixml-multilegorders-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the MultilegOrders message category.
Fixml-tradecapture-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines TradeCapture

messages:
TradeCaptureReport
TradeCaptureReportAck
TradeCaptureReportRequest
TradeCaptureReportRequestAck
Fixml-tradecapture-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the TradeCapture message category.
Fixml-confirmation-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines Confirmation

messages:
Confirmation
Confirmation_Ack
ConfirmationRequest
Fixml-confirmation-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the Confirmation message category.
Fixml-positions-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

PositionMaintenance messages:
AdjustedPositionReport
AssignmentReport
ContraryIntentionReport
PositionMaintenanceReport
PositionMaintenanceRequest
PositionReport
RequestForPositions
RequestForPositionsAck
Fixml-positions-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the PositionMaintenance message category.
Fixml-collateral-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines

CollateralManagement messages:
CollateralAssignment
CollateralInquiry
CollateralInquiryAck
CollateralReport
CollateralRequest
CollateralResponse
Fixml-collateral-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the CollateralManagement message category.
Fixml-application-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines Application

messages:
ApplicationMessageReport
ApplicationMessageRequest
ApplicationMessageRequestAck
Fixml-application-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the Application message category.
Fixml-businessreject-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines BusinessReject

messages:
BusinessMessageReject
Fixml-businessreject-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the BusinessReject message category.
Fixml-network-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines Network

messages:
NetworkCounterpartySystemStatusRequest
NetworkCounterpartySystemStatusResponse
Fixml-network-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the Network message category.
Fixml-usermanagement-base-5-0-SP1.xsd Includes Fixml-components-base-5-0-SP1.xsd. Defines UserManagement

messages:
UserNotification
UserRequest
UserResponse
Fixml-usermanagement-impl-5-0-SP1.xsd Includes FIX50-components-impl-5-0-SP1.xsd.

Used to customise the UserManagement message category.
Fixml-fields-base-5-0-SP1.xsd Includes Fixml--base-5-0-SP1.xsd. Defines Fields messages:
Fixml-fields-base-5-0-SP1.xsd Includes Fixml--base-5-0-SP1.xsd. Defines Impl Fields messages:
Fixml-session-base-5-0-SP1.xsd Session level messages to establish and control a FIX session
Fixml-pretrade-base-5-0-SP1.xsd Pre trade messages including reference data, market data, quoting, news
and email, indication of interest
Fixml-trade-base-5-0-SP1.xsd Order handling and execution messages
Fixml-posttrade-base-5-0-SP1.xsd Post trade messages including trade reporting, allocation, collateral,

confirmation, position mantemenance, registration instruction, and
settlement instructions

Fixml-infrastructure-base-5-0-SP1.xsd Infrastructure messages for application sequencing, business reject,

network and user management
Fixml-main-5-0-SP1.xsd Includes the session, pretrade, trade, posttrade and infrastructure schema
files

COMMON COMPONENTS OF APPLICATION MESSAGES - Component

Blocks (Included in pre-trade, trade, and post-trade messages)
Many of the FIX Application Messages are composed of common "building blocks" or sets of data fields. For
instance, almost every FIX Application Message has the set of symbology-related fields used to define the
"Instrument": Symbol, SymbolSfx, SecurityIDSource, SecurityID….. EncodedSecurityDesc. Rather than
replicate a common group of fields, the FIX specification specifies several key component blocks below which are
simply referenced by component name within each Application Message which uses them. Thus when reviewing
a specific message definition, the appropriate group of fields should be expanded and used whenever a component
block is identified.
Note that some component blocks may be part of repeating groups thus if the component block is denoted as part
of a repeating group, then the entire group of fields representing the component block are to be specified at the
component block's repeating group "level" in the message definition and follow repeating group rules concerning
field order. See "Repeating Groups" for more details.
Instrument (symbology) component block

The Instrument component block contains all the fields commonly used to describe a security or instrument.
Typically the data elements in this component block are considered the static data of a security, data that may be
commonly found in a security master database. The Instrument component block can be used to describe any
asset type supported by FIX.
Tag FieldName Req'd Comments

55 Symbol N Common, "human understood" representation of the
security. SecurityID value can be specified if no symbol
exists (e.g. non-exchange traded Collective Investment
Vehicles)
Use "[N/A]" for products which do not have a
symbol.
65 SymbolSfx N Used in Fixed Income with a value of "WI" to indicate
"When Issued" for a security to be reissued under an old
CUSIP or ISIN or with a value of "CD" to indicate a
EUCP with lump-sum interest rather than discount price.
48 SecurityID N Takes precedence in identifying security to counterparty
over SecurityAltID block. Requires SecurityIDSource if
specified.
22 SecurityIDSource N Required if SecurityID is specified.
Start of Component block, expanded in line < SecAltIDGrp >
454 NoSecurityAltID N
 455 SecurityAltID N
 456 SecurityAltIDSource N
End of Component block, expanded in line < SecAltIDGrp >
460 Product N Indicates the type of product the security is associated
with (high-level category)
1227 ProductComplex N Identifies an entire suite of products for a given market.
In Futures this may be "interest rates", "agricultural",
"equity indexes", etc

1151 SecurityGroup N An exchange specific name assigned to a group of

related securities which may be concurrently affected by
market events and actions.
461 CFICode N Indicates the type of security using ISO 10962 standard,
Classification of Financial Instruments (CFI code)
values. It is recommended that CFICode be used instead
of SecurityType for non-Fixed Income instruments.
167 SecurityType N It is recommended that CFICode be used instead of
SecurityType for non-Fixed Income instruments.
Required for Fixed Income. Refer to Volume 7 -
Fixed Income
Futures and Options should be specified using the
CFICode[461] field instead of SecurityType[167] (Refer
to Volume 7 - Recommendations and Guidelines for
Futures and Options Markets.)
762 SecuritySubType N Sub-type qualification/identification of the SecurityType
(e.g. for SecurityType="MLEG"). If specified,
SecurityType is required.
200 MaturityMonthYear N Specifies the month and year of maturity. Applicable for
standardized derivatives which are typically only
referenced by month and year (e.g. S&P futures). Note
MaturityDate (a full date) can also be specified.
541 MaturityDate N Specifies date of maturity (a full date). Note that
standardized derivatives which are typically only
referenced by month and year (e.g. S&P futures).may
use MaturityMonthYear and/or this field.
When using MaturityMonthYear, it is recommended
that markets and sell sides report the MaturityDate on all
outbound messages as a means of data enrichment.
1079 MaturityTime N
966 SettleOnOpenFlag N Indicator to determine if Instrument is Settle on Open.
1049 InstrmtAssignmentMethod N
965 SecurityStatus N Gives the current state of the instrument
224 CouponPaymentDate N Date interest is to be paid. Used in identifying Corporate
Bond issues.
225 IssueDate N Date instrument was issued. For Fixed Income IOIs for
new issues, specifies the issue date.
239 RepoCollateralSecurityType N (Deprecated in FIX.4.4)
226 RepurchaseTerm N (Deprecated in FIX.4.4)
227 RepurchaseRate N (Deprecated in FIX.4.4)
228 Factor N For Fixed Income: Amortization Factor for deriving
Current face from Original face for ABS or MBS
securities, note the fraction may be greater than, equal to
or less than 1. In TIPS securities this is the Inflation
index.
Qty * Factor * Price = Gross Trade Amount

For Derivatives: Contract Value Factor by which

price must be adjusted to determine the true nominal
value of one futures/options contract.
(Qty * Price) * Factor = Nominal Value
255 CreditRating N
543 InstrRegistry N The location at which records of ownership are
maintained for this instrument, and at which ownership
changes must be recorded. Can be used in conjunction
with ISIN to address ISIN uniqueness issues.
470 CountryOfIssue N ISO Country code of instrument issue (e.g. the country
portion typically used in ISIN). Can be used in
conjunction with non-ISIN SecurityID (e.g. CUSIP for
Municipal Bonds without ISIN) to provide uniqueness.
471 StateOrProvinceOfIssue N A two-character state or province abbreviation.
472 LocaleOfIssue N The three-character IATA code for a locale (e.g. airport
code for Municipal Bonds).
240 RedemptionDate N (Deprecated in FIX.4.4)
202 StrikePrice N Used for derivatives, such as options and covered
warrants
947 StrikeCurrency N Used for derivatives
967 StrikeMultiplier N Used for derivatives. Multiplier applied to the strike
price for the purpose of calculating the settlement value.
968 StrikeValue N Used for derivatives. The number of shares/units for the
financial instrument involved in the option trade.
206 OptAttribute N Used for derivatives, such as options and covered
warrants to indicate a versioning of the contract when
required due to corporate actions to the underlying.
Should not be used to indicate type of option - use the
CFICode[461] for this purpose.
231 ContractMultiplier N For Fixed Income, Convertible Bonds, Derivatives, etc.
Note: If used, quantities should be expressed in the
"nominal" (e.g. contracts vs. shares) amount.
969 MinPriceIncrement N Minimum price increment for the instrument. Could also
be used to represent tick value.
1146 MinPriceIncrementAmount N Minimum price increment amount associated with the
MinPriceIncrement [969]. For listed derivatives, the
value can be calculated by multiplying
MinPriceIncrement by ContractValueFactor [231]
996 UnitOfMeasure N 0
1147 UnitOfMeasureQty N
1191 PriceUnitOfMeasure N
1192 PriceUnitOfMeasureQty N
1193 SettlMethod N Settlement method for a contract. Can be used as an
alternative to CFI Code value
1194 ExerciseStyle N Type of exercise of a derivatives security

1195 OptPayAmount N Cash amount indicating the pay out associated with an
option. For binary options this is a fixed amount
1196 PriceQuoteMethod N Method for price quotation
1197 FuturesValuationMethod N For futures, indicates type of valuation method applied
1198 ListMethod N Indicates whether the instruments are pre-listed only or
can also be defined via user request
1199 CapPrice N Used to express the ceiling price of a capped call
1200 FloorPrice N Used to express the floor price of a capped put
201 PutOrCall N Used to express option right
1244 FlexibleIndicator N Used to indicate if a security has been defined as flexible
according to "non-standard" means. Analog to CFICode
Standard/Non-standard indicator
1242 FlexProductEligibilityIndicato N Used to indicate if a product or group of product
r supports the creation of flexible securities
997 TimeUnit N Used to indicate a time unit for the contract (e.g., days,
weeks, months, etc.)
223 CouponRate N For Fixed Income.
207 SecurityExchange N Can be used to identify the security.
970 PositionLimit N Position Limit for the instrument.
971 NTPositionLimit N Near-term Position Limit for the instrument.
106 Issuer N
348 EncodedIssuerLen N Must be set if EncodedIssuer field is specified and must
immediately precede it.
349 EncodedIssuer N Encoded (non-ASCII characters) representation of the
Issuer field in the encoded format specified via the
MessageEncoding field.
107 SecurityDesc N
350 EncodedSecurityDescLen N Must be set if EncodedSecurityDesc field is specified
and must immediately precede it.
351 EncodedSecurityDesc N Encoded (non-ASCII characters) representation of the
SecurityDesc field in the encoded format specified via
the MessageEncoding field.
component block <SecurityXML> N Embedded XML document describing security.
691 Pool N Identifies MBS / ABS pool
667 ContractSettlMonth N Must be present for MBS/TBA
875 CPProgram N The program under which a commercial paper is issued
876 CPRegType N The registration type of a commercial paper issuance
Start of Component block, expanded in line < EvntGrp >
864 NoEvents N
 865 EventType N
 866 EventDate N

 1145 EventTime N Specific time of event. To be used in combination with

EventDate [866]
 867 EventPx N
 868 EventText N
End of Component block, expanded in line < EvntGrp >
873 DatedDate N If different from IssueDate
874 InterestAccrualDate N If different from IssueDate and DatedDate
component block <InstrumentParties> N Used to identify the parties listing a specific instrument
*** = Required status should match "Req'd" setting for <Instrument> component block in the message definition
FIXML Definition for this Component Block– see TUhttp://www.fixprotocol.org for

H UTH
details
Refer to FIXML Element Instrmt

Examples using Alternative Security IDs

The SecurityAltID repeating group is used to carry additional security identifiers for the same security. Note that
this repeating group can only be used inconjunction with the information in SecurityID and SecurityIDSource
fields. In other words, it may not be used instead of the SecurityID and SecurityIDSource fields.
The first example is from an order for shares in Daimler Chrysler, which has an ISIN DE0007100000, a CUSIP
D1668R123, and a Sedol 5529027
Field (tag) Value Explanation

Symbol (55) DCX Symbol = DCX (Daimler Chrysler)
SecurityID (48) DE0007100000
SecurityIDSource (22) 4 ID Type is ISIN
NoSecurityAltID (454) 2 Two additional security IDs specified
 SecurityAltID (455) D1668R123
 SecurityAltIDSource (456) 1 SecurityID type is Cusip
 SecurityAltID (455) 5529027
 SecurityAltIDSource (456) 2 SecurityID type is Sedol
The second example is from an order for shares in IBM, which has an ISIN US4592001014, and a QUICK
(Japanese) code of 000006680

Symbol (55) IBM Symbol = IBM (International
Business Machines)
SecurityID (48) US4592001014
SecurityIDSource (22) 4 ID Type is ISIN
NoSecurityAltID (454) 1 One additional security ID specified
 SecurityAltID (455) 000006680
 SecurityAltIDSource (456) 3 SecurityID type is Quick
Specifying an FpML product specification from within the FIX Instrument Block
There are two methods in which a FpML product specification or document can be referenced from the FIX
Instrument component block. The first method allows the full FpML product document to be embedded
within the Instrument component block's SecurityXML (1185) field, found in the SecurityXML component
block. The second method allows the FpML production document to be referenced as a URL in the
Instrument component block. The tables below illustrates these two methods.

Option 1 – Include the FpML product specification as an XML String within SecurityXML
Symbol (55) [N/A]
SecurityID (48) [FpML] Refer to EncodedSecurityDesc for the
FpML product decription,
SecurityIDSource (22) I ISDA/FpML Product Specification
SecurityXMLLen (1184) 1234 The length of the FpML product
specification contained within
EncodedSecurityDesc
SecurityXML (1185) <FpML>….</FpML> Contains the FpML product
specification as an XML string
SecuityXMLSchema fpml.org/... Contains the URI or URL for the
schema that is used to interpret the
XML payload in SecurityXML (1185)
Note that prior to FIX 5.0 SP1 the FpML product specification was recommended to be transmitted in the
EncodedSecurityDesc (351) field. By using the SecurityXML (1185) field to transmit the FpML product
specification the EncodedSecurityDesc (351) field can be used in its intended manner to provide security
descriptions using non-ASCII character encoding. This prior approach may still be used in FIX 5.0 and prior
versions.
Option 2 – Reference the FpML product specification from another source via a URL in SecurityID
Symbol (55) [N/A]
SecurityID (48) (a valid URL Specify a URL to reference a separate
reference) or external location for the FpML
product description.
Example:
TUhttp://www.cme.com/produ
H
ct/irswap.jpg?id=122345 UTH
SecurityIDSource (22) K ISDA/FpML Product URL

UnderlyingInstrument (underlying instrument) component block

The UnderlyingInstrument component block, like the Instrument component block, contains all the fields
commonly used to describe a security or instrument. In the case of the UnderlyingInstrument component
block it describes an instrument which underlies the primary instrument Refer to the Instrument component
block comments as this component block mirrors Instrument, except for the noted fields.

311 UnderlyingSymbol N
312 UnderlyingSymbolSfx N
309 UnderlyingSecurityID N
305 UnderlyingSecurityIDSource N
Start of Component block, expanded in line < UndSecAltIDGrp >
457 NoUnderlyingSecurityAltID N
 458 UnderlyingSecurityAlt N
ID
 459 UnderlyingSecurityAlt N
IDSource
End of Component block, expanded in line < UndSecAltIDGrp >
462 UnderlyingProduct N
463 UnderlyingCFICode N
310 UnderlyingSecurityType N
763 UnderlyingSecuritySubType N
313 UnderlyingMaturityMonthYea N
r
542 UnderlyingMaturityDate N
1213 UnderlyingMaturityTime N
241 UnderlyingCouponPaymentDa N
te
242 UnderlyingIssueDate N
243 UnderlyingRepoCollateralSec N (Deprecated in FIX.4.4)
urityType
244 UnderlyingRepurchaseTerm N (Deprecated in FIX.4.4)
245 UnderlyingRepurchaseRate N (Deprecated in FIX.4.4)
246 UnderlyingFactor N
256 UnderlyingCreditRating N
595 UnderlyingInstrRegistry N
592 UnderlyingCountryOfIssue N
593 UnderlyingStateOrProvinceOf N
Issue
594 UnderlyingLocaleOfIssue N

247 UnderlyingRedemptionDate N (Deprecated in FIX.4.4)

316 UnderlyingStrikePrice N
941 UnderlyingStrikeCurrency N
317 UnderlyingOptAttribute N
436 UnderlyingContractMultiplier N
998 UnderlyingUnitOfMeasure N
1423 UnderlyingUnitOfMeasureQty N
1424 UnderlyingPriceUnitOfMeasur N
e
1425 UnderlyingPriceUnitOfMeasur N
eQty
1000 UnderlyingTimeUnit N Used to indicate a time unit for the contract (e.g., days,
1419 UnderlyingExerciseStyle N
435 UnderlyingCouponRate N
308 UnderlyingSecurityExchange N
306 UnderlyingIssuer N
362 EncodedUnderlyingIssuerLen N
363 EncodedUnderlyingIssuer N
307 UnderlyingSecurityDesc N
364 EncodedUnderlyingSecurityD N
escLen
365 EncodedUnderlyingSecurityD N
esc
877 UnderlyingCPProgram N
878 UnderlyingCPRegType N
972 UnderlyingAllocationPercent N Specific to the < UnderlyingInstrument > Percent of the
Strike Price that this underlying represents. Necessary
for derivatives that deliver into more than one underlying
instrument.
318 UnderlyingCurrency N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
879 UnderlyingQty N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
Unit amount of the underlying security (par, shares,
currency, etc.)
975 UnderlyingSettlementType N Specific to the < UnderlyingInstrument > Indicates order
settlement period for the underlying deliverable
component.
973 UnderlyingCashAmount N Specific to the < UnderlyingInstrument > Cash amount
associated with the underlying component. Necessary
for derivatives that deliver into more than one underlying

instrument and one of the underlying's is a fixed cash

value.
974 UnderlyingCashType N Specific to the < UnderlyingInstrument > Used for
derivatives that deliver into cash underlying. Indicates
that the cash is either fixed or difference value
(difference between strike and current underlying price)
810 UnderlyingPx N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
In a financing deal clean price (percent-of-par or per
unit) of the underlying security or basket.
882 UnderlyingDirtyPrice N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
In a financing deal price (percent-of-par or per unit)
of the underlying security or basket. "Dirty" means it
includes accrued interest
883 UnderlyingEndPrice N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
In a financing deal price (percent-of-par or per unit)
of the underlying security or basket at the end of the
agreement.
884 UnderlyingStartValue N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
Currency value attributed to this collateral at the start
of the agreement
885 UnderlyingCurrentValue N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
Currency value currently attributed to this collateral
886 UnderlyingEndValue N Specific to the <UnderlyingInstrument> (not in
<Instrument>)
Currency value attributed to this collateral at the end
of the agreement
component block N Specific to the <UnderlyingInstrument> (not in
<UnderlyingStipulations> <Instrument>)
Insert here the contents of the
<UnderlyingStipulations> Component Block
1044 UnderlyingAdjustedQuantity N Specific to the <UnderlyingInstrument> (not in
<Instrument>). For listed derivatives margin
management, this is the number of shares adjusted for
upcoming corporate action. Used only for securities
which are optionable and are between ex-date and
settlement date (4 days).
1045 UnderlyingFXRate N Specific to the <UnderlyingInstrument> (not in
<Instrument>). Foreign exchange rate used to compute
UnderlyingCurrentValue (885) (or market value) from
UnderlyingCurrency (318) to Currency (15).
1046 UnderlyingFXRateCalc N Specific to the <UnderlyingInstrument> (not in
<Instrument>). Specified whether UnderlyingFxRate

(1045) should be multiplied or divided to derive

UnderlyingCurrentValue (885).
1038 UnderlyingCapValue N
component block N
<UndlyInstrumentParties>
1039 UnderlyingSettlMethod N
315 UnderlyingPutOrCall N Used to express option right
*** = Required status should match "Req'd" setting for <UnderlyingInstrument> component block in the message
definition

H UTH
details
Refer to FIXML element UndInstrmt

InstrumentLeg (symbology) component block

The InstrumentLeg component block, like the Instrument component block, contains all the fields commonly used
to describe a security or instrument. In the case of the InstrumentLeg component block it describes a security
used in multileg-oriented messages.
Refer to the Instrument component block comments as this component block mirrors Instrument, except
for the noted fields.
Several multileg-oriented messages specify an Instrument Leg component block. An instrument can have zero or
more instrument legs. The fundamental business rule that applies to the multileg instrument is that the multileg
instrument is defined as the combination of instrument legs. The multileg instrument must be able to be traded
atomically – that all instrument legs are traded or none are traded.
The LegRatioQty[623] is used to define the quantity of the leg that makes up a single unit of the multleg
instrument. An option butterfly strategy is made up of three option legs.
600 LegSymbol N
601 LegSymbolSfx N
602 LegSecurityID N
603 LegSecurityIDSource N
Start of Component block, expanded in line < LegSecAltIDGrp >
604 NoLegSecurityAltID N
 605 LegSecurityAltID N
 606 LegSecurityAltIDSour N
ce
End of Component block, expanded in line < LegSecAltIDGrp >
607 LegProduct N
608 LegCFICode N
609 LegSecurityType N
764 LegSecuritySubType N
610 LegMaturityMonthYear N
611 LegMaturityDate N
1212 LegMaturityTime N
248 LegCouponPaymentDate N
249 LegIssueDate N
250 LegRepoCollateralSecurityTy N (Deprecated in FIX.4.4)
pe
251 LegRepurchaseTerm N (Deprecated in FIX.4.4)
252 LegRepurchaseRate N (Deprecated in FIX.4.4)
253 LegFactor N
257 LegCreditRating N
599 LegInstrRegistry N
596 LegCountryOfIssue N

597 LegStateOrProvinceOfIssue N
598 LegLocaleOfIssue N
254 LegRedemptionDate N (Deprecated in FIX.4.4)
612 LegStrikePrice N
942 LegStrikeCurrency N
613 LegOptAttribute N
614 LegContractMultiplier N
999 LegUnitOfMeasure N
1224 LegUnitOfMeasureQty N
1421 LegPriceUnitOfMeasure N
1422 LegPriceUnitOfMeasureQty N
1001 LegTimeUnit N Used to indicate a time unit for the contract (e.g., days,
1420 LegExerciseStyle N
615 LegCouponRate N
616 LegSecurityExchange N
617 LegIssuer N
618 EncodedLegIssuerLen N
619 EncodedLegIssuer N
620 LegSecurityDesc N
621 EncodedLegSecurityDescLen N
622 EncodedLegSecurityDesc N
623 LegRatioQty N Specific to the <InstrumentLeg> (not in <Instrument>)
624 LegSide N Specific to the <InstrumentLeg> (not in <Instrument>)
556 LegCurrency N Specific to the <InstrumentLeg> (not in <Instrument>)
740 LegPool N Identifies MBS / ABS pool
739 LegDatedDate N
955 LegContractSettlMonth N
956 LegInterestAccrualDate N
1358 LegPutOrCall N Used to express option right
1017 LegOptionRatio N LegOptionRatio is provided on covering leg to create a
delta neutral spread. In Listed Derivatives, the delta of
the leg is multiplied by LegOptionRatio and OrderQty to
determine the covering quantity.
566 LegPrice N Used to specify an anchor price for a leg as part of the
definition or creation of the strategy - not used for
execution price.
*** = Required status should match "Req'd" setting for <InstrumentLeg> component block in message definition


H UTH
details
Refer to FIXML element InstrmtLeg

InstrumentExtension component block

The InstrumentExtension component block identifies additional security attributes that are more commonly found
for Fixed Income securities.

668 DeliveryForm N Identifies the form of delivery.
869 PctAtRisk N Percent at risk due to lowest possible call.
Start of Component block, expanded in line < AttrbGrp >
870 NoInstrAttrib N
 871 InstrAttribType N
 872 InstrAttribValue N
End of Component block, expanded in line < AttrbGrp >
*** = Required status should match "Req'd" setting for <InstrumentExtension> component block in message
definition

H UTH
details
Refer to FIXML element InstrmtExtension

OrderQtyData component block

The OrderQtyData component block contains the fields commonly used for indicating the amount or quantity of
an order. Note that when this component block is marked as "required" in a message either one of these three
fields must be used to identify the amount: OrderQty, CashOrderQty or OrderPercent (in the case of CIV).

38 OrderQty N One of CashOrderQty, OrderQty, or (for CIV only)
OrderPercent is required. Note that unless otherwise
specified, only one of CashOrderQty, OrderQty, or
OrderPercent should be specified.
152 CashOrderQty N One of CashOrderQty, OrderQty, or (for CIV only)
OrderPercent is required. Note that unless otherwise
specified, only one of CashOrderQty, OrderQty, or
OrderPercent should be specified. Specifies the
approximate "monetary quantity" for the order. Broker
is responsible for converting and calculating OrderQty in
tradeable units (e.g. shares) for subsequent messages.
516 OrderPercent N For CIV - Optional. One of CashOrderQty, OrderQty or
(for CIV only) OrderPercent is required. Note that unless
otherwise specified, only one of CashOrderQty,
OrderQty, or OrderPercent should be specified.
468 RoundingDirection N For CIV - Optional
469 RoundingModulus N For CIV - Optional
*** = Required status should match "Req'd" setting for <OrderQtyData> component block in message definition

H UTH
details
Refer to FIXML element OrdQtyData

CommissionData component block

The CommissionDate component block is used to carry commission information such as the type of commission
and the rate.

12 Commission N
13 CommType N
479 CommCurrency N For CIV - Optional
497 FundRenewWaiv N For CIV - Optional
*** = Required status should match "Req'd" setting for <CommissionData> component block in message
definition

H UTH
details
Refer to FIXML Element CommData

Parties component block

The Parties component block is used to identify and convey information on the entities both central and peripheral
to the financial transaction represented by the FIX message containing the Parties Block. The Parties block allows
many different types of entites to be expressed through use of the PartyRole field and identifies the source of the
PartyID through the the PartyIDSource.
See “Volume 6 - APPENDIX 6-G - USE OF <PARTIES> COMPONENT BLOCK” for additional usage
information..

453 NoPartyIDs N Repeating group below should contain unique
combinations of PartyID, PartyIDSource, and PartyRole
 448 PartyID N Used to identify source of PartyID. Required if
PartyIDSource is specified. Required if NoPartyIDs > 0.
 447 PartyIDSource N Used to identify class source of PartyID value (e.g. BIC).
Required if PartyID is specified. Required if NoPartyIDs
> 0.
 452 PartyRole N Identifies the type of PartyID (e.g. Executing Broker).
Required if NoPartyIDs > 0.
 Start of Component block, expanded in line < PtysSubGrp >
 802 NoPartySubIDs N
  523 PartySubID N
  803 PartySubIDTy N
pe
 End of Component block, expanded in line < PtysSubGrp >
*** = Required status should match "Req'd" setting for <Parties> component block in message definition

H UTH
details
Refer to FIXML element Ptys

NestedParties component block

The NestedParties component block is identical to the Parties Block. It is used in other component blocks and
repeating groups when nesting will take place resulting in multiple occurrences of the Parties block within a single
FIX message.. Use of NestedParties under these conditions avoids multiple references to the Parties block within
the same message which is not allowed in FIX tag/value syntax.

539 NoNestedPartyIDs N Repeating group below should contain unique
combinations of NestedPartyID, NestedPartyIDSource,
and NestedPartyRole
 524 NestedPartyID N Used to identify source of NestedPartyID. Required if
NestedPartyIDSource is specified. Required if
NoNestedPartyIDs > 0.
 525 NestedPartyIDSource N Used to identify class source of NestedPartyID value
(e.g. BIC). Required if NestedPartyID is specified.
Required if NoNestedPartyIDs > 0.
 538 NestedPartyRole N Identifies the type of NestedPartyID (e.g. Executing
Broker). Required if NoNestedPartyIDs > 0.
 Start of Component block, expanded in line < NstdPtysSubGrp >
 804 NoNestedPartySubIDs N
  545 NestedPartySu N
bID
  805 NestedPartySu N
bIDType
 End of Component block, expanded in line < NstdPtysSubGrp >
*** = Required status should match "Req'd" setting for <NestedParties> component block in message definition

H UTH
details
Refer to FIXML element NstPtys

NestedParties2 (second instance of nesting) component block

The NestedParties2 component block is identical to the Parties Block. It is used in other component blocks and
FIX message.. Use of NestedParties2 under these conditions avoids multiple references to the Parties block within

756 NoNested2PartyIDs N Repeating group below should contain unique
combinations of Nested2PartyID,
Nested2PartyIDSource, and Nested2PartyRole
 757 Nested2PartyID N Used to identify source of Nested2PartyID. Required if
Nested2PartyIDSource is specified. Required if
NoNested2PartyIDs > 0.
 758 Nested2PartyIDSource N Used to identify class source of Nested2PartyID value
(e.g. BIC). Required if Nested2PartyID is specified.
Required if NoNested2PartyIDs > 0.
 759 Nested2PartyRole N Identifies the type of Nested2PartyID (e.g. Executing
Broker). Required if NoNested2PartyIDs > 0.
 Start of Component block, expanded in line < NstdPtys2SubGrp >
 806 NoNested2PartySubID N
s
  760 Nested2PartyS N
ubID
ubIDType
 End of Component block, expanded in line < NstdPtys2SubGrp >
*** = Required status should match "Req'd" setting for <NestedParties2> component block in message definition

H UTH
details
Refer to FIXML element NstPtys2

NestedParties3 (third instance of nesting) component block

FIX message.. Use of NestedParties3 under these conditions avoids multiple references to the Parties block within

s
ubID
ubIDType

H UTH
details

NestedParties4 (fouth instance of nesting) component block

FIX message. Use of NestedParties4 under these conditions avoids multiple references to the Parties block within

s
ubID
ubIDType

H UTH
details

SettlParties (settlement parties) component block

The SettlParties component block is used in a similar manner as Parties Block within the context of settlement
instruction messages to distinguish between parties involved in the settlement and parties who are expected to
execute the settlement process.

781 NoSettlPartyIDs N Repeating group below should contain unique
combinations of SettlPartyID, SettlPartyIDSource, and
SettlPartyRole
 782 SettlPartyID N Used to identify source of SettlPartyID. Required if
SettlPartyIDSource is specified. Required if
NoSettlPartyIDs > 0.
 783 SettlPartyIDSource N Used to identify class source of SettlPartyID value (e.g.
BIC). Required if SettlPartyID is specified. Required if
NoSettlPartyIDs > 0.
 784 SettlPartyRole N Identifies the type of SettlPartyID (e.g. Executing
Broker). Required if NoSettlPartyIDs > 0.
 Start of Component block, expanded in line < SettlPtysSubGrp >
 801 NoSettlPartySubIDs N
  785 SettlPartySubI N
D
  786 SettlPartySubI N
DType
 End of Component block, expanded in line < SettlPtysSubGrp >
*** = Required status should match "Req'd" setting for <SettlParties> component block in message definition

H UTH
details
Refer to FIXML element SettlPtys

SpreadOrBenchmarkCurveData component block

The SpreadOrBenchmarkCurveData component block is primarily used for Fixed Income to convey spread to a
benchmark security or curve.

218 Spread N For Fixed Income
220 BenchmarkCurveCurrency N
221 BenchmarkCurveName N
222 BenchmarkCurvePoint N
662 BenchmarkPrice N
663 BenchmarkPriceType N Must be present if BenchmarkPrice is used.
699 BenchmarkSecurityID N The identifier of the benchmark security, e.g. Treasury
against Corporate bond.
761 BenchmarkSecurityIDSource N Source of BenchmarkSecurityID. If not specified, then
ID Source is understood to be the same as that in the
Instrument block.
*** = Required status should match "Req'd" setting for <SpreadOrBenchmarkCurveData> component block in
message definition

H UTH
details
Refer to FIXML element SpreadOrBnchmkCrvData

LegBenchmarkCurveData component block

The LegBenchmarkCurveData is used to convey the benchmark information used for pricing in a multi-legged
Fixed Income security.

676 LegBenchmarkCurveCurrency N
677 LegBenchmarkCurveName N
678 LegBenchmarkCurvePoint N
679 LegBenchmarkPrice N
680 LegBenchmarkPriceType N
*** = Required status should match "Req'd" setting for <LegBenchmarkCurveData> component block in message
definition

H UTH
details
Refer to FIXML element LegBnchmkCrvData

Stipulations component block

The Stipulations component block is used in Fixed Income to provide additional information on a given security.
These additional information are usually not considered static data information.

232 NoStipulations N
 233 StipulationType N Required if NoStipulations >0
 234 StipulationValue N
*** = Required status should match "Req'd" setting for <Stipulations> component block in message definition

H UTH
details
Refer to FIXML element Stips

UnderlyingStipulations component block

The UnderlyingStipulations component block has the same usage as the Stipulations component block, but for an
underlying security.

887 NoUnderlyingStips N
 888 UnderlyingStipType N Required if NoUnderlyingStips >0
 889 UnderlyingStipValue N
*** = Required status should match "Req'd" setting for <UnderlyingStipulations> component block in message
definition

H UTH
details
Refer to FIXML element UndStips

LegStipulations component block

The LegStipulations component block has the same usage as the Stipulations component block, but for a leg
instrument in a multi-legged security.

683 NoLegStipulations N
 688 LegStipulationType N Required if NoLegStipulations >0
 689 LegStipulationValue N
*** = Required status should match "Req'd" setting for <LegStipulations> component block in message definition

H UTH
details
Refer to FIXML element LegStips

YieldData component block

The YieldData component block conveys yield information for a given Fixed Income security.

235 YieldType N
236 Yield N
701 YieldCalcDate N
696 YieldRedemptionDate N
697 YieldRedemptionPrice N
698 YieldRedemptionPriceType N
*** = Required status should match "Req'd" setting for <YieldData> component block in message definition

H UTH
details
Refer to FIXML element YldData

PositionQty component block

The PositionQty component block specifies the various types of position quantity in the position life-cycle
including start-of-day, intraday, trade, adjustments, and end-of-day position quantities. Quantities are expressed in
terms of long and short quantities.

702 NoPositions N
 703 PosType N Required if NoPositions > 1
 704 LongQty N
 705 ShortQty N
 706 PosQtyStatus N
 976 QuantityDate N Date associated with the quantity being reported
 component block N Optional repeating group - used to associate or distribute
<NestedParties> position to a specific party other than the party that
currently owns the position.
*** = Required status should match "Req'd" setting for <PositionQty> component block in message definition

H UTH
details
Refer to FIXML element PosQty

PositionAmountData component block

The PositionAmountData component block is used to report netted amounts associated with position quantities. In
the listed derivatives market the amount is generally expressing a type of futures variation or option premium. In
the equities market this may be the net pay or collect on a given position.

753 NoPosAmt N Number of Position Amount entries
 707 PosAmtType N
 708 PosAmt N
 1055 PositionCurrency N
*** = Required status should match "Req'd" setting for <PositionAmountData> component block in message
definition

H UTH
details
Refer to FIXML element PosAmtData

TrdRegTimestamps component block

The TrdRegTimestamps component block is used to express timestamps for an order or trade that are required by
regulatory agencies These timesteamps are used to identify the timeframes for when an order or trade is received
on the floor, received and executed by the broker, etc.

768 NoTrdRegTimestamps N
 769 TrdRegTimestamp N Required if NoTrdRegTimestamps > 1
 770 TrdRegTimestampTyp N Required if NoTrdRegTimestamps > 1
e
 771 TrdRegTimestampOri N
gin
 1033 DeskType N Type of Trading desk
 1034 DeskTypeSource N
 1035 DeskOrderHandlingIns N
t
*** = Required status should match "Req'd" setting for <TrdRegTimestamps> component block in message
definition

H UTH
details
Refer to FIXML element TrdRegTmstampsGrp

SettlInstructionsData component block

The SettlInstructionsData component block is used to convey key information regarding standing settlement and
delivery instructions. It also provides a reference to standing settlement details regarding the source, delivery
instructions, and settlement parties
It is important to understand that Settlement Instructions convey standing (reference) data only – and is not used
for settlement transactions which are currently outside the scope of the FIX Protocol..
See “Volume 6 - APPENDIX 6-H - USE OF <SETTLINSTRUCTIONS> COMPONENT BLOCK” for
additional usage information.

172 SettlDeliveryType N Required if AllocSettlInstType = 1 or 2
169 StandInstDbType N Required if AllocSettlInstType = 3 (should not be
populated otherwise)
170 StandInstDbName N Required if AllocSettlInstType = 3 (should not be
171 StandInstDbID N Identifier used within the StandInstDbType
Required if AllocSettlInstType = 3 (should not be
Start of Component block, expanded in line < DlvyInstGrp >
85 NoDlvyInst N
 165 SettlInstSource N
 787 DlvyInstType N
 component block N
<SettlParties>
End of Component block, expanded in line < DlvyInstGrp >
*** = Required status should match "Req'd" setting for <SettlInstructionsData> component block in message
definition

H UTH
details
Refer to the FIXML element SettlInstrctnsData

PegInstructions component block

The Peg Instructions component block is used to tie the price of a security to a market event such as opening
price, mid-price, best price. The Peg Instructions block may also be used to tie the price to the behavior of a
related security.

211 PegOffsetValue N Amount (signed) added to the peg for a pegged order in
the context of the PegOffsetType
1094 PegPriceType N Defines the type of peg.
835 PegMoveType N Describes whether peg is static/fixed or floats
836 PegOffsetType N Type of Peg Offset (e.g. price offset, tick offset etc)
837 PegLimitType N Specifies nature of resulting pegged price (e.g. or better
limit, strict limit etc)
838 PegRoundDirection N If the calculated peg price is not a valid tick price,
specifies how to round the price (e.g. be more or less
aggressive)
840 PegScope N The scope of the "related to" price of the peg (e.g. local,
global etc)
1096 PegSecurityIDSource N Required if PegSecurityID is specified.
1097 PegSecurityID N Requires PegSecurityIDSource if specified.
1098 PegSymbol N
1099 PegSecurityDesc N
*** = Required status should match "Req'd" setting for <PegInstructions> component block in message definition
Note that Pegged orders are specified by the use of OrdType (to denote that the order is a pegged order) and
ExecInst (to specify what price the order is pegged to).

H UTH
details
Refer to the FIXML element PegInstrctns

DiscretionInstructions component block

The presence of DiscretionInstructions component block on an order indicates that the trader wishes to display one
price but will accept trades at another price.

388 DiscretionInst N What the discretionary price is related to (e.g. primary
price, display price etc)
389 DiscretionOffsetValue N Amount (signed) added to the "related to" price specified
via DiscretionInst, in the context of
DiscretionOffsetType
841 DiscretionMoveType N Describes whether discretion price is static/fixed or
floats
842 DiscretionOffsetType N Type of Discretion Offset (e.g. price offset, tick offset
etc)
843 DiscretionLimitType N Specifies the nature of the resulting discretion price (e.g.
or better limit, strict limit etc)
844 DiscretionRoundDirection N If the calculated discretion price is not a valid tick price,
specifies how to round the price (e.g. to be more or less
aggressive)
846 DiscretionScope N The scope of "related to" price of the discretion (e.g.
local, global etc)
*** = Required status should match "Req'd" setting for <DiscretionInstructions> component block in message
definition

H UTH
details
Refer to the FIXML element DsctnInstrctns

FinancingDetails component block

Component block is optionally used only for financing deals to identify the legal agreement under which the deal
was made and other unique characteristics of the transaction. The AgreementDesc field refers to base standard
documents such as MRA 1996 Repurchase Agreement, GMRA 2000 Bills Transaction (U.K.), MSLA 1993
Securities Loan – Amended 1998, for example.

913 AgreementDesc N The full name of the base standard agreement, annexes
and amendments in place between the principals and
applicable to this deal
914 AgreementID N A common reference to the applicable standing
agreement between the principals
915 AgreementDate N A reference to the date the underlying agreement was
executed.
918 AgreementCurrency N Currency of the underlying agreement.
788 TerminationType N For Repos the timing or method for terminating the
agreement.
916 StartDate N Settlement date of the beginning of the deal
917 EndDate N Repayment / repurchase date
919 DeliveryType N Delivery or custody arrangement for the underlying
securities
898 MarginRatio N Percentage of cash value that underlying security
collateral must meet.
*** = Required status should match "Req'd" setting for <FinancingDetails> component block in message
definition

H UTH
details
Refer to the FIXML element FinancingDetails

ExpirationQty component block

The ExpirationQty component block identified the expiration quantities and type of expiration.

981 NoExpiration N
 982 ExpirationQtyType N Required if NoExpiration > 1
 983 ExpQty N
*** = Required status should match "Req'd" setting for <ExpirationQty> component block in message definition

H UTH
details
Refer to FIXML element ExpirationQty

SideTrdRegTS component block

The SideTrdRegTS component block is used to convey regulatory timestamps associated with one side of a multi-
sided trade event.

1016 NoSideTrdRegTS N
 1012 SideTrdRegTimestam N
p
pType
pSrc
*** = Required status should match "Req'd" setting for <SideTrdRegTS> component block in message definition

H UTH
details
Refer to FIXML element SideTrdTegTS

InstrumentParties component block

The use of this component block is restricted to instrument definition only and is not permitted to contain
transactional information. Only a specified subset of party roles will be supported within the InstrumentParty
block.
Possible uses of this block include identifying Listing Source information; Clearing Org information; Parent and
Capital Structure information for F/I and derivative instruments.

1018 NoInstrumentParties N Repeating group below should contain unique
combinations of InstrumentPartyID,
InstrumentPartyIDSource, and InstrumentPartyRole
 1019 InstrumentPartyID N Used to identify party id related to instrument
 1050 InstrumentPartyIDSou N Used to identify source of instrument party id
rce
 1051 InstrumentPartyRole N Used to identify the role of instrument party id
 Start of Component block, expanded in line < InstrumentPtysSubGrp >
 1052 NoInstrumentPartySub N
IDs
  1053 InstrumentPart N
ySubID
  1054 InstrumentPart N
ySubIDType
 End of Component block, expanded in line < InstrumentPtysSubGrp >
*** = Required status should match "Req'd" setting for <InstrumentParties> component block in message
definition

H UTH
details
Refer to FIXML element InstrumentParties

UnderlyingAmount component block

The UnderlyingAmount component block is used to supply the underlying amounts, dates, settlement status and
method for derivative positions.

984 NoUnderlyingAmounts N
 985 UnderlyingPayAmoun N Amount to pay in order to receive the underlying
t instrument.
 986 UnderlyingCollectAm N Amount to collect in order to deliver the underlying
ount instrument.
 987 UnderlyingSettlement N Date the underlying instrument will settle. Used for
Date derivatives that deliver into more than one underlying
instrument. Settlement dates can vary across underlying
instruments.
 988 UnderlyingSettlement N Settlement status of the underlying instrument. Used for
Status derivatives that deliver into more than one underlying
instrument. Settlement can be delayed for an underlying
instrument.
*** = Required status should match "Req'd" setting for <UnderlyingAmount> component block in message
definition

H UTH
details
Refer to FIXML element UnderlyingAmount Grp

DisplayInstruction component block

The DisplayInstruction component block is used to convey instructions on how a reserved order is to be handled
in terms of when and how much of the order quantity is to be displayed to the market.

1138 DisplayQty N
1082 SecondaryDisplayQty N
1083 DisplayWhen N
1084 DisplayMethod N
1085 DisplayLowQty N Required when DisplayMethod = 3
1086 DisplayHighQty N Required when DisplayMethod = 3
1087 DisplayMinIncr N Can be used to specify larger increments than the
standard increment provided by the market. Optionally
used when DisplayMethod = 3
1088 RefreshQty N Required when DisplayMethod = 2
*** = Required status should match "Req'd" setting for <DisplayInstruction> component block in message
definition

H UTH
details
Refer to FIXML element DisplayInstruction Grp

TriggeringInstruction component block

The TriggeringInstruction component block specifies the conditions under which an order will be triggered by
related market events as well as the behavior of the order in the market once it is triggered. .

1100 TriggerType N Required if any other Triggering tags are specified.
1101 TriggerAction N
1102 TriggerPrice N Only relevant and required for TriggerAction = 1
1103 TriggerSymbol N Only relevant and required for TriggerAction = 1
1104 TriggerSecurityID N Requires TriggerSecurityIDSource if specified. Only
relevant and required for TriggerAction = 1
1105 TriggerSecurityIDSource N Requires TriggerSecurityIDSource if specified. Only
relevant and required for TriggerAction = 1
1106 TriggerSecurityDesc N
1107 TriggerPriceType N Only relevant for TriggerAction = 1
1108 TriggerPriceTypeScope N Only relevant for TriggerAction = 1
1109 TriggerPriceDirection N Only relevant for TriggerAction = 1
1110 TriggerNewPrice N Should be specified if the order changes Price.
1111 TriggerOrderType N Should be specified if the order changes type.
1112 TriggerNewQty N Required if the order should change quantity
1113 TriggerTradingSessionID N Only relevant and required for TriggerType = 2.
1114 TriggerTradingSessionSubID N Requires TriggerTradingSessionID if specified. Relevant
for TriggerType = 2 only.
*** = Required status should match "Req'd" setting for <TriggeringInstruction> component block in message
definition

H UTH
details
Refer to FIXML element TriggeringInstruction Grp

RootParties component block

The RootParties component block is a version of the Parties component block used to provide root information
regarding the owning and entering parties of a transaction.

1116 NoRootPartyIDs N Repeating group below should contain unique
combinations of RootPartyID, RootPartyIDSource, and
RootPartyRole
 1117 RootPartyID N Used to identify source of RootPartyID. Required if
RootPartyIDSource is specified. Required if
NoRootPartyIDs > 0.
 1118 RootPartyIDSource N Used to identify class source of RootPartyID value (e.g.
BIC). Required if RootPartyID is specified. Required if
NoRootPartyIDs > 0.
 1119 RootPartyRole N Identifies the type of RootPartyID (e.g. Executing
Broker). Required if NoRootPartyIDs > 0.
 Start of Component block, expanded in line < RootSubParties >
 1120 NoRootPartySubIDs N Repeating group of RootParty sub-identifiers.
  1121 RootPartySubI N Sub-identifier (e.g. Clearing Acct for PartyID=Clearing
D Firm) if applicable. Required if
NoRootPartySubIDs > 0.
  1122 RootPartySubI N Type of Sub-identifier. Required if NoRootPartySubIDs
DType > 0.
 End of Component block, expanded in line < RootSubParties >
*** = Required status should match "Req'd" setting for <RootParties> component block in message definition

H UTH
details
Refer to FIXML element RootParties Grp

UndlyInstrumentParties component block

The use of this component block is restricted to instrument definition only and is not permitted to contain
transactional information. Only a specified subset of party roles will be supported within the InstrumentParty
block.
Possible uses of this block include identifying Listing Source information; Clearing Org information; Parent and
Capital Structure information for F/Iixed Income and derivative instruments.

1058 NoUndlyInstrumentParties N Repeating group below should contain unique
combinations of InstrumentPartyID,
InstrumentPartyIDSource, and InstrumentPartyRole
 1059 UndlyInstrumentPartyI N Used to identify party id related to instrument
D
 1060 UndlyInstrumentPartyI N Used to identify source of instrument party id
DSource
 1061 UndlyInstrumentParty N Used to identify the role of instrument party id
Role
 Start of Component block, expanded in line < UndlyInstrumentPtysSubGrp >
 1062 NoUndlyInstrumentPa N
rtySubIDs
  1063 UndlyInstrume N
ntPartySubID
  1064 UndlyInstrume N
ntPartySubID
Type
 End of Component block, expanded in line < UndlyInstrumentPtysSubGrp >
*** = Required status should match "Req'd" setting for <UndlyInstrumentParties> component block in message
definition

H UTH
details
Refer to FIXML element UndlyInstrumentParties Grp

SecurityTradingRules component block

Ths SecurityTradingRules component block is used as part of security definition to specify the specific security's
standard trading parameters such as trading session eligibility and other attributes of the security.

Start of Component block, expanded in line < BaseTradingRules >
Start of Component block, expanded in line < TickRules >
1205 NoTickRules N Number of tick rules. This block specifies the rules for
determining how a security ticks, i.e. the price
increments at which it can be quoted and traded,
depending on the current price of the security.
 1206 StartTickPriceRange N Starting price range for specified tick increment
 1207 EndTickPriceRange N Ending price range for the specified tick increment
 1208 TickIncrement N Tick increment for stated price range. Specifies the valid
price increments at which a security can be quoted and
traded
 1209 TickRuleType N Specifies the type of tick rule which is being described
End of Component block, expanded in line < TickRules >
Start of Component block, expanded in line < LotTypeRules >
1234 NoLotTypeRules N Number of Lot Types
 1093 LotType N Defines the lot type assigned to the order. Use as an
alternate to RoundLot(561). To be used with
MinLotSize(1231). LotType + MinLotSize ( max is next
level minus 1)
 1231 MinLotSize N Minimum lot size allowed based on lot type specified in
LotType(1093)
End of Component block, expanded in line < LotTypeRules >
Start of Component block, expanded in line < PriceLimits >
1306 PriceLimitType N Describes the how the price limits are expressed
1148 LowLimitPrice N Allowable low limit price for the trading day. A key
parameter in validating order price. Used as the lower
band for validating order prices. Orders submitted with
prices below the lower limit will be rejected
1149 HighLimitPrice N Allowable high limit price for the trading day. A key
parameter in validating order price. Used as the upper
band for validating order prices. Orders submitted with
prices above the upper limit will be rejected
1150 TradingReferencePrice N Reference price for the current trading price range
usually representing the mid price between the
HighLimitPrice and LowLimitPrice. The value may be
the settlement price or closing price of the prior trading
day.
End of Component block, expanded in line < PriceLimits >
827 ExpirationCycle N

562 MinTradeVol N The minimum order quantity that can be submitted for
an order.
1140 MaxTradeVol N The maximum order quantity that can be submitted for a
security. For listed derivatives this indicates the
minimum quantity necessary for an order or trade to
qualify as a block trade
1143 MaxPriceVariation N The maximum price variation of an execution from one
event to the next for a given security. Expressed in
absolute price terms.
1144 ImpliedMarketIndicator N
1245 TradingCurrency N Used when the trading currency can differ from the price
currency
561 RoundLot N Trading lot size of security
1377 MultilegModel N Used for multileg security only. Defines whether the
security is pre-defined or user-defined. Not that value =
2 (User-defined, Non-Securitized, Multileg) does not
apply for Securities.
1378 MultilegPriceMethod N Used for multileg security only. Defines the method used
when applying the multileg price to the legs.
423 PriceType N Defines the default Price Type used for trading.
End of Component block, expanded in line < BaseTradingRules >
Start of Component block, expanded in line < TradingSessionRulesGrp >
1309 NoTradingSessionRules N Allows trading rules to be expressed by trading session
 336 TradingSessionID N Identifier for the trading session
Must be provided if NoTradingSessions > 0
Set to [N/A] if values are not specific to trading session
 625 TradingSessionSubID N Identifier for the trading session
Set to [N/A] if values are not specific to trading session
sub id
 Start of Component block, expanded in line < TradingSessionRules >
 Start of Component block, expanded in line < OrdTypeRules >
1237 NoOrdTypeRules N Number of order types
 40 OrdType N Indicates order types that are valid for the specified
market segment.
 End of Component block, expanded in line < OrdTypeRules >
 Start of Component block, expanded in line < TimeInForceRules >
1239 NoTimeInForceRules N Number of time in force techniques
 59 TimeInForce N Indicates time in force techniques that are valid for the
specified market segment
 End of Component block, expanded in line < TimeInForceRules >
 Start of Component block, expanded in line < ExecInstRules >
1232 NoExecInstRules N Number of execution instructions

 1308 ExecInstValue N Indicates execution instructions that are valid for the
specified market segment
 End of Component block, expanded in line < ExecInstRules >
 Start of Component block, expanded in line < MatchRules >
1235 NoMatchRules N Number of match rules
 1142 MatchAlgorithm N The type of algorithm used to match orders in a specific
security on an electronic trading platform.
Possible values are FIFO, Allocation, Pro-rata, Lead
Market Maker, Currency Calendar
 574 MatchType N The point in the matching process at which this trade
was matched.
 End of Component block, expanded in line < MatchRules >
 Start of Component block, expanded in line < MarketDataFeedTypes >
1141 NoMDFeedTypes N The number of feed types and corresponding book depths
associated with a security
 1022 MDFeedType N Describes a class of service for a given data feed
 264 MarketDepth N The depth of book associated with a particular feed type
 1021 MDBookType N Describes the type of book for which the feed is
intended. Can be used when multiple feeds are provided
over the same connection
 End of Component block, expanded in line < MarketDataFeedTypes >
 End of Component block, expanded in line < TradingSessionRules >
End of Component block, expanded in line < TradingSessionRulesGrp >
Start of Component block, expanded in line < NestedInstrumentAttribute >
1312 NoNestedInstrAttrib N
 1210 NestedInstrAttribType N Code to represent the type of instrument attribute
 1211 NestedInstrAttribValu N Attribute value appropriate to the NestedInstrAttribType
e field
End of Component block, expanded in line < NestedInstrumentAttribute >

H UTH
details
Refer to FIXML element SecurityTradingRules

ApplicationSequenceControl component block

The ApplicationSequenceControl is used for application sequencing and recovery. Consisting of ApplSeqNum
(1181), ApplID (1180), ApplLastSeqNum (1350), and ApplResendFlag (1352), FIX application messages that
carries this component block will be able to use application level sequencing. ApplID, ApplSeqNum and
ApplLastSeqNum fields identify the application id, application sequence number and the previous application
sequence number (in case of intentional gaps) on each application message that carries this block.
The ApplResendFlag (1352) is used to indicate that messages are being retransmitted as a result of an Application
Message Request.
See Application Sequencing Message section for further details on usage and restrictions.

1180 ApplID N Identifies the application with which a message is
associated. Used only if application sequencing is in
effect.
1181 ApplSeqNum N Application sequence number assigned to the message by
the application generating the message. Used only if
application sequencing is in effect. Conditionally
required if ApplID has been specified.
1350 ApplLastSeqNum N The previous sequence number in the application
sequence stream. Permits an application to publish
messages with sequence gaps where it cannot be
avoided. Used only if application sequencing is in effect.
Conditionally required if ApplID has been specified
1352 ApplResendFlag N Used to indicate that a message is being sent in response
to an Application Message Request. Used only if
application sequencing is in effect. It is possible for both
ApplResendFlag and PossDupFlag to be set on the same
message if the Sender's cache size is greater than zero
and the message is being resent due to a session level
resend request.

H UTH
details
Refer to FIXML element ApplSeqGrp

SecurityXML component block

The SecurityXML component is used for carrying security description or definition in an XML format. See
"Specifying an FpML product specification from within the FIX Instrument Block" for more information on using
this component block with FpML as a guideline.

1184 SecurityXMLLen N Must be set if SecurityXML field is specified and must
1185 SecurityXML N XML payload or content describing the Security
information.
1186 SecurityXMLSchema N XML Schema used to validate the XML used to describe
the Security.

H UTH
details
Refer to FIXML element SecXML

COMMON APPLICATION MESSAGES (Apply to pre-trade, trade, and

post-trade)
Business Message Reject

The Business Message Reject message can reject an application-level message which fulfills session-level
rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body
length is incorrect), a session-level Reject message should be issued.
See the session-level Reject message
It should *NOT* be used in the following situations:
Situation Appropriate Response
Session-level problem meeting the criteria of Use the session-level Reject message (MsgType=3)
the session-level Reject message
In response to: Use the Quote Request Reject message
• Quote Request
In response to: Use the Quote Status Report message
• Quote
• Quote Cancel
• Quote Status Request
• Quote Response
In response to: Use the Mass Quote Acknowledgment message
• Mass Quote
In response to: Use the Market Data Request Reject message
• Market Data Request
In response to: Use the Security Definition message
• Security Definition Request
In response to: Use the SecurityTypes message
• Security Type Request
In response to: Use the Security List message
• Security List Request
In response to: Use the Derivative Security List message
• Derivative Security List Request
In response to: Use the Security Status message
• Security Status Request
In response to: Use the Trading Session Status message
• Trading Session Status Request
In response to: Use the Trading Session List message
• Trading Session List Requeset

In response to
Use the Execution Report message
• New Order - Single
• Order Status Request
• Order Mass Status Request
• New Order – Cross
• New Order – Multileg
• New Order – List
• List Execute
In response to: Use the Order Cancel Reject message
• Order Cancel Request
• Order Cancel/Replace Request
• Cross Order Cancel Request
• Cross Order Cancel/Replace Request
• Mulileg Order Cancel/Replace Request
• List Cancel Request
In response to: Use the Don’t Know Trade (DK) message or the
Execution Report Acknowledgement message
• Execution Report
In response to: Use the Order Mass Cancel Report message
• Order Mass Cancel Request
In response to: Use the Order Mass Action Report message
• Order Mass Action Request
In response to: Use the List Status message
• List Status Request
In response to: Use the Bid Response message
• Bid Request
In response to: Use the Allocation Instruction Ack message
• Allocation Instruction
In response to: Use the Allocation Report Ack message
• Allocation Report
In response to: Use the Confirmation Ack message
• Confirmation
In response to: Use the Registration Instructions Response
message
• Registration Instructions
In response to: Use the Trade Capture Report message
• Trade Capture Report Request
In response to: Use the Confirmation message
• Confirmation Request

In response to: Use the Settlement Instructions message

• Settlement Instruction Request
In response to: Use the Position Maintenance Report message
• Position Maintenance Request
In response to: Use the Request for Positions Ack message
• Request for Positions
In response to: Use the Collateral Assignment message
• Collateral Request
In response to: Use the Collateral Response message
• Collateral Assignment
In response to: Use the Collateral Inquiry Ack message
• Collateral Inquiry
Note the only exceptions to this rule are:
U
1. in the event a business message is received, fulfills session-level rules, however, the message
U
cannot be communicated to the business-level processing system. In this situation a Business Message
U
Reject with BusinessRejectReason = “Application not available at this time” can be issued if the system
is unable to send the specific “reject” message listed above due to this condition.
2. in the event a valid business message is received, fulfills session-level rules, however, the
U
message type is not supported by the receipient. In this situation a Business Message Reject with
U
BusinessRejectReason = “Unsupported Message Type” can be issued if the system is unable to send the
specific “reject” message listed above because the receiving system cannot generate the related “reject”
message.
3. In the event a business message is received, fulfills session-level rules, but lacks a field
U
conditionally required by the FIX specification. In this situation a Business Message Reject with
U
BusinessRejectReason = “Conditionally Required Field Missing” can be issued if the system is unable to
send the specific “reject” message listed above. One example of this would be a stop order missing
StopPx. However, a Business Message Reject message MUST NOT be used to enforce proprietary rules
U U
more restrictive than those explicit in the FIX specification, such as a broker requiring an order to contain
an Account, which the FIX specification considers an optional field.
Messages which can be referenced via the Business Message Reject message are:
(the “ID” field BusinessRejectRefID refers to noted in [ ])

• Indication of Interest (IOI) [IOIid]
• Advertisement [AdvId]
• News [Headline]
• Email [EmailThreadID]
• Market Data-Snapshot/Full Refresh [MDReqID]
• Market Data-Incremental Refresh [MDReqID]
• Market Data Request Reject [MDReqID]
• Market Definition [MarketReportID]
• Market Definition Request [MarketReqID]
• Market Definition Update Report [MarketReportID]
• Security Definition [SecurityResponseID or SecurityReportID]
• Security Definition Update Report [SecurityResponseID or SecurityReportID]
• Security Status [SecurityStatusReqID]
• Security Types [SecurityResponseID]

• Security List [SecurityResponseID]

• Security List Update Report [SecurityResponseID or SecurityReportID]
• Derivative Security List [SecurityResponseID]
• Derivative Security List Update Report [SecurityRespondID]
• Trading Session Status [TradSesReqID]
• Trading Session List [TradSesReqID]
• Trading Session List Update Report [TradSesReqID]
• Mass Quote Acknowledgement [QuoteReqID or QuoteID]
• Quote Request Reject [QuoteReqID]
• RFQ Request [RFQReqID]
• Quote Status Report [QuoteStatusReqID or QuoteRespID or QuoteID or QuoteMsgID]
• Quote Status Report [QuoteID]
• Order Cancel Reject [ClOrdID]
• List Status [ListID]
• List Strike Price [ListID]
• Bid Response [BidID]
• Order Mass Cancel Report [OrderID]
• Order Mass Action Report [MassActionReportID]
• Order Mass Status Request [MassStatusReqID] [tbd]
• Don’t Know Trade (DK) – may respond with Order Cancel Reject if attempting to cancel
order [ExecID]
• Execution Report Acknowledgement [ExecID]
• Allocation Instruction ACK [AllocID]
• Allocation Report ACK [AllocID]
• Allocation Alert [AllocID]
• Confirmation ACK [ConfirmID]
• Trade Capture Report [TradeReportID]
• Trade Capture Report Request Ack [TradeRequestID]
• Trade Capture Report Ack [TradeReportID]
• Position Maintenance Report [PosMaintRptID]
• Request for Positions Ack [PosMaintRptID]
• Adjusted Position Report [PosMaintRptID]
• Positions Report [PosMaintRptID]
• Assignment Report [AsgnRptID]
• Contrary Intention Report [ContIntRptID]
• Settlement Instructions [SettInstMsgID]
• Settlement Obligation Report [SettlObligMsgID]
• Registration Instructions Response [RegistID]
• Collateral Response [CollRespID]
• Collateral Inquiry Ack [CollInquiryID]
• Collateral Report [CollRptID]
Scenarios for Business Message Reject:

BusinessRejectReason
0 = Other
1 = Unkown ID
2 = Unknown Security
3 = Unsupported Message Type (receive a valid, but unsupported
MsgType)
4 = Application not available
5 = Conditionally Required Field Missing
6 = Not Authorised

7 = DeliverTo firm not available at this time

18 = Invalid price increment
Whenever possible, it is strongly recommended that the cause of the failure be described in the Text
field (e.g. “UNKNOWN SYBMOL: XYZ”).
The business message reject format is as follows:

Business Message Reject
StandardHeader Y MsgType = j (lowercase)
45 RefSeqNum N MsgSeqNum of rejected message
372 RefMsgType Y The MsgType of the FIX message being referenced.
1130 RefApplVerID N Recommended when rejecting an application message
that does not explicitly provide ApplVerID ( 1128) on
the message being rejected. In this case the value from
the DefaultApplVerID(1137) or the default value
specified in the NoMsgTypes repeating group on the
logon message should be provided.
1406 RefApplExtID N Recommended when rejecting an application message
that does not explicitly provide ApplExtID(1156) on the
rejected message. In this case the value from the
DefaultApplExtID(1407) or the default value specified in
the NoMsgTypes repeating group on the logon message
should be provided.
1131 RefCstmApplVerID N Recommended when rejecting an application message
that does not explicitly provide CstmApplVerID(1129)
on the message being rejected. In this case the value
from the DefaultCstmApplVerID(1408) or the default
value specified in the NoMsgTypes repeating group on
the logon message should be provided.
379 BusinessRejectRefID N The value of the business-level "ID" field on the message
being referenced. Required unless the corresponding ID
field (see list above) was not specified.
380 BusinessRejectReason Y Code to identify reason for a Business Message Reject
message.
58 Text N Where possible, message to explain reason for rejection
354 EncodedTextLen N Must be set if EncodedText field is specified and must
355 EncodedText N Encoded (non-ASCII characters) representation of the
Text field in the encoded format specified via the
StandardTrailer Y
FIXML Definition for this Message– see TUhttp://www.fixprotocol.org for details

H UTH

Refer to the FIXML element BizMsgRej

Network Status Messages

It is envisaged these messages will be used in two scenarios:
Scenario A
Allow one counterparty using a “hub and spoke” FIX network to know whether another counterparty is currently
connected to the hub (i.e. whether the counterparty's session to the hub is up or not).
Scenario B
Allow a counterparty connecting to a global brokerage to know which regions within that brokerage are currently
available as order routing destinations.
Network (Counterparty System) Status Request Message

This message is send either immediately after logging on to inform a network (counterparty system) of the type of
updates required or to at any other time in the FIX conversation to change the nature of the types of status updates
required. It can also be used with a NetworkRequestType of Snapshot to request a one-off report of the status of a
network (or counterparty) system. Finally this message can also be used to cancel a request to receive updates into
the status of the counterparties on a network by sending a NetworkRequestStatusMessage with a
NetworkRequestType of StopSubscribing.
Network (Counterparty System) Status Request

StandardHeader Y MsgType = "BC"
935 NetworkRequestType Y
933 NetworkRequestID Y
Start of Component block, expanded in line < CompIDReqGrp >
936 NoCompIDs N Used to restrict updates/request to a list of specific
CompID/SubID/LocationID/DeskID combinations.
If not present request applies to all applicable available

counterparties. EG Unless one sell side broker was a
customer of another you would not expect to see
information about other brokers, similarly one fund
manager etc.
 930 RefCompID N Used to restrict updates/request to specific CompID
 931 RefSubID N Used to restrict updates/request to specific SubID
 283 LocationID N Used to restrict updates/request to specific LocationID
 284 DeskID N Used to restrict updates/request to specific DeskID
End of Component block, expanded in line < CompIDReqGrp >
StandardTrailer Y

H UTH
Refer to the FIXML element NtwkSysStatReq

Network (Counterparty System) Status Response Message

This message is sent in response to a Network (Counterparty System) Status Request Message.
If the network response payload is larger than the maximum permitted message size for that FIX conversation the
response would be several Network Status Response Messages the first with a status of full and then as many
messages, as updates to the first message, adding information as required.
Network (Counterparty System) Status Response

StandardHeader Y MsgType = "BD"
937 NetworkStatusResponseType Y
933 NetworkRequestID N
932 NetworkResponseID Y
934 LastNetworkResponseID N Required when NetworkStatusResponseType=2
Start of Component block, expanded in line < CompIDStatGrp >
936 NoCompIDs Y Specifies the number of repeating CompId’s
 930 RefCompID Y CompID that status is being report for. Required if
NoCompIDs > 0,
 931 RefSubID N SubID that status is being report for.
 283 LocationID N LocationID that status is being report for.
 284 DeskID N DeskID that status is being report for.
 928 StatusValue Y
 929 StatusText N Additional Information, i.e. "National Holiday"
End of Component block, expanded in line < CompIDStatGrp >
StandardTrailer Y

H UTH
Refer to the FIXML element NtwkSysStatRsp

User Administration Messages

These messages are provided in FIX to allow the passing of individual user information between two
counterparties. The messages allow for the following function
1 – Individual User Logon

2 – Individual User Status Enquiries
3 – Individual User Logout
4 – Individual User password change
NOTE: While it is not encouraged to transmit passwords in a FIX conversation unless you can guarantee
the end to end security of both the FIX conversation and any intermediate routing hubs that are involved in
the routing.
User Request Message

This message is used to initiate a user action, logon, logout or password change. It can also be used to request a
report on a user’s status.
User Request
StandardHeader Y MsgType = "BE"
923 UserRequestID Y
924 UserRequestType Y
553 Username Y
554 Password N
925 NewPassword N
1400 EncryptedPasswordMethod N
1401 EncryptedPasswordLen N
1402 EncryptedPassword N
1403 EncryptedNewPasswordLen N
1404 EncryptedNewPassword N
95 RawDataLength N
96 RawData N Can be used to hand structures etc to other API’s etc
StandardTrailer Y

H UTH
Refer to the FIXML element UserReq

User Response Message
This message is used to respond to a user request message, it reports the status of the user after the completion of
any action requested in the user request message.
User Response
StandardHeader Y MsgType = "BF"
923 UserRequestID Y
553 Username Y
926 UserStatus N
927 UserStatusText N Reason a request was not carried out
StandardTrailer Y

H UTH
Refer to the FIXML element UserRsp
User Notification
The User Notification message is used to notify one or more users of an event or information from the sender of
the message. This message is usually sent unsolicited from a marketplace (e.g. Exchange, ECN) to a market
participant.
User Notification
StandardHeader Y MsgType = CB
Start of Component block, expanded in line < UsernameGrp >
809 NoUsernames N Number of usernames
 553 Username N Recipient of the notification
End of Component block, expanded in line < UsernameGrp >
926 UserStatus Y Reason for notification - when possible provide an
explanation.
58 Text N Explanation for user notification.
354 EncodedTextLen N Must be set if EncodedText field is specified and must
355 EncodedText N Encoded (non-ASCII characters) representation of the
Text field in the encoded format specified via the
StandardTrailer Y


H UTH
Refer to the FIXML element UserNotification

Application Sequencing Messages

Introduction
FIX has a growing need to support application-level sequencing of messages in order to segregate the transmission
of data over a session. The ability to identify and retransmit a subset of data by application and application
sequence number range is an important feature in support of secondary distribution of data (see definition below).
The current retransmission capabilities of the FIX session require that all messages on that session between the
specified starting and ending message sequence number are resent rather than just those that have been produced
by a specific upstream business process or application. This can pose capacity and performance problems for
systems that need only a small set of messages related to an application. Secondary data distribution consists of a
diverse set of data sourced from different applications; drop copy data, credit limit information, metrics, etc. It is
not recommended that application sequencing is used over a conventional order routing or a transaction flow
oriented connection. Standard FIX session capabilities should be used in this case.
Application Sequencing greatly enhances the usefulness of FIX messages that are transmissted apart from the FIX
session layer by making it possible for the receiver to detect and request missed messages on a specified feed.
Market Data sent over a broadcast or multicast transport is often in need of sequencing and retransmission.
Application Sequencing provides a means by which to sequence each message that is part of a broadcast stream
such that the receiver can verify ordered delivery of the data. Application Resends can then be requested when
gaps are detected in the application sequence.
Background
The purpose of Application-level Sequencing is to allow messages being sent over a FIX session to be
distinguished by the sending application that is upstream from the FIX engine. In the case that a session-level
resend would result in an unnecessarily large number of messages being resent, Application Sequencing and
Recovery makes provision for the desired messages - and only the desired messages - to be seamlessly requested
and resent while retaining the standard behaviors of the session protocol. It also provides the receiver with the
flexibility to put off recovery of application level messages until a slow period or after the market has closed.
Extends control over resent data
The primary intent of Application Sequencing and Recovery is to allow receivers to avoid a retransmission of
large quantities of unusable data which may result in receivers needing to glean the retransmission for the data
they actually need - such as critical drop copy information that is used in risk management applications.
Application Sequencing allows the channeling of different types of data across a single FIX session. For example,
Application Sequencing can allow drop copy data to be sent over the same FIX session with order flow data.
While this may not be practical from a trading standpoint the flexibility that it introduces is compelling. This
allows data which has a higher importance and priority to be identified by application ID thereby allowing
requests for retransmission to be issued promptly and precisely.
Support for secondary data distribution
Another goal of the proposal is to provide support for “secondary data” distribution. Application Sequencing
extends the capabilities of FIX such that secondary data can be distributed using a single channel. This data may
be less time critical with less demanding latency requirements than order entry and market data, although this is
not necessarily the case as drop copies are used for time sensitive risk management tasks. Secondary data may
consist of drop copy fills, credit limit information, statistical data, trade confirmations, and best bids and offers for
vendor consumption, etc. These are just a few of the possibilities. Application Sequencing benefits data providers
and their users by providing a common protocol which can be used to perform secondary data distribution. New
applications transmitting data can be quickly introduced over an existing channel with minimal effort simply by
introducing a new ApplID (application ID).

Transaction usage is not recommended

Application Sequencing is not something that will be used in a normal order routing scenario. It has more
relevance in large volume one-way connections in which the receiver would like to have some ability to control
the data that is resent after a disconnect or data loss. There is no obvious advantage in using Application
Sequencing with a regular trading connection since all data transmitted between Sender and Receiver is of equal
importance in maintaining a viable trading session. Application Sequencing should not be used to track broker
connections that are in place for trading purposes. It should only be used for managing the flow of data when a
FIX connection is used to deliver data in bulk and where there is a stated need to create classes of data.
For additional usage guidance on using these messages, see Volume 7 – USER GROUP: EXCHANGES AND
MARKETS.
Using Application Sequencing and Session Sequencing for Gap Detection

The use of ApplResendFlag on the new Application Sequence Group Component is used to indicate that messages
are being retransmitted as a result of an Application Message Request. It is possible for both ApplResendFlag and
PossDupFlag to be set on the same message if the Sender’s cache size is greater than zero and the message is
being resent due to a session level resend request.
The Sender and Receiver may agree to use a limited cache in order to benefit from the convenience of session-
level retransmission. In this case, a message that is dropped in response to an Application Message Request may
have both fields present. This scenario depends on whether (1) the Sender is maintaining a cache and (2) the
Sender and Receiver have agreed to fill any gaps to the extent possible using the session-level.
In this scenario, a combination of Application and Session level sequencing will be used to recover missed
messages. A limited cache of session level messages may be retained by the Sender in order to recover messages
that have been dropped within an pre-stated window defined by time or number of messages. When a FIX session
Resend Request message is issued within this window the Sender’s session will resend the messages. Once the
window has been exceeded an Application Message Request must be issued in order to recover dropped messages.
The application level will not be aware that a gap has occurred until the session level has recovered what it
available. Beyond this, the application will detect the gap according to the logic as described and issue a resend
request at the application level using the Application Message Request.
Gap detection and recovery with respect to the Application Message Request message and response messages
(e.g. Application Message Request Ack and resent application messages using ApplicationSequenceGrp
component block) may also need to take place at the application level since session level recovery may have been
suspended.

Application Message Request

This message is used to request a retransmission of a set of one or more messages generated by the application
specified in RefApplID (1355). The message can be used for five types of transmission requests:
0 - retransmission of application messages for a specified application and sequence number range,
1 - subscription to an application in order receive, for example, drop copy services,
2 - request for the last application sequence number sent by an application,
3 - request the valid set of application identifiers for which a user is authorized,
4 - unsubscribe to one or more of applications
The Request message specifies the sequence number range using ApplBegSeqNum (1182) and ApplEndSeqNum
(1183) for a given RefApplID (1355) to request messages for retransmission.
Application Message Request

StandardHeader Y MsgType = BW
1346 ApplReqID Y Unique identifier for request
1347 ApplReqType Y Type of Application Message Request being made
Start of Component block, expanded in line < ApplIDRequestGrp >
1351 NoApplIDs N Specifies number of application id occurrences
 1355 RefApplID N
 1182 ApplBegSeqNum N Message sequence number of first message in range to be
resent
 1183 ApplEndSeqNum N Message sequence number of last message in range to be
resent. If request is for a single message
ApplBeginSeqNo = ApplEndSeqNo. If request is for all
messages subsequent to a particular message,
ApplEndSeqNo = "0" (representing infinity).
End of Component block, expanded in line < ApplIDRequestGrp >
58 Text N Allows user to provide reason for request
354 EncodedTextLen N
355 EncodedText N
StandardTrailer Y

H UTH
Refer to the FIXML element ApplMsgReq

Application Message Request Ack

This message is used to acknowledge an Application Message Request providing a status on the request (i.e.
whether successful or not). This message does not provide the actual content of the messages to be resent.
Application Message Request Ack

StandardHeader Y MsgType = BX
1353 ApplResponseID Y Identifier for the Application Message Request Ack
1346 ApplReqID N Identifier of the request associated with this ACK
message
1347 ApplReqType N
1348 ApplResponseType N
1349 ApplTotalMessageCount N Total number of messages included in transmission
Start of Component block, expanded in line < ApplIDRequestAckGrp >
1351 NoApplIDs N Number of applications
 1182 ApplBegSeqNum N
 1183 ApplEndSeqNum N
 1357 RefApplLastSeqNum N
 1354 ApplResponseError N
End of Component block, expanded in line < ApplIDRequestAckGrp >
58 Text N
355 EncodedText N
StandardTrailer Y

H UTH
Refer to the FIXML element ApplMsgReqAck

Application Message Report

This message is used for three difference purposes: to reset the ApplSeqNum (1181) of a specified ApplID (1180).
to indicate that the last message has been sent for a particular ApplID, or as a keep-alive mechanism for ApplIDs
with infrequent message traffic. The purpose of the Application Message Report is indicated by ApplReportType
(1426).
Using Application Message Report to reset ApplSeqNum
The Application Message Report (Reset) is sent by the ApplID sender to alert the receiver that the
ApplSeqNum is being reset, for one or more ApplID, to the specified value(s). The next application message
received will then conform to this value. In other words, ApplSeqNum in this message represents the next
expected application sequence number the receiver will receive from the sender for the corresponding
ApplID. An Application Message Report (Reset) has no affect on, and is independent of, the FIX session
sequence number in MsgSeqNum (34).
Using Application Message Report to indicate lastmessage sent
The ApplID sender can use the Application Message Report to indicate that the last message has been sent for
one or more ApplIDs. Reception of this message mean the recipient can safely assume that no more message
will be sent for that/or those ApplIDs. RefApplLastSeqNum should be set to the last ApplSeqNum sent for
this ApplID.
Using Application Message Report as keep-alive mechanism
For recipients of ApplIDs with infrequent message traffic it is a problem to detect a gap in the message flow.
The gap cannot be detected until reception of the next message for that ApplID. To mitigate this problem the
Application Message Report message can be issued by the ApplID sender at regular intervals.
RefApplLastSeqNum should be set to the last ApplSeqNum sent for this ApplID.
Application Message Report

StandardHeader Y MsgType = BY
1356 ApplReportID Y Identifier for the Application Message Report
1426 ApplReportType Y Type of report
Start of Component block, expanded in line < ApplIDReportGrp >
1351 NoApplIDs N Number of applications
 1399 ApplNewSeqNum N
 1357 RefApplLastSeqNum N
End of Component block, expanded in line < ApplIDReportGrp >
58 Text N
355 EncodedText N
StandardTrailer Y

H UTH

Refer to the FIXML element ApplSeqReset

Application Sequencing Message flows

Application recovery over a FIX session
The message flow shows a use case in which the Receiver disconnects from the Sender and generates an
Application Message Request in order to fill the sequence gap. The workflow occurs as follows (see Figure 1):
1. The Sender and receiver establish a connection using a standard FIX session.
2. The Sender forwards messages to a receiver from Application 1 and Application 2 over the FIX session. The
Receiver is checking Application Sequence Numbers at the application level
3. The Receiver then experiences a disconnection.
4. While disconnected, the Sender continues to send messages for Application 1 and Application 2.
5. Upon reconnecting, the Receiver’s session sends a Resend Request to recover missed messages (due to Logon
with higher than expected MsgSeqNum).
6. The Sender responds with SequenceReset-GapFill in order to suppress the session level retransmission of
messages. This has been pre-arranged between parties based on the nature of the connection
7. A message for Application 1, ApplSeqNum is 11 is received causing the Receiver to detect an application
level gap
8. The Receiver sends an Application Message Request to specifically request any messages from Application 1
that may have been missed starting at the last application sequence number received.
9. Messages from Application 2 are not requested and are therefore not retransmitted.
10. The Sender retransmits the requested messages for Application 1

Figure 1: Application Sequencing Recovery over a FIX session

Application Sequencing Recovery Over a FIX Session
Receiver Receiver Sender Sender

Sender
Application Session Application1 Application2
FIX Session FIX Session
Receiving
Application 1 Messages
Application checks ApplFeedID=A1, ApplSeqNum=1 ApplFeedID=A1, ApplSeqNum=1
for App-level Gaps
ApplFeedID=A2, ApplSeqNum=1 ApplFeedID=A2, ApplSeqNum=1
Disconnect
ApplFeedID=A1, ApplSeqNum=2-10
Sender responds
Reconnect
Logon MsgSeqNum=10009 using GapFill for
ALL MESSAGES
Resend Request (35=4)
Next message for
App A1 is sent
SequenceRest-GapFill
Receiving App Application 1 Messages

detects gap and ApplFeedID=A1, ApplSeqNum=11 ApplFeedID=A1, ApplSeqNum=11
generates App
Appl Message Request – A1, 2-10
Resend Request
Messages for
App A1 are
Appl Message Response – A1, 2-10 Resent
ApplFeedID=A1, ApplSeqNum=2-10ApplFeedID=A1, ApplSeqNum=2-10
Application recovery independent of FIX session

The message flow shows a use case in which the Receiver is using Application Sequencing and Recovery to
recover data over that has been lost over a multicast-broadcast transport. In this scenario the following recovery
takes place (see Figure 2):
1. The Sender sequences the messages in Application 1 and 2 using ApplSeqNum so that the Receiver/s are
able to detect gaps and perform Application Message Requests based on the ApplSeqNum.
2. The Receiver disconnects from the feed while the Sender continues to generate new messages.
3. Once reconnected the Receiver detects the gap and generates an Application Message Request for
Application 1 in order to fill the sequence gap. The missed messages for Application 2 are not recovered.
4. The Request is sent over the back-channel which has been separately established in order to support the
Resend Request.
5. The Sender uses the back-channel to respond with an Application Resend Response and delivers the
requested messages with the original ApplSeqNum.

Figure 2: Application Sequencing Recovery outside of a FIX session
Application Sequencing Recovery Outside of the FIX Session
Receiver Sender Sender

Receiver Sender
Application Application1 Application2
One-way
Multicast Multicast
comm
Receiving
Application checks ApplFeedID=A1, ApplSeqNum=1 ApplFeedID=A1, ApplSeqNum=1
for App-level Gaps
ApplFeedID=A2, ApplSeqNum=1 ApplFeedID=A2, ApplSeqNum=1
Disconnect
Reconnect
Next message for

Back-channel Two-way Back-channel App A1 is sent
Receiving App Application 1 Messages

detects gap and ApplFeedID=A1, ApplSeqNum=11 ApplFeedID=A1, ApplSeqNum=11
generates App Appl Message Request – A1, 2-10
Resend Request
Messages for
App A1 are
Appl Message Response – A1, 2-10 Resent
ApplFeedID=A1, ApplSeqNum=2-10ApplFeedID=A1, ApplSeqNum=2-10

Glossary
Business Terms
The following glossary is an attempt to identify business terms used in this document or related to implementing
FIX globally. Requests for new terms and/or suggested definitions should be posted in the FIX Web Site’s
Discussion section.
Term Definition Field where

used
Acceptable Counterparty A counterparty eligible for trading with the order or quote [PartyRole]
Initiatior.
Accrued Interest Rate The amount the buyer compensates the seller for the portion of the
next coupon interest payment the seller has earned but will not
receive from the issuer because the issuer will send the next
coupon payment to the buyer. Accrued Interest Rate is the
annualized Accrued Interest amount divided by the purchase price
of the bond.
After Tax Yield Municipals. The yield on the bond net of any tax consequences [YieldType]
from holding the bond. The discount on municipal securities can
be subject to both capital gains taxes and ordinary income taxes.
Calculated from dollar price.
All or None A round-lot market or limit-price order that must be executed in [ExecInst]
its entirety or not at all; unlike Fill or Kill orders, AON orders are
not treated as canceled if they are not executed as soon as
represented in the Trading Crowd.
American style option An option that can be exercised at anytime before its expiration [ExerciseStyle]
date.
Source: www.investopedia.com and www.investorwords.com
Annual Yield The annual interest or dividend income an investment earns, [YieldType]
expressed as a percentage of the investment’s total value.
As defined Sides of the legs are the same as defined in the multileg [Side]
instrument.
At Crossing An order that is valid only during crossing (auction) phases. The [TimeInForce]
order is valid during the day or up to and including a specified
trading (sub) session. Also see Good Till Crossing (GTX), Good
Through Crossing,At the Opening and At the Close.
At the close Indicated price is to be around the closing price, however, not held [IOIQualifier]
to the closing price.
At the Opening A market or limit-price order to be executed at the opening of the [TimeInForce]
stock or not at all; all or part of any order not executed at the
opening is treated as canceled.
Auto-match Specifies that the source matching mechanism for a trade is [MatchType]
automatic matching (of orders and / or quotes)
Automated Floor Order The use of electronic devices or systems to capture orders and [TradeHandling
Routing route the resulting trades to downstream system for matching and Instr]
post-trade activities.
Average Price Guarantee A limit order instruction that order allows fills against worse [DiscretionInst]


used
prices if this is compensated with higher prices so the volume
weighted average is at the limit price or better. Applies to each
execution round in automatic matching.
Basis Price A price established by joint agreement of odd-lot dealers in 100- [OrdType]
share-unit stocks when:
- no round-lot has occurred during the trading session,
- the spread between the closing bid and offer is two points or
more, and
- on odd-lot the dealer has been given a “basis-price” order.
Bermuda style option A type of option that can only be exercised on predetermined [ExerciseStyle]
dates, usually every month.
Source: www.investopedia.com
Binary Option A binary option is a cash settled option that has a discontinuous
payoff. Binary options come in many forms, but the two most
basic are: cash-or-nothing and asset-or-nothing. Each can be
European or American style and can be structured as a put or call.
Also called a "digital option" or "all-or-nothing option".
Source: www.riskglossary.com
Block Lot A lot size that is larger than the Round Lot and associated with [LotType]
special block trading rules as bilaterally agreed between parties.
Book Yield The yield of a security calculated by using its book value instead [YieldType]
of the current market price. This term is typically used in the US
domestic market.
Broker Execution According to US futures markets (CFTC): [TrdRegTimest
ampType]
Time at which a broker executed the order for another broker.
Broker of Credit Broker to receive trade credit. [PartyRole]
Broker Receipt According to US futures markets (CFTC): [TrdRegTimest
ampType]
Time at which broker received the order.
Buy Minus A round-lot market order to buy “minus” is an order to buy a [Side]
stated amount of a stock provided that its price is:
- not higher than the last sale if the last sale was a “minus” or
“zero minus” tick and
- not higher than the last sale minus the minimum fractional
change in the stock if the last sale was a “plus” or “zero plus” tick.
A limit price order to buy “minus” also states the highest price at
which it can be executed.
Cabinet Trade An off-market transaction to close out a nearly worthless out-of-
the-money option contract.
Call Date The date on which the issuer of a security has the right but not the [EventType]
obligation to repurchase the security at a predetermined price.
Call First Refer to client before trading. [ExecInst]


used
Cancel if Not Best Indicates that an order should be cancelled if it is no longer the [ExecInst]
best bid if buying, or the best offer if selling. If the order is
cancelled due to this instruction, the message cancelling it must
carry ExecRestatementReason="Canceled, Not Best".
Cancel on System Failure If a system failure interrupts trading or order routing, attempt to [ExecInst]
cancel this order. Note that depending on the type and severity of
the failure, this might not be possible.
Cancel on Trading Halt If trading in this instrument is halted, cancel this order and do not [ExecInst]
reinstate it when/if trading resumes.
CIV ("Collective Collective investment vehicle ("CIV") are set up for the purposes [CFICode]
Investment Vehicle") of collecting and pooling investor funds and issuing shares (or
and
their equivalent). "Open-ended" CIVs entitle the holder to receive,
on demand, an amount in value which is proportionate to the a “Product”
whole net asset value of the vehicle. Coversely "Closed-ended" within Volume
CIVs do not grant this right to investors. 7
CIVs are more commonly known as Mutual Funds, Unit Trusts,
OEICS (Open Ended Investment Companies), SICAVs etc.
A CIV may be legally constituted as a Limited Company with
variable capital, a Trust or a Limited Partnership - depending on
local legislation & tax regimes.
CIVs typically invest in equities, bonds, derivatives etc. - as
described in their prospectus. Other CIVs are Umbrella Fund
(made up of sub-funds investing in equities, gilts etc), Fund Of
Funds (invests only in other funds), Master-Feeder Fund
(marketed to a specific group for investment in a central master
fund), Multi-Manager Fund (whose asset management is divied
between several managers), Side By Side (onshore and offshore
funds with the same investment strategy)
Clearing Firm Firm that will clear the trade. Used if different from the executing [PartyRole]
firm.
Clearing Organization Identifies the Clearing Organization where the position is [PartyRole]
maintained.
Client ID Firm identifier used in third party-transactions or for investor [PartyRole]
identification in intermediary transactions. (should not be a
substitute for OnBehalfOfCompID/DeliverToCompID).
[PositionEffect]
Close An instruction to position keeping that the trade should bring the
position towards zero, i.e. close as much as possible of any
existing position and open an opposite position for any remainder.
[PositionEffect]
Close but Notify on Open An instruction to position keeping that the trade should close an
existing position. If the position is closed out and an opposite
position is opened a notification is sent out.
[YieldType]
Closing Yield The yield of a bond based on the closing price.
[YieldType]
Closing Yield Most The yield of a bond based on the closing price as of the most
Recent Month recent month's end.
[YieldType]
Recent Quarter recent quarter’s end.


used
[YieldType]
Recent Year recent year’s end.
[YieldType]
Compound Yield The yield of certain Japanese bonds based on its price. Certain
Japanese bonds have irregular first or last coupons, and the yield is
calculated compound for these irregular periods.
[MatchType]
Confirmed Trade Report A trade that is completed (both sides are reported) and matched.
(reporting from The receiver confirms the completed trade.
recognized markets)
[PartyRole]
Contra Firm The broker or other firm which is the contra side of the trade.
[PartyRole]
Contra Clearing Firm Clearing firm of the broker or other firm which is the contra side
of the trade.
Contra Trader Individual usually identified by a trading badge number or initials [PartyRole]
that takes the opposite side of a trade.
Contract For Difference A single stock total return swap, combining financing and [BookingType]
(CFD) synthetic equity exposure in one transaction.
Contract Weighted Relevant for multileg orders (Energy Specific). The price of the [MultilegPrice
Average Price strategy is given as an average price of all legs in the multileg, Method]
including adjustment for differences in contract sizes between the
legs.
Correspondent Broker Identifies a correspondent broker. [PartyRole]
Correspondent Clearing ClearingFirm that is going to carry the position on their books at [PartyRole]
Firm another clearing house (exchanges).
Correspondent Clearing Identifies a correspondent clearing organization [PartyRole]
Organization
Counter-Order Selection A model where the user selects which order to hit by providing the [OrdType]
order ID in the order being submitted against it (also know as
Hit/Take orders).
Specifies that the source matching mechanism for a trade is a Hit / [MatchType]
Take.
Coupon Rate The rate of interest that, when multiplied by the principal, par
value, or face value of a bond, provides the currency amount of
the periodic interest payment. The coupon is always cited, along
with maturity, in any quotation of a bond's price.
Cross Client sends Broker a buy or sell order. Broker wishes to take the [OrdType]
other side and cross with the client. Broker sends an order with
Side=Cross to an exchange.
Crossed Generally indicates that the current offer price is better than the [QuoteConditio
bid one - a situation where a trade normally should have occurred. n]
The rules for crossed book situations are bilaterally agreed
between counterparties.
[See Vol. 3 Market Data for usage notes]
Cross Auction Crossing session, for example to open or close a market. Rules [MatchType]
governing this type of session usually differ from those effective
during continuous trading. For example, price determination could
be subject to the principle of most executable volume. Visibility


used
of the order book is typically restricted (e.g. top-of-book only,
indicative crossing price) compared to continuous trading. The
session itself might be separated into different phases governed by
different rules, all of which are defined by the marketplace
offering this type of matching mechanism.
Specifies that the source matching mechanism for a trade report is
Call Auction (a crossing session like the onnes often used to open
or close a market).
Cross Short Client wants to establish a short position, and so sends a Sell Short [OrdType]
to Broker. Broker wants to cross with the Client, so Broker sends a
Cross Short order to an exchange. Cross Short is crucial here
because many exchanges have tick rules needing to be enforced,
and the order getting converted from Sell Short to Cross (instead
of Cross Short) could result in an illegal short sell.
Cross Short Exempt Client wants to establish a short position, and is exempt from the [OrdType]
uptick restriction. So Client sends Sell Short Exempt to Broker.
Broker wants to cross with the Client, so Broker needs a way to
send "Cross Short Exempt" to the exchange so that an audit trail
traces back indicating that the party selling short was exempt from
the uptick rule.
Currency swap "An agreement to exchange future cash flows. There are two
fundamental types: the cross-currency swap and the interest rate
(single currency) swap."
Source: A Foreign Exchange Primer by Shani Shamah
U U
Current Yield Annual interest on a bond divided by the market value. The actual [YieldType]
income rate of return as opposed to the coupon rate expressed as a
percentage.
Customer Account Identifies the customer account associated with the message. [PartyRole]
Dated Date The effective date of a new securities issue determined by its
underwriters. Often but not always the same as the "Issue Date"
and the "Interest Accrual Date"
Day Order A buy or sell order that, if not executed expires at the end of the [TimeInForce]
trading day on which it was entered.
Default Position Effect An instruction to use the default position keeping rules assigned to [PositionEffect]
the account. For Options and Futures the default is normally "net"
position, while for Forwards the deafault is usally "open" position.
Dealt currency In a foreign exchange transaction, 'dealt currency' indicates which [Currency]
currency was orginally specified. For example, An invesment
manager may 'buy 100M USD against EUR'. This has USD as the
'dealt currency' and EUR as the 'counter currency'. Note that when
viewed from the sell-side's (or broker's) perspective, this is a 'Sell
100M USD against EUR' the 'dealt currency' remains the same.
Derivative Related Exercise or expiration of options, forwards or futures contracts [TrdType]
Transaction that imply an exchange of securities or a trade that relates to a
derivatives trade and that forms an unconditional part of a
combination together with a derivative trade.
Discount When a bond sells below its par value, it is said to be selling at a [PriceType]


used
discount. A price with a PriceType of "discount" is the difference
between 100 and the bond's percent-of-par price.
Do Not Increase A limit order to buy, a stop order to sell, or a stop-limit order to [ExecInst]
sell which is not to be increased in shares on the ex-dividend date
as a result of a stock dividend or distribution.
Do Not Reduce A limit order to buy, a stop order to sell, or a stop-limit order to [ExecInst]
sell that is not to be reduced in price by the amount of an ordinary
cash dividend on the ex-dividend date. A do-not-reduce order
applies only to ordinary cash dividends; it should be reduced for
other distributions - such as when a stock goes “ex” stock dividend
or “ex” rights.
Dollar Price See "Percent of Par" [PriceType]
Entering Firm Broker who has recorded or reported an execution. This field is [PartyRole]
particularly useful where the trade is entered into a trade recording
system by a broker who is not a party to the trade, as it allows any
inquiries or problem resolution to be directed to the appropriate
source.
Entering Trader Individual usually identified by a trading badge number or initials [PartyRole]
that actually enters an order to a market (especially in open outcry
markets). Usually the Entering Trader is the same as the
Executing Trader. However, under some circumstances the
Entering Trader will have the trade executed by another trader
who is then identified as the Executing Trader.
Entering Unit Individual unit within an Entering Firm, e.g. trading desk, branch [PartyRole]
office or similar, that actually enters an order to a market. Usually
the Entering Unit is the same as the Executing Unit that is
responsible for the transction. The Executing Unit can delegate the
entry but not the responsibility to another unit who is then
identified as the Entering Unit.
European style option An option that can only be exercised at the end of its life or for a
short, specified period of time just prior to expiration (usually on a
single day).
Source: www.investopedia.com and www.investorwords.com
Even swap An FX Swap where the given amount to be bought and sold is the
same on the near and far legs. See "uneven swap".
Exchange Exchange associated with the position. [PartyRole]
Exchange granted trade A trade done according to an individual or general authorisation, [TrdType]
obtainedprior to theconsumation ofthe trade, from the marketplace
for the specific case and/or kind of trade.
Execute as delta neutral Indicates that the quantity of a strategy leg is to be (or was) [ExecInst]
using volatility provided calculated as delta neutral using provided volatility parameters
Execute as duration Indicates that the quantity of a strategy leg is to be (or was) [ExecInst]
neutral calculated as duration neutral
Execute as FX neutral Indicates that the quantity of a strategy FX leg is to be (or was) [ExecInst]
calculated as neutral with regards to the security traded for the
other legs of the strategy


used
Execution Time According to US futures markets (CFTC): [TrdRegTimest
ampType]
Non-qualified reporting time of order execution.
Executing Firm Identifies executing / give-up broker. [PartyRole]
Executing System System Identifier where execution took place (some markets have [PartyRole]
multiple execution location such as an electronic book or
automatic execution system).
Executing Trader Trader or broker id associated with Executing Firm who actually [PartyRole]
executes the trade.
Executing Unit Identifies executing unit within an Executing Firm, e.g. trading [PartyRole}
desk, branch office or similar.
Exhaust A reserve order refresh method where the displayed quantity is not [DisplayWhen]
refreshed until exhausted (filled).
External Routing Indicates that an order sent to one market may be routed by that [ExecInst]
Allowed market to other external markets, especially in cases where the
order locks or crosses the market and it can be executed against
another market’s superior price. Note: The absence of this
instruction does not imply that an order should not be routed
externally; rather, the order receiver’s default will apply.
External Routing Not Indicates that an order sent to one market may never be routed by [ExecInst]
Allowed that market to other external markets. Should the order lock or
cross the market but be unable to execute due to price protection
reasons, a market may have to take alternate action, which might
include rejecting the order, depending on the market’s rules.
Note: The absence of this instruction does not imply that an order
should be routed externally; rather, the order receiver’s default
will apply.
Fill or Kill A market or limit-price order that is to be executed in its entirety [TimeInForce]
as soon as it is represented in the Trading Crowd; if not so
executed, the order is to be canceled. Not to be confused with
Immediate or Cancel.
Final Inventory Due Date Specifies the last date on which purchase dates for a contract must [EventType]
be provided to the service provider.
First Delivery Date Specifies the first delivery date of the delivery period for a [EventType]
physically delivered instrument.
First Intent Date Specifies the first date of the delivery period on which intents may [EventType]
be submitted for a physically delivered instrument.
FIX Connection A FIX Connection is comprised of three parts: logon, message
exchange, and logout.
FIX Session A FIX Session is comprised of one or more FIX Connections,
meaning that a FIX Session spans multiple logins.
Fixed Price Cabinet Cabinet Trade executed at a price equal to the minimum tick size [PriceType]
Trade (or smallest possible price) . See "Cabinet Trade".
Fixed Tick Rule A fixed cabinet trade price set to a minimum tick amount. [TickRuleType]
Flexible Instrument An exchange-listed instrument for which a set of pre-defined


used
attributes such as strike price, expiration date and underlying
instrument may be provided by the user at the time of creation
(creating a new instrument). Can be an option or future.
Floating Price Cabinet Cabinet Trade executed at a price that can be different than the [PriceType]
Trade minimal price. See "Cabinet Trade".
Forex - Swap A "Swap" order for Foreign Exchange (currency trading). [OrdType]
Foreign exchange swap The transaction of exchanging two currencies at an agreed upon
rate at an agreed upon time. The transaction is reversed at a future
rate and time, with no payment streams between the points in
time.
Source: A paraphrase of definition from

http://joxo.co.uk/SummaryGuideToFXForFinancialandITProfessi
onals.html
Funari Japanese term for an order to buy or sell a stated amount of a [OrdType]
security at the specified limit price with any unexecuted (leftover)
quantity becoming a Market On Close order.
Fund manager Client ID For CIV: [PartyRole]
An identifier for an Investor or a broker or funds supermarket’s
nominee/custodian company which is recognized by the Fund
manager.
Giveup Clearing Firm Firm to which the trade is given up (carries the position that [PartyRole]
results from a trade).
Good Till Canceled An order to buy or sell that remains in effect until it is either [TimeInForce]
executed or canceled; sometimes called an “open order”.
Good Till Crossing An order to buy or sell that is canceled prior to the market [TimeInForce]
(GTX) entering into an auction, or crossing phase. Typically, markets that
support continuous trading will have an auction phase at the
beginning and sometimes also at the end of trading to match up
orders that have been entered into the exchange's order book
during the pre- or post-trading phase (i.e. where no continuous
trading was available). A GTX order automatically expires
immediately prior to the commencement of a crossing session, i.e.
the party originating the order wants to make sure it gets filled
during the current continuous auction, and any remaining open
quantity should be discarded at the end of the current continuous
auction period.
Good Through Crossing An order that is valid up till and including a crossing phase. Also [TimeInForce]
see Good Till Crossing (GTX), At Crossing, At the Opening and
At the Close.
Government Equivalent Ask yield based on semi-annual coupons compounding in all [YieldType]
Yield periods and actual/actual calendar.
Held The firm executing the order is held to best execution [ExecInst]
requirements, and may not make discretionary decisions.
Opposite of Not Held
Ignore Price Validity Disables validity checking of price fields for an order or change [ExecInst]


used
Checks request.
Imbalance Only Indicates than order is an “Imbalance” order. Exchanges often use [ExecInst]
this type of (often unpriced) order to allow certain trading
participants to remove imbalances in call auctions.
Immediate A reserve order refresh method where the displayed quantity stays [DisplayWhen]
the same until the remaining executable quantity of the order goes
below.
Immediate or Cancel A market or limit-price order that is to be executed in whole or in [TimeInForce]
part as soon as it is represented in the Trading Crowd; any portion
not so executed is to be canceled. Not to be confused with Fill or
Kill.
The price of a multileg order strategy is given using individual [MultilegPrice
Individual Prices prices for the legs. Method]
A reserve order instruction to refresh using the initially displayed [DisplayMetho
Initial quantity. d]
Specifies the first date on which purchase dates for a contract must [EventType]
Initial Inventory Due be provided to the service provider.
Date
An “initiator” may be one of the following: Quoting and
Initiator • an institutional client other messages
• a financial planner
• a retail broker representing a retail customer
Volume 7
• a broker/dealer
• an inter-dealer broker (or broker’s broker)
• an issuer
[ExecInst]
Institutions Only Broker is restricted to dealing with other buy side firms.
Instrument Denominator Specifies the price denominator of a fractionally quoted [InstrAttribTyp
instrument such as treasure note futures or corn futures. Values are e]
whole numbers. Examples are Quarters (4), Eights (8), Sixteenths
(16), Thirty-seconds (32), etc.
Instrument Numerator Specifies the denominator for the fractional portion of a numerator [InstrAttribTyp
for a fractionally quoted price. For example, a price 5 3¼ / 32 has e]
an Instrument Numerator of 4. Values are whole numbers.
Instrument Price Specifies the number of decimal places that are provided in order [InstrAttribTyp
Precision to correctly format a price. Generally, used for the formatting of e]
fractional prices. Values are whole numbers.
Instrument Strike Price Specifies the number of decimal places that are provided in order [InstrAttribTyp
Precision to correctly format a strike price. Generally, used for the e]
formatting of fractional prices. Values are whole numbers.
Interest Accrual Date The start date used for calculating accrued interest on debt
instruments which are being sold between interest payment dates.
Often but not always the same as the "Issue Date" and the "Dated
Date".
Intermarket sweep An order that is an intermarket sweep as defined by the SEC in [ExecInst]
Regulation NMS. This value is used on Immediate or Cancel
limit orders (or other order type and time in force). It indicates
that the party sending the order has taken responsibility for price
protection, and the recipient of the order should execute it, if
possible, without regard to protection of other markets’ prices.


used
While the term “Intermarket sweep” is specific to the United
States, the ExecInst value that represents it may be used in other
markets, where appropriate, to indicate an order that should be
executed without regard to price protection.
A trade done internally at a marketplace member. Often restricted [TradeConditio
Internalized Trade
to the inside of the current spread. In cases where the trade must n]
be offered to the market for price improvement it is often called
Cross Trade.
The broker or other intermediary with the closest association with [PartyRole]
Introducing Firm
the investor.
Inverse Floater Bond Inverse floater semi-annual bond equivalent rate. [YieldType]
Yield
For Equities: [PartyRole]
Investor ID
Identifies beneficiary or broker acting on behalf of beneficiary.
This field is mandatory for various exchanges either pre or post
trade.
Numerical entry containing no dashes.
For CIV: [PartyRole]
An Investor identifier such as a taxpayer reference (NINO, NPN,
DSS, SSN number etc) for an individual investor or a registration
number (EIN, etc.) for a company.
May contain alphanumeric and dashes.
Issue Date The date on which a bond or stock offering is issued. It may or
may not be the same as the effective date ("Dated Date") or the
date on which interest begins to accrue ("Interest Accrual Date")
Issue Price Stabilization This indication must, according to certain regulation, be used [OrderRestricti
when a broker is contracted by the issuer to stabilize the price ons]
before an issue of new stock of a security that is already traded (or
a buy-back/buy-out).
Issuer Holding Certain regulation requires this indicator to be attached when an [OrderRestricti
issuer is buying back its own stock (or units of other instruments). ons]
It can also be used in cases when a new issue is auctioned out over
the exchange.
Issuing/Buy-back Auction A call auction with the purpose of issuing new or buying back [MatchType]
stock, bonds or other security.
Last Delivery Date Specifies the last delivery date of the delivery period for a [EventType]
physically delivered instrument.
Last Intent Date Specifies the last date of the delivery period on which intents may [EventType]
be submitted for a physically delivered instrument.
Last Peg A pegged order specifying that the order should be priced relative [PegPriceType]
to the last sale price.
Limit An order to buy a security at or below a stated price, or to sell a [OrdType]
security at or above a stated price.
Limit or Better Indicates an order to [OrdType]
- buy a security at the indicated limit price or lower, or to


used
- sell a security at the indicated limit price or higher.
Limit With or Without An order to be executed at a limit price, with or without round-lot [OrdType]
sales; valid only for odd lot orders.
Liquidity Provider Identifies the individual that provided liquidity, e.g. was the [PartyRole]
market maker (specialist) involved in a trade. Used to identify the
liquidity provider involved in a block of EFP trade for listed
futures markets.
Locate/Lending Firm Identity of the firm which is loaning the security in a short sale. [PartyRole]
Locked Generally indicates that the current bid and offer prices are the [QuoteConditio
same, a situation where a trade normally should have occurred. n]
The rules for locked book situations are bilaterally agreed between
counterparties. Also see Crossed.
Marked To Market Yield An adjustment in the valuation of a securities portfolio to reflect [YieldType]
the current market values of the respective securities in the
portfolio.
Market Indicates an order to buy or sell a stated amount of a security at [OrdType]
the most advantageous price obtainable after the order is
represented in the Trading Crowd.
Market If Touched Indicates an order to buy or sell a stated amount of a security or [OrdType]
commodity as soon as a preset market price is reached, at which
point it becomes a Market order.
Market On Close Indicated price is held to the closing price ("firm" instruction). [IOIQualifier]
Market operations Identifies an OTC (privately negotiated) trade is entered by a [TradeConditio
Entered Trade marketplace official on behalf of the reporting party. n]
Market Or Better Indicates an order to buy or sell a stated amount of a security at [OrdType]
the quoted market or better.
Market Peg A pegged order specifying that the order should be priced relative [PegPriceType]
to the offer price if buying or bid price if selling.
Market Segment A subdivision of a market or marketplace that is setup and
operates within that market. A market segment may be setup for a
variety of reasons including (examples):
- regulatory - e.g. separate derivatives trading from stock trading
- membership - e.g. requiring separate membership or trading
authorization
- geographical - e.g. separate segments for various countries
- separate venues - e.g. floor/pit trading vs. electronic
- trading rules - e.g. different rules and behaviours that a market
needs to support for the entities it offers to trade
Market with Leftover as Indicates an order to buy or sell a stated amount of a security at [OrdType]
Limit the prevailing market price with any unexecuted (leftover)
quantity becoming a Limit order at the last executed price.
Median Price One type of average, found by arranging the values in order and [QuoteConditio
then selecting the one in the middle. If the total number of values n]
in the sample is even, then the median is the mean of the two


used
middle numbers. The median is a useful number in cases where
the distribution has very large extreme values which would
otherwise skew the data. (Source:
http://www.investorwords.com/).
Mid Price The average of a set of prices (not taking quantity into account). [QuoteConditio
Also see “Trading Session VWAP Price” n]
Mid-Price Peg (Midprice A pegged order specifying that the order should be priced relative [PegPriceType]
of inside quote) to the mid-price of the inside quotes.
Most Recent Closing The last available yield stored in history, computed using price. [YieldType]
Yield
Multi asset class Multileg Identifies that the trade occurred due to an equity / derivatives (or [TradeConditio
Trade other multi asset class) combination, either in the legs or in a n]
multileg order book.
Multileg-to-Multileg Identifies that a multileg order has executed against another [TradeConditio
Trade multileg order in a multileg order book (i.e. the legs were not n]
involved).
Net Price Relevant for multileg orders. The price is given as the sum of the [MultilegPrice
Price * Ratio for all legs. Method]
• If buying the strategy, the price of a bought leg (which is
a buy-leg in the multileg definition) is added, and the
price of a sold leg is subtracted.
• If selling the strategy, the price of a bought leg (which is
a sell-leg in the multileg definition) is subtracted, and the
price of a sold leg is added.
New A reserve order instruction to refresh using a quantity defined [DisplayMetho
separately from the initial display quantity. d]
Next Fund Valuation For CIV orders - indicates that the Investor wishes the order to be [OrdType]
Point dealt at the unit price determined at the next Valuation Point,
a.k.a. a Forward price.
Next Roll Date Next roll date for a swap [EventType]
No Cross The broker executing this trade is forbidden from taking the other [ExecInst]
side of the trade. Opposite of OK to Cross.
Non-standard settlement A Trade that deviates from the standard settlement and delivery [TrdType]
period.
Not Held The firm executing the order is not held to best execution [ExecInst]
requirements, and may be able to make some discretionary
decisions. Opposite of Held.
Odd Lot An amount of a security that is less than the normal unit of trading [LotType]
for that particular security. For stocks, any transaction less than
100 shares is usually considered to be an odd lot. (Source:
Investopedia)
Off Hours Trade A trade that occurs outside normal trading hours. Used to qualify [TrdSubType]
privately negotiated trades (subject to regulations)
OK to Cross The broker executing this trade is allowed to take the other side of [ExecInst]
the trade. Opposite of No Cross.


used
Omnibus Account An account where the positions for multiple entities (usually [PartyRole]
customers) are maintained. The omnibus accounting is usually
done on a gross basis where long and short positions are not netted
together.
On Basis An order to buy or sell at the basis price. The basis price is [OrdType]
established by joint agreement of odd lot dealers in 100 share unit
stocks when no round lot sale has occurred during the trading
session, the spread between the closing bid and offer is two points
or more, and an odd lot dealer has been given a basis price order.
On Hours Trade A trade that occurs during normal trading hours. Used to qualify [TrdSubType]
privately negotiated trades (subject to regulations)
One Cancels the Other An OCO order is an order whose execution results in the [ListExecInst]
(OCO) immediate cancellation of another order linked to it. Cancellation
of the Contingent Order happens on a best efforts basis. In an
OCO order, 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.
One-Party Report for A trade report for one side of a privately negotiated trade. When [TradeHandling
Matching both sides are reported the receiver matches and confirms the Instr]
trade.
One-Party Report for Pass A trade report for one side of a privately negotiated trade. The [TradeHandling
Thru receiver forwards a request to the counterparty who declines or Instr]
accepts the trade.
One Triggers the Other An OTO orders involves two orders—a primary order and a [ListExecInst]
(OTO) secondary order. The primary order is a live marketplace order.
The secondary order, held in a separate order file, is not. If the
primary order executes in full, the secondary order is released to
the marketplace and becomes live. An OTO order can be made up
of stock orders, option orders, or a combination of both.
One Updates the Other An OUO order is an order whose execution results in the [ListExecInst]
(OUO) immediate reduction of quantity in another order linked to it. The
quantity reduction happens on a best effort basis. In an OUO order
both orders are live in the marketplace at the same time. The
execution of either order triggers an attempt to reduce the
remaining quantity of the other order, partial executions included.
There are two sub-types of OUO orders:
1. In the Proportional Quantity Reduction model, the quantity of
the unfilled order is reduced proportionally to size of the
order that got filled. Example:
• Order A is for 100; Order B is for 50.
• When order B is partially filled for 25 (50 %), order A is
restated to a quantity of 50 (50 %).
2. In the Absolute Quantity Reduction model, the quantity of the
unfilled order is reduced with the fill size of the order that got
filled. Example:
• Order A is for 100; Order B is for 50.


used
• When order B is partially filled for 25, order A is restated
to a quantity of 75.
Open An instruction to position keeping that the trade should open a [PositionEffect]
new position.
Opening Peg A pegged order specifying that the order should be priced relative [PegPriceType]
to the opening price.
Opposite Sides of the legs are the opposite of their definition in the multileg [Side]
instrument.
Order imbalance, auction Used when a call auction (e.g. opening or closing a market) is [SecurityTradin
is extended extended due to an imbalance at the auction clearing price. gEvent]
Order Origination Firm Buyside firm associated with Order Origination Firm which [PartyRole]
originates/submits the order.
Order Origination Trader Buyside trader id associated with Order Origination Firm which [PartyRole]
originates/submits the order.
OTC Used to report into an exchange trades or prices that were agreed [TrdType]
directly, outside of the exchange rules, between the counterparties
("over the counter")
OTC Quote A OTC trade that occurs as the result of a Quote Negotiation. [TrdSubType]
Used to qualify privately negotiated trades (subject to regulations)
Outside Spread A trade done outside the current spread of the book. Often allowed [TradeConditio
due to special considerations only. n]
Par Equal to the face value (nominal) of a security, e.g. A bond selling [QuantityType]
at par is worth an equivalent to its original issue value, typically
$1000/bond.
Participate Don’t Initiate An order that may participate in a transaction initiated by another [ExecInst]
party, but may not initiate a transaction. For example, on US
ECNs / Exchanges, this may represent an order that will be quoted
to the marketplace and will trade if another party initiates a trade
(i.e. hits the posted quote), but cannot be routed to initiate a trade
with another market or market maker.
Peg to VWAP A pegged order specifying that the order should be priced relative [PegPriceType]
to the VWAP price.
Peg Refresh An execution restatement reason indicating that the order is [ExecRestatem
restated only because the pegged price was refreshed. entReason]
Pegged Order An order that acts like a limit order except that the limit price is
set relativeto another price, such as the last sale price, midpoint
price, opening price, bid, offer or VWAP (Volume Weighted
Average Price).
Per Unit The currency price per unit, e.g. per equity share or per contract. [PriceType]
Percent of Par The ratio between the current price of a bond and its par value [PriceType]
adjusted for amortization or indexing and expressed as a percent.
For example if a EUR1,000 bond is trading at EUR1032.50 its
price is expressed as 103.25 or 103¼. In the US this is usually
referred to as the "dollar price" even in scholarly material and
handbooks.


used
Percent of Volume The sender does not want to be all of the volume on the floor. [ExecInst]
Portfolio Trade The reporting of the portfolio trade should be executed when the [TrdType]
final leg of the transaction is completed. Used for trading an
index vs. a cash basket. Certain market regulations require that
participants repot a portfolio trade when the final leg of the
transaction is completed.
Position Account Account for positions resulting from derivatives trades. Each [PartyRole]
position account has a long and short quantity. Position quantities
stored in the long and short quantity fields can be kept net or
gross. Accounts that are kept gross are usually omnibus accounts.
Position Removal Date Specifies the date the firm positions will be removed for a [EventType]
financially (cash settled) delivered instrument.
Pre-listed only Instruments must be pre-listed [ListMethod]
Predefined Multileg An order for a multileg security that is already defined at the [MultilegModel
Security marketplace or with the receiver of the order. ]
[Note: see Vol. 4's Multileg Order section on predefined multileg
security models.]
Premium When a bond sells above its par value, it is said to be selling at a [PriceType]
premium. A price with a PriceType of "premium" is the
difference between the bond's percent-of-par price and 100.
Previous Fund Valuation For CIV orders - indicates that the Investor prefers that the order [OrdType]
Point be dealt at the unit price determined at the immediately preceding
Valuation Point, a.k.a. a Historic price. (This can be overridden by
the constitution of the fund or, in certain circumstances, by the
Fund Manager.)
Price Band Range (from-to or high-low) within which a valid price needs to
be specified.
Price Volatility To ensure price continuity, continuous trading is interrupted by a [SecurityTradin
Interruption volatility interruption whenever the potential execution price of an gEvent]
order lies outside the dynamic and/or static price range around a
reference price. A volatility interruption triggers a change of
trading form: e.g. continuous trading is interrupted and an auction
is initiated.
Primary Peg A pegged order specifying that the order should be priced relative [PegPriceType]
to the bid price if buying or offer price if selling.
Open Average Yield The average yield of the respective securities in the portfolio. [YieldType]
Order Originator ID of the party entering the trade into the system (data entry, [PartyRole]
userid, buy side trader, etc.).
Put Date The date on which the buyer of a security has the right but not the [EventType]
obligation to sell the security back to the issuer at a predetermined
price.
Previous Close Yield The yield of a bond based on the closing price 1 day ago. [YieldType]
Previously indicated An order sent in response to an Indication of Interest message. [OrdType]
Previously quoted An order sent in response to a Quote message. [OrdType]


used
Proceeds Yield The CD equivalent yield when the remaining time to maturity is [YieldType]
less than two years.
Random A reserve order instruction to refresh using a randomized display [DisplayMetho
quantity. d]
Redeem For CIV: [Side]
A “sell” order for CIV units which must be forwarded to the fund
manager (or their transfer agent) rather than being matched /
crossed with a “buy” order, e.g. by an intermediary, funds
supermarket, broker/dealer etc. This would be used in markets
where the originator requires specific tax treatment and/or dealing
charges.
Reinstate on System If a system failure interrupts trading or order routing, attempt to [ExecInst]
Failure reinstate this order, subject to time in force limitations. Note that
depending on the type and severity of the failure, this might not be
possible.
Reinstate on Trading Halt If trading in this instrument is halted, reinstate this order when/if [ExecInst]
trading resumes, subject to time in force limitations.
Repurchase Agreement Used to report both the initial deal and the repurchase. Allows [TrdType]
regulators to connect the two.
Note that this "definition" is not for the standard business term.
See online resources below.
Request to Intermediary Used in a model where an intermediary, e.g. clearing house, is [AllocType]
involved in communicating allocation details and actions between
two parties
Respondent A “respondent” may be one of the following: Quoting and
• a broker/dealer other messages
• an inter-dealer broker (or broker’s broker)
• an electronic service
• bid or offer prices provided by one or more market makers Volume 7
• bid or offer prices provided by an inter-dealer broker
• matching system with limit orders entered by customers
(dealers or institutions)
• an issuer
Reversed Net Price Relevant for multileg orders. This pricing convention is often used [MultilegPrice
at commodities markets. The price is given as the sum of the Price Method]
* Ratio for all legs.
• If buying the strategy, the price of a bought leg (which is
a buy-leg in the multileg definition) is subtracted, and the
price of a sold leg is added.
• If selling the stategy, the price of a bought leg (which is a
sell-leg in the multileg definition) is added, and the price
of a sold leg is subtracted.
Riskless Principal "Riskless" principal transactions are generally described as trades [OrderCapacity
in which, after receiving an order to buy (or sell) from a customer, ]
the broker-dealer purchases (or sells) the security from (or to)
another person in a contemporaneous offsetting transaction.
Above from the SEC web-site


used
TUhttp://www.sec.gov/rules/final/34-44291.htm
H UUUTH
See Exchange Act Rule 10b-10(a)(2)(ii)(A) [17 CFR 240. 10b-

10(a)(2)(ii)(A)]; Exchange Act Rel. No. 33743 (Mar. 9, 1994) at
n.11.
Round Lot Also known as as "Board Lot" or "Trade Lot". A standardized [LotType]
number of shares defined by a stock exchange as a trading unit. In
most cases, this means 100 shares.
Source: www.investopedia.com
Sell Plus A round-lot market order to sell “plus” is an order to sell a stated [OrdType]
amount of a stock provided that its price is:
- not lower than the last sale if the last sale was a “plus” or “zero
plus” tick and
- not lower than the last sale minus the minimum fractional
change in the stock if the last sale was a “minus” or “zero minus”
tick.
A limit-price order to sell “plus” also states the lowest price at
which it can be executed.
Sell Short An order to sell a security that the seller does not own; a sale [OrdType]
effected by delivering a security borrowed by, or for the account
of, the seller. Can only be executed on a “plus” or “zero plus”
tick.
Sell Short Exempt Short sale exempt from short-sale rules. [OrdType]
Semi-annual Yield The yield of a bond whose coupon payments are reinvested semi- [YieldType]
annually.
Settlement currency Commonly referred to as "counter currency" in FX nomenclature.
For non-NDF deals (FX swaps, spot and forward) the term
"settlement currency" can only mean one thing: the currency that
is on the opposite from the dealt currency (expressed in FIX using
Currency field (tag 15)). For example: Symbol is EUR/USD, and
the dealt is EUR then SettlCurrency is USD.
For NDF deals the term "settlement currency" could be either the
dealt currency or the "counter currency" or a third currency. For
example: In a USD/KRW NDF deal where the dealt currency is
KRW, the settlement currency is USD, if the dealt currency is
USD then the settlement currency can also be USD. In a
GBP/KRW NDF deal where the deal typically settles in a third
currency, USD in this case, then the settlement currency is USD.
(NDFs will be discussed in detail in Phase 2 gap analysis).
For FX OTC Spot Options, the settlement currency can refer to
either the counter currency or the currency of the option premium
(or premia). However, for the purposes of FIX usage, it will refer
to the currency of the option premium.
Settlement Location Identifies Settlement Depository or, if local settlement, the ISO [PartyRole]
Country Code.
Simple Yield The yield of a bond assuming no reinvestment of coupon [YieldType]
payments. (Act/360 day count)


used
Sponsoring Firm A member of the exchange that is sponsoring an Entering Entity to [PartyRole]
send orders to the exchange. The Sponsoring Member Firm
permits sponsorees (e.g. Entering Entities) to trade thereby
allowing them to enter orders directly to the exchange via
automated means. (e.g. NYSE allowing direct access via
Anonymous DOT service).
Spread A "spread" price is one of four things all denominated in basis [PriceType]
points:
1) For an outright security trade, the "spread" price is the
difference in yield between the object security and its
benchmark - implied or explicit.
2) For a swap (or switch) of two issued securities the "spread"
price is the difference in yield between the security being sold
and the one being bought.
3) For a roll of a futures contract with a contract in the same
commodity but having a different contract settlement month
the "spread" price is the price difference between the contract
being sold and the one being bought.
4) For a floating-rate Financing transaction the “spread” is the
difference in yield extended above or below the yield of the
stated benchmark.
All four types are expressed in basis points (the price or yield
difference times 100) and may be negative.
Stop A stop order to buy which becomes a market order when the [OrdType]
security trades at - or above - the stop price after the order is
represented in the Trading Crowd. A stop order to sell which
becomes a market order when the security trades at - or below -
the stop price after the order is represented in the Trading Crowd.
Stop Limit A stop order to buy which becomes a limit order at the limit price [OrdType]
when the security trades at - or above - the stop price after the
order is represented in the Trading Crowd. A stop order to sell
which becomes a limit order at the limit price when the security
trades at - or below- the stop price after the order is represented in
the Trading Crowd.
Stopped A trade is guaranteed for the order, usually at a stated price or [OrdStatus]
better, but has not yet occurred. For example, a specialist on an
exchange may "stop" an order while searching for a better price.
Streetside Trade Capture Reporting of completed trades for clearance and settlement or A “Section” in
Reporting compliance purposes. Reports may be originated by Exchanges or “Volume 5”
by clearing firms and sent to clearing firms directly or via a
clearing corporation or central counterparty such as DTCC in the
US.
Strict Limit (No Price A limit order that must be traded at the exact limit price specified [ExecInst]
Improvement) without any price improvement. Requires OrdType=Limit.
Subscribe For CIV: [Side]
A “buy” order for CIV units which must be forwarded to the fund
manager (or their transfer agent) rather than being matched /
crossed with a “sell” order, e.g. by an intermediary funds


used
supermarket, broker/dealer etc. This would be used in markets
where the originator requires specific tax treatment and/or dealing
charges.
Succession Event An event in which one entity succeeds to the obligations of [CorporateActi
another entity due to a corporate action (as a result of operation or on]
law or pursuant to any agreement), which may include events such
as a merger, consolidation, an amalgamation, a transfer of assets
or liabilities, a de-merger, a spin-off.
Suspended The order is not eligible for trading. This usually happens as a [OrdStatus]
result of a verbal or otherwise out of band request to suspend the
order, or because the order was submitted, or modified via a
Cancel/Replace Request, with ExecInst=Suspended.
Swap Start Date Starting date of an interest rate swap. Corresponds to the roll date [EventType]
date.
Swap End Date End date of an interest rate swap. Corresponds to the termination [EventType]
date
Swap Next Start Date Next starting date of an interest rate swap subsequent to the roll [EventType]
date
Swap Roll date Date on which a swap contract is rolled to the next period or start [EventType]
date. Corresponds to the Fixing Date on which the floating rate of
the swap is set.
Swap Value Factor The daily change in Net Present Value of a swap trade or position. [MDEntryType
Used in calculating the mark-to-market amount. ]
Tax Equivalent Yield The after tax yield grossed up by the maximum federal tax rate of [YieldType]
39.6%. For comparison to taxable yields.
TED Price The price spread between the active 3 month treasury bill futures [PriceType]
contract and the 3 month Eurodollar futures contract. Used as an
indicator of investor confidence in the U.S. markets.
TED Yield The difference in basis points between the yield-to-maturity of the [PriceType]
bond / note and the yield-to-maturity of a Hypothetical
Euromarket bond with identical coupon and maturity.
Time In According to US futures markets (CFTC): [TrdRegTimest
ampType]
Timestamp of when order was received on the trading floor
(booth).
Time Out According to US futures markets (CFTC): [TrdRegTimest
ampType]
Timestamp when the trade was received from the pit.
Tradable Indicator Specifies whether an instrument can be traded or not. [InstrAttribTyp
e]
Trade Along Clients who specify "Trade Along" give brokers permission to [ExecInst]
handle and place their order in the market even if the broker
already has its own proprietary orders for the same security placed
in the market.
Trade Confirmation A trade report confirming that a trade has been made. [TradeHandling
Instr]


used
Trading Session VWAP The volume weighted average price for a trading session. [QuoteConditio
Price n]
Trailing Stop Peg A pegged order representing a stop order with a stop price pegged [ExecInst]
to trail a specified distance behind the last sale price. The price of
a trailing stop to buy can never increase, and the price of a trailing
stop to sell can never decrease.
Triggered or Activated by An execution instruction that indicates that the sending system [ExecType]
System activated or updated the order. The triggering or activation is
normally based on instructions provided in the original order –
e.g. Stop order instructions.
True Gross Yield Yield calculated using the price including accrued interest, where [YieldType]
coupon dates are moved from holidays and weekends to the next
trading day.
True Yield The yield calculated with coupon dates moved from a weekend or [YieldType]
holiday to the next valid settlement date.
Try to Stop Used in specialist-driven markets to direct the specialist to try and [ExecInst]
stop the order.
Two-Party Report A trade report requesting the receiver to register both sides of a [TradeHandling
privately negotiated trade. Instr]
Two-Party Trade Report Specifies that the source for a trade report is a privately negotiated [MatchType]
(privately negotiated Two-Party Trade Report.
trade)
Unacceptable A counterparty not eligible for trading with the order or quote [PartyRole]
Counterparty Initiatior.
Underlying Contra Firm The broker or other firm which is the contra side of the trade for [PartyRole]
the underlying security.
Uneven swap An FX Swap where the given amount to be bought and sold is
different on the near and far legs.
URI (Uniform Resource W3C standard defined as "the generic set of all names/addresses See Appendix
Identifier) that are short strings that refer to resources". Note that "URL" 6-B
(Uniform Resource Locator), commonly referred to by web
browsers, is a subset of the URI standard. The W3C standards
body considers URL an "informal term (no longer used in
technical specifications)".
User-defined Multileg An order for a multileg security where the user defines the [MultilegModel
Security security together with the order and that multileg security is made ]
available to other actors. The lifetime of the multileg is bilaterally
agreed between parties.
security models]
User-defined, Non- A multileg order that does not involve securitization. The multileg [MultilegModel
Securitized, Multileg is not made available to other parties and the order is represented ]
only as implied-out prices. The multileg expires with the order.
security models]
User requested Instruments can be user requested as well as pre-listed. [ListMethod]


used
Value date The delivery or settlement date of a foreign exchange trade
transaction.
Variable Tick Rule A cabinet order can trade in even increments that can be [TickRuleType]
significantly different than a conventional tick increment.
Volume Weighted Volume Weighted Average Price is used for trades in which the [TrdType]
Average Price price is set at a guaranteed VWAP.
With or Without An odd lot order filled on an effective round lot transaction, or on [OrdType]
an effective bid or offer, whichever occurs first after the specialist
receives the order. (e.g. NYSE order type)
Yield At Issue Municipals. The yield of the bond offered on the issue date. [YieldType]
Yield Change Since Close The change in the yield since the previous day's closing yield. [YieldType]
Yield Difference The price of a strategy (multileg) order is given as a spread [MultilegPrice
between the two legs. Method]
Yield To Average The yield achieved by substituting a bond's average maturity for [YieldType]
Maturity the issue's final maturity date.
Yield To Next Call The yield of a bond to the next possible call date. [YieldType]
Yield To Longest The yield assuming only mandatory sinks are taken. This results [YieldType]
Average Life in a lower paydown of debt; the yield is then calculated to the
final payment date.
Yield To Maturity The yield of a bond to its maturity date. [YieldType]
Yield To Next Put The yield to the date at which the bond holder can next put the [YieldType]
bond to the issuer.
Yield To Next Refund Sinking Fund Bonds. Yield assuming all bonds are redeemed at [YieldType]
the next refund date at the redemption price.
Yield To Shortest The yield assuming that all sinks (mandatory and voluntary) are [YieldType]
Average Life taken at par. This results in a faster paydown of debt; the yield is
then calculated to the final payment date.
Yield To Tender Date The yield on a Municipal bond to its mandatory tender date. [YieldType]
Yield To Worst The lowest yield to all possible redemption date scenarios. [YieldType]
Yield Value of 1/32 The amount that the yield will change for a 1/32 nd change in price.
P P [YieldType]
Yield with Inflation Based on price, the return an investor would require on a normal [YieldType]
Assumption bond that would make the real return equal to that of the inflation-
indexed bond, assuming a constant inflation rate.
Other sources for definitions of financial terms include:

http://www.investinginbonds.com
http://www.investopedia.com
http://www.investorwords.com
http://www.riskglossary.com
http://www.888options.com

Appendix 1-A: Abbreviations used within FIXML
Acct Account Corp Corporate

Acrl Accrual Ctry Country
Acrd Accrued Cpn Coupon
Ack Acknowledgement Crss Cross
Actn Action Cum Cumulative
Adj Adjust Ccy Currency
Adjmt Adjustment Crv Curve
Adv Advertisement Data Data
Afctd Affected Db Database
Algo Algorithm Dt Date
Alloc Allocation Def Definition
AOS AllowableOneSidedness Del Delete
Amt Amount Dlvr Deliver
Appl Application Deriv Derivative
Asgn Assignment Desc Description
Attrb Attribute Dest Destination
Avg Average Dev Device
Base Base Disc Discount
Bhf Behalf Dsctn Discretion
Bnchmk Benchmark Dsctnry Discretionary
Bkng Booking DK Don't Know
Brkr Broker Dup Duplicate
Brkrs Brokers Efctv Effective
Biz Business Enc Encoded
Calc Calculation Err Error
Cxl Cancel Exch Exchange
Cpcty Capacity EFP ExchangeForPhysical
Capt Capture Exct Execute
Csh Cash Exctn Execution
Cl Client Exr Exercise
Cls Close Fctr Factor
Coll Collateral Feed Feed
Comm Commission Force Force
Cmn Common FX Foreign Currency
Comp Company Fwd Forward
Cnfm Confirmation Fut Future
Confirm Confirmation GTD Good Till Date
Cntra Contra Grp Group
Ctrl Control Hndl Handling

ID Identifier
Implct Implicit
Incr Increment
Ndx Index
IOI Indication of Interest
Ind Indicator
Info Information
Inpt Input
Inq Inquiry
Instn Institution
Inst Instruction
Instrmt Instrument
Int Interest
Iss Issue
Issr Issuer
Lmt Limit
Lqdty Liquidity
List List
Loc Locate
Lctn Location
Lot Lot
Mnt Maintenance
Mgn Margin
Mkt Market
Mass Mass`
Mtch Match
Mat Maturity
Max Maximum
Msg Message
Meth Method
Min Minimum
Misc Miscellaneous
Model Model
Mod Modification
Mny Money
Mo Month
Mleg Multileg
Nst Nested
Ntwk Network
Notifctn Notification
Num Number - multiple reports,
counts


No Number - NumInGroup fields Rstctn Restriction

Oblig Obligation Rstctns Restrictions
Ofr Offer Rslt Result
Opt Option R Roles
Ord Order Rnd Round
Orig Original Rules Rules
Oth Other Scnd Secondary
Pty Party Sec Security
Pmt Payment Seg Segment
Pct Percent Snd Sender
Pctg Percentage Sndg Sending
Pos Position Seq Sequence
Psbl Possible Svc Service
Prlm Preliminary Ses Session
Prev Previous Settl Settlement
Px Price Shrt Short
Pri Priority Sz Size
Prtztn Priotization Src Source
Prod Product Stand Standing
Pub Publish Start Start
Qual Qualifier St State
Qlty Quality Stat Status
Qty Quantity Stip Stipulation
Quot Quote Strk Strike
Rng Range Sub Subscription
Rt Rate Subsid Subsidiary
Rtng Rating Sfx Suffix
Rsn Reason Sym Symbol
Red Redemption Sys System
Ref Reference Tgt Target
Rgst Registration Trm Term
Rgstry Registry Tick Tick
Rej Reject Tkt Ticket
Reltd Related Tm Time
Rpt Report TS Timestamp
Rpts Reports Tot Total
Repo Repurchase Trkng Tracking
Req Request Trd Trade
Reset Reset Trdg Trading
Rsp Response TrdgSes TradingSession
Rstmt Restatement Txn Transaction
Rstct Restrict Typ Type

Und Underlying Vol Volume

Upd Update Yr Year
Val Valuation Yld Yield
Valu Value

Fix-5.0 SP1 Vol-1

Uploaded by

Copyright:

Available Formats

Fix-5.0 SP1 Vol-1

Uploaded by

Document Information

Original Title

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

Fix-5.0 SP1 Vol-1

Uploaded by

Copyright:

Available Formats

FINANCIAL INFORMATION

Version 5.0 Service Pack 1

VOLUME 1 – INTRODUCTION TO THE FIX PROTOCOL

Copyright, 2007-2008, FIX Protocol, Limited

THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE

© Copyright 2003-2008 FIX Protocol Limited, all rights reserved

Copyright, 2007-2008, FIX Protocol, Limited Page 2 of 144

discussion, and notification of FIX-related events.

FIX Protocol Ltd March 2008

Copyright, 2007-2008, FIX Protocol, Limited Page 3 of 144

About FIX Protocol Limited

FIX Protocol Limited is represented by the following high-level organization structure:

Global Steering Committee

Global Education & Marketing

• Global Steering Committee comprised of the FPL Committee Chairs

For a current list of active FPL Working Groups, visit:

Links to Product and Regional Committees' web pages are at:

Copyright, 2007-2008, FIX Protocol, Limited Page 4 of 144

VOLUME 2 - TRANSPORT PROTOCOLS

VOLUME 3 -FIX APPLICATION MESSAGES: PRE-TRADE

VOLUME 4 -FIX APPLICATION MESSAGES: ORDERS AND EXECUTIONS (TRADE)

CATEGORY: SINGLE/GENERAL ORDER HANDLING

Copyright, 2007-2008, FIX Protocol, Limited Page 5 of 144

VOLUME 5 - FIX APPLICATION MESSAGES: POST-TRADE

CATEGORY: ALLOCATION AND READY-TO-BOOK

VOLUME 6 - FIX DATA DICTIONARY

VOLUME 7 - FIX USAGE NOTES

PRODUCT: COLLECTIVE INVESTMENT VEHICLES (CIV)

Copyright, 2007-2008, FIX Protocol, Limited Page 6 of 144

ABOUT FIX PROTOCOL LIMITED.......................................................................................................................4

OVERVIEW OF MAJOR CHANGES IN FIX 5.0...................................................................................................8

FIX PROTOCOL SYNTAX......................................................................................................................................12

COMMON COMPONENTS OF APPLICATION MESSAGES - COMPONENT BLOCKS (INCLUDED IN

COMMON APPLICATION MESSAGES (APPLY TO PRE-TRADE, TRADE, AND POST-TRADE).......99

APPENDIX 1-A: ABBREVIATIONS USED WITHIN FIXML........................................................................140

Copyright, 2007-2008, FIX Protocol, Limited Page 7 of 144

FINANCIAL INFORMATION EXCHANGE PROTOCOL

OVERVIEW OF MAJOR CHANGES IN FIX 5.0

Copyright, 2007-2008, FIX Protocol, Limited Page 8 of 144

Transport Independence (TI) Framework

Copyright, 2007-2008, FIX Protocol, Limited Page 9 of 144

Extension Base Release Extension

Service Pack Mangement

Extension Pack Mangement

Copyright, 2007-2008, FIX Protocol, Limited Page 10 of 144

Flexibility Provided by FIX 5.0

versions). A BeginString=FIX.5.0 (or later versions) will not be valid.

FIX Application Layer

ApplVerID = FIX.4.1 FIX.4.1

FIX Session Layer

FIX Application Layer

1 TT The value FIX.5.0 will be represented using enumeration 7

Copyright, 2007-2008, FIX Protocol, Limited Page 11 of 144

FIX PROTOCOL SYNTAX

COMMON FIX SYNTAX RULES

Copyright, 2007-2008, FIX Protocol, Limited Page 12 of 144

prices for options strategies can be negative under certain market

Copyright, 2007-2008, FIX Protocol, Limited Page 13 of 144

00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating