FIX Connection models - (a) Point to Point (b) Hub and Spoke Model

From - http://www.gxsblogs.com/keifers/2009/08/nyse-euronext-acquires-nyfix-the-last-big-independent-fix-network.html

About FIX
The FIX (Financial Information Exchange) standard includes both a networking communications protocol and a message format.  FIX is primarily used to execute trades of various types of securities (stocks, bonds, futures, options and foreign exchange) between buyers and sellers.  The typical users of FIX include hedge funds, mutual funds, life insurers, brokerage firms and custodial banks.  Common FIX transactions include Indications of Interest (IOI), price quotations, order instructions and trade confirmations.  Many of the post-trade transactions and post-settlement activities do not use FIX, but rather the SWIFT standards.



Historically, there have been two types of FIX vendors:

• Point-to-Point – In the point-to-point model each buy-side financial institution establishes its own private community.  FIX connections are then configured separately with each individual counterparty.  In the point-to-point model the FIX vendor manages the physical circuits and connectivity.  Message translation, enrichment, monitoring are performed by FIX software engines on either side of the firewall.  The point-to-point model typically appeals to larger, more sophisticated investment managers who seek to customize their FIX networks and the version of FIX they are implementing.
  
• Hub and Spoke – In the hub and spoke model, financial institutions need only maintain a single connection to the FIX network to gain access to the community.  Hub and spoke providers offer more value added services such as order routing, message translation, data enrichment and transaction monitoring.  Counterparties at each end point may not even have a FIX engine behind their firewall.  Hub and spoke models typically appeal to midsize firms which need to quickly and cost-effectively scale their FIX connectivity.
  

Point-to-point providers more closely resemble telecommunications providers, but with a suite of specialized value added services designed for securities trading.  Hub and spoke vendors resemble B2B integration service providers, but with a specialized focus on securities trading.
Value Added Services

Perhaps, the most interesting of NYFIX's product line is the Transaction Services they offer. NYFIX achieved such high volumes of trade orders on its FIX network that it was able to offer its own trade execution services.  In other words, NYFIX could identify to opportunities to match buyers and sellers of securities without having to route the orders to traditional marketplaces such as NASDAQ and NYSE.  The NYFIX service for trade matching is called Millenium, which is generically referred to as an Alternative Trading Service (ATS) or what some call a Dark Pool of Liquidity.  With Millenium, NYFIX offers a higher value add to the customer, which has the effect of encouraging further use of the vendor's FIX services.  NYFIX ATS services are a great example of how B2B integration providers can evolve beyond technology infrastructure into business applications.  Integration hubs, can quickly reach a point of critical mass at which such high volumes of information are being exchanged that network patterns can become a source of intelligence and opportunity.  I think this principle applies regardless of which business process the integration hub is organized around whether its supply chains, health care claims or securities trading.

OTC trade life cycle 1: Basic derivatives trading lifecycle

OTC trade life cycle 1: Basic derivatives trading lifecycle: It’s worth noting that the derivatives trading lifecycle is considerably longer and more complicated than the lifecycle associated with sim...

Orig Source : http://javarevisited.blogspot.in/2012/01/what-is-fix-engine-in-fix-protocol.html

 What is FIX Engine in FIX Protocol

FIX Engine is in heart in FIX protocol Implementation, whenever we discuss about FIX protocol we talk about FIX engines, performance of different Fix engines, support of different FIX versions on FIX engine etc. but on basic level we definitely like to know what is a FIX engine and what does FIX Engine do in FIX protocol. In this article we will try to touch base on such questions with an independent view on FIX engines.

Quick guide on Fix Engine functionality

What is FIX Engines

Fix engines are program written in any programming language like Java, C++ which is used to facilitate online trading using FIX Protocol. its an implementation of FIX protocol and a single piece of software required to establish FIX connectivity. FIX messages which caries stocks trading orders electronically in form of tag and value is composed, parse and understand by FIX engines. FIX engines is also responsible for establishing FIX connectivity between client and broker or client and exchange. In a simple FIX connectivity setup we have two FIX engines running one at client side and other at broker or exchange side. These FIX engines first establish FIX session between each other and than transmit application level  messages(electronic stock order, cancels and order amendments etc). In Short FIX engine is essential piece of software your company will require to build electronic trading infrastructure.

What does FIX Engine do ?

Here is short summary of what is responsibility of FIX engine and what does fix engine do:

1) Establish Fix Connectivity by sending session level messages.

2) Manage FIX Session

3) Recover if FIX session lost

4) Creating, sending, parsing FIX messages for electronic trading.

5) Handles replay

6) Supports different FIX (Financial information exchange) protocol version and tags.

Who uses FIX Engines

FIX Engines are mostly used by large Investment banks, brokerage firms, hedge funds, pension funds and other independent parties which are interested in electronic trading. In stock trading first FIX engines is used at two places first at client side (most of high net worth individual, hedge funds uses FIX protocol to transmit orders to brokers) and on Exchange side if Exchange supports FIX protocol or you have connected to a broker. Since different exchange uses there proprietary exchange protocol (e.g. HKSE uses OG, TSE uses Arrowhead protocol and NASDAQ uses OUCH protocol), use of FIX engine on exchange side is less as compared ot client side, As clients and firms prefer to use FIX protocol for sending orders and receiving executions.

Performance of FIX Engine:

Performance of any FIX engines is key in order to be successful in online trading or electronic trading space. fastest, robust, flexible FIX Engines are proffered by brokerage firms and client alike. Since today's market is very volatile and sensitive due to high frequency and algorithmic trading, speed of FIX engines has become more important and derived bigger investment banks and brokerage houses to implement or create there own Fix engines.

Commercial FIX engines in Market

There are lot of commercial FIX Engines are available in market and they are listed on vendor page of FIX protocol. here is quick list of popular FIX engines you may want to choose for your firm:

1) NYFIX Appia

by far most used, flexible, robust and easy to maintain and support. what is best feature of Appia is that it

provides you to create new FIX session on the fly and manage fix session without downtime in FIX engine.

2) Cameron FIX Engine

Another popular fix engine which strictly follow FIX protocol and supports almost all of FIX protocol version.

3) Onix Biz

I have not used onixs.biz fix protocol solutions but sounds like good candidate.

4) B2Bits

B2Bits offers fix engines and fix solution in Java, .NET and C++.

despite these popular ones there are lot many other players like rapidaddition, Inforeach and Flyer Fix Engines.

That's all on FIX engines of FIX protocol , you can also check my other articles on FIX protocols for getting more knowledge on how fix protocol works etc.

Related FIX Tutorials

Top 20 FIX Protocol Interview Questions

FIX Protocol Session or Admin messages tutorial

What is Repeating groups in FIX

Difference between Session Level and Business message Reject

Difference between FIX 4.2 vs FIX 4.4 

Common issues on financial information exchange (FIX) Connectivity

Read more: http://javarevisited.blogspot.com/2012/01/what-is-fix-engine-in-fix-protocol.html#ixzz33fKwEyaK

Client FIX Onboarding

Very good information on RoE from  http://www.fixtradingcommunity.org/pg/structure/tech-specs/implementation-guide/rules-of-engagement

and on FIX Onboarding.

Rules of Engagement

Introduction  General infrastructure  Choosing a network  Choosing a FIX engine  Testing a FIX implementation  Training  Fixed income external systems  Fixed income dealer systems  Rules of engagement  The FIX process for fixed income              Introduction Introduction General infrastructure Choosing a network Choosing a FIX engine Testing a FIX implementation Training Fixed income external systems Fixed income dealer systems Rules of engagement The FIX process for fixed income

Many firms with larger FIX implementations have chosen to support their counter parties by supplying them with rules of engagement documents. This section describes the most common elements of an engagement document. Generally, these documents represent a supplement to the official FIX specification as published on the FPL website. Or you may wish to in include these rules in your standard business terms that can be updated yearly.

Session level and connectivity rules

Network Options

This section usually describes the supported networks and vendors. For example, specifics regarding recommendations for particular vendors would appear here. Additionally, mention might be made of special handling of certain providers, the non-support of Internet based connections, required hardware encryption methods, and the like.

FIX Versions

It is important that at the outset of the document the firm describe their support for varying versions of the FIX Protocol. Most firms support at least FIX 4.0, some support more than just this one version. Any differences between message types, or support for a certain message type only starting with a specific version of the Protocol, will be dealt with later in the document.

Encryption Support

This section may contain information about the encryption requirements stipulated by the firm. For example, a firm might require any Internet based connectivity to be encrypted using a specific implementation, such as PGP-DES-MD5 as described in the FIX Protocol specifications. In addition, a firm would list any supported or unsupported encryption mechanisms.

