FIX協定的目標是把各類證券金融業務需求流程格式化，使之成為一個個可用計算機語言描述的功能流程，並在每個業務功能接口上統一交換格式，方便各個功能模組的連線。
1 簡介
FIX會話協定與選擇用於電子數據傳遞的物理介質（銅纜，光纖，衛星傳輸等）及傳輸協定規範（X.25，同步，TCP/IP等）無關。它提供了一個訊息傳遞的可靠數據流。直到2006年10月，FIX會話協定與FIX套用協定一道，為用戶提供了一個可靠的傳輸FIX套用訊息的傳輸機制。
FIX會話層與數據傳輸相關，而FIX套用層則定義了商業相關的數據內容。
2006年10月，FPL’s Global Techenical Committee 引入了一個新的框架，將FIX會話層協定從FIX套用層協定分離開來。這就使套用協定訊息可以使用任何適的會話傳輸技術進行傳送，而FIX會話層協定是這些可選的協定中的一個。在新的框架下，GTC引入了一個新的別名，之後FIX會話層協定版本為FIXT.x.y，第一個版本為FIXT1.1。
2 FIXML及其它基於XML數據的傳輸
儘管FIX會話協定的標準頭（Standard Header），標準尾部（Standard Trailer）和管理訊息是基於“tag=value”語法的，但它能夠支持傳輸FIXML及其它基於XML的數據。FIXML及其它XML數據被夾在FIX標準頭與FIX標準尾部中間，並通過標準頭的XmlDataLen域指定其內容長度，XmlData域包含其具體的數據。這樣，FIX引擎可以通過多年使用的，可靠的，實時地異步傳輸機制傳送FIXML及其它XML數據。當MsgType域值為’n’時，代表傳輸的數據為FIX未在MsgType中定義的XML數據。
3 FIX訊息傳送
3.1 Sequence Numbers 序列編號
所有的FIX訊息都由一個唯一的序列號進行標示。序列號在每一個FIX會話開始時被初始化為1，並在整個會話期間遞增。監控序列號可以使會話參與者識別和處理丟失的訊息，當在一個FIX會話中重新連線時能夠優雅地進行應用程式同步。
每個會話將建立一組互不依賴的接受和傳送序列。會話參與者將維護一個賦予傳送訊息的序列和一個監控接受訊息的訊息塊間隙序列號。
3.2 Heartbeats 心跳信號
在訊息互動期間，FIX應用程式將周期性產生Heartbeat心跳訊息。該心跳訊息可以監控通信鏈路狀態及識別接受序列號間隙。傳送Heartbeat的周期間隔由會話發起者使用在Logon訊息中HeartBtInt域進行定義。Heartbeat心跳訊息的時間間隔應當在每一個訊息傳送後復位，即傳送一個訊息後，在間隔給定的時間內無其它訊息傳送則傳送一個Heartbeat心跳訊息。HeartBtInt的值應當被會話雙方認同，由會話發起方定義並由會話接收者通過Logon訊息進行確認。同一個HeartBtInt被會話雙方——登錄的發起者和登錄的接受者共同使用。
3.3 Ordered Message Processing 訊息序列處理
FIX協定假設訊息在所有參與者間完全按照順序進行傳輸。協定的實現者在設計訊息間隙填充處理時應當考慮這個假設。有兩種方式處理訊息間隙。每一個都要求所有的訊息時最後一個接收訊息的後續訊息或在維護一個所有新訊息有序序列時，請求特定丟失訊息。比如：接收方丟失了5個訊息塊中的第二個，程式能忽略第3到第5個訊息，產生一個對訊息2到訊息5的重傳請求，或者從訊息2到無窮大訊息編號的重傳請求。另外的方式是暫時存儲訊息3到訊息5，僅要求重傳訊息2。對於這兩種方式，訊息3到訊息5都不應該先於訊息2進行處理。
3.4 Possible Duplicates 可能的複製
當一個FIX引擎對一個訊息是否成功地被指定的目標接收或者當對一個重傳請求進行回響時，將會產生一個可能的訊息複製。這個訊息將用同樣的序列進行重新傳送，此時在頭部的PossDupFlag域將會被設定為‘Y’。接收端程式負責處理該重發訊息，可以作為一個新訊息進行處理，或者根據實際情況忽略該訊息。所有重傳請求的回響訊息都將包含其值為‘Y’的PossDupFlag域。沒有PossDupFlag域或者PossDupFlag域為‘N’的訊息應被當作初始傳送訊息。注意，一個PossDupFlag值為‘Y’的重傳訊息需要重新計算其CheckSum值。一個可能的複製訊息里發生變化的域包括：CheckSum，OrigSendingTime，SendingTime，BodyLength和PossDupFlag。加密相關域（SecureDataLen和SecureData）也必須被重新構造。
3.5 Possible Resends 可能的重傳
模糊的套用層訊息可能隨同PossResend標誌被重傳。當一個指令沒有在規定時間長度內進行確認或者終端用戶掛起該指令沒有進行傳送時這種方法非常有用。接收程式必須識別此標誌，並質疑其內部域以確定該指令是否在之前已經被接收過。注意，可能的重傳訊息將包含與原始訊息相同的數據體，但包含PossResend標誌和一個新的序列號。此外，CheckSum和與加密相關的域值需要重構。
3.6 Data Integrity 數據完整性
訊息數據內容的完整性可以參用兩種方式來驗證：訊息長度和效驗碼檢查。
程式通過計算BodyLength域到（並包含）在CheckSum標記（“10=”）後的分界符的字元數與在BodyLength中標示的訊息長度進行比較來完成完整性效驗。
ChekSum完整性檢查，通過計算從域“8=” 中“8”開始，包括緊跟在CheckSum標記域的分界符<SOH>每個字元的2進制和同CheckSum進行比較得到。
3.7 Message Acknowledgment 訊息確認
FIX會話協定基於一個最佳化模型。普通的數據傳送（無單個訊息確認）被假設為通過訊息序列間隙進行錯誤識別。每個訊息由一個唯一的序列號進行標示。接收端應用程式負責監控接收訊息序列號以識別訊息間隙並產生重傳請求。
FIX協定不支持單個訊息的確認。然而，多數套用訊息需要顯示地套用層接收和拒絕。
3.8 Encryption 加密
敏感數據在公眾網路上的傳輸建議採用數據加密技術來掩飾套用訊息。
加密算法由連線雙方共同協商。
一個訊息的任何一個域可以被加密並放在SecureData域中。然而，一些顯示的標誌域必須採用明文進行傳輸。為確保完整性，明文域可以在SecureData域中重複。
當使用加密時，建議但不是必須，所有的訊息體都進行加密。如果一個訊息中的重複組數據中的部分數據要加密，這個重複組必須全部進行加密。
預先協商好的加密算法在Logon訊息中進行聲明。
4 SESSION PROTOCOL會話協定
一個FIX會話定義為一個在連線雙方間的的帶有連續序列號的有序訊息雙向傳輸流。 單個FIX會話能夠跨越多個連續（不是並行的）的物理連線。在一個維持的，單獨的FIX會話中，參與方能夠多次連線和下線。連線的參與方必須根據單個系統及時間區域需求，公共協商會話的開始和結束。無論什麼原因，重新設定接收和傳送序列號為1，意味著一個新的FIX會話的開始。
建議一個新的FIX會話在每24小時期間建立一次。可以維持24小時的連線和通過設定在Logon訊息中的ResetSeqNumFlag建立一套新的序列號。
FIX會話協定基於一個最佳化模型。普通的數據傳送（無單個訊息確認）被假設為通過訊息序列間隙進行錯誤識別。這個部分詳細介紹了FIX會話層和訊息序列間隙的實現。
以下術語將在這部分使用：
Valid FIX Message有效FIX訊息 是按照協定正確生成，包含有效訊息體長度和效驗域的訊息。
Initiator發起者 建立通信連路，通過傳送初始Logon訊息發起會話的參與方。
Acceptor接收方 FIX會話的接收方。負責執行第一層次的認證和通過傳輸 Logon訊息的確認正式聲明連線請求被接受。
FIX ConnectionFIX連線 由3部分組成：logon登錄，message exchange訊息傳輸，和logout註銷。
FIX SessionFIX 會話 由一個或多個FIX Connection FIX連線組成。意思是一個FIX會話可以有多次登錄。4.1
4.1 Logon 登錄
建立一個FIX連線，分別包含3個操作：創建通信層鏈路，接收者認證/接受發起者和訊息同步（初始化）。連線流程如下：
l會話發起者同會話接收者建立通信鏈路。
l發起者傳送一個Logon訊息。接收者檢查Logon訊息，認證發起者身份。Logon訊息包含支持之前雙方協商好的認證方法所必須的數據。如果發起者被成功認證，接收者用一個Logon訊息進行回響。如果認證失敗，會話接收者將關閉連結，之前可以選擇傳送一個Logout訊息以提示認證失敗的原因。這個Logout訊息不時必須傳送的，如果這樣做將會占用該會話的一個序列號，在某些情況下會有問題，如：在會話期進行多次Logon時。發起者可以在Logon訊息後緊接著開始傳送訊息。然而，接收者可能沒有準備好接收它們。發起者必須等待接收者傳送的Logon確認訊息才能認為完全建立回話。
在發起者認證通過之後，接收者立即回響一個Logon確認訊息。依據會話使用的加密方法，這個Logon訊息可以，也可以不報還同樣的會話密鑰。發起者方將把接收方反悔的Logon確認訊息視為一個FIX會話建立的標誌。如果會話接收方選擇乾邊會話加密密鑰，會話的發起方必須傳送一個Logon訊息到對方以確認密鑰改變請求。這樣，能讓會話接收者知道發起者何時開始使用新的會話密鑰。雙方有責任診斷和避免在此階段出現無限循環。
l認證完成之後，發起方和接收方必須在傳送任何查詢或新訊息之前通過詢問MsgSeqNum域來同步其訊息。將Logon訊息中的MsgSeqNum同內部監控的下一個希望的序列號進行比較可以指示任何的訊息間隙。此外，發起方能通過比較確認Logon訊息的MsgSeqNum及下一個期望值來偵測訊息的間隙。後面的訊息恢復部分文當將介紹如何進行訊息間隙的處理。
l推薦引擎應當在一個臨時的佇列中存儲傳送訊息系列，在訊息間隙關閉時處理它們。這樣可以阻止對n->m，n->m+1，n->m+2，…的重發請求，這些請求能導致許多PossDupFlag=’Y’的訊息。
l當使用ResetSeqNumFlag來維持24小時連線和建立一套新的序列號時，應該按照下面的方式進行處理。雙方應當協商一個復位時間以及此過程的發起方。注意，ResetSeqNum過程的發起方可以與Logon過程的發起方不是同一個。一方通過傳送一個TestRequest初始化此過程，並等待一個Heartbeat的回響以確認沒有序列號間隙。一旦收到Hearbeat，發起者應當傳送一個帶有ResetSeqNumFlag值為‘Y’和MsgSeqNum為1的Logon訊息。接收方應當傳送一個帶有ResetSeqNumFlag值為‘Y’和MsgSeqNum為1的Logon訊息作為回響。此時，任何一方傳送的新的訊息可以從MsgSeqNum編號為2開始計數。應當注意，一旦發起方傳送設定了ResetSeqNumFlag的Logon訊息，接收者必須遵守這個請求，並且作為最後一個序列號傳送的訊息的“yesterday”值不再可用。如果此過程的初始化未被正確執行，連結應當被關閉，手動關閉方式將會被介入。
4.2 Message exchange 訊息交換
初始化過程之後，正常的訊息交換將開始。所有有效的訊息格式的細節將在“Adminitrative Message ”管理訊息和“Application Messages”套用訊息部分介紹。
4.3 Logout
正常的訊息交換的終止將通過交換Logout訊息來完成。換句話說，通信的終止應被看作異常並作為一個錯誤進行處理。沒有接收到Logout訊息的會話終止應當作參與方的註銷。
推薦傳送一個TestRequest訊息強制請求從對方獲取Heartbeat。這樣可以幫助判斷沒有序列間隙。
在實際的會話關閉前，Logout的發起者應等待對方回響一個Logout確認訊息。這種方式給接收者在需要時一個執行任何間隙填充錯作的機會。一旦ResendRequest訊息被接收，接收者應發起Logout操作。會話可以終止，如果接收者在適當的時間表內沒有回響。
注意：註銷不會影響任何指令的狀態。左右活動的指令將繼續有機會在註銷後被執行。
4.4 Message Recovery 訊息恢復
在FIX會話初始化過程及會話過程中，通過跟蹤接收序列號，訊息間隙的出現將會被偵測到。以下部分介紹了如何恢復訊息。
如前所述，每個FIX參與方必須為FIX會話維護兩個序列號，一個是接收序列號，一個是傳送序列號，兩者都在建立FIX會話開始時初始化為1。每個訊息被賦予一個唯一的序列號值，並在訊息傳送後遞增。此外，每個收到的訊息都有一個唯一的序列號，接收序列號計數器在收到每個訊息後將會被遞增。
當接收序列號與所希望得到的的正確序列號不必配時，必須採取糾錯處理。注意，SeqReset-Reset訊息（對比正常德重傳請求處理，僅用於從嚴重災難中進行恢復）對於這個規則來說是個例外，它應當被處理，而不用考慮其MsgSeqNum值。 如果接收訊息的序列號小於期望接收的序列號，並且PossDupFlag值未被設定，這表示出現一個嚴重錯誤。強烈推薦終止會話，啟用手動干預。如果接收訊息的序列號大於期望值，這表明有丟失訊息，並通過Resend Request 重傳請求這些訊息的重新傳輸。
注意：後續的請求者（requester）指為請求傳送方；重傳者（resender）指請求的回響方。訊息重傳和訊息同步叫做“間隙填充”（gap filling）。
再收到重傳請求的情況下，重傳者可以用三種方式之一進行回響：
1、按照原先序列號，順序重新傳輸請求訊息，並將PossDupFlag設定成‘Y’（除管理訊息不被重傳，並需要一個SeqReset-GapFill外）。
2、發出一個SeqReset-GapFill和一個PossDupFlag值為‘Y’的訊息代替管理和套用訊息的重傳。
3、發出一個SeqReset-GapFill和一個PossDupFlag值為‘Y’的訊息強制進行序列號的同步。
通常情況下使用1，2的組合。而3則僅用於從災難中，且不能通過間隙填充模式進行數據恢復的場景。
在間隙填充過程中，一些管理訊息應不被重傳。取而代之的是一個特殊的SeqReset-GapFill訊息將被產生。不能被重傳的訊息有：Logon，Logout，ResendRequest，Heartbeat，TestRequest和SeqReset-Reset，SeqRest-GapFill。
所有的FIX協定的實現，都必須監控接收訊息以偵測管理訊息的重傳（PossDupFlag值標示沖傳）。當接收到這些訊息時，應當僅對序列號完整性進行處理，而商業/套用訊息應被跳過（如，不處理基於ResendRequest請求的重傳間隙填充）。
如果有連續的管理訊息需要重發，推薦只傳送一個SeqRest-GagFill訊息。SeqRest-GapFill訊息的序列號為下一個希望傳送的序列號。 GapFill訊息的NewSeqNo域包含了這些管理訊息中的最高序列號值加上1。如，在一個重傳錯作中，有7個順序的管理訊息等待重發。它們的序列號從9到15。替代7個間隙填充訊息，一個SeqReset-GapFill訊息將會被傳送。 此間隙填充訊息的序列號被設定為9，因為遠端把序列號9作為下一個期望接收的訊息。GapFill訊息的NewSeqNo的值為16，表示下一個傳送訊息的序列號。
序列號檢查是FIX會話管理最重要的部分。然而，一些FIX訊息的序列號處理存在一些不同，下表列出了接收序列號比期望接收序列號大時的處理方法。
注意：除了Reset訊息外的所有情況，如果接收序列號小於期望接收序列號，且PossDupFlag未被設定，FIX會話應被終止。在關閉會話前，一個Logout訊息和一些描述性文本應被傳送給對端。
| 訊息類型 | 序列號不必陪時的處理 |
| Logon | 必須是傳送的第一個訊息。認證和接受連線。如果一個訊息間隙在logon序列號中被檢測到，那么在返回一個Logon確認訊息後，傳送一個ResendRequest |
| Logout | 如果一個訊息間隙被檢測到，在確認Logout訊息傳送之後再發起一個ResendRequest以補償所有丟失訊息。不要終止會話。Logout訊息的發起方負責終止會話。這樣可以允許Logout發起者對任何ResendRequest訊息進行回響。 如果是Logout的發起方，那么這是一個Logout確認訊息，必須在收到之後立即終止會話。 唯一一個“不終止會話”的例外是無效的Logout嘗試。會話接收者有權傳送一個Logout訊息並立即終止會話。這樣可以減少未經授權的連線嘗試。 |
| ResendRequest | 首先執行重傳處理，接著按照自己的順序傳送ResendRequest訊息用以填充接收訊息間隙。 |
| SeqReset-Reset | 忽略接收序列號。SeqReset訊息的NewSeqNo將包含下一個傳送訊息的序列號。 |
| SeqReset-GapFill | 傳送一個返回ResendRequest。間隙填充訊息行為與SeqReset訊息相似。然而，確認沒有訊息被連續地跳過是非常重要的。這意味著GapFill訊息必須按順序接收。一個無序的GapFill訊息時則表明一種異常情況。 |
| 所有的其他類型訊息 | 執行間隙填充操作。 |
4.5 Logon訊息的NextExpectedMsgSeqNum處理
NextExpectedMsgSeqNum (789)域從FIX4.4開始加入到Logon訊息中，用以支持一個FIX會話的重同步。這個新方法是可選的。其適用必須得到參與方的共同同意。
NextExpectedMsgSeqNum (789)的使用如下：
在Logout的請求階段，會話發起者把期望從會話接收者的下一個MsgSeqNum（34）的值賦於NextExpectedMsgSeqNum (789)。通常，Logon請求傳送頭部MsgSeqNum（34）的值表示下一個序列號值。
會話接收者校驗Logout請求，包括NextExpectedMsgSeqNum (789)，確認沒有間隙存在。然後，構建一個Logout回響，其NextExpectedMsgSeqNum (789)值包含了期望從會話發起者接收到的MsgSeqNum（34）值。如果那是一個期望的序列號，MsgSeqNum（34）會被遞加。傳送頭部MsgSeqNum（34）按照常規進行構造。
會話發起者等待傳送套用訊息直到接收到Logon回響。當接收到Logon回響，發起者要校驗該回響和NextExpectedMsgSeqNum (789)以確認沒有訊息間隙。
會話雙方採用以下方式對收到的NextExpectedMsgSeqNum (789)進行處理：
1、如果等於下一個期望序列號值，則從該編號開始傳送新訊息。
2、如果小於下一個期望序列號值，從之前最後傳送的訊息到NextExpectedMsgSeqNum (789)按順序恢復所有丟失訊息，然後間隙填充將跨過Logon使用的序列號，使用比原Logon大1的序列號繼續傳送新的排隊訊息。
3、如果大於下一個期望序列號值，傳送Logout終止會話。
除了希望自動進行那個間隙填充外，任何一方應給予接收的Logon訊息的MsgSeqNum（34）產生一個ResendRequest。如果間隙由Logon訊息的MsgSeqNum（34）導致，接收邏輯應希望自動填充間隙以恢復間隙的任何訊息序列。
4.6 Standard Message Header標準訊息頭
任何管理和套用訊息都緊跟在一個標準頭部之後。頭部標示了訊息的類型、長度、目標、序列號，來源及創建時間。
兩個域用於協助重發訊息。PossDupFlag為‘Y’表明一個會話級事件導致的訊息重傳（如，使用同一個序列號重傳一個訊息）。PossResend為‘Y’表明使用新的序列號重新發出一個訊息（如，重新傳送一個Order指令）。接收程式應按下述方法進行處理：
PossDupFlag 如果一個訊息的序列號表明之前已經收到，忽略該訊息；如果沒有，進行正常處理。
PossResend 將訊息傳遞給應用程式以判斷是否之前已經收到（如，驗證Order的ID號和參數）。
Message Routing Details – One Firm-to-One Firm (point-to-point)
Message Routing Details – One Firm-to-One Firm（Point-to-point）訊息路由-點對點
下表展示了使用SenderCompID，TargetCompID，DeliverToCompID，和OnBehalfOfCompID在兩個企業間的一個單一的FIX會話。假設A為賣方，B為買方
| SenderCompID | OnBehalfOfCompID | TartgetCompID | DelivrToCompID | |
| A 到B | A | B | ||
| B 到 A | B | A |
Message Routing Details-Third Party Message Routing訊息路由-第三方訊息路由
FIX會話協定具備支持一個FIX會話包含多個參與這者的能力。包括1對多，對對1，或者1對1的形式。此外，一些第三方可以與其它第三方連線，在訊息發起者和最終的接收者間形成一個多跳的鏈。SenderCompID，TargetCompID，DeliverToCompID，和OnBehalfOfCompID域用於路由訊息。
當一個第三方在另一個企業中間傳送一個訊息時（使用OnBehalfOfCompID），可以選擇在NoHops重複組中加入它的細節信息。這個重複組構建了訊息在第三方重新傳送的的一個歷史列表。NoHops重複組不用於協助路由，而是為接收訊息方對參與的第三方進行審計時提供痕跡。當一個第三方轉發一個訊息給下一跳（可能是最終接收者，或另一個第三方）時，此第三方可以將其跳信息加到NoHops重複組中（如，將其SenderCompID作為HopCompID，其SendingTime作為HopSendingTime，將接收訊息的MsgSeqNum或其他引用數據作為HopRefID ）。
注意：如果OnBeHalfOfCompID或DeliverToCompID訊息源識別/路由方法在一個FIX會話中使用，那么該方法必須在通過此會話傳送的所有訊息中使用。
下表提供了在單一FIX會話中表名多個企業參與時SenderCompID，TargetCompID，DeliverToCompID和OnBehalfOfCompID的使用方法。假設A=賣方，B和C表示買方，Q=第三方。
| SenderCompID | OnBehalfOf CompID | TargetCompID | DeliverTo CompID | DeliverTo CompID | HopSendingTime | |
| 從A通過Q到B | ||||||
| 1 A到Q | A | Q | B | |||
| 2 Q到B | Q | A | B | Q | A的傳送時間 | |
| B通過Q回響A | ||||||
| 1 B到Q | B | Q | A | |||
| 2 Q到A | Q | B | A | Q | B的傳送時間 | |
| A通過Q傳送到B和C | ||||||
| 1A到Q | A | Q | B | |||
| 2Q到B | Q | A | B | Q | A的傳送時間 | |
| 3A到Q | A | Q | C | |||
| 4Q到C | Q | A | C | Q | A的傳送時間 | |
| B和C通過Q傳送到A | ||||||
| 1B到Q | B | Q | A | |||
| 2Q到A | Q | B | A | Q | B的傳送時間 | |
| 3C到Q | C | Q | A | |||
| 4Q到A | Q | C | A | Q | C的傳送時間 | |
注意，由於在一個給定的FIX會話中，一些域（如在一個新Order指令中的ClOrdID）必須是唯一的。因此，當使用OnBehalfOfCompI（或DeliverToCompID）進行定址時，推薦的做法是在OnBehalfOfCompI（或DeliverToCompID）之後加上源地址。這樣，如果A傳送訊息到Q的ClOrdID為“123”，那么Q將“A-123”作為ClOrdID的值傳送到C，以確保唯一性。
標準訊息頭部如下
Standerd Message Header
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 | |
| 8 | BeginString | Y | FIXT.1.1(不能加密，必須是訊息的第一個域) | |
| 9 | BodyLength | Y | (不能加密，必須是訊息的第二個域) | |
| 35 | MsgType | Y | (不能加密，必須是訊息的第三個域) | |
| 1128 | ApplVerID | N | 使用SP標示方法標明套用版本。ApplVerID用於一個特定訊息的場景 | |
| 1129 | CstmApplVerID | N | 用於支持客戶共同協商認可的功能 | |
| 49 | SenderCompID | Y | （不能被加密） | |
| 56 | TargetCompID | Y | （不能被加密） | |
| 115 | OnBehalfOfCompID | N | 通過第三方傳送訊息時交易參與者企業ID（可以內置於堅密數據部分） | |
| 128 | DeliverToCompID | N | 通過第三方傳送訊息時交易參與者企業ID（可以內置於堅密數據部分） | |
| 90 | SecureDataLen | N | 用於標示訊息加密部分的長度時必選（不能加密） | |
| 91 | SecureData | N | 訊息體加密時必選。總緊跟在SercureDataLen域之後 | |
| 34 | MsgSeqNum | Y | （可以內置於堅密數據部分） | |
| 50 | SenderSubID | N | （可以內置於堅密數據部分） | |
| 142 | SenderLocationID | N | 傳送者的LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分） | |
| 57 | TargetSubID | N | 為管理訊息保留，不針對一個特定用戶。（可以內置於堅密數據部分） | |
| 143 | TargetLocationID | N | 交易參與者LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分） | |
| 116 | OnBehalfOfSubID | N | 交易參與者SubID，用於通過第三方傳送訊息。（可以內置於堅密數據部分） | |
| 144 | OnBehalfOfLocation | N | 交易參與者的LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分） | |
| 129 | DeliverToSubID | N | 交易參與者SubID，用於通過第三方傳送訊息。（可以內置於堅密數據部分） | |
| 145 | DeliverToLocationID | N | 交易參與者的LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分） | |
| 43 | PossDupFlag | N | 當重傳訊息時總是必選，無論是由傳送方系統提示，還是作為重傳請求的回響結果。（可以內置於堅密數據部分） | |
| 97 | PossResend | N | 當訊息可能是另一個訊息的複製訊息且使用一個不同的序列號時必選。（可以內置於堅密數據部分） | |
| 52 | SendingTime | Y | （可以內置於堅密數據部分） | |
| 122 | OrigSendingTime | N | 當作為一個ResendRequest的返回結果重傳訊息時必選。如果數據不可用，則與SendingTime值相同（可以內置於堅密數據部分） | |
| 212 | XmlDataLen | N | 當標示XmlData訊息體長度時必選。（可以內置於堅密數據部分） | |
| 213 | XmlData | N | 包含XML格式的訊息塊（如FIXML）。總緊跟在XmlDataLen後。（可以內置於堅密數據部分） | |
| 347 | MessageEncoding | N | 在訊息的“Encode”域中使用的訊息編碼格式（非ASCII編碼）。使用編碼域時必選。 | |
| 369 | LastMsgSeqNumProcessed | N | FIX引擎到收到、下游套用（如交易系統、指令路由系統）處理過的的最後一個MsgSeqNum值。在每個訊息傳送時確定。用於參與方偵測訊息積壓（未被處理？）。 | |
| 627 | NoHops | N | ||
| -〉 | 628 | HopCompID | N | |
| 629 | HopSendingTime | N | ||
| -〉 | 630 | HopRefID | N | |
4.7 Standard Message trailer標準訊息尾部
每個訊息，管理或套用訊息，以一個標準尾部結束。該尾部用於分割訊息並包含描述Checksum值的3個數字字元。
Standard Message Trailer
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| 93 | SignatureLength | N | 如果尾部包含簽名則必選。注意，不能包含在SecureData域中。 |
| 89 | Signature | N | 注意，不能包含在SecureData域中。 |
| 10 | CheckSum | Y | （不能加密，總是訊息的最後一個域） |
5 ADMINISTRATIVE MESSAGES管理訊息
管理訊息強調協定的套用需求。以下部分內容描述了每個管理訊息，提供訊息的圖表。
管理訊息由連線各方產生。
5.1 Heartbeat 心跳訊息
心跳訊息監控通信鏈路的狀態，用於識別一連串訊息中最後沒有收到的訊息。
當如果一個FIX連線的任何一方在超過HeartBtInt規定的時間間隔後沒有收到任何數據，將傳送一個Hearbeat訊息。當如果一個FIX連線的任何一方在超過HeartBtInt規定的時間間隔加上一些傳輸時間後沒有收到任何數據，將傳送一個Test Request測試請求訊息。如果在超過HeartBtInt規定的時間間隔加上一些傳輸時間後仍然沒有收到Heartbeat訊息，那么應視為連線斷開並應採取糾錯處理。如果HearBtInt設定為0，則不會產生常規的Heartbeat訊息。注意，一個測試請求訊息能夠不間隔HeartBtInt的值被傳送，用於強制請求一個Heartbeat訊息。
Heartbeat訊息作為測試請求訊息的回響，必須包含在請求測試訊息中的TestReqID值，用於驗證Heartbeat訊息是測試請求訊息的回響而不是常規逾時的回響。
Heatbeat訊息格式如下：
Heartbeat
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| StandardHeader標準頭部 | Y | MsgType=0 | |
| 112 | TestReqID | N | 當Heartbeat訊息是Test Request訊息的回響時必選 |
| StandartTrailer | Y |
5.2 Logon登入訊息
Logon訊息認證一個連線到一個遠程系統的用戶。Logon訊息必須是應用程式用於請求初始化一個FIX會話的第一個訊息。
HeartBtInt（108）域用於申明產生心跳訊息的時間間隔，連線雙方使用形同的HeartBtInt值。其值應被雙方企業一致同意，由Logon訊息發起者初始化，並被Logon接收者回應。
當接收到Logon訊息，會話接收者將認證參與者的連線請求，並發出一個Logon訊息確認連線請求被接受。這個確認Logon訊息也能用於發起者驗證連線已經與對端正確建立。
在接收到Logon訊息後會話接收者必須立即準備好開始處理訊息。會話發起者可以選擇在收到Logon確認訊息前傳輸FIX訊息，但推薦在收到返回的Logon訊息後，完成加密秘要協商後進行正常的訊息傳輸。
確認Logon訊息可以用於加密秘要協商。如果一個會話密鑰被認為是弱秘要，一個推薦的新的更加強狀的會話秘要將在Logon訊息中返回。這僅在加密協定允許秘要協商時有效。
Logon訊息能用於確定支持的訊息最大長度MaxMessageSize（能用於控制將大訊息進行分節的規則）。也能用於確定雙方接收和傳送所支持的訊息的類型MsgType。
下表是Logon訊息的格式：
Logon
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| StandardHeader標準頭部 | Y | MsgType=A | |
| 98 | EncryptMethod | Y | 不能加密 |
| 108 | HearBtInt | Y | 雙方使用同一個值 |
| 95 | RawDataLength | N | 由一些認證方法使用 |
| 96 | RawData | N | 由一些認證方法使用 |
| 141 | ResetSeqNumFlag | N | 表示FIX會話雙方應復位序列號 |
| 789 | NextExpectedMsgSeqNum | N | 可選，雙方檢測和恢復訊息間隙的候選協商方法參照“Logon訊息NextExpectedMsgSeqNum ” |
| 383 | MaxMessageSize | N | 能用於指定所支持接收訊息的最大位元組數 |
| 384 | NoMsgTypes | N | 指定RefMsgTypes的重複次數 |
| -〉 | 372 RefMsgType | N | 制定一個特定的、被支持的MsgType。如果NoMsgTypes大於0時必選。從Logon訊息的傳送者角度應當被指定。 |
| -〉 | 385 MsgDirection | N | 表明所支持MsgType的接收或傳送方向。當NoMsgTypes大於0時必選。從Logon訊息的傳送者角度應當被指定。 |
| -〉 | 1130 RefApplVerID | N | 在會話層指定一個訊息的套用SP發行版本。SP發行時付值的枚舉域。 |
| -〉 | 1131 RefCstmApplVerID | N | 再會話層指定一個用戶擴展訊息的套用。 |
| 464 | TestMessageIndicator | N | 用於指定此FIX會話將傳送、接收 “Test” “production”訊息。？ |
| 553 | Username | N | |
| 554 | Password | N | 注意，沒有傳輸層加密時存在最小安全性。 |
| 1137 | DefaultApplVerID | Y | 由FIXT承載的FIX的默認版本。 |
| StandartTrailer | Y |
5.3 Test Request 測試請求訊息
測試請求訊息強制對方傳送一個Heartbeat訊息。測試請求訊息檢查序列號或驗證通信線路狀態。對端應用程式回響一個包含TestReqID的Heartbeat訊息。
TestReqID用於檢查對端套用是依據測試請求訊息產生的Heartbeat訊息，而不是通常的逾時。對端應用程式將TestReqID包含在回響Heartbeat訊息中。任何字元串可以被用於TestReqID（一個建議是使用時間戳字元串）。
測試請求訊息格式如下：
Test Request
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| StandardHeader標準頭部 | Y | MsgType=A | |
| 112 | TestReqID | Y | 不能加密 |
| StandartTrailer | Y |
5.4 Resend Request 重傳請求訊息
重傳請求訊息由接收用用程式傳送用於開始訊息的重傳。這個功能在序列號間隙被偵測到時，在接受應用程式丟失訊息時，或者作為一個初始化處理功能時非常實用。
重傳請求訊息能用於請求一個單一訊息，一定範圍內的訊息，或者一個特定訊息的所有後續訊息。
注意：傳送應用程式可能希望考慮重傳訊息的訊息類型。如：如果在重傳序列中的一個新指令訊息在其最初傳送後經過一段相當長的時間，那么傳送方可能不希望重傳該訊息以提供改變市場條件的潛在可能性。（Seqence Reset-GapFill訊息用於傳送方不希望傳送二跳過這類訊息。）
注意：接收程式必須按照順序處理訊息。如：如果收到訊息8和9，訊息7丟失，程式應忽略訊息8和9，並要求重傳訊息7到9，或者最好重傳訊息7到0（0表示序列號無窮大）。後者，作為當序列號出現混亂，雙方同時嘗試恢復一個間隙時，從當前的某些競爭條件下快速恢復的推薦方法。
1.為請求一個單一訊息， BeginSeqNo=EndSeqNo
2.為請求一定範圍內的訊息，BeginSeqNo=請求範圍內第一個訊息，EndSeqNo=請求範圍內最後一個訊息。
3.請求特定訊息的所有後續訊息：BeginSeqNo=請求範圍內第一個訊息，EndSeqNo=0。
重傳請求訊息格式如下：
Resend Request
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| StandardHeader標準頭部 | Y | MsgType=2 | |
| 7 | BeginSeqNo | Y | 不能加密 |
| 16 | EndSeqNo | Y | |
| StandartTrailer | Y |
5.5 Reject（session-level）駁回訊息
當一個接收訊息由於違背會話層規則，不能被正確的處理，應傳送駁回訊息。一個例子是：當一個接收訊息通過解密，效驗和檢查，及數據體長度檢查後沒有有效的基礎數據（如，MsgType=&），將產生一個駁回訊息。結果是，這些訊息將傳遞給交易應用程式，如果需要，將產生商業邏輯級的駁回。
駁回訊息應記錄到日誌中，且接收序列號應增加。
注意：接收應用程式應忽略任何干擾訊息，不能被解析的及未通過數據完整性檢查的訊息。處理下一個FIX訊息將導致檢測到一個序列號間隙並產生一個Resend Request訊息。FIX引擎應包含處理在此情況下的無限重傳循環。
生成和接收到一個駁回訊息表明一個接收或傳送程式的邏輯錯誤導致的嚴重的錯誤。
如果傳送程式選擇重傳駁回訊息，該訊息應賦予一個新的序列號值，且PossResend設定為‘Y’。
無論何時，強烈推薦將描述失敗原因在Text 域中描述（如，INVALID DATA（35））。
如果接收到的一個套用級訊息滿足所有會話級規則，該訊息應在商業訊息級被處理。如果在處理過程中檢測到規則衝突，將產生髮送一個商業績駁回。許多商業級訊息都有自己特定的駁回訊息。如果沒有，則產生髮送一個Business Message Reject訊息。
注意，在收到一個商業訊息，滿足會話級規則，但不能被傳送給商業級處理系統時，一個帶有BusinessRjectReason=“Application not available at this time”的Business Message Reject訊息將被發出。
會話級駁回訊息場景：
| SessionRejectReason |
| 0=Invalid tag number 無效的tag編號 |
| 1=Required tag missing tag丟失 |
| 2=Tag not defined for this message type 這類訊息的Tag沒有被定義 |
| 3=Undefined Tag未知Tag |
| 4=Tag specified without a value缺少Tag值 |
| 5=Value is incorrect (out of range) for this tagtag值錯誤（超界） |
| 6=Incorrect data format for value錯誤值數據 |
| 7=Decryption problem解密錯誤 |
| 8=Signature problem簽名錯誤 |
| 9=CompID problem企業ID錯 |
| 10=SendingTime accuracy problem傳送時間不正確 |
| 11=Invalid MsgType無效的MsgType |
| 12=XML Validation error XML語法驗證錯誤 |
| 13=Tag appears more than once Tag重複出現 |
| 14=Tag specificed out of required order 指定的Tag順序錯誤 |
| 15=Repeating group fields out of order重複組域順序錯誤 |
| 16=Incorrect NumInGroup count for repeating group 重複組NumInGroup錯誤 |
| 17=Non “data” value includes field delimiter(SOH character) 包含了SOH分界符的錯誤數據 |
| 99=Other其它錯誤 |
| 注意：其他的會話級規則衝突可能存在，SessionRejectReason值為99（Other），並在Text域中進行詳細描述。 |
駁回訊息格式：
Reject
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| StandardHeader標準頭部 | Y | MsgType=3 | |
| 45 | RefSeqNum | Y | 被駁回訊息的MsgSeqNum |
| 371 | RefTagID | N | 被參照的FIX域tag值 |
| 372 | RefMsgType | N | 被參照的FIX訊息MsgType值 |
| 373 | SessionRejectReason | N | 會話級駁回訊息錯誤代碼 |
| 58 | Text | N | 解釋駁回原因的文本信息 |
| 354 | EncodedTextLen | N | 如果使用EncodeText域，必選，且EncodeText必須緊跟在該域之後 |
| 355 | EncodedText | N | 使用MessageEncoding 域制定的編碼規則對Text域內容的編碼數據（非ASCII碼） |
| StandartTrailer | Y |
5.6 Sequence Reset（Gap Fill）序列號復位（間隙填充）訊息
序列號復位訊息有兩種模式：Gap Fill模式和Reset模式。
5.6.1Gap Fill 模式
在下列情況下，Gap Fill模式用於回響當出現一個或多個訊息必須被跳過時的Resend Request訊息
1.在常規的重傳處理過程中，傳送應用程式可以選擇不傳送訊息（如，一個過期的指令）。
2.在常規的重傳處理過程中，大量的管理訊息將跳過而不重傳（如：Heartbeat， TestRequest 訊息）。
GapFillFlag（123）域為‘Y’時，為Gap Fill模式。
如果GapFillFlag（123）域設定為‘Y’，MsgSeqNum應同標準訊息序列號規則保持一致（如，序列號Reset GapFill模式訊息的MsgSeqNum應為GapFIll訊息的最開始的MsgSeqNum,因為其值為遠端程式希望接收的訊息序列號）。
5.6.2Reset Mode 復位模式
復位模式包括了指定一個任意的、數值更大的、接收者期望的Reset-Reset訊息序列號，並用於在出現不可恢復的應用程式錯誤時重新建立一個FIX會話。
復位模式由GapFillFlag為‘N’時，或被忽略時被指定。
如果GapFillFlag沒有出現，或其值為‘N’，可以認為Sequence Reset訊息的目標是從序列號混亂時的恢復。在序列號的Reset-Reset模式中，在訊息頭中的MsgSeqNum將被忽略（如，當接受到帶有錯誤的MsgSeqNum序列號的Sequence Reset-Reset模式訊息時，不產生重傳請求）。序列號復位的Reset訊息不應被當作揖個重傳請求的常規回響（使用序列號復位的Gap Fill模式）。序列號復位的Reset模式僅在當使用序列號復位的Gap Fill模式無法恢復時進行災難恢復。注意，使用序列號復位模式時有可能造成訊息丟失。
5.6.3Rules for processing all Sequence Reset messages處理所有序列號復位訊息的規則
傳送程式將啟動序列號復位。所有情況下，這個訊息指定NewSeqNo以作為訊息接收方期望接收的下一個訊息的序列號的復位，緊接在訊息和/或被挑過的序列號？
序列號復位，近能增加序列號。如果一個序列號復位訊息嘗試減小期望接收訊息的序列號時，應被當作揖個嚴重錯誤而被拒絕。多個Resend Request重傳請求可能在接連著被發起（如，5道10，接著5到11）。如果序列號8，10，11是套用訊息而5到7和9是管理訊息，那么重傳請求的結果為：序列號復位GapFill模式下的NewSeqNo為8，訊息8；序列號復位GapFill模式下的NewSeqNo為10，訊息10。也可以是序列號復位GapFill模式下的NewSeqNo為8，訊息8；序列號復位GapFill模式下的NewSeqNo為10，訊息10，和訊息11。必須小心地忽略嘗試減少期望序列號值的複製的序列號復位GapFill模式訊息。可以通過檢查MsgSeqNum是否小於期望值來檢查。如果是，那么該序列號復位GapFill模式訊息為複製訊息，應被忽略。
序列號復位訊息格式：
Sequence Reset
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| StandardHeader標準頭部 | Y | MsgType=4 | |
| 123 | GapFillFlag | N | |
| 36 | NewSeqNo | Y | |
| StandartTrailer | Y |
5.7 Logout註銷訊息
Logout訊息發起或確認一個FIX會話的終止。沒有Logout訊息交換的連線斷開應被視為一個異常情況。
在實際的關閉會話前，Logout發起者應等待對端的Logout確認訊息的回響。這樣可以給遠端在必要時執行一些Gap Fill操作的機會。如果遠端在規定的時間間隔後沒有回響，會話可以終止。
在傳送Logout訊息後，註銷發起者不應傳送任何訊息，除非註銷的接收者通過ResendRequest訊息請求傳送訊息。
註銷訊息格式如下：
Logout
| Tag （標記） | FieldName （域名） | Req’d （必選） | 備註 |
| StandardHeader標準頭部 | Y | MsgType=5 | |
| 58 | Text | N | |
| 354 | EncodedTextLen | N | 如果使用EncodeText域，必選，且EncodeText必須緊跟在該域之後 |
| 355 | EncodedText | N | 使用MessageEncoding 域制定的編碼規則對Text域內容的編碼數據（非ASCII碼） |
| StandartTrailer | Y |
5.8 CheckSum Calculation 校驗和計算
一個FIX訊息校驗和通過計算到ChechSum域（但不包括）的訊息的每個位元組和得到。然後，校驗和被轉換為模256的數字用於傳送和比較。校驗和在所有加密操作之後被計算。
為了便於傳輸，校驗和必須以可列印字元形式進行傳輸，因此，校驗和被轉換位3個ASCII數字。
比如：如果訊息的校驗和為274，則模256後為18（256+18 = 274）。這個值將採用|10=018|進行傳輸，其中“10=”是校驗和域的標籤。
產生校驗和的代碼示列如下：
char *GenerateCheckSum( char *buf, long bufLen )
{
static char tmpBuf[ 4 ];
long idx;
unsigned int cks;
for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );
sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) );
return( tmpBuf );
}
6 FIX 會話層測試用例和期望行為
6.1 Applicability 適用性
本文檔在2002年9月20日最後被修訂，當時的FIX協定的最新版本為帶有20020930的擴展的FIX 4.3 。此文當適用於FIX4.X，除非特別說明。
6.2When to send a Logout vs. when to just disconnect何時傳送Logout與僅下線
一般情況下，一個Logout訊息應在關閉一個連線前傳送。如果這個Logout訊息是源於一個錯誤條件，Logout的Text域應提供錯誤原因的描述，為遠端FIX系統提供問題診斷的操作支持。這裡有2個例外，推薦不傳送Logout訊息：
1、在登入階段，如果會話發起者的SenderCompID，TargetCompID或IP其中一個無效時，推薦立即終止會話，不傳送Logout訊息。這個登入嘗試有可能使一個未經授權的破壞系統的未認證嘗試，因此，企業不希望泄露其FIX系統的任何信息，如，哪個SenderCompID，TargetCompID是有效的，或所支持的FIX版本。
2、在登入階段，當一個有效的FIX會話已經被一個企業使用時，該企業的第2次連線嘗試的Logon訊息被接受時，推薦會話接收者立即中斷該第2次連線嘗試，不傳送Logout訊息。傳送一個Logout訊息將冒著妨礙和影響當前FIX連線的風險。例如：在一些FIX實現系統中，傳送一個Logout訊息可能會消耗一個序列號，這樣將會導致在一個已經建立的FIX會話中的序列號混亂。
在其他情況下，如果傳送一個Logout訊息不產生風險和安全衝突，Logout訊息應隨同描述信息一起傳送。
6.3 When to send a Session Reject vs. when to ignore the message 何時傳送會話駁回與何時忽略訊息
以下內容從FIX協定規範中的Reject訊息定義中摘抄：
注意：接收程式應忽略任何文本混亂，不能被解析以及數據完整性檢查失敗的訊息。處理下一個右下的FIX訊息將導致檢測到一個序列號間隙並產生一個重傳請求訊息Resend Request。這種情況下，FIX引擎應包含識別重傳無限循環的邏輯。
FIX協定採取樂觀的觀點。它假設一個混亂的訊息是由於傳輸中出現的錯誤，而不是FIX系統的問題。因此，如果傳送一個重傳請求訊息（Resend Request），該混亂訊息將被正確得重傳。如果一個訊息沒被認為是混亂的，那么，推薦傳送一個會話級駁回訊息。
6.4 What constitutes a garbled message 什麼樣的情況認為是一個混亂訊息
1.BeginString（tag#8）不是一個訊息中的第一個tag或不是8=FIXT.n.m.的格式。
2.BogyLength（tag#9）不是一個訊息中的第二個tag或沒有包含正確的位元組數。
3.MsgType（tag#35）不是一個訊息中的第三個tag。
4.Checksum（tag#10）不適最後一個tag或沒有包含正確的值。
如果丟失MsgSeqNum（tag#34），一個Logout訊息將被傳送以終止FIX連線。因為這種情況意味著一個嚴重的應用程式錯誤。
6.5 FIX Session-level State Matrix FIX會話層狀態舉證
| Precedence 次序 | State 狀體 | Initiator 發起者 | Acceptor 接收者 | Descriptioin 描述 |
| 1 | 斷開 當天未連線 | Y | Y | 當前處於斷開狀態，當日未進行連線嘗試。沒有MsgSeqNum被使用（下一個當日的連線的MsgSeqNum值為1）。 |
| 2 | 斷開 當日開始連線 | Y | Y | 當前處於斷開狀態，嘗試建立當日連線，這樣，MsgSeqNum開始被消耗（下一個當日連線時，MsgSeqNum將從其（last+1）開始） |
| 3 | 檢測到網路連線的中斷 | Y | Y | 處於連線狀態時，檢測到一個網路連線中斷（如TCP socket關閉）。斷開網路連線並關閉該會話的配置。 |
| 4 | 等待連線 | N | Y | 會話登入訊息接收者等待對端的連線。 |
| 5 | 初始話（發起）連線 | Y | N | 會話登入訊息發起者同對端建立連線。 |
| 6 | 網路連線建立 | Y | Y | 雙方建立網路連線。 |
| 7 | 傳送Logon發起訊息 | Y | N | 會話登入發起者傳送Logon 訊息。 ***異常：24小時會話 |
| 8 | 收到Logon發起訊息 | N | Y | 會話登入接收者收到對端的Logon訊息 ***異常：24小時會話 |
| 9 | Logon發起訊息回響 | N | Y | 會話登入接收者使用Logon訊息與對端握手，回響對端Logon訊息。 |
| 10 | 處理ResendRequest | Y | Y | 接收和回響對端傳送的對訊息的ResendRequeset訊息，和（或）對MsgSeqNum所請求範圍的SequenceReset-Gap Fill訊息。修改以駁回接收到的MsgSeqNum小於LastSeqNum的Resend Request訊息。 |
| 11 | 收到MsgSeqNum過大 | Y | Y | 從對端接收到過大的MsgSeqNum，將訊息排隊暫存，傳送ResendRequest訊息 |
| 12 | 等待/處理ResendRequest回響 | Y | Y | 處理請求的MsgSeqNum請求的、PossDupFlag=’Y’的訊息，和/或從對端進行的SequenceRset-Gap Fill訊息。將MsgSeqNu過高的接收訊息排隊暫存。 |
| 13 | 在實踐間隔後未收到訊息 | Y | Y | 沒有非混亂訊息在HeartBeatInt+回響時間內被接收，傳送TestRequest訊息。 |
| 14 | 等待/處理TestRequest訊息回響 | Y | Y | 處理接收訊息。當接收到非混亂訊息後，復位心跳間隔時間。 |
| 15 | 接收Logout訊息 | Y | Y | 從對端接收到發起註銷/連線斷開的Logout訊息。如果MsgSeqNum過高，傳送RsendRequest。如果傳送，等待一定周期，以完成ResendRequest的回響處理。注意，依據Logout的原因，對端可能不能執行該請求。 傳送Logout訊息作為回響並等待一定時間讓對端斷開網路連線。注意，對端可能傳送ResendRequest訊息，如果Logout回響訊息的MsgSeqNum過高並重新發起Logout操作。 |
| 16 | 發起Logout處理 | Y | Y | 識別優雅下線的條件和原因（如：日終，多個未回響的TestRequest訊息傳送後，MsgSeqNum過高等）。傳送Logout效益給對端。等待一個時間周期以接收Logout回響。在這期間，如有可能，處理新接收的訊息和/或ResendRequest。注意，一些註銷/終止條件（如資料庫/訊息存儲失敗），可能要求緊接在初始滬Logout訊息傳送後立即止網路連線。斷開該會話的網路連線並關閉該會配置。 |
| 17 | 活動/正常會話 | Y | Y | 網路連線建立後，Logon訊息成果交換完成，接收和傳送的MsgSeqNum都是所期望的順序，並且Heartbeat 或其他訊息在（HeartBeatInt +回響周期）內被接收。 |
| 18 | 等待Logon確認 | Y | N | 會話發起者等待會話接收者傳送Logon確認訊息。 |
6.6 FIX LogonProcess State Transition Diagram FIX登入訊息處理狀態轉換圖
| Session Initiator（e.g. buyside）Action 會話發起者（如，買方）行為 | Session Acceptor（e.g. sellside）Action會話接收者（如，賣方）行為 | Session Initiator（e.g.buyside）State會話發起者（如，買方）狀態 | Session Acceptor（e.g. sellside）State會話接收者（如，賣方）狀態 |
| 開始 | 未連線-當日未連線 未連線-當日連線 | 等待連線 | |
| 連線 | 發起連線 （可能）檢測到網路連線中斷 | 等待連線 | |
| 接受連線 | 建立網路連線 | 建立網路連線 | |
| 發起登入 | 傳送發起登入訊息Logout | 建立網路連線 | |
| 收到發起登入訊息Logout | 傳送發起登入訊息Logout | 收到發起登入訊息Logout | |
| 傳送發起登入訊息回響 | 傳送發起登入訊息Logout | 發起Logon的回響 （可能）發起 Logout處理 （可能）接收到的MsgSeqNum過高 | |
| （可能）傳送ResendRequest | 發起Logon回響 （可能）接收到的MsgSeqNum過高 | ||
| 接收發起登入訊息的回響 | （可能）活動/正常的會話 （可能）發起 Logout處理（如，MsgSeqNum過高） | 發起Logon的回響 | |
| （可能）傳送RsendRequest | （可能）活動/正常的會話 （可能）接收的MsgSeqNum過高 | （可能）活動/正常的會話 （可能）處理ResendRequest | |
| 活動/正常的會話 | 活動/正常的會話 |
6.7 FIX Logout Process State Transition Diagram FIX Logout處理狀態轉換圖
| Logout Initiator: Action Logout發起者行為ie | Logout Acceptor Action Logout接收者行為 | Logout Initiator State Logout發起者狀態 | Logout Acceptor State Logout接收者狀態 |
| 開始 | 1.活動/正常的會話 2.沒有在時間間隔內收到訊息 3.等待/處理回響TestRequest | ||
