FIX Protocol Tutorial

Financial Information eXchange (FIX) protocol was developed in 1992 as an industry standard protocol for real time electronic transfer of trading messages (pre-trade, trade, post-trade) using Order Management Systems (OMS) between Financial institutions and ECN/Stock Exchanges. FIX protocol helped to improve global trading practices by keeping an electronic log of end to end transaction of each order sent to market. For e.g., the FIX session messages produced by the OMS caters the need of post trade analysis and meeting compliance requirement such as providing an audit trail of a client order which was filled at a best possible price. FIX protocol is widely used by both buy side (institutions) and sell side (broker/dealer) of the financial markets. Prior to FIX protocol, trading information was communicated through telephone lines between broker-dealer and traders. Brokers handles buy/sell orders placed by individual/institutional clients in return for a commission. Dealers buy/sell securities for their own or their own firm instead for their clients through a broker. Traders buy/sell securities for their own portfolios. Investment banker or Underwriters buy new issues of stock directly from corporations and sell them to individual and institutional investors. FIX protocol supports a range of financial products such as Equities, Fixed Income, Derivatives (Options, Futures, IRs, SWAPS), FX for trading.

User Base of FIX Protocol

  • Institutional investors – such as mutual fund managers, corporate financial depts., hedge funds like Fidelity, Vanguard etc.
  • Brokers/Dealers – such as Barclays, BNP Paribas, Deutsche Equities, Credit Suisse, Goldman Sachs etc
  • Exchange, ECNs – exchanges and electronic crossing networks such as NSE, ASX, NYSE, NASDAQ, Instinet etc.
  • Financial industry utilities – market data providers, clearing and settlement organisations such as Reuters, Bloomberg, SWIFT etc
  • Software and service vendors – Large number of the software vendors who develop software for trading in market integrate FIX into their products

History of FIX Protocol

  • 1992 – First used between Salomon and Fidelity
  • Jan, 1995 – FIX 2.7 published
  • September, 1995 – FIX 3.0 published
  • 1996 – FIX 4.0 published
  • 1998 – FIX 4.1 published
  • 2000 – FIX 4.2 published – Equity market data and allocation, Futures and Options, FX, user defined tags(UDT) added
  • 2001 – FIX 4.3 published – Fixed Income, improved XML
  • 2003 – FIX 4.4 published – Confirms and Trade Reporting
  • 2006 – FIX 5.0 & T1.1 published – Complex FX, improved session/ transport level.

Benefits of using FIX Protocol

  • Significant cost savings as FIX reduces the time and installation charges of complex networks to connect to trading terminals situated across different countries
  • Reduced operational risks as it requires minimum manual intervention while processing of orders.
  • Increases the efficiencies of trader/broker/dealer side by reducing time of price and execution data transmission.
  • Order logging mechanism helps in getting audit trail of orders in doing post trade analysis and for compliance purpose
  • Staffing cost for organisation has reduced as handful number of traders can do more punching of orders using FIX protocol
  • FIX APIs are integrated with trading software easily which resulted in trading software vendors to develop newer algo strategies at a growing rate.

FIX Message Format

FIX messages are broadly divided in to 2 categories:

  • Admin message or session messages: Logon, Logout, heartbeat, test request, resend request, reject, sequence reset
  • Application message or order messages: New Order, Amend Order, Filled Order, Partially Filled order, Cancel order, Execution report

FIX message tags are segregated from left to right as:

Header: message type, length, sender/receiver name, sequence number, time stamp

Body: session /application specific data

Trailer: message checksum

For example, look at this sample FIX new single order message:

8= FIX4.2^9=0185^35=D^34=5^43=N^49=VENDOR^50=CUSTOMER^56=BROKER^52=20160727-10:17:47^1=ACT^11=AKS_2^21=1^55=NIFTY^48=1173^22=8^54=2^38=50^40=2^44=8200^59=0^10=82

Header: 8<protocol version>,9<body length>,35<messagefield>,34<MsgSeqNum>,43<PossDupFlag>,49<SenderCompID>,56<TargetCompID>,52<TimeStamp>

Body: 1<Account>,11<ClOrdID>,21<HandInst>,55<Symbol>,48<SecurityID>,22<IDSource>,54<Side>,38<Order Qty>,49<OrdType>,44<Price>,59<TimeInForce>

Trailer: 10<Checksum>

Admin Messages or Session Messages

Logon: [35 =A]

Logon message does the user authentication while connecting to the remote session acceptor application. This is the first message sent by the client FIX Engine. The session acceptor application will send a logon response on successful login. A standard FIX logon message will carry the logon tag 35=A with the SenderCompID tag 49, TargetCompID tag 56, Sequence Number tag 34 (MsgSeqNum) and based on result of authentication either a successful logon tag 35=A or logout tag 35=5 is returned back in the response message.

Scenarios:

  • Invalid CompID in tag 49 or tag 56 – response sent by receiving application will be logout with error message sent in tag 58
  • Sending Sequence number lower than expected – response will be logout 35=5 with error message sent in tag 58
  • Sending Sequence number greater than expected – 2 responses will be sent: first response will have successful logon 35=A, second response will have resend request 35=2 to initiate the retransmission of messages to sync up the sequence number gap.
  • Sending reset sequence number tag 141=Y with logon tag 35=A – This will reset both incoming and outgoing sequence number. Before sending ResetSeqNumFlag tag 141 the initiator must send a test request tag 35=1 to check if there any unsent message in queue. The test request message instantly sends a heartbeat message to the target (either server or client) application and verifies the communication link and check sequence number. The target application responds to the test request message 35=1 with a Heartbeat containing TestReqID.
  • Invalid MsgType – any message type other than specified in FIX specification which is sent from either initiator or acceptor will get rejected
  • Required tag missing – Any mandatory FIX tag which when gets missed by either initiator or acceptor will give session level reject
  • Invalid tag number – Any tag number which is not specified in FIX specification which is not either the standard FIX tags or the customised tag, then it will give an error.
  • Tag not defined for this message type – sending incorrect tags combined with a specific message type will give session level reject
  • Undefined tags – when tags will have empty values, possibility is that FIX engine might crash

Read more about various FIX Admin messages