人民银行第二代支付系统互联规范、报文交换标准概要介绍(开发座谈会(第一期)版).ppt

人民银行第二代支付系统互联规范、报文交换标准概要介绍(开发座谈会(第一期)版).ppt

《人民银行第二代支付系统互联规范、报文交换标准概要介绍(开发座谈会(第一期)版).ppt》由会员分享，可在线阅读，更多相关《人民银行第二代支付系统互联规范、报文交换标准概要介绍(开发座谈会(第一期)版).ppt（43页珍藏版）》请在冰点文库上搜索。

第二代支付系统互联规范、报文交换概要介绍,中国人民银行清算总中心支付系统开发中心,主要内容,第一部分：

第二代支付系统互联规范介绍第二部分：

第二代支付系统报文交换标准介绍第三部分：

有关问题说明,第二代支付系统互联规范介绍,第二代支付系统互联规范共由13个文档组成，每个文档适用于不同类型的系统参与者与第二代支付系统互联。

注意：

选择与本参与机构的类型相适合的文档进行阅读。

这13个文档不是每个都对本行有用，不需要全部。

行内系统不改造的参与者如何接入二代支付系统？

仍通过现有的一代大、小额支付系统前置机（即MBFE）接入。

行内系统不需要调整与修改，与支付系统之间仍收、发原一代支付系统的CMT/PKG格式报文。

完成行内系统改造后的参与者如何接入二代支付系统？

一代支付系统建设过程中，大额、小额等每一个业务系统都建设了一套相对独立的从参与者到CCPC再到NPC的应用逻辑，既要负责业务需求和功能的实现，也要负责报文收发和节点间的传输。

从实际情况来看，关于报文的收发和在节点间的传输需求，对各个业务系统而言，基本都是一致的，因此各系统分别去实现这些功能属于重复。

为便于向参与者提供灵活、可靠的接入服务，二代支付系统建设中，提出了“报文传输与业务处理分离”的思路，通过构建一个高可用的支付报文传输平台（PaymentMessageTransmissionSystem，简称PMTS），实现参与者与支付系统之间安全可靠的支付业务报文传递。

从支付报文传输平台（即PMTS）的角度来看，各类金融信息系统均可接入到该平台，通过该平台提供的服务来发送/接收跨行的报文；支付系统处理中心也只是接入到PMTS的一个信息系统，从PMTS中获取报文，进行处理和转发。

构建支付报文传输平台后，支付系统与参与者和其他外围系统的关系如下图所示：

图中的CNAPS2，即第二代支付系统包含了大额支付系统、小额支付系统、网上支付跨行清算系统、清算账户管理系统、公共数据管理系统等业务系统支付报文传输平台（即PMTS）负责完成第二代支付系统与外部参与者间的支付业务报文传输，是整个第二代支付系统的一个基础服务平台。

PMTS的功能与特点,支付报文传输平台（PMTS）作为一个连接支付系统和参与者的渠道，是一个高可用的端到端报文传输平台，其任务是保证支付系统与各个参与者之间的高可靠性的报文传输。

其业务功能主要是以下几点：

（1）传输安全：

保证支付报文传输过程中端到端的数据完整性；

（2）报文校验：

对收到的支付报文要进行格式校验，不满足格式要求的给予拒绝处理，从而实现对参与者故障的有效隔离。

参与者故障中报文级的错误可以在支付报文传输平台得到屏蔽，不影响业务处理系统（同时业务系统也支持对参与者设置故障状态，限制该参与者业务的发起与接收）。

（3）智能路由：

对于满足格式要求的，根据目标地址自动选择传输路径，确保最终送达支付系统以及/或者参与者。

该平台支持参与者多点接入路由的灵活调整，如在某些节点发生故障的时候，该平台能够根据调整后的路由选择其他节点继续进行报文传输处理。

支付报文传输平台具备如下主要特性：

（1）与业务系统无关：

支持大额、小额和网银系统的各类报文，未来可扩展支持其他支付清算系统的报文；

