FIX Messages

This section provides an overview of the FIX Message structure, its formation and processing.

• Important terms
• General guidelines for building FIX Messages
• Repeating Groups in FIX Messages
• FAQ

Important terms:

• FIX session: A FIX session is a bi-directional stream of ordered messages between two parties and in the FIX Protocol specified format.
• Field tag: A FIX Message is a sequence of the FIX Protocol defined as well as custom fields and their values. To reduce the size of a message, the FIX Protocol enumerates these fields with positive integers called tags. For example, tag 35 stands for the field MsgType.
• Enumerated field: Wherever relevant, the FIX Protocol enumerates field values of certain fields and provides their description. Such fields are referred to as enumerated fields. For example, the field Scope at tag 546 is enumerated with 1, 2 and 3 as valid values. The descriptions of these values are 1= Local Market, 2 = National and 3 = Global.
• FIX Message syntax: A FIX Message is a sequence of fields and their values in the <tag>=<value><delimiter> format. For example, 35=6 represents the message type 6 (Indication of Interest message).
• Delimiter: The FIX Protocol uses the <SOH> character as the delimiter to separate the tag=value pairs. It is a non printable ASCII character with code 0x01. For convenience and readability, the illustrations in FF.FIX Engine Knowledgebase represent the <SOH> character by '|'. For example, 35=6|.
• FIX Message blocks: A FIX Message is a sequence of three blocks: Header, Body and Trailer.

  There are no special indicators to indicate the beginning and end of these blocks. The FIX Protocol treats the occurrence of the first Body field as the beginning of the message Body. Similarly, the occurrence of the first Trailer field marks the beginning of the message Trailer.

  The Body contents are different in different message types. The Header and Trailer contents are similar for messages across all message types.
  

  

• FIXimate: FIXimate on the FIX Protocol Website is the standard repository for a quick reference to the list of:
  • FIX Protocol specified message types.
  • FIX Protocol specified fields list including their names, tag numbers, data types and enumerated values.
  • The required (mandatory) and optional fields in the standard message Header.
  • The required (mandatory) and optional fields in the standard message Trailer.
  • The required (mandatory) and optional fields that can occur in each FIX Protocol defines message type.
  The FIXimate provides these details separately for different FIX Protocol versions.
• Custom fields: The FIX Protocol reserves tag numbers from 5000 to 9999 for custom (user-defined) fields. Parties to a FIX session mutually agree to use these fields in their inter-firm communication. The FIX Protocol lets you register or reserve these tags via the FIX Protocol Website. The FIX Protocol reserves tag numbers from 10000 onwards for internal use (within a single firm). You need not register or reserve these tags via the FIX Protocol Website.
• Custom message types: By mutual agreement, you and your counterparty can define custom messages types and specify their Body contents. To implement custom message types, you must define them in your counterparty-specific FIX Data Dictionary.
• Customized messages: By mutual agreement, you and your counterparty can modify the list of fields and field enumerations allowed in a standard FIX message type. Such modified message is referred to as a customized message.
  

  To implement customized messages, you must define them in your counterparty-specific FIX Data Dictionary.

• Standard Header: A Header is the first block of each FIX Message and it identifies the message type, message length, sender, destination, sequence number and sending time etc. The FIX Protocol provides the list of standard Header fields on the FIXimate. You may add your custom fields to this list and also set the Header fields as required or optional depending on your requirements. However, the FIX Protocol defines seven Header fields as required (mandatory) in all messages, as listed in the following table:
  
  

  Field Tag	Field Name	Required	Description
  8	BeginString	Y	Always the first field in a FIX Message. Specifies the FIX Protocol version.
  9	BodyLength	Y	Always the second field in a FIX Message. Specifies the message length in bytes. The CheckSum (tag 10) value is based on this field.
  35	MsgType	Y	Always the third field in a FIX Message. Defines the message type.
  49	SenderCompID	Y	The ID for identifying the message sending party.
  56	TargetCompID	Y	The ID for identifying the message receiving party.
  34	MsgSeqNum	Y	A positive integer that specifies the message sequence number.
  52	SendingTime	Y	The UTC time at the time of sending the message.

  
  
