Home » Products » FF.FIX Engine » FF.FIX Engine Knowledgebase » FIX Data Dictionary

FIX Data Dictionary

About FIX Data Dictionary

While conceptualizing and planning the design for your FIX Initiator application, FIX Acceptor application or FIX-compliant programmatic components, you may come across several questions like:

  1. How do I build my FIX Initiator or Acceptor application or the application components when my counterparties follow different FIX Protocol versions and dialects?
  2. How do I implement custom fields in a standard or custom FIX Message type or in the standard Header, which is a requirement of one of my counterparties but not all?
  3. My counterparty requires me to support a message type that is not defined by the FIX Protocol. How do I implement it?
  4. All my counterparties support different sets of FIX Message types. Can my common code work across all counterparties?
  5. The lists of message types and fields in the FIX Protocol specifications are too big to implement. Very few message types and fields are relevant to my business. Can I implement the relevant fields and message types only?
  6. Without changing the code of my application, how do I implement minor updates, such as, support for new fields and message types in higher FIX Protocol versions, custom fields, custom message types, additional enumerated values of an existing field etc?
  7. How do I validate a FIX Message from one of my counterparty when there is no uniformity in FIX Message types and fields supported by different counterparties?

FF.FIX Engine relieves you from all these questions using the counterparty dependent FIX Data Dictionary approach. It is an XML file that contains the following mutually agreed information, by you and your counterparty:

  • FIX Protocol version.
  • List of message types to be allowed, including custom message types.
  • List of Header fields and their mandatory or optional nature.
  • List of Trailer fields and their mandatory or optional nature.
  • List of Body fields in each supported message type and their mandatory or optional nature.
  • List of all supported standard (FIX Protocol defined) and custom fields, including their tag numbers and data types.
  • List of fields that can appear under each supported NumInGroup type field (Repeating Group field).
  • List of standard (FIX Protocol defined) and custom enumerated values for each supported enumerated field.

Note:
FF.FIX Engine includes an easy to use FF.FIX ROE tool that lets a user quickly create, open, edit and save counterparty dependent Data Dictionary files in XML format. The knowledge of XML is not essential to use the FF.FIX ROE tool. FF.FIX ROE supports FIX.4.0, FIX.4.1, FIX.4.2, FIX.4.3, and FIX.4.4 versions of the FIX Protocol.

Later, even if you do not subscribe to higher versions of FF.FIX Engine or FF.FIX ROE, you can manually upgrade to support new message types, fields and enumerations from higher versions of the FIX Protocol just by editing the existing XML file in any text editor like Notepad. For details, refer to the FAQ on FIX Data Dictionary.

::FAQ::

  1. How does FF.FIX ROE help me in making my FF.FIX Engine based application customizable?
  2. What is the structure of a typical FIX Data Dictionary?
  3. How do I specify the FIX Protocol version in the FIX Data Dictionary?
  4. How do I implement the mandatory and optional Header fields agreed with my counterparty?
  5. How do I implement Trailer fields agreed with my counterparty?
  6. How do I implement different message types agreed with my counterparty, including the custom message types?
  7. How do I specify the Repeating Groups in a message?
  8. How do I implement the standard and custom FIX fields that my organization and the counterparty mutually agreed to use?
  9. How do I specify the description for enumerations of an enumerated field?
  10. How do I implement new message types and fields that my organization and the counterparty mutually agreed to use?
  11. I created a FIX Data Dictionary for my counterparty 'X'. How do I implement it in the FIX configuration file for that counterparty?
  12. How do I programmatically refer to a FIX Data Dictionary file in XML format and get an object structure from it?
  13. How do I programmatically extract a FixDataDictionaryField identified by a field name and get the information therein?
  14. How do I programmatically extract a FixDataDictionaryMessage object identified by a message name and get the information from it?
  1. How does FF.FIX ROE help me in making my FF.FIX Engine based application customizable?

