Getting Familiar with MsgType (Tag 35)

As you guys must be aware that FIX message is mainly about tags. If you want to be a master of FIX Protocol then you should must remember if not all then at least some important tags. Tag 35 (MsgType) is one of the very important tag of FIX message. It indicates the type of communications between sender and receiver FIX engine.

In this post we will discuss about different types of messages between sender and receiver FIX Engine with examples. As you know, to start the communication there should must be an active connection. How can we check whether connection is active or not, or how to establish connection – that we will discuss in next post.

A FIX session is defined as a bi-directional stream of ordered messages between the FIX Engine and FIX clients with continues sequence number series.

For Clients who wish to route orders using FIX need to establish a FIX session with the corresponding FIX Engine. Each FIX session is identified by Tag 49 (SenderCompID), Tag Tag 56 (TargetCompID) and Tag 8 (FIX Version).

Session Start Up

To start-up a FIX session, client has to connect to FIX Engine via TCP/IP by using given IP address and port. Immediately after establishing the connection, client has to send Logon message with required tags and exact sequence number. Sequence No. less than expected will cause the disconnection while sequence no. greater than expected will allow connection followed by resend request.

FIX Engine requires user name and password to authenticate the session initiator (Optional).

Client has to send Logon with Tag 49 (SenderCompId) set to <CompanyID>, Tag 56 (TargetCompId) set to <Engine ID> and Tag 8 (FIX Version).

The FIX Engine accepts client's login request, then in response, FIX Engine sends FIX Logon with Tag 108 (HeartBtInt).

In case of login is failure then, FIX Engine sends FIX Logout with Tag 58 (Text) set to logon rejection cause.

Different Message Types: -

1.        35=A (Logon)

The logon message authenticates a user establishing a connection to a remote system. The logon message must be the first message sent by the application requesting to initiate a FIX session.

Eg:- [8=FIX.4.29=007235=A49=SENDERFIXENGINE56=RECIEVERFIXENGINE34=4421452=20131226-07:28:2198=0108=3010=106]

8=FIX.4.29=007235=A49=RECIEVERFIXENGINE56=SENDERFIXENGINE34=4391352=20131226-07:28:2198=0108=3010=111

The HeartBtInt (108) field is used to declare the timeout interval for generating heartbeats (same value used by both sides). The HeartBtInt value should be agreed upon by the two firms and specified by the Logon initiator and echoed back by the Logon acceptor.

2.        35=0 (HeartBeat)

The Heartbeat monitors the status of the communication link and identifies when the last of a string of messages was not received. When either end of a FIX connection has not sent any data for HeartBtInt seconds, it will transmit a Heartbeat message.

Eg:- 8=FIX.4.29=006035=049=RECIEVERFIXENGINE56=SENDERFIXENGINE34=4391452=20131226-07:28:5110=070

When either end of the connection has not received any data for HeartBtInt seconds, it will transmit a Test Request message. If there is still no Heartbeat message received after HeartBtInt seconds then the connection should be considered lost and corrective action be initiated. If HeartBtInt is set to zero then no regular heartbeat messages will be generated.

3.        35=1 (Test Request)

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 (FIX tag 35=1) with a Heartbeat (FIX tag 35=0) containing the TestReqID (FIX tag 112).

8=FIX.4.29=008835=149=SENDERFIXENGINE56=RECIEVERFIXENGINE34=4421652=20131226-07:29:04112=Appia-20131226-07:29:0410=158

8=FIX.4.29=008835=049=RECIEVERFIXENGINE56=SENDERFIXENGINE34=4391552=20131226-07:29:04112=Appia-20131226-07:29:0410=162

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 TestReqID.

