金融信息交換協(xié)議-FIX

1、 Financial Information Exchange (FIX)Financial Information Exchange (FIX)金融信息交換協(xié)議金融信息交換協(xié)議 目 錄 Financial Information eXchange(FIX)金融信息交換協(xié)議的制定是由多個(gè)致力金融信息交換協(xié)議的制定是由多個(gè)致力于提升其相互間交易流程效率的金融機(jī)構(gòu)和經(jīng)紀(jì)商于于提升其相互間交易流程效率的金融機(jī)構(gòu)和經(jīng)紀(jì)商于1992年共同發(fā)起。這些企年共同發(fā)起。這些企業(yè)把他們及他們的行業(yè)視為一個(gè)整體，認(rèn)為能夠從對交易指示，交易指令及交易業(yè)把他們及他們的行業(yè)視為一個(gè)整體，認(rèn)為能夠從對交易指示，交易指令及交

2、易執(zhí)行的高效電子數(shù)據(jù)交換中獲利。執(zhí)行的高效電子數(shù)據(jù)交換中獲利。FIX由此誕生，它是不受某個(gè)商業(yè)機(jī)構(gòu)控制的由此誕生，它是不受某個(gè)商業(yè)機(jī)構(gòu)控制的開放消息標(biāo)準(zhǔn)，一個(gè)能夠被調(diào)整組建適用于任何一個(gè)企業(yè)的商務(wù)需求的協(xié)議。開放消息標(biāo)準(zhǔn)，一個(gè)能夠被調(diào)整組建適用于任何一個(gè)企業(yè)的商務(wù)需求的協(xié)議。 FIX協(xié)議是一個(gè)消息標(biāo)準(zhǔn)，促進(jìn)與安全交易相關(guān)的信息交換，在希望進(jìn)行自動通協(xié)議是一個(gè)消息標(biāo)準(zhǔn)，促進(jìn)與安全交易相關(guān)的信息交換，在希望進(jìn)行自動通信的交易方之間進(jìn)行使用。該消息協(xié)議將支持各種商務(wù)功能。信的交易方之間進(jìn)行使用。該消息協(xié)議將支持各種商務(wù)功能。 FIX最早用于支持最早用于支持美國國內(nèi)的委托人之間基于直接信息流轉(zhuǎn)的證券交

3、易。隨著協(xié)議本身的發(fā)展，增美國國內(nèi)的委托人之間基于直接信息流轉(zhuǎn)的證券交易。隨著協(xié)議本身的發(fā)展，增加了大量的支持多邊界交易的、衍生工具及其它產(chǎn)品的數(shù)據(jù)域。加了大量的支持多邊界交易的、衍生工具及其它產(chǎn)品的數(shù)據(jù)域。FIX協(xié)議包含協(xié)議包含2個(gè)層次：會話層和應(yīng)用層。會話層與數(shù)據(jù)的通信相關(guān)；而應(yīng)用層個(gè)層次：會話層和應(yīng)用層。會話層與數(shù)據(jù)的通信相關(guān)；而應(yīng)用層定義了商務(wù)相關(guān)數(shù)據(jù)內(nèi)容。定義了商務(wù)相關(guān)數(shù)據(jù)內(nèi)容。 2006年年10月，月，F(xiàn)PL（FIX Protocol Limited）發(fā)布了）發(fā)布了FIX5.0。FIX5.0引入引入TI（the transport independence ）傳輸無關(guān)框架。）傳輸無

4、關(guān)框架。TI將將FIX會話層從應(yīng)用層協(xié)議會話層從應(yīng)用層協(xié)議中分離出來。在中分離出來。在TI框架下，應(yīng)用層協(xié)議消息可以通過任意合適的傳輸技術(shù)進(jìn)行傳框架下，應(yīng)用層協(xié)議消息可以通過任意合適的傳輸技術(shù)進(jìn)行傳送，在這里，送，在這里，F(xiàn)IX會話層協(xié)議是會話層協(xié)議是FIX應(yīng)用層消息的可選傳輸傳輸協(xié)議之一。應(yīng)用層消息的可選傳輸傳輸協(xié)議之一。FIX協(xié)議是用于封裝通訊數(shù)據(jù)包的一套規(guī)則 FIX協(xié)議存在2種語法格式： 1 “標(biāo)記=值” 語法格式 2 “FIXML語法” 語法格式同一個(gè)商業(yè)信息流適用于任何一種語法 “標(biāo)記=值” 語法格式：8=FIX.4.29=25135=D49=AFUNDMGR56=ABROKER34