Without modifying the code of your FF.FIX Engine based application, you can simply change Data Dictionaries and upgrade your application to support:

  • Custom enumerations, fields and message types.
  • New enumerations, fields and message types from an existing or future FIX Protocol versions.

FF.FIX ROE is a tool to create, open, edit and save counterparty dependent Data Dictionary files in XML format. The knowledge of XML is not essential to use FF.FIX ROE. You can update your Data Dictionary as required, define it in the FIX configuration file and customize your application without any code changes.
  1. What is the structure of a typical FIX Data Dictionary?

A typical FIX Data Dictionary appears as shown below. The first line is the usual information on XML version and schema. Other elements and attributes are discussed in details in further FAQ.

<?xml version="1.0" ?>
<!-- FF.FixDataDictionary -->
<fixDataDictionary version="FIX.4.2">

<!-- FIX Header Fields -->
    <fixheader>
        <fixfield name="BeginString" required="Y" description="FIX.4.2 (Always unencrypted, must be first field in message)" />
        <fixfield name="BodyLength" required="Y" description="(Always unencrypted, must be second field in message)" />
        <fixfield name="MsgType" required="Y" description="(Always unencrypted, must be third field in message)" />
        <fixfield name="SenderCompID" required="Y" description="(Always unencrypted)" />
        <fixfield name="TargetCompID" required="Y" description="(Always unencrypted)" />
        ...
        ...
    </fixheader>
<!-- FIX Trailers Fields -->

    <fixtrailer>
        <fixfield name="SignatureLength" required="N" description="Required when trailer contains signature. Note: Not to be included within SecureData field" />
        <fixfield name="Signature" required="N" description="Note: Not to be included within SecureData field" />
        <fixfield name="CheckSum" required="Y" description="(Always unencrypted, always last field in message)" />
    </fixtrailer>
<!-- FIX Messages -->

    <fixmessages>
        <fixmessage name="Heartbeat" msgtype="0">
        <fixfield name="TestReqID" required="N" description="Required when the heartbeat is the result of a Test Request message." />
    </fixmessage>

    <fixmessage name="List Cancel Request" msgtype="K">
        <fixfield name="Text" required="N" description="" />
        <fixfield name="TransactTime" required="Y" description="Time this order request was initiated/released by the trader or trading system." />
        <fixfield name="ListID" required="Y" description="" />
        <fixfield name="EncodedTextLen" required="N" description="Must be set if EncodedText field is specified and must immediately precede it." />
        <fixfield name="EncodedText" required="N" description="Encoded (non-ASCII characters) representation of the Text field in the encoded format specified via the MessageEncoding field." />
    </fixmessage>

    <fixmessage name="Logon" msgtype="A">
        <fixfield name="RawDataLength" required="N" description="Required for some authentication methods" />
        <fixfield name="RawData" required="N" description="Required for some authentication methods" />
        <fixfield name="EncryptMethod" required="Y" description="(Always unencrypted)" />
        <fixfield name="HeartBtInt" required="Y" description="Note same value used by both sides" />
        <fixfield name="ResetSeqNumFlag" required="N" description="Indicates both sides of a FIX session should reset sequence numbers" />
        <fixfield name="MaxMessageSize" required="N" description="Can be used to specify the maximum number of bytes supported for messages received" />

        <repeatinggroup name="NoMsgTypes" required="N" description="Specifies the number of repeating MsgTypes specified">
            <fixfield name="RefMsgType" required="N" description="Specifies a specific, supported MsgType. Required if NoMsgTypes is > 0. Should be specified from the point of view of the sender of the Logon message" />
            <fixfield name="MsgDirection" required="N" description="Indicates direction (send vs. receive) of a supported MsgType. Required if NoMsgTypes is > 0. Should be specified from the point of view of the sender of the Logon message" />
        </repeatinggroup>
      </fixmessage>

    ...

    ...

    </fixmessages>

    <!-- FIX Fields -->
        <fixfields>
        <fixfield tag="1" name="Account" datatype="STRING" description="Account mnemonic as agreed between broker and institution." />
        <fixfield tag="2" name="AdvId" datatype="STRING" description="Unique identifier of advertisement message. (Prior to FIX 4.1 this field was of type int)" />
    <fixfield tag="3" name="AdvRefID" datatype="STRING" description="Reference identifier used with CANCEL and REPLACE transaction types. (Prior to FIX 4.1 this field was of type int)" />

        <fixfield tag="4" name="AdvSide" datatype="CHAR" description="Broker's side of advertised trade Valid values: B = Buy S = Sell X = Cross T = Trade">
            <choice value="B" description="Buy" />
            <choice value="S" description="Sell" />
            <choice value="T" description="Trade" />
            <choice value="X" description="Cross" />
        </fixfield>

        <fixfield tag="5" name="AdvTransType" datatype="STRING" description="Identifies advertisement message transaction type Valid values: N = New C = Cancel R = Replace">
            <choice value="C" description="Cancel" />
            <choice value="N" description="New" />
            <choice value="R" description="Replace" />
        </fixfield>

        ...
        ...
    <fixfields>
