金融交易协议总结.docx

金融信息互换协议（FIX）
1协议简介
1.1FIX地位及作用
金融信息传输业有多种标准同时并存，为避免混乱及反复使用，FIX协议是一个免费的开放式通信标准，于1992年由富达投资和所罗门兄弟为推动股票交易双边通信框架而开发。自诞生以来，FIX协议顺应行业不断变化的需求和其他资产类别的规定而取得了长足发展，其使用亦日益普遍。

1.2FIX国内外使用情况
FPLMemberFirms，表态支持并加入FIX的组织，重要有以下几个方面的组织：
l Buy-sideinstitutions：美国世纪投资公司、高桥资本等26个单位；
l Sell-sidebroker/dealers：摩根、国信证券等55个单位；
l ECNs/Exchanges：上交所、纳斯达克、香港交易所等37个单位；
l Associations：ISO等14个单位；
l Vendors：IBM、FIXSolutions等140多个单位。
2023年《中国FIX电子交易会议》记载，已有超过10000家机构正在使用FIX协议，其中涉及：几乎所有重要证券交易所和投资银行，全球最大的共同基金和货币经理，数千家小型投资公司，领先的期货交易所提供FIX连接，重要的债券交易商已经实行或正在实行FIX连接。
1.3FIX版本
Fix协议现有的版本应用4.X-5.0sp2。国外投行重要应用4.5-5.0，国内投行处在试用尝试阶段，各种版本均有，但4.2居多。
5.0版本与4.X版本的不同：TI（thetransportindependence）特性，即传输无关框架。TI将FIX会话层从应用层协议中分离出来。在TI框架下，应用层协议消息可以通过任意合适的传输技术进行传送，在这里，FIX会话层协议是FIX应用层消息的可选传输传输协议之一。

