What is FIX Protocol
- FIX (Financial Information eXchange) protocol is an electronic communication protocol which was first authored in 1992.
- It is now the de facto standard used for pre-trade and trade communications in the global market exchanges.
- It is expanding its usage into post-trade and other security types such as commodities, forex, fixed income, and derivatives.
- There are different versions of FIX, but the most standard ones used are FIX 4.2, FIX 4.4, FIX 5.0
- FIX is independent of any communication protocol or physical medium, but it is most typically ran over TCP.
FIX Message Format
- The general format of a FIX Message is : Standard Header + Message Body + Standard Trailer
- Each message is a stream of tag-value pair separated by a delimiter character, the non-printing ASCII "SOH" (#001, hex: 0x01) (In the example message below, | is used for SOH)
- Fields inside repeating groups must be in the order that the fields are specified in the message definition
- Example message: 8=FIX.4.4 | 9=176 | 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 |
Standard Header
- Contains the metadata of the message and administrative level information - such as FIX version, bodylength, identity of the firms involved, etc
- Required tags vary in different FIX versions, but usually include below tags
- Tags can be in different orders in FIX messages, but the 3 tags (8-BeginString, 9-BodyLength, 35-MsgType) should be the first, second and third tag of any message.
| Tag |
Field Name |
Description |
| 8 |
BeginString |
Identifies the beginning of a new message and the FIX version used |
| 9 |
BodyLength |
Message length in bytes |
| 35 |
MsgType |
Defines the message type |
| 49 |
SenderCompID |
Identifies the firm sending the message |
| 56 |
TargetCompID |
Identifies the firm receiving the message |
| 34 |
MsgSeqNum |
Used to ensure the orders of the messages received and sent |
| 52 |
SendingTime |
Time of message Transmission |
Message Body
- Contains data specific to the particular message (particular MsgType)
- Each message type has different set of tags required and used - these restrictions may vary for different systems
- Same tag cannot appear twice, instead of repeating group tags
Simple NewOrderSingle <D> Message (Does not include all tags)
| Tag |
Field Name |
Example |
Required? |
Description |
| 35 |
MsgType |
D |
Y |
Message type in standard header (D for NewOrderSingle) |
| 11 |
ClOrdID |
12345678 |
Y |
Unique identifier of the order |
| 48 |
SecurityID |
1234 |
N |
The ID of the target security - requires tag <22> if specified |
| 22 |
SecurityIDSource |
|
N |
The source of the security ID |
| 55 |
Symbol |
AAPL |
N |
Simple human-friendly symbol of the security |
| 54 |
Side |
Sell |
Y |
Order side (Buy, Sell, Short Sell, etc) |
| 60 |
TransactTime |
UTC |
Y |
Time this order was initiated |
| 38 |
OrderQty |
10000 |
Y |
Quantity of the order |
| 40 |
OrdType |
Market |
Y |
Type of the order |
| 44 |
Price |
100.00 |
N |
Price of the roder - required if <40>=Limit |
Standard Trailer
- Every FIX message must end with the standard trailer
- Checksum<10> is used to ensure the integrity of the messages exchanged
- Checksum is calculated by the sender and sent together in the message
- When the receiver receives the message, it calculates the checksum again and compares the calculated checksum and received checksum
- If the checksums match, it means the message is transmitted without any loss
- The checksum is calculated by summing every byte of the message up to but not including the checksum field itself then applying a simple modulo 256 is applied to the summation