• Standard Trailer: A Trailer is the last block of each FIX Message. The following table lists the FIX Protocol defined (standard) Trailer fields:
  
  

  Field Tag	Field Name	Required	Description
  10	CheckSum	Y	Always the last field in a FIX Message. Takes three bytes.
  93	SignatureLength	C	Required conditionally, only when the Trailer contains the Signature field. Represents the number of bytes in the Signature field.
  89	Signature	N	Electronic signature.

  
  
• Inbound and outbound sequence numbers: For detecting messages missed during a FIX session, each party to the session assigns an ordinal number (in a natural number sequence) to each of its Outbound Messages and includes it at the tag 34 of the message Header. This number becomes the outbound sequence number for the sender party and inbound sequence number for receiving party.
• Raw Message: The message string in the <tag>=<value><delimiter> format is referred to as the Raw Message. A Raw Message string is not in human readable format. FF.FIX Engine includes a supplementary tool FF.FIX Analyzer. It presents message strings in a human readable format and brings out their business meaning.

General guidelines for building FIX Messages

1. In all messages, tags 8, 9 and 35 are always the first, second and the third fields respectively. FF.FIX Engine arranges them in the required sequence.
2. Tag 10 is always the last field of a message. FF.FIX Engine internally sets this field as the last field in a message.
3. A standard Trailer contains either the tag 10 (CheckSum) or a set of tags 93 (SignatureLength), 89 (Signature) and 10. It cannot have any other fields.
4. Header, Body and Trailer parts of a message must appear in order in any Raw Message.
5. FF.FIX Engine inserts a <SOH> character after each tag=value pair. You need not include it separately in the value string.
6. Each tag in a message must have a value. Hence, an optional field tag can occur in the message string only if it is assigned some value.
7. No field tag can repeat in a Raw Message unless it is a part of some Repeating Group.
8. The order of field tags in the message Body is immaterial, unless the field is:
   • A NumInGroup type field: Such field must immediately precede the first of the Repeating Groups under it.
   • A part of a Repeating Group: All Repeating Groups under a specific NumInGroup type field must have the same fields and in the same order.
   • A Length type field: All Length type fields must precede their associated Data type fields. You need not set these fields manually. FF.FIX Engine internally generates a Length type field and assigns it a value based on the value of the Data type field you set.
9. Do not set values of CheckSum (tag 10) and BodyLength (tag 9) fields. FF.FIX Engine internally sets them while generating the Raw Message based on other field values that you set.
10. Do not set a value for the SendingTime (tag 52) field. FF.FIX Engine internally assigns this value while sending the message to the counterparty.

Repeating Groups

To avoid conflicts in a field value, the FIX Protocol does not allow a tag number to repeat in a message. Fields in Repeating Groups of fields are the only exception to this rule. Since each Repeating Group is a separate unit of information the repetition of fields is valid in repeating Groups. The FIX Protocol also allows nested Repeating Groups.

For example, the data type of the NoNestedPartyIDs field (tag 539) is NumInGroup. The tags 524, 525 and 538 can repeat under it as specified below:

Tag Number		Field Name	Required	Description
539 (Repeating Group Level 1)		NoNestedPartyIDs	N	If set as (Y), Repeating Groups of tag=value pairs for tags 524, 525 and 538 respectively must follow it.
	524	NestedPartyID	C	Required if tag 539 is present.
	525	NestedPartyIDSource	C	Required if Tag 539 is present
	538	NestedPartyRole	C	Required if Tag 539 is present

Using above specifications, the following portion of a Raw Message is valid:

… … 539=2|524=XYZ|525=B|538=R5|524=PQR|525=C|538=R4|… …

It means:

::FAQ::

1. What functionalities does the FixMessage class provide?
2. How do I create a FIX Message?
3. How do I set fields in different parts of a FIX Message?
4. Which overloaded SetField methods are available for setting fields and their values in a FIX Message?
5. How do I extract a Raw Message string from the FixMessage object structure?
6. How do I set a Data type field in the FIX Message structure?
7. What is the difference between SetField and AddField methods?
8. How do I extract a particular field from a FIX Message?
9. How do I set a Repeating Group of fields in a message?
10. How do I read Repeating Groups of fields from a FIX Message?
11. How do I validate the FIX field values for their data types?
12. How do I validate the FIX field values contained in a FIX Message?
13. How do I iterate through each field in a FIX Message structure container?
14. How do I iterate through each field in a FIX Message structure container containing a repeating group?
15. How do I get the current CheckSum and BodyLength from my FixMessage object?
16. How do I set an encoded field in Unicode (UTF8) Encoded format?
17. How do I suppress a specific field present in the FIX Message object structure from appearing in the Raw Message generated from it?