（2）兼容多种报文格式：

支持CMT/PKG/XML报文，并可以根据需要方便扩展；（3）高可用性：

系统要具有较好的容错机制，在部分节点失效时能继续提供报文传输服务。

PMTS-MBFE参与者接入端软件,PMTS-MBFE是PMTS系统的一部分，物理部署于参与者端。

它是连接支付系统和参与者行内系统的桥梁，是支付系统的重要组成部分。

PMTS-MBFE的主要功能包括报文转发、报文格式检查、安全管理等，即对参与者行内系统提交的报文和支付系统发来的报文进行相应的报文格式检查，并根据系统安全规范实现报文的可靠传输和交换。

参与者接入端软件不参与业务相关处理，如业务合法性检查、重账检查、业务核对等，以降低其运行维护复杂度。

参与者接入端软件只提供直连接入功能，不提供业务录入、来帐打印等间连接入功能。

（这点与一代大、小额MBFE不同）参与者接入端软件应用软件由人民银行负责开发，免费提供给系统参与者使用，物理部署在系统参与者端，并由系统参与者进行系统维护与管理。

参与者接入端软件的部署,系统参与者使用参与者接入端服务器通过支付系统专用网连接第二代支付系统，参与者接入端服务器上部署参与者接入端软件，物理摆放在系统参与者系统内部，使用消息中间件和支付系统交换业务报文。

部署示意图如右：

PMTS-MBFE集群方式部署建议,PMTS-MBFE集群配置方式支持主备模式冷备模式热备模式并行模式并行模式并行冗余模式,主备模式,冷备模式：

主用直联前置机与备用直联前置机不共享存储设备，配置为相同的系统配置、网络IP等等，正常情况下，主用直联前置机与CCPC两台服务器连接，负责完成报文收发。

而备用直联前置机不启用。

如右图：

当主用直联前置机发生故障时，可即时启用备用直联前置机，接入网络，进行报文的收发。

主备模式,热备模式：

主用直联前置机与备用直联前置机共享存储设备。

主用直联前置机与CCPC两台服务器连接，负责完成报文收发。

备用直联前置机同时保持与CCPC服务器的连接，具备与支付系统接入网关的报文收发链路，但正常情况下不启用报文收发功能如右图：

当主用直联前置机发生故障时，可即时启用备用直联前置机的报文收发功能，将其切换为主用直联前置机，同时将原主用直联前置机置为备用模式。

并行模式,并行模式下，两台（或多台）直联前置机均与支付系统接入网关连接，同时在线，完成报文收发。

当任一直联前置机发生故障时，即单点故障情况下，报文收发功能不受影响。

部署示意图如下：

并行冗余模式,并行接入两个接入网关，1个作为主用，另1个作为备用。

主用接入网关故障情况下，可快速切换到备用接入网关（预计不超过30分钟）,行内对于多台PMTS-MBFE可用性及负载情况的探测,当行内部署台或者更多的PMTS-MBFE时，可以通过向PMTS-MBFE发送报文了解这些PMTS-MBFE的可用性及负载情况。

1、可用性判断标准：

发送探测请求报文后，超过行内规定的时间无回应报文2、负载情况的判断标准：

探测回应报文中有一个“负载系数”的值，表示该PMTS-MBFE的压力（即待处理的业务报文数量），0时表示无压力，值越大则负载越大。

参与者接入端软件的数据交换,参与者通过参与者接入端软件与支付系统进行报文交换示意图如右所示：

完成行内改造的参与者接入前的工作,需完成以下两项工作：

1、按照第二代支付系统直联前置机配置指引，准备前置机运行环境，部署PMTS参与者接入端软件；2、按照第二代支付系统报文交换标准，完成“互联规范”中要求的有关支付系统业务报文（含一代报文和二代报文，具体参考“互联规范”4.6节）的开发。

