Tuesday, April 27, 2010

FIX protocol interview questions : Part 1 - Admin/Session

Well, I just felt a need that key FAQs in FIX be documented, so that can be used for a variety of purposes, primarily during interviews to gauge a candidate. I have tried to be correct to the max, but do not guarantee it. This is what is best to my knowledge, and its good to cross check things with the FIX site and documentation available there.

1. What is buy side and what is sell side ?
Sell side is the one who earns brokerage.
Buy side is the one who pays brokerage.
buy side (institutions)
sell side (brokers/dealers)

2. What is the latest FIX version in market now?
Its FIX 5.0 SP2.
Something called FIXT.1.1 is also coming.

3. What is FIXML?
FIXML is a structured, validated Extensible Markup Language (XML) derived grammar that is encapsulated within the standard FIX message. This format leaves the FIX session handling intact and minimizes the impact to existing implementations. As an XML-derived language, FIXML messages can be validated by standard parsers and take advantage of a flexible message structure. FIXML is the FIX Markup Language for application messages. It is an XML-derived language, encompassing a series of Document Type Definitions (DTDs) which define the formal representation of FIXML messages. These DTDs will be maintained and versioned in the same manner as the FIX specification. Since FIXML is an XML-based language, it can be parsed/validated by any of the widely available XML parsers, and is positioned to evolve with the XML standard in areas such as datatype validation.

4. What version of FIXML is avlbl now in market ?
Goes hand in hand with FIX version.

5. What is FIXimate?
A tool available on fixprotocol.org to help understand FIX msgs quickly.

6. What is FIXT1.1?
With the release of FIX Protocol version 5.0 in 2006 the FIX Global Technical Committee has introduced a new framework called Transport Independence (TI). Under the TI framework the FIX Session Protocol and the FIX Protocol (the application layer messages) have been separated. This allows FIX Protocol messages to sent via any appropriate transport technology (e.g. MQ, WS-RX, message bus) in addition to the FIX Session Protocol.

7. How does the FIX header look like ?
The first three fields in the standard header are BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).

