前言

金融資訊交換 (Financial Information eXchange, FIX) 是用於證券產業電子資訊交換 (Electronic Data Interchange, EDI) 的協定，最早是誕生於1992年，當時僅是用於富達投資 (Fidelity Investments) 與所羅門兄弟 (Salomon Brother) 間對於證券交易與市場資訊進行資料交換使用，在當時，這樣的通訊協定稱為"富達資訊交換協定 "(Fidelity Information eXchange)。後來，經由各家銀行、券商、投資機構以及相關資訊科技產業的技術討論下，彙整出了一個全球共通的規範版本，並成立了金融資訊交換協定有限公司 (FIX Protocol Ltd.) 處理協定的相關事務，並因應需求，進行版本的修正與更新。

相較於國外的電子資訊交換協定，國內最早進行電子資訊交換是在1994年。一直到近年來，FIX在國內逐漸普及，台灣證券交易所也在去 (2009) 年十二月發佈了台灣官方的FIX電文規範，為台灣在金融交易方面與國際接軌的作為定調，也在技術層面，為將來與國外資金直接進行金融交易行為拓展了其可能性。

版本沿革

FIX協定經過了十餘年來的發展，歷經不斷的改良與版本更新，除了因應不斷創造出來的實體或衍生性金融商品，以及各式各樣或經過改良或新穎的交易途徑，亦須跟隨著在技術面上的不斷精進而有所異動。目前我們在官方網站上能看得到的最早的版本是在1996年發佈的4.0，在其後有1998年的4.1，2000年的4.2，以及其陸陸續續，每隔一兩年的一個次級版本變更。最新的版本則是在去年四月發佈的5.0 Service Pack 2。

由於FIX是因應金融資訊交換所生，於應用面所關注的是關於金融資訊、委託內容、行情等資料；於通訊面需要高度確保傳送/接收資訊的到達及其內容的正確性，所以FIX協定內容包含了兩個層級：Session層及Application層。Session層包括版本資訊、發送端資訊、接收端資訊、訊息序號，以及其他Session層級的標註資訊等；Application層則專注於所要交換的金融資訊內容。金融資訊內容隨著發送端與接收端，會有各自協議而有若干不同的部分，但在Session層集的資訊交換，由於攸關著Session連線是否能順利建立，進而影響到金融資訊交換的行為，所以在FIX協定中有較嚴謹的定義。FIX官方在2006年發佈了FIX T1.1 (FIX Transport 1.1)，這是FIX在歷經多次版本異動後，首次將Session層協定的相關規範獨立於Application層，單獨發佈。由此便可看出，FIX協定在Session層規範的嚴謹要求。

技術介紹

目前國內諸多與國外進行FIX交易之券商，皆是採用FIX 4.2的版本，而台灣證券交易所所制訂的FIX電文規範，亦是採用此版本，故本篇在介紹FIX技術內容時，將會以此版本為依據。

FIX協定所採用的底層通訊協定為TCP/IP，於此之上建構起Session層與Application層的協定規範。然則在FIX T1.1中所描述的，TCP/IP的採用係起因於此為現行最普及且穩定的網路協定，在實際運作上，傳統的X.25、乃至於Message Queue等，只要符合FIX T1.1中所規範之行為，皆是可接受之符合FIX標準的服務。

