中国票据交易系统直连接口规范(概述分册)

中国票据交易系统直连接口规范
【概述分册】
上海票据交易所
2019年04月
文档修订记录
版本编号变化状态简要说明日期变更人批准日期批准人V1.0 A 新建2017.6.8 张艳宁、郑龙2017.6.8 欧韵君V2.0 M 修改2017.9.30 张艳宁2017.9.30 欧韵君V2.1 M 修改2018.4.20 张艳宁2018.4.20 欧韵君V3.0 M 修改2019.4.30 张艳宁2019.4.30 欧韵君注：变化状态：A—增加，M—修改，D—删除
目录
修改记录 (3)
1报文交换标准概述 (6)
1.1术语说明 (6)
1.2业务标准 (6)
2报文格式概述 (9)
2.1报文结构 (9)
2.2报文头格式 (9)
2.3报文体格式 (12)
2.4报文编号 (14)
2.5其他约束 (14)
3报文数据定义 (15)
3.1数据类型 (15)
3.2票据状态 (28)
3.3票据流转状态 (28)
3.4票据库存状态 (30)
3.5票据风险状态 (30)
3.6报价单状态 (31)
4附录 (33)
附录1：直连模式 (33)
附录2：报文清单 (33)
附录3：基础数据清单 (33)
附录4：业务编号 (34)
附录5：权限清单 (34)
附录6：处理码清单 (35)
附录7：状态流转表.......................................................................................... 错误！未定义书签。

附录8：直连切换规则 (36)
附录9：直连切换前文件下发清单 (36)
附录10：直连切换后文件下发清单 (36)
附录11：文档规范 (37)
修改记录
序号修改日期修改说明
1 2017-6-1
2 1、[M]-修改修改2.3.2数字签名章节描述；
2、[M]-修改报文清单中增加数字证书绑定通知报文；
2 2017-6-18 1、[M]-修改中国票据交易系统对账文件格式标准中文件命名改
为“DRAFTLIST-会员代码-yyyymmdd-10位序号.dat”；
2、[M]-修改调整附录7：状态流转表；
3 2017-6-21 1、[M]-修改调整RlvInfo字典；
2、[M]-修改附录2：报文清单，登录/退出申请报文需要加签
4 2017-6-27 1、[M]-修改修改票据库存状态“已增信保管”替换为“已增信
保证”；
5 2017-7-12 1、[M]-修改修改DishonorCode、RefuseReason字典值；
6 2017-7-21 1、[M]-修改修改附录5：权限清单，并补充相关说明。

2、[A]-增加增加数据类型ClrTsn；
7 2017-8-24 1、[M]-修改修改报文数据定义的数据类型RefuseReason、
VerfyAdd、RlvInfo、UpldMode、ClrRsn的附加说明，新增
数据类型SettleMentType
2、[M]-修改修改附录7：状态流转表“库存变更申请报文（贴
现保管行内移库拒绝应答时自动发起）”，前置和后置全部写成- 8 2017-9-4 1、[A]-增加附录8：线下文件下发清单增加文件《中国票据交
易系统在途业务清单文件格式标准》
2、[M]-修改修改附录5：权限清单下发范围。

3、[A]-增加新增数据类型
MaxMinxxxAlphaNumericSymbolText，统一社会信用代码修
改为适用于MaxMin18AlphaNumericSymbolText
9 2017-9-12 1、[M]-修改 CurrencyAndAmountRegCap 修改为金额总长
16位（含小数点），最多13位整数，2位小数
2、[M]-修改 PercentRate的类型定义修改为小数部分6位
3、[D]-删除删除数据类型PercentTrdRate
4、[M]-修改直连接口规范中的MD5算法改用SHA256算法进行
报文消息完整性校验，同步修改报文头格式BodyChksum、
Reserve、EndFlag相关信息。

10 2017-9-15 1、[D]-删除删除数据类型UserType中的字典值：UT05
11 2017-9-21 1、[M]-修改增加数据类型StlRequestType中的字段值
12 2017-9-22 1、[A]-增加新增非交易过户与再贴现相关的业务流转状态
13 2017-10-19 1、[M]-修改存量基础数据文件中的会员信息数据文件增加了
“是否开通结算确认”字段
2、[M]-修改清算结算业务对账文件的结算汇总文件不含撤销数
据；
3、[M]-修改 OutInAmtCode入金失败代码增加字典项：
C1O1AC096，出入金未知异常
13 2017-10-24 1、[M]-修改权限清单中的报文权限清单增加定义了清算类上行
报文发起时需检查的业务权限。