与第一代支付系统的兼容,为了实现第一代支付系统向第二代支付系统的平滑过渡，第二代支付系统投产后相当一段时间内，将既支持参与者通过行内系统改造采用第二代支付系统报文标准接入，也支持参与者不进行改造，继续采用原一代报文交换标准接入。

因此，完成行内系统改造的参与者加入二代支付系统时，需要在支持二代支付系统报文标准（即XML格式报文）的同时，支持部分一代支付系统报文标准（即CMT/PKG格式报文），以实现与未完成行内系统改造的参与者间进行业务往来。

系统互联的三种数据格式,1、第二代支付系统新增报文（XML格式）2、原第一代支付系统报文（CMT/PKG格式）3、基础数据文件（XML格式的文件）,1、第二代支付系统新增报文,为便于系统参与者接入支付系统，降低报文转换复杂性，二代支付系统新增报文交换标准采纳了部分ISO20022报文标准作为支付系统的报文，并参照ISO20022规范开发了其他报文，全部报文均采用XML格式描述。

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

行内系统发送报文给支付系统时，应将待发送的往帐报文使用XMLSchema（随报文标准一起下发的）进行格式检查，检查通过后，才能提交给参与者接入端软件。

行内系统从参与者接入端软件接收报文后，行内系统应使用XMLSchema对收到的来帐报文进行格式检查，检查通过后，才能提交给行内系统进行业务处理。

对检查失败的来帐报文，行内业务人员可以选择主动联系支付系统业务管理人员，对异常来账报文做补发处理；也可选择行内系统直接丢弃，留待日终对账解决。

详细报文交换标准参考第二代支付系统报文交换标准。

2、原第一代支付系统报文交换标准,原一代支付系统的CMT/PKG报文的格式保持“不变”。

详细报文交换标准参考二代支付系统报文交换标准。

关于格式保持不变，注意：

原一代支付系统中，参与者行内系统是调用人民银行发布的API与支付系统的MBFE进行通讯的，当报文从行内系统发出时，如图：

报文1实际上经过API后转换为报文2。

两个报文略有不同，主要有三点不同：

1、报文头长度不同。

报文1使用的是所谓的“短报头”。

而报文2使用的是所谓的“长报头”。

2、密押字段。

对于需要加、核密押的报文，报文1中是不含密押字段的。

而报文2经过API后增加了密押字段。

3、报文尾。

大额报文，报文1是不含报文尾的，报文2含报文尾。

而对于行内系统调用API接收报文时，与上面提到的三点不同相反。

3、基础数据文件,为便于各系统参与者将二代支付系统的各类基础数据导入行内系统或者进行其他处理，二代支付系统提供了基础数据文件。

（例如行内准备测试环境，需要一套完整的支付系统参数数据，则需要对这个基础数据文件进行处理后，导入到自身系统中）。

基础数据文件的格式是XML的。

这些数据文件的格式标准具体参考二代支付系统报文交换标准文档集中的二代支付系统基础数据文件格式标准。

报文传输的可靠性约束,为保证系统间报文传输的可靠性，行内系统和支付系统均应在接收到对方发送的报文时给予通信级报文接收确认，该报文使用“通信级确认报文”，具体参见二代支付系统报文交换标准。

参与者通信软件发送报文给支付系统时，应标记该报文的发送状态为“待确认”，待收到支付系统返回的通信级确认报文后，修改状态为“已确认”。

对没有收到通信级确认报文的往帐报文，应视为没有发送给支付系统，参与者通信软件可以再次提交该报文给支付系统。

（注意：

如未收到通信级确认，但收到了业务应答，则应以业务应答为准更新业务状态）参与者通信软件收到支付系统转发的来帐报文时，应返回通信级确认报文给支付系统。

对没有收到通信级确认报文的来帐报文，支付系统视为没有发送给参与者，可能会再次发送该报文给参与者。

参与者通信软件应提供来帐报文的重复报文检测机制，检查来帐报文报头的报文标识号，对报文标识号重复的报文，应视为重复报文，可以直接丢弃。

