FIX協定的工作原理 2022年03月07日 星期一 – Posted in: 套利软件

介紹

 自成立以來，股票市場的交易歷史發生了巨大的變化。 第一個證券交易所出現在大約400年前。 當時，交易是口頭達成的，交易規則也才剛剛開始。 但世界並沒有停滯不前，為了跟上時代的步伐，證券交易所採用了當時所有可能的科技工具。

囙此，在19世紀中期，在與交易相距一定距離的地方的交易申請通過電報線路來連接。 然後電話代替了它。 最終，交易員的第一個交易請求通過互聯網通信傳輸。

公平地說，在現代，通過電話進行交易有時仍會發生在一些經紀人身上。 其中的一部分是交易的唯一保證管道。 此外，從最初的交易所開始到21世紀初，直接在交易所領土上進行的交易都是口頭進行的。 這樣的交易場所被稱為股票交易場，代表著我們在好萊塢電影中熟悉的一種奇觀。

FIX協定歷史記錄

 最古老的數位交易協定之一是FIX協定。它 代表“金融資訊協定”或“金融交換協定”，這兩個定義都可以找到。 FIX協定規範創建於1992年，旨在提供富達投資與所羅門兄弟之間的股票交易資訊。 經紀人和投資基金希望加快交易所的交易過程。 其結果是形成了一個以電子管道傳輸資訊的開放標準，沒有任何主要組織可以控制。 如今，FIX已經成為不同國家的金融市場參與者用來連接其產品的行業標準。

最初，該通信協議僅在上述兩家交易所之間使用，稱為SBX（所羅門兄弟交易所），僅用於股票交易。 然後，正如故事所說，這些公司的領導人意識到他們發明的重要性，提出加入高盛和普特曼的發展。 此後，該協定被命名為當前名稱。

最初，該協定只支持17種消息類型和103個標籤。 這個想法非常成功，到1995年，超過70%的美國券商使用了該協定。 這是由於成本節約、成本降低和交易錯誤减少。 畢竟，在通過電話進行交易時，人為因素有很大的影響。 隨著時間的推移，該協定已經顯著擴展。 新增了對衍生品、債券和貨幣交易的支持。 當前的FIX規範描述了168條消息、7868個標籤，並涵蓋了所有類別的證券。 1998年，FIX協定及其規範的開發以及相關科技的開發被移交給了FIX協定有限公司財團。 該財團後來更名為FIX Trading Community。 該組織目前有270多家主要金融機構的成員。

FIX協定的工作原理

 FIX協定通過TCP運行。 現時，FIX協定模型定義在兩個級別——會話或控制級別（會話創建、數據交付工作）和應用程式級別（數據內容描述）。 控制層負責修復會話的基本參數：打開和關閉連接，恢復遺失的消息。 應用層控制數據的發送和接收：請求、執行、拒絕、市場數據和狀態資訊請求。 協定本身是文字，也就是說，它使用ASCII錶中的字元。 它分為兩種表示形式——傳統的，形式為Tag=Value（Tag=Value或Key=Value），以及XML（FIXML）表示形式。 最新版本現時是5.0，但最常見的是4.2和4.4版。 不同的經紀人和交易所可以使用不同版本的協定，有時會同時使用多個版本。

Syntax  Tag=Value

該消息類似於以下內容：

8=FIX.4.2 | 9=178 | 35=D | 34=1234567 | 49=TESTER | 56=PHLX | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 54=1 | 167=FUT | 55=MSFT | 38=15 | 40=2 | 44=15 | 59=0 | 10=128 |

這是一個文字字串，由垂直條分隔的部分組成。 這些部分稱為欄位。 反過來，每個部分由一個由等號分隔的鍵值對組成。 符號右邊是鍵，左邊是值。 在FIX規範中，鍵被稱為標籤。 標籤始終是正整數，本質上是指向欄位名的指針。 特定交換的檔案中描述了所有欄位名及其可能的值。 其中大多數欄位都是標準欄位，可以在任何交換的BOM錶中找到。 還有一些自定義欄位，它們僅在特定的交換中定義並具有意義。如果可以在通用FIX協定規範中找到標準欄位的描述，則必須在交換FIX協定規範中描述自定義欄位。 還有必填欄位、可選欄位和條件必填欄位（必填欄位取決於消息中是否存在其他欄位）。SoH（標題開頭）符號用作欄位之間的分隔符號。 它實際上是不可見的，囙此在本例中，它被替換為豎條。 在UNICODE編碼中，此字元的程式碼為“\u0001”。

