1第二代支付系统报文交换标准概述

内部资料，注意保管
第二代支付系统报文交换标准
【概述分册】
（版本1.4.2）
中国人民银行清算总中心
2013年05月
注：变化状态：A—增加，M—修改，D—删除
目录
修改记录 (3)
1报文交换标准概述 (10)
1.1术语说明 (10)
1.2业务标准 (10)
2报文格式概述 (37)
2.1报文结构 (37)
2.2报文头格式 (37)
2.3数字签名域 (40)
2.4报文体格式 (41)
2.5报文编号 (41)
2.6其他约束 (42)
3数据类型 (45)
4公共业务组件 (51)
4.1业务头组件<G RP H DR> (51)
4.2批量包组头组件<PKGG RP H DR> (52)
4.3原报文主键组件<O RGNL G RP H DR> (53)
4.4原业务主键<O RGNL T X> (54)
4.5业务应答信息组件<R SPN I NF> (55)
4.6NPC处理信息组件<NPCP RC I NF> (56)
4.7报文分片组件<P RTTN> (57)
4.8数据变更组件<C HNG C TRL> (57)
5附录 (59)
5.1附录一：参与者发起报文与系统状态对照表 (59)
5.2附录二：参与者发起报文处理状态对照表 (64)
5.3附录三：业务类型（业务种类）与拒绝代码对照表 (85)
5.4附录四：TAG码和报文标签对照表 (88)
5.5附录五：处理码及处理描述 (108)
修改记录
1报文交换标准概述
第二代支付系统（以下简称CNPAS2）报文交换标准采纳了部分ISO20022报文作为CNPAS2的报文，并借鉴ISO20022规范开发了其他报文，全部报文均采用XML格式描述。

其中，对采纳使用的ISO20022报文，CNPAS2根据实际情况，进行了必要的格式约束。

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行别代码
为标识各参与者的类别属性，支付系统为每类参与者分配一个标识号。

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

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

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

1.2.3城市代码号
城市代码号由4-6位数字组成。

城市代码号是4位数字的，规则沿用一代支付系统的城市代码；是6位数字的，规则为在4位数字基础上前补足两个0组成6位数字，如北京表示为001000，上海表示为002900。

以参与者实际获取的基础数据中的城市代码号为准。

1.2.4节点代码
支付系统为国家处理中心和每个城市处理中心分配一个标识号以识别该节点。

该标识号由四位定长数字组成，编码结构如下：
nnnn
(1)
1.2.5参与者行号
根据第一代支付系统的规则，支付系统为每个参与者（含直接参与者、间接参与者、特许直接参与者）分配一个标识号以标识该参与者。

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

同时为了支持中国人民银行总行发布的《金融机构编码规范》中的14位金融机构编码的需要，第二代支付系统报文标准中将“参与者行号”字段设置为最长14位字符长度，即可支持第一代支付系统的12位长度行号，也可支持14位金融机构编码。

目前暂填写和使用第一代支付系统的12位长度行号。

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

全国一点接入的参与机构，其客户账号应在参与机构内部全国唯一；以省为单位接入的参与机构，其客户账号在参与机构内部省内唯一。

1.2.7明细标识号
在CNAPS2的同一个子系统内，明细标识号唯一标识一个参与机构发起的一笔明细业务，由报文发起参与机构编制，规则为“当前工作日期（8位数字）+报文序号（8位数字，不足8位的，左补0）组成，共16位长度”。

在同一个批量报文中，CNAPS2使用｛CNAPS2子系统号+发起行（特指每笔明细中发起行，在贷记业务中发起行为付款行，在借记业务中发起行为收款行）+明细标识号｝作为明细业务重账检查标准。

1.2.8报文标识号
在CNAPS2的同一个子系统内，报文标识号唯一标识一个参与机构发起的一个报文，由报文发起参与机构编制，对于需要业务层面进行分片的大报文来说，多个片段报文使用不同的“报文标识号”。

报文标识号的编号规则为：当前工作日期（8位数字）+报文序号（8位数字，不足8位的，左补0）组成，共16位长度，例如2010020200000001。

注意：由于过渡期内二代参与者既可以发出XML格式报文，也可以发出CMT/PKG格式报文，在CMT/PKG格式报文中存在8位数字“报文序号/包序号”（简称“报文序号1”），在XML格式报文中存在“报文标识号”后8位报文序号（简称“报文序号2”）。

为便于系统处理，同一发起参与机构发出报文中“报文序号1”和“报文序号2”应不重复。

1.2.9业务层面报文重账检查规则
CNAPS2使用｛CNAPS2子系统号+发起参与机构+报文标识号｝三项作为业务层面报文重账的检查标准。