5、=252=20030615-01:14:4911=123451=11111163=064=2003062121=3110=1000111=5000055=IBM48=45920010122=154=160=2003061501:14:4938=500040=144=15.7515=USD59=010=127 FIXML語法格式：語法格式： 會話層消息會話層消息:Heartbeat心跳消息管理Test Request網(wǎng)路測試請求Resend Request重傳請求Reject駁回(會話級)Sequence Reset序列號復(fù)位Logout注銷Logon登錄驗(yàn)證應(yīng)用層消息應(yīng)用層消息:Executi

6、on Report執(zhí)行報(bào)告Order - Single下新單Order Cancel Reject駁回撤單Order Cancel Request撤單請求Order Cancel/Replace Request撤單/改單請求Order Status Request狀態(tài)請求Business Message Reject駁回(商業(yè)級)FIX會話即一個(gè)在連接雙方用帶有連續(xù)序列號的有序消息雙向傳輸流。FIX會話連接由3部分組成：logon登錄，消息傳輸，和logout注銷。一般建議每24小時(shí)重新建立一次會話，同時(shí)在新的會話中設(shè)置在Logon消息中的ResetSeqNumFlag建立一套新的序列號。Bo

7、dyLength：為數(shù)據(jù)體長度，如：“abcd” 長度為4校驗(yàn)和計(jì)算：一個(gè)FIX消息校驗(yàn)和通過計(jì)算從開頭標(biāo)志8到標(biāo)志10前一個(gè)字符的每個(gè)字節(jié)和得到。然后，校驗(yàn)和被轉(zhuǎn)換為模256的數(shù)字用于傳送和比較。 標(biāo)記標(biāo)記參數(shù)名參數(shù)名中文名中文名必輸必輸8BeginStringFIX.4.2Y9BodyLength包長Y35MsgType消息類別Y49SenderCompID發(fā)送方Y(jié)56TargetCompID接收方Y(jié)34MsgSeqNum消息序列號Y43PossDupFlag復(fù)制標(biāo)志97PossResend重傳標(biāo)志52SendingTime發(fā)送時(shí)間Y (數(shù)據(jù)體部分) 10CheckSum 校驗(yàn)和YLogo

8、n消息認(rèn)證一個(gè)連接到一個(gè)遠(yuǎn)程系統(tǒng)的用戶。Logon消息必須是應(yīng)用程序用于請求初始化一個(gè)FIX會話的第一個(gè)消息。HeartBtInt（108）域用于申明產(chǎn)生心跳消息的時(shí)間間隔，連接雙方使用形同的HeartBtInt值。其值應(yīng)被雙方企業(yè)一致同意，由Logon消息發(fā)起者初始化，并被Logon接收者回應(yīng)。當(dāng)接收到Logon消息，會話接收者將認(rèn)證參與者的連接請求，并發(fā)出一個(gè)Logon消息確認(rèn)連接請求被接受。這個(gè)確認(rèn)Logon消息也能用于發(fā)起者驗(yàn)證連接已經(jīng)與對端正確建立。在接收到Logon消息后會話接收者必須立即準(zhǔn)備好開始處理消息。會話發(fā)起者可以選擇在收到Logon確認(rèn)消息前傳輸FIX消息，但推薦在收到返

9、回的Logon消息后，完成加密秘要協(xié)商后進(jìn)行正常的消息傳輸。確認(rèn)Logon消息可以用于加密秘要協(xié)商。如果一個(gè)會話密鑰被認(rèn)為是弱秘要，一個(gè)推薦的新的更加強(qiáng)狀的會話秘要將在Logon消息中返回。這僅在加密協(xié)議允許秘要協(xié)商時(shí)有效。Logon消息能用于確定支持的消息最大長度MaxMessageSize（能用于控制將大消息進(jìn)行分節(jié)的規(guī)則）。也能用于確定雙方接收和發(fā)送所支持的消息的類型MsgType。心跳消息監(jiān)控通信鏈路的狀態(tài)，用于識別一連串消息中最后沒有收到的消息。當(dāng)如果一個(gè)FIX連接的任何一方在超過HeartBtInt規(guī)定的時(shí)間間隔后沒有收到任何數(shù)據(jù)，將發(fā)送一個(gè)Hearbeat消息。當(dāng)如果一個(gè)FIX連