支付系统和参与者均不应对对方返回的通信级确认报文再返回通信级确认报文。

报文权限控制说明,为了保证业务处理的安全可靠，系统参与者需对收发的业务报文进行权限控制。

对于无权发送的业务报文应禁止发出。

对于参与者与参与者之间的业务，未完成行内改造的一代参与者之间使用CMT/PKG格式报文进行数据交换；完成行内改造的二代参与者之间使用新的XML格式报文进行数据交换；一代参与者与二代参与者之间使用CMT/PKG格式报文进行数据交换。

对于参与者与NPC之间的业务，例如业务状态查询、登录、退出等等，一代参与者与NPC之间使用CMT/PKG格式报文进行数据交换；二代参与者与NPC之间使用XML格式报文进行数据交换。

小提示：

如何判断一个参与者已经完成改造，即支持XML格式的报文？

业务权限变更通知报文当NPC下发的权限中有这样一条权限时，说明“机构A”已经完成行内系统改造。

数字签名机制,对于二代支付系统新增的报文，为了保证系统参与者与支付系统之间关键业务数据可靠性和不可抵赖性，系统参与者发起需加、核签业务报文时，应对其加编数字签名，而接收此类报文时，需核数字签名。

对业务量较大的参与者，可以考虑在行内系统部署专用的硬件签名服务器，以实现快速的编签、核签处理。

对业务量较少的参与者，可以不必部署专用的硬件签名服务器，而使用软件加、核签方式（例如：

可以采用OpenSSL实现）为验证签名者证书的有效性，系统参与者应自行从CFCA网站获得CRL列表，导入系统参与者行内系统，并以CRL列表为准核验数字证书的合法性，支付系统不提供CRL下发与广播功能。

数字证书与系统参与者绑定,支付系统用以编制业务签名的数字证书，以系统参与者为单位申请和使用，系统参与者向当地CCPCRa申请证书，并从CFCA网站下载证书后，应及时向支付系统发送“数字证书绑定通知报文”报文建立参与者和新证书的绑定关系，支付系统受理该报文并处理成功后，广播该报文给全部系统参与者，各系统参与者接收该报文，并从该报文获取系统参与者的数字证书公钥信息，存档以便后续验证数字签名使用。

系统参与者进行数字证书绑定成功后才可以发起业务报文，其他系统参与者接收到业务报文时需验证数字证书与业务发送参与者的绑定关系和数字签名的合法性。

第一代支付系统密押/密钥,过渡期间，二代参与者在与一代参与者间进行业务往来时，需按照一代报文标准在行内系统对往账业务报文进行加押，对来账业务报文进行核押，编、核押规则参考二代支付系统报文交换标准文档集中的一代支付系统报文编核押规则。

编、核押设备仍可使用原一代支付系统的密押服务器/密押卡，编、核押接口API可联系密押设备生产厂家获取。

但需注意，区别于一代支付系统中参与者与支付系统交互采用地方押、全国押的三级密钥体系式，二代参与者与支付系统交互需使用两级密钥体系。

上线切换时，人民银行将统一更换二代参与者密押服务器/密押卡的密钥。

对于通存通兑业务PIN口令的加、解密操作，也可沿用一代支付系统的密押服务器设备，但需对密押服务器的配置进行升级，以支持与NPC直接交换密文的两级密钥体系。

具体参见第二代支付系统直联前置机配置指引。

第二代支付系统报文交换标准,基本术语,业务要素业务要素是业务数据项的抽象名称，是业务的基本组成单位，如银行账户的账号。

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

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

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

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

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

根报文域报文使用XML文档标准，该文档的根节点称为根报文域，标签固定为。

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

报文格式概述,字符集和编码报文采用Unicode字符集，UTF-8编码方式。

报文结构系统使用XML报文传输业务数据。

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

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

报文头、数字签名域和报文体共同构成一个完成的报文，之间没有任何字符间隔。

数字签名域,数字签名域采用变长数据格式，格式如下：

