FIX Processing

The Financial Information eXchange (FIX) protocol is a messaging standard developed specifically for the real-time electronic exchange of securities transactions.

The FIX Protocol specification was originally authored in 1992 by Chris Morstatt and Robert "Bob" Lamoureux to enable electronic communication of equity trading data between Fidelity Investments and Salomon Brothers. FIX has become the de facto messaging standard for pre-trade and trade communication in the global equity markets, and is expanding into the post-trade space to support straight-through processing, as well as continuing to expand into foreign exchange, fixed income and derivatives markets.

FIX is a public-domain specification owned and maintained by FIX Protocol, Ltd (FPL).

FIX Messages

FIX messages are formed from a number of fields, each field is a pair of a

Fields are separated from the next field by the ASCII 0x01 delimiter (Start of Header).

The tag is a string representation of an integer that indicates the meaning of the field.

The value is an array of bytes that hold a specific meaning for the particular tag,

The values may be in plain text or encoded as pure binary (in which case the value is preceded by a length field). The FIX protocol defines meanings for most tags, but leaves a range of tags reserved for private use between consenting parties.

The ordering of fields within the message is generally unimportant, however repeating groups are preceded by a count and encrypted fields are preceded by their length.

Message Structure

Entire FIX Messages are composed of a

Example of FIX message

There are two main groups of messages,

The administration messages handle the basics of a FIX Session. They allow for a session to be started and terminated and for recovery of missed messages.

The application messages deal with the sending and receiving of trade-related information such as an order request or information on the current state and subsequent execution of that order.

Message Header

Up to FIX.4.4, the header contained three fields:

From FIXT.1.1 / FIX.5.0, the header contains five mandatory fields and one optional field:

Message Body

The body of the message is entirely dependent on the message type defined in the header tag 35. E.g.

35=D

indicates a Trade/SingleGeneralOrderHandling/NewOrderSingle with fields like

in the FIX 4.4 Standard. Hereby, the fields of a concrete message type are taken from a uniform list of fields for all messages of a FIX Version where these fields are specified in Tag Number, name and meaning.

You can obtain more information about the structure of FIX Message Types in the different FIX Versions via FIX Interactive Message And Tag Explorer (FIXimate), an interactive Web browser based reference for the FIX Specification..

Checksum

The last field of the message is tag 10, the FIX Message Checksum. It is always expressed as a three digit number (e.g. 10=002).

An example of a complete FIX message for Trade/SingleGeneralOrder/Execution Report

8=FIX.4.2|9=178|35=8|49=PHLX|56=PERS|52=20071123-05:30:00.000|11=ATOMNOCCC9990900|20=3|150=E|39=E|55=MSFT|167=CS|54=1|38=15|40=2|44=15|58=PHLX EQUITY TESTING|59=0|47=C|32=0|31=0|151=15|14=0|6=0|10=128|

with the | character used to represent Start of Header (ASCII 0x01) character.

FIX Communication

The following shows a simple end-to-end example of FIX communication:

Example of FIX message

In our example, the FIX Client sends a NewOrderSingle message (MsgType = D). This message is used to send new buy/sell orders to brokers or exchanges.

|8=FIX.4.2|9=210|35=D|49=PROBE|56=MESSENGER|115=Field115|128=Field128|34=2|57=EURONEXT_LOCAL|116=Field116|129=Field129|52=20090304-10:02:31|
11=ClOrdID415|21=1|100=PA|55=FR0000133308|54=1| 60=20090304-10:02:31|38=1000|40=2|44=10|10=187.

As an acknowledgment, the server sends an ExecutionReport message (MsgType=8) with tag OrdStatus=0.

|8=FIX.4.2|9=0343|35=8|142=930|115=Field128|116=Field129|128=Field115|129=Field116|50=EURONEXT_LOCAL|56=PROBE|49=MESSENGER|34=3|52=20090304-10:02:39
|38=1000|9552=000100000000|9551=2| 55=FR0000133308|9549=M090304010000001|54=1|59=0|44=10|60=20090305-11:01:57|150=0|39=0|151=1000|
20=0|37=0934A0000000001|32=0|31=0|14=0|6=0|17=12361609590001|11=ClOrdID415|9554=273|10=054

FIX Communication Protocol

Fix Messages are send via are sent via TCP Socket connections between two counterparts. These connections persist over the lifetime of a FIX Session.

FIX Sessions are connections with a counterpart established for a specific timeframe. During the session FIX messages are exchanged via a socket connection.

At the end of the communication the FIX client sends a logout message to stop the session.

@ISB Add more

The QuickFIX/J Camel Component

QuickFIX/J provides an implementation for a FIX engine which

The QuickFIX/J Camel Component allows you to use QuickFix in Camel Routes.

FIX sessions are endpoints for the quickfix component. An endpoint URI may specify a single session or all sessions managed by a specific QuickFIX/J engine. When a consumer does not include a session ID in the endpoint URI, it will receive exchanges for all sessions managed by the FIX engine associated with the configuration file specified in the URI. If a producer does not specify a session in the endpoint URI then it must include the session-related fields in the FIX message being sent. If a session is specified in the URI then the component will automatically inject the session-related fields into the FIX message.

from("quickfix:fix-client.properties")
.filter(header(QuickfixjEndpoint.EVENT_CATEGORY_KEY)
.isEqualTo(QuickfixjEventCategory.AppMessageReceived))
.filter(header(QuickfixjEndpoint.MESSAGE_TYPE_KEY).isEqualTo(MsgType.ORDER_SINGLE))
.to("ipp:authenticate:setCurrent?user=motu&password=motu")
.to("ipp:process:start?processId=NewOderSingleProcessing&data=Order::${body}");