10、接的任何一方在超過HeartBtInt規(guī)定的時(shí)間間隔加上一些傳輸時(shí)間后沒有收到任何數(shù)據(jù)，將發(fā)送一個(gè)Test Request測試請求消息。如果在超過HeartBtInt規(guī)定的時(shí)間間隔加上一些傳輸時(shí)間后仍然沒有收到Heartbeat消息，那么應(yīng)視為連接斷開并應(yīng)采取糾錯(cuò)處理。如果HearBtInt設(shè)置為0，則不會產(chǎn)生常規(guī)的Heartbeat消息。注意，一個(gè)測試請求消息能夠不間隔HeartBtInt的值被發(fā)送，用于強(qiáng)制請求一個(gè)Heartbeat消息。Heartbeat消息作為測試請求消息的響應(yīng)，必須包含在請求測試消息中的TestReqID值，用于驗(yàn)證Heartbeat消息是測試請求消息的響應(yīng)而不是常規(guī)

11、超時(shí)的響應(yīng)。 測試請求消息強(qiáng)制對方發(fā)送一個(gè)Heartbeat消息。測試請求消息檢查序列號或驗(yàn)證通信線路狀態(tài)。對端應(yīng)用程序響應(yīng)一個(gè)包含TestReqID的Heartbeat消息。TestReqID用于檢查對端應(yīng)用是依據(jù)測試請求消息產(chǎn)生的Heartbeat消息，而不是通常的超時(shí)。對端應(yīng)用程序?qū)estReqID包含在響應(yīng)Heartbeat消息中。 重傳請求消息由接收用用程序發(fā)送用于開始消息的重傳。這個(gè)功能在序列號間隙被偵測到時(shí)，在接受應(yīng)用程序丟失消息時(shí)，或者作為一個(gè)初始化處理功能時(shí)非常實(shí)用。重傳請求消息能用于請求一個(gè)單一消息，一定范圍內(nèi)的消息，或者一個(gè)特定消息的所有后續(xù)消息。注意：發(fā)送應(yīng)用程序可能

12、希望考慮重傳消息的消息類型。如：如果在重傳序列中的一個(gè)新指令消息在其最初發(fā)送后經(jīng)過一段相當(dāng)長的時(shí)間，那么發(fā)送方可能不希望重傳該消息以提供改變市場條件的潛在可能性。（Seqence Reset-GapFill消息用于發(fā)送方不希望發(fā)送而跳過這類消息。）注意：接收程序必須按照順序處理消息。如：如果收到消息8和9，消息7丟失，程序應(yīng)忽略消息8和9，并要求重傳消息7到9，或者最好重傳消息7到0（0表示序列號無窮大）。后者，作為當(dāng)序列號出現(xiàn)混亂，雙方同時(shí)嘗試恢復(fù)一個(gè)間隙時(shí)，從當(dāng)前的某些競爭條件下快速恢復(fù)的推薦方法。1.為請求一個(gè)單一消息， BeginSeqNo=EndSeqNo2.為請求一定范圍內(nèi)的消息，

13、BeginSeqNo=請求范圍內(nèi)第一個(gè)消息，EndSeqNo=請求范圍內(nèi)最后一個(gè)消息。3.請求特定消息的所有后續(xù)消息：BeginSeqNo=請求范圍內(nèi)第一個(gè)消息，EndSeqNo=0。 當(dāng)一個(gè)接收消息由于違背會話層規(guī)則，不能被正確的處理，應(yīng)發(fā)送駁回消息。一個(gè)例子是：當(dāng)一個(gè)接收消息通過解密，效驗(yàn)和檢查，及數(shù)據(jù)體長度檢查后沒有有效的基礎(chǔ)數(shù)據(jù)（如，MsgType=&），將產(chǎn)生一個(gè)駁回消息。結(jié)果是，這些消息將傳遞給交易應(yīng)用程序，如果需要，將產(chǎn)生商業(yè)邏輯級的駁回。駁回消息應(yīng)記錄到日志中，且接收序列號應(yīng)增加。注意：接收應(yīng)用程序應(yīng)忽略任何干擾消息，不能被解析的及未通過數(shù)據(jù)完整性檢查的消息。處理下一個(gè)FIX消

