FIX Messages

FIX Antenna .NET Programmer's Guide

FIX Message is a portion of data formatted according to the FIX Protocol standards.

FixAntenna.NET library allows developers to abstract away from the complexity of different formats specifications. This section is provided for informing you only and is not required to start developing applications with FixAntenna.NET.

FIX Protocol Syntax

The FIX Protocol currently supports two syntaxes:

  1. "Tag=Value" syntax. Tag=Value pairs are separated with hex: 0x01 character
  2. FIXML syntax, where Tags and Values are attributes and values of XML file accordingly

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.

Tag=Value (Raw) FIX 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.

Field Delimiter

All fields (including those of data type data i.e. 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 end with "10=nnn<SOH>". There shall be no embedded delimiter characters within fields except for data type data.

Sample Fix Message Using Tag=Value Syntax

Here is a sample raw FIX Message

raw_FIX
8=FIX.4.2<SOH>9=153<SOH>35=D<SOH>49=BLP<SOH>56=SCHB<SOH>34=1<SOH>50=30737<SOH>97=Y<SOH>
52=20000809-20:20:50<SOH>11=90001008<SOH>1=10030003<SOH>21=2<SOH>55=TESTA<SOH>54=1<SOH>38=4000<SOH>
40=2<SOH>59=0<SOH>44=30<SOH>47=I<SOH>60=20000809-18:20:32<SOH>10=061<SOH>

More samples of raw FIX messages can be found on FixProtocol TechResources

Message Structure

Each message consists of a stream of <tag>=<value> fields with a field delimiter between fields in the stream. Tags are numerical. 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. 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.
  6. 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 MultipleValueString data type 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').

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).

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.

Fix Message with repeating groups

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, 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

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 communication. 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.

Component Blocks

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 Note

Note that some component blocks may be a part of repeating groups, thus if the component block is denoted as a part of a repeating group, the entire group of fields representing the component block is to be specified at the component block's repeating group "level" in the message definition and follow the repeating group rules concerning field order. See "Repeating Groups" for more details.

FIXML FIX Message Format

FIXML is an XML-based standard. The structure of XML is defined by DTD schemas that can be downloaded from the Fix Protocol web site

We will not describe FIXML format in detail, a minute overview of it can be found in this PDF document

Here is a sample Fix Message constructed using FIXML (version 4.4) syntax

XML
<FIXML>
   <Order ID="123456" Side="2" TxnTm="2001-09-11T09:30:47-05:00" Typ="2" Px="93.25" Acct="26522154">
     <Hdr Snt="2001-09-11T09:30:47-05:00" PosDup="N" PosRsnd="N" SeqNum="521" SID="AFUNDMGR" TID="ABROKER"/>
     <Instrmt Sym="IBM" ID="459200101" Src="1"/>
     <OrdQty Qty="1000"/>
   </Order>
</FIXML>
Note Note

Currently, FIXML format is not supported by FixAntenna.NET.

See Also

Other Resources