The QuickFIX/J component is able to start endpoints from a standard quickfixj configuration file. The format of the URI is as below:

quickfix:configFile[?sessionID=sessionID]
from("quickfix:examples/inprocess.cfg?sessionID=FIX.4.2:MARKET->TRADER").
filter(header(QuickfixjEndpoint.EVENT_CATEGORY_KEY).isEqualTo(QuickfixjEventCategory.AppMessageReceived)).
to("trade-executor:market");

Exchange Structure

The header of the Message Exchange contains the following fields

Header Name Description
EventCategory One of AppMessageReceived, AppMessageSent, AdminMessageReceived, AdminMessageSent, SessionCreated, SessionLogon, SessionLogoff. See the QuickfixjEventCategory enum.
SessionID The FIX message SessionID
MessageType The FIX MsgType tag value
DataDictionary Specifies a data dictionary to used for parsing an incoming message. Can be an instance of a data dictionary or a resource path for a QuickFIX/J data dictionary file

These fields can be e.g. used for routing or correlation purposes.

The body of the Message Exchange will contain name value pairs for all fields of the FIX message.

QuickFix Configuration

The Endpoint URI for Quickfix needs to defer to a Quickfix configuration which can be provided as a Spring Bean, e.g.

<bean id="quickfixjConfiguration" class="org.apache.camel.component.quickfixj.QuickfixjConfiguration">
<property name="defaultSettings">
<util:map>
<entry key="SocketConnectProtocol" value="VM_PIPE"/>
<entry key="SocketAcceptProtocol" value="VM_PIPE"/>
<entry key="UseDataDictionary" value="N"/>
</util:map>
</property>
<property name="sessionSettings">
<util:map>
<entry key="FIX.4.2:INITIATOR->ACCEPTOR">
<util:map>
<entry key="ConnectionType" value="initiator"/>
<entry key="SocketConnectHost" value="localhost"/>
<entry key="SocketConnectPort" value="5000"/>
</util:map>
</entry>
<entry key="FIX.4.2:ACCEPTOR->INITIATOR">
<util:map>
<entry key="ConnectionType" value="acceptor"/>
<entry key="SocketAcceptPort" value="5000"/>
</util:map>
</entry>
</util:map>
</property>
</bean>

(Pseudo-)Synchronous Processing

Although the FIX protocol is event-driven and asynchronous by nature, there are specific pairs of messages
that represent a request-reply message exchange.

To use a synchronous exchange pattern, there should be a single request message and single reply message to the request. Examples include

To mark and endpoint to receive and return a FIX message to establish a synchronous communication, add

exchangePattern=InOut

to the QuickFIX/J endpoint URI..

The MessageOrderStatusService in the example below is a bean with a synchronous service method. The method returns the response
to the request (an ExecutionReport in this case) which is then sent back to the requestor session.

from("quickfix:examples/inprocess.cfg?sessionID=FIX.4.2:MARKET->TRADER&exchangePattern=InOut")
.filter(header(QuickfixjEndpoint.MESSAGE_TYPE_KEY).isEqualTo(MsgType.ORDER_STATUS_REQUEST))
.bean(new MarketOrderStatusService());

Using the QuickFIX/J Camel Component from Stardust

You can use the QuickFIX/J Camel Component directly in a Camel Trigger in Stardust by

as in

By adding,

to the Route the Message Exchange created from the QuickFIX/J endpoint will be automatically converted into a Map/List structure and can directly be used for

E.g. by modeling

you may model a message processing for content-based routing like

More about content based-routing can be obtained here.

It is intended to provide Process Models with all FIX message structures for all relevant FIX versions in later releases of @integration-product@.

Camel String to FIX Converter

This section describes the String to FIX Converter that transforms a String FIX Format message to a QuickFIX/J Message object. The converter is suited for cases where a message received by an endpoint needs to be transformed to a FIX object message without declaring a bean. To be able to use the converter, you need to add the following in your pom.xml file

<dependency>
  <groupId>com.sungard.infinity.isb</groupId>
  <artifactId>string-to-fix-converter</artifactId>
  <version>1.0.0</version>
  <type>jar</type>
  <scope>compile</scope>
</dependency>

Example

The example below shows how to transform FIX String messages into FIX Objects using the parser. In this case, FIX messages are sent to the start endpoint in a String format. Each message will be parsed using the QuickFix/J converter. If a FIX message is not valid, an error will be thrown.

onException(InvalidMessage.class).handled(true).to("mock:result");
from("direct:start").convertBodyTo(quickfix.Message.class).to("mock:result");

The FIXConverter is a component developed by the enabling Team and it is available in the Maven repository.

Using a Custom Dictionary

If you are using a custom dictionary, you can add the following configuration in a Spring context file to overwrite the default FIX dictionary used by the transformer. In the configuration below the YOUR_CUSTOM_DICTIONARY.xml will be used by the transformer instead of the default FIX 4.2 dictionary. Please note that the bean name should be stringToFixTransformer.

<bean name="stringToFixTransformer" class="com.sungard.infinity.isb.quickfix.parsing.transformer.StringToFixTransformer">
    <property name="dataDictionary42" ref="customFix42Dictionary" />
</bean>

<bean id="customFix42Dictionary" class="quickfix.DataDictionary">     <constructor-arg index="0" value="YOUR_CUSTOM_DICTIONARY.xml" /> </bean>

Testing FIX Processing

QuickFix Messenger can be used as FIX initiator and FIX acceptor.