网上支付跨行清算系统报文格式标准
“业务状态查询报文”时使用该域的第1位。用法：查询本行发起支付类业务在IBPS-NPC的处理情况时填写1，查询本行接收支付类业务在IBPS-NPC的处理情况时填写2。 其他报文：本域保留。建议忽略任何未定义的值。 标识报头块结束，固定使 EndFlag 结束标识 125 3 x M 用：}\\r\\n \\r = 0x0d \\n = 0x0a 说明：
１、x类型标识字符，取值范围为a-z、A-Z、0-9、－(连字符)、_(下划线)；n类型标识数字，
取值范围为0-9；d类型标识日期，格式为：yyyymmdd；t类型标识时间，格式为：hhmmss； ２、各域均为定长域，值不足长度时应补位：x类型的，后补空格(0x20)；n类型的，前补0(0x30)； ３、强制域必须填值。x类型的不能为全空格(0x20)，n、d、t类型的不能是全0(0x30)；可选项可
以不填值，但应填充占位字符。x类型填充空格(0x20)，n、d、t类型的填充0(0x30)； ４、报头块各域字母均不区分大小写，建议使用全大写字母。 第三方贷记业务对于报文头的使用说明：
１、第三方发起第三方贷记业务报文时：
“报文发起人”填写第三方参与机构行号，“报文接收人”填写付款清算行行号； ２、付款清算行发起第三方贷记业务回执报文时：
“报文发起人”填写付款清算行行号，“报文接收人”填写第三方参与机构行号； ３、收款清算行发起第三方贷记业务回执报文时：
“报文发起人”填写收款清算行行号，“报文接收人”填写第三方参与机构行号；
2.2.2 报文头填写范例 2.2.2.1
域 类 版本 域名 BeginFlag VersionID 行内系统发送给MBFE
含义 起始标识 版本号 报文发起人 发送系统号 报文接收人 接收系统号 位置 0 3 5 17 21 33 长度 3 2 12 4 12 4 类型 x n x x x x 属性 M M M M M M 说明 {H: 01 102100099998 IBPS 103100022226 IBPS 发 OrigSender 起 方 OrigSenderSID 接 OrigReceiver 收 OrigReceiverSID 中国人民银行清算总中心 第30页
网上支付跨行清算系统报文格式标准
方 OrigSendDate OrigSendTime StructType 报文描述 MesgRefID MesgPriority MesgDirection Reserve EndFlag 通信级参考号 报文优先级 报文传输方向 （保留域） 结束标识 94 114 115 116 125 20 1 1 9 3 x n X x x O M M O M MesgType MesgID 报文发起日期 报文发起时间 格式类型 报文类型代码 通信级标识号 37 45 51 54 74 8 6 3 20 20 d t x x x M M M M M 20100501 094508 XML ibps.101.001.01 A1234B1234C1234D1234 00000000000000000000 3 U }\\r\\n 2.2.2.2 MBFE发送给行内系统
域 类 版本 域名 BeginFlag VersionID 含义 起始标识 版本号 报文发起人 发送系统号 报文接收人 接收系统号 报文发起日期 报文发起时间 格式类型 报文类型代码 通信级标识号 位置 0 3 5 17 21 33 37 45 51 54 74 长度 3 2 12 4 12 4 8 6 3 20 20 类型 x n x x x x d t x x x 属性 M M M M M M M M M M M 说明 {H: 01 102100099998 IBPS 103100022226 IBPS 20100501 094508 XML ibps.101.001.01 A1234B1234C1234D1234 00000000000000000000 3 D }\\r\\n 发 OrigSender 起 方 OrigSenderSID 接 OrigReceiver 收 方 OrigReceiverSID OrigSendDate OrigSendTime StructType 报文描述 MesgRefID MesgPriority MesgDirection Reserve EndFlag MesgType MesgID 通信级参考号 报文优先级 报文传输方向 （保留域） 结束标识 94 114 115 116 125 20 1 1 9 3 x n X x x O M M O M 2.3
报文体格式
报文体为XML格式，使用
网上支付跨行清算系统报文格式标准
... ... 注：namespace_string的值为该报文所对应的schema文件中定义的名字空间值。 2.3.1 格式检查
每个报文都有对应的schema文件用来进行报文格式检查，schema文件名称与报文编号相同，使用ISO20022标准的报文则采用ISO20022发布的schema文件。
参与机构发送报文给IBPS时，应将待发送往帐报文的报文体使用XML Schema进行格式检查，检查通过后，才能提交给PMTS-MBFE。
参与机构从PMTS-MBFE接收报文后，应使用XML Schema对收到的来帐报文的报文体进行格式检查，检查通过后，才能提交给行内系统进行业务处理。对检查失败的且应返回应答报文或回执报文的来帐报文，如报文可以解析并能获取返回应答报文或回执报文需要的报文数据时，返回“已拒绝”应答报文或回执报文，否则丢弃该报文，留待日终对账解决。 2.4
数字签名
2.4.1 加签要素和数字签名编制
IBPS使用数字签名保证业务数据的可靠性和防抵赖性。数字签名由业务发起方编制，IBPS-NPC和业务接收方核验。
IBPS编制业务数字签名的做法如下：
（1）按报文中业务要素出现的顺序，将各加签业务要素值后附“|（竖线）”后顺序拼接成签名要素串；例如“102100033452|CNY1234.56|ibps.100.001.01|”。最后一个业务要素值后面也有“|（竖线）”；取金额字段（含货币符号属性）作为加签要素时，应包括该金额对应的货币符号，例如CNY1234.56。其中，金额必须包含小数点和两位小数。
（2）使用本行的数字证书（私钥）对签名要素串签名，签名的校验算法使用SHA1WithRSA算法；
（3）将签名值使用BASE64转码后填写到报文的数字签名域。
各加签业务要素值，指业务要素对应的XML报文域数据，包括该域除XML标签外的所有字符，无须补齐位数，并截断两端空白字符。空白字符，指空格（0x20）、制表(0x09)、回车(0x0d)、换行(0x0a)四个字符。
如加签业务要素没有在报文中出现，或其值为全空白（即截断两端空白字符后长度为0），则拼接签名要素串时忽略该加签业务要素及其附加的“|”(竖线)。
2.4.2 数字证书绑定通知报文的数字签名核验标准
IBPS数字证书绑定通知报文使用带签名者证书（公钥）的数字签名（PKCS#7，分离式带证书数字签名，即DetachedSign）。核验该数字签名的要求如下：
（1）数字签名核验成功，并获取签名者证书（公钥）；
（2）检查签名者证书，应是CFCA签署且证书合法、有效，应使用证书注销列表文件（CRL）进行证书是否已被注销的检查；
（3）检查签名者证书的DN域，应包含OU=CNAPS（忽略大小写），且CN域应包含签名者的行号；
核验通过后，IBPS-NPC和各接收参与机构应存储签名者的证书公钥数据，并作为后续验证该参与机构发送的非数字证书绑定通知报文的数字签名的证书。
中国人民银行清算总中心 第32页
网上支付跨行清算系统报文格式标准
2.4.3 非数字证书绑定通知报文的数字签名核验标准
IBPS非数字证书绑定通知报文使用无签名者证书（公钥）的数字签名（PKCS#1，裸签）。核验该数字签名的要求如下：
（1）按报文格式标准中的加签要素组织签名要素串； （2）获取发起参与机构绑定的证书公钥；
（3）使用该公钥、签名要素串、数字签名，核验数字签名的合法性，应使用证书注销列表文件（CRL）进行证书是否已被注销的检查。
核验通过后，IBPS-NPC和各接收参与机构应存储业务及其签名备查。
2.4.4 特殊字符的说明
IBPS数字签名经BASE64转码后放置到报文的数字签名域，由于BASE64转码后的值可以包含回车符（建议每输出76个字符后插入回车符），因此在把数字签名加入到报文中时，应避免使用Dom的API操作，否则Dom的API可能会对数字签名中的特殊字符进行转义，从而导致接收方核签失败。例如，Dom API将数字签名的回车符转换为“ ”。 2.5
报文编号
报文编号规则为“xxxx.nnn.nnn.nn”
表示系统编号，四位小写字母 表示报文编号，三位数字
预留， 固定填写001 版本号， 两位数字 2.5.1 系统编号 序号 业务类型名称 1. 清算账户管理系统 2. 大额实时支付系统 3. 小额批量支付系统 4. 公共控制与管理系统 5. 支付管理信息系统 6. 网上支付跨行清算系统 7. 全国支票影像交换系统 8. 电子商业汇票系统 2.5.2 报文编号 序号 业务类型名称 1. 支付类业务 2. 信息类业务 3. 轧差清算类 4. 日终处理类 5. 运行控制类 6. 系统管理类 编号范围 100-199 300-399 600-699 700-799 800-899 900-999 系统编号 saps hvps beps ccms pmis ibps ncis ecds 中国人民银行清算总中心 第33页
网上支付跨行清算系统报文格式标准
2.6 其他约束
2.6.1 单个报文长度
提交给IBPS的单个报文长度应少于1M字节（按照1000*1000字节计算），超过该长度的报文将被PMTS-MBFE拒绝。
IBPS下发的报文一般限制在1M字节内，但业务明细下载应答报文包含了原报文及原报文的应答报文，可能突破1M字节，达到1-3M字节，因此建议接收者定义报文接收区大小应定义为4M，消息中间件的消息大小应为4M。
2.6.2 UTF-8的BOM问题
IBPS报文使用UTF-8编码，传输报文时，应注意报文中不能包含UTF-8编码的BOM header（即EF BB BF）。对带有BOM header的报文，系统将拒绝受理。
2.6.3 ISO20022报文说明
IBPS部分报文直接使用ISO20022标准定义的报文，并根据IBPS的特点进行了定制化，主要注意事项说明如下：
（1）如ISO20022报文栏位为强制项，而本系统无对应业务要素的，这些强制项栏位被保留，其填写要求参见报文的附加说明；
（2）如本系统业务要素在ISO20022报文中无合适栏位的，这些业务要素放置到ISO20022业务含义并不贴切的栏位中。此时不应从ISO20022报文域的英文名解读该域的业务含义，而应以中文域名为准。例如，数字签名域放置到ISO20022的EmailAddress栏位。
（3）受ISO20022报文栏位要素的排列限制，使用ISO20022报文的各业务要素排列顺序与我国业务习惯有些差异，请以报文规定为准。
（4）报文表格中“属性”字段格式为[x..y]，其中x表示该字段最少出现次数，y表示该字段最多出现次数；例如[1..10]表示该字段最少出现1次，最多出现10次。
中国人民银行清算总中心 第34页