其中“CNAPS2子系统号”指报文头中的“发送系统号”，“发起参与机构”指报文体中的名称为“发起参与机构”的要素，如某个报文中不存在名称“发起参与机构”的要素，则见报文的报文说明部分。

注：对于二代“即时转账报文”，当借贷双方为同一直接参与机构时，该直接参与机构会收到两条三要素相同的二代“即时转账报文”，其中“借贷标识”不同。

1.2.10端到端标识号
端到端标识号用来在业务受理机构内部区分客户业务的唯一标识，由不超过35位数字或字母组成，并在客户发起业务委托时，由业务受理机构产生。

1.2.11业务类型编码
支付系统为各系统处理的各种业务分配一个唯一的标识号以标识该种业务。

该业务类型号使用4位字母或数字，编号结构如下：
X XXX
(1) (2)
说明：
（1）业务性质编码。

A 普通贷记业务；
B 普通借记业务；
C 实时贷记业务；
D 实时借记业务；
E 定期贷记业务；
F 定期借记业务；
G 即时转账业务；
H 资金清算类业务；
J 清算账户及流动性管理类业务；
K 业务管理类业务；
M 信息业务；
（2）业务序号：相同业务性质的各种业务按顺序编号。

1.2.12业务种类编码
业务种类赋予五位业务种类代码，取值范围为“00000～99999”，编码规则如下：编码结构： X XX XX
（1）（2）（3）
说明：
（1）定义范围。

1位数字，0人民银行总行统一规定的业务种类；9人民银行各分支行自定义的业务种类；“1－8”保留。

（2）类别号。

2位数字，表示业务的经济属性。

（3）序号。

2位数字，顺序编号。

1.2.13报文与业务类型对照表
1.2.14业务类型与业务种类对照表
1.2.15港澳中银与支付系统往来业务的特殊说明
（1）普通来往业务的规定：
a)港澳中银与内地银行之间允许往来的业务种类会按照人民银行的有关文件进行特
殊设置；
b)当为跨境支付的“个人跨境汇款”和“个人跨境退款”时收付款人是必须为同名客
户；
c)港澳清算行和参加行向内地银行发送汇款业务时付款人当天累计汇款金额必须低
于当日累计汇款金额上限，收款人在当天累计收款金额必须低于当日累计收款金
额上限；
d)港澳清算行和参加行接收汇款时收款人在当天累计收款金额是必须低于当天累计
收款金额上限；
（2）退汇业务的规定：
a)发起退汇业务时必须与原业务的时间进行匹配，必须在规定的匹配时间之内；
b)退汇业务同名户检查,收款人及收款行必须与原业务的付款人及付款行相同,
付款人及付款行必须与原业务的收款人及收款行相同；
c)退汇业务与原业务金额匹配检查，退汇业务的支付金额≤原业务金额；
1.2.16二代小额支付系统业务组包规则
a)普通贷记业务、普通借记业务、实时贷记业务、实时借记业务、CIS通用回执业
务、信息类业务按接收清算行分别组包。

b)定期贷记业务和定期借记业务根据业务类型号按接收清算行分别组包。

支付系统
为每一业务类型分配唯一的标识代码。

业务种类是标识每笔明细业务的附加性质，
如定期贷记或定期借记业务的水费、电费、煤气费等，是对业务类型包括内容的
具体说明。

c)实时贷记业务包、实时借记业务包、实时代收业务包、实时代付业务包和实时信
息包每包限一笔。

d)借记业务按相同的回执期（T+N）组包。

e)集中代收付中心发起的批量代收业务，按同一收款人、同一业务类型号、同一发
起清算行、同一接收清算行、同一回执期限组包；批量代付业务按同一付款人、
同一业务类型号、同一发起清算行、同一接收清算行、同一回执期限组包。

（集
中代收付中心根据收（付）款单位分别组包更便于中心与收（付）款单位信息传
输服务，更符合业务开展实际情况。

）
f)借记回执包按原包组包，并附加成功或失败的信息。

1.2.17集中代收付业务最长处理期限
集中代收付业务最长处理期限用来控制集中代收付业务从发起到回执轧差整个业务处理流程最长时间的系统参数。

NPC自收到集中代收（付）信息包后，按照包内所列回执期限开始计时，按照T+N（N≥0）判断未轧差的集中代收（付）信息包是否超时。

当集中代收（付）业务在T+N日日切后仍未处理完成，系统自动撤销超期的集中代收（付）信息包和处于轧差排队的代收（付）回执包，NPC将该笔代收（付）信息包和代收（付）回执包状态变更为“已超期退回”，并通知集中代收付中心和收付款清算行。

集中代收付中心和收付款清算行收到超期撤销通知后，更改本地状态为“已超期退回”。

集中代收付业务最长处理期限由业务管理部门规定，通过CCMS设置并下发。