14 2017-11-13 1、[M]-修改基础数据文件-会员信息数据文件的清算模式栏位
增加栏位为空状态的说明。

2、[M]-修改基础数据文件-机构信息数据文件的交易账户状
态、托管账户状态栏位增加栏位为空状态的说明。

15 2017-11-14 1、[M]-修改状态流转表中，权属初始登记报文前库存状态修改
为“-”
16 2017-11-19 1、[M]-修改数据类型EffectiveCode字典项修改为CC00 有
效
17 2017-11-21 1、[M]-修改交易业务确认报文（CES010）纳入对账。

2、[M]-修改修改机构信息数据文件的机构全称（中文）、机构
简称（中文）为Max60Text；机构信息数据文件、交易员信息数
据文件地址字段调整为Max60Text；机构信息数据文件联系人字
段调整为Max20Text ；机构信息数据文件中去掉系统参与者大
额行名；交易员信息数据文件用户姓名字段调整为Max50Text ；
交易员信息数据文件邮箱字段调整为Max30Text；支付系统行名
行号信息数据文件本行上级参与机构字段调整为Max70Text；支
付系统行名行号信息数据文件电话/电挂字段调整为Max50Text
3、[M]-修改票据流转状态增加取值：转贴现清算失败
（ST0302）、买断式回购清算失败（ST0306）
18 2017-12-07 1、[M]-修改修改权限清单中转贴现/质押式回购/买断式回购发
送修改报文、对话报价成交/应答报文的业务权限检查规则；修改
转贴现/质押式回购/买断式回购的机构业务权限和用户业务权
限。

2、[M]-修改增加系统对账文件的报文时间说明。

19 2017-12-11 1、[M]-修改更新基础数据清单中机构类型、机构类型类别关系
的数据清单
2、[A]-增加新增附录8：直连切换规则
3、[M]-增加增加票据流转状态：ST0405 质押式回购到期锁
定、ST0408 买断式回购到期锁定、ST0417再贴现质押式回购到
期锁定
20 2017-12-19 1、[C]-创建新增系统工作日期说明（1.2.9）
21 2018-2-2 1、[M]-修改 PercentRate的类型定义修改为11位数字，小数
部分6位
22 2018-2-5 1、[M]-修改删除RCbusitype数据类型，修改Busitype字
典值。

23 2018-2-9 1、[M]-修改对字典项Verfy增加字典值“电票确认”，影像类
型增加“再贴现”、“非交易过户”字典值。

2、[M]-修改修改SendRange字典项
3、[A]-增加附录11：直连切换后下发文件增加再贴现对账文件
24 2018-3-21 1、[M]-修改对字典项BrStatus增加字典值“ST03 注销”
25 2018-5-15 1、[A]-增加数据类型增加MemSysStatus的数据类型
2、[M]-修改更新业务权限清单：再贴现质押式回购-业务申请、
再贴现质押式回购-业务确认
3、[M]-修改更新报文清单中通用转发报文的报文发起时间为日
间+日终
25 2018-6-4 1、[A]-增加 UserStatus增加字典项“US04 注销”，机构承
接生效后，被承接机构与用户将被注销。

2、[M]-修改修改再贴现对账文件中业务类型、申请单状态的字
段类型。

3、[A]-增加新增数据类型CurrencyAndAmountBal，适用于
托管账户余额对账文件中期初余额、借方发生额、贷方发生额、期
末余额的字段类型。

26 2018-6-12 1、[M]-修改修改再贴现授信文件-再贴现授信类型的字段类型
为“MaxMin1NumericText”
2、[M]-修改修改再贴现授信文件、再贴现受理关系文件、再贴
现申请单自动作废对账文件、月末托管票据明细对账文件、每日托
管账户余额对账文件的文件名
27 2018-6-13 1、[M]-修改更新基础数据清单：增加“单笔再贴现票据张数上
限”
28 2018-6-19 1、[M]-修改数据类型BuyBackType增加字典值BBT03 部分
逾期赎回
29 2018-6-28 1、[M]-修改权限清单-业务权限清单增加非交易过户、质押式
提前/逾期赎回业务权限
30 2018-7-8 1、[M]-修改状态流转表-贴现登记撤回的前置状态、再贴现质
押式回购逾期情况
31 2018-7-13 1、[M]-修改修改CES019报文的对账标志为不对账
2、[M]-修改公共类基础数据文件增加机构新原关系数据文件
3、[M]-修改再贴现申请单自动作废对账文件-申请单状态字段
类型
32 2018-7-31 1、[M]-修改更新处理码清单
2、[M]-修改更新权限清单中非交易过户、质押式提前/逾期赎
回相关业务权限
33 2018-11-7 1、[M]-修改附录4业务编号规则中增加扣费请求编号规则。