The FixMessage class in the FF.Fix.Core.Message namespace offers an object oriented abstraction of the FIX Message structure. It defines the logical structure of a FIX Message and provides methods and properties to access and manipulate the field information in the message. Using these methods and properties, you can perform tasks like setting fields, extracting fields, extracting a FIX Message as a string or byte array etc.

The FixMessageTypes class defines all standard FIX Message types. After creating a FixMessage object, you can add different fields and their values to the Header, Body and Trailer of the message.

For example:

The code to create a FixMessage instance of message type D based on the FIX Protocol version 4.2 is:

The code to create a custom message of type U9 for sending to the counterparty that follows FIX Protocol version 4.4, the code is:

The FixFieldTag class includes all FIX Protocol defined fields along with their tag numbers. You can select required fields from this class and assign values to them. The following code snippets show setting of fields in different parts of a FIX Message and in different ways.

Setting Header fields

The FixFieldTag class is useful to confirm the correctness of the field name and its tag number because it contains the field list in the <FieldName>_<FieldTag> format. However, it is not necessary to use this class every time. Custom fields do not appear in the FixFieldTag class. Hence FF.FIX Engine lets you set custom or FIX fields directly using their tag numbers and values, as demonstrated below:

Setting Body fields

The second and third examples show that FF.FIX Engine treats the fields as Body fields, unless explicitly mentioned as Header or Trailer fields. Since the Header and Trailer fields are common to all messages, FF.FIX Engine lets users concentrate on their business logic in the message Body and treat the fields as Body fields by default while setting them.

The second and third examples also demonstrate that it is possible to set a field using the strings, even if their data types are different. This is because the FIX Message string includes the tag values in a string format only.

Setting Trailer fields
You never need to set any Trailer field, unless you decide to use the optional field Signature (tag 89). The code to set the Signature field value to ABCL is:

FF.FIX Engine provides different SetField methods with several overloads to deal with different requirements. The following table lists and demonstrates them:

A Raw Message string is a FIX Message expressed in a string format. You can extract the Raw Message from a FixMessage object structure using the ToString() or ToArray() functions.
For example:

The first parameter value (1) states the sequence number of the message to be extracted. The second parameter value (true) is a flag indicating that SendingTime (tag 52) field value should contain the milliseconds part.

The output at the console will appear as follows:

A Data type field value is merely a string. If it contains <SOH> character(s), it can result into errors in tag value identification and parsing errors. This is because the occurrence of <SOH> character is considered as the beginning of a new tag=value pair in a FIX Message string.

The FIX Protocol removes this difficulty using a Length type field that precedes each Data type field. The Length type field provides the length of data string in the value of the Data type field.

FF.FIX Engine relieves you from setting the Length type fields separately. Whenever you set a Data type field using SetDataField methods, FF.FIX Engine internally calculates the length of the data string and sets the associated Length type field.

There are two SetDataField methods:
void SetDataField(int fieldTag, string fldValue)
void SetDataField(int fieldTag, byte[] fldValue)

For setting encoded Data type fields, FF.FIX Engine offers a special method:
void SetEncodedDataField(eMessageEncoding messageEncoding, int fieldTag, string fldValue)

The parameters in above methods are:

• fieldTag: Represents the field tag (positive integer).
  fldValue: Represents the corresponding tag value in string or byte array format.
• eMessageEncoding: Represents the encoding format for the Data type field value. FF.FIX Engine supports the following encoding types:
  • JIS           //ISO-2022-JP
  • EUC        //EUC-JP
  • SJIS        //Shift_JIS
  • Unicode  //UTF-8

See the following examples of Data type field setting:

Example 1:

Internally, this code creates a tag=value pair for two fields as follows:

354=11<SOH>355=Hello World<SOH>

Note that the value 11 of the Length type field at tag 354 represents that the string length of the Data type field at tag 355 is 11 bytes.

Example 2:

Internally, the above code creates two fields (tag 354 and tag 355) with their respective values. The value of tag 354 is the string length of the Data type field. The code also demonstrates that it is possible to assign a byte array to a Data type field.