客户在集中代收付中心办理批量代收付业务时可在N值范围内（N≥0）进行选择。

1.2.18贷记业务最长处理期限
贷记业务最长处理期限用来控制贷记包（含普通贷记业务、定期贷记业务和CIS通用截留回执）从发起到轧差整个业务处理流程最长时间的系统参数。

NPC收到贷记业务包开始计时，按照T+N（N≥0）判断轧差排队的贷记业务是否超时。

当贷记业务包在T+N日日切后仍处于轧差排队，NPC自动撤销该笔排队业务并将该笔贷记业务包状态变更为“已超期退回”，并通知贷记业务发起方。

贷记业务发起方收到超期撤销通知后，更改本地状态为“已超期退回”。

贷记业务处理期限为系统参数，由业务管理部门规定并通过CCMS设置并下发。

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

该XML报文仅承载业务数据本身，并没有包含与报文流转、交换、路由等相关的信息，这些信息须附加到额外的数据块中传输，为处理的简便性，系统将这个额外数据块附加到业务报文的头部，称之为报文头，而将业务报文本身称为报文体。

报文头与报文体之间存放数字签名，称为数字签名域，数字签名域是可选的，对于需要加核数字签名的报文该域必须存在且按照要求填写数字签名内容，对于不需要加核数字签名的报文该域不出现。

报文头、数字签名域和报文体共同构成一个完成的报
（报文头）
2.2报文头格式
2.2.1报文头格式说明
节点间报头传输通信级数据，主要由版本标识、发起方、接收方、报文描述四个部分
说明：
１、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行内系统发送给MBFE
2.2.2.2MBFE发送给行内系统
2.3数字签名域
2.3.1数字签名域格式
数字签名域采用变长数据格式，格式如下：
2.3.2加签要素和数字签名编制
CNAPS2使用数字签名保证业务数据的可靠性和防抵赖性。

数字签名由业务发起方编制，CNAPS2-NPC和业务接收方核验。

CNAPS2编制业务数字签名的做法如下：
（1）按报文中业务要素出现的顺序，将各加签业务要素值后附“|（竖线）”后顺序拼接成签名要素串；例如“102100033452|CNY1234.56|beps.101.001.01|”。

最后一个业务要素值后面也有“|（竖线）”；取金额字段作为加签要素时，应包括该金额对应的货币符号，例如格式CNY1234.56；取含有TAG标识符字段（格式为“/tag/value”）时，只使用value部分的内容，不包括/tag/字符。

（2）使用本行的数字证书（私钥）对签名要素串签名，签名的校验算法使用SHA1WithRSA算法；
（3）将签名值使用BASE64转码后填写到报文的数字签名域。

各加签业务要素值，指业务要素对应的XML报文域数据，包括该域除XML标签外的所有字符，无须补齐位数，并截断两端空白字符。

空白字符，指空格（0x20）、制表(0x09)、回车(0x0d)、换行(0x0a)四个字符。

如加签业务要素没有在报文中出现，或其值为全空白（即截断两端空白字符后长度为0），则拼接签名要素串时忽略该加签业务要素。

2.3.3数字证书绑定通知报文的数字签名核验标准
CNAPS2数字证书绑定通知报文使用带签名者证书（公钥）的数字签名（PKCS#7）。

核验该数字签名的要求如下：
（1）数字签名核验成功，并获取签名者证书（公钥）；
（2）检查签名者证书，应是CFCA签署且证书合法、有效，应使用证书注销列表文件（CRL）进行证书是否已被注销的检查；
（3）检查签名者证书的DN域，应包含ou=CNAPS（忽略大小写），且CN域应包含签名者的行号；
核验通过后，CNAPS2-NPC和各接收参与机构应存储签名者的证书公钥数据，并作为后续验证该参与机构发送的非数字证书绑定通知报文的数字签名的证书。

2.3.4非数字证书绑定通知报文的数字签名核验标准
CNAPS2非数字证书绑定通知报文使用无签名者证书（公钥）的数字签名（PKCS#1，裸签）。

核验该数字签名的要求如下：
（1）按报文格式标准中的加签要素组织签名要素串；
（2）获取发起参与机构绑定的证书公钥；
（3）使用该公钥、签名要素串、数字签名，核验数字签名的合法性，应使用证书注销列表文件（CRL）进行证书是否已被注销的检查。

核验通过后，CNAPS2-NPC和各接收参与机构应存储业务及其签名备查。

2.3.5特殊字符的说明
数字签名经BASE64转码后放置到报文的数字签名域，由于BASE64转码后的值可以包含回车符，因此在把数字签名加入到报文中时，应避免使用Dom的API操作，否则Dom 的API可能会对数字签名中的特殊字符进行转义，从而导致接收方核签失败。

例如，Dom API将数字签名的回车符转换为“&#13;”。

