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消息的标准结构图如下：（详见《银行间市场业务数据交换协议》）

域8Header标准消息头域 9域35域块域块IMIX MessageIMIX消息Body消息体Compoent组件域块域域：表示某个域Repeating Group重复组Group Block 1组块 1域块域域块重复组组块：表示多个域集合：表示重复组，可由多个重复组块组成：表示重复组中每块重复部分，也是由域块组成：表示多个域的集合，这些域所代表的含义之间具有关联性域块Trailer标准消息尾域10Group Block 2组块 2域块域组件Group Block n组块 n域块

图 1 IMIX消息结构

说法是大方

4.1.1 消息头

每个会话消息或应用消息都有一个消息头，该消息头指明消息类型、消息体长度、发送目的地、消息序号、发送起始点和发送时间。

消息头格式见下表 域号 8 9 35 49 50 56 57 115 116 域名 BeginString BodyLength MsgType SenderCompID SenderSubID TargetCompID TargetSubID OnBehalfOfCompID OnBehalfOfSubID 必需 必需 必需 必需 必需 说明 起始串定义消息的协议版本（不可加密，消息的第一个域） 消息体长度（不可加密，消息的第二个域） 消息类型（不可加密，消息的第三个域） 发送方代码（不可加密，发送方标识符） 发送方子标识符（可加密） 接收方代码（不可加密，接收方标识符） 接收方子标识符（可加密） 最初发送方标识符（可加密），用于经第三方中转发送。 最初发送方子标识符（可加密）, 用于经第三方中转发送。 128 129 DeliverToCompID DeliverToSubID 最终接收方标识符（可加密），用于经第三方中转发送。 最终接收方子标识符（可加密）, 用于经第三方中转发送。 34 43 MsgSeqNum PossDupFlag 必需 消息序列号（可加密） 消息可能重复标志，当一条消息以相同的序列号重传时（两条消息完全一样），作此标记，多 必需

数由于传输层异常重发时所标记。（可加密） 97 PossResend 消息可能重传标志，当一条消息以不同的序列号重传时所加标志位，多数由于上层处理逻辑异常而重传时所带标记。（可加密） 发送时间（可加密） 原始发送时间（可加密） 52 122 347 SendingTime OrigSendingTime MessageEncoding 必需 消息中Encoded域的字符编码类型（非ASCII码） 369 LastMsgSeqNumProcessed 最后处理消息序号（可加密） 370 10287 10052 10308 10333 HopsGrp OnBehalfOfSendingTime SegmentID ErrorCode SysSeqNo UserSeqNo

最初发送时间 产品编号，新一代本币系统必需域。 错误代码，新一代本币系统必需域。 全局消息序号，新一代本币系统必需域。 用户特定消息序号，新一代本币系统必需域。 表 1标准消息头

例如：银行A的交易员小王发送消息给银行B的交易员小张，则小王发出去的消息标

准头部应该如下表所示：

域号 8 9 35 49 域名 BeginString BodyLength MsgType 值 IMIX.1.0 计算得到 说明 起始串IMIX1.0（不可加密，消息的第一个域） 消息体长度（不可加密，消息的第二个域） 8 Execution Report消息 小王所在机构的标识 SenderCompID 银行A 56 128 TargetCompID DeliverToCompID CFETS 银行B 通过交易中心中转 小张所在机构的标识。 50 129 SenderSubID DeliverToSubID 小王 小张 小王在所在机构的标识 小张在所在机构的标识 34 52 SeqNo SendingTime xxx 时间 消息序列号 发送时间（可加密）

表 2标准消息头例子

而小张给小王发的消息标准头部则应该如下表所示 域号 8 9 35 49 56 128 域名 BeginString BodyLength MsgType 值 IMIX.1.0 计算得到 说明 起始串IMIX1.0（不可加密，消息的第一个域） 消息体长度（不可加密，消息的第二个域） D NewOrderSingle消息哦 小张所在机构的标识 通过交易中心中转 小王所在机构的标识 SenderCompID 银行B TargetCompID DeliverToCompID CFETS 银行A 50 129 SenderSubID DeliverToSubI小张 小王 小张在所在机构的标识 小王在所在机构的标识 D 34 52

