PREFACE

The Financial Information eXchange (FIX®) Protocol 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 counterparties.
  • 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 buy-side to sell-side 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 (GTC) Chairpersons (see http://www.fixtrading.org/groups/gtc/). The FIX website at http://www.fixtrading.org is the main source of information, discussion, and notification of FIX-related events.

We look forward to your participation.

FIX Protocol Ltd January 2020

ABOUT FIX PROTOCOL LIMITED

FIX Protocol Limited (FPL) oversees and manages the development of the FIX 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.fixtrading.org.

FIX Trading Community™ is a brand of FIX Protocol Ltd, a non-profit UK registered entity, originally created to own, maintain and develop the FIX Protocol messaging language.

FIX® is embedded into the fabric of the financial trading community, used by thousands of firms every day to complete millions of transactions in a cost-efficient and effective manner.

FIX has been created and continues to be developed through collaborative industry efforts with the intention that it remains as a non-proprietary, free and open protocol. Maintaining this position is of utmost importance, as the cost to the industry of a fee based alternative would prove incredibly expensive.

To ensure this status is protected, FIX Protocol Ltd is managed under a special “Purpose Trust” which owns the assets and enables the organisation to concentrate on promoting protocol adoption without undue risk or exposure. An effort that is further supported by legal protection afforded through the fees paid by member firms.

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

  • Global Steering Committee comprised of the FPL Global Committee Chairs
  • Global Technical Committee comprised of Product/Region Committee Representatives
  • Global Product Committees (Fixed Income & Currencies, Listed Products & Exchanges)
  • Global Buy-Side Committee
  • Global Member Services Committee
  • Regional Committees (Americas, Asia Pacific, EMEA, Japan)

For a current list of FPL Member firms, visit http://www.fixtrading.org/member-firms/.

For a current list of active FPL Working Groups, visit http://www.fixtrading.org/working-groups/.

Links to Product and Regional Committees’ web pages are at http://www.fixtrading.org/committees/.

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 FIX Family of Standards addresses the different needs of the application, encoding and session level. Whilst there is basically a single standard called FIX Latest for the application level defining business related data content, FIX offers a number of choices for the encoding of messages as well as for the session level, i.e. the technical interaction between counterparties to deliver data. There is a second standard for the application level called FIXatdl which is an XML based standard to specify the user interface components for algorithmic trading.

Specifications for the encoding (aka syntax) and the session level are called Technical Standards and have their own name and version together with their own documentation. FIX also supports industry standards such as Google Protocol Buffers (GPB) for encoding and Advanced Message Queuing Protocol (AMQP) for the session protocol. This document is only about FIX Latest, i.e. the application level.

The following table shows a comprehensive list of the FIX Family of Standards followed by a diagram of the FIX Technical Standard Stack:

StandardAcronymLayerDescription
FIX LatestnoneApplicationThe most current version of FIX that supports multiple asset classes and a wide range of trading life cycle business processes. It includes all FIX Extension Packs.
FIX Algorithmic Trading Definition LanguageFIXatdlApplicationXML based standard to specify the user interface components for algorithmic trading.
FIX tag=valuetagvalueEncodingOriginal FIX encoding and the most widely used one. A simple ASCII string format.
FIX Markup LanguageFIXMLEncodingXML encoding used within FIX. FIXML is widely adopted for derivatives post trade clearing and settlement globally. FIXML is also used for reporting.
FIX Adapted for STreamingFASTEncodingProtocol designed to reduce bandwidth use and latency for market data dissemination.
Simple Binary EncodingSBEEncodingHigh performance binary encoding in use within the industry for market data dissemination as well as for transactional workflows.
Encoding FIX using Google Protocol BuffersGPBEncodingFIX encoding using industry standard protocol GPB. Often used within companies as part of internal messaging.
Encoding FIX using Javascript Object NotationJSONEncodingFIX encoding using industry standard protocol JSON. Intended for both internal processing and the use of FIX application messages within web based applications and APIs.
Encoding FIX using Abstract Syntax NotationASN.1EncodingFIX encoding using industry standard protocol ASN.1. ISO standard encoding system that includes multiple encodings itself (BER, OER, PER, XER).
FIX Session ProtocolFIX4SessionOriginal FIX session protocol and the most widely adopted one. Session protocol for FIX 4.2 and FIX 4.4.
FIX TransportFIXTSessionApplication version independent session protocol introduced with FIX 5.0 and used in conjunction with FIX Latest.
FIX High Performance Session ProtocolFIXPSessionHigh performance session protocol for point-to-point and multicast that supports multiple modes of operation (recoverable, unsequenced, idempotent).
FIX Simple Open Framing HeaderSOFHSessionSimple and primitive message framing header that communicates two pieces of information, the length of a message and the encoding type of that message.
FIX-over-TLSFIXSSessionStandard to secure FIX sessions using the industry standard Transport Layer Security (TLS) protocol.

ORGANIZATION OF SPECIFICATION

The FIX Latest Specification is organized into multiple areas (aka sections), with each area covering specific categories followed by an appendix with detailed component and message layouts. The area titles are directly linked to the appropriate websites as part of the FIX Online Specification.

Message and Component Definitions

All areas contain definitions of FIX components and application messages. Components are sets of related data fields grouped together and are referenced by the component name in messages that they are used in. FIX components are organized as follows:

  • Globally Common Components – are components commonly used by many messages defined across all areas of the FIX specification. These are the most commonly used components. Their definitions are found in the “Introduction to FIX”.
  • Common Components – are area- or section-specific components, i.e. these are components commonly used only by the FIX messages found in that area or section (e.g. pre-trade, trade, post-trade sections). Their definitions are found at the end of the appendix of the area-specific documentation.
  • Specific Components – are message category specific components, i.e. these are components that are used only by the FIX messages in a specific message category in a given area (e.g. Securities Reference Data message category). Their definitions are found in the appendix of the area-specific documentation in their respective message category.
  • Messages are described as part of the category description. Additionally, the detailed message layouts are found in the appendix of the area-specific documentation in their respective message category.
  • Messages are 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.
  • Messages and components may have nested fields and components as part of repeating groups. The tag number (name) of a nested field (component) is prefixed with an arrow “→”.

Extension Pack Management

Extension Packs are the building blocks of FIX Latest and represent specific functional proposals that have been presented to and approved by the GTC. Extension Packs are applied to the repository in a cumulative manner, i.e. the latest Extension Pack always includes all previous Extension Packs. 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 point an Extension Pack has been applied, the updated repository, schema, and message tables will be publicly available.
  4. When implementing a specific Extension Pack, ApplExtID(1156) can be used to specify the Extension Pack identifier, i.e. its number.
  5. Users of an Extension Pack do not need to implement it in its entirety and do not need to implement other Extension Packs present in the repository. Rules of engagement need to be bilaterally agreed on to define the supported subset of FIX Latest.

FIX PROTOCOL DATA TYPES

The mapping of data types to a wire format (e.g. ASCII, binary) depends on the chosen encoding. FIX supports a number of different encodings (see above) so that this section only describes their semantic. The specification for each of the Technical Standards for encoding defines the actual mappings. Note that some of the binary encodings allow the usage of a more efficient data type as long as its values are a subset of the base type shown below. For example String fields may be limited to whole numbers in case of entity identifiers by using an int data type instead. An int field, however, must never be changed to a String field as this would allow additional values not covered by the semantic of the data type.

Data Types

Data TypeBase TypeDescription
intintWhole numbers. Value can be positive (unsigned) or negative (signed).
  LengthintLength in bytes. Value must be positive.
  TagNumintTag number of a field when using FIX tagvalue encoding. Value must be positive.
  SeqNumintMessage sequence number. Value must be positive.
  NumInGroupintNumber of entries in a repeating group. Value must be positive.
  DayOfMonthintDay during a particular month. Value range from 1 to 31.
floatfloatFloating-point number. Value can be positive (unsigned) or negative (signed). The number of decimal places (precision) used should be a factor of business/market needs and mutual agreement between counterparties.
  QtyfloatNumber of units. Whole number (securities denominated in whole units, e.g. shares) or floating-point number (securities denominated in fractional units).
  PricefloatPrice of a unit. Value can be positive (unsigned) or negative (signed). For example, prices for options strategies can be negative under certain market conditions.
  PriceOffsetfloatPrice offset, which can be mathematically added to a field with data type “Price”. Value can be positive (unsigned) or negative (signed).
  AmtfloatAmount (value in monetary terms). Typically a field with data type “Price” times a field with data type “Qty”
  PercentagefloatPercentage as a fractional number (e.g. 0.05 represents 5% and 0.9525 represents 95.25%).
charcharSingle character value, can include any alphanumeric character or punctuation (except for a character used as a delimiter by the given encoding). All char fields are case sensitive (i.e. m != M).
  BooleancharCharacter field containing one of two values: ‘Y’ = True/Yes or ‘N’ = False/No
StringStringAlpha-numeric free format text, can include any character or punctuation (except for a character used as a delimiter by the given encoding). All String fields are case sensitive (i.e. morstatt != Morstatt).
  MultipleCharValueStringData type for string fields containing one or more space delimited single character values (e.g. “2 A F”).
  MultipleStringValueStringData type for string fields containing one or more space delimited multiple character values (e.g. “AV AN A”).
  CountryStringString data type representing a country using ISO 3166 Country code (2 character and uppercase) values.
  CurrencyStringString data type representing a currency type using ISO 4217 Currency code (3 character) values.
  ExchangeStringString data type representing a market or exchange using ISO 10383 Market Identifier Code (MIC) values.
  MonthYearStringString data type representing month of a year. An optional day of the month or an optional week code can be appended. Valid formats: YYYYMM or YYYYMMDD or YYYYMMWW. Valid values: YYYY = 0000-9999; MM = 01-12; DD = 01-31; WW = w1, w2, w3, w4, w5.
  UTCTimestampStringString data type representing time/date combination in UTC (Universal Time Coordinated, also known as “GMT”) in YYYYMMDD-HH:MM:SS.sss* format whereby “sss*” represents any precision bilaterally agreed upon. Colons, dash, and period required for a mapping to tag=value syntax. 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), sss* = 000*-999* (e.g. ssssss = 000000-999999 for microseconds). See below for examples and details on leap seconds.
  UTCTimeOnlyStringString data type representing time-only in UTC (Universal Time Coordinated, also known as “GMT”) in HH:MM:SS.sss* format whereby “sss*” represents any precision bilaterally agreed upon. Colons and period required for a mapping to tag=value syntax. This special-purpose field is paired with data type UTCDateOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss* = 000*-999* (e.g. ssssss = 000000-999999 for microseconds).
  UTCDateOnlyStringString data type representing date represented in UTC (Universal Time Coordinated, also known as “GMT”) in YYYYMMDD format. This special-purpose field is paired with data type UTCTimeOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31.
  LocalMktDateStringString data type representing a date of the local market (as opposed to UTC) in YYYYMMDD format. This is the “normal” date data type used by the FIX Protocol. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31.
  TZTimeOnlyStringString data type 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. See below for examples.
  TZTimestampStringString data type 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. See below for examples.
  dataStringData type for string fields containing raw data with no format or content restrictions. This requires different handling depending on the encoding used. For example, in tagvalue syntax, such fields are always immediately preceded by a separate field of data type “Length”. Please see the Technical Standard specification of the given encoding for details.
  XMLdataStringData type for string fields containing an XML document with no format or content restrictions. This requires different handling depending on the encoding used. For example, in tagvalue syntax, such fields are always immediately preceded by a separate field of data type “Length”. Please see the Technical Standard specification of the given encoding for details.
  LanguageStringIdentifier for a national language using ISO 639-1 (2 character and lowercase) language code.