Duplicate and Resend Message handling

While the FIX specification is detailed in describing required handling of potential duplicate information, some firms choose to implement additional safety checks to protect themselves and the client they connect with. This section is the place to detail any such implementation.

For example, firm SELL will know, and assume the counter party knows, that tags 43 and 97 can indicate potentially duplicate information, either contained within a message with the same sequence number, or in a message with a new sequence number. The rules in processing these messages are detailed and mostly clear, however, firm SELL might decide to improve on the session level handling of duplicates, and institute a rule as follows:

If a message is received from counter party BUY today that shows the following identical fields it will be considered a duplicate, and will be excluded from further processing: Symbol (55), Side (54), and ClOrdID (11).

This rule would be implemented one level above the session layer, and serves as an additional safe guard against duplicate information.

Start of Day / End of Day Procedures

In many cases, a publisher of a rules of engagement document will describe here the ways a FIX session will be started and terminated. Information reflecting the roles and responsibilities of each counter party to the connection can be found here.

For example, a firm might decide to initiate all connections, and not accept any incoming requests for a TCP socket. Additionally, a schedule will be defined here outlining the minimum down time of the firm's infrastructure to accommodate the roll-over of sequence numbers. Some firms allow End of Day (EOD) to run at any time during the day.

Counter Party Identification

Every party to a FIX connection generally has their own way of identifying originator and destination for each connection. In this section, you are likely to find information about the preferred way of identification, such as values for SenderCompID (49), SenderSubID (50), TargetCompID (56), TargetSubID (57), and any OBO (on-behalf-of) ID values required or supported.

Failover Procedures

Many firms operate two or more production machines for FIX connectivity. In some cases, network equipment is installed that make the number of machines at the counter party transparent to the other side in that a virtual IP address exists to which connection request are issued or from where they originate.

Usually, when a machine handling a FIX connection fails, the connection will drop. While a brief interruption of service may result, generally all it takes to get back to normal operating conditions is to reconnect, and sync up sequence numbers (resend any messages generated but not received previously).

It helps if this section contains any procedures to follow in case of a failure of hardware or telecom equipment describing the above processes in as much detail as possible.

Definition of Security ID Conventions

For any trading system, the correct identification of securities in a FIX message is of utmost importance. There are several fields within each FIX message, incoming or outgoing, that allow for identification of securities. A rules of engagement document should specify which symbology is preferred, and, if more than one is supported, which conventions are acceptable.

For example, Symbol (55) might be required in the implementation, but the last word in identity and validation of the security might be performed based on the combination of SecurityID (48) and IDSource (22) to avoid problems with mistyped symbols. Additionally, some other fields might be accepted in an incoming message, but remain unused for validation or identification purposes.