表 3标准消息头例子

SeqNo SendingTime xxx 时间 消息序列号 发送时间 4.1.2 消息尾

每一个会话消息或应用消息都有一个消息尾，并以此终止。消息尾可用于分隔多个消息，包含有3位数的校验和值。

消息尾格式见下表4

域号 93 89 10

表 4标准消息尾

域名 必需 说明 数字签名长度（不可加密） 数字签名（不可加密） 校验和，消息的最末域。（不可加密） SignatureLength Signature CheckSum 必需 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号域也应当是可选择性的。

如果重复组的某一个域是必需的，那么在重复组内每次重复时该域都应出现。 通过缩进的符号“→”对消息定义内的重复组进行指定。 重复组可嵌入其他重复组(可不止一层嵌套)。通过缩进的符号“→”后跟缩进的符号“→”的方式对嵌套的重复组进行指定。

有嵌套重复组时，必需对外层的重复组进行指定。 例如定义一重复组： 454 → → NoSecurityAltID 455 456 SecurityAltID N N 备选债券代码个数 备选债券代码 备选债券代码源 SecurityAltIDSource N

表 5重复组

则该重复组实际使用例子如下 454 → → → → → → NoSecurityAltID 455 456 455 456 455 456 SecurityAltID SecurityAltIDSource SecurityAltID SecurityAltIDSource SecurityAltID SecurityAltIDSource 3 债券1 财政部发行 债券2 企业发行 债券3 央行发行 表 6

在传送过程中，该重复组在消息中如下所示：

454=3455=债券1456=财政部发行455=债券2456=企业发行455=债券3456=央行发行

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）消息。

消息类型 登录 针对消息序号错误所采取的措施 永远是连接双方发送的第一条消息，用于认证和确认连接。如果发现登录消息中有缺口，则应在回送登录确认消息之后立即发送重发请求 注销 如果发现有缺口，应发送重发请求消息以重新接收所有丢失的消息，然后再发送注销消息作为对注销请求的确认。注意严禁在有缺口情况下结束会话。并由注销的最初发起人负责结束会话，因此注销发起人有责任回应所有的重发请求 重发请求 首先处理完对方的重发请求，随后发送自己的重发请求以填补消息序号错误而发现的消息缺口。 序号重设-重设 可以忽略消息序号错误。因为在序号重设-重设（ SeqReset-Reset ） 消息中的新消息序号（NewSeqNo）强制为下一发送消息的消息序号。 序号重设-缺口填补 应立即向对方发送重发请求。但是，必需确保没有无意间跳过任何消息，这意味着缺口填补消息应按次序被接收到，如果次序不对，那么表示出现了非正常的情况 所有其它信息 执行正常的缺口填补。 表 1

6. IMIX Protocol关键域\\组件说明

6.1 消息类型

MsgType用于定义传输的消息类型，域号为35。IMIX协议为不同的业务场景定义不同的IMIX消息类型，例如：< 35=6>表示传输的消息为意向报价，< 35=8>表示传输的为成交信息。取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件

6.2 市场标识符

用于区分不同的业务市场的市场标识，域号为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协议通过对组件以及< UnderlyingInstrument >组件的定义在交易方式和基础交易品种这两个维度上对本币市场的金融产品进行描述。

例如：在现券市场中，产品名称即债券名称

Instrument 22 48 55 SecurityIDSource SecurityID Symbol 101 20070025 07国开13 表 7

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

Instrument 22 48 UnderlyingInstrument 309 311 241 SecurityIDSource SecurityID UnderlyingSecurityID UnderlyingSymbol UnderlyingCouponPaymentDate 102 SL03M 20070062 China001310% 2007-08-01 表 8

