《第二代支付系统互联规范、报文交换标准培训材料.ppt》由会员分享，可在线阅读，更多相关《第二代支付系统互联规范、报文交换标准培训材料.ppt（70页珍藏版）》请在三一办公上搜索。
1、第二代支付系统互联规范、报文交换标准培训,中国人民银行清算总中心 支付系统开发中心,主要内容,第一部分：第二代支付系统互联规范第二部分：第二代支付系统报文交换标准,第二代支付系统互联规范,主要内容,互联规范的组成参与者与二代支付系统互联概述参与者与二代支付系统系统互联详述系统互连的安全说明,1、第二代支付系统与城市商业银行银行汇票处理系统互联规范本文档适用于城市商业银行银行汇票处理系统与第二代支付系统互联。2、第二代支付系统与电子商业汇票系统互联规范本文档适用于电子商业汇票系统（即Electronic Commercial Draft System，简称ECDS）与第二代支付系统互联。3、第二
2、代支付系统与非金融支付服务组织系统互联规范本文档适用于非金融支付服务组织与第二代支付系统互联，例如代收付中心等非金融支付服务组织。4、第二代支付系统与港澳中银系统互联规范本文档适用于中国银行香港分行和澳门分行与第二代支付系统互联。5、第二代支付系统与国库会计数据集中系统互联规范本文档适用于国库会计数据集中系统（即TCBS）与第二代支付系统互联。6、第二代支付系统与境内外币支付系统互联规范本文档适用于境内外币支付系统（即China Foreign eXchange Payment System，简称CFXPS）与第二代支付系统互联。,第二代支付系统互联规范共由12个文档组成，每个文档适用于不同类
3、型的系统参与者与第二代支付系统互联。,7、第二代支付系统与商业银行行内系统互联规范本文档适用于商业银行参与机构与第二代支付系统互联。8、第二代支付系统与支付信用信息查询系统互联规范本文档适用于支付信用信息查询系统（即Payment Credit Information Inquiry System，简称PCIS）与第二代支付系统互联。9、第二代支付系统与中国外汇交易系统互联规范本文档适用于中国外汇交易系统与第二代支付系统互联。10、第二代支付系统与中国银联综合业务系统互联规范本文档适用于中国银联综合业务系统与第二代支付系统互联。11、第二代支付系统与中央银行会计核算数据集中系统互联规范本文档适
4、用于中央银行会计核算数据集中系统（即ACS）与第二代支付系统互联。12、第二代支付系统与中央债券综合业务系统互联规范本文档适用于中央债券综合业务系统与第二代支付系统互联。,第二代支付系统互联规范共由12个文档组成，每个文档适用于不同类型的系统参与者与第二代支付系统互联。,主要内容,互联规范的组成参与者与二代支付系统互联概述参与者与二代支付系统系统互联详述系统互连的安全说明,如何接入？,一代支付系统建设过程中，大额支付系统、小额支付系统等每一个业务系统都建设了一套相对独立的从参与者到CCPC再到NPC的应用逻辑，既要负责业务需求和功能的实现，也要负责报文收发和节点间的传输。从实际情况来看，关于报
5、文的收发和在节点间的传输需求，对各个业务系统而言，基本都是一致的，因此各系统分别去实现这些功能属于简单重复。为便于向参与者提供灵活、可靠的接入服务，二代支付系统建设中，提出了“报文传输与业务处理分离”的思路，通过构建一个高可用的支付报文传输平台（Payment Message Transmission System，简称PMTS），实现参与者与支付系统之间安全可靠的支付业务报文传递。从支付报文传输平台的角度来看，各类金融信息系统均可接入到该平台，通过该平台提供的服务来发送/接收跨行的支付信息（即报文）；支付系统也只是接入到支付报文传输平台的一个信息系统，从支付报文传输平台中获取报文，进行处理和
6、转发。,构建支付报文传输平台后，支付系统与参与者和其他外围系统的关系如下图所示：,图中的CNAPS2，即第二代支付系统包含了大额支付系统、小额支付系统、网上支付跨行清算系统、清算账户管理系统、公共数据管理系统等业务系统支付报文传输平台（即PMTS）负责完成第二代支付系统与外部参与者间的支付业务报文传输，是整个第二代支付系统的一个基础服务平台。,PMTS的功能与特点,支付报文传输平台（PMTS）作为一个连接支付系统和参与者的渠道，是一个高可用的端到端报文传输平台，其任务是保证支付系统与各个参与者之间的高可靠性的报文传输。其业务功能主要是以下几点：（1）传输安全：保证支付报文传输过程中端到端的数据
7、完整性；（2）报文校验：对收到的支付报文要进行格式校验，不满足格式要求的给予拒绝处理，从而实现对参与者故障的有效隔离。参与者故障中报文级的错误可以在支付报文传输平台得到屏蔽，不影响业务处理系统（同时业务系统也支持对参与者设置故障状态，限制该参与者业务的发起与接收）。（3）智能路由：对于满足格式要求的，根据目标地址自动选择传输路径，确保最终送达支付系统以及/或者参与者。该平台支持参与者多点接入路由的灵活调整，如在某些节点发生故障的时候，该平台能够根据调整后的路由选择其他节点继续进行报文传输处理。支付报文传输平台具备如下主要特性：（1）与业务系统无关：支持大额、小额和网银系统的各类报文，未来可扩展
8、支持其他支付清算系统的报文；（2）兼容多种报文格式：支持CMT/PKG/XML报文，并可以根据需要方便扩展；（3）高可用性：系统要具有较好的容错机制，在部分节点失效时能继续提供报文传输服务。,PMTS-MBFE 参与者接入端软件,PMTS参与者接入端软件（PMTS-MBFE，部署在直联前置机上的应用软件）是连接支付系统和参与者行内系统的桥梁，是支付系统的重要组成部分。参与者接入端软件的主要功能包括报文转发、报文格式检查、安全管理等，即对参与者行内系统提交的报文和支付系统发来的报文进行相应的报文格式检查，并根据系统安全规范实现报文的可靠传输和交换。参与者接入端软件不参与业务相关处理，如业务合法性
9、检查、重账检查、业务核对等，以降低其运行维护复杂度。参与者接入端软件只提供直连接入功能，不提供业务录入、来帐打印等间连接入功能。参与者接入端软件应用软件由人民银行负责开发，免费提供给系统参与者使用，物理部署在系统参与者端，并由系统参与者进行系统维护与管理。,参与者接入端软件的部署,系统参与者使用参与者接入端服务器通过支付系统专用网连接第二代支付系统，参与者接入端服务器上部署参与者接入端软件，物理摆放在系统参与者系统内部，使用消息中间件和支付系统交换业务报文。部署示意图如右：,参与者接入端软件的数据交换,参与者通过参与者接入端软件与支付系统进行报文交换示意图如右所示：,接入前的工作,参与者连接第
10、二代支付系统前需完成以下两项工作：1、按照第二代支付系统直联前置机配置指引，准备前置机运行环境，部署PMTS参与者接入端软件；2、按照第二代支付系统报文交换标准，完成“互联规范”中要求的有关支付系统业务报文（含一代报文和二代报文，具体参考“互联规范”4.6节）的开发。,主要内容,互联规范的组成参与者与二代支付系统互联概述参与者与二代支付系统系统互联详述系统互连的安全说明,参与者接入端软件和行内系统互联,通信方式 行内系统与参与者接入端软件间可以通过消息中间件Server-Server或Client-Server模式交换报文，也可以使用商业银行自行开发的通讯软件访问参与者接入端软件的消息中间件（
11、Server）实现报文交换。注：参与者接入端软件与支付系统间的通讯方式必须为消息中间件方式，详细参考第二代支付系统直联前置机配置指引及第二代支付系统直联前置机安装配置手册。,参与者接入端软件和行内系统数据交换过程,行内系统向支付系统发送报文时，通过消息中间件或自行开发的通信软件将往帐报文发送到参与者接入端软件指定的消息队列，由参与者接入端软件负责将报文发送给支付系统；行内系统接收支付系统转发的来帐报文时，通过消息中间件或自行开发的通信软件读取参与者接入端软件指定的消息队列获取报文。,与第一代支付系统的兼容,为了实现第一代支付系统向第二代支付系统的平滑过渡，第二代支付系统投产后相当一段时间内，将
12、既支持参与者通过行内系统改造采用第二代支付系统报文标准接入，也支持参与者不进行改造，继续采用原一代报文交换标准接入。因此，参与者加入二代支付系统时，需要在支持二代支付系统报文标准（即XML格式报文）的同时，支持部分一代支付系统报文标准（即CMT/PKG格式报文），以实现与未完成行内系统改造的参与者间进行业务往来。,系统互联的三种数据格式,1、第二代支付系统新增报文 2、原第一代支付系统报文 3、基础数据文件,1、第二代支付系统新增报文,为便于系统参与者接入支付系统，降低报文转换复杂性，二代支付系统新增报文交换标准采纳了部分ISO20022报文标准作为支付系统的报文，并参照ISO20022规范开
13、发了其他报文，全部报文均采用XML格式描述。其中，对采纳使用的ISO20022标准报文，根据支付系统的实际情况，进行了必要的格式约束。行内系统发送报文给支付系统时，应将待发送的往帐报文使用XML Schema进行格式检查，检查通过后，才能提交给参与者接入端软件。行内系统从参与者接入端软件接收报文后，行内系统应使用XML Schema对收到的来帐报文进行格式检查，检查通过后，才能提交给行内系统进行业务处理。对检查失败的来帐报文，行内业务人员可以选择主动联系支付系统业务管理人员，对异常来账报文做补发处理；也可选择行内系统直接丢弃，留待日终对账解决。详细报文交换标准参考第二代支付系统报文交换标准。,
14、2、原第一代支付系统报文交换标准,原一代支付系统的CMT/PKG报文的格式保持不变。详细报文交换标准参考二代支付系统报文交换标准。,3、基础数据文件,为便于各系统参与者将二代支付系统的各类基础数据导入行内系统或者进行其他处理，二代支付系统提供了基础数据文件。这些数据文件的格式标准具体参考二代支付系统报文交换标准文档集中的二代支付系统基础数据文件格式标准。,报文传输的可靠性约束,为保证系统间报文传输的可靠性，行内系统和支付系统均应在接收到对方发送的报文时给予通信级报文接收确认，该报文使用“通信级确认报文”，具体参见二代支付系统报文交换标准。参与者通信软件发送报文给支付系统时，应标记该报文的发送状
15、态为“待确认”，待收到支付系统返回的通信级确认报文后，修改状态为“已确认”。对没有收到通信级确认报文的往帐报文，应视为没有发送给支付系统，参与者通信软件可以再次提交该报文给支付系统。参与者通信软件收到支付系统转发的来帐报文时，应返回通信级确认报文给支付系统。对没有收到通信级确认报文的来帐报文，支付系统视为没有发送给参与者，可能会再次发送该报文给参与者。参与者通信软件应提供来帐报文的重复报文检测机制，检查来帐报文报头的报文标识号，对报文标识号重复的报文，应视为重复报文，可以直接丢弃。支付系统和参与者均不应对对方返回的通信级确认报文再返回通信级确认报文。,业务报文的三种处理模式,模式一：参与者主动
16、发送报文模式二：参与者接收报文不需回复模式三：参与者接收报文需回复,模式一：参与者主动发送报文,参与者行内系统发送报文给支付系统，支付系统受理该报文，根据业务流程的不同，对于需回复回应报文的则支付系统回应相应的报文给参与者，例如参与者向支付系统发送“登录/退出申请报文”，支付系统回应“登录/退出应答报文”；对于无需回复回应报文的则支付系统不回应相应的报文给参与者，例如参与者向支付系统发送“自由格式报文”，支付系统成功处理后不回应报文给参与者。,模式二：参与者接收报文不需回复,支付系统发送报文给参与者行内系统，参与者行内系统受理该报文，无须返回业务回应报文给支付系统；对这类报文，参与者行内系统业
17、务检查失败、核签失败的，应直接丢弃该报文；例如系统状态变更通知、金额上限变更通知等等,模式三：参与者接收报文需回复,支付系统发送报文给参与者行内系统，参与者行内系统受理该报文，返回业务回应报文给支付系统；例如业务查询报文、小额普通借记业务报文等等。,系统互联报文一览表,系统互联报文一览表（续）,其他参考第二代支付系统互联规范4.6节不同参与机构所对应的文档中的报文一览表内容不同,主要内容,互联规范的组成参与者与二代支付系统互联概述参与者与二代支付系统系统互联详述系统互连的安全说明,1、报文权限控制说明,为了保证业务处理的安全可靠，系统参与者需对收发的业务报文进行权限控制。对于无权发送的业务报文
18、应禁止发出。对于参与者与参与者之间的业务，未完成行内改造的一代参与者之间使用CMT/PKG格式报文进行数据交换；完成行内改造的二代参与者之间使用新的XML格式报文进行数据交换；一代参与者与二代参与者之间使用CMT/PKG格式报文进行数据交换。对于参与者与NPC之间的业务，例如业务状态查询、登录、退出等等，一代参与者与NPC之间使用CMT/PKG格式报文进行数据交换；二代参与者与NPC之间使用XML格式报文进行数据交换。,2、数字签名机制,对于二代支付系统新增的报文，为了保证系统参与者与支付系统之间关键业务数据可靠性和不可抵赖性，系统参与者发起需加、核签业务报文时，应对其加编数字签名，而接收此类
19、报文时，需核数字签名。对业务量较大的参与者，可以考虑在行内系统部署专用的硬件签名服务器，以实现快速的编签、核签处理。对业务量较少的参与者，可以不必部署专用的硬件签名服务器，而使用软件加、核签方式（例如：可以采用OpenSSL实现）为验证签名者证书的有效性，系统参与者应自行从CFCA网站获得CRL列表，导入系统参与者行内系统，并以CRL列表为准核验数字证书的合法性，支付系统不提供CRL下发与广播功能。,3、数字证书与系统参与者绑定,支付系统用以编制业务签名的数字证书，以系统参与者为单位申请和使用，系统参与者向当地CCPC Ra 申请证书，并从CFCA网站下载证书后，应及时向支付系统发送“数字证书
20、绑定通知报文”报文建立参与者和新证书的绑定关系，支付系统受理该报文并处理成功后，广播该报文给全部系统参与者，各系统参与者接收该报文，并从该报文获取系统参与者的数字证书公钥信息，存档以便后续验证数字签名使用。系统参与者进行数字证书绑定成功后才可以发起业务报文，其他系统参与者接收到业务报文时需验证数字证书与业务发送参与者的绑定关系和数字签名的合法性。,4、第一代支付系统密押/密钥,过渡期间，二代参与者在与一代参与者间进行业务往来时，需按照一代报文标准在行内系统对往账业务报文进行加押，对来账业务报文进行核押，编、核押规则参考二代支付系统报文交换标准文档集中的一代支付系统报文编核押规则。编、核押设备仍
21、可使用原一代支付系统的密押服务器/密押卡，编、核押接口API可联系密押设备生产厂家获取。但需注意，区别于一代支付系统中参与者与支付系统交互采用地方押密钥的模式，二代参与者与支付系统交互需使用全国押密钥。上线切换时，人民银行将统一更换二代参与者密押服务器/密押卡的密钥。对于通存通兑业务PIN口令的加、解密操作，也可沿用一代支付系统的密押服务器设备，但需对密押服务器的配置进行升级，以支持与NPC直接交换密文的两级密钥体系。具体参见第二代支付系统直联前置机配置指引。,第二代支付系统报文交换标准,主要内容,报文交换标准的组成XML格式报文交换标准XML格式报文schemaXML格式报文示例第一代支付系
22、统报文标准第一代支付系统报文编核押规则,01_XML格式报文交换标准描述第二代支付系统中业务报文的结构、报文中主要数据域的定义与填写规则、各个报文包含的业务要素等等。作为第二代支付系统一个组成系统的网上支付跨行清算系统（即Internet Banking Payment System，简称IBPS）的报文交换标准前期已经发布，本次不对IBPS系统所涉及到报文交换标准重新发布。包括以下文档：1、第二代支付系统报文交换标准（概述）2、第二代支付系统报文交换标准（大额支付系统分册）3、第二代支付系统报文交换标准（小额支付系统分册）4、第二代支付系统报文交换标准（清算账户系统分册）5、第二代支付系统报
23、文交换标准（公共控制系统分册）,第二代支付系统报文交换标准共由六组文档组成。,02_XML格式报文schema第二代支付系统xml报文的schema文件，便于各系统参与者根据schema文件的规则对xml报文进行格式合法性检验。包括所有报文的schema文件（目前共130个独立的schema文件）。,第二代支付系统报文交换标准共由六组文档组成。,03_XML格式报文示例第二代支付系统xml报文的示例，这些报文示例并非真实的报文数据，仅供各系统参与者了解xml报文的层级结构参考使用。包括所有报文的示例文件（目前共148个独立的报文示例文件）。,第二代支付系统报文交换标准共由六组文档组成。,04_
24、导出文件格式标准 描述第二代支付系统导出的基础数据格式，便于各系统参与者按照该格式将基础数据导入行内系统进行处理。包括以下文档：1、第二代支付系统基础数据文件格式标准,第二代支付系统报文交换标准共由六组文档组成。,05_第一代支付系统报文标准描述原第一代支付系统中业务报文的结构、报文中主要数据域的定义与填写规则、各个报文包含的业务要素等等，第一代支付系统报文标准为已经发布的标准，为便于参与机构获取本次附带下发，并未对原文档的内容进行修改。包括以下文档：1、大额支付系统MESG报文格式汇总v2.3.22、小额支付系统报文格式标准V2.3,第二代支付系统报文交换标准共由六组文档组成。,06_第一代
25、支付系统报文编核押规则描述第一代支付系统CMT/PKG格式报文的编、核押规则，系统参与者需按照此规则对第一代支付系统CMT/PKG格式报文的编、核押处理。包括以下文档：1、第一代支付系统报文编核押规则,第二代支付系统报文交换标准共由六组文档组成。,主要内容,报文交换标准的组成XML格式报文交换标准XML格式报文schemaXML格式报文示例第一代支付系统报文标准第一代支付系统报文编核押规则,XML报文数量,二代支付系统目前共有XML报文148条，分布在四个分册中：大额支付系统分册-17条小额支付系统分册-45条清算账户系统分册-54条公共控制系统分册-32条,基本术语,业务要素业务要素是业务数
26、据项的抽象名称，是业务的基本组成单位，如银行账户的账号。报文报文是系统节点间交换业务数据的基本单位，由报文头和报文体组成，其中报文体由多个报文块组成。报文块报文块是报文的基本组成单位，使用XML标签界定，由多个报文域组成。报文域报文域是报文块的基本组成单位，使用XML标签界定。每个报文域封装一个或多个业务要素，多个报文域组成报文块。对复杂的业务要素，报文域可能包含多个报文子域。根报文域报文使用XML文档标准，该文档的根节点称为根报文域，标签固定为。报文子域对于分级的报文域，较低级的域称作报文子域，使用XML标签界定，位于较高级报文域的XML标签内部。,报文格式概述,字符集和编码 报文采用Uni
27、code字符集，UTF-8编码方式。报文结构系统使用XML报文传输业务数据。该XML报文仅承载业务数据本身，并没有包含与报文流转、交换、路由等相关的信息，这些信息须附加到额外的数据块中传输，为处理的简便性，系统将这个额外数据块附加到业务报文的头部，称之为报文头，而将业务报文本身称为报文体。报文头与报文体之间存放数字签名，称为数字签名域，数字签名域是可选的，对于需要加核数字签名的报文该域必须存在且按照要求填写数字签名内容，对于不需要加核数字签名的报文该域不出现。报文头、数字签名域和报文体共同构成一个完成的报文，之间没有任何字符间隔。,报文头,节点间报头传输通信级数据，主要由版本标识、发起方、接收
28、方、报文描述四个部分组成，采用定长数据格式，总长度为132字节。格式如下：,数字签名域,数字签名域采用变长数据格式，格式如下：,报文体,报文体为XML格式，使用标签标识XML报文的根。注：namespace_string的值为该报文所对应的schema文件中定义的名字空间值。,报文编号,单个报文长度,单个报文长度大小应符合以下规定，超过该长度大小的报文将被支付系统拒绝。,数据类型,数据类型（续）,所有数据类型参见第二代支付系统报文交换标准（概述）中的第3节“数据类型”,通讯层重账判定规则,通过报文头的数据判定报文发起人（OrigSender）报文发起日期（OrigSendDate）通信级标识号
29、（MesgID）唯一确定一个报文，该三项重复的报文作为通信级重复报文；,业务层重账判定规则,报文标识号唯一标识一个参与机构发起的一个报文，由报文发起参与机构编制（支付类报文、信息类报文等各类报文混编）。CNAPS2使用发起参与机构号+报文标识号作为重复报文的检查标准。对两者均相同的报文，CNAPS2视为重复报文。各参与机构应按相同的规则进行重复报文检查。CNAPS2规定报文标识号的编号规则为：当前工作日期（8位数字）+报文序号（8位数字，不足8位的，前补0）组成，共16位长度。例如2010020200000001。,主要内容,报文交换标准的组成XML格式报文交换标准XML格式报文schemaX
30、ML格式报文示例第一代支付系统报文标准第一代支付系统报文编核押规则,Schema数量,共有130条schema文件存在多条报文对应使用同一条schema文件的情况，所以146条报文对应使用130条schema文件,Schema文件,W3C标准，对报文体的XML文件进行定义,使用工具软件帮助阅读,主要内容,报文交换标准的组成XML格式报文交换标准XML格式报文schemaXML格式报文示例第一代支付系统报文标准第一代支付系统报文编核押规则,报文示例数量,共有146条报文示例文件每条报文对应一条报文示例文件注：报文示例文件中只含报文体，不含报文头和数字签名域。报文示例文件仅供帮助理解报文结构，其中
31、的内容不一定正确。,主要内容,报文交换标准的组成XML格式报文交换标准XML格式报文schemaXML格式报文示例第一代支付系统报文标准第一代支付系统报文编核押规则,第一代支付系统报文标准,1、大额支付系统MESG报文格式汇总v2.3.22、小额支付系统报文格式标准V2.3注：第一代支付系统报文标准为已经发布的标准，为便于参与机构获取本次附带下发，并未对原文档的内容进行修改。截至2010年10月15日 大额系统报文标准最新版本为V2.3.2小额系统报文标准最新版本为V2.3,主要内容,报文交换标准的组成XML格式报文交换标准XML格式报文schemaXML格式报文示例第一代支付系统报文标准第一代支付系统报文编核押规则,第一代支付系统报文编核押规则,描述第一代支付系统CMT/PKG格式报文的编、核押规则，系统参与者需按照此规则对第一代支付系统CMT/PKG格式报文的编、核押处理。,第一代支付系统中需要编核押的报文清单（大额）,第一代支付系统中需要编核押的报文清单（小额）,