14、息將導(dǎo)致檢測到一個(gè)序列號間隙并產(chǎn)生一個(gè)Resend Request消息。FIX引擎應(yīng)包含處理在此情況下的無限重傳循環(huán)。生成和接收到一個(gè)駁回消息表明一個(gè)接收或發(fā)送程序的邏輯錯(cuò)誤導(dǎo)致的嚴(yán)重的錯(cuò)誤。如果發(fā)送程序選擇重傳駁回消息，該消息應(yīng)賦予一個(gè)新的序列號值，且PossResend設(shè)置為Y。無論何時(shí)，強(qiáng)烈推薦將描述失敗原因在Text 域中描述（如，INVALID DATA（35）。如果接收到的一個(gè)應(yīng)用級消息滿足所有會話級規(guī)則，該消息應(yīng)在商業(yè)消息級被處理。如果在處理過程中檢測到規(guī)則沖突，將產(chǎn)生發(fā)送一個(gè)商業(yè)級駁回。許多商業(yè)級消息都有自己特定的駁回消息。如果沒有，則產(chǎn)生發(fā)送一個(gè)Business Messag

15、e Reject消息。注意，在收到一個(gè)商業(yè)消息，滿足會話級規(guī)則，但不能被傳送給商業(yè)級處理系統(tǒng)時(shí)，一個(gè)帶有BusinessRjectReason=“Application not available at this time”的Business Message Reject消息將被發(fā)出。 會話級駁回以下內(nèi)容從FIX協(xié)議規(guī)范中的Reject消息定義中摘抄：注意：接收程序應(yīng)忽略任何文本混亂，不能被解析以及數(shù)據(jù)完整性檢查失敗的消息。處理下一個(gè)右下的FIX消息將導(dǎo)致檢測到一個(gè)序列號間隙并產(chǎn)生一個(gè)重傳請求消息Resend Request。這種情況下，F(xiàn)IX引擎應(yīng)包含識別重傳無限循環(huán)的邏輯。FIX協(xié)議采取樂

16、觀的觀點(diǎn)。它假設(shè)一個(gè)混亂的消息是由于傳輸中出現(xiàn)的錯(cuò)誤，而不是FIX系統(tǒng)的問題。因此，如果發(fā)送一個(gè)重傳請求消息（Resend Request），該混亂消息將被正確得重傳。如果一個(gè)消息沒被認(rèn)為是混亂的，那么，推薦發(fā)送一個(gè)會話級駁回消息?；靵y消息混亂消息-發(fā)送一個(gè)重傳請求發(fā)送一個(gè)重傳請求非混亂消息非混亂消息-發(fā)送一個(gè)會話級駁回消息發(fā)送一個(gè)會話級駁回消息忽略任何文本混亂、不能被解析以及數(shù)據(jù)完整性檢查失敗的消息忽略任何文本混亂、不能被解析以及數(shù)據(jù)完整性檢查失敗的消息 什么樣的情況認(rèn)為是一個(gè)混亂消息 1. BeginString（tag#8）不是一個(gè)消息中的第一個(gè)tag或不是8=FIXT.n.m.的格式。

17、2. BogyLength（tag#9）不是一個(gè)消息中的第二個(gè)tag或沒有包含正確的字節(jié)數(shù)。3. MsgType（tag#35）不是一個(gè)消息中的第三個(gè)tag。4. Checksum（tag#10）不適最后一個(gè)tag或沒有包含正確的值。如果丟失MsgSeqNum（tag#34），一個(gè)Logout消息將被發(fā)送以終止FIX連接。因?yàn)檫@種情況意味著一個(gè)嚴(yán)重的應(yīng)用程序錯(cuò)誤。 Logout消息發(fā)起或確認(rèn)一個(gè)FIX會話的終止。沒有Logout消息交換的連接斷開應(yīng)被視為一個(gè)異常情況。在實(shí)際的關(guān)閉會話前，Logout發(fā)起者應(yīng)等待對端的Logout確認(rèn)消息的響應(yīng)。這樣可以給遠(yuǎn)端在必要時(shí)執(zhí)行一些Gap Fill操作

18、的機(jī)會。如果遠(yuǎn)端在規(guī)定的時(shí)間間隔后沒有響應(yīng)，會話可以終止。在發(fā)送Logout消息后，注銷發(fā)起者不應(yīng)發(fā)送任何消息，除非注銷的接收者通過ResendRequest消息請求發(fā)送消息。 一般情況下，一個(gè)Logout消息應(yīng)在關(guān)閉一個(gè)連接前發(fā)送。如果這個(gè)Logout消息是源于一個(gè)錯(cuò)誤條件，Logout的Text域應(yīng)提供錯(cuò)誤原因的描述，為遠(yuǎn)端FIX系統(tǒng)提供問題診斷的操作支持。這里有2個(gè)例外，推薦不發(fā)送Logout消息：1、在登陸階段，如果會話發(fā)起者的SenderCompID，TargetCompID或IP其中一個(gè)無效時(shí)，推薦立即終止會話，不發(fā)送Logout消息。這個(gè)登陸嘗試有可能使一個(gè)未經(jīng)授權(quán)的破壞系統(tǒng)的未