34 2019-2-20 1、[M]-修改修改DishonorCode、MvTrTp、DealStatus、
StlRequestType字典值；
2、[A]-增加直连切换当天下发文件增加上线前业务数据文件、
节假日数据文件、机构新原关系文件
3、[M]-修改会员信息数据文件增加财务公司ECDS线上清算权
限信息
说明：[C]-创建；[M]-修改；[A]-增加；[D]-删除；
1报文交换标准概述
1.1术语说明
1.业务要素
业务要素是业务数据项的抽象名称，是业务的基本组成单位，如银行账户的账号。

2.报文
报文是系统节点间交换业务数据的基本单位，由报文头和报文体组成，其中报文体由多个报文块组成。

3.报文块
报文块是报文的基本组成单位，使用XML标签界定，由多个报文域组成。

4.报文域
报文域是报文块的基本组成单位，使用XML标签界定。

每个报文域封装一个或多个业务要素，多个报文域组成报文块。

对复杂的业务要素，报文域可能包含多个报文子域。

5.根报文域
报文使用XML文档标准，该文档的根节点称为根报文域，标签固定为<Document/>。

6.报文子域
对于分级的报文域，较低级的域称作报文子域，使用XML标签界定，位于较高级报文域的XML标签内部。

1.2业务标准
1.2.1字符集和编码
报文采用Unicode字符集，UTF-8编码方式。

对于禁止中文的Text类型字段，只允许出现英文字母、数字及以下特殊字符，即所谓的X字符集：
. , - _ ( ) / = + ? ! & * ; @ # : % [ ] \n \r \t （空格）
对于允许中文的Text类型字段，系统不做特殊检查，只要在Unicode字符集范围内的字符都能通过。

1.2.2会员代码
票交所系统为每个法人会员分配一个会员代码，该标识号由6位定长数字组成，第一位区分会员性质，“1”代表银行类会员、“2”代表非银行类会员、“3”代表资管类会员。

1.2.3机构代码
票交所系统为每个参与者分配一个机构代码，该标识号由9位定长数字组成。

1.2.4行别代码
该标识号由三位定长数字组成，编码结构如下：
n nn
(1) (2)
说明：
（1）类别代码：1位数字，标识银行类型。

值定义如下：0－中央银行；1－国有独资商业银行；2－政策性银行；3－其他商业银行；4－非银行金融机构；5、6、7－外资银
行；（8待分配）；9－特许参与者。

（2）行别代码：2位数字。

1.2.5大额支付系统行号
根据大额支付系统的规则，支付系统为每个参与者（含直接参与者、间接参与者、特许直接参与者）分配一个标识号以标识该参与者。

该标识号由十二位定长数字组成，其编码结构如下：
nnn nnnn nnnn n
(1) (2) (3) (4)
说明：
（1）行别代码：3位数字；
（2）地区代码：4位数字；
（3）分支机构序号：4位数字，按各行别各地区机构顺序编排；
（4）校验码：1位数字，生成算法由中国人民银行确定；
（5）特许参与者也按此标准分配行号。

1.2.6客户账号
客户账号由最长32位X字符集范围内的字符组成。

1.2.7报文标识号
1.2.7.1报文标识号组成规则
报文标识号指报文格式定义中“报文标识<MsgId/>”标签下的“报文标识号<Id/>”，由报文的发起方填写，填写规则为：会员代码（6位）+机构代码（9位）+日期（8位，如20070101）+当日序号（10位，如0000000001）。

其中会员代码、机构代码为业务发起方的会员代码、机构代码；如果为会员发起的报文，则机构代码为“000000000”；如果为票交所发起的报文，则会员代码+机构代码为“000000000000000”；日期指报文填写时的系统工作日期,当日序号为一流水号，由发起方自行确定，但要求保证填写得到的报文标识号在当天唯一。