Example 3:
To set the RawData (tag 96) field to the value Hello|World and to set the Signature field (tag 89) to FFFIX in encoded form, the code is as follows:

The output is:

Observe the internally set fields (tag 95 and tag 93) and their values.

AddField and SetField methods perform similar tasks and take similar parameter list. However, the AddField methods throw an exception if the field you are setting already exists in the FixMessage structure. The SetField methods always overwrite the field value in case it is already present.

The FixMessage class provides the following GetField methods to retrieve a tag value from the FixMessage structure:

Example 1:

A fixMessage object of FixMessage class has PossDupFlag (tag 43) set to value Y. Tag 43 is the Header field.

The above code produces FixFieldNotFound exception as the tag 43 is searched in the Body part of the message, where it is not present.

The above code returns the string "Y" as the tag 43 is searched in the Header part of the message, where the field actually exists with the value Y.

Example 2:

The above code returns the SenderCompID field (tag 49) value from the Header of the message as a string, using and without using the FixFieldTag class.

Example 3:

The above code returns the value of SecureData field (tag 91) from the Header in the byte array format.

Example 4:

If you wish to get a field value from the message Body, you need not use .Body explicitly in the code. You can directly access Body fields from the fixMessage object.

Example 5:

The above code returns the value of the Quantity field (tag 53) from the Body of the message in the integer format. The GetFieldAsInt method (and other methods too) operates on FIX Message Body part, if you do not explicitly use .Header, .Body or .Trailer after fixMessage in the code.

Example 6:

The above code returns the value of the CheckSum field (tag 10) from the Trailer of the message in the integer format.

Repeating Groups allow record structures within a FIX Message. The first record structure is preceded by a Repeating Group field which specifies the number of record structures that follow it.

For example: See the FIX Message portion given below:

268=2|79=0|69=3|5=GBP/CHF|70=0|71=4|79=0|69=3|5= EUR/GBP|70=0|71=5|

Its analysis is provided below:

The code for creating Repeating Groups in above example is:

You may check the output of above code as follows:

The output at the console would be:

Consider a FIX Message string:

The code to extract the repeating groups from it is demonstrated below:

The output would be as follows:

General SetField methods do not validate values you assign to a field against the data type of the field.

For example, you may assign a float value 1000.2 to the PossDupFlag field (tag 43) as follows:

This code is valid and it sets 43=1000.2 without any error or warning, though it is erroneous because the PossDupFlag field has boolean data type.

FF.FIX Engine provides a secure way to avoid invalid data type assignments using objects of the FixFieldValue class. This class includes many structures, each relating a separate data type. The names for these structures are in the Fix<DataType>Field format. For example: FixIntField, FixPriceField, FixDataField etc.

While creating an object of FixFieldValue class, the system verifies the data type of the field value assigned by you and throws an exception if you assigned a value having incorrect data type.

After you create a valid object of FixFieldValue class, you can use it to set a field in the FIX Message using the SetField(FixFieldValue fixFieldValue) method.

For example:

You wish to set 44=99.33 and 158=0.50 securely, without any data type mismatch. Tag 44 belongs to the data type Price. Tag 158 belongs to the data type Percentage. The required code is:

FF.FIX Engine enables you to validate fields in a FIX Message on the basis of standard FIX specifications as well as FIX dialects. FIX dialects are the non-standard (customized) implementations of the FIX Protocol. You can implement different FIX dialects using different FIX Data Dictionaries. The FixDialect class provides access to different FIX dialects as well as standard FIX versions. For example:

• To use the standard FIX 4.4 version for field validations, you can use the eFixVersion based constructor for creating the fixDialect object.

  FixDialect fixDialect = new FixDialect(eFixVersion.FIX44);

• To use a custom FIX Data Dictionary (FIX dialect) for field validations, you can specify it as given below while creating the fixDialect object.

  FixDialect fixDialect = new FixDialect(“D:\ABC_FIXDataDictionary.xml);

FIX field validation requires information about the field data types from the FIX Data Dictionary. After accessing the FIX Data Dictionary through the fixDialect object, the sample code to validate fields in the FIX Message Body would be:

The FixDataValidator class provides several methods to validate the FIX field contents against its data type.

The following code provides an example:

The following code provides an example:

The following code provides an example:

The following code provides an example:

The following code provides an example:

The output is as follows. Observe the suppression of field at tag 55 in the second string.