2.4报文体格式
2.4.1格式检查
每个报文都有对应的schema文件用来进行报文格式检查，schema文件名称与报文编号相同，使用ISO20022标准的报文则采用ISO20022发布的schema文件。

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

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

对检查失败的来帐报文，如报文可以解析并能获取返回业务级回应报文需要的报文数据时，返回“已拒绝”回执报文，否则丢弃该报文，留待日终对账解决。

2.5报文编号
报文编号规则为“xxxx.nnn.nnn.nn”
表示系统编号，四位小写字母
表示报文编号，三位数字
预留，固定填写001
版本号，两位数字
2.5.1系统编号
2.5.2报文编号
2.6其他约束
2.6.1单个报文长度
单个报文长度大小应符合以下规定，超过该长度大小的报文将被MBFE拒绝。

2.6.2UTF-8的BOM问题
报文使用UTF-8编码，传输报文时，应注意报文中不能包含UTF-8编码的BOM
header（其对应的二进制为EF BB BF）。

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

2.6.3ISO20022报文说明
部分报文直接使用ISO20022标准定义的报文，并根据系统的特点进行了定制化，主要注意事项说明如下：
（1）如ISO20022报文栏位为强制项，而本系统无对应业务要素的，这些强制项栏位被保留，其填写要求参见报文的说明；
（2）受ISO20022报文栏位要素的排列限制，使用ISO20022报文的各业务要素排列顺序与我国业务习惯有些差异，请以报文规定为准。

（3）报文表格中“属性”字段格式为[x..y]，其中x表示该字段最少出现次数，y 表示该字段最多出现次数；例如[1..10]表示该字段最少出现1次，最多出现10次。

（4）采标报文中，对于支付系统应用到的栏位，应用软件一般会进行严格的格式检查；对于支付系统未应用到的栏位，参与者间可相互协商，根据实际情况自行填充，这些栏位只要符合ISO20022标准的约束且能通过Schema检查，支付系统会原封不动转发。

例如：涉及跨境支付业务，参与者在填写收、付款人开户行行号字段及当汇兑业务由境内客户发起时的“中介机构1”字段，可以在按照支付系统标准要求填写<MmbId>栏位的同时，填写ISO 20022标准报文中的<BIC>栏位，支付系统会原封不动转发。

2.6.4不同类型参与者之间使用一、二代报文应遵守的规则
不同类型参与者之间使用一、二代报文进行交互应遵循以下规则：
（1）一代参与者与二代参与者之间应使用一代报文。

（2）二代参与者之间可以使用一代报文或二代报文，系统应支持业务管理部门根据需要，对于二代参与者之间使用一代报文进行许可或禁止控制。

查询查复、借记业务回执等存在匹配关系的业务报文，参与者原则上必须使用同报文格式。

如查询行发起一代查询报文，查复行必须使用一代报文查复；参与者发起一代借记业务报文，接收方需使用一代借记回执报文回复；参与者发起二代借记业务报文，接收方需使用二代借记回执报文回复。

（3）二代参与者与NPC之间应使用二代报文。

2.6.5关于备注、备注2、附言、附言2的说明
增加备注2、附言2栏位的目的是为了能够适应跨境业务目前已经存在的标准，使得跨境业务转为支付系统业务时，相关的信息不会因为长度不够而丢失信息。

对于发起参与者，如果备注、附言栏位长度已经可以满足业务办理需要，则可以不填写备注2、附言2栏位。

对于接收参与者，可以把备注、备注2合并成一个字段，附言、附言2合并成一个字段进行处理。

2.6.6关于与ACS之间业务往来的特殊说明
当参与者向ACS发起业务时，接收清算行【借（贷）记行、接收直接参与机构】要素填写ACS直接参与者行号。

接收行【收（付）款人开户行、接收参与机构】等要素必须填写ACS辖属人行间接参与者行号，不能填写ACS直接参与者行号。

2.6.7关于报文标准中固定填写项的说明
为满足ISO20022标准的填写要求，CNAPS2报文标准包含了部分固定项。

对这些项，各参与者发起往帐时应按要求填写该项的值，接收来帐时应忽略这些项，不应对这些项进
行值合法性检查。

2.6.8关于“Unstructured”要素填写的说明
报文中“Unstructured”要素，备注栏中会出现类似“/xxx/value“的说明，其中/xxx/表示该业务要素的唯一编码，values表示该要素的内容，例如“票据日期”要素在报文中填写的方式为“<Ustrd>/C14/2010-05-01</Ustrd>”，要素的数据类型指value的数据类型，例如“票据日期”的数据类型为ISODate，指/C14/后的value为日期型。

“Unstructured”要素需按报文结构中定义的顺序出现，商业银行需要以/xxx/作为取值依据。

3数据类型。