6.7 交易成员信息

和用于描述交易成员信息，例如：现券市场中的成员信息如下： Parties 453 NoPartyIDs 2 → → → → → → → → → → → → → → → → → → → → → → → → → → → → → → → → → 448 447 452 PtysSubGrp 802 → → → → → → → → → → → → → → → → → → → → 448 447 452 802 → → → → PartyID PartyIDSource PartyRole NoPartySubIDs BANK01 101 10 Bank of China 5 Bank of China 110 20008 112 Bank of China 23 955912345678901 15 Bank of China 113 Bank of China 114 622512345678901 115 Bank of China I18 Bank of China I19 BANK02 102 2 ICBC 102 TRADER02 2 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType PartyID PartyIDSource PartyRole NoPartySubIDs 523 PartySubID 803 PartySubIDType 523 PartySubID 803 PartySubIDType 表 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 本方报价与关联机构方报价

<标准消息头>，可用于区别本方报价与关联机构报价。关联机构报价成交数据所包含的交易相关信息与本方机构报价成交数据所包含的信息基本相同，可以参考本方报价成交数据部分的说明。对于下载终端而言，接收到关联机构报价成交数据的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的角度设置的，设定为拆入方向。

域号 35 49 56 域名 MsgType SenderCompID TargetCompID 取值 S CFETS-FI-CSTP A000000000000000001 机构A 57 48 54 537 10176 453 → → → → → → → → → → 448 452 802 → → 448 452 802 → → 523 803 523 803 TargetSubID SecurityID Side QuoteType MarketIndicator NoPartyIDs PartyID PartyRole NoPartySubIDs PartySubID PartySubIDType PartyID PartyRole NoPartySubIDs PartySubID PartySubIDType XXXXXXX IBO1M 1 1 1 2 101 1 张三 101 102 1 李四 101 机构A拆入资金 对话报价 信用拆借 交易双方 机构A作为发起方 发起方其他相关信息数目 发起方交易员名称 机构B作为对手方 对手方相关信息数目 对手方交易员名称 A000000000000000001 机构A代码 B000000000000000001 机构B代码 表 10

机构C收到的消息例子片段如下，从下面的例子可以看出，下载服务代码和机构C标识代码出现在消息头中，作为消息接收双方。而机构A和机构B信息作为报价双方信息出现在Parties组件中，由PartyRole可知机构A在报价中是作为报价发起方，而机构B作为对手方。由于该条报价是下载服务作为关联机构报价发送给机构C的，所以下载服务在交易方向域Side的取值还是以关联机构A的角度设置的，设定为拆入方向。 域号 35 49 56 48 54 537 10176 453 → → → → → → 448 452 802 → → 448 523 803 域名 MsgType SenderCompID TargetCompID SecurityID Side QuoteType MarketIndicator NoPartyIDs PartyID PartyRole NoPartySubIDs PartySubID PartySubIDType PartyID 取值 S CFETS-FI-CSTP IBO1M 1 1 1 2 101 1 张三 101 拆入 对话报价报价 信用拆借 交易双方 机构A作为发起方 发起方其他相关信息数目 发起方交易员名称 C000000000000000001 A000000000000000001 机构A代码 B000000000000000001 机构B代码 → → → → 452 802 → → 523 803 PartyRole NoPartySubIDs PartySubID PartySubIDType 102 1 李四 101 机构B作为对手方 对手方相关信息数目 对手方交易员名称 表 11 如果下载服务将该条报价发送给机构B，机构B可以从该条报价中消息得知其作为报价对手方。消息例子片段如下：