反過來，當消息被劃分為多個欄位時，它們又定義了另外三個組件：

• 標題（消息標題）
• 正文（消息正文）
• 消息訓練器（校驗和）

在FIX1.1/FIX5.0中， 標頭包含5個必填欄位和一個可選欄位： 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (DestComppID), 和 1128 (ApplVerID – 如果存在，則必須位於第6處). 主要有兩組消息——管理消息和應用消息。 管理消息處理FIX會話的基本資訊。 它們允許您啟動和結束會話，以及恢復遺失的消息。 申請資訊與交易相關資訊的發送和接收有關，例如認股權證請求或關於認股權證當前狀態和後續執行的消息。

我們將分析這條消息：

• 8=FIX.4.2 – BeginString。使用協定版本。 告訴交易員程式要應用哪些規則來解析此消息的欄位。
• 9=178 – BodyLength。消息正文長度為178位元組，包括消息頭。 計算為從標籤35（含）到標籤10（不含）的字元數。 還考慮了SoH分離器。
• 35=D – MsgType。消息類型。 在這種情況下，D表示提出交易請求。 例如，35=V的欄位表示獲得了有關該儀器的市場數據。
• 34=1234567 – MsgSeqNum。消息號碼。 如果MsgSeqNum消息在發送的序列中沒有1個不同，服務器將返回一個錯誤，並且不處理該消息。
• 49=TESTER – SenderCompID。由交易所發佈的發件人ID。 這可以是用戶名，如果消息是由代理發送的，則可以是代理的名稱。
• 56=PHLX – TargetCompID。 要發送到的收件人ID。 也由交易所發行。
• 52=20071123-05:30:00.000 – SendingTime。發送郵件的日期和時間。
• 11=ATOMNOCCC9990900 – ClOrdID。經紀人交易系統中的應用程式編號。
• 54=1 – Side。資產購買行為
• 167=FUT – SecurityType。資產是一種未來
• 55=MSFT – Symbol。 微軟的推廣活動。 不同交易所的報價可能有所不同。
• 38=15 – OrderQty。 交易量為15個批次或契约。
• 40=2 – OrdType。限價購買，限價訂購。
• 44=15 – Price。購買價格-15
• 59=0 – TimeInForce。 申請截止日期為工作日結束。
• 10=128 – CheckSum。消息校驗和。 始終是消息中的最後一個欄位。 使用特殊公式計算，並在協定規範中進行了描述。 它是通過將消息中除校驗和欄位字元外的所有字元的ASCII值相加來設定的。 將該值除以256，然後取隔間的剩餘部分。 校驗和必須始終為三個字符長。 所以，如果模數是22，那麼在數位之前加上0——“022”。

如果您概括地描述這條消息，這是一個以15個合約的最高價格購買微軟股票期貨的行為，到期日為一天結束。

為了在修復中提供更大的靈活性，該協定包含所謂的用戶定義欄位，即用戶定義欄位。 它們用於合作金融組織之間的資料傳輸。 從5000到9999的標籤號是為自定義欄位保留的，可以在標準的官方網站上保留。 隨後使用了這些數位，囙此分配了一個從20000到39999的新的間隔。

FIXML語法

語法方面的工作始於1998年，第一個版本於1999年發佈。 它在語義上等同於使用標記編碼的消息，但使用XML解析科技。 FIXML格式的新操作應用程式如下：

<FIXML>

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>

<Instrmt Sym=”IBM” ID=”459200101″ IDSrc=”1″/>

<OrdQty Qty Qty=”1000″/>

</Order>

</FIXML>

在XML格式中，一個特定的程式碼塊在一個所謂的標籤（另一個標籤，而不是協定本身使用的標籤）中形成框架。 例如，有一個<FIXML>頂級順序標籤。 任何標籤都會打斷特定的程式碼或消息，並使用相同的標籤將其關閉，但在左邊緣內，有一個斜杠字元。 囙此，上述標籤將按如下管道關閉該塊： </FIXML>.

接下來，在這個標籤中，我們看到以下標籤：

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>.

在這裡，我們可以看到標籤名-順序，在括弧內，還有其他資訊(相同的欄位，key=value配對為語法Tag=Value).

在這種情況下：

ClOrdID=”123456″ -經紀人交易系統中的訂單id

