IMIX协议分析

IMIX协议分析
1. IMIX Protocol简介
IMIX协议全称银行间市场信息交换协议（Inter-bank Market Information eXchange Protocol），用于银行间本币市场和外汇市场的金融信息的传输。

IMIX协议基于FIX协议制定。

FIX协议全称金融信息交换协议（Financial Information Exchange Protocol），是被国际金融界广泛使用的行业标准。

FIX协议基于Tag/Value格式制定，提供覆盖交易前、中、后的全面的业务层消息和易用、强壮的Session层消息。

IMIX消息继承了FIX消息的易用性，并根据国内金融市场的特点进行针对化的定制，对FIX协议进行扩充、优化，形成了适用于国内金融市场的独特的协议。

同FIX协议一样，IMIX协议提供了覆盖国内银行间市场的交易前、中、后的业务层消息和强壮的Session层消息，为银行间市场金融数据的交互提供了便捷的通道。

2. Milestone
2004年9月：项目调研
2004年10月-12月：立项
2005年1月至2005年12月：翻译FIX4.4，形成《银行间市场业务数据交换协议》初稿
2006年1月至2006年12月：完善修改《银行间市场业务数据交换协议》初稿
2007年1月至2007年12月：根据银行间市场特点，进一步完善修改《银行间市场业务数据交换协议》基础上形成意见征求稿，并报金标委。

2008年12月，完成外汇CSTP内容协议定义
2008年12月，完成外汇CMDS内容协议定义
2009年5月，完成CDC接口系统协议定义
2009年1月，完成外汇清算会员和保证金结算行系统协议定义
2009年5月，完成本币基准和本币Shibor系统协议定义
2009年6月，完成本币CSTP和本币CMDS系统协议定义
2009年7月，完成本币交易系统协议定义
2010年10月，完成外汇清算所协议定义
2010年11月，本币清算所协议制定中
2011年，将继续扩大协议的应用范围，如增值服务等
3. IMIX应用业务领域
IMIX协议依据中国银行间本币和外汇市场的业务需求编制，目前覆盖了中国银行间本
币和外汇市场的报价、交易、清算等领域。

3.1中国银行间市场概述
银行间市场是银行同业进行资金拆借、债券买卖、外汇交易的场所，不同于交易所市场，银行间市场以场外交易的方式存在，以询价方式为主，询价交易方式是银行间市场与场内市场的最大区别。

按照交易内容的不同，银行间市场可以分成人民币信用拆借市场、银行间债券市场、人民币利率衍生品市场和银行间外汇市场，前三个市场由于采用人民币计价，又合称为银行间本币市场。

银行间本币市场和外汇市场的基础框架都是由中国人民银行的附属机构中国外汇交易中心暨银行间同业拆借中心（简称CFETS）负责运行维护。

CFETS于1994年初成立于上海，是为了适应1994年开始的外汇管理体制改革设立的。

3.2银行间外汇市场
1993年底，国务院决定改革当时的外汇管理体制，实现人民币经常项目下有条件可兑换。

从1994年1月1日起，实现汇率并轨和结售汇制度，建立银行间外汇市场和和采用单一的、有管理的浮动忽略制。

在此背景下，中国外汇交易中心于同年初建立于上海。

根据中国人民银行赋予的职责，交易中心负责提供外汇交易系统和交易后的本、外币资金清算服务。

随着外汇体制改革的不断深入和我国外贸交易量的指数化增长，银行间外汇市场迅速发展壮大，交易品种也不断丰富多彩。

目前，银行间外汇市场提供的业务范围已经从人民币外汇即期交易扩展到人民币外汇远期、掉期、外汇拆借和外币对买卖。

交易的币种除人民币外，还覆盖包括美元(USD)、港币(HKD)、欧元(EUR)、日元(JPY)、英镑(GBP)、加元（CAD）、瑞士法郎(CHF)、新加坡元(SGD)在内的全球主要币种及与中国贸易密切的国家的币种。

CFETS负责银行间外汇市场的交易组织和系统维护，除提供交易服务以外，还提供人民币即期交易的清算服务和增值服务。