8. How does the FIX trailer look like ?
The last field in the standard trailer is the CheckSum (tag #10).

9. Repeating data groups –
Fields within repeating data groups must be specified in the order that the fields are specified in the message definition within the FIX specification document.

10 . Is encryption possible in FIX? More details.
The choice of encryption method will be determined by mutual agreement of the two parties involved in the connection. Any field within a message can be encrypted and included in the SecureData field, however, certain explicitly identified fields must be transmitted unencrypted. The clear (unencrypted) fields can be repeated within the SecureData field to serve as an integrity check of the clear data. When encryption is employed, it is recommended but not required that all fields within the message body be encrypted. If repeating groups are used within a message and encryption is applied to part of the repeating group, then the entire repeating group must be encrypted.

11. What is the field delimiter ?
The non-printing, ASCII "SOH" (#001, hex:0x01, referred to in this document as ), is used for field termination. Messages are delimited by the “SOH” character following the CheckSum field. All messages begin with the “8=FIX.x.y” string and terminate with “10=nnn“.

12. What is MultipleValueString data type? When is it used?
String field containing one or more space delimited values.
I have not seen a single scenario where it is used.

13. What are different data types in FIX –
Int, float, char, String, Boolean (Y,N)
Qty, Price, PriceOffset, Amt, MultipleValueSting, Currency, Exchange,
UTCTimeStamp (YYYYMMDD-HH:MM:SS (whole seconds) or
YYYYMMDD-HH:MM:SS.sss (milliseconds) format, colons, dash, and period required)
UTCTimeOnly(HH:MM:SS (whole seconds) or HH:MM:SS.sss (milliseconds) format, colons, and period required.)
LocalMktDate (YYYYMMDD format)
UTCDate : YYYYMMDD date of current GMT
Data : Raw data, always preceded with length field.
(UTC – Universal Time Coordinated also known as GMT)
Month-year : char field in YYYYMM format
Day-of-month : int field with values between 1-31

14. What are sequence numbers?
All FIX messages are identified by a unique sequence number. Sequence numbers are initialized at the start of each FIX session (see Session Protocol section) starting at 1 (one) and increment throughout the session. Monitoring sequence numbers will enable parties to identify and react to missed messages and to gracefully synchronize applications when reconnecting during a FIX session.
Each session will establish an independent incoming and outgoing sequence series; participants will maintain a sequence series to assign to outgoing messages and a separate series to monitor for sequence gaps on incoming messages.

15. More about heartbeats?
The hHeartbeat iInterval is declared by the session initiator using the HeartBtInt field in the Logon message. The heartbeat interval timer should be reset after every message is transmitted (not just heartbeats).

16. Does heartbeat/logon/logout etc msgs have seq numbers?
Like all application messages, even admin msgs have sequence number, including heartbeat. MsgSeqNum is a mandatory field in the standard message header.

17. More about ordered message processing?
The FIX protocol assumes complete ordered delivery of messages between parties. Implementers should consider this when designing message gap fill processes. Two options exist for dealing with gaps, either request all messages subsequent to the last message received or ask for the specific message missed while maintaining an ordered list of all newer messages. For example, if the receiver misses the second of five messages, the application could ignore messages 3 through 5 and generate a resend request for messages 2 through 5, or, preferably 2 through 0 (where 0 represents infinity). Another option would involve saving messages 3 through 5 and resending only message 2. In both cases, messages 3 through 5 should not be processed before message 2.

18. More about Possible Duplicates?
When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request, a possible duplicate message is generated. The message will be a retransmission (with the same sequence number) of the application data in question with the PossDupFlag included and set to "Y" in the header. It is the receiving application's responsibility to handle the message (i.e. treat as a new message or discard as appropriate). All messages created as the result of a resend request will contain the PossDupFlag field set to “Y”, messages lacking the PossDupFlag field or with the PossDupFlag field set to “N” should be treated as original transmissions.
Note: When retransmitting a message with the PossDupFlag set to Y, it is always necessary to
recalculate the CheckSum value. The only fields that can change in a possible duplicate message are the CheckSum, OrigSendingTime, SendingTime, BodyLength and PossDupFlag. Fields related to encryption (SecureDataLen and SecureData) may also require recasting.

19. More about Possible resend?
Ambiguous application level messages may be resent with the PossResend flag set. This is useful when an order remains unacknowledged for an inordinate length of time and the end-user suspects it had never been sent. The receiving application must recognize this flag and interrogate internal fields (order number, etc.) to determine if this order has been previously received. Note: The possible resend message will contain exactly the same body data but will have the PossResend flag and will have a new sequence number. In addition the CheckSum field will require recalculation and fields related to encryption (SecureDataLen and SecureData) may also require recasting.

20. How can we maintain a 24 hour session, using ResetSeqNumFlag?
What is the process to establish a new set of sequence numbers?

Both sides should agree on a reset time and the party that will be the initiator of the process. Note that the initiator of the ResetSeqNum process may be different than the initiator of the Logon process. One side will initiate the process by sending a TestRequest and wait for a Heartbeat in response to ensure of no sequence number gaps. Once the Heartbeat has been received, the initiator should send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The acceptor should respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. At this point new messages from either side should continue with MsgSeqNum of 2. It should be noted that once the initiator sends the Logon with the ResetSeqNumFlag set, the acceptor must obey this request and the message with the last sequence number transmitted “yesterday” may no longer be available.

21. What care to be taken before logging off/closing the session?
It is recommended that before sending the Logout message, a TestRequest should be issued to force a Heartbeat from the other side. This helps to ensure that there are no sequence number gaps.

22. More about standard message header?
Following are mandatory fields –
BeginString[8], MsgType[35], BodyLength[9]
SenderCompId[49], TargetCompId[56]
MsgSeqNo[34], SendingTime[52]

23. More about standard message trailer?
CheckSum[10] is the only mandatory field, and it is the last field.

24. How is data integrity maintained?
Using BodyLength[9] and CheckSum[10] fields.
BodyLength is calculated starting from field starting after BodyLenght and
before CheckSum field.
CheckSum is calculated from ‘8= upto SOH before the checksum field.
Binary value of each character is calculated and compared to the LSB of the calculated value to the checksum value.
If the checksum has been calculated to be 274 then the modulo 256 value is 18 (256 + 18 = 274). This value would be transmitted a 10=018 where
"10="is the tag for the checksum field.

25. If there’s no heartbeat for a long time, how can my gateway check if the connection is active or not?
Send a TestRequest, to which the other party must respond with a heartbeat
with same TestReqId.

26. What all msgs you can respond with, when you receive a resend request?
Retransmit the requested msgs in order, with orig seq no, and PossDupFlag=Y
Issue a seq-reset-GapFill with PossDupFlag=Y, to replace the retransmission of admin and app msgs.
Issue a seq-reset-reset with PossDupFlag=Y to force seq no synchronization.

27. Can HeartBtInt be ever zero?
If HeartBtInt is set to zero, then it means, the two parties have agreed to have no hearbeats. But TestReq will still force a heartbeat.

28. Logon msg is responded with Logon[A] only.

29. There are two modes of seq reset msg –
Gap Fill : GapFillFlag=Y
Reset : No GapFillFlag, or GapFillFlag = N.

30. Different Admin MsgTypes –
HeartBeat 0
Logon A
Logout 5
TestRequest 1
ResendRequest 2
SeqReset (2 modes) 4
Reject 3


  1. Dear Sir,
    Thanx for providing the information on FIX protocol. I want to contact u but i don't know u r mail id. This is my mail id: madhumfm@gmail.com

  2. Dear Bloger,

    I have gone through your Blogs and it really help me lot to understand the basic of trading . I have been working as an IT/QA analyst for 5 yrs in the financial industry but never got a chance to work in any equity, FI etc trading applications. It is very hard to get into trading application QA testing without prior experience.

    Can you please help me or guide me to understand FIX messaging protocol, order management system and execution system visually or any article text available or any reference books with picture? I have an interview coming soon as a QA analyst (who having good knowledge on FIX messaging protocol and OMS) for e-trading application.

    Also please let me know if any certification course is there for FIX protocol/ Trading expert QA .

    I would be really thank full to you .

  3. Hi

    I like this post:

    You create good material for community.

    Please keep posting.

    Let me introduce other material that may be good for net community.

    Source: QA analyst interview questions

    Best rgs

  4. Hi

    Tks very much for post:

    I like it and hope that you continue posting.

    Let me show other source that may be good for community.

    Source: Administrative analyst interview questions

    Best rgs