域号 35 49 56 48 54 537 10176 453 → → → → → → → → → → 448 452 802 → → 448 452 802 → → 523 803 523 803 域名 MsgType SenderCompID TargetCompID SecurityID Side QuoteType MarketIndicator NoPartyIDs PartyID PartyRole NoPartySubIDs PartySubID PartySubIDType PartyID PartyRole NoPartySubIDs PartySubID PartySubIDType 取值 S CFETS-FI-CSTP IBO1M 1 1 1 2 101 1 张三 101 拆入 对话报价报价 信用拆借 交易双方 机构A作为发起方 发起方其他相关信息数目 发起方交易员名称 机构B作为对手方 对手方相关信息数目 对手方交易员名称 B000000000000000001 A000000000000000001 机构A代码 B000000000000000001 机构B代码 102 1 李四 101 表 12

6.9 双向报价与利率互换产品报价

由于双向报价与利率互换产品在报价信息上都存在两个交易方向上都有报价信息，所以IMIX协议定了以Leg开头的相关组件用于描述双向报价信息，或利率互换产品中的固定-

浮动报价明细以及浮动-浮动报价明细。

例如：组件用于双向报价场景中，或者利率互换的意向报价中。 信用拆借市场的双向意向报价消息结构片段如下，其中域< NoLegs>=2可表示该报价为双向的报价，具体的报价信息在Leg重复组中传输。

域号 537 48 555 域名 QuoteType SecurityID NoLegs 取值 101 IBO2M 2 双向报价 两个重复组表示双向报价信息 → → → → → 见附录 682 566 686 见附录 见附录 LegSide LegIOIQty LegPrice LegPriceType LegSettlCurrAmt2 LegAccruedInterestTotalAmt LegSide LegIOIQty LegPrice LegPriceType 1 1208000000 4.53 1 1214747000 6747000 4 1208000000 4.53 1 → → → → → 见附录 682 566 686 表 13

再例如：利率互换市场的固定-浮动意向报价结构如下： 域号 域名 取值 固定-浮动报价 意向报价 54 537 48 Side QuoteType SecurityID J 0 FR007/Shibor3M_1Y 555 → → 624 566 NoLegs LegSide LegPrice 2 1 0.1 固定-浮动交易信息 固定支付端 → → → → 686 624 686 677 LegPriceType LegSide LegPriceType LegBenchmarkCurveName 3 B 6 LIBOR6M 浮动支付端（基准利率端） 浮动利率 参考利率 表 14

再例如：利率互换市场的浮动-浮动意向报价结构如下： 域号 域名 取值 浮动-浮动报价 意向报价 54 537 48 Side QuoteType SecurityID K 0 FR007/Shibor3M_1Y 555 NoLegs 3 浮动-浮动交易信息 参考利率1双向报价和参考利率2信息 → → → 624 686 677 LegSide LegPriceType LegBenchmarkCurveName 1 6 LIBOR3M 参考利率1支付端 浮动利率 参考利率1 → → 624 686 LegSide LegPriceType 4 6 参考利率1收取端 浮动利率 → 677 LegBenchmarkCurveName LIBOR3M 参考利率1 → → → 624 686 677 LegSide LegPriceType LegBenchmarkCurveName B 6 LIBOR6M 参考利率2（基准端） 浮动利率 参考利率2 表 15 其中Leg重复组可用于表示浮动端或者固定端的明细，具体的取值详见相关文档中的

《IMIX-成员端数据下载-Dictionary.XSL》

6.10 发送范围

IMIX协议中使用RoutingGrp和GroupGrp表示发送范围的详细信息.

215 (NoRoutingIDs)表示发送范围的数目

216 (RoutingType)表示发送范围类型，取值如下 1-目标对手方（一般对话报价都只有一个） 2-目标对手方列表（多个） 5-所有市场参与者

217 (RoutingID)为发送目标的标识代码。 例如：

发送范围包括一个指定对手方和两组指定对手方，则用RoutingGrp按照如下表示。 NoRoutingIDS=3，表示三个重复组件来表示这三种发送范围，其中一种范围是RoutingType=1，RoutingID=100000311000000101001代码，表示指定一个对手方代码，此时在Parties组件里面会有相关对手方信息，包括交易员信息等。