IMIX协议现在主要覆盖银行间外汇市场的清算和增值服务业务，用于收盘后CFETS和清算所之间传输交易数据和清算数据，也用于交易期间向会员发送增值数据。

3.3银行间本币市场
银行间本币市场由信用拆借市场、债券市场和人民币利率衍生品市场组成。

信用拆借市场是银行同业进行信用拆借的场所，提供1天（隔夜拆借）、7天、14天、1月、3月等多种期限的拆借品种的标准化合约。

债券市场是已发行债券的二级交易市场，交易的债券类型包括国债、央行票据、金融债、次级债、公司债、国际开发机构债券、短期融资券、资产支持证券，针对各种类型的债券，银行间市场提供包括现券买卖、资产支持证券买卖、债券借贷、债券远期、质押式回购、买断式回购在内的多种交易方式。

人民币利率衍生品市场是银行间
新成立的市场，交易的品种包括远期利率协议和利率互换。

利率衍生品市场是我国构建多层次金融市场不可或缺的组成部分，是优化我国利率形成机制的重要手段。

金融机构通过银行间本币市场提供的多种多样的交易工具，管理本机构的资金头寸，调整资产负债结构和进行投资理财。

银行间本币市场提供询价和做市两种交易方式，提供意向报价、双向报价、对话报价、点击成交报价、做市报价、限价报价等多种报价方式，满足不同投资需求。

银行间本币市场经过十多年的发展，已经成为我国场外交易市场的主体，参与交易的会员覆盖商业银行、证券公司、保险公司、信托公司、基金、企业年金等各类金融机构。

IMIX协议目前覆盖了银行间本币市场报价、交易、STP服务、清算等几乎交易流程的各个领域，涵盖所有本币市场的交易品种和交易方式，为银行间本币市场提供流畅的数据交互通道。

4. IMIX Protocol结构分析
4.1消息结构
IMIX消息的标准结构图如下：（详见《银行间市场业务数据交换协议》）
图 1 IMIX消息结构
说法是大方
4.1.1 消息头
每个会话消息或应用消息都有一个消息头，该消息头指明消息类型、消息体长度、发送目的地、消息序号、发送起始点和发送时间。

消息头格式见下表
表1标准消息头
例如：银行A的交易员小王发送消息给银行B的交易员小张，则小王发出去的消息标准头部应该如下表所示：
表2标准消息头例子而小张给小王发的消息标准头部则应该如下表所示
表3标准消息头例子
4.1.2 消息尾
每一个会话消息或应用消息都有一个消息尾，并以此终止。

消息尾可用于分隔多个消息，包含有3位数的校验和值。

消息尾格式见下表4
表4标准消息尾
4.1.3 消息体
主要描述应用层面的业务信息（具体的消息类型见《银行间市场业务数据交换协议》），应用消息中有很多共用的数据域集合——组件。

比如说，大多数应用消息都会用到一系列定义债券品种的域：Symbol，SecurityID，SecurityIDSource，……为避免重复，协议中定义了一些关键组件，在应用消息定义中直接用名称引用这些组件。

实际的消息定义和使用中，则应该将组件扩展开成为相应的数据域集合。

4.1.4 组件
在IMIX协议中，组件是一个逻辑概念，它用来表示一组彼此之间有一定关系的消息域的组合。

这些组件在IMIX协议中都赋以相应的名称，用来更好的理解消息结构以及所应用的场景。

在实际消息传送过程中，这些组件名称并不会作为信息消息中出现，可以这么说，组件的出现是起到更好让人能够理解IMIX消息结构的作用。

4.1.5 重复组
域可以在重复组里多次重复，用以传输数组同类的数据。

在IMIX协议中，重复组也同样是一个逻辑概念，它用来表示一组彼此之间有一定关系的消息域的组合能够连续反复地在消息中出现。

在实际消息传送过程中，这些重复组件名称也不会作为信息消息中出现。

通常域名起始为’No’字符的域指明重复的次数，并位于重复组的开始处。

本文档中重复组的定义通过缩进的符号表示，重复组也可嵌套。

使用子重复组时不能省略父重复组。

重复组内的第一个域是必需的。