虽然报文格式标准中的报文标识号的数据类型是Max35NumericText，但要求各个系统参与者的报文标识号填写固定的33位。

票交所系统会在日切后，向各接入点发送系统状态变更通知报文，告知各接入点系统日期更新及最新的系统时间参数。

1.2.7.2转发报文的报文标识号
通用业务转发报文的原业务申请报文部分会带有原申请报文的报文标识号。

通用转发报文还会带有该报文本身的报文标识号，该报文本身的报文标识号是和其内的原申请报文的报文标识号一样的。

转贴现对话报价转发报文、质押式回购对话报价转发报文、买断式回购对话报价转发报文部分会带有原申请报文的报文标识号。

此类报文还会带有该报文本身的报文标识号，该报文本身的报文标识号是和其内的原申请报文的报文标识号一样的。

1.2.7.3报文域原申请报文标识<OrgnlMsgId><Id/></OrgnlMsgId>填写规则
以下报文中含有原申请报文标识报文域，每个报文中，该域的填写规则如下：
通用业务应答报文：填写原业务申请报文中的报文标识号（不是通用转发报文的报文标识号）；
通用业务撤销报文：填写原业务申请报文中的报文标识号；
通用业务确认报文：此报文是票交所系统对参与者发来的报文的回执报文，所以该报文的原申请报文标识表示票交所系统处理的是哪个报文；
转贴现对话报价发送申请报文、质押式回购对话报价发送申请报文、买断式回购对话报价发送申请报文：如首次发送，不填写；如修改发送，填写交易对手最新发送的转贴现对话报价发送申请报文、质押式回购对话报价发送申请报文、买断式回购对话报价发送申请报文中的报文标识号；
对话报价确认报文：此报文是票交所系统对参与者发来的对话报价报文的回执报文，所以该报文的原申请报文标识表示票交所系统处理的是哪个报文；
对话报价成交/终止应答报文：填写交易对手最新发送的转贴现对话报价发送申请报文、质押式回购对话报价发送申请报文、买断式回购对话报价发送申请报文中的报文标识号（不是相关转发报文的报文标识号）；
登录/退出应答报文：原登录/退出申请报文的报文标识号；
业务申请清退通知报文：填写原业务申请报文中的报文标识号；
影像上传申请应答报文：填写原影像上传申请报文中的报文标识号；
所有的查询应答报文：填写原查询申请报文中的报文标识号。

1.2.8业务层面报文重账检查规则
票交所系统使用报文标识号作为业务层面报文重账的检查标准。

如发现重账，返回通用业务确认报文及其他相应确认、应答报文，反馈原申请已收到，状态为成功、失败、待处理,不限于通过通用业务确认报文反馈。

注：如发现报文头中的“通信级标识号”重复，则直接丢弃。

1.2.9系统工作日期
票交所系统维护系统工作日期，通过系统状态变更通知报文下发给参与者。

对于上行报文，票交所系统会判断报文标识号中的日期是否为当前系统工作日期，如不符则拒绝。

对于下行报文，票交所系统生成的报文标识号中的日期为当前系统工作日期。

票交所系统以系统工作日期为范围生成该日期的对账文件（报文明细文件）。

报文头中的报文发起日期、报文发起时间以及报文体中的报文时间，票交所系统的下行报文使用北京日期与北京时间，不校验上行报文的相关日期与时间。

2报文格式概述
2.1报文结构
票交所系统使用XML报文传输业务数据。

该XML报文仅承载业务数据本身，并没有包含与报文流转、交换、路由等相关的通信级信息。

这些通信级信息须附加到额外的数据块中传输。

为处理的简便性，票交所系统将通信级数据块附加到业务报文的头部，称之为报头，而将业务报文本身称为报体。

报头与报体构成一个完成的报文，即票交所系统报文格式如下：
MsgHeader Document
说明：总体上，报文分为两大部分：报文头部分及报文体部分。

1.报文头部分
报文头部分用于存放具体的通信信息，其内容和格式固定，需要按照规定的格式填写。

2.报文体部分
报文体部分包括正文体和数字签名，采用XML格式实现。

注：标准XML报文首位字符不允许出现空格等字符，应以<?xml version="1.0" encoding="UTF-8"?>开始。