另外两种范围分别是RoutingType=2，RoutingID=GroupID1和RroutingType=2，RoutingID=GroupID2

使用GroupGrp组件表示对手方列表信息。

例子1：发送范围确定为另一家结构，则消息片段为 域号 54 域名 Side 取值 1 215 → → 216 217 448 452 802 → → → → 523 803 523 803 NoRoutingIDs RoutingType RoutingID NoPartyIDs PartyID PartyRole NoPartySubIDs PartySubID PartySubIDType PartySubID PartySubIDType PartyID PartyRole 1 1 B0000000000000000001 2 B0000000000000000001 102 2 张三 两个报价相关方 对手方 453 → → → → → → → → → 发起方 101 B0000000000000000001 130 A0000000000000000001 101 448 452 表 16

RoutingID和PartyID相同，表明机构A发送给机构B，这个场景可以不用使用RoutingGrp 例子2：发送范围确定为所有参与者，则消息片段为

域号 54 215 → 216 域名 Side NoRoutingIDs RoutingType NoPartyIDs 取值 1 1 5 1 发送全市场 由于是发送给全市场的，所以只需要填入发起方信息。 453 → 448 PartyID B0000000000000000001 → → → → → 452 802 → → → 523 803 523 PartyRole NoPartySubIDs PartySubID PartySubIDType PartySubID 102 2 张三 101 30000033000000101003 → → 803 PartySubIDType 130 表 17 例子2：发送范围确定为多个对手方列表，则消息片段为 域号 54 215 → → → → 216 217 216 217 523 域名 Side NoRoutingIDs RoutingType RoutingID RoutingType RoutingID NoGroupsIDs GroupID GroupRole NoPartyIDs PartyID PartySubID 取值 1 2 2 LIST1 2 LIST2 2 LIST1 102 2 机构1 张三 两个列表 发送给列表LIST1 发送给列表LIST2 两个列表信息 10205 → → → → → 10059 10060 → →

→ → → → → → →

→ → 803 PartySubIDType 101 PartyID GroupID GroupRole NoPartyIDs PartyID PartyID 机构2 LIST2 102 2 机构3 机构4 10059 10060 → → 表 18

6.11 标准品种与非标准品种

标准产品是由交易中心场务定义的、用于双向报价的交易品种。标准产品的期限是固定的，如7天、14天。 （例外——在利率互换和远期利率协议市场中，可以用于所有的报价，有些属性是由场务定义的。）

非标准品种（交易品种）是为了市场统计的方便按照期限长度进行命名的品种。 所有市场的双向报价都是标准品种，在IRS和FRA市场中，所有的报价方式都可以是标准品种，当然在这两个市场中的非双向报价方式的报价品种也可以是非标准品种。其他市场的非双向报价只能是非标准品种。 IMIX协议中用域48 SecurityID表示品种代码，用域 55 Symbol表示品种名称.在业务现实中，标准品种是有品种代码的，非标准品种没有品种代码，由于48 SecurityID是消息的必须域，对于标准和非标准品种的情况下，该域在消息中都必须出现，因此，协议中规定在报价品种为标准品种时48 SecurityID填标准品种的代码，在报价品种为非标准品种的时候，48 SecurityID中填字符串“User-Defined”.示例如下： （1）报价品种为标准品种 48 55 SecurityID Symbol XXXXXX XXXXXX 品种代码 品种名称

（2）报价品种为非标准品种 48 55 SecurityID Symbol User-Defined XXXXXX 品种代码 品种名称

由于在非标准品种的情况下，48 SecurityID中填字符串“User-Defined”，不能标识品种信息，协议中用域55 Symbol填写非标准品种的名称，通过该域标识非标准品种的信息。