</fixDataDictionary>

Note:

  1. The attribute description in the <fixfield> and <repeatinggroup> elements is an optional attribute. You can omit the field descriptions from the <fixfield> and <repeatinggroup> elements by excluding this attribute.
  2. The description attribute in the <choice> elements is a mandatory attribute.
  3. All other attributes in a FIX Data Dictionary XML file are mandatory.
  1. How do I specify the FIX Protocol version in the FIX Data Dictionary?

The attribute version in the <fixDataDictionary> element of the Data Dictionary is in the FIX.m.n format, where m and n respectively represent the major and minor versions of the FIX Protocol agreed by you and your counterparty for use in your FIX sessions.

For example:

<?xml version="1.0"?>
<fixDataDictionary version="FIX.4.2">
    ...
    ...
</fixDataDictionary>
  1. How do I implement the mandatory and optional Header fields agreed with my counterparty?

The <fixheader> element in a Data Dictionary should include only those Header fields, which you and your counterparty mutually agreed to use as required (mandatory) or optional fields. To keep your Data Dictionary precise and compact, do not add the fields which you do not need to the Data Dictionary..

You can include the following types of fields in the <fixheader> element:

  • All FIX Protocol specified mandatory standard Header fields.
  • Only those optional fields from the standard Header which you and your counterparty decided to use.
  • Custom Header fields that you and your counterparty decided to use.

For example:

<fixheader>
    <fixfield name="BeginString" required="Y" description="FIX.4.2 (Always unencrypted, must be first field in message)" />
    <fixfield name="BodyLength" required="Y" description="(Always unencrypted, must be second field in message)" />
    <fixfield name="MsgType" required="Y" description="(Always unencrypted, must be third field in message)" />
    <fixfield name="SenderCompID" required="Y" description="(Always unencrypted)" />
    <fixfield name="TargetCompID" required="Y" description="(Always unencrypted)" />
    ...
    ...
</fixheader>

Note:

  1. The attribute name in the <fixfield> sub element represents the name of a standard or custom FIX field. Its value should match with the value of the attribute name in the <fixfields> element too.
  2. The attribute required indicates whether the field is mandatory (value Y) or optional (value N).
  3. The optional attribute description gives the description of the Header field. You can omit it from the FIX Data Dictionary file, if required.
  4. After defining a specific field as a required field, the conditional fields associated with it also become required fields. For example, the field XmlData is an optional field in the FIX Protocol specifications. If you define it as a required field, then the conditional field XmlDataLen also becomes a required field in the Data Dictionary.
  1. How do I implement Trailer fields agreed with my counterparty?

The standard Trailer fields are:

Field Tag Field Name Required
93 SignatureLength N (Optional). But Y (mandatory), if tag 89 is included in the Trailer.
89 Signature N (Optional)
10 CheckSum Y (Mandatory)

The <fixtrailer> element in a FIX Data Dictionary defines Trailer fields.