19、認(rèn)證嘗試，因此，企業(yè)不希望泄露其FIX系統(tǒng)的任何信息，如，哪個(gè)SenderCompID，TargetCompID是有效的，或所支持的FIX版本。2、在登陸階段，當(dāng)一個(gè)有效的FIX會話已經(jīng)被一個(gè)企業(yè)使用時(shí)，該企業(yè)的第2次連接嘗試的Logon消息被接受時(shí)，推薦會話接收者立即中斷該第2次連接嘗試，不發(fā)送Logout消息。發(fā)送一個(gè)Logout消息將冒著妨礙和影響當(dāng)前FIX連接的風(fēng)險(xiǎn)。例如：在一些FIX實(shí)現(xiàn)系統(tǒng)中，發(fā)送一個(gè)Logout消息可能會消耗一個(gè)序列號，這樣將會導(dǎo)致在一個(gè)已經(jīng)建立的FIX會話中的序列號混亂。在其他情況下，如果發(fā)送一個(gè)Logout消息不產(chǎn)生風(fēng)險(xiǎn)和安全沖突，Logout消息應(yīng)隨同描述信

20、息一起發(fā)送。 1、為新單生成一個(gè)新的ClOrdID，將新單發(fā)到 Accepter FIX網(wǎng)關(guān)。2、如果信息有問題，會收到一個(gè)駁回消息，駁回處理一般是記錄日志并通知Client端等待改正后再下單3、如果沒有問題會收到一個(gè)接收核實(shí)消息，并返回單號Order id。4、接著會收到一個(gè)Execution report消息，會返回這個(gè)單的執(zhí)行狀態(tài)：接收下單或拒絕下單。5、將Execution report中的成交量、未成交量、總數(shù)量、成交均價(jià)、最新價(jià)等信息報(bào)給算法服務(wù)器。 Connecter FIXAccepter FIX1.NewOrder: ClOrdID=G01 / Order ID = (空)2

21、.ExecutionReport: ClOrdID=G01 / Order ID = 1 ExecType = A (pending new )3.ExecutionReport: ClOrdID=G01 / Order ID = 1 ExecType=0或8(New或Rejected)2.ExecutionReport: ClOrdID=G01 ExecType = 8 (Rejected )4.ExecutionReport: ClOrdID=G01 / Order ID = 1 ExecType=1或2(Partial fill或Fill)1、為新單生成一個(gè)新的ClOrdID，將新單發(fā)到

22、Accepter FIX網(wǎng)關(guān)2、如果沒有問題會收到一個(gè)接收核實(shí)消息，并返回單號Order id3、將剛才的單發(fā)送一個(gè)撤單請求4、如果信息內(nèi)容有錯(cuò)，會收到駁回消息；否則就收到撤單核實(shí)消息PendingCancel5、最后撤單成功了會收到Execution report Connecter FIXAccepter FIX1.NewOrder: ClOrdID=G01 / Order ID = (空)2.ExecutionReport: ClOrdID=G01 / Order ID = 1 ExecType = 0 (new)3. OrderCancelRequest : ClOrdID=G02 /

23、 OrgClOrdID=G01 Order ID = 1 4. OrderCancelReject: ClOrdID=G02 OrgClOrdID=G01 OrderID=14.ExecutionReport: Order ID = 1 ClOrdID=G02 ExecType=4(Pending Cancel) OrgClOrdID=G01 5.ExecutionReport: ClOrdID=G02 / Order ID = 1 ExecType=4(Canceled) OrgClOrdID=G01 1、為新單生成一個(gè)新的ClOrdID，將新單發(fā)到Accepter FIX網(wǎng)關(guān)2、如果沒有問

24、題會收到一個(gè)接收核實(shí)消息，并返回單號Order id3、將剛才的單發(fā)送一個(gè)改單請求4、如果信息內(nèi)容有錯(cuò)，會收到駁回消息；否則就收到撤單核實(shí)消息PendingReplace5、最后撤單成功了會收到Execution reportConnecter FIXAccepter FIX1.NewOrder: ClOrdID=G01 / Order ID = (空)2.ExecutionReport: ClOrdID=G01 / Order ID = 1 ExecType = 0 (new)3. ReplaceRequest : ClOrdID=G02 / OrgClOrdID=G01 Order ID = 1 4. OrderCancelReject: ClOrdID=G02 OrgClOrdID=G01 OrderID=14.ExecutionReport: Order ID