Since its inception in 1992, the Financial Information Exchange (FIX) Protocol has become a powerful tool for financial markets organizations to exchange internal and external data about pre-trade, order buys and sells, trade confirmations and allocations, etc.
Over the years, the FIX Protocol message types, tags, tag enumerated values and datatypes has grown steadily. The protocol provides a lot of freedom - all standard definitions of messages can be further customized based on bilateral or multilateral usage conventions. In real life trading venues and liquidity pools (acting as a FIX session acceptors) often provide users with custom FIX Rules of Engagement specifications which session initiators must implement in custom FIX Dictionary Dialects.
How the set of FIX message types (FIX MsgType) has evolved
Here is the list of message types in FIX4.0 – at the very beginning of the FIX Protocol development – there are only 27 FIX message types (MsgTypes) from 0 to S.
With the latest FIX extension pack version of the FIX Protocol in FIX5.0 SP2 EP264 – there are 164 FIX message types (MsgTypes) 0 to z.
This is not a bad thing. FIX messaging usage has expanded significantly over the last 30 years based on maturity and increased scope of adoption demands.
The FIX Tag MsgType <35> field defines the message type. The message type is always the third field in the FIX message and is unencrypted. This is easier to see in an example: |35=U1|
You will notice that the alphanumeric principle used to reference the FIX MsgTypes and you will observe that the sequence has a gap at the uppercase ‘U’ MsgType. This is missing by design in all versions of the FIX protocol and its extensions. The uppercase ‘U’ is reserved to be available to users as the basis for the User Defined Message types.
You will find MsgType=U user defined messages in the FIX specification documentation for key large market participants such as the Intercontinental Exchange (ICE) and NASDAQ. These custom messages are used to exchange custom specific user-defined securities messages, details on auctions, company details, historic trades – all information that is not included into the standard FIX definitions but that counterparties need to exchange.
Why would counterparties need so many message types?
By comparing the FIX message News<B> with message Email<C> we see that there are a lot of common fields. These messages could be combined into the one single message that fits both requirements. So why has the number of FIX message types expanded instead of consolidated? The answer is the context.
When the counterparty receives a News<B> message, they receive not only a chain of FIX tag=values pairs, but also the context of why and when such a message was sent, e.g., that the message contains broadcasted news rather than personal email.
This context makes it simpler to interpret the received data. If the FIX standard message list does not provide a predefined relevant context then there is always the option to create a FIX user-defined message.
Supporting user defined messages in OnixS FIX Engines SDKs
Here is a simple example of how to implement user-defined message on both Acceptor and Initiator sides of a FIX session.
Let us assume that as a venue we are a FIX Acceptor and we would like to use the custom message where users could request the status of the symbol. Let’s call our message type a User Defined Request = “UDR”. We would like users to send the RequestID<20000>, Symbol<58> fields and RequestType<20001> where users should either subscribe (value ‘1’) or unsubscribe (value ‘2’). This is an example of such a FIX message:
8=FIX.4.4|9=000|35=UDR|49=TradingGateway|56=Client|34=8|43=Y|52=20210107-10:23:03.032|20000=Request1|20001=1|55=IBM|10=000|
User-defined messages as well as custom tags are not present in the standard definitions of the FIX messages, so the FIX Engine requires the custom dialect. The dialect is an instruction to the FIX Engine of how to parse or compose the messages, how the fields are ordered, what is the structure of the repeating groups, etc.:
Then it is possible to create the message:
private static Message CreateUDR(Dictionary dictionary)
{
var request = new Message("UDR", dictionary);
request.Set(20000, "Request1");
request.Set(20001, 1);
request.Set(Tag.Symbol, "IBM");
return request;
}
Or to parse the message:
session.InboundApplicationMessage += (object sender, InboundMessageEventArgs e) =>
{
switch (e.Message.Type)
{
case "UDR":
string requestID = e.Message.Get(20000);
int requestType = e.Message.GetInteger(20001);
string symbol = e.Message.Get(Tag.Symbol);
break;
}
};
User-defined message fields could include any standard FIX Data Types. Note that FIX Data Types cannot be customized, so any user-defined message should be based on the most suitable standard data types.
Real world example: ICE User Defined Strategy FIX messaging
The ICE adds a new context for their SecuritiesDefinitionRequest<c> with a specific user-defined message response. In addition to the conventional SecurityDefinitionResponse<d> message provided in response to a securities definition request, the ICE implements a User Defined Strategy (UDS) message type to deliver details about market participant (user) and exchange-defined strategies.
As can be seen from the FIX dialect definitions below, there are a considerable number of user-defined fields used in both messages.
The UDS messages are intended to provide data on a single instrument per single request.
With the SecurityDefinitionResponse<d> messages, ICE returns a set of messages per single request with the number of entries defined in the NoRpts<82> field.
Here each individual SecurityDefinitionResponse<d> message contains the definitions of multiple instruments as underlyings with the NoUnderlyings<711> tag used to specify the number of securities in one message.
The difference between these two messages is based on the context of the instruments – the security definitions is a static list of instruments that are known at the start of the trading day. But strategies can be created dynamically within the trading day, so there is no need to return the entire list of instruments. In this context a single UDS message per single request is more relevant.
These ICE usage scenarios are real world examples of using a FIX Engine SDK along with venue specific FIX Dictionary dialect and reference implementation source code fast-start samples that are calibrated, supported, and certified with the venue specific service APIs.
In an OnixS context we offer the OnixS FIX Engine SDKs for general FIX messaging integration, and we offer the OnixS directConnect venue specific packages designed to support venue specific APIs – some of which are FIX based and others to support venue non-FIX protocols. In the previous ICE User Defined Strategy (UDS) message examples, this specific FIX messaging is implemented and supported in the OnixS directConnect: ICE FIX Order Entry, ICE FIX Trade Capture, and ICE FIX Private Order Feed SDK implementations.
Request your evaluation
You can request an evaluation of the OnixS FIX Engine .NET Framework, .NET Core. C++ or Java SDK implementations. Or if your requirements are to support a venue specific API, you can select an evaluation SDK for that. Available selections are available here = https://downloads.onixs.biz