PatternPatternUsed 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).
  TenorPatternUsed 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. See below for details of tenor data type.
  Reserved100PlusPatternValues “100” and above are reserved for bilaterally agreed upon user defined enumerations.
  Reserved1000PlusPatternValues “1000” and above are reserved for bilaterally agreed upon user defined enumerations.
  Reserved4000PlusPatternValues “4000” and above are reserved for bilaterally agreed upon user defined enumerations.

UTC and 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 December 31 or June 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 in tagvalue syntax may read “19981231-23:59:59”, “19981231-23:59:60”, “19990101-00:00:00” (see http://tycho.usno.navy.mil/leapsec.html).

Examples for Timestamp Data Types

All of the examples only apply to cases where tagvalue syntax is being used for the encoding.

Examples for data type UTCTimestamp

  • TransactTime(60)=“20011217-09:30:47.123” milliseconds
  • TransactTime(60)=“20011217-09:30:47.123456” microseconds
  • TransactTime(60)=“20011217-09:30:47.123456789” nanoseconds
  • TransactTime(60)=“20011217-09:30:47.123456789123” picoseconds

Examples for data type TZTimeOnly

  • 07:39Z is 07:39 UTC
  • 02:39-05 is five hours behind UTC, thus Eastern Time
  • 15:39+08 is eight hours ahead of UTC, Hong Kong/Singapore time
  • 13:09+05:30 is 5.5 hours ahead of UTC, India time

Examples for data type TZTimestamp

  • 20060901-07:39Z is 07:39 UTC on 1st of September 2006
  • 20060901-02:39-05 is five hours behind UTC, thus Eastern Time on 1st of September 2006
  • 20060901-15:39+08 is eight hours ahead of UTC, Hong Kong/Singapore time on 1st of September 2006
  • 20060901-13:09+05:30 is 5.5 hours ahead of UTC, India time on 1st of September 2006

Tenor Data Type

Definitions and examples for tenor data type:

  • 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

USER DEFINED FIELDS

In order to provide maximum flexibility for its users, the FIX Protocol accommodates User Defined Fields (UDFs). 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 UDFs 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 UDFs, which are used as part of inter-firm communication. These tags can be registered/reserved via the FIX website (https://www.fixtrading.org/standards/user-defined-fields/). At this time, the available tag numbers in the user defined range of 5000 to 9999 have all been allocated. In December 2009 the FIX GTC Governance Board approved the use of tag numbers in the 20000 to 39999 range for use as user defined tags to be used bilaterally between parties. These tags do not need to be registered. The FIX GTC Governance Board recommends that fields/tags and enumeration values from FIX Latest which meet the business or implementation of FIX be retro-fitted into the implementation.

The GTC’s policy with regards to UDFs is for the community, where possible, to use tags, components or repeating groups from the latest Extension Pack in their legacy FIX implementation when these meet the requirements, as opposed to customised extensions through user defined fields, components, or repeating groups.

UDFs in the range 8000-8499 are reserved for the FIX Global Technical Committee for the support of regulatory requirements in supported legacy versions of FIX. UDFs in the range 8500-8999 are currently reserved for work-in-progress in China.

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.