【FIX协议】金融信息交换协议（FIX）v5.0读书笔记（1）

转自： http://blog.csdn.net/songzhang/article/details/1778118

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 值去摘取正确长度的字节数据。