具体格式示例如下：
<?xml version="1.0" encoding="UTF-8"?>
<Document>
<MainBody>正文体内容</MainBody>
<PtcptSgntr>数字签名</PtcptSgntr>
</Document>
2.2报文头格式
2.2.1报文头格式说明
节点间报头传输通信级数据，主要由版本标识、发起方、接收方、报文描述四个部分组成，采用定长数据格式，总长度为191字节。

格式如下：
域类域名含义位置长度
类
型
属
性
说明
BeginFlag 起始标识0 3 x M
标识报头块开始，固定使
用：{H:
版
本
VersionID 版本号 3 3 n M 固定填写001 发
起方SenderID 报文发起方 6 6 x M
标识报文发起方会员代码
票交所发起 000000
接
收方ReceiverID 报文接收方12 6 x M
标识报文接收方会员代码
票交所接收 000000
票交所广播 999999
报
文描述OrigSender 报文发起人18 6 x M
标识报文原始业务发起方
会员代码
票交所发起 000000 OrigReceiver 报文接收人24 6 x M 标识报文最终业务接收方
会员代码
票交所接收 000000 票交所广播 999999
OrigSendDate 报文发起日期30 8 d M 标识OrigSender发出本报文的机器日期
OrigSendTime 报文发起时间38 6 t M 标识OrigSender发出本报文的机器时间
MesgType 报文类型代码44 20 x M 报文编号
MesgID 通信级标识号64 20 x M 通信层标识一个报文，由OrigSender顺序编制，并确保在OrigSendDate当日唯一接收方根据OrigSender＋OrigSendDate＋MesgID唯一确定一个报文，该三项重复的报文作为通信级重复报文
MesgRefID 通信级参考号84 20 x O 标识本报文的关联报文，由OrigSender设置，后续节点应保持该域不变，并在通信回应报文中带回该值，以便OrigSender 匹配原报文
MesgDirection 报文传输方向104 1 x M 由参与者发出：U
由票交所系统发出：D
MesgPriority 报文优先级105 1 n M 固定填写3 EncryptFlag 报文加密标识106 1 x M 固定填写N
BodyLength 报体长度107 8 n M 标识本报文报体部分的长度（按字节数统计）
BodyChksum 报体校验值115 64 x M 标识本报文非报文头部分的校验值，校验算法使用SHA-256
Reserve （保留域）179 9 x O 保留（固定填写9个空格）
EndFlag 结束标识188 3 x M 标识报头块结束，固定使用：}\r\n
\r = 0x0d
\n = 0x0a
说明：
1.x类型标识字符，取值范围为a-z、A-Z、0-9、.(英文句号)、－(连字符)、_(下划线)；n 类型标识数字，取值范围为0-9；d类型标识日期，格式为：yyyymmdd；t类型标识时间，格式为：hhmmss；
2.各域均为定长域，值不足长度时应补位：x类型的，后补空格(0x20)；n类型的，前补0(0x30)；
3.强制域必须填值。

x类型的不能为全空格(0x20)，n、d、t类型的不能是全0(0x30)；可选项可以不填值，但应填充占位字符。

x类型填充空格(0x20)，n、d、t类型的填充0(0x30)；
4.报头块各域字母均不区分大小写，建议使用全大写字母；
5.报文发起方、报文接收方指报文的发起和接收方，一方是票交所，一方是参与者；报文发起人、报文接收人指的是业务的发起方和接收方，涉及应答的报文，双方都是参与者。

通用业务撤销报文、通用业务应答报文的报文接收人是指业务接收方，即参与者。

6.票交所系统在下行转贴现对话报价转发报文、质押式回购对话报价转发报文、买断式回购对话报价转发报文、通用业务撤销报文、通用业务转发报文、通用业务应答报文、自由格式信息报文、业务查询报文、业务查复报文时，报文头中填写的报文发起人和报文接收人和所对应的上行报文（分别是转贴现对话报价发送修改申请报文、质押式回购对话报价发送修改申请报文、买断式回购对话报价发送修改申请报文、通用业务撤销报文、会员发送的申请报文、通用业务应答报文、会员发送的自由格式信息报文、会员发送的业务查询报文、会员发送的业务查复报文）报文头中的报文发起人和报文接收人一致。

7.票交所代码为“000000”。

全市场广播或非全市场广播报文，接收人代码填写“999999”。

