http://javarevisited.blogspot.com/2011/04/fix-protocol-tutorial-for-beginners.html 需要能访问blogspot.博主还有关于tibco的开发资料,有兴趣可参考
复制一下。 I have been writing FIX Protocol Tutorial from last few months and today I thought about doing a revision on all those tutorials. It’s very easy to read and forget about anything you have learn so periodic revision is very important and I see its important here as well. In this article I will put summary of each of my previous FIX Protocol Tutorial and give a link back to original article for further reading. This will allow any beginner or new comer to get an idea of what topics from FIX has been already covered in these tutorials and helps them to quickly navigate between those. With growing use of online trading and electronic trading for various Asset classes such as futures ,options, equities , Fixed Income and Commodities and growing number of online stock trading companies and broker in world market demand of FIX Protocol developers are increasing day by day and now I can see more jobs for FIX developer than few years back. This is a niche area and these online stock trading companies or brokers pay very good for any one who is very good knowledge of FIX simply because it’s very difficult to find a good FIX Protocol developer FIX Protocol can be used for Stock trading , futures or options trading , foreign exchange trading or commodities trading which enables a FIX Protocol developer to work on any of these area. But only source of knowing FIX is by reading detailed FIX specification provided by fixprotocol.org or by working in project which involves heavy use of FIX . There is no substitute of experience in Java or FIX Protocol and these FIX Protocol Tutorial is my aim to share knowledge and experience I have acquired by working in various high volume and low latency electronic systems based on FIX Protocol. These FIX Protocol Tutorials are random collections of my thoughts on various FIX topics and areas it doesn’t cover all aspect of FIX Protocol. If you are interested on learning any part which is not covered here please let me know and I will try to write a short FIX Protocol Tutorial on that topic You can also refer fixprotocol.org for further reference.
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.
Basics of FIX protocol and FIX Engine FIX protocol is Industry standard protocol for electronic trading , with evolution with computer technology Trading also getting Electronic and now most of the exchanges in the world are fully electronic and concept of trading floor is taken over by computers. When I was new to FIX protocol I have searched net to find a good FIX protocol tutorial but not much is available so I am trying to write my own experience in form of short FIX protocol tutorial. In this blog post I would like to share my thoughts, experience and knowledge about FIX protocol which I had acquired by working on different areas of FIX. FIX protocol is a tag value protocol where every field has a unique tag name and signify something e.g. Price (tag 44) denotes the price of a particular shares , OrderQty denotes quantity of order. FIX protocol specify different types of messages for different trading purposes e.g. for Sending an Order to exchange they used NewOrderSingle message (MsgType=35) or for Sending a Cancel to exchange they used CancelOrder message (MsgType=F). MsgType (tag 35) and they message for all purpose of trade life cycle e..g they have pre trade message ( e.g. News , Indication of Interest ) , trade message (NewOrderSingle, OrderCancelReplaceRequest , OrderCancelRequest) and post trade message (e.g. Allocation messages). To understand these FIX message client and broker, the two party involved in trading has a piece of software called FIX Engine. There are many commercial FIX engine available which is used in Industry e.g. Cameron FIX Engine, NYFIX's Appia etc. Messages on FIX protocol can be broadly classified into two type’s first Session level message also called Admin messages and Second Application level messages. Session level messages is uesd to establish FIX session between two FIX engine and Application messages are messages which is meant for some purpose e..g NewOrderSingle message which is used to send order via FIX. MsgType (tag 35) is an important tag in FIX protocol which is used to uniquely identify a FIX message. Every single message in FIX protocol must have corresponding MsgType otherwise FIX engine will reject those messages saying it’s not a valid FIX message. As per FIX protocol connection between two FIX engine is called FIX session and every FIX session has pre agreed host/port and comp id. Since a single FIX engine can be used to server multiple clients on broker side every client is uniquely identified by combination of IP , port and there Comp IDs , Comp IDs are combination of SenderCompID and TargetCompID which are two separate tag in FIX protocol. Once FIX Session established now client can send Orders via FIX and broker then send it exchange for execution. I will try to keep it updated with relevant information, please ask if you have any questions, doubt etc. Happy learning and welcome to FIX protocol world
FIX protocol tutorial : Fix Session is not connecting how to diagnose it ? Please vote +1 if you like this post In this blog post of FIX protocol tutorial series I would like to share my experience with connectivity issues around Fix Engines. to exchange message or say to trade electronically clients connect to broker using FIX protocol and for that they use FIX Engine. In FIX protocol connection between two FIX Engine is refereed as FIX Session and we normally say whether FIX Session is connected or not connected. FIX Session normally have there start time , end time and EOD time (End of day time) also called TradingSession start time , Trading Session End Time and Trading Session EOD time. Fix Session Start time is the time when FIX Engine tries to connect each other , to connect successfully both client and broker must have agreed on Fix Session start time and there FIX engine must be running on that time to make them connect to each other. Here I will mainly discuss issues I have faced during FIX Session establishment These are very classic problems and should I say most common problem working with FIX protocol and almost everybody face this problem in there day to day work and has there own way to figure out what exactly is wrong and how to fix that. here I am listing some guideline or say an approach for people who just started working on FIX protocol to figure out what is wrong and how to fix that hope this would help specially to newcomers on FIX protocol. As per FIX protcol FIX Engine connects to each other over TCP connection on agreed host and port that's why first check in your log that if there is any logon message 35=A ,if there is no logon message something is wrong on TCP(socket ) level and TCP connection between client FIX Engine and broker Fix Engine has not been established. to verify this just check whether your host is connected to broker host or not by issuing following command. netstat -a | grep port (port is the one which you are using to connect to broker) if you don't see a connection ESTABLISHED means no TCP connection has been established between your host and broker host and something is wrong either with broker FIX engine host or network. Now check if broker host is pingable or not , to check broker host is alive and not down. you can use "telnet" command for checking that. telnet hostname port (here hostname and port is broker host and port) if you just see "trying ........." means host is not reachable and something is wrong with network may network link issue or any firewall rule issue, you need to involve network team here for further diagnosis. Now come to other part , in case you see logon message (MsgType=A or 35=A) in your log and still session is not establish then check for logout message (MsgType=5 or 35=5) by seeing Text(tag 58) here you can figure out why session is not connecting may be sequence number mismatch. Now there could be two reason : 1) Either broker is logging you out because you are sending sequence no less than what broker is expecting.In this case you need to reset your Outgoing sequence Number to what broker is expecting. 2) In case your Fix engine is logging out broker because broker is sending sequence number less than what your Fix Engine is expecting ,In this case you need to reset your Incoming sequence number. Sequence number reset can also be done on broker side in opposite way you are doing but before doing that intranet you need to think why sequence number got mismatched and in case of any replay there would not be any side effect.
FIX Protocol repeating group In this FIX protocol tutorial I am going to share my experience about FIX repeating block or group. This is fundamental concept of FIX protocol and used to carry repeating data. Correct understanding of various available FIX repeating groups e.g. PartyID block, Allocation repeating group etc is very important for writing FIX based software. In this FIX tutorial I will explain about how to parse a repeating group, how to prepare a repeating group and how to understand a repeating group. If you like to know more about basic concepts in FIX protocol then you may find my FIX Protocol tutorial interesting. In FIX protocol when a group of tags appear multiple time in a FIX message they are called repeating group. These are essential to denote repeating entity in a FIX message e.g. take an example of PartyID repeating group which is used to denote Party trading on ID (India, Korea, Taiwan, China etc) market. I will keep our discussion around this particular repeating group to illustrate different points. PartyID repeating group is made of following tags: 453 NoPartyIDs 448 PartyID 447 PartyIDSource 452 PartyRole Every repeating group starts with a particular tag which specifies how many repeating tags are present within repeating group e.g. in case of PartyID repeating group NoPartyIDs(tag 453) denotes how many Party ID repeating entries are present in the message for example NoPartyIDs=2 will state two Parties are present that there are two repeating groups are present in the message also such tag must be come immediately before start of repeating group entries for example in case of PartyID block NoPartyIDs must come before repeating tags e.g. PartyRole According to FIX protocol each entry of a repeating group should have a specific field which in turn identifies the beginning of a group new entry. This field must occur in raw message before any other tag from a single repeating group entry. In other words, these fields separate repeating group entries from each other. In case of PartyID block see tag 448 PartyID which is first tag of repeating group and mark start of one group and end of other. Important aspects of FIX repeating group’s structure: Well defined FIX messages assume all tags of a repeating group come in a particular order and appearance of any tag which doesn't belong to repeating group (according to the FIX specification) automatically indicates the end of the repeating group. Subsequent further appearance of tags from the repeating group is not allowed by the FIX Standard. Repeating group inside repeating group As per FIX protocol specification it is possible for repeating groups to appear inside of another repeating group on this case all entries of the inner repeating group belong to the single entry of the outer repeating group, they are commonly referred as SubIDs e.g. in PartyID instance block we could have another repeating group called NoOfSubIDs which is made of SubIDType and SubID. The number of instances of repeating group must match with the value specified by Number tags e.g. NoPartyIDs, otherwise FIX Engine will not able to understand FIX message will reject as malformed FIX message. Parsing of repeating group While parsing a repeating group we must consider two important tag 1) Number tag (NoXXX) e.g. NoPartyIDs to check how many repeating groups are present 2) Finding the leading tag which mark start and end of repeating group. Generally every Repeating group has a particular tag which is used as marker tag but in most cases they follow the order specified in FIX specification. But there is no hard line on that in most cases a FIX messages parser use Number tag to identify number of repeating group and then typically use the occurrence of the first documented tag of the repeating group to determine start and end of repeating group. Formatting a FIX message with repeating group It’s good to follow the order of tags specified in the FIX Message specification while constructing a repeating group that allows FIX parser to use the first tag specified in FIX documents as marker tag for start and end of repeating group. In Summary -- When group of tags appear multiple times in a FIX message we call them repeating group. -- Number tag is a leading tag which specifies how many repeating groups are present in the FIX message e.g. NoPartyIDs -- First tag specified in FIX Message specification is used as marker tag to mark start and end of a FIX message. -- No of repeating groups must match with the number specified by No### tag e.g. NoPartyIDs -- Follow the order of tags specified in the FIX Message specification while constructing a repeating group -- A Repeating group can contain another repeating group within it. -- PartyID blocks are introduced in FIX 4.3 so it will not work on earlier FIX protocol versions.
Replaying messages in FIX protocol In FIX Protocol two FIX engines communicate with each other using FIX messages and every FIX messages is assign with unique sequence number denoted by tag 34. Apparently every FIX engine has two sequence numbers Incoming Sequence Number (which FIX engine is expecting from counter party) and Outgoing Sequence Number (which FIX engine is sending to counter party). This sequence numbers along with rules specified in FIX protocol technical specification ensures that no FIX engine should lose any FIX messages in the event of any disconnect. In this FIX Protocol Tutorial we will discuss some scenarios where disconnect between two FIX Engine occurs and how they recover from that situation. Normally disconnect and reconnect can cause replay of messages which would be require from either party e.g. either client or broker based upon who has higher sequence number. This FIX Protocol Tutorial is in continuation of my earlier tutorial FIX Protocol Session or Admin messages tutorial and Difference between FIX 4.2 vs FIX 4.4 in FIX connectivity. FIX Protocol Tutorials for Beginners Now let’s see few scenarios where replay of FIX messages can occur: 1) If End of Day (EOD) didn’t run for any of FIX engine: Every FIX session has some EOD or End of day timings usually some time after market close, on which they reset sequence number both incoming and outgoing to 1/1 and starts fresh day. If by any chance FIX EOD doesn't happens on either side then both incoming and outgoing sequence number doesn’t reset to 1/1 on that side and both FIX engine will be out of sequence and when next day when they start connecting to each other logon will not be successful, then client FIX engine keeps sending logon message every time increasing sequence number until the broker (acceptor) fix engine accepts the connection. once broker fix engine accept the connection it will reply back with its outgoing sequence number which is not 1 and could be 400 based on number of message yesterday. FIX Protocol Session and Admin Tutorials Since client fix engine incoming sequence number is still 1, it would send a resend request for messages from 1 to 400 and broker will replay those messages. These replay messages could be the trades of yesterday. So to avoid such scenario its best to have your End of Day job runs on time agreed between broker and client and you should have an alert when it failed. if you fix engine provides supports to manual change of sequence number then you can manually adjust those as well. Normally commercial FIX engines like NYFIX Appia supports EOD operation in process itself but if your FIX engine doesn't support EOD then you could setup an Autosys or unix cron job to delete the persistence files related to sequence number so that when process comes up again next day it will create new persistence file with sequence number 1/1. 2) Due to network issues connection between Sender FIX Engine and Receiver FIX Engine has been lost and after issue resolved when they try to reconnect they might be Out of sequence. 3) Sender or Receiver FIX Engine goes down due to Host Failure, In this event also when they try to reconnect each other validation of Sequence number will be done and replay will happen if any of have dropped any messages. 4) Due to restart of either Sender or Receiver FIX Engine. Also its worth noting that to handle replay of FIX messages properly FIX protocol provides two special tag PossDup (fix tag 43) and PossResend (tag 97) which suggest the receiving fix engine that these message has been sent earlier.
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. You can also check Session level messages in FIX protocol to learn more about FIX protocol Sessions.
FIX 4.2 vs FIX 4.4 FIX protocol has evolved over time; it’s now more than a decade it’s started by Fidelity and Solomon Brothers. FIX connectivity is the most popular connectivity solution exists for trading whether its equities, futures, options or fixed income or even foreign exchange (FX). FIX protocol has dominated the market and become as standard solution for any market or broker which is trying to develop connectivity with market within a short period of time because of complexity of native exchange api and lack of support FIX protocol come as handy. To develop fix connectivity you need to agree upon which FIX protocol version are you going to follow , since many fix protocol version exists e.g. FIX4.0, FIX4.1, FIX4.2 and FIX4.4 even more newer version are available but most firm use FIX 4.2 as there preferred FIX connectivity solution or you can say still most widely used version is FIX 4.2 , many firms , clients , hedge funds , pension funds still use it for online trading but even after launch of more advance version it still remains the popular one. On advance side FIX 4.4 is getting popularity. In this short discussion I am highlighting some of the difference between FIX 4.2 and FIX 4.4. Two most popular FIX protocol versions you can check FIX specification for more detail and some other difference which exits. FIX specification are available on http://www.fixprotocol.org you can download pdf version of these specification and can look before developing your FIX connectivity. There are many differences between these two versions of fix protocol, some of them I am highlighting here. 1) There was tag called ExecTransType (tag 20) which was there in FIX 4.2 and now merged to ExecType tag 150 into FIX4.4, this tag used to define the nature of execution received from the exchange or broker. 2) Replaced the use of the QuantityType (tag 465) field with new QtyType (tag 854) which contains a re-organized/consolidated set of values. 3) Removed various Settlement Instructions-related fields. 4) Added "Quote Response" to list of messages for which Quote Status Report message is the appropriate response. Establishing FIX connectivity is challenging if it involves custom fix tags, these are the tags which are not defined by FIX protocol but used by many firm or between client and broker for carrying some extra information which is agreed upon that. FIX protocol allows you to define custom FIX tags for your FIX connectivity until and unless they are not conflicting with any other FIX tags. Generally firms use tag above 10000 or 5000 to define this custom FIX tags. There are many other changes which are available in the release notes of fix 4.4 http://www.fixprotocol.org, I will add some more as I come to know which is used in day trading more often.
How to write FIX Engine using FIX Protocol Please vote +1 if you like this post Basics of FIX protocol and FIX Engine FIX protocol is Industry standard protocol for electronic trading , with evolution with computer technology Trading also getting Electronic and now most of the exchanges in the world are fully electronic and concept of trading floor is taken over by computers. When I was new to FIX protocol I have searched net to find a good FIX protocol tutorial but not much is available so I am trying to write my own experience in form of short FIX protocol tutorial. In this blog post I would like to share my thoughts, experience and knowledge about FIX protocol which I had acquired by working on different areas of FIX. FIX protocol is a tag value protocol where every field has a unique tag name and signify something e.g. Price (tag 44) denotes the price of a particular shares , OrderQty denotes quantity of order. FIX protocol specify different types of messages for different trading purposes e.g. for Sending an Order to exchange they used NewOrderSingle message (MsgType=35) or for Sending a Cancel to exchange they used CancelOrder message (MsgType=F). MsgType (tag 35) and they message for all purpose of trade life cycle e..g they have pre trade message ( e.g. News , Indication of Interest ) , trade message (NewOrderSingle, OrderCancelReplaceRequest , OrderCancelRequest) and post trade message (e.g. Allocation messages). To understand these FIX message client and broker, the two party involved in trading has a piece of software called FIX Engine. There are many commercial FIX engine available which is used in Industry e.g. Cameron FIX Engine, NYFIX's Appia etc. Messages on FIX protocol can be broadly classified into two type’s first Session level message also called Admin messages and Second Application level messages. Session level messages is uesd to establish FIX session between two FIX engine and Application messages are messages which is meant for some purpose e..g NewOrderSingle message which is used to send order via FIX. MsgType (tag 35) is an important tag in FIX protocol which is used to uniquely identify a FIX message. Every single message in FIX protocol must have corresponding MsgType otherwise FIX engine will reject those messages saying it’s not a valid FIX message. As per FIX protocol connection between two FIX engine is called FIX session and every FIX session has pre agreed host/port and comp id. Since a single FIX engine can be used to server multiple clients on broker side every client is uniquely identified by combination of IP , port and there Comp IDs , Comp IDs are combination of SenderCompID and TargetCompID which are two separate tag in FIX protocol. Once FIX Session established now client can send Orders via FIX and broker then send it exchange for execution. I will try to keep it updated with relevant information, please ask if you have any questions, doubt etc.
Common issue on financial information exchange (FIX) Connectivity Please vote +1 if you like this post FIX Protocol Session Connectivity Hi guys, in this post I would like share my experience with financial information exchange (FIX) Connections which is essential to setup FIX connectivity for trading purposes. Financial information exchange (FIX) Connections used in both Client Connectivity and Exchange connectivity space (in case exchange supports financial information exchange (FIX) Protocol or you are connecting to any broker via FINANCIAL INFORMATION EXCHANGE (FIX) Protocol). So whenever a new client comes on board a new Fix Session will be needed for him who will be identified by host, port and comp ids e.g. SenderCompID and TargetCompID. Before you setup a new financial information exchange (FIX) session in your fix engine you will need to require network connectivity between client's network and your network, this usually done by network team and for security reasons some firewall rules also needs to be setup. While working on this part you may face several network connectivity issue based on what are you choosing e.g. Radianz, VPN or internet. Once network connection gets established you are ready to connect to client. Now client will send logon request (MessagType=A) with sequence no 1, 1 (At start of day) and with SenderCompID and TargetCompID agreed upon. On TCP layer first of all socket connection gets established in client IP and your IP and your Fix Engine listens on port specified. once your Fix Engine gets logon request its validate content and authenticity of client and if all is OK it replies with another logon request message. Now your financial information exchange (FIX) session is established and you are ready to send orders via this connection. Some important points to remember while troubleshooting FINANCIAL INFORMATION EXCHANGE (FIX) connectivity issues: 1) Which FINANCIAL INFORMATION EXCHANGE (FIX) Protocol versions are you using for connectivity? Both counterparties must use same version of FINANCIAL INFORMATION EXCHANGE (FIX) Protocol to establish FIX Connectivity. 2) Are you sending Correct SenderCompID (FIX Tag 49) and TargetCompID (FIX tag 50)? CompIDs must be configured on FIX Acceptor side. 3) Are you using correct IP and Port? 4) Are yor FIX Engine is sending correct sequence number which brokers FIX Engine is expecting? 5) Are you handling Resend request correctly?