If you decide not to use the Signature field, then the <fixtrailer> element becomes:

<fixtrailer>
    <fixfield name="SignatureLength" required="N" />
    <fixfield name="Signature" required="N" />
    <fixfield name="CheckSum" required="Y" />
</fixtrailer>

If you decide to use the Signature field, then the <fixtrailer> element becomes:

<fixtrailer>
    <fixfield name="SignatureLength" required="Y" />
    <fixfield name="Signature" required="Y" />
    <fixfield name="CheckSum" required="Y" />
</fixtrailer>
  1. How do I implement different message types agreed with my counterparty, including the custom message types?

The <fixmessages> element in a Data Dictionary includes a separate <fixmessage> sub element for each standard and custom FIX message type that you and your counterparty agree to use.

Each <fixmessage> element specifies the message name, message type and the list of Body fields in the message with their nature (required or optional).

A typical <fixmessages> element appears as follows:

<fixmessages>
    <fixmessage name="Heartbeat" msgtype="0">
        <fixfield name="TestReqID" required="N" description="Required when the heartbeat is the result of a Test Request message." />
    </fixmessage>

    <fixmessage name="Logon" msgtype="A">
        <fixfield name="EncryptMethod" required="Y" />
        <fixfield name="HeartBtInt" required="Y" />
        <fixfield name="RawDataLength" required="N" />
        <fixfield name="RawData" required="N" />
        <fixfield name="ResetSeqNumFlag" required="N" />
        <fixfield name="MaxMessageSize" required="N" />

        <repeatinggroup name="NoMsgTypes" required="N">
            <fixfield name="RefMsgType" required="N" />
            <fixfield name="MsgDirection" required="N" />
        </repeatinggroup>
    </fixmessage>

        ...
        ...
</fixmessages>

Note:

  1. The attribute name in <fixmessage> elements specifies the message name.
  2. The attribute msgtype in <fixmessage> elements specifies message types (the value of tag 35). For a custom message type, it is the value you agree with your counterparty. For tag 35 values of FIX Message types, refer to the FIXimate.
  3. The attribute name appears in the <fixfield> and <repeatinggroup> elements. Itrepresents names of a standard or custom FIX fields. Its value should match with the value of the attribute name in the <fixfields> element.
  4. The attribute required appears in the <fixfield> and <repeatinggroup> elements.It indicates whether a field is mandatory (value Y) or optional (value N).
  5. The optional attribute description in the <fixfield> and <repeatinggroup> elements gives description of fields.
  1. How do I specify the Repeating Groups in a message?

A Repeating Group field is a field having NumInGroup data type. To parse and validate messages having Repeating Groups, your Data Dictionary must specify Repeating Group fields in each message type and also the list of fields that repeat in groups under each Repeating Group field.

For example, NoMsgTypes is the Repeating Group field in the message type Logon. Several groups of RefMsgType and MsgDirection fields may follow the NoMsgTypes field in a Logon message.

Then the <fixmessage> element for the Logon message would be:

<fixmessage name="Logon" msgtype="A">
    <fixfield name="RawDataLength" required="N" description="Required for some authentication methods" />
    <fixfield name="RawData" required="N" description="Required for some authentication methods" />
    <fixfield name="EncryptMethod" required="Y" description="(Always unencrypted)" />
    <fixfield name="HeartBtInt" required="Y" description="Note same value used by both sides" />
    <fixfield name="ResetSeqNumFlag" required="N" description="Indicates both sides of a FIX session should reset sequence numbers" />
    <fixfield name="MaxMessageSize" required="N" description="Can be used to specify the maximum number of bytes supported for messages received" />

    <repeatinggroup name="NoMsgTypes" required="N" description="Specifies the number of repeating MsgTypes specified">
        <fixfield name="RefMsgType" required="N" description="Specifies a specific, supported MsgType. Required if NoMsgTypes is > 0. Should be specified from the point of view of the sender of the Logon message" />
        <fixfield name="MsgDirection" required="N" description="Indicates direction (send vs. receive) of a supported MsgType. Required if NoMsgTypes is > 0. Should be specified from the point of view of the sender of the Logon message" />
    </repeatinggroup>