在协议执行时把第一个域用作“分隔符”，表明新的重复组的开始。

如果第XXX号（NoXXX）域大于0，那么第XXX号后所列的第一个域就变成有条件的必需的域。

指明重复组号的第XXX号（NoXXX）域(如：交易会话号（NoTradingSessions）, 分配号（NoAllocs）)在重复组内只出现一次，必需直接位于重复组的内容之前。

如果重复组内有一个域是必需的，那么第XXX号（NoXXX）域就应当是必需的。

如果重复组内的所有参与方都是可选择性的，那么第XXX号域也应当是可选择性的。

如果重复组的某一个域是必需的，那么在重复组内每次重复时该域都应出现。

通过缩进的符号“→”对消息定义内的重复组进行指定。

重复组可嵌入其他重复组(可不止一层嵌套)。

通过缩进的符号“→”后跟缩进的符号“→”的方式对嵌套的重复组进行指定。

有嵌套重复组时，必需对外层的重复组进行指定。

例如定义一重复组：
表5重复组
则该重复组实际使用例子如下
表 6
在传送过程中，该重复组在消息中如下所示：
454=3<SOH>455=债券1<SOH>456=财政部发行<SOH>455=债券2<SOH>456=企业发行<SOH>455=债券3<SOH>456=央行发行<SOH>
5. IMIX Protocol会话机制
为了保证IMIX会话能够能够正常的开始和终止，保证IMIX消息在传送过程不会发生的消息丢失引起的消息序列缺口问题，以及其他一系列与IMIX消息传送相关的问题，IMIX 定义了一套会话机制，该会话机制通过定义特殊的消息域以及会话消息实现了会话登录，会话注销，消息缺口填补，消息重复发送等传送场景的处理过程，这些都是IMIX协议为了保证消息正确传送提供的一种解决方案。

如果具体的IMIX协议的实现者能够通过其他的技术或者机制保证消息的正确传送，就不用实现IMIX会话机制。

5.1消息序号
任何一条消息都被分配一个唯一的消息序号来加以标识，消息序号在每次会话过程中从
1 开始，在整个会话过程中连续递增，直到该会话过程全部结束。

通过监视消息序号的连续性可识别交换中的消息缺口，并做出反应，使得连接双方数据同步。

连接双方都明确确定相互独立的消息序号，参与连接的任何一方负责维护自己发送的消息序号，并监视接收的消息序号以保证消息缺口能被发现并加以处理。

5.2心跳
在消息交换的空闲期间，连接双方将在规定的时间间隔内发出心跳消息。

通过心跳消息可以监控通讯连接的状态，识别接收信息的序号缺口。

心跳间隔时间由会话发起人在登录时，用登录中的心跳指令域（HeartBtInt）来加以确定。

每次传送信息完毕之后，应立即重新设置心跳间隔计时器。

心跳间隔时间应得到连接双方的确认，由登录会话发起方设定并得到登录接受方的确认回应。

连接双方使用相同的心跳间隔时间。

5.3缺口填补
本协议的消息传输模式是基于消息被完整传送的。

但消息在传输过程中可能存在丢失，而消息发送方无法检测是否丢失了消息，因此消息接收方应负责检测消息的缺口并加以处理。

有两种处理方法：（1）消息接收方发现缺口后向消息发送方请求发送缺口消息及其后的所有消息；（2）消息接收方发现缺口后，保存已收到消息，并向消息发送方请求重复发送缺口消息。

5.4消息重复发送
在响应一个重发请求而重复发送消息时，或者不确定对方是否收到已发消息而重复发送该消息时，消息发送方须在被重发消息内加上可能重复标志（Possible Duplicate=Y）。

如何处理该消息则由消息接收方处理。

注意：当生成有此类可能重复发送的消息时，由于某些信息可能会改变，如原始时间、发送时间、正文长度、可能重复标志等，所以应重新计算校验和。

5.5消息重新发送
消息重新发送，是基于应用层的可能重发消息。

如发送的订单在相当长的时间内没有得到确认，或者怀疑其根本未曾被发送过，消息发送方可通过设置可能重新发送标志来重新发送(Possible Resend=Y)。

