FIX messages simulator

Last Updated on by

Post summary: General thoughts how to test FIX messages with a FIX simulator.

FIX stands for Financial Information eXchange and is most probably the most used protocol for exchanging electronic messages in the financial world.

FIX sessions

In order to exchange data systems in financial world use FIX messages. The first important step before exchanging messages is to establish a connection between each other. There are two roles for counterparties

  • Acceptor – acts as a server. Stays and listens for clients that will connect
  • Initiator – acts as a client. It is the active participant in the connection

Once roles are defined fix session should be established between both. They can maintain as many different sessions as they need. A session is uniquely identified by FIX protocol version and IDs of both counterparties.

A session is started by initiator by sending Logon request and receiving Logon Acknowledgement. A session is kept alive by both sides. They send Heartbeat messages to each other. A session is ended by Logout message send from one of the counterparties. The other acknowledges the Logout.

FIX messages

Once all the ceremony of setting a session is done and the session is alive both counterparties can start exchanging FIX messages with data. FIX message in short is a string containing key-value pairs in format <TagNumber>=<Value> separated by SOH (\u0001) character. Each tag has a name and in some cases vast specification what values accept, what each value means, etc. FIXimate is a pretty good online tool which gives information about tags. Each tag is represented by its integer number in the message. Tags are separated in three parts of the message:

  • Header – contains information needed for session identification
  • Body – contains business data
  • Trailer – checksum for message validation

An example where SOH is replaced with |


Testing of FIX message scenarios

Depending on business logic behind actual testing of FIX messages could be a pretty complicated task. Each message alone could have tens of tags with data. Each tag is meaningful and the system can react in a different manner based on its value. Each message could depend on the previous message. The combination and complex business logic could be made through a very difficult testing task.

How to do it

There are numerous FIX simulators available out there. They will work for most of the cases but since FIX communication can be really boutique in some cases external tool is not a good idea. The internal tool is what I suggest and propose a solution in the current post.

Visualise the message

This is maybe the hardest part of everything. How to show messages so they can be easy to comprehend and edit. Obviously editing long string with user-unfriendly data is not the best solution. I admit not the perfect solution but couldn’t think of better than good old-fashioned Excel. In short, each column is a specific tag. Each row is a single fix message and you fill the tag value for this particular fix message. There could be separation rows to make different tests scenarios.

Convert the messages

Once Excel test cases are ready they are exported with a macro to special XML format. XML is then read from FIX simulator and converted to real fix messages.

Send the messages

FIX messages are then sent on the wire. In order to send them, you need fix engine. Very popular is QuickFIX engine. It has Java and .NET version. There are example applications which help for better understanding how to use the engine.


Testing FIX messages based on business rules is definitely a very important task. It also is not the simplest task you might think of as a QA. Still, it is achievable. I would say creating custom solution will initially take some time but in the long run, it will pay off as you will have total control over features you have and need.