1.?? 什么是FIX
Financial Information eXchange(FIX)金融信息交換協議的制定是由多個致力于提升其相互間交易流程效率的金融機構和經紀商于1992年共同發起。這些企業把他們及他們的行業視為一個整體,認為能夠從對交易指示,交易指令及交易執行的高效電子數據交換的驅動中獲利。FIX由此誕生,一個不受單一實體控制的開放消息標準,一個能夠被調整組建適用于任何一個企業的商務需求的協議。
FPL(FIX Protocol Limited)認為FIX的優勢在于:
- 就商務流程而言,FIX為機構,中間商,以及其他市場參與者提供了一個減少不必要的電話溝通和瑣碎的文檔傳遞方法,為面向特定個體傳遞高質量的信息提供便利。
- FIX為于技術專家提供了一個開放的標準,對他們開發的努力和實踐產生了影響,使他們能高效地創建同一個更大范圍的參與者之間的聯系。
- FIX可以為賣主提供一條現成的通往行業的信息存取路徑,減少了市場營銷的難度,增加了潛在的客戶群。??
開放性已成為FIX成功的關鍵。出于開放的原因,當在鼓勵各方參與標準制定時,FIX保留了參與者需求的不確定性。同時FIX避免“過標準化over-standardization”。它不受限于一個簡單類型的載體,及一個簡單的安全協議。它把決定權交給使用它的多個企業。FPL希望這種鼓勵在非標準化領域的努力能夠促進技術的完善。?
FIX現已被許多企業和銷售商使用。它已經成為行業內的推薦的消息協議。FIX已經從最初的買方-到-賣方的證券交易中得到發展。現在被廣泛的用于交易市場,及其它市場參與者。除了證券交易,FIX現在支持4種產品:Collective Investment Vehicles (CIVs)集成投資工具(?), Derivatives金融衍生產品,Fixed Income(?),Foreign Exchange外匯交易(?)。
FIX協議是一個消息標準,促進與安全交易相關的信息交換,在希望進行自動通信的交易對手間進行使用。該消息協議將支持各種商務功能。 FIX最早用于支持美國國內的委托人間基于直接信息流轉的證券交易。隨著協議本身的發展,增加了大量的支持多邊界交易的、衍生工具及其它產品的數據域。同樣,該協議被擴展允許第三方參與于交易對手間的信息傳遞。隨著FIX后續版本的發布,期待它的功能將繼續得到發展。
FIX協議包含2個層次:會話層和應用層。會話層與數據的通信相關;而應用層定義了商務相關數據內容。
? 2006年10月,FPL發布了FIX5.0。FIX5.0引入TI(the transport independence )傳輸無關框架。TI將FIX會話層從應用層協議中分離出來。在TI框架下,應用層協議消息可以通過任意合適的傳輸技術進行傳送,在這里,FIX會話層協議是FIX應用層消息的可選傳輸傳輸協議之一。兩個協議層的版本標注將會有所不同,FIX X.Y為FIX應用層協議版本;FIXT X.Y為FIX會話層協議版本編號。
2.?? FIX5.0新增特性概述
? 2.1.TI——the transport independence