消息接收方收到该类消息后，应通过查询消息内的域（如订单编号等）来确定此前是否收到过该消息。

注意：此类消息应确定包含相同的正文数据，同样，由于某些信息可能会改变，所以应重新计算校验和。

5.6消息确认
本协议的消息传输模式是基于消息被完整传送的；并且通过监测消息序号缺口以识别对正常传送过程中的错误。

协议不支持对单个消息收发的确认，但大量的应用消息须在应用层作出明确的收发确认，如订单的确认。

5.7会话连接
会话过程的数据交换可以这样描述：连接双方各有一组连续的消息序号随消息传送；交易期间可能多次断开并重新连接，其断开的原因可以是外因引起，也可以是连接双方根据系统而统一制定何时断开并重新连接。

建议一次会话连接不超过24 小时；如需要保持24 小时以上的连接，则可发送一条含有序号重设标志的登录消息来建立新的起始消息序号。

会话过程分为三个部分：登录、消息交换、注销。

5.7.1 登录
登录连接包含三个步骤：建立电信通讯连接、连接双方的确认/认证、消息传输同步的初始化。

主要有以下几点：
5.7.1.1 连接
会话的发起方与会话接收方建立电信通讯连接。

5.7.1.2 认证
会话发起方发送登录消息（Logon），会话接收方认证发起方身份的合法性。

登录消息应包括认证的必要数据，如用户名、密码等。

如果会话发起方身份通过认证，则会话接收方发送一个登录消息作回应。

如果认证失败，会话接收方则在发送一个包含失败说明的注销消息（Logout）后关闭连接。

发送注销消息不是必需的，因为其占用了一个消息序号，而且在某些情况下可能会引起其他问题。

登录成功后，会话发起方可在登录消息之后立即开始发送消息，但此时会话接收方可能并没有作好接收消息的准备；因此会话发起方应在收到接收方的登录消息确认之后，才认为会话连接建立完成。

建议：在登录后或者刚发送完测试请求消息（TestRequest）时延迟等待一段时间，双方再发送新的消息，使得连接双方能有效控制重发请求；否则可能会导致一方会针对对方的每一条新消息发出重发请求。

5.7.1.3 初始化
在身份通过认证之后，会话发起方和会话接收方应首先同步消息序号，然后才能相互发送新的信息。

同步消息序号通过消息序号域（MsgSeqNum）来确定，将登录消息里的消息序号（MsgSeqNum）与内部监控的下一个预期的消息序号进行比较，就能发现消息的消息序号缺口。

同样，会话发起方通过将会话接收方发送的登录消息里的消息序号（MsgSeqNum）与下一个预期的消息序号进行比较，也能发现消息的缺口。

5.7.2 消息交换
在以上初始化完成之后，可以开始进行信息交换。

所有有效消息的格式将在“会话消息”和“应用消息”部分中详细叙述。

5.7.3 注销
会话的正常结束是通过连接双方互相发送注销消息（Logout）完成的。

若结束时没有收到回送的注销消息（Logout），则把对方视作已注销。

除此之外的其它方式的会话结束视为非正常，并应按错误来处理。

在发送注销消息（Logout）之前，应发送测试请求消息（TestRequest）以要求对方的心跳信息，这有助于保证不出现消息序号缺口。

在结束会话之前，注销消息（Logout）的发起方应该等待对方回送的注销消息（Logout），这样给注销消息的接收方一个填补缺口的机会。

待重发请求的信息全部收到后，注销消息的接收方才可发送应答的注销消息（Logout）。

如果注销消息的接收方在一定时间内没有答复，那么会话就可以立即中断。

注意：注销不影响任何订单的状况。

所有有效的订单都可在注销（Logout）之后执行。

5.8消息恢复
以下描述了有关恢复消息的具体方法。

当接收进来的消息序号与预期的消息序号不相符合时，需进行修正处理。

但需要注意的是，如果接收进来的是序号重设消息（SeqReset-Reset），则不需要进行修正处理。

因为此类消息的消息序号对随后的消息处理没有任何影响。