Additionally, there are cases in international symbology where an ID number describes a security listed in more than one location (for example, ISIN numbers are not exchange specific. Rules governing the handling of such cases should be outlined in this section as well.

Lastly, not all ID sources might be accepted or understood by the party, so it is a good idea to list the acceptable forms of SecurityID (48) here as well.

Business message types

It is not always practical or desirable for a counter party to support or even accept all FIX message types. For example, a sell side firm might not accept list orders, but single orders only. This section contains the "meat" of the rules of engagement as it describes the messages supported, any modifications or customizations desired to properly process the message, and the like. A possible list of business message types detailed in a rules of engagement (from a sell side perspective) could include the following items:

• Indications of Interest (out)
• Single Orders (in)
• Day Orders (in)
• Multi-Day Orders (in)
• List Orders (in)
• Day Orders (in)
• Multi-Day Orders (in)
• Order Modify Requests (in)
• Order Cancel Requests (in)
• Order Cancel Rejects (out)
• Don't Know Trade (in)
• Order Status Requests (in)
• Report Busts and Corrections (out)
• Allocations (in)
• Allocation Acks (out)

In addition to the business message types accepted this section could include any conventions for single fields within the business messages, such as the use of the following:

• Account (1)
• HandlInst (21)
• OrdType (40)
• Price (44)
• Text (58)
• TimeInForce (59)

For example, some firms require a certain value to be contained in the Account (1) field for every message received, others only support certain order types (40), and some firms may not accept multi-day orders. This is the area of the rules of engagement to list any requirements of for specific field values.

Test scripts

In order to ensure safe and continuous operation of any system, particularly mission critical transaction handling components, testing is highly recommended. At the time of this writing, no formal standard for certification of FIX engine technology and abilities exists; however, many firms have created specific testing scripts to be executed by a newly connected counter party. This is the section to describe the test bed environment along with any specifics that would help quickly implement the testing effort. The current version of the FIX Protocol (4.4) contains an extensive amount of material that describes the standardized changes in order state for a number of scenarios, along with expected behaviors for session level state changes. These parts of the official specification should form the basis upon which any testing procedures are built.

Examples and Glossary

A really well executed rules of engagement document contains sample message sets that can be used for testing, or that describe in more detail the instructions given earlier. For many implementers, seeing the actual message shortens the learning cycle tremendously. Another good idea is a short but precise guide to language used in the document. For example, some people might understand "Cancel/Replace;" others might mean "Modification," with the ensuing consequences in changing order id and other parameters in a message.

Document Status: FPL's Global Steering Committee has approved this document for release on an online basis to FPL members only. This is the first edition of the Implementation Guide. The Global Fixed Income Committee, as sponsor of this Guide, advises members that the Guide may undergo frequent revision in format, content, or style in the coming months. Among these revisions may the system for assigning edition or version identifiers to the Guide. Whenever the Guide is revised the Global Fixed Income Committee will endeavor to notify all members through the FPL Program Office.

FIX Protocol Session or Admin messages tutorial

 FIX Protocol Session or Admin messages tutorial

FIX Protocol Session or Admin messages tutorial

I have been working in FIX protocol for almost 5 years when I started working on FIX protocol I looked upon internet for some good tutorial which could supplement or complement lengthy FIX protocol specification there was nothing at that time so when I started my blog I thought to write about my own experience in FIX protocol as short, clear and concise tutorial format. Since I like question answer type of knowledge sharing too I have written some blog post on FIX protocol Interview questions you may find it interesting.

In today’s FIX tutorial we are going to have a look on FIX protocol session level messages. As you guys may know all FIX messages can be broadly classified in two categories Admin messages also called session level messages and Application messages which include Trade, pre trade and post trades messages.  Understanding of how FIX session works is very important because until you know the fundamental of FIX Sequence number, how does FIX session gets connected , what are the sequence of messages that flows between Sender Fix Engine and receiver FIX engine you won’t be able to quickly identify any problem related to FIX protocol.  FIX specification is very clear about what should FIX engine do on various FIX session connection / disconnection scenario.

Just to revise as per FIX protocol first Sender FIX Engine and receiver FIX engine connects to each other on TCP/IP protocol on specified IP and Port via leased line , Radianz link , Virtual Private network(VPN) or via internet. Once TCP Socket level connectivity established Sender application sends Logon (fix tag 35=A MsgType=A) with agreed SenderCompID (fix tag 49) and TargetCompID (fix tag 56). Receiver FIX engine receives this message and authenticate Sender FIX Engine client based upon SenderCompID (fix tag 49) and TargetCompID (fix tag 56) ,if client is authenticated successfully then receiver fix engine replies with same sends Logon (fix tag 35=A) message and connection is successfully established and then both FIX engine will send Heartbeat messages (fix tag 35=0) at specified  heartbeat interval to keep connection alive. In case receiver FIX engine is not able to authenticate client it will send a Logout message (fix tag 35=5) and connection will be terminated though socket connection will still be there. Receiver FIX engine can also send Logout message (fix tag 35=5) if it receives fix message with sequence number lower than it is expecting.

-->





Now let’s see each of session level or Admin messages in little detail. You can always refer FIX protocol specification document and that is recommended also to get complete description of each of these messages.
Some important Session level or Administrative messages specified in FIX specification are following:

Heartbeat:
Heartbeat messages are denoted by MsgType=0 in financial information exchange (FIX) Protocol. Both FIX Session Initiator and FIX Session Acceptor sends each other Heartbeat messages to keep FIX session alive on a interval defined by Heartbeat Interval which is usually 30 or 60 seconds. If you see Heartbeat message (FIX tag 35=0) in your FIX Engine log file means your FIX session is up and connected.

Logon:
Logon message is denoted by FIX tag 35=A and it is used to send login message from FIX initiator. As per FIX Protocol once TCP connection between FIX Initiator and FIX Acceptor got established, FIX initiator sends Logon message (tag 35=A) with pre agreed SenderCompID (tag 49) and TargetCompID (tag 56) and with Sequence No (FIX tag 34) expecting by FIX Acceptor. When FIX Acceptor receives Logon request (MsgType=A) it authenticate FIX session based on CompID specified in FIX Message and Sequence No and reply back with either Logout (tag 35=5) message or Logon(tag 35=A)  message based upon result of authentication.

Resend Request
Resend Request (FIX tag 35=2 or MsgType=2) is used for asking of retransmission or replay of lost messages during transmission or due to incorrect sequence number. It’s normally sent by the FIX Engine which is receiving message to initiate the retransmission of messages. FIX Engine uses Resend Request (tag 35=2) if a sequence number gap is detected or if FIX Engine of receiving application lost a message or as a part of initialization process to make sequence number in sync.

Resend Request (FIX tag 35=2 or MsgType=2) can be used to request a single FIX message, a range of FIX messages or all FIX messages subsequent to a particular FIX message.

Its worth noting that sending FIX Engine may like to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has been passed since it was originally sent, the sender FIX Engine may not wish to retransmit the order since market dynamics an price etc might have been changed also this may result in stale order reject which is done by Order Management Systems (OMS). (The Sequence Reset (FIX tag 35=4 or MsgType=4) Also called as Gap Fill is used to skip FIX messages that a sender FIX Engine does not want to resend.)

It is mandatory that the receiving FIX Engine process messages in sequential order, e.g. if FIX message number 11 is missed and 12-13 received, the application should ignore 12 and 13 and ask for a resend of 11-13, or 11 -0 (0 denotes infinity). Second approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides of FIX Engines are simultaneously attempting to recover a sequence number gap.

Test Request
In financial information exchange also called FIX Protocol Test Request is denoted by FIX tag 35=1 or MsgType=1. Test Request FIX Message is used by FIX Engine to forces a heartbeat from the opposing FIX Engine. The Test Request (FIX tag 35=1) message checks sequence numbers or verifies communication line status. The opposite FIX Engine responds to the Test Request Test Request (FIX tag 35=1) with a Heartbeat (FIX tag 35=0) containing the TestReqID (FIX tag 112).

The TestReqID FIX tag 112) verifies that the counterparty FIX Engine is generating the Heartbeat (FIX tag 35=0) as the result of Test Request (FIX tag 35=1) and not a normal timeout. The opposite FIX Engine includes the TestReqID (FIX tag 112) in the resulting Heartbeat (FIX tag 35=0). Any string can be used as the Heartbeat (FIX tag 35=0) (Some fix engine generally uses a timestamp string).

