fix1金融交易协议总结

金融信息交换协议（FIX） 1 协议简介 1.1 FIX 地位及作用 金融信息传输业有多种标准同时并存，为避免混乱及重复使用，FIX 协议是一个免费 的开放式通信标准，于 1992 年由富达投资和所罗门兄弟为推动股票交易双边通信框架而开 发。自诞生以来，FIX 协议顺应行业不断变化的需求和其他资产类别的要求而取得了长足 发展，其使用亦日益普遍。 1.2 FIX 国内外使用情况 FPL Member Firms，表态支持并加入 FIX 的组织，主要有以下几个方面的组织： Buy-side institutions：美国世纪投资公司、高桥资本等 26 个单位； Sell-side broker/dealers：摩根、国信证券等 55 个单位； ECNs/Exchanges：上交所、纳斯达克、香港交易所等 37 个单位； Associations：ISO 等 14 个单位； Vendors： IBM、FIX Solutions 等 140 多个单位。 2008 年中国 FIX 电子交易会议记载，已经有超过 10000 家机构正在使用 FIX 协议， 其中包括：几乎所有主要证券交易所和投资银行，全球最大的共同基金和货币经理，数千 家小型投资公司，领先的期货交易所提供 FIX 连接，主要的债券交易商已经实施或正在实 施 FIX 连接。 1.3 FIX 版本 Fix 协议现有的版本应用 4.X-5.0sp2。国外投行主要应用 4.5-5.0，国内投行处于试用尝 试阶段，各种版本均有，但 4.2 居多。 5.0 版本与 4.X 版本的不同： TI（the transport independence ）特性，即传输无关框架。 TI 将 FIX 会话层从应用层协议中分离出来。在 TI 框架下，应用层协议消息可以通过任意 合适的传输技术进行传送，在这里，FIX 会话层协议是 FIX 应用层消息的可选传输传输协 议之一。 1.4 FIX 协议特点及其优势 FIX 协议由于其开放的体系，具有如下四个主要特点： 使用简单，各类应用系统可以依据 FIX 协议规则，编写自身的应用程序，应用于 任何希望自动连接的交易双方，能支持各种商务功能。 规则开放透明，具有不断扩充的能力。为了把最大的灵活性给予用户，FIX 鼓励 用户自定义域。这些域应在已达成有关共识的交易各方范围内使用，并应小心使 用，以避免在各方实施该协议之初的时候容易引发的冲突。FIX 由一个非盈利的 FIX 组织管理维护，公布 FIX 协议的标准化格式，在鼓励卖主加入该标准的同时， FIX 始终保持中立。 不受载体的限制，它可通过租用数据线路、数据转接介质或在互联网上使用， 安全机制方面，FIX 不提供特定的安全机制，它只是一个信息交换平台。但它支 持任何双方允许的加密体系。 由于有上述的四个特点，实施 FIX 所带来的优势主要表现在： 降低整合各种内部操作程序的成本及复杂性 降低与新交易伙伴连接的成本及复杂性 由于规模经济效应或发掘共享基础设施的潜能，实现自动化处理所需的投入（如 软件和硬件）因而下降 因人工重输信息或使用转换引擎所造成的潜在错误减少，市场参与者之间的通讯 质量因此得到了提升 1.5 FIX 协议结构 FIX 协议的格式存在着两种结构:tag=value 结构和 FIXML 结构。目前采用的都是第一 种方式来完成数据交换。本报告主要讲述这种格式的消息。 其中 FIXML 可读性更强，但占用更多的带宽资源。 1.5 FIX 消息模式 FIX 消息格式：每个 FIX 消息均由消息头、消息体和消息尾组成。每个消息均由一系 列的=字段组成，字段间用分隔符 (0x01)分割。 消息头开始顺序有如下三个字段：BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).此后还包括有其他字段；消息尾就是一个 CheckSum (tag #10)； 所有 FIX 消息都是以“8=FIX.x.y”开始，以“10=nnn“结束。 具体的消息格式在中信证券 FIXGW 接入说明中有说明。 2 协议工作原理 2.1 通信模型及基本概念 2.1.1 通信模型 Initiator ：发起者，建立通信连路，通过发送初始 Logon 消息发起会话的参与方。 Acceptor ：接收方 FIX 会话的接收方。负责执行第一层次的认证和通过传输 Logon 消 息的确认正式声明连接请求被接受。 原则：先发起者为 Initiator ，接受者为 Acceptor 。 标准模式以网关为 Acceptor，客户端为 Initiator 做为常用模式。 2.1.2 Fix connection FIX 连接 由 3 部分组成：logon 登录，message exchange 消息传输，和 logout 注销。 2.1.3 Fix session FIX 会话由一个或多个 FIX Connection FIX 连接组成。一个 FIX 会话可以有多次登录。 2.1.4 Sequence Num 所有的 FIX 消息都由一个唯一的序列号进行标示。序列号在每一个 FIX 会话开始时被 初始化为 1，并在整个会话期间递增。监控序列号可以使会话参与者识别和处理丢失的消 息， 当在一个 FIX 会话中重新连接时能够快速进行应用程序同步。 每个会话将建立一组互不依赖的接受和发送序列。会话参与者将维护一个赋予发送消 息的序列和一个监控接受消息的消息块间隙序列号。 2.1.5 Heartbeats 在消息交互期间，FIX 应用程序将周期性产生 Heartbeat 心跳消息。该心跳消息可以监 控通信链路状态及识别接收序列号间隙。发送 Heartbeat 的周期间隔由会话发起者使用在 Logon 消息中 HeartBtInt 域进行定义。 Heartbeat 心跳消息的时间间隔应当在每一个消息发送后复位，即发送一个消息后，在 间隔给定的时间内无其它消息发送则发送一个 Heartbeat 心跳消息。HeartBtInt 的值应当被 会话双方认同，由会话发起方定义并由会话接收者通过 Logon 消息进行确认。同一个 HeartBtInt 被会话双方登录的发起者和登录的接受者共同使用。 2.1.6 Data integrity 和 Checksum 消息数据内容的完整性可以参用两种方式来验证：消息长度和效验码检查。 程序通过计算 BodyLength 域到（并包含）在 CheckSum 标记（“10=”）后的分界符的 字符数与在 BodyLength 中标示的消息长度进行比较来完成完整性效验。 2.1.6 CheckSum ChekSum 完整性检查，通过计算从域 “8=” 中“8”开始，包括紧跟在 CheckSum 标记域 的分界符每个字符的 2 进制和同 CheckSum 进行比较得到。 一个 FIX 消息校验和通过计算到 ChechSum 域（但不包括）的消息的每个字节和得到。 然后，校验和被转换为模 256 的数字用于传送和比较。校验和在所有加密操作之后被计算。 产生校验和的代码示列如下： char *GenerateCheckSum( char *buf, long bufLen ) static char tmpBuf 4 ; long idx; unsigned int cks; for( idx = 0L, cks = 0; idx bufLen; cks += (unsigned int)buf idx+ ); sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) ); return( tmpBuf ); 2.1.7 Message Ack FIX 协议不支持单个消息的确认。采用的是监控消息时隙的方法来进行消息恢复和验 证。 普通的数据传送（无单个消息确认）通过消息序列间隙进行错误识别。每个消息由一 个唯一的序列号进行标示。接收端应用程序负责监控接收消息序列号以识别消息间隙并产 生重传请求。 每个 FIX 参与方必须为 FIX 会话维护两个序列号，一个是接收序列号，一个是发送序 列号，两者都在建立 FIX 会话开始时初始化为 1。每个消息被赋予一个唯一的序列号值， 并在消息发送后递增。此外，每个收到的消息都有一个唯一的序列号，接收序列号计数器 在收到每个消息后将会被递增。 当接收序列号与所希望得到的的正确序列号不必配时，必须采取纠错处理。 2.1.8 Encryption 加密算法由连接双方共同协商。 一个消息的任何一个域可以被加密并放在 SecureData 域中。然而，一些显示的标志域 必须采用明文进行传输。为确保完整性，明文域可以在 SecureData 域中重复。 当使用加密时，建议但不是必须，所有的消息体都进行加密。如果一个消息中的重复 组数据中的部分数据要加密，这个重复组必须全部进行加密。 预先协商好的加密算法在 Logon 消息中进行声明。 2.1.9 User definition field FIX 为给用户提供最大的灵活性，FIX 协议允许用户自定义域。这些域在认同的参与 者之间实现、应用，并且应注意避免冲突。 Tag 数在 5000 到 9999 保留用于用户自定义域。这些 tag 值用于企业联盟的信息交换。 可以通过 FIX 网站进行注册。 10000 以上保留用于单一企业内部使用。不用注册。 2.2 会话层协议 2.2.1 Logon 登陆 建立一个 FIX 连接，分别包含 3 个操作： 创建通信层链路 接收者认证/接受发起者 消息同步（初始化） 。 连接流程如下： 会话发起者同会话接收者建立通信链路，即 TCP 连接。 发起者发送一个 Logon 消息。接收者检查 Logon 消息，认证发起者身份。Logon 消息 包含支持之前双方协商好的认证方法所必须的数据。如果发起者被成功认证，接收者用一 个 Logon 消息进行响应。如果认证失败，会话接收者将关闭链接，之前可以选择发送一个 Logout 消息以提示认证失败的原因。这个 Logout 消息不是必须发送的。 在发起者认证通过之后，接收者立即响应一个 Logon 确认消息。依据会话使用的加密 方法，这个 Logon 消息可以，也可以不报还同样的会话密钥。发起者方将把接收方返回的 Logon 确认消息视为一个 FIX 会话建立的标志。如果会话接收方选择单边会话加密密钥， 会话的发起方必须发送一个 Logon 消息到对方以确认密钥改变请求。这样，能让会话接收 者知道发起者何时开始使用新的会话密钥。发起方和接收方必须在发送任何查询或新消息 之前通过询问 MsgSeqNum 域来同步其消息。发起方能通过比较确认 Logon 消息的 MsgSeqNum 及下一个期望值来侦测消息的间隙。 2.2.2 Messsage exchange 消息交换 初始化过程完成之后，将会进行正常的数据信息交换。主要包括管理消息和应用消息 的传送。 2.2.3 Logout 注销 正常的消息交换的终止将通过交换 Logout 消息来完成。一般设计上会发送一个 TestRequest 消息强制请求从对方获取 Heartbeat。这样可以帮助判断没有序列间隙 。 在实际的会话关闭前，Logout 的发起者应等待对方响应一个 Logout 确认消息。这种方 式给接收者在需要时一个执行任何间隙填充错作的机会。一旦 ResendRequest 消息被接收， 接收者应发起 Logout 操作，并且接收者在适当的时间表内没有响应，会话可以终止。 2.2.4 重传请求消息 下面四项待补充： 重传请求消息 测试请求消息 重传请求消息 Reject 消息 2.3 应用层协议（待补充） 最重要的：委托，查询，撤单，执行回报 3 国内现有应用方案 金证：/soft_market/ 将 Fix 协议的请求通过 C/C+或 XML 方式转化成业务系统对应协议，同时转发回 处理结果回报。使得在业务系统与 FIX 接入方系统之间通过 FIX 协议进行互通连 接。 国信：GsApi FPL 成员 根网科技：/en1/child.php?id=46 恒生：/fundsjjhy/555.htm 深圳证券通信公司：/main/index.shtml Bloomberg、恒生、金证、根网、上期技术 4 如何开发 FIX 程序 4.4.1 开发需求 短期需求： 实现 FIX4.2 协议的客户端接入。 快速准确的协议解释及翻译。 与恒生柜台高速有效地通讯。 实现路由功能，作为客户端和服务端的适配器，实现星型连接。 实现基本的股票交易查询等功能点。 强大的监控功能。 具备安全性保障。 4.4.2 开发方法 一般情况下，FIX 开发中涉及到两方面，一个是会话层和应用层。应用层即业务逻辑 相关的层面，在把握好业务逻辑后，相对固定简单。然而对于会话层的实现，涉及太多的 方面，因此推荐采用现有的 FIX 引擎来开发。 /products/1 列出了全球很多公司的 183 种不同 FIX engines，当 然，还包括一些没有登记上去的 FIX engine。国内现有的开发主要采用开源并且跨语种的 QuickFIX 引擎。 QuickFIX 可以灵活的运用在 C+、C#、Java、Python、Ruby 等编程语言之