报文示例数量,共有150条报文示例文件每条报文对应一条报文示例文件三点注意事项：

1、报文示例文件中只含报文体，不含报文头和数字签名域。

报文头的机构是定长格式，按照报文标准可以很方便的理解。

2、报文示例文件仅供帮助理解报文结构，其中的内容不一定正确，例如行号、账号、户名等都是虚构的，不真实。

3、大家可以使用工具软件（例如XML-SPY）自带的功能，根据schema文件产生报文，便于行里系统开发时的各项测试。

第一代支付系统报文标准,1、大额支付系统MESG报文格式汇总v2.3.22、小额支付系统报文格式标准V2.3两点注意：

1、第一代支付系统报文标准为已经发布的标准，为便于参与机构获取本次附带下发，并未对原文档的内容进行修改。

2、截至2010年11月11日大额系统报文标准最新版本为V2.3.2小额系统报文标准最新版本为V2.3如果大家自己找资料来看的话，注意不用看错了版本。

第一代支付系统报文编核押规则,描述第一代支付系统CMT/PKG格式报文的编、核押规则，系统参与者需按照此规则对第一代支付系统CMT/PKG格式报文的编、核押处理。

对于那些需要编押的报文，从行内系统发出时需要编密押。

对于那些需要核押的报文，行内系统接收到以后，需要核密押。

（以前一代时，行内系统是不做编、核密押的，这点不同）,有关问题说明,支票圈存业务办理,1、一代参与者继续使用原有规则；2、二代参与者连接PMTS-MBFE办理支票圈存业务,注：

过渡期内：

支票圈存行与一代参与机构之间发起的支票圈存业务需继续采用一代规则；与二代参与机构之间进行业务往来时，支票圈存行在发起与支票圈存相关的“支票圈存管理报文”、“实时信息冲正申请报文”和“通讯级确认报文”时，报文头的“保留域Reserve”字段第一位填写一个大写英文字母F；支票付款人开户行在发起“支票圈存管理应答报文”、“实时信息冲正应答报文”和“通讯级确认报文”时，报文头的“保留域Reserve”字段第一位填写一个大写英文字母F。

UMTS-MBFE升级为PMTS-MBFE,商业银行在二代投产前，需将目前网上跨行支付系统使用的UMTS-MBFE升级为PMTS-MBFE，但报文接口保持不变；PMTS-MBFE支持同时收发跨行网银、大小额支付等业务系统报文，但参与者也可根据自身实际情况分开部署；未来，PMTS-MBFE的应用软件版本将会统一更新、统一维护；,通讯层重账判定规则,通过报文头的数据判定报文发起人（OrigSender）报文发起日期（OrigSendDate）通信级标识号（MesgID）唯一确定一个报文，该三项重复的报文作为通信级重复报文；,业务层重账判定规则,报文标识号唯一标识一个参与机构发起的一个报文，由报文发起参与机构编制（支付类报文、信息类报文等各类报文混编）。

CNAPS2使用发起参与机构号+报文标识号作为重复报文的检查标准。

对两者均相同的报文，CNAPS2视为重复报文。

各参与机构应按相同的规则进行重复报文检查。

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

CNAPS2规定报文标识号/明细标识号的编号规则为：

当前工作日期（8位数字）+报文序号（8位数字，不足8位的，前补0）组成，共16位长度。

例如2010020200000001。

公共类报文下发方式,目前，业务标准中对部分CCMS报文有明确说明：

发送和接收系统号均填写CCMS。

此类报文包括行名行号、数字证书绑定通知等报文；对于数字证书绑定通知报文，跨行网银系统为01版，大小额系统为02版，NPC将同时支持受理两种不同版本的报文，参与者只需通过其中一个报文绑定成功即可；公共类报文的包含的数据信息，大、小额等业务系统均需使用，但支付系统NPC只给参与者下发一份，参与者接收到后需要根据自身系统整合情况将数据共享或者拷贝多份使用。