如果接收的消息的消息序号比预期的消息序号小，而且没有设置可能重复标志（PossDupFlag），那么表明发生了严重的错误。

因此建议强制结束会话，并开始进行人工干预。

如果接收进来的消息序号比预期的大，那么表明有消息被遗漏，应通过发送重发请求申请填补缺口。

注意：以下段落中的请求人指的是提出重发请求的一方，重发人指的是回应重发请求的一方。

当收到重发请求时，重发人可任选以下之一作出回应：
➢作为正常回应，重发人按顺序发送被请求的消息，这些消息的消息序号仍为原消息序号，并且将可能重复的标志（PossDupFlag）置位为“Y”。

➢作为正常回应，重发人发送序号重设-缺口填补（SeqReset-GapFill）消息，可能重复标志（PossDupFlag）置位为“Y”，以表示删除过时或多余的消息。

➢作为非正常回应，重发人发送序号重设-重设（SeqReset-Reset）消息，可能重复的标志（PossDupFlag）置位为“Y”，以强制消息序号同步。

在缺口填补过程中，某些会话管理消息不应被重新发送；取而代之的是一种特殊的序号重设-缺口填补消息（SeqReset-GapFill）。

不应被重新发送的会话管理消息包括：登录、注销、重发请求、心跳、测试请求、序号重设-重设消息（SeqReset-Reset ）和序号重设-缺口填补消息（SeqReset-GapFill）。

由此，会话拒绝消息便成为了唯一可能被重新发送的
会话消息。

会话过程中应监视接收到的消息，以便发现由于疏漏而被对方重新发送了的会话消息
（设置了可能重复标志（PossDupFlag）的）。

当收到这些消息以后，只须确认它们占有一个消息序号空间即可，可以忽略消息中包含的对业务或应用的处理信息。

如果碰到多个连续的无需重发的会话消息，建议只发送一个序号重设- 缺口填补消息（SeqReset-GapFill）。

该序号重设-缺口填补消息的消息序号是下一个预期的消息序号。

序号重设-缺口填补消息（SeqReset-GapFill）的新消息序号（NewSeqNo）为本连续会话消息段中最大消息序号+1。

例如，在重新发送操作期间，有7 条连续的会话消息等待发送，他们以消息序号9 开始和以消息序号15 结束，此时只发送一个序号重设-缺口填补消息（SeqReset-GapFill）来代替那7 条消息，那么该序号重设-缺口填补消息
（SeqReset-GapFill）的消息序号是9，这是因为要承接上条消息而保持消息序号的连续性；其中新消息序号（NewSeqNo）是16，这样使得对方知道下一消息发送时的消息序号。

建议：在缺口被填补完成之后，交换引擎应将无序的消息暂时保存为有序的排列并按顺序对它们进行处理，以防止出现对n->m,n->m+1,n->m+2,.的重发请求，否则会导致大量的可能重复（PossDupFlag=‘Y’）标记。

检验消息序号是否连续在会话过程管理中是必不可少的部分。

不过，针对消息类型的不同，处理消息序号流的差异也有不同的处理。

下列的表１列出了当接受到的消息序号大于预期消息序号时而应采取的措施。

注意：在任何情况下，除了序号重设－重设消息外，如果进来的消息序号比预期的消息序号小，而且可能重复标志（PossDupFlag）没有被设置，那么应立即终止会话过程。

并应在结束会话之前，向对方发送带有解释正文的注销（Logout）消息。

表 1
6. IMIX Protocol关键域\组件说明
6.1消息类型
MsgType用于定义传输的消息类型，域号为35。

IMIX协议为不同的业务场景定义不同的IMIX消息类型，例如：< 35=6>表示传输的消息为意向报价，< 35=8>表示传输的为成交信息。

取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件
6.2市场标识符
<MarketIndicator>用于区分不同的业务市场的市场标识，域号为10176。

在不同的市场下，同一种类型的IMIX消息往往在应用上有不同，需要根据不同的市场标识符，根据具体的业务逻辑对消息进行解释，例如：<10176=1>表示该消息为信用拆借市场的，则收到一条MsgType=6的消息，则为信用拆借市场的意向报价消息，就需要根据该市场意向报价的业务逻辑对IMIX消息传递的信息进行处理。