</fixmessage>
  1. How do I implement the standard and custom FIX fields that my organization and the counterparty mutually agreed to use?

Since a custom or FIX field may occur in several message types, the Data Dictionary structure limits the description of fields in <fixmessage> elements only to their field names and their mandatory or optional nature in that message. The full details of each standard and custom FIX field are available to your application from the <fixfields> element of the Data Dictionary.

For each standard and custom FIX field that occurs anywhere in any of the supported message types, the <fixfields> element contains a separate <fixfield> subelement. Each <fixfield> sub element specifies the tag number, field name and data type of the field that it defines. For an enumerated field, the <fixfield> sub element includes as many <choice> elements as the number of enumerations of the field that it defines. For example:

<fixfields>
    <fixfield tag="1" name="Account" datatype="STRING" description="Account mnemonic as agreed between broker and institution." />
    <fixfield tag="2" name="AdvId" datatype="STRING" description="Unique identifier of advertisement message. (Prior to FIX 4.1 this field was of type int)" />
    <fixfield tag="3" name="AdvRefID" datatype="STRING" description="Reference identifier used with CANCEL and REPLACE transaction types. (Prior to FIX 4.1 this field was of type int)" />

    <fixfield tag="4" name="AdvSide" datatype="CHAR" description="Broker's side of advertised trade Valid values: B = Buy S = Sell X = Cross T = Trade">
        <choice value="B" description="Buy" />
        <choice value="S" description="Sell" />
        <choice value="T" description="Trade" />
        <choice value="X" description="Cross" />
    </fixfield>

    <fixfield tag="5" name="AdvTransType" datatype="STRING" description="Identifies advertisement message transaction type Valid values: N = New C = Cancel R = Replace">
        <choice value="C" description="Cancel" />
        <choice value="N" description="New" />
        <choice value="R" description="Replace" />
    </fixfield>

Note:

  1. The attributes tag, name, datatype and description in the <fixfield> elements specify the field tag number, field name, field data type and field description respectively. The attribute description is optional.
  2. The attributes value and description in each <choice> sub element specify the allowed enumerated values and their descriptions. The attribute description is mandatory.
  1. How do I specify the description for enumerations of an enumerated field?

For an enumerated field, the <fixfield> element includes as many <choice> elements as the number of enumerations of the field that it defines. Each <choice> sub element contains the attributes value and description that specify the enumerated value and its description.

For example, the AdvSide field at tag 4 is a character type enumerated field. Its possible values are B, S, T and X. You and your counterparty may decide to support only the B and S values depending on their relevance for your business. Then the corresponding <fixfield> element shall appear as:

<fixfields>
    <fixfield tag="4" name="AdvSide" datatype="CHAR">
        <choice value="B" description="BUY" />
        <choice value="S" description="SELL" />
    </fixfield>

    ...
    ...
</fixfields>

Note:
For preciseness and compactness, the Data Dictionary need not include enumerations that are not required. You may add your custom enumerations to the Data Dictionary, as required.
  1. How do I implement new message types and fields that my organization and the counterparty mutually agreed to use?

To implement Required Action
  • Standard FIX Message types that you did not use earlier, including the message types from the newer versions of the FIX Protocol
  • Custom message types (undefined in the FIX Protocol)
  1. Add a separate <fixmessage> sub element in the <fixmessages> element for each additional message type that you wish to implement.
  2. If the newly added messages include fields that are not defined in the <fixfields> element of the Data Dictionary, add a separate <fixfield> element for each undefined field.
  • New standard fields (not defined in the Data Dictionary earlier)
  • Custom fields (undefined in the FIX Protocol)
  1. Add a separate <fixfield> sub element in the <fixfields> element of the Data Dictionary for each new and custom field that you wish to implement.
  2. In the message types that use these fields, add the respective <fixfield> elements.

  1. I created a FIX Data Dictionary for my counterparty 'X'. How do I implement it in the FIX configuration file for that counterparty?

