金融信息交换协议（FIX）v5.0

时间：2021-08-14 14:36:57
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

金融信息交换协议（FIX）v5.0
上图描述了在TI框架下传输机制的变化。它能够用于承载所有FIX应用层协议的消息。
 
 
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后发布。
一个“新指令消息（ New Order ）”的 FIX 和 FIXML 不同伴本的比较。
 
 
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 DTD 的
< FIXML >
< FIXMLMessage >
< Header >
< PossDupFlag Value ="N" />
< PossResend Value ="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>
< HandlInst Value ="1" />
< ExDestination Value ="L" />
< Instrument >
< Symbol >IBM </Symbol>
< SecurityID >459200101 </SecurityID>
< SecurityIDSource Value ="1" />
</ Instrument >
< Side Value ="2" />
< TransactTime >20021120-12:13:12 </TransactTime>
< OrderQtyData >
< OrderQty >1000 </OrderQty>
</ OrderQtyData >
< OrdType Value ="2" />
< Price >93.25 </Price>
< Currency Value ="USD" />
</ Order >
</ ApplicationMessage >
</ FIXMLMessage >
</ FIXML >
长度为684字节，是FIX tag=value消息的3倍多。实际上，3-5倍
FIXML 4.4 Schema.
< FIXML >
     <OrderClOrdID="123456"
                    Side ="2"
                    TransactTm ="2001-09-11T09:30:47-05:00"
                    OrdTyp ="2"
                    Px ="93.25"
                    Acct ="26522154">
         < Hdr Snt ="2001-09-11T09:30:47-05:00"
                 PosDup ="N"
                 PosRsnd ="N"
                 SeqNum ="521">
             < Sndr ID ="AFUNDMGR"/>
             < Tgt ID ="ABROKER"/>
         </ Hdr >
         < Instrmt Sym ="IBM"
                    ID ="459200101"
                    IDSrc ="1"/>
         < OrdQty Qty ="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
            < Instrmt Sym ="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: H http://www.w3.org/2001/XMLSchema H

杨航收集技术资料，分享给大家

 


标签：

相关文章