Side=”2″ -銷售訂單

TransactTm=”2001-09-11T09:30:47-05:00″ 交易日期和時間

OrdTyp=”2″ – 索賠類型-限額訂單

Px=”93.25″ – 購買或出售資產的價格

Acct=”26522154″ – 用戶帳號

與前一個XML標籤一樣，XML標籤以斜杠結束 – </Order>

開始和結束XML標籤之間的內容稱為標籤體。 囙此，Order標籤是FIXML標籤的主體。 在作為主體的訂單標籤中，還有兩個標籤： Instrmt和OrdQty。

下一個標籤:

<Instrmt Sym=”IBM” ID=”459200101″ IDSrc=”1″/>

在這裡，我們可以看到它同時閉合，在它的末端有一條斜線。 如果標記中沒有任何正文，則情况就是這樣，並且沒有必要製作單獨的框架標籤。 該標籤包含工具的程式碼、id等資訊。

在<OrdQty Qty=“1000”/>標籤中，我們可以看到有關交易量的資訊，它也是沒有正文的結束標籤。

FIXML通常用於後臺和清算應用程式，而不是用於交易。

FIX會話層

前面的示例描述了應用程式層。 該規範定義了負責用戶端和交換之間會話級別的特殊欄位類型：

• 35=A – 登入。 用於在連接時向交換系統驗證用戶身份。 首先發送此消息，並向數據會話的開始發送交換訊號。 成功提交後會收到回復消息。 如果連接失敗，將返回一個錯誤。
• 35=5 – 註銷。 此消息用於與服務器解除授權，並關閉與交易所的交易會話。
• 35=0 – 心跳。 心率或脈搏。 此消息從連接的雙方互相發送，表示雙方都已準備好接收和發送消息。 心跳頻率在第一條登入消息中設定。
• 35=1 – 測試請求。 此消息是一條測試消息，當交易對手在設定的時間段內未發送心跳消息時發送。 如果此消息仍未應答，會話將關閉。
• 35=2 – 重新發送請求。 此消息是在遺失任何資訊時重新發送消息的請求。
• 35=3 – 拒絕。 如果上一條資訊格式錯誤或無法執行，則由交易對手發送。
• 35=4 – 序列重置，或重置消息發送序列。 它可以有兩種形式。

– 123=”Y” – 有一個具有指定值的GapFillFlag標記。 訓示在再次發送管理消息時忽略這些消息的請求。

– 用於將MsgSeqNum計數器歸零

實現FAST作為修復API的增强功能

大量FIX數據在處理過程中會出現重大延遲，這使得交易員不太可能製定有效的交易策略。 在意識到這一問題後不久，就採取了糾正這種情況的第一步。 FAST協定的目標是允許傳輸大量數據，避免獲取資訊的延遲。 FAST（FIX Adapted for STreaming，翻譯為適用於流媒體的FIX）是由FIX Protocol Ltd.開發的科技標準，專門用於優化網絡呈現。 它本質上是FIX協定的二進位格式，允許以緊湊的形式傳輸有關交易和市場環境的大量資訊。 這使得它可以在需要低傳輸延遲的高速交易系統中使用。 Fast由位於帕薩迪納的加利福尼亞理工學院開發。 現時是FAST 1.2的最新版本。 最常見的應用程序是直接連接到交易所，繞過經紀人的交易系統。 FAST協定是標準化的市場資訊分發協定，在世界上最為流行。 此前，所有互聯網流量都基於上世紀70年代開發的傳輸控制協定（TCP）系統。 TCP是一種通訊端連接，需要確認數据包傳遞。 它將大檔案和消息分解為1500位元組的數据包，每個數据包包含數据包的源地址和目標地址。發送方等待確認發送的數据包已成功送達，然後才發送下一個數据包。 如果傳送失敗或傳送訊號沒有在指定的超時時間內到達，數据包將再次發送，但發送速率較低。 它可以持續很久，速度呈指數下降，直到傳遞成功的訊號出現。 很明顯，即使是很小的線路問題也會嚴重影響資料速率，因為每次發送失敗都會損失寶貴的毫秒。 囙此，FAST引入了一種解決方案——系統不斷監控數据包和接收到的消息，以便立即檢測線路上的問題，並將下一次發送設定為穩定的速率，儘管這樣速率略有降低。這種方法在大多數情况下無需重新發送數据包，因為它不需要花費時間來檢測效能是否緩慢。 在某些交換機中，連接介面通過兩種類型的連接實現：UDP和TCP。 在UDP通訊端上發送所有數據毫無意義，因為這樣的連接不需要確認傳遞，數据包就會消失，任何一方都不會知道。 囙此，大多數數據通過UDP通訊端傳輸，只有未傳輸的數据集通過TCP傳輸。 在快速發展的市場中，與重傳相關的延遲通常是不受歡迎的，這會導致錯過機會或糟糕的交易。