If you created the Data Dictionary file DataDictionary_X.xml for your counterparty 'X', you can implement it in the FIX configuration file for that counterparty as follows:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <Session>
        ...
        ...
        <add key="DataDictionary" value="D:\...\DataDictionary_X.xml" />
        ...
        ...
    </Session>

    ...
    ...
</configuration>

Note:
Since the FIX session requires a Data Dictionary for parsing and validation of messages with Repeating Groups, Data types fields etc, it is important to specify the complete path of the Data Dictionary file. If you do not specify the path, the application uses the application directory path as the default path.
  1. How do I programmatically refer to a FIX Data Dictionary file in XML format and get an object structure from it?

The FF.Fix.Core.FixDataDictionary class represents an object model structure for the Data Dictionary in XML format.

For example, to create an object structure for the Data Dictionary file CME4.2.xml located in the folder D:\...\DataDictionary, the code is:

using FF.Fix.Core;
...
...
FixDataDictionary cmeFIXDataDictionary = FixDataDictionaryManager.Instance().GetFixDataDictionary("D:\...\DataDictinary\CME4.2.xml");

Other objects in relation with the FixDataDictionary object are:

  • FixDataDictionaryField: Represents a FIX field programmatically.
  • FixDataDictionaryMessage: Represents a FIX Message type (based on the MsgType field at tag 35) programmatically.
  • FixDataDictionaryHeader: Represents the Header information in a Data Dictionary programmatically.
  • FixDataDictionaryTrailer: Represents the Trailer information in a Data Dictionary programmatically.

These objects provide a rich set of APIs to extract the information from a Data Dictionary.
  1. How do I programmatically extract a FixDataDictionaryField identified by a field name and get the information therein?

After creating the FixDataDictionary object structure for your Data Dictionary (XML file), you can access the required information from its four related objects given below:

  • FixDataDictionaryField: Represents a FIX field programmatically.
  • FixDataDictionaryMessage: Represents a FIX Message type (based on the MsgType field at tag 35) programmatically.
  • FixDataDictionaryHeader: Represents the Header information in a Data Dictionary programmatically.
  • FixDataDictionaryTrailer:Represents the Trailer information in a Data Dictionary programmatically.

For example, to get information about the OrdType field, first you create a corresponding object and then extract further information using other APIs, as shown below:

String fieldName = "OrdType";
FixDataDictionaryField fixDataDictionaryField = ficDataDictionary.GetFixDataDictionaryField(fieldName);

//Extract the field information with further APIs
//Obtain field tag number
int fieldTag = fixDataDictionaryField.FieldTag;

//Obtain field name
string fieldName = fixDataDictionaryField.FieldName;

//Extract data type of the field
eFixFieldDataType fixFieldDataType = fixDataDictionaryField.FieldDataTypeEnum;

//Check if the field is mandatory
bool isRequiredField = fixDataDictionaryField.IsRequiredField;

//Check if the field is Repeating Group field
bool isGroupField = fixDataDictionaryField.IsGroupField;

//Check if the field value is valid
bool hasValidFieldValue = fixDataDictionaryField.HasValidFieldValue("Market");

//Obtain description of the field value
string fieldValueDescription = fixDataDictionaryField.GetFieldValueDescription("Market");

You may use similar APIs on the FixDataDictionaryMessage, FixDataDictionaryHeader and FixDataDictionaryTrailer structures.
  1. How do I programmatically extract a FixDataDictionaryMessage object identified by a message name and get the information from it?

To get information about a specific message type, say a Logon message (MsgType = A), first you require to create a FixDataDictionaryMessage object. After this, you can access the further information using the related APIs.

For example:

FixDataDictionaryMessage fixDataDictionaryMessage = fixDataDictionary.GetDataDictionaryMessage(FF.Fix.Core.Message.FixMessageTypes.Logon_A);