因此在本指引中非标准品种的示例中，都带有55 Symbol域（不管业务表中是否有该域）；在标准品种的情况下，55 Symbol在示例中也存在，不过使用者可以根据需要是否使用该域，因为在标准品种的情况下，48 SecurityID已经可以标识标准品种的信息。

本指引中所有的双向报价的IMIX示例都是做标准品种的示例，因为双向报价都只能使用标准品种。指引中IRS和FRA市场的所有报价也都是做标准品种的示例，因为IRS和FRA市场所有的报价品种都可以是标准品种，当然除双向报价外，也可以是非标准品种的，示例只做标准品种的情况。指引中其他市场的其他报价做的都是非标准品种的示例。成交消息中的示例可以是标准品种的示例，也可以是非标准品种的示例，取决与该成交是对标准品种报价的成交还是对非标准品种报价的成交。

例外情况：对于现券市场、资产支持证券市场和ETF市场由于不存在交易品种之说（这三个市场的交易的对象都具有券的性质），示例中48和55域分别填写其具体的债券代码和债券名称。

6.12 本方和对手方

在报价和成交数据中都有本方和对手方的概念。本方和对手方是一个动态的概念，不管是报价还是成交消息，消息的接收方都认为自己是本方，另一方是对手方，协议本身是不定义本方和对手方的。 但是协议的使用者可以根据业务逻辑和消息结构判断本方和对手方，例如 对报价消息而言，根据当前的业务现实，在除对话报价以外的其他报价方式下，本币CSTP用户收到的本方数据只能是其发起的报价数据，IMIX消息中其PartyID对应的PartyRole取值只能是101，因此在这些报价方式下，消息中PartyRole=101的机构方既是该消息的本方；然而在对话报价中，不管是报价的发起方还是报价的接收方（对手方）都会收到该笔报价，并归入本方数据中，因此，PartyRole取值是101或是102的机构都可能是本方，取决于该消息发送给哪方。 对应成交消息而言，成交达成以后，交易系统会分别向成交双方发送成交单，每一方在接收到该成交单以后，都认为这是本方的数据，另一方是对手方，因此没有固定的本方和对手方，只有固定的买方和卖方的概念。协议中通过PartyRole取值119和120分别表示一笔交易的买方和卖方。不过，协议中通过域Side和PartyRole可以判断一笔成交单消息中哪方是本方，哪方是对手方。 Side用于表示交易方向，取值1表示买入，取值4表示卖出。每份成交单中都有Side域，表示该成交单的接收方是买入还是卖出，如果是买入（Side=1）,则买方（PartyRole=119）即是该成交单的本方，卖方则是对手方；相反，如果卖出（Side=4），则卖方（PartyRole=120）即是该成交单的本方，买方则是该成交单的对手方。

6.13 应急服务

新增了应急报价服务，书面委托、传真给交易中心，交易中心能代发报价。提供报价服务与成交服务，报价服务包括报价发送，报价修改和报价撤销。报价类型包括意向报价，双向报价，点击成交报价和限价报价。成交服务包括成交录入，修改和撤销。

应急报价和普通报价的区别主要在增加了应急标识10022ContingencyIndicator域，并且取值为Y表示是应急服务场景；应急成交和普通成交的区别除了10022域之外，还增加了

10105DealTransType域，用来标识成交录入，修改和撤销的场景。下面以信用拆借市场为例，列举一个应急意向报价场景和一个应急成交录入场景：

