1. What is the difference between OrdStatus and ExecType in FIX4.4?

OrdStatus (39) indicates the current status of the order. ExecType (150) was
introduced in 4.2 to indicate the type of execution report received. For example, if
you replace an order that is already partially filled, the order status is Partially Filled
but the ExecType for the replace confirmation is Replaced (FIX 4.2).

2. What is the minimum length of ClOrdID?

ClOrdID is a mandatory string field so the minimum length is 1. Obviously, one
character doesn't make much sense because of limited flexibility. Length is
determined by the combination of the executing party / vendor / exchange.

3. Which tag in FIX 4.4 can be used to denote Smart Order Routing?
There is no specific tag in FIX 4.4 that denotes Smart Order Routing. Brokers and/or
executing destinations can decide from different options. They can simply go with a
user-defined tag or with a standard tag such as HandlInst (21), ExDestination (100) or
SecurityExchange (207).

4. What is business message reject in FIX Protocol?

The Business Message Reject (j) message can reject an application-level message
which fulfills session-level rules and cannot be rejected via any other means. For
example, if the fix engine accepts a tag that is not supported by the FIX application,
this type of reject should be sent. See here for more detailed answer

5. What do you mean by DK (Don't know) Trade?

Don't Know Trade is a MessageType (Q) that indicates a reject of a received execution
report. For example, if you only sent one order today with ClOrdID = 10 but you
received an execution report from an execution destination for ClOrdID = 20, your FIX
application should reject this execution report.
6. Which tag is used in FIX Protocol to denote an order is for equity or for future
options?
FIX tag 167 (SecurityType) should be used to identify asset type. In FIX 4.4, you are
recommended to use CFICode (461).

7. What is tag RoutingID and why does it use in FIX Protocol?

RoutingID (217) is used to specify a specific routing destination. It is part of a
repeating group so it's convenient if you want to specify more than one destination.
It's only defined for 3 MessageTypes (Email, News, IOI); and only IOI is commonly
used. If you are asked this in an interview, well, good luck with that one.

8. Can you have different OrderID on NewOrder and Modification and Cancel
messages?
OrderID is the identifier generally provided on execution reports from the exchange /
execution destination. It should remain the same throughout a trade's lifecycle
regardless if you replace or cancel.

9. What is FIX Session?

It's linked to facilitate communication between FIX engines. At low level, it's just a
TCP/IP connection with client authentication detail. See here for a more detailed
answer.

10. What do you mean by EOD of FIX Session?

EOD stands for End of Day and indicates a reset of sequence numbers to 1/1 in regards
to an FIX session. Both incoming and outgoing sequence numbers are reset as part of
EOD. Commercial FIX engines like QuickFIX, Appia or Cameron FIX allows you to
specify different EOD time for the different client session.

11. Which FIX tag is used to denote "CARE" order in FIX Protocol?
FIX tag 21 (HandlInst) is used to indicate a CARE order. A care order is handled
manually by either a trader or someone on the execution side; therefore, 21=3
(manual) is meant for this.

12. Which tag is used to denote trading capacity of order e.g. Prop or Agency?
Up until FIX 4.2, Rule80A (47) was used to indicate order capacity. Starting in FIX 4.3,
OrderCapacity (528) was introduced.
13. How do you identify FIX version of an FIX message?
This can be done either at the FIX engine configuration level or looking at the FIX
message header. FIX tag 8 indicates FIX version.

14. Which tag is used to denote MsgType in FIX protocol?

MessageType is tag 35. Different types of messages e.g. NewOrderSingle,
OrderCancelRequest, OrderReplaceRequest are just different values of tag 35 e.g.
35=D is a new order, 35=G is modification and 35=F are cancel the request.

15. How do you handle out of sequence messages e.g. you received Canceled ack
and then a fill?
The handling of out of sequence messages varies per firm. If a cancel is received prior
to a fill, the cancel could close the order and the fill can get rejected. Some firms
will allow the fill to be processed. There really is no standard here.

16. What do you do if your session gets disconnected intraday?

Pray. This is not a good thing. Just don't reset the sequence numbers; that could lead
to a very costly error and possibly the loss of your job. Coordinate with the
counterparty to get things back to normal. Most fix engine configurations support
automatic reconnections so be careful.

17. What are heartbeat messages which tag you use to identify heartbeat
messages?
Heartbeat messages are keep-alive messages; letting the other FIX engine know that
you are still alive and active. Heartbeat is a MessageType (35=0).

18. What is LeavesQty which tag is used to denote LeavesQty in fix message?
LeavesQty (151) indicates how much quality is left to be executed on the order. If
value of tag 151 is zero it means order is fully executed and order status would be
filled, while if value of LeavesQty is greater than zero means trade is only partially
executed and order status would be partial fill.

19. What is the equivalent of tag 20 ExecTransType in FIX 4.4?

ExecTransType was removed in FIX 4.3 to eliminate confusion since ExecType also is
used to indicate the type of execution report received. The old values of
ExecTransType have been merged into ExecType (150). 20=1 --> 150=H | 20=2 -->
150=G | 20=3 --> 150=I. See here to learn more.

20. What are various FIX tags which are used for symbology identification?
The most common FIX tag used for symbology identification is tag 55 (Symbol). You
can also use the combination of tag 22 (IDSource) and 48 (SecurityID).

New FIX Protocol interview Question

I have created this new FIX Protocol Interview section to include new questions
contributed by my reader and different sources. Please let me know if you have asked
an FIX Protocol interview question which is not present here and I will include it for
community’s benefit.

1. You placed a new order and then modification and before modification a
cancel, what would be the OrigClOrdid of Cancel?
Since Modification request is not accepted yet so ClOrdID of original order will be in
place So Cancel Request must contain OrigClOrdID (Tag 41) same as ClOrdID of
Original Order.

2. You placed a new order and then place a replace request and received Pending
replace message and then a fill, what would be ClOrdID of the fill?
Since OrderCancelReplaceRequest (tag 35=F) is not accepted, ClOrdID of NewOrder
will be in force and fill will contain ClOrdID of the NewOrderSingle (35=A). It’s only
after your received ExecutionReport with ExecType=Replaced your ClOrdID of the
active order gets updated. Pending Replace is a just indication that broker or
exchange received a Replace Request but not yet accepted or rejected it.

3. You placed a new order got a partial fill and place a replace and got replaced
what would be the value of tag 39 and tag 150.
Since Order is in Partial fill status so tag 39 OrdStatus will contain partial fill and
ExecType will be Replaced I thing 150=5 and 39=1.

Read more: https://javarevisited.blogspot.com/2011/03/top-20-fix-protocol-

interview-questions.html#ixzz5NbA41aZp

FIX Protocol tutorials: Difference between Session Level Reject and Business message Reject
FIX Protocol tutorials: Difference between Session Level Reject and Business message Reject
In FIX protocol there are multiple ways of rejecting message some of them are using an Execution Report
(MsgType=8) and ExecType=8 to reject a FIX message if it can not be acceptable by exchange e.g. Sending order
for an exchange and link between broker and exchange is down. Another way of rejecting message is
OrderCancelReject (FIX MsgType=9) which is used to reject amend (OrderCancelReplace message FIX MsgType
35=G) and cancel (OrderCancelRequest FIX MsgType=F) messages if its not possible to modify or cancel original
message e.g. Sending Cancel request to an already filled order will be rejected by OrderCancelReject message in
FIX protocol.

In this FIX tutorial (that's what I called it :) it may not be a full fledged tutorial but it just an article based on my
experience which gives you basic idea about some functionality available in FIX protocol and supplement your
concept while reading lengthy but detailed FIX protocol specification) we are going to discuss another two ways or
rejecting FIX messages , these reject message represent more serious error than previous two and named as
Session Level Reject (FIX MsgType 35=3) and Business Message Reject (35=j). If you want to know more about
my FIX protocol tutorials please see this link FIX Protocol tutorial.

Both Session level Reject (FIX MsgType 35=3) and Business Message Reject (FIX MsgType 35=j) is used to reject
incoming FIX message.
Session level Reject (FIX MsgType 35=3) message should be used when incoming message cannot be parsed
correctly because of session level rule violation. for example Session level Reject(FIX MsgType 35=3) should be
used to reject an incoming FIX message with invalid basic data like unknown MsgType (e.g. MsgType 35=99) which
successfully passes de-encryption, Checksum (FIX tag 10) and BodyLength (FIX tag 9) checks. As recommended
by FIX Protocol we should always try to forward FIX message to the trading application for application or business
level rejections.

We should always log both Session level Reject(FIX MsgType 35=3) and Business Message Reject (FIX MsgType
35=j)in the FIX Engine log file so that Trade Support knows about it and inform client or broker about it also
Sequence Number should be increased as a result of session or business level reject. Session level Reject (FIX
MsgType 35=3) indicates a serious error which is due to buggy or faulty logic in either the sending or receiving FIX
engine so it the message fails on session level rule e.g. checksum or body length a session level reject should be
preferred over business level reject while business Message Reject (FIX MsgType 35=j) should be used to reject an
application-level message which passes all session-level rules and cannot be rejected by any other means.

Business Message Reject (FIX MsgType 35=j) can be used in following scenario:
1) Account not mapped correctly on broker side.
2) Unknown ID
3) Valid but unsupported message type
4) Unknown security
5) Valid but unknown message type.
6) Some of conditionally required field is not present in Incoming FIX message.