2.2.2报文头填写范例
2.2.2.1参与者系统提交给票交所系统
域类域名含义位置长度
类
型
属
性
说明BeginFlag 起始标识0 3 x M {H:
版
本
VersionID 版本号 3 3 n M 固定填写001 发
起
方
SenderID 报文发起方 6 6 x M 100000
接
收
方
ReceiverID 报文接收方12 6 x M 000000
报文描述OrigSender 报文发起人18 6 x M 100000
OrigReceiver 报文接收人24 6 x M 100001
OrigSendDate 报文发起日期30 8 d M 20170426 OrigSendTime 报文发起时间38 6 t M 103000
MesgType 报文类型代码44 20 x M
CPR.001.005
（注意后补空格）
MesgID 通信级标识号64 20 x M
A1234B1234C1234D12
34
MesgRefID 通信级参考号84 20 x O
000000000000000000
00
MesgDirection 报文传输方向104 1 x M U
MesgPriority 报文优先级105 1 n M 3
EncryptFlag 报文加密标识106 1 x M N
BodyLength 报体长度107 8 n M 00006447
BodyChksum 报体校验值115 32 x M
A1B2C3D4E5F6A1B2C3
D4E5F6A1B2C3D4
Reserve （保留域）147 9 x O
（9个空格）
EndFlag 结束标识156 3 x M }\r\n
2.2.2.2票交所系统发送给参与者系统
域类域名含义位置长度
类
型
属
性
说明BeginFlag 起始标识0 3 x M {H:
版
本
VersionID 版本号 3 3 n M 固定填写001 发
起
方
SenderID 报文发起方 6 6 x M 000000
接
收
方
ReceiverID 报文接收方12 6 x M 100000
报文描述
OrigSender 报文发起人18 6 x M 100001
OrigReceiver 报文接收人24 6 x M 100000
OrigSendDate 报文发起日期30 8 d M 20170426
OrigSendTime 报文发起时间38 6 t M 103000
MesgType 报文类型代码44 20 x M
CPR.001.005
（注意后补空格）MesgID 通信级标识号64 20 x M
A1234B1234C1234D12
34
MesgRefID 通信级参考号84 20 x O
000000000000000000
00
MesgDirection 报文传输方向104 1 x M D
MesgPriority 报文优先级105 1 n M 3
EncryptFlag 报文加密标识106 1 x M N
BodyLength 报体长度107 8 n M 00006447
BodyChksum 报体校验值115 32 x M
A1B2C3D4E5F6A1B2C3
D4E5F6A1B2C3D4
Reserve （保留域）147 9 x O
（9个空格）EndFlag 结束标识156 3 x M }\r\n
2.3报文体格式
2.3.1正文体
正文体用于标识报文的业务数据信息。

报文体中除去数字签名的部分都是正文体的部
分，如以下结构中<MainBody/>标签的部分：
<?xml version="1.0" encoding="UTF-8"?>
<Document>
<MainBody>...</MainBody>
<PtcptSgntr>...</PtcptSgntr>
</Document>
2.3.2数字签名
数字签名部分包含两个报文域，<PtcptSgntr/>和<CdesSgntr/>。

其中<PtcptSgntr/>是系统参与者在发起业务报文时加的签名，使用该系统参与者的证书进行签名。

<CdesSgntr/>是票交所系统在报文下发或转发时加的签名。

数字证书绑定通知报文使用带签名者证书（公钥）的数字签名（PKCS#7），非数字证书绑定通知报文使用无签名者证书（公钥）的数字签名（PKCS#1，裸签）。

签名验签算法使用SM2算法，签名为BASE64串。

<PtcptSgntr/>签名适用于系统参与者发给票交所系统的需加签的报文，即此时报文包括<PtcptSgntr/>一个签名；
<CdesSgntr/>签名适用于票交所系统下发的需要加签的报文，此时报文包括<CdesSgntr/>一个签名；也适用于票交所系统将一个系统参与者发送的报文转发给另一个系统参与者，在原报文中增加内容时（如“通用转发报文”），需要对全文的内容加签。

具体结构如下：
<?xml version="1.0" encoding="UTF-8"?>
<Document>
<MainBody>...</MainBody>
<CdesSgntr>...</CdesSgntr>
</Document>
加签要素的说明：
票交所系统采用以“块”做为要素的方式进行加核签处理，系统参与者发送业务报文时，对正文体部分的内容做为整体进行加签，并加入到根报文域<Document/>内正文体的后面；票交所系统下发报文时，与系统参与者加签方式相同。