FIX協定的訊息可區分為Administrative訊息與Application訊息，而每個訊息皆包括Header、Body與Trailer等三個部分。訊息格式是不固定長度，由一連串的=所組成，彼此間使用分隔符號SOH (ASCII#=1) 分開。所謂的tag#即是用來標記這一組訊息是表示什麼樣的資訊，例如，tag#=44 表示價錢，44=17.95 便表示這筆訊息中，價錢的值是17.95。在大多數情況下，訊息的欄位都沒有固定的順序，僅規範所有Header欄位皆必須在Body之前，其中Header前三個欄位必須為8 (BeginString)、9 (BodyLength)、35 (MsgType)；而所有Trailer欄位皆須在Body之後，其中Trailer的最後一個欄位必須為10 (Checksum)，最後再以一個SOH結尾。也就是說，所有FIX的訊息皆應可表示為：

一、Administrative訊息

Administrative訊息即是被規範在FIX T1.1中，用來建立、維持並確保訊息傳送/接收的一系列訊息。其中包括Logon、Logout、Heartbeat、Test Request、Resend Request及Sequence Reset等等，運用在下列幾個Session層級的運作情境：

◎Logon：當Client端建立TCP/IP連線後，傳送此訊息做為建立Session的第一個訊息，當Server端收到Client傳來的Logon要求，須進行相關的驗證，如果通過了驗證，便回傳一個Logon訊息表示登錄成功，Session便就此建立起來；如果驗證失敗，便回傳Logout訊息並切斷TCP/IP連線。

◎Logout：當某一方要中止Session前，須要進行登出作業，然而在登出之前，須要先確認彼此傳送/接收的訊息皆沒有漏失。所以，登出之發起端應該傳送Test Request，而接收端應以Heartbeat訊息回應，這樣的動作，是要藉由其中所帶的Sequence Number資訊，確保對方有收到己方所傳送的最後一筆 (以及之前的每一筆) 訊息。完成這樣的動作後，方可送出Logout，而接收端在收到Logout之後，便回應Logout訊息並切斷連線。

◎Sequence Number同步：在FIX協定的規範中，Sequence Number的同步是相當重要且規範嚴謹的一環－整個協定是藉由這樣的機制確保所有傳送出去的訊息皆有被對方接收，而對方傳送出來的訊息己方皆有接收到。Sequence Number是在Header中的一個必要欄位，隨著每一個傳出的訊息遞增，己方所傳出的訊息有一套自己的Sequence Number，對方同樣也有一套，各自維護傳出的Sequence Number。

另一方面，為了驗證是否有漏失訊息，接收方亦須保存最近一筆接收到的訊息所帶的Sequence Number，當接收到了一個新訊息，便比對該Sequence Number與己方所保存的是否僅差1，若否，則表示有漏失訊息發生。同樣的，在Logon與Logout的過程中，亦須進行這樣的Sequence Number比對動作，以確保訊息。

當偵測到了訊息漏失，便應傳送Resend Request，告知對方訊息漏失Sequence Number區間，要求補送。對方在接收到Resend Request後，便應將相對應的訊息補送，或傳送Sequence Number Reset，強制設定新的Sequence Number。

◎Heartbeat ：為了確保Session連線狀態，FIX協定在規範了Heartbeat機制，當Session閒置過久時，便應傳送Heartbeat訊息以維持Session。

二、Application訊息

Application訊息即是關於金融資訊的內容交換，除了Header與Trailer部分，整個Body皆是金融資訊欄位。這個部份的定義範圍即為廣泛，也極具有彈性，這是為了兼容於不同買家、不同賣家、不同商品，乃至於不同交易途徑與模式等等，在制定之初便規範了甚多的訊息種類，也針對各個訊息規範了甚多的欄位。這部份由於不同的情境相去甚遠，將在下節以台灣證券交易所FIX規範為例做介紹。

台灣證券交易所FIX電文規範

台灣證券交易所在2009年十二月，發佈了FIX電文規範，雖然目前尚未正式上線，但這樣的舉動，不僅僅表示台交所對證券交易的相關技術關注不遺餘力，也更為國內金融市場提供了一項新途徑－一項與國際接軌，在技術上打通與國外資本市場流動通道的康莊道路。

在台交所公佈的FIX規範中，明定將採用的是FIX 4.2的版本，這同時也是國內諸多券商在與國外進行金融資訊交換時所採用的版本，對於國內券商要支援適用本版規範，可節省不少成本與力氣。另一方面，本規範對於Session層的規範大致皆與FIX協定所制定的標準一致，這也使得要以FIX線路與台交所進行委託交易的券商在依循FIX協定Session層標準後，便可將重點專注於台交所於Application層的規範。

一、系統架構



台交所推行FIX規範是與現行的TMP電文系統平行存在，並以不影響現行運作為最基本底線。所以針對由以FIX規範進行委託的線路皆需另外申請，與TMP線路是平行存在的。另外，交易所也公佈了每一FIX線路所能承載的委託量，約略是對應十條傳統TMP線路。

二、Application訊息

以現行TMP電文系統而言，皆是以T010 (整股子系統為例) 進行所有新單委託、刪、改單、委託單狀態查詢等等．而交易所關於業務面的回報則包括T020 (委託成功)、T030 (委託失敗)、R3 (成交回報) 等等。然而對FIX協定來說，每個動作皆有各自、較明確的功能訊息，例如，新單 (New Order - Single)、改單 (Order Replace Request)、刪單 (Order Cancel Replace Request)、查詢委託單狀態 (Order Status Request) 等等；在回報方面，FIX協定反而是處於匯多為一的一方，凡是委託成功、新單委託失敗、成交回報等等，皆是以執行回報 (Execution Report) 回覆，而刪、改單的委託失敗，則是以取消拒絕 (Cancel Reject) 回報。

三、與FIX協定的差異

以Application層面的規範來看，台交所的版本仍然大致上與FIX協定的標準一致，這對要實作與台交所對接的券商端來說，無疑是一個好消息；另一個更好的消息是，台交所為與現行TMP系統能無痛接軌，針對FIX協定標準無法滿足現有系統所提供的資訊與服務的若干情境，小幅修正了FIX協定在Application層的一些訊息欄位，以期能達到完全對應現有系統資訊。這包括：

◎不傳送暫態 (Pending) 訊息 ：FIX協定規範在接收到各個新、刪、改單後，而尚未進行業務面的處理前，應該傳送一個暫態訊息。這點在現行系統中是不存在的，對於現有的委託管理系統 (Order Management System，OMS) 也不具有任何業務面的實質意義，所以台交所將不傳送這類訊息。

◎不傳送委託單狀態 ：FIX協定規範在每筆回報中，需包含兩個狀態類的訊息，一個是此筆回報本身的狀態，另一個則是此筆回報所代表的委託單狀態。兩者在FIX標準中具有幾乎一致的候選值 (Candidate Value)，而後者的值是由每一筆回報狀態，經過優先順序比較運算過後得出的結果。由於現行的回報所包含的狀態皆是針對該筆回報本身，所以台交所在這方面的處理原則是：每筆回報的委託單狀態皆與回報本身的狀態一致，免去了運算委託單狀態的複雜度。

◎新增委託類型 (OrderType) 候選值 ：由於全球金融交易的手法各異，在FIX協定中並沒有適當的候選值來表示台灣的盤後定價交易，故台交所針對這部份，新增了一個候選值－Z (Limit after close)。

◎新增執行類型 (ExecType) 候選值 ：台交所針對新單委託，可能會因為剩餘的允許委託額度不足，而回覆委託成功 (T020)，但委託成功的張 (股) 數少於其新單委託的量。這樣的情境在FIX協定的標準中亦沒有適當的值可表示，所以台交所針對這部份，新增了一個候選值－P (Partial New) 。

◎委託書編號的機制 ：FIX協定對於委託書編號 (OrderID) 的規範是，由買方 (Buy Side) 進行一筆新單委託後，賣方 (Sell Side) 會針對該新單編給一個委託書編號，於執行回報中回報給買方。然而目前國內委託交易之委託書編號，是由買方 (券商端) 依據己方之委託序號，連同櫃號組合而成，在新單委託中傳送至交易所。台交所在自己所制定的FIX電文規範中，也將之修正為與現行系統一致，也就是 OrderID 是由在 New Order 中傳送至交易所，而非在回報中產生。

◎新增三個自定欄位 ：在新單委託中的投資人帳號標記 (InvacnoFlag)、委託類別 (OrdType，台交所既有的委託類別，與FIX中所定義的OrderType有截然不同的意義)、交易代碼 (ExCode) 等三個欄位，是FIX協定中沒有定義亦無對應欄位的，台交所為此三項欄位，在FIX協定所規範的自定欄位範圍 (Tag#>10000) 中，自行規範在自己的版本中。

未來展望

金融交易電子化是行之有年的事實，金融交易國際化是越演越烈的趨勢，在這兩者的推波助瀾之下，一個為全球所共同接受與支援的協定是勢在必行。FIX協定便是在這樣的背景下誕生，且已在先進國家中成長茁壯。台灣雖然金融交易已發展多年，金融交易電子化也已開花結果，但與國際間的金融交易流通，卻仍是在亦步亦趨的發展階段。再加上與我關係密切的海峽對岸，更是處於金融啟蒙階段。FIX所構成的商機，不僅僅是存在在全球化金融交易之中；單就FIX協定本身相關的伺服器、線路與路由服務等等，在亞太地區便已顯得潛力無窮。

參考資料

1.「FIX 標準在證券交易系統系統規劃模式之應用研究-以建華證券為例」張銀益/胡俊之/蔡明志/彭耀堯/李兆涵, 2005

2. FIX Protocol Ltd.

3. Wikipedia - Financial Information eXchange

4. FIX 4.2 Specification with 20010501 Errata

5. 台灣證券交易所 FIX電文規範手冊