Session level Reject (FIX MsgType 35=3) can be used in following scenario.
CompID problem: Either FIX Initiator or FIX Acceptor is sending incorrect SenderCompID (tag 49) and
TargetCompID (tag 50).
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

Read more: https://javarevisited.blogspot.com/2011/02/fix-protocol-tutorials-

difference.html#ixzz5NbElbMlb

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.

Yes.

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

POSTED BY AJ AT 1:16 AM

FIX Session vs Admin Messages

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.

Read more: https://javarevisited.blogspot.com/2011/02/fix-protocol-session-or-admin-

messages.html#ixzz5NbbuasVX

FIX Protocol Session or Admin messages tutorial

I have been working on 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 into 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.

FIX Session vs Admin Messages

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 re-transmission 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 re-transmission 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 re-
sending 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 re-transmit
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.

Read more: https://javarevisited.blogspot.com/2011/02/fix-protocol-session-or-admin-

messages.html#ixzz5NbcHL73M

Javarevisited
Blog about Java, Programming, Spring, Hibernate, Interview Questions, Books and Online Course Recommendations from Udemy, Pluarlsight etc

Home

core java
 spring
 hibernate
 collections
 multithreading
 design patterns
 interview questions
 coding
 data structure
 OOP
 java 8
 books
 About Me
 Java Certifications
 JDBC
 jsp-servlet
 JSON
 SQL
 Linux
 Courses
 online resources
 jvm-internals
 REST
 Eclipse
  jQuery
 Java IO
 Java XML

THURSDAY, DECEMBER 2 1, 2017

Financial Information Exchange (FIX) Protocol Interview Questions Answers

Financial Information Exchange (FIX) Protocol Interview Questions and Answers
Some more Fix protocol interview question , I will put answer along when I'll get some time for now just questions
:)

Now I have updated it with answer, Please let me know if you have any doubt, or you have other questions, you
can also contribute by any question asked during any FINANCIAL INFORMATION EXCHANGE (FIX)
protocol interview.

Read more: https://javarevisited.blogspot.com/2010/12/fix-protocol-interview-

questions.html#ixzz5NbcYTbcC