http://fixwiki.org/fixwiki/FIXwiki - Official Blog
  • FIX – stands for Financial Information eXchange.
  • As its name states, it is an electronic protocol that is widely adopted by industry sectors and used for exchanging messages at all stages of a trade life cycle.
  • In its core FIX is represented as messages those are exchanged between various parties involved in a trade.
  • Anatomy of FIX message is : Header, Body and Footer (also referred as Trailer). Each section is either separated by a delimiter (SOH – ASCII value 1, meaning Start Of Header) or the messages are supported in FXML – an XML schema to represent these sections.
  • FIX is platform independent and a session level protocol. Understandably a session level protocol would involve activities involving establishing and managing sessions. A session is a period of time in communication between parties from the time the session is explicitly established and explicitly or unexpectedly terminated due to communication failures ( in other network layers) or system failures.
  • Due to above mentioned role the FIX plays as session level protocol, the types of messages too fall under two broader classes – Administrative and Application
  • Administrative type messages are used to establish and terminate sessions, health check of established communication links and so forth. Application type messages are those concerned with actual trade lifecycle.
  • Administrative Messages : Logon, Logout, NetworkCounterpartySystemStatusRequest, TestRequest, Heartbeat, SequenceReset etc. I will try to classify all these messages further down in my blogs.
  • Application Messages – please refer to Wiki [1]
  • In each section of FIX message, the information is encoded as key-value pairs. Keys, also referred as Tags are listed in FIX dictionary – part of FIX specification documentation and have corresponding numeric values.
  • Each FIX message starts with Tag id 8 -  “8=FIX.m.n”  where ‘m’ and ‘n’ indicating the FIX version this message belongs to ends with a CheckSum value used in validation in communication of messages for data loss – “10=<CheckSum><SOH>”
  • FIX messages are highly extensible with user defined tags – those tag values must be >= 5000 and < 9999. User can also define new message types and in such case they must start with ‘U’.
  • FIX advocates a client server paradigm – where client is the one requesting/initiating the session and the server is the one acknowledges such session requests.
  • Both client and server maintains sequence number to coordinate communications. If there is a mismatch in sequence number (in the messages received) then it may result in message rejection – in such cases those messages needs to be re-submitted and in rare cases it may require manual intervention. Every new sessions start with sequence number 1.
  • The parties involved in trade scenario are Buy Side, Sell Side, Electronic Communication Networks (ECN), Exchanges, Broker-Dealers etc.
  • A trade lifecycle comprises of: Pre-Trade, In-Trade and Post-Trade activities.
  • FIX supports different product classes involved in trades: Currency (FX), Equities, Fixed Income, and Derivatives such as options, forwards, futures, options..etc
  • Reader is advised of need for FIX to support various markets around the world. These are specializations – for example some of the messages fields are only applicable to Japanese markets and some of them are only to Korean markets..etc
  • At the time  of writing there are 142 message types listed [1]
  • A FIX Protocol implementation is called FIX Engine. There numerous commercial and open source implementations out there.  QuickFix is for example an open source implementation and QuickFix/J [4] is a completely Java based implementation of QuickFix engine.
  • System components of a FIX implementation – here we refer to the whole infrastructure as ‘implementation’ – not just the FIX Engine implementation.






















  • In the above example, FIX Engine manages the session and communication between the buy and sell side throughout the trade lifecycle. Critically missing picture from Figure 1 is that a client may directly speak to Liquidity sources such as exchanges, ECN and other private market as long they are FIX enabled. In this case Broker-Dealer will execute those orders on behalf of its institutional clients against target liquidity source.

References:

[1] Wiki: Refer this for various message types used  http://fixwiki.org/fixwiki/Category:Message
[2] Beginners Guide Forum: http://www.fixtradingcommunity.org/pg/structure/tech-specs/presentations-docs/beginners-guide
[3] Fix message format Details : http://www.fixtradingcommunity.org/pg/file/fplpo/read/30478/fix-message-construction-message-format-details
[4] QuickFix /J - Java Implementation of QuickFix   FIX engine : http://www.quickfixj.org/