FAST 的工作原理

正如我們已經知道的，FIX協定是一系列欄位，這些欄位依次由key=value對組成。 除了字串格式本質上是冗餘的這一事實之外，您可能會注意到每條消息都有重複的元素，例如欄位名和“=”字元。 FAST通過使用描述整個消息結構的範本來消除冗餘。 這種方法稱為隱式標記。 由於傳輸數據中的固定標記只是“隱含的”，囙此Tag=Value的語法變化如下：

• 範本描述了一組帶有運算子的結構化欄位；
• 消息中的欄位序列與範本中的標記序列匹配；
• 消息中只發送更改數據。

每個標記值都有固定的位元組長度。 知道特定欄位的長度以及欄位在消息中的放置順序，就不難識別消息中這些欄位的值。 囙此，範本只允許直接傳輸數據本身，而無需傳輸冗餘字元。 這種編碼被稱為簡單二進位編碼，或SBE。 囙此，消息編碼和解碼的延遲比字元協定低得多，因為不需要將資料轉換為電腦可以使用的格式。由於相應欄位在消息中處於固定位置，囙此訪問所需值要容易得多。 您只需要知道它相對於消息開頭的偏移量，以及它的值的長度。 與標籤和FIXML不同，SBE消息不是自我描述的。 只有具有最小標頭的數據才會通過網絡發送，以標識控制消息的範本。 描述消息結構的中繼資料（範本）在主通信通道之外交換。 在收到必要的範本後，交易服務器知道在該連接會話的框架內以何種格式向用戶端發送數據。 囙此，在傳輸數據之前，系統在未來如何與它們通信的問題上以某種管道達成一致。 消息模式通常以XML格式發送。 它可以包含任意數量的消息範本。 範本描述了組成消息的欄位。 此外，該模式還提供了一個簡單和複雜的資料類型清單，可以在任意數量的欄位中重新使用。

針對FIX協定的不同語言的開放實現

Java – QuickFIX/J – http://www.quickfixj.org/

.NET/C# – QuickFIX/N – http://quickfixn.org/

免費線上FIX消息解析器- FIX解析器 – https://fix.aprics.net/

開放式語言實現

For C – FPL的參攷實現 – www.fixprotocol.org/fastdownload

For C# – FPL的參攷實現 – www.fixprotocol.org/fastdownload

Java л д code – OpenFAST – www.openfast.org

www.sourceforge.net/projects/openfastdotnet/ Д я

Для C++ – QuickFAST – www.quickfast.org

Для Golang – goFAST – www.github.com/co11ter/goFAST

其他協定FIX編碼

FIX社區還開發了FIX協定和其他數據序列化協定之間的標準映射，例如：

• JSON
• Google（協定緩衝區）

|ASN.1

FIX/FAST協定應用領域

通常情况下，縮寫詞是兩個單詞同時出現的。 用於從貿易交易所獲取各種金融資訊：金融工具錶（價格、數量等）、報價、所有交易、指數，以及有關所有非個人應用程式的資訊。 獲得的數据集可能因交換而不同。主要的FIX/FAST是：

• 私人交易商進行交易
• 程式師可以基於這項科技創建產品。 比如 – FIX API 交易平臺, 不同交換機的連接器，交易系統，數據收集系統和統計資料。
• 交易所之間的資訊交流
• 獲取各種資訊機构的最新資料

最常見的用途是高頻交易者通過直接市場准入（DMA）獲得超過其他市場參與者的優勢。 該協定可由證券交易所、銀行和外匯經紀人納入交易生態系統。 根據眾所周知的數據，加密貨幣交易所不使用這種技術。 從歷史上看，這些交易所大多使用WebSocket連接來獲取市場資訊，使用HTTP rest API連接來進行交易操作，從而直接連接到交易員的交易服務器。 如果WebSocket科技在速度上仍然與TCP連接相當，那麼HTTP rest API會損失很多。