上圖描述了在TI框架下傳輸機制的變化。它能夠用于承載所有FIX應用層協議的消息。
?2.2.Application Versioning
2.3.Service Pack Mangement
2.4.Extension Pack Mangement
Flexibility Provided by FIX 5.0 FIX 5.0 提供的靈活性
3.?? FIX協議語法概述
目前,FIX協議存在2種語法格式。
1?“標記=值”語法格式
2?“FIXML語法”語法格式
同一個商業信息流適用于任何一種語法。
3.1.普通FIX語法規則(Common FIX Syntax Rules)
普通FIX語法規則,是對“標記=值”和“FIXML”2種語法都適用的一般規則。
3.1.1?? Data Type
- int:整型?沒有小數點,逗號,可以包含正負號的數字序列。注,int的值前面可以包含0。(如 “00023” = “23”).
Examples:???????? 723 in field 21 would be mapped int as |21=723|.
-723 in field 12 would be mapped int as |12=-723|
- ?float: 浮點數。可包含小數點和正負號的數字序。累計總長度為15個數字。前面可以有0,小數末尾可加零,或截尾
- String: 字符串。是大小寫敏感的。
- char: 字符。除分界符號SOH外的字符。大小寫敏感。.
- data:?原始數據。 沒有格式和內容限制。之前緊接有一個長度域。長度域應制定data數據域包含的字節數(不好含分界符所占字節)。數據中可能包含分界符字節,所以需要用data類型數據長度來輔助區別。
3.1.2 Pattern Data Type 結構數據
結構化數據用于建立和提供數據域的有效值是否基于FIX數據類型或其它結構數據類型一些限制
3.1.3 Required Fields 必選數據域
協議每個消息由必選、可選和條件必選(根據其他域的不同)數據域構成。系統應當設計成可支持只提供必選和條件必選數據域的相關操作。
3.1.4 FIX “Tag=Value” SYNTAX “標記=值”語法
3.1.4.1 Message Format消息格式
FIX消息的一般格式為:一個標準頭+消息體+一個標準的尾部
每個消息由一個包含多個 ,由分界符隔開的,“標記=值”數據域的流構成。標記為TagNum數據類型。所有的標記都有一個特定的值。可選域可以不出現。無值消息將會產生一個Reject消息。
1.??????? FIX消息的一般格式為:一個標準頭+消息體+一個標準的尾部
2.??????? 消息頭的前三個域為
BeginString(tag #8)+BodyLenth(tag#9)+MsgType(tag#35)
3.????? 標準消息尾的最后一個域為CheckSum(tag#10)
4.????? 在重復數據組內的數據域必須按照FIX規范文檔中規定的順序明確定義。Noxxx域,xxx表示循環組的計數,必須放置在循環組數據內容的的前面。
5.????? 一個特定的tag 數應當是唯一的。如果重復,將被認為是一個違反規范文檔的錯誤。錯誤應當向FIX Global Technical Committee報告
此外,某些數據類型為Multiple CharValue的數據域,可以包含多個由空格隔開,由一個SOH技術的多個部分。
在同一個消息里,包含明文部分和密文部分的數據的數據域也是可能的。通常用于驗證和認證。比如3.1.4.2 3.1.4.2 Field Delimiter: 域分界符
數據域分界符,在FIX一個消息內的所有數據域由一個分界字符標記結尾。用ASCII碼的“SOH”(#001,hex:0x01)進行間隔。所有消息由“8=FIX.x.y<SOH>”標記開始,最后由“10=nnn<SOH>“標記結束。3.1.4.3 Repeating Groups:循環組
允許在一個循環組里出現重復的數據域。372=x<SOH>為循環組的第一個域???
·??????? 如果使用循環組,循環組的第一個域是必選項,作為新循環組的一個分界。該第一域緊跟在NoXXX后面,然后,當NoXXX值大于0時,變成當條件必選。
·??????? NoXXX域(比如,NoTradingSessions,NoAllocs)定義了循環組實例的數量,對一個循環組只出現一次,且必須在循環組內容之前。
·??????? 如果在一個循環組中的一個域是必選的,則NoXXX是必選的。如果所有循環組中的成員是可選的,則NoXXX域也應該是可選的。
·??????? 如果一個循環組域被列為必選,則它必須出現在該循環組的每一個實例中。
·??????? 循環組在消息中被設計成通過縮排,和à符號進行定義。一些循環組可以在其他循環組中級聯出現。可大于一層的級聯。
Example of nested repeating group
Portion of New Order - List message showing a nested repeating group for allocations for each order. Note the NoAllocs repeating group is nested within the NoOrders repeating group and as such each instance of the orders repeating group may contain a repeating group of allocations. | |||||
73 | NoOrders | Y | Number of orders in this message (number of repeating groups to follow) | ||
-〉 | 11 | ClOrdID | Y | Must be the first field in the repeating group. | |
-〉 | 526 | SecondaryClOrdID | N | ||
-〉 | 67 | ListSeqNo | Y | Order number within the list | |
-〉 | 583 | ClOrdLinkID | N | ||
-〉 | 160 | SettlInstMode | N | ||
-〉 | component block?<Parties> | N | Insert here the set of?"Parties" (firm identification) fields defined in "COMMON COMPONENTS OF APPLICATION MESSAGES" | ||
-〉 | 229 | TradeOriginationDate | N | ||
-〉 | 1 | Account | N | ||
-〉 | 581 | AccountType | N | ||
-〉 | 589 | DayBookingInst | N | ||
-〉 | 590 | BookingUnit | N | ||
-〉 | 591 | PreallocMethod | N | ||
-〉 | 78 | NoAllocs | N | Indicates number of pre-trade allocation accounts to follow | |
-〉 | -〉 | 79 | AllocAccount | N | Required if NoAllocs > 0.?Must be the first field in the repeating group. |
-〉 | -〉 | 467 | IndividualAllocID | N | |
-〉 | -〉 | component block?<NestedParties> | N | Insert here the set of?"Nested Parties" (firm identification "nested" within additional repeating group) fields defined in "COMMON COMPONENTS OF APPLICATION MESSAGES" | |
-〉 | -〉 | 80 | AllocQty | N | |
-〉 | 63 | SettlmntTyp | N | ||
-〉 | 64 | FutSettDate | N | Takes precedence over SettlmntTyp value and conditionally required/omitted for specific SettlmntTyp values. | |
Rest of the message not shown |
3.1.4.4 User Defined Fields: 用戶自定義域
為給用戶提供最大的靈活性,FIX協議允許用戶自定義域。 這些域在認同的參與者之間實現、應用,并且應注意避免沖突。
Tag數在5000 到9999保留用于用戶自定義域。這些tag值用于企業聯盟的信息交換。可以通過FIX網站進行注冊。
10000以上保留用于單一企業內部使用。不用注冊。
3.1.4.5 Precautions when using UNICODE 使用UNICODE的注意事項
如果使用UNICODE編碼,則SOH可能出現在編碼內容中。所以一個FIX引擎必須使用EncodedLen值去摘取正確長度的字節數據。
3.1.5 FIXML SYNTAX?FIXML語法
FIXML Highlights重要信息
·???????FIXML是創建FIX消息的XML字典
·???????使用同樣的FIX數據字典和商業邏輯。
·???????主要關注FIX應用層消息,不對會話層進行規范
·???????能被封裝在FIX會話層協議和其他協議,如果MQ TIBCO SOAP等協議當中。
3.1.5.1Background背景
1998年,FPL FIXML工作組開始引入XML格式,并發布白皮書支持一個改進方法將FIX協議遷移到XML格式。工作組在1999年1月15日,發布了一個初始版本FIXML DTDs。當前版本的DTDs基于FIX4.1,4.2和4.3版。FIXML Schema 基于FIXML,緊接著在FIX4.4后發布。
1.?????FIX and FIXML Version and Comparison using New Order Single Message
一個“新指令消息(New Order)”的FIX和FIXML不同伴本的比較。
FIX tag=value Version
The following is a FIX 4.2 New Order Single message in classic tag-value pair format:
以下是FIX4.2版本New Order單一消息的經典“符號-值”格式表示
8=FIX.4.2^9=251^35=D^49=AFUNDMGR^56=ABROKER^34=2^52=20030615-01:14:49^11=12345^1=111111^63=0^64=20030621^21=3^110=1000^111=50000^55=IBM^48=459200101^22=1^54=1^60=2003061501:14:49 38=5000^40=1^44=15.75^15=USD^59=0^10=127
注意:^為SOH分界符
此消息長度為195字節。.
FIXML 4.2 Version
基于FIXML 4.2 DTD 的
<FIXML>
<FIXMLMessage>
<Header>
<PossDupFlagValue="N"/>
<PossResendValue="N"/>
<SendingTime>20020103-12:00:01</SendingTime>
<Sender>
<CompID>AFUNDMGR</CompID>
</Sender>
<Target>
<CompID>ABROKER</CompID>
</Target>
</Header>
<ApplicationMessage>
<Order>
<ClOrdID>1968</ClOrdID>
<Account>4130287</Account>
<HandlInstValue="1"/>
<ExDestinationValue="L"/>
<Instrument>
<Symbol>IBM</Symbol>
<SecurityID>459200101</SecurityID>
<SecurityIDSourceValue="1"/>
</Instrument>
<SideValue="2"/>
<TransactTime>20021120-12:13:12</TransactTime>
<OrderQtyData>
<OrderQty>1000</OrderQty>
</OrderQtyData>
<OrdTypeValue="2"/>
<Price>93.25</Price>
<CurrencyValue="USD" />
</Order>
</ApplicationMessage>
</FIXMLMessage>
</FIXML>
長度為684字節,是FIX tag=value消息的3倍多。實際上,3-5倍
FIXML 4.4 Schema Version
FIXML 4.4 Schema.
<FIXML>
<OrderClOrdID="123456"
???????????????????Side="2"
??????????????????? TransactTm="2001-09-11T09:30:47-05:00"
??????????????????? OrdTyp="2"
??????????????????? Px="93.25"
??????????????????? Acct="26522154">
??????????????????? TransactTm="2001-09-11T09:30:47-05:00"
??????????????????? OrdTyp="2"
??????????????????? Px="93.25"
??????????????????? Acct="26522154">
???????? <HdrSnt="2001-09-11T09:30:47-05:00"
???????????????? PosDup="N"
???????????????? PosRsnd="N"
???????????????? SeqNum="521">
???????????????? PosDup="N"
???????????????? PosRsnd="N"
???????????????? SeqNum="521">
???????????? <SndrID="AFUNDMGR"/>
???????????? <TgtID="ABROKER"/>
???????? </Hdr>
???????? <InstrmtSym="IBM"
??????????????????? ID="459200101"
??????????????????? IDSrc="1"/>
??????????????????? ID="459200101"
??????????????????? IDSrc="1"/>
<OrdQtyQty="1000"/>
</Order>
</FIXML>
長度為348,比原始FIX tag=value消息長70%相對前一個格式,就可閱讀性而言,沒有重要數據丟失。
Sample Message Content 消息內容實例
The following table is included to help clarify the message content shown above
Tag/Attribute | Meaning |
<FIXML> | Root element |
????? <Order ??????????????????? ClOrdID="123456" ?????????????? ?????Side="2" ??????????????????? TransactTm="2001-09-11T09:30:47-05:00" ??????????????????? OrdTyp="2" ??????????????????? Px="93.25" ??????????????????? Acct="26522154"> | New order Client’s order ID Sell order Transaction time Limit order Limit price Customer’s account |
????? ????? <InstrmtSym="IBM" ???????????????????? ID="459200101" ???????????????????? IDSrc="1"/> | Stock symbol Stock CUSIP (ID source=CUSIP) |
????? ????? <OrdQtyQty="1000"/> | Order quantity |
????? </Order> | Close of order |
</FIXML> | Close root element |
FIXML 4.4 Schema設計目標
FIXML消息設計目標
這些設計目標是指FIXML的實例文檔。
·???????W3C.FIXML的實現應當遵照W3C的XML技術標準。
·????????FIXML的實現應當是適合在大容量數據傳輸場景的實現。其目標應用:
·????????Order(指令)路由
·????????交易報告和交易后處理
·????????產品(證券)信息分配
·????????市場創建的低容量應用。Market making for lower volume applications ???
·????????應當做到帶寬占用的最小化。少于FIX tag=value格式長度的1.5倍。
·????????在遵循前面原則的基礎上,仍維持FIXML消息的可讀性。
·????????同FIX 4.4 tag=value相同,在FIXML里支持FpML產品規范。
·????????支持FIX tag=value消息的翻譯相互轉換。
·????????提供對ISO15022的相互參照,包括每個消息,元素和組件。
·????????維持可擴展性和客戶個性化
·?????????增加自定義消息的能力。
·????????在消息、組件塊 和重復組中添加自定義域的能力.
·????????FIXML的實現應當提供所有層次的傳輸無關性。
·????????FIXML的實現應當能夠支持FIXML版本識別。
Design Objectives for the Schema Document
Schema文檔的設計目標
·????????FIXML Schema 應當使用當前事實上的,最好的XML Schema行業應用實踐來實現。
·????????FIMXL Schema 應當采用完全支持FIXML4.4 Schema版本方式來實現。
·????????支持版本的識別。
·????????提供足夠的meta-data來識別FIX 域名稱,組件類型,tag編號,ISO 15002庫的交叉飲用。
·????????保持與FpMLSchema的互操作和兼容。
楊航收集技術資料,分享給大家
The FIXML Schema shall be based upon and be compatible with the current version of XML schema:Hhttp://www.w3.org/2001/XMLSchemaH
楊航收集技術資料,分享給大家
?