Session Level Reject
In financial information exchange (FIX) protocol Session level Reject or  Reject  message is denoted by FIX tag 35=3 or MsgType=3.  Session level Reject is used by FIX engine when a fix message is received but cannot be properly processed due to a session-level rule violation as specified in FIX Protocol specification document. As an example FIX Engine will use Session level Reject or a reject it receives a FIX message with invalid basic data (e.g. MsgType 35 =$) which successfully passes de-encryption, Checksum (FIX tag 10) and BodyLength (FIX tag 9) checks. As a rule FIX messages should be forwarded to the trading application for business level rejections whenever possible.

Rejected messages should be logged into log file and the incoming sequence number must be incremented by FIX Engine.

Its worth noting that receiving FIX Engine  should disregard any FIX message which  is incorrect , cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence number mismatch and a Resend Request (FIX tag 35=2 or MsgType=2) will be generated and passed to counter-party FIX Engine.

Generation and receipt of a Reject (FIX tag 3) message indicates a serious error that may be the result of faulty logic in either the sending or receiving FIX Engine.

If the sending FIX Engine chooses to retransmit the rejected message, it should be assigned a new sequence number (FIX tag 34) and sent with PossResend (FIX tag 97) =Y.

Its recommended  to describe the cause of reject in the fix tag  Text (FIX Tag 58)  which then can be used by receiving FIX engine or developer to identify actual cause of Session level reject  (e.g. Price tag is missing in Limit Order).

Below are some scenarios where session-level Reject (FIX Tag 3 or MsgType=3) can be used.

CompID problem: Either FIX Initiator or FIX Acceptor is sending incorrect SenderCompID (tag 49) and TargetCompID (tag 56).

Invalid MsgType: Either FIX initiator or FIX Acceptor is sending MsgType other than specified in FIX Specification for that particular FIX Version e.g. FIX4.2