参与者申请报文加签说明：
<?xml version="1.0" encoding="UTF-8"?>
<Document>
<MainBody>…</MainBody>
<PtcptSgntr>
申请报文中的签名，加签部分为：<MainBody/>内的全部内容，包括标签
<MainBody/>本身
</PtcptSgntr>
</Document>
票交所发起或转发报文加签说明：
<?xml version="1.0" encoding="UTF-8"?>
<Document>
<MainBody>…</MainBody>
<CdesSgntr>
加签部分为：<MainBody/>内的全部内容，包括标签<MainBody/>本身
</CdesSgntr>
</Document>
2.3.3格式检查
每个报文都有对应的schema文件用来进行报文格式检查，schema文件名称与报文编号相同。

参与机构发送报文给票交所系统时，应将待发送往帐报文的报文体使用XML Schema
进行格式检查，检查通过后，才能提交给票交所系统。

参与机构从票交所系统接收报文后，应使用XML Schema对收到的报文体进行格式检查，检查通过后，才能提交给行内系统进行业务处理。

对检查失败的报文，丢弃该报文，留待日终对账解决。

2.4报文编号
2.4.1系统编号
序号业务类型名称系统编号
1.会员类MEM
2.纸票业务处理类NCP
3.登记托管类CPR
4.核心交易类CES
5.清算结算类CAS
6.通用信息类CIM
7.公共控制类CCM
8.计费类CHS
2.4.2报文编号
报文编号规则为“xxx.nnn.nnn”，简称“xxxnnn”
表示系统编号，三位小写字母
表示报文序号，三位数字
版本号，三位数字
2.5其他约束
2.5.1单个报文长度
单个报文长度大小应符合以下规定，超过该长度大小的报文将被票交所系统拒绝。

序号报文名称报文大小
（按照1M=1024*1024字节计算）
1.通用非签名信息业务报文
<2M 2.通用签名信息业务报文
3.自由格式报文3M
4.通用业务转发报文、托管票据明细通知报文、票交所
资金账户清算排队查询应答报文
不限定报文大小
5.其余报文<2M
2.5.2UTF-8的BOM问题
报文使用UTF-8编码，传输报文时，应注意报文中不能包含UTF-8编码的BOM header（其对应的二进制为EF BB BF）。

对带有BOM header的报文，系统将拒绝受
理。

3报文数据定义
3.1数据类型
类型名称类型定义附加说明
MaxxxxText 表示字符串，最少1字符，最多
xxx字符的文本，含数字、字母、
中文、及其他各种字符。

每个数字、字母、中文及其他
各种字符均占一个字符。

MaxxxxNumericText 表示数字串，最少1位，最多xxx 位的数字。

MaxMinxxxNumericText 表示固定xxx位长度的数字串。

MaxxxxAlphaNumericText 表示字符串，最少1字节，最多
xxx字节的文本，只含
a-z,A-Z,0-9。

不含中文和其它符号
MaxMinxxxAlphaNumericText 表示固定xxx字节的字符串，只
含a-z,A-Z,0-9。

不含中文和其它符号
MaxMinxxxAlphaNumericSymbolTex t 表示固定xxx字节的字符串，只
含a-z,A-Z,0-9,-
不含中文和其它符号
ISODateTime yyyy-mm-ddTHH:MM:SS 例如：2007-03-11T15:09:05，其中的"T"为日期和时间的分割符，是必须的
ISODate yyyy-mm-dd 例如：2007-03-09 ISOTime HH:MM:SS 例如：17:30:00
PercentageRate 7位数字，小数部分6位用来表示百分比的单位
例如，0.534表示53.4%
CurrencyAndAmount (便签里面3位英文币种属性)金
额总长19位（含小数点），最多
16位整数,2位小数
币种属性固定填写“CNY”
CurrencyAndAmountRegCap (便签里面3位英文币种属性)金
额总长16位（含小数点），最多
13位整数,2位小数
币种属性固定填写“CNY”
BanEndorsementMarkCode 2位字母+2位数字编码EM00 可再转让EM01 不得转让
SignUpMarkCode 2位字母+2位数字编码SU00 同意SU01 拒绝
DraftTypeCode 2位字母+2位数字编码AC01 银承AC02 商承
TypeMarkCode 2位字母+2位数字编码TM00 登陆TM01 退出
ModType 2位字母+2位数字编码CC00 新增CC01 变更。