4.        35=2 (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. The resend request can be used to request a single message, a range of messages or all messages subsequent to a particular message.

Note: The sending application may wish 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 elapsed since its original inception, the sender may not wish to retransmit the order given the potential for changed market conditions. (The Sequence Reset-GapFill message is used to skip messages that a sender does not wish to resend.)

[8=FIX.4.29=007735=249=RECIEVERFIXENGINE56=SENDERFIXENGINE34=4390252=20131226-07:22:527=4419916=4420310=106]

Note: It is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter 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 are simultaneously attempting to recover a gap.

• To request a single message: BeginSeqNo (7) = EndSeqNo (16).
• To request a range of messages: BeginSeqNo = first message of range, EndSeqNo = last message of range.
• To request all messages subsequent to a particular message: BeginSeqNo = first message of range, EndSeqNo = 0 (represents infinity).

5.        35=3 (Reject) – Session Level Reject

The reject message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data which successfully passes de-encryption, CheckSum and BodyLength checks. As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.

Rejected messages should be logged and the incoming sequence number incremented.

Note: The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop, which may be encountered in this situation. Generation and receipt of a Reject message indicates a serious error that may be the result of faulty logic in either the sending or receiving application.

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

Whenever possible, it is strongly recommended that the cause of the failure be described in the Text field (58).

If an application-level message received fulfills session-level rules, it should then be processed at a business message-level. If this processing detects a rule violation, a business-level reject should be issued. Many business-level messages have specific "reject" messages, which should be used. All others can be rejected at a business-level via the Business Message Reject (380) message.

Diff between application level reject and session level reject: - FixEngine will reject any message which doesn't confirm FIX protocol i.e. some mandatory tags missing e.g. MsgType with Session level reject, application will not get that message for processing, while application e.g. OMS or Execution System will reject message based on Business logic or FIX (financial information exchange) Protocol trade life cycle with application level Reject (MsgType=8 and ExecType=8).

6.        35=4 (Sequence Reset)

The Sequence Reset message 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.

Gap Fill mode

Gap Fill mode is used in response to a Resend Request when one or more messages must be skipped over for the following reasons:

• 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.
• 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 (such as Heart Beats, Test Requests), 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.

Gap Fill mode is indicated by GapFillFlag (tag 123) field = "Y". For Gap Fill mode, tag 36 (NewSeqNo) possess the value of new sequence number with GapFill flag (123) = Y. Eg: -

[8=FIX.4.29=010235=449=SENDERFIXENGINE56=RECIEVERFIXENGINE34=4420343=Y122=20131226-07:21:5252=20131226-07:22:5536=44204123=Y10=067]

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. Reset mode is indicated by the GapFillFlag (tag 123) field = "N" or if the field is omitted. In Sequence Reset - Reset mode, the MsgSeqNum in the header should be ignored (i.e. the receipt of a Sequence Reset - Reset mode message with an out of sequence MsgSeqNum should not generate resend requests).

Rules for processing all Sequence Reset messages

The sending application will initiate the Sequence Reset. The message in all situations specifies NewSeqNo to reset to as the value of the next sequence number to be expected by the message receipient immediately following the messages and/or sequence numbers being skipped.

The Sequence Reset can only increase the sequence number. If a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error. It is possible to have multiple Resend Requests issued in a row (e.g. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the series of messages as result of the Resend Request may appear as Sequence Reset-GapFill mode with NewSeqNo of 8, message 8, Sequence Reset-GapFill with NewSeqNo of 10, and message 10. This could then followed by Sequence Reset-GapFill with NewSeqNo of 8, message 8, Sequence Reset-GapFill with NewSeqNo of 10, message 10, and message 11. One must be careful to ignore the duplicate Sequence Reset-GapFill mode which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum is less than expected. If so, the Sequence Reset-GapFill mode is a duplicate and should be discarded. Eg:-

2013/12/26 14:35:12:817: FIXFormatter_SENDERFIXENGINE: SENDING RESEND REQUEST - seq# begin: 44370 end: 44382 current: 44370 to: SENDERFIXENGINE

2013/12/26 14:35:12:817: FIXConnectionData: Sending data on connection {SENDERFIXENGINE} [8=FIX.4.29=007735=249=RECIEVERFIXENGINE56=SENDERFIXENGINE34=4407552=20131226-09:05:127=4437016=4438210=106]

2013/12/26 14:35:12:820: FIXPump: Received data on connection {SENDERFIXENGINE} [8=FIX.4.29=010235=449=SENDERFIXENGINE56=RECIEVERFIXENGINE34=4437043=Y122=20131226-09:03:5452=20131226-09:05:1236=44374123=Y10=080]

2013/12/26 14:35:12:820: FIXPump: Received data on connection {SENDERFIXENGINE} [8=FIX.4.29=020535=D49=SENDERFIXENGINE56=RECIEVERFIXENGINE34=4437443=Y122=20131226-09:03:5452=20131226-09:05:1250=guest57=Algo22=555=AMX1=A121=160=20131226-09:03:5415=USD11=46504463=059=054=147=A40=138=100847=102510=059]

2013/12/26 14:35:12:821: FIXPump: Received data on connection {SENDERFIXENGINE} [8=FIX.4.29=010235=449=SENDERFIXENGINE56=RECIEVERFIXENGINE34=4438243=Y122=20131226-09:04:1252=20131226-09:05:1236=44383123=Y10=078]

2013/12/26 14:35:12:821: FIXPump:SENDERFIXENGINE: RECEIVED SequenceReset from 44370 to 44374

2013/12/26 14:35:12:821: FIXPump:SENDERFIXENGINE: RECEIVED SequenceReset from 44382 to 44383

2013/12/26 14:35:12:821: FIXPump:SENDERFIXENGINE: RECV - Resend Request Done received end seq no 44382

2013/12/26 16:45:48:009: FIXPump: Received data on connection {SENDERFIXENGINE} [8=FIX.4.29=017735=D49=SENDERFIXENGINE56=RECIEVERFIXENGINE34=4464552=20131226-11:15:4850=guest57=MDX22=555=AMX1=A121=160=20131226-11:15:4815=USD11=46506063=059=054=147=A40=138=100847=101410=112]

Except below 4 tags, every other tags should have same value in re-transmitted message.

43 = PossDupFlag – Y (Possible Duplicate) / N (Original Transmission)

122 = OrigSendingTime – Tag 60 value of original order

60 = SendingTime – current sending time

10 - checksum

7.        35=5 (Logout)

The logout message initiates or confirms the termination of a FIX session. Disconnection without the exchange of logout messages should be interpreted as an abnormal condition. Before actually closing the session, the logout initiator should wait for the opposite side to respond with a confirming logout message. This gives the remote end a chance to perform any Gap Fill operations that may be necessary. The session may be terminated if the remote side does not respond in an appropriate timeframe. After sending the Logout message, the logout initiator should not send any messages unless requested to do so by the logout acceptor via a ResendRequest.

2013/12/26 12:56:55:529: FIXConnectionData: Sending data on connection {SENDERFIXENGINE} [8=FIX.4.29=019435=549=RECIEVERFIXENGINE56=SENDERFIXENGINE34=4391252=20131226-07:26:5558=00100000001n3zh_3583- CODE: 1-208-0-34: Serious Error: Message sequence number: 44212 is less than expected sequence number: 4421410=001]

8.        35=6 (Indication of Interest)

Indication of interest messages are used to market merchandise which the broker is buying or selling in either a proprietary or agency capacity. The indications can be time bound with a specific expiration value. Indications are distributed with the understanding that other firms may react to the message first and that the merchandise may no longer be available due to prior trade.

Indication messages can be transmitted in various transaction types; NEW, CANCEL, and REPLACE. All message types other than NEW modify the state of the message identified in IOIRefID (Tag 26).