1.4FIX协议特点及其优势
FIX协议由于其开放的体系，具有如下四个重要特点：
l 使用简朴，各类应用系统可以依据FIX协议规则，编写自身的应用程序，应用于任何希望自动连接的交易双方，能支持各种商务功能。
l 规则开放透明，具有不断扩充的能力。为了把最大的灵活性给予用户，FIX鼓励用户自定义域。这些域应在已达成有关共识的交易各方范围内使用，并应小心使用，以避免在各方实行该协议之初的时候容易引发的冲突。FIX由一个非赚钱的FIX组织管理维护，公布FIX协议的标准化格式，在鼓励卖主加入该标准的同时，FIX始终保持中立。
l 不受载体的限制，它可通过租用数据线路、数据转接介质或在互联网上使用，
l 安全机制方面，FIX不提供特定的安全机制，它只是一个信息互换平台。但它支持任何双方允许的加密体系。
由于有上述的四个特点，实行FIX所带来的优势重要表现在：
l 减少整合各种内部操作程序的成本及复杂性
l 减少与新交易伙伴连接的成本及复杂性
l 由于规模经济效应或发掘共享基础设施的潜能，实现自动化解决所需的投入（如软件和硬件）因而下降
l 因人工重输信息或使用转换引擎所导致的潜在错误减少，市场参与者之间的通讯质量因此得到了提高
1.5FIX协议结构
FIX协议的格式存在着两种结构:tag=value结构和FIXML结构。目前采用的都是第一种方式来完毕数据互换。本报告重要讲述这种格式的消息。
其中FIXML可读性更强，但占用更多的带宽资源。
1.5FIX消息模式
FIX消息格式：每个FIX消息均由消息头、消息体和消息尾组成。每个消息均由一系列的<tag>=<value>字段组成，字段间用分隔符<SOH>(0x01)分割。
消息头开始顺序有如下三个字段：BeginString(tag#8)followedbyBodyLength(tag#9)followedbyMsgType(tag#35).此后还涉及有其他字段；消息尾就是一个CheckSum(tag#10)；
所有FIX消息都是以“8=FIX.x.y<SOH>”开始，以“10=nnn<SOH>“结束。
具体的消息格式在《中信证券FIXGW接入说明》中有说明。
2协议工作原理
2.1通信模型及基本概念
2.1.1通信模型
Initiator：发起者，建立通信连路，通过发送初始Logon消息发起会话的参与方。
Acceptor：接受方FIX会话的接受方。负责执行第一层次的认证和通过传输Logon消息的确认正式声明连接请求被接受。
原则：先发起者为Initiator，接受者为Acceptor。
标准模式以网关为Acceptor，客户端为Initiator做为常用模式。
2.1.2Fixconnection
FIX连接由3部分组成：logon登录，messageexchange消息传输，和logout注销。
2.1.3Fixsession
FIX会话由一个或多个FIXConnectionFIX连接组成。一个FIX会话可以有多次登录。
2.1.4SequenceNum
所有的FIX消息都由一个唯一的序列号进行标示。序列号在每一个FIX会话开始时被初始化为1，并在整个会话期间递增。监控序列号可以使会话参与者辨认和解决丢失的消息， 当在一个FIX会话中重新连接时可以快速进行应用程序同步。
每个会话将建立一组互不依赖的接受和发送序列。会话参与者将维护一个赋予发送消息的序列和一个监控接受消息的消息块间隙序列号。
2.1.5Heartbeats
在消息交互期间，FIX应用程序将周期性产生Heartbeat心跳消息。该心跳消息可以监控通信链路状态及辨认接受序列号间隙。发送Heartbeat的周期间隔由会话发起者使用在Logon消息中HeartBtInt域进行定义。
Heartbeat心跳消息的时间间隔应当在每一个消息发送后复位，即发送一个消息后，在间隔给定的时间内无其它消息发送则发送一个Heartbeat心跳消息。HeartBtInt的值应当被会话双方认同，由会话发起方定义并由会话接受者通过Logon消息进行确认。同一个HeartBtInt被会话双方——登录的发起者和登录的接受者共同使用。
2.1.6Dataintegrity和Checksum
消息数据内容的完整性可以参用两种方式来验证：消息长度和效验码检查。
程序通过计算BodyLength域到（并包含）在CheckSum标记（“10=”）后的分界符的字符数与在BodyLength中标示的消息长度进行比较来完毕完整性效验。
2.1.6CheckSum
ChekSum完整性检查，通过计算从域“8=”中“8”开始，涉及紧跟在CheckSum标记域的分界符<SOH>每个字符的2进制和同CheckSum进行比较得到。
一个FIX消息校验和通过计算到ChechSum域（但不涉及）的消息的每个字节和得到。然后，校验和被转换为模256的数字用于传送和比较。校验和在所有加密操作之后被计算。
产生校验和的代码示列如下：
char*GenerateCheckSum(char*buf,longbufLen)
{
staticchartmpBuf[4];
longidx;
unsignedintcks;
for(idx=0L,cks=0;idx<bufLen;cks+=(unsignedint)buf[idx++]);
sprintf(tmpBuf,“%03d”,(unsignedint)(cks%256));
return(tmpBuf);
}
2.1.7MessageAck
FIX协议不支持单个消息的确认。采用的是监控消息时隙的方法来进行消息恢复和验证。
普通的数据传送（无单个消息确认）通过消息序列间隙进行错误辨认。每个消息由一个唯一的序列号进行标示。接受端应用程序负责监控接受消息序列号以辨认消息间隙并产生重传请求。
每个FIX参与方必须为FIX会话维护两个序列号，一个是接受序列号，一个是发送序列号，两者都在建立FIX会话开始时初始化为1。每个消息被赋予一个唯一的序列号值，并在消息发送后递增。此外，每个收到的消息都有一个唯一的序列号，接受序列号计数器在收到每个消息后将会被递增。
当接受序列号与所希望得到的的对的序列号不必配时，必须采用纠错解决。
2.1.8Encryption
加密算法由连接双方共同协商。
一个消息的任何一个域可以被加密并放在SecureData域中。然而，一些显示的标志域必须采用明文进行传输。为保证完整性，明文域可以在SecureData域中反复。
当使用加密时，建议但不是必须，所有的消息体都进行加密。假如一个消息中的反复组数据中的部分数据要加密，这个反复组必须所有进行加密。
预先协商好的加密算法在Logon消息中进行声明。
2.1.9Userdefinitionfield
FIX为给用户提供最大的灵活性，FIX协议允许用户自定义域。这些域在认同的参与者之间实现、应用，并且应注意避免冲突。
Tag数在5000到9999保存用于用户自定义域。这些tag值用于公司联盟的信息互换。可以通过FIX网站进行注册。
10000以上保存用于单一公司内部使用。不用注册。
2.2会话层协议
2.2.1Logon登陆
建立一个FIX连接，分别包含3个操作：
l 创建通信层链路
l 接受者认证/接受发起者
l 消息同步（初始化）。
连接流程如下：
会话发起者同会话接受者建立通信链路，即TCP连接。
发起者发送一个Logon消息。接受者检查Logon消息，认证发起者身份。Logon消息包含支持之前双方协商好的认证方法所必须的数据。假如发起者被成功认证，接受者用一个Logon消息进行响应。假如认证失败，会话接受者将关闭链接，之前可以选择发送一个Logout消息以提醒认证失败的因素。这个Logout消息不是必须发送的。
在发起者认证通过之后，接受者立即响应一个Logon确认消息。依据会话使用的加密方法，这个Logon消息可以，也可以不报还同样的会话密钥。发起者方将把接受方返回的Logon确认消息视为一个FIX会话建立的标志。假如会话接受方选择单边会话加密密钥，会话的发起方必须发送一个Logon消息到对方以确认密钥改变请求。这样，能让会话接受者知道发起者何时开始使用新的会话密钥。发起方和接受方必须在发送任何查询或新消息之前通过询问MsgSeqNum域来同步其消息。发起方能通过比较确认Logon消息的MsgSeqNum及下一个盼望值来侦测消息的间隙。
2.2.2Messsageexchange消息互换
初始化过程完毕之后，将会进行正常的数据信息互换。重要涉及管理消息和应用消息的传送。
2.2.3Logout注销
正常的消息互换的终止将通过互换Logout消息来完毕。一般设计上会发送一个TestRequest消息强制请求从对方获取Heartbeat。这样可以帮助判断没有序列间隙。
在实际的会话关闭前，Logout的发起者应等待对方响应一个Logout确认消息。这种方式给接受者在需要时一个执行任何间隙填充错作的机会。一旦ResendRequest消息被接受，接受者应发起Logout操作，并且接受者在适当的时间表内没有响应，会话可以终止。
2.2.4重传请求消息
下面四项待补充：
重传请求消息
测试请求消息
重传请求消息
Reject消息
2.3应用层协议（待补充）
最重要的：委托，查询，撤单，执行回报
3国内现有应用方案
金证：
n 将Fix协议的请求通过C/C++或XML方式转化成业务系统相应协议，同时转发回解决结果回报。使得在业务系统与FIX接入方系统之间通过FIX协议进行互通连接。
国信：GsApiFPL成员
根网科技：
恒生：
深圳证券通信公司：
Bloomberg、恒生、金证、根网、上期技术
4如何开发FIX程序
4.4.1开发需求
短期需求：
实现FIX4.2协议的客户端接入。
快速准确的协议解释及翻译。
与恒生柜台高速有效地通讯。
实现路由功能，作为客户端和服务端的适配器，实现星型连接。
实现基本的股票交易查询等功能点。
强大的监控功能。
具有安全性保障。
4.4.2开发方法
一般情况下，FIX开发中涉及到两方面，一个是会话层和应用层。应用层即业务逻辑相关的层面，在把握好业务逻辑后，相对固定简朴。然而对于会话层的实现，涉及太多的方面，因此推荐采用现有的FIX引擎来开发。
，当然，还涉及一些没有登记上去的FIXengine。国内现有的开发重要采用开源并且跨语种的QuickFIX引擎。
QuickFIX可以灵活的运用在C++、C#、Java、Python、Ruby等编程语言之中。该引擎是目前应用较为广泛的FIX协议应用程序，但关于QuickFIX的文档还不是很多，有关它的技术资料可以登陆。
4.4.2测试方法（待补充）
会话层测试方法
应用层测试方法
参考文献
.org
《FIX-5.0_VOL-X》
《FIX-4.2_VOL-X》
《标准化和FIX协议：建立标准的市场源头》
《中信证券FIX网关接入说明》
《金融数据互换国际标准在证券》
金证《FIX网关解决方案.ppt》
《newordersingle.pdf》