IMIX协议分析.doc

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. Milestone2004年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 消息头每个会话消息或应用消息都有一个消息头，该消息头指明消息类型、消息体长度、发送目的地、消息序号、发送起始点和发送时间。消息头格式见下表域号域名必需说明8BeginString必需起始串定义消息的协议版本（不可加密，消息的第一个域）9BodyLength必需消息体长度（不可加密，消息的第二个域）35MsgType必需消息类型（不可加密，消息的第三个域）49SenderCompID必需发送方代码（不可加密，发送方标识符）50SenderSubID发送方子标识符（可加密）56TargetCompID必需接收方代码（不可加密，接收方标识符）57TargetSubID接收方子标识符（可加密） 115OnBehalfOfCompID最初发送方标识符（可加密），用于经第三方中转发送。116OnBehalfOfSubID最初发送方子标识符（可加密）, 用于经第三方中转发送。128DeliverToCompID最终接收方标识符（可加密），用于经第三方中转发送。129DeliverToSubID最终接收方子标识符（可加密）, 用于经第三方中转发送。34MsgSeqNum必需消息序列号（可加密）43PossDupFlag消息可能重复标志，当一条消息以相同的序列号重传时（两条消息完全一样），作此标记，多数由于传输层异常重发时所标记。（可加密）97PossResend消息可能重传标志，当一条消息以不同的序列号重传时所加标志位，多数由于上层处理逻辑异常而重传时所带标记。（可加密）52SendingTime必需发送时间（可加密）122OrigSendingTime原始发送时间（可加密）347MessageEncoding消息中Encoded域的字符编码类型（非ASCII码）369LastMsgSeqNumProcessed最后处理消息序号（可加密）370OnBehalfOfSendingTime最初发送时间10287SegmentID产品编号，新一代本币系统必需域。10052ErrorCode错误代码，新一代本币系统必需域。10308SysSeqNo全局消息序号，新一代本币系统必需域。10333UserSeqNo用户特定消息序号，新一代本币系统必需域。HopsGrp表 1标准消息头例如：银行A的交易员小王发送消息给银行B的交易员小张，则小王发出去的消息标准头部应该如下表所示：域号域名值说明8BeginStringIMIX.1.0起始串IMIX1.0（不可加密，消息的第一个域）9BodyLength计算得到消息体长度（不可加密，消息的第二个域）35MsgType8Execution Report消息49SenderCompID银行A小王所在机构的标识56TargetCompIDCFETS通过交易中心中转128DeliverToCompID银行B小张所在机构的标识。50SenderSubID小王小王在所在机构的标识129DeliverToSubID小张小张在所在机构的标识34SeqNoxxx消息序列号52SendingTime时间发送时间（可加密）表 2标准消息头例子而小张给小王发的消息标准头部则应该如下表所示域号域名值说明8BeginStringIMIX.1.0起始串IMIX1.0（不可加密，消息的第一个域）9BodyLength计算得到消息体长度（不可加密，消息的第二个域）35MsgTypeDNewOrderSingle消息哦49SenderCompID银行B小张所在机构的标识56TargetCompIDCFETS通过交易中心中转128DeliverToCompID银行A小王所在机构的标识50SenderSubID小张小张在所在机构的标识129DeliverToSubID小王小王在所在机构的标识34SeqNoxxx消息序列号52SendingTime时间发送时间表 3标准消息头例子4.1.2 消息尾每一个会话消息或应用消息都有一个消息尾，并以此终止。消息尾可用于分隔多个消息，包含有3位数的校验和值。消息尾格式见下表4 域号域名必需说明93SignatureLength数字签名长度（不可加密）89Signature数字签名（不可加密）10CheckSum必需校验和，消息的最末域。（不可加密）表 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号域也应当是可选择性的。如果重复组的某一个域是必需的，那么在重复组内每次重复时该域都应出现。通过缩进的符号“”对消息定义内的重复组进行指定。重复组可嵌入其他重复组(可不止一层嵌套)。通过缩进的符号“”后跟缩进的符号“”的方式对嵌套的重复组进行指定。有嵌套重复组时，必需对外层的重复组进行指定。例如定义一重复组： 454NoSecurityAltIDN备选债券代码个数455SecurityAltIDN备选债券代码456SecurityAltIDSourceN备选债券代码源表 5重复组则该重复组实际使用例子如下454NoSecurityAltID3455SecurityAltID债券1456SecurityAltIDSource财政部发行455SecurityAltID债券2456SecurityAltIDSource企业发行455SecurityAltID债券3456SecurityAltIDSource央行发行表 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 登录登录连接包含三个步骤：建立电信通讯连接、连接双方的确认/认证、消息传输同步的初始化。主要有以下几点： 连接 会话的发起方与会话接收方建立电信通讯连接。 认证会话发起方发送登录消息（Logon），会话接收方认证发起方身份的合法性。登录消息应包括认证的必要数据，如用户名、密码等。如果会话发起方身份通过认证，则会话接收方发送一个登录消息作回应。如果认证失败，会话接收方则在发送一个包含失败说明的注销消息（Logout）后关闭连接。发送注销消息不是必需的，因为其占用了一个消息序号，而且在某些情况下可能会引起其他问题。登录成功后，会话发起方可在登录消息之后立即开始发送消息，但此时会话接收方可能并没有作好接收消息的准备；因此会话发起方应在收到接收方的登录消息确认之后，才认为会话连接建立完成。建议：在登录后或者刚发送完测试请求消息（TestRequest）时延迟等待一段时间，双方再发送新的消息，使得连接双方能有效控制重发请求；否则可能会导致一方会针对对方的每一条新消息发出重发请求。 初始化在身份通过认证之后，会话发起方和会话接收方应首先同步消息序号，然后才能相互发送新的信息。同步消息序号通过消息序号域（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）强制为下一发送消息的消息序号。序号重设-缺口填补应立即向对方发送重发请求。但是，必需确保没有无意间跳过任何消息，这意味着缺口填补消息应按次序被接收到，如果次序不对，那么表示出现了非正常的情况所有其它信息执行正常的缺口填补。表 16. IMIX Protocol关键域组件说明6.1 消息类型MsgType用于定义传输的消息类型，域号为35。IMIX协议为不同的业务场景定义不同的IMIX消息类型，例如：表示传输的消息为意向报价，表示传输的为成交信息。取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件6.2 市场标识符用于区分不同的业务市场的市场标识，域号为10176。在不同的市场下，同一种类型的IMIX消息往往在应用上有不同，需要根据不同的市场标识符，根据具体的业务逻辑对消息进行解释，例如：表示该消息为信用拆借市场的，则收到一条MsgType=6的消息，则为信用拆借市场的意向报价消息，就需要根据该市场意向报价的业务逻辑对IMIX消息传递的信息进行处理。取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件6.3 报价类型在业务报价场景中，QuoteType用于表示不同的报价类型，域号为537。例如：表示该报价为限价报价。取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件6.4 交易方式（询价，竞价，点击）TradeMethod用于区分不同交易方式，域号为10317。例如：表示该笔交易为询价方式的。取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件6.5 做市与非做市交易TradeType用于定义交易类型，区分做市交易和非做市交易。取值详见相关文档中的IMIX-成员端数据下载-Dictionary.XSL文件6.6 交易品种与基础品种在本币市场中，按照交易方式的划分，可以分为现货交易，远期交易，回购交易，期货交易，期权交易和互换交易。如果按照基础交易品种划分，可以分为债券，抵押，指数和借贷等。对于债券，又可以有公司企业债券，国债等。对于抵押，可以有资产支持证券，抵押支持债券等。对于指数，可以有ETFs, 利率等。对于借贷，可以有信用拆借等。IMIX协议通过对组件以及组件的定义在交易方式和基础交易品种这两个维度上对本币市场的金融产品进行描述。例如：在现券市场中，产品名称即债券名称Instrument22SecurityIDSource10148SecurityID2007002555Symbol07国开13表 7在债券借贷市场中如下，交易品种名称为SL03M，表示2个月零1天 3个月的债券借贷，而借贷的标的债券名称和代码需要在中填写。Instrument22SecurityIDSource10248SecurityIDSL03MUnderlyingInstrument309UnderlyingSecurityID20070062311UnderlyingSymbolChina001310%241UnderlyingCouponPaymentDate2007-08-01表 86.7 交易成员信息 和用于描述交易成员信息，例如：现券市场中的成员信息如下：Parties453NoPartyIDs2448PartyIDBANK01447PartyIDSource452PartyRole101PtysSubGrp802NoPartySubIDs10523PartySubIDBank of China803PartySubIDType5523PartySubIDBank of China803PartySubIDType110523PartySubID20008803PartySubIDType112523PartySubIDBank of China803PartySubIDType23523PartySubID955912345678901803PartySubIDType15523PartySubIDBank of China803PartySubIDType113523PartySubIDBank of China803PartySubIDType114523PartySubID622512345678901803PartySubIDType115523PartySubIDBank of China803PartySubIDTypeI18523PartySubIDBank of China803PartySubIDTypeI19448PartyIDBANK02447PartyIDSource452PartyRole102802NoPartySubIDs2523PartySubIDICBC803PartySubIDType102523PartySubIDTRADER02803PartySubIDType2表 9其中448 PartyID传输机构ID，具体的机构信息、帐户信息、交易员信息等通过传输，根据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的角度设置的，设定为拆入方向。域号域名取值35MsgTypeS49SenderCompIDCFETS-FI-CSTP56TargetCompIDA000000000000000001机构A57TargetSubIDXXXXXXX48SecurityIDIBO1M54Side1机构A拆入资金537QuoteType1对话报价10176MarketIndicator1信用拆借453NoPartyIDs2交易双方448PartyIDA000000000000000001机构A代码452PartyRole101机构A作为发起方802NoPartySubIDs1发起方其他相关信息数目523PartySubID张三803PartySubIDType101发起方交易员名称448PartyIDB000000000000000001机构B代码452PartyRole102机构B作为对手方802NoPartySubIDs1对手方相关信息数目523PartySubID李四803PartySubIDType101对手方交易员名称表 10机构C收到的消息例子片段如下，从下面的例子可以看出，下载服务代码和机构C标识代码出现在消息头中，作为消息接收双方。而机构A和机构B信息作为报价双方信息出现在Parties组件中，由PartyRole可知机构A在报价中是作为报价发起方，而机构B作为对手方。由于该条报价是下载服务作为关联机构报价发送给机构C的，所以下载服务在交易方向域Side的取值还是以关联机构A的角度设置的，设定为拆入方向。域号域名取值35MsgTypeS49SenderCompIDCFETS-FI-CSTP56TargetCompIDC00000000000000000148SecurityIDIBO1M54Side1拆入537QuoteType1对话报价报价10176MarketIndicator1信用拆借453NoPartyIDs2交易双方448PartyIDA000000000000000001机构A代码452PartyRole101机构A作为发起方802NoPartySubIDs1发起方其他相关信息数目523PartySubID张三803PartySubIDType101发起方交易员名称448PartyIDB000000000000000001机构B代码452PartyRole102机构B作为对手方802NoPartySubIDs1对手方相关信息数目523PartySubID李四803PartySubIDType101对手方交易员名称表 11如果下载服务将该条报价发送给机构B，机构B可以从该条报价中消息得知其作为报价对手方。消息例子片段如下：域号域名取值35MsgTypeS49SenderCompIDCFETS-FI-CSTP56TargetCompIDB00000000000000000148SecurityIDIBO1M54Side1拆入537QuoteType1对话报价报价10176MarketIndicator1信用拆借453NoPartyIDs2交易双方448PartyIDA000000000000000001机构A代码452PartyRole101机构A作为发起方802NoPartySubIDs1发起方其他相关信息数目523PartySubID张三803PartySubIDType101发起方交易员名称448PartyIDB000000000000000001机构B代码452PartyRole102机构B作为对手方802NoPartySubIDs1对手方相关信息数目523PartySubID李四803PartySubIDType101对手方交易员名称表 126.9 双向报价与利率互换产品报价由于双向报价与利率互换产品在报价信息上都存在两个交易方向上都有报价信息，所以IMIX协议定了以Leg开头的相关组件用于描述双向报价信息，或利率互换产品中的固定-浮动报价明细以及浮动-浮动报价明细。例如：组件用于双向报价场景中，或者利率互换的意向报价中。信用拆借市场的双向意向报价消息结构片段如下，其中域=2可表示该报价为双向的报价，具体的报价信息在Leg重复组中传输。域号域名取值537QuoteType101双向报价48SecurityIDIBO2M555NoLegs2两个重复组表示双向报价信息见附录LegSide1682LegIOIQty1208000000566LegPrice4.53686LegPriceType1见附录LegSettlCurrAmt21214747000见附录LegAccruedInterestTotalAmt6747000见附录LegSide4682LegIOIQty1208000000566LegPrice4.53686LegPric