(1) 应急意向报价 域号 (Tag) 28 23 27 44 48 54 55 58 60 62 63 10002 537 10022 10176 10271 10282 10289 (FieldName) IOITransType IOIID IOIQty Price SecurityID Side Symbol Text TransactTime ValidUntilTime SettlType AccruedInterestTotalAmt QuoteType ContingencyIndicator MarketIndicator QuoteTime RemarkIndicator SettlCurrAmt2 （Value) N IBO-2007-08-21-123456 230000 0.05 User-Defined 1 XXXX XXXX 20070820-12:40:00 20070821-12:40:00 1 105 0 Y 1 20070821-12:33:34 Y 2400000 意向报价会话类型：N-新报价 意向报价编号 域名 例子取值 注解 拆借金额 拆借利率 交易品种代码 交易方向 拆入 交易品种名称 备注 报价有效时间 清算速度 T+0 应计利息 意向性报价 应急场景 市场标识: 1-信用拆借市场 报价日期时间 有备注 到期还款金额 10316 10465 453 TradeLimitDays DataCategoryIndicator NoPartyIDs 22 0 1 BC0000000000000000B拆借期限 数据类型标识 参与方数目 → 448 PartyID SH → → → → 215 → 452 802 → → 216 523 803 PartyRole NoPartySubIDs PartySubID PartySubIDType NoRoutingIDs RoutingType 101 1 XXXX 2 1 5 发起方

(2) 应急成交录入

域号 (Tag) 17 44 48 54 55 58 60 (FieldName) ExecID Price SecurityID Side Symbol Text TransactTime （Value) IBO-2007-08-21-123456 0.05 XXXX 1 XXXX XXXX 20081006-12:34:56 成交编号 域名 例子取值 注释 拆借利率 交易品种代码 交易方向 交易品种名称 备注 更新日 64 75 117 150 10002 193 10022 10014 10105 SettlDate TradeDate QuoteID ExecType AccruedInterestTotalAmt SettlDate2 ContingencyIndicator CashHoldingDays DealTransType 20070822 20070821 IBO-QuoteID-2007-08-21-123456 F 1000 20070921 Y 20 0 首次结算日 成交日期 报价编号 成交状态-成交 应计利息 到期结算日 应急场景 实际占款天数 成交录入 市场标识: 10176 MarketIndicator 1 1-信用拆借市场 10282 10289 32 10316 10318 10465 453 → → → → 448 452 802 → 523 RemarkIndicator SettlCurrAmt2 LastQty TradeLimitDays TradeTime DataCategoryIndicator NoPartyIDs PartyID PartyRole NoPartySubIDs PartySubID Y 2323232 23034232 30 12:34:56 0 2 BC0000000000000000BSH 119 5 XXXX 有备注 到期还款金额 拆借金额 拆借期限 成交时间 数据类型标识

→ → → → → → → → → → → → → → → → → → → → → → → → → → → → → → → 448 452 802 → → → → → → → → → → 803 523 803 523 803 523 803 523 803 523 803 523 803 523 803 523 803 523 803 PartySubIDType PartySubID PartySubIDType PartySubID PartySubIDType PartySubID PartySubIDType PartySubID PartySubIDType PartyID PartyRole NoPartySubIDs PartySubID PartySubIDType PartySubID PartySubIDType PartySubID PartySubIDType PartySubID PartySubIDType PartySubID PartySubIDType 2 XXXXXXXX 15 XXXXXXXX 23 XXXXXXXX 110 XXXXXXXX 112 ICBC00000000000000BNJ 120 4 XXXX 2 XXXXXXXX 15 XXXXXXXX 23 XXXXXXXX 110 XXXXXXXX 112 资金账号 资金账户户名 资金开户行 资金开户行联行行号 资金账号 资金账户户名 资金开户行 资金开户行联行行号

6.14 盘后消息重发

为了确保API用户能够收到所有的消息，避免特殊原因的消息丢失，盘后固定时点CSTP系统会向特定用户重发一次当天的所有消息，此类消息的消息结构和内容与日间收到的消息格式和内容上都是一样的，只是消息头中的域 115的取值是“RESEND”，而不是普通消息中的“CFETS-RMB”, 标识消息的发送方是消息重发系统，而不是本币交易系统。API用户可以用重发的消息和当天收到的消息比较，以防止消息丢失。

判断消息是否是重发的标准是115域的取值，取值是“RESEND”标明是API盘后重发消息，取值是“CFETS-RMB”标明消息是盘中正常收到的消息。

API用户盘中收到的消息的消息头结构示例如下： 8 9 35 34 BeginString BodyLength MsgType MsgSeqNum IMIX.1.0 1 6 24 20070820-12:40:52 SendingTime 00 消息的最初发送方是115 OnBehalfOfCompID CFETS-RMB 本币交易系统 CFETS-RMB-CS49 SenderCompID TP BC0000000000056 TargetCompID 00000BSH BC0000000000057 TargetSubID 00000BSH-小张

意向性报价 消息序列号 发送时间 API用户盘后重发的消息的消息头结构示例如下： 8 9 35 34 BeginString BodyLength MsgType MsgSeqNum IMIX.1.0 1 6 24 20070820-12:40:52 SendingTime 00 消息的最初发送方是115 OnBehalfOfCompID RESEND 重发系统 CFETS-RMB-CS49 SenderCompID TP BC0000000000056 TargetCompID 00000BSH BC0000000000057 TargetSubID 00000BSH-小张

意向性报价 消息序列号 发送时间 6.15 系统更新报价消息

对于任何一笔报价，在成交达成之后，报价的状态需要从新报价转换成成交状态，交易系统会向CSTP成员发送一条报价修改消息，其中域297 QuoteStatus取值107，标识状态是“已成交”。对于点击成交和做市报价，每次在点击成交之后，如果剩余量不为零，在成交单发出之前，系统会首先发送一条报价修改消息，其中域10087 LeavesTotalQty标识原报价的剩余量，32 LastQty标识到目前为止该报价已经被成交的总量，297 QuoteStatus取值108表示部分成交。如果原报价量被点击完，在成交单之前仍然会有一条报价修改消息，其中10087取值为0，297取值为107。

6.16 报价状态“发送”和“收到”的说明

对于报价的发送方和接收方“报价状态”前台显示的是“发送”或“收到”，但是从消息的角度，IMIX消息中没有这两个状态，在对话报价中双方收到的状态都是“正常”（297=16），如果用户需要显示“发送”或“收到”，需要用户根据逻辑判断，判断逻辑如下：

根据128域中的机构ID找到消息体中的相同的机构ID的Parties 组件，判断组件中的452 PartyRole的取值，如果是101（报价发起方），则该机构的“报价状态”就是“发送”；如果是102（对手方），则该机构的“报价状态”就是“收到”。

6.17 结算方式

域919 DeliveryType、10045 DeliveryType2、10098 LegDeliveryType和10459 LegDeliveryType2都是标识结算方式或到期结算方式，取值都是0 - DVP;4 - PUD;5 - DUP;6 - BVB;7-NONE;8-BVBF;9-BVP，业务关系对应如下： 0 – DVP 券款对付 4 – PUD 见券付款 5 – DUP 见款付券 6 – BVB 券券对付 7 – NONE 纯券过户 8 – BVBF 返券付费解券 9 – BVP 券费对付

6.18 期限的转换

除现券市场和资产支持证券市场以外都有期限要求，其中信用拆借、质押式回购、买断式回购、债券借贷、债券远期界面显示要求期限精确到天，如“32”天；利率互换市场期限以YMD的格式显示，如“2M”；远期利率协议以“远期期限*合约期限”的方式显示，如“2M*8M”。

对于API消息，信用拆借、质押式回购、买断式回购、债券借贷、债券远期市场的消息中，域10316的取值既是“期限”的数据。对于利率互换市场，10316的取值以YYMMMDDD的格式传，如交易期限是6个月，消息中10316=6000，如果是1年，消息中10316=1000000.对于远期利率协议市场，传输方式与利率互换市场一致，但是通过两个域传，10314传远期期限，10316传合约期限。

对于报表，将以YYMMMDDD的格式发送，如果收到的是178天，表明期限是178天；如果传的是2000，表明是2M，如果是1000000，表明是1Y。

本文来源：https://www.bwwdw.com/article/zf4o.html