取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件
6.3报价类型
在业务报价场景中，QuoteType用于表示不同的报价类型，域号为537。

例如：<537=102>表示该报价为限价报价。

取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件
6.4交易方式（询价，竞价，点击）
TradeMethod用于区分不同交易方式，域号为10317。

例如：<10317=1>表示该笔交易为询价方式的。

取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件
6.5做市与非做市交易
TradeType用于定义交易类型，区分做市交易和非做市交易。

取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件
6.6交易品种与基础品种
在本币市场中，按照交易方式的划分，可以分为现货交易，远期交易，回购交易，期货交易，
期权交易和互换交易。

如果按照基础交易品种划分，可以分为债券，抵押，指数和借贷等。

对于债券，又可以有公司企业债券，国债等。

对于抵押，可以有资产支持证券，抵押支持债券等。

对于指数，可以有ETFs, 利率等。

对于借贷，可以有信用拆借等。

IMIX协议通过对<Instrument>组件以及< UnderlyingInstrument >组件的定义在交易方式和基础交易品种这两个维度上对本币市场的金融产品进行描述。

例如：在现券市场中，产品名称即债券名称
表7
在债券借贷市场中如下，交易品种名称为SL03M，表示2个月零1天–3个月的债券借贷，而借贷的标的债券名称和代码需要在<UnderlyingInstrument>中填写。

表8
6.7交易成员信息
<Parties>和<PtysSubGrp>用于描述交易成员信息，例如：现券市场中的成员信息如下：
表9
其中448 PartyID传输机构ID，具体的机构信息、帐户信息、交易员信息等通过< PtysSubGrp>传输，根据803 PartySubIDType取值的不同，对应的523 PartySubID表示不同的业务含义，如：
当803=101，对应的523中填交易员姓名；
当803=124，对应的523中填机构中文全称；
当803=125，对应的523中填机构中文简称；
当803=118，对应的523域中填资金中文帐户户名；
当803=23，对应的523域中填资金英文帐户户名；
当803=110，对应的523域中填资金开户行名称；
当803=15，对应的523中填资金账号；
当803=112，对应的523中填资金开户行联行行号；
当803=22，对应的523中填资金托管帐户户名；
当803=111，对应的523中填托管机构名称；
当803=10，对应的523中填托管账号；
等；
以此类推，具体的取值详见相关文档中的《IMIX-成员端数据下载-Dictionary.XSL》文件
对于机构信息和机构交易员信息，本指引中的IMIX示例仅在448 PartyID中存放机构ID，
在803=101时，523存放交易员姓名，其他的信息如机构全称、简称等信息，接收方可以根据需要在收到的消息中通过选择803的不同取值获取，指引中的IMIX示例不在一一列举。

6.8本方报价与关联机构方报价
<标准消息头>，<Parties>可用于区别本方报价与关联机构报价。

关联机构报价成交数
据所包含的交易相关信息与本方机构报价成交数据所包含的信息基本相同，可以参考本方报价成交数据部分的说明。

对于下载终端而言，接收到关联机构报价成交数据的IMIX消息，其中Parties中包含的机构信息是关联机构的信息。

如下面例子所示，假设机构A（会员代码A000000000000000001）在信用拆借市场作为拆入方发送一笔对话报价给机构B（B000000000000000001），而机构A是机构C （C000000000000000001）的关联机构。

对于本币下载服务而言，该报价的发起方是机构A，报价对手方是机构B，则下载服务会发送该则该笔报价作为机构A的本方报价发送给A，而同样会把该条报价作为关联机构报价发送给机构C。

机构A收到的消息例子片段如下，从下面的例子可以看出，下载服务代码和机构A标识代码出现在消息头中，作为消息接收双方。

而机构A和机构B信息作为报价双方信息出现在Parties组件中，由PartyRole可知机构A在报价中是作为报价发起方，而机构B作为对手方。

由于该条报价是下载服务发送给机构A的，所以下载服务在交易方向域Side的取值是以机构A的角度设置的，设定为拆入方向。