Incorrect data format for value: If a FIX tag has a data type Timestamp and FIX engine is sending some other data type

Required tag missing: Either FIX Initiator or FIX Acceptor is not sending mandatory FIX tag in a particular FIX message e.g. Price (FIX tag 44) missing in a NewOrderSingle (MsgType=D) message with OrdType =2 i.e. Limit Order.

Invalid tag number: Either FIX initiator or FIX Acceptor is sending any tag other than specified in FIX Specification for that particular FIX Version e.g. FIX4.2

Tag not defined for this message type: Either FIX initiator or FIX Acceptor is sending any tag other than specified in FIX Specification for that particular message type e.g. Sending TestReqID in logout message.

Undefined Tag: In case any of sender FIX engine is sending custom tag and that is not configured or supported by Revenging fix engine.

Tag specified without a value: e.g. 35= and there is no value for that particular fix tag. Its not a valid fix message and so receiving fix engine will reject it.

Sequence Reset
Sequence Reset also called as Gap fill messages is denoted by FIX tag 35=4 or FIX MsgType 35=4. It is used in response to Resend Request (FIX tag 35=2 or MsgType=2) by sending FIX engine to reset the incoming sequence number on the opposing side FIX engine. Sequence Reset message (fix tag 35=4) operates in two different modes one in which GapFillFlag (FIX tag 123) is 'Y' also called Sequence Reset - Gap Fill and second mode on which GapFillFlag (FIX tag 123) is 'N' or not present also called Sequence Reset - Reset mode. As per FIX protocol specification the "Sequence Reset (fix tag 35=4)-Reset" mode should ONLY be used to recover from a disaster situation which cannot be otherwise recovered by "Gap Fill" mode.

The Sequence Reset or GapFill message (fix tag 35=4) can be useful in the following circumstances:

1. While processing Resend Request (FIX tag 35=2 or MsgType=2) sending FIX Engine may choose not to send a message (e.g. a stale order). The Sequence Reset (fix tag 35=4) - Gap Fill can be used to fill the place of that message.

2. While processing Resend Request (FIX tag 35=2 or MsgType=2) sending FIX Engine may choose not to send a message if all the messages are only administrative or session level messages, because there is no point on resending them in that case also Sequence Reset (fix tag 35=4) - Gap Fill is used to fill the message or sequence gap.

Logout
Logout message is denoted by FIX tag 35=5 or MsgType=5 in FIX protocol specification and it is used to terminate or close any FIX session. In case receiver FIX engine is not able to authenticate client it will send a Logout message (fix tag 35=5) and connection will be terminated though socket connection will still be there. Receiver FIX engine can also send Logout message (fix tag 35=5) if it receives fix message with sequence number lower than it is expecting. The Logout message (fix tag 35=5) is used to terminate a FIX session. Termination or disconnection without the exchange of Logout message (fix tag 35=5) messages is treated an abnormal condition.

Exchange of Logout message (fix tag 35=5) before actually terminating or closing the session allows the initiator FIX engine to perform any kind of Sequence Reset (fix tag 35=4) or Gap fill operations that may be required or necessary. Logout initiator should also wait for the opposite FIX engine to respond with a confirming Logout message (fix tag 35=5) it can terminate the session in case the remote FIX Engine does not respond within a specified time period.

To read more about FINANCIAL INFORMATION EXCHANGE (FIX) protocol, see my FIX Protocol tutorial series. 

Related post:

Top 20 FIX Protocol Interview Questions

FIX Protocol Tutorial for beginners

FIX Protocol Session or Admin messages tutorial

Fix Session is not connecting how to diagnose it?

FIX Protocol Tutorial 2: Basics of FIX Protocol and FIX Engine

FIX Protocol Tutorial 4: Repeating groups in FIX

FIX Protocol Tutorial 5: Replaying messages in FIX protocol

FIX Protocol tutorial 6: Difference between Session Level and Business message Reject

FIX Protocol Tutorial 7: Difference between FIX 4.2 vs FIX 4.4 

FIX Protocol Tutorial 8: Writing your own FIX Engine

FIX Protocol Tutorial 9: Common issues on financial information exchange (FIX) Connectivity

Read more: http://javarevisited.blogspot.com/2011/02/fix-protocol-session-or-admin-messages.html#ixzz2qeVTEgIc

FIX – A Reader’s Digest

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/