构建支付报文传输平台后，支付系统与参与者和其他
外围系统的关系如下图所示：
CFXPS
CNAPS2
大额支付系统 小额支付系统 网上支付跨行清算系统 清算账户管理系统 公共管理系统
ECDS
• 图中的CNAPS2， 即第二代支付系统 包含了大额支付系 统、小额支付系统、 网上支付跨行清算 系统、清算账户管 理系统、公共数据 管理系统等业务系 统
行内系统不改造的参与者如何 接入二代支付系统？
• 仍通过现有的一代大、小额支付系统前置机（即MBFE）接入。 • 行内系统不需要调整与修改，与支付系统之间仍收、发原一代支付
系统的CMT/PKG格式报文。
完成行内系统改造后的参与者 如何接入二代支付系统？
• 一代支付系统建设过程中，大额 、小额…等每一个业务系统都建设了一 套相对独立的从参与者到CCPC再到NPC的应用逻辑，既要负责业务需求 和功能的实现，也要负责报文收发和节点间的传输。从实际情况来看，关 于报文的收发和在节点间的传输需求，对各个业务系统而言，基本都是一 致的，因此各系统分别去实现这些功能属于重复。
• 为便于向参与者提供灵活、可靠的接入服务，二代支付系统建设中，提出 了“报文传输与业务处理分离”的思路，通过构建一个高可用的支付报文 传输平台（Payment Message Transmission System，简称PMTS），实 现参与者与支付系统之间安全可靠的支付业务报文传递。
• 从支付报文传输平台（即PMTS ）的角度来看，各类金融信息系统均可接 入到该平台，通过该平台提供的服务来发送/接收跨行的报文；支付系统 处理中心也只是接入到PMTS的一个信息系统，从PMTS中获取报文，进 行处理和转发。
– 报文1实际上经过API后转换为报文2。两个报文略有不 同，主要有三点不同：
– 1、报文头长度不同。报文1使用的是所谓的“短报头”。 而报文2使用的是所谓的“长报头”。
– 2、密押字段。对于需要加、核密押的报文，报文1中是 不含密押字段的。而报文2经过API后增加了密押字段。
– 3、报文尾。大额报文，报文1是不含报文尾的，报文2 含报文尾。
• 示意图如右 所示：
支付系统端
支
付
数据交换
系
消息中间件
统
系统参与者端
P
M
T
行
S
数据交换 内
M
系
B
统
F
E
完成行内改造的参与者接入前 的工作
• 需完成以下两项工作：
– 1、按照《第二代支付系统直联前置机配置指 引》，准备前置机运行环境，部署PMTS参与 者接入端软件；
– 2、按照《第二代支付系统报文交换标准》， 完成“互联规范”中要求的有关支付系统业务 报文（含一代报文和二代报文，具体参考“互 联规范” 4.6节）的开发。
CNAPS2接入网关B
PMTS服务器
PMTS服务器
inactive
inactive
active
active
行内系统
行内对于多台PMTS-MBFE可 用性及负载情况的探测
• 当行内部署２台或者更多的PMTS-MBFE时，可以通过向PMTS-MBFE发 送报文了解这些PMTS-MBFE的可用性及负载情况。
• 1、可用性判断标准：
• 发送探测请求报文后，超过 行内规定的时间无回应报文
• 2、负载情况的判断标准：
• 探测回应报文中有一个“负 载系数”的值，表示该 PMTS-MBFE的压力（即待 处理的业务报文数量），0 时表示无压力，值越大则负 载越大。
参与者接入端软件的数据交换
• 参与者通过 参与者接入 端软件与支 付系统进行 报文交换
• 当任一直联前置
机发生故障时， CNAPS2
即单点故障情况
单个CNAPSFE故障时
下，报文收发功 参与者
能不受影响。
• 部署示意图如下：
active
active
inactive
active
PMTS-MBFEA
PMTS-MBFEB
PMTS-MBFEA
PMTS-MBFEB
行内系统
行内系统
并行冗余模式
CNAPSFEA 共享存储
CNAPSFEB
行内系统
CNAPSFEA
CNAPSFEB
共享存储
行内系统
CNAPSFEA
CNAPSFEB
共享存储
行内系统
并行模式
• 并行模式下，两
台（或多台）直
联前置机均与支
付系统接入网关
连接，同时在线，
完成报文收发。
CNAPS2接入网关A CNAPS2接入网关B
CNAPS2接入网关A CNAPS2接入网关B
与第一代支付系统的兼容
• 为了实现第一代支付系统向第二代支付系统的平滑过 渡，第二代支付系统投产后相当一段时间内，将既支 持参与者通过行内系统改造采用第二代支付系统报文 标准接入，也支持参与者不进行改造，继续采用原一 代报文交换标准接入。
• 因此，完成行内系统改造的参与者加入二代支付系统 时，需要在支持二代支付系统报文标准（即XML格式 报文）的同时，支持部分一代支付系统报文标准（即 CMT/PKG格式报文），以实现与未完成行内系统改 造的参与者间进行业务往来。
• 当主用直联前置机发生 故障时，可即时启用备 用直联前置机，接入网 络，进行报文的收发。
CNAPS2接入网关A CNAPS2接入网关B
CNAPS2接入网关A CNAPS2接入网关B
CNAPS2 参与者
主用CNAPSFE发生故障
主用
PMTS-MBFEA
备用
PMTS-MBFEB
备用
PMTS-MBFEA
– 而对于行内系统调用API接收报文时，与上面提到的三 点不同相反。
3、基础数据文件
• 为便于各系统参与者将二代支付系统的各类基础数据导入行内系统或者进 行其他处理，二代支付系统提供了基础数据文件。（例如行内准备测试环 境，需要一套完整的支付系统参数数据，则需要对这个基础数据文件进行 处理后，导入到自身系统中）。基础数据文件的格式是XML的。
• 详细报文交换标准参考《第二代支付系统报文交换标准》。
2、原第一代支付系统报文交换标准
• 原一代支付系统的CMT/PKG报文的格式保持“不变”。 • 详细报文交换标准参考《二代支付系统报文交换标准》。
• 关于格式保持不变，注意：
– 原一代支付系统中，参与者行内系统是调用人民银行发 布的API与支付系统的MBFE进行通讯的，当报文从行 内系统发出时，如图：
参与者接入端软件的部署
• 系统参与者使用 参与者接入端服 务器通过支付系 统专用网连接第 二代支付系统，
参与者接入端服
务器上部署参与
者接入端软件，
参与 者接
物理摆放在系统
入端 软件
参与者系统内部，
使用消息中间件
和支付系统交换
业务报文。
• 部署示意图如右：
二代支付系统
支付系统专用网
路由器
防火墙
签名服务器
主用
PMTS-MBFEB
行内系统
行内系统
主备模式
• 热备模式：
• 主用直联前置机与备
用直联前置机共享存
பைடு நூலகம்
储设备。主用直联前
置机与CCPC两台服
务器连接，负责完成
报文收发。备用直联 前置机同时保持与
CNAPS2接入网关 CNAPS2接入网关
CNAPS2接入网关 CNAPS2接入网关
CNAPS2接入网关 CNAPS2接入网关
国债 银联
支付报文传输平台
商业银行
清算组织
ACS • 支付报文传输平台
（ 即PMTS）负责
完成第二代支付系
统与外部参与者间
TCBS
的支付业务报文传
输，是整个第二代
支付系统的一个基
础服务平台。
......
PMTS的功能与特点
• 支付报文传输平台（PMTS）作为一个连接支付系统和参与者的渠道，是一个高 可用的端到端报文传输平台，其任务是保证支付系统与各个参与者之间的高可靠 性的报文传输。其业务功能主要是以下几点：
• 行内系统发送报文给支付系统时，应将待发送的往帐报文使用XML Schema（随报文标准一起下发的）进行格式检查，检查通过后，才能 提交给参与者接入端软件。
• 行内系统从参与者接入端软件接收报文后，行内系统应使用XML Schema对收到的来帐报文进行格式检查，检查通过后，才能提交给行 内系统进行业务处理。对检查失败的来帐报文，行内业务人员可以选择 主动联系支付系统业务管理人员，对异常来账报文做补发处理；也可选 择行内系统直接丢弃，留待日终对账解决。
参与者接入端服务器 （部署PMTS-MBFE应
用软件）
行内系统
一代支付系统 密押设备
PMTS-MBFE集群方式部署建议
• PMTS-MBFE集群配置方式支持
– 主备模式
• 冷备模式 • 热备模式
– 并行模式
• 并行模式 • 并行冗余模式
主备模式
• 冷备模式：
• 主用直联前置机与备用 直联前置机不共享存储 设备，配置为相同的系 统配置、网络IP等等， 正常情况下，主用直联 前置机与CCPC两台服 务器连接，负责完成报 文收发。而备用直联前 置机不启用。如右图：
第二代支付系统 互联规范、报文交换概要介绍
中国人民银行清算总中心 支付系统开发中心
主要内容
• 第一部分：
– 第二代支付系统互联规范介绍
• 第二部分：
– 第二代支付系统报文交换标准介绍
• 第三部分：
– 有关问题说明
第二代支付系统互联规范介绍
•第二代支付系统互联规范共由13个文档组成，每 个文档适用于不同类型的系统参与者与第二代支 付系统互联。 •注意：选择与本参与机构的类型相适合的文档进 行阅读。这13个文档不是每个都对本行有用，不 需要全部。