中国支付清算体系(一) —— CNAPS2 总体框架
WalletsClub清结工2020/10/10 8:59:01

引子

今天中国国内支付行业的发达水平、繁荣程度,不客气得讲在全世界都是数一数二的,世界上最大的银行卡组织(银联)在中国、世界上交易量最大的网络零售支付清算体(网联)在中国,世界上前两大电子钱包公司(支付宝&微信支付)也在中国。

说出来我们自己可能都不信,支撑这个国家如此庞大的支付体系运转的现代化支付清算系统,服役才不到20年!这是什么概念呢?就好比一个平台刚上线马上就搞双十一,而且一搞就是18年,天天双十一,就是这么横。

CNAPS是China National Advanced Payment System的缩写,也就是「中国现代化支付系统」,目前已经升级到了第二代,以下简称CNAPS2。需要说明的是,CNAPS2并不是指某一个系统,而是一个由很多子系统组成的系统集,是一个统称。

CNAPS2是中国支付清算的核心和基石,由中国人民银行清算总中心开发和运营,其结构如下图所示:

在中国,不同领域还有很多其他机构开发和运营的支付清算系统,比如银行卡领域的「银联」、非银领域的「网联」、外汇领域的「境内外汇支付系统」、国债领域的「中央债权系统」等等,这些系统里面来来回回倒腾的其实都只是清算的「数据信息」,真正要让资金发生流转,必须通过CNAPS2来完成。

读过我们文章的小伙伴都知道,一笔资金要想正确的发生转移,有两个必备的条件:

  • 信息流
  • 资金流

「资金流」就是CNAPS2干的事情。

金融机构清算账户之间真正的资金转移都是在CNAPS2里面发生的,那么其他清算系统是怎么告诉CNAPS2要动账的呢?换句话说就是,他们是怎么和CNAPS2打通「信息流」的呢?答案是他们之间使用了一个叫做PMTS(Payment Message Transmission System,直译为支付报文传输平台)的通讯系统。

我们把视线放远一些,CNAPS2和其他的支付系统之间的实际上是这样连接起来的(为了简化理解,我们只列出部分的支付清算系统)

中国的支付清算体系在物理结构上设立了两级处理中心:NPC(National Processing Center,即国家处理中心)和CCPC(City Clearing Processing Center,即城市处理中心),全国一共有32个CCPC,除了深圳其他都是省会城市。NPC通过PMTS分别与各个CCPC相连,核心的支付业务处理都是在NPC完成的,CCPC主要负责报文的转发。

我们继续把视线再放远一点,可以看到在NPC和CCPC上分别部署的具体的支付清算系统大概是这样的:

参与者可以直接接入NPC,也可以通过CCPC间接接入NPC,比如对于大额支付系统,中国银联作为特许参与者可以与NPC直接连接;对于小额支付系统,商业银行或非银支付机构与CCPC连接。具体的接入规则很庞杂,大致如下图所示(来自人行):

我们一直反复强调,支付清算的核心就两个东西:资金流&信息流。接下来,我们就先搞清楚这两个东西在中国的支付清算体系里面是怎么运转的,把这两个核心的点搞清楚了,其他的支付清算系统是怎么运作的就好理解了。

好了,废话不多说,下面开始烧脑掉头发,我们来了解一下CNAPS2的两个核心系统。

清算账户管理系统(SAPS)——资金的搬运工

对中国支付清算体系感兴趣的小伙伴们通常都是从大、小额系统开始的,但大家可能不知道的是,大小额系统其实并不负责真正的资金移动,他们只是支付清算的「业务系统」(比如小额系统的核心工作是Netting,也就是计算双边净额,国内喜欢叫轧差),真正让资金移动的是大小额系统背后的那个叫做「撒泼氏的女人」——SAPS。

SAPS是Settlement Account Processing System的缩写,也就是清算账户管理系统。顾名思义,所有金融机构的清算账户都是在这个系统中维护的,资金的转移也是在这个系统中发生的,所以SAPS是正经八百的C位「财神爷」。

在SAPS中,账户被分成了这么几类:

  • 一般清算账户:即政策性银行、商业银行以及城乡信用社在人行开设的准备金存款账户
  • 特许清算账户:人行特许的参与者开设的专门用于办理人民币资金结算的存款账户,比如银联的账户
  • 联行类账户:人行会计营业部门、国库部门开设的账户,主要用在大小额联行类科目下
  • 汇总平衡类账户:这是一个特殊的账户,人民银行会计营业部门、国库部门才有这类账户

每一个账户都有如下的一些属性:

  • 账号
  • 户名
  • 余额
  • 类型(存款类、联行类、汇总平衡类)
  • 借贷方向
  • 状态(待开户、开户、销户、待销户、借记控制)
  • 最低余额
  • 日间透支限额
  • 质押融资配置

了解了账户是怎么回事,那么SAPS系统对这些账户做些什么呢?主要的功能大致是这样的:

看着这些功能很费劲也很费解,我们来举个具体的例子,当大额系统向SAPS发来一笔大额转账(如普通贷记业务)支付请求的时候,SAPS会做如下事情:

  1. 检查发起清算行的清算账户可用头寸是否足以支付,可用头寸=清算账户余额-圈存资金-余额最低控制金额。所谓圈存资金可以认为是临时冻结的资金,比如证券交易的时候,要先冻结一部分资金,待证券业务系统完成了证券的交割,这部分圈存的资金就会被触发交割,所以这部分资金是不能参与其他清算的;
  2. 如果可用头寸足够,则SAPS立即对收付双方的清算账户逐笔记账(具体的会计分录我们这里略过),然后将处理结果返回给大额支付系统;
  3. 如果可用头寸不足,则SAPS将支付请求放入队列进行等待,对于不同的支付请求,排队的优先级是不一样的,优先级从高到低是这样的:
  • 错账冲正
  • 特急大额支付(救灾战备款)
  • 日间透支利息和支付业务收费
  • 同城票据交换轧差净额
  • 小额借方轧差净额和网银借方轧差净额的清算
  • 单边业务
  • 紧急大额支付
  • 普通大额支付和即时转账

在队列里面的支付请求怎么办呢?这就涉及到SAPS的风险和流动性管理,出队列的过程国内称之为「队列解救」,有几种办法解救队列:

大额清算排队撮合机制:这种方法日间交易的时候不启用,一般在大额支付系统当日营业截止后、下一次清算窗口开启前才启用,并且需要队列里面至少有2个支付指令(不然也没法撮合对吧),撮合的过程就是净额轧差一下,如果轧差后余额还是不够支付,那就没救了,只能打回了

  • 自动质押融资:这种方法是要首先在系统中配置好规则(这个规则很复杂,比如有触发的起点金额、当场最高融资金额、单笔最高融资金额、成员行最高融资金额、利率、手动还是自动啊等等一堆的配置),当银行日间流动性不足的时候,根据规则自动或者手动触发向人行质押债权以补足流动性(这里又涉及到和中央债券系统的交互,其实整个过程非常复杂)
  • 日间透支:人行根据参与者的信誉会授予一个日间的透支额度,该额度内部分业务可以透支,比如大小额、网银
  • 资金池管理:银行在央行开设的清算账户可能不止一个,比如以分行为单位开了很多个,这时候如果某个分行的头寸不够了,可以根据事先的配置,自动的从其他分行的清算账户里调动流动性过来,资金池管理原则实际上也不是说说这么简单,有很多的原则,有兴趣的可以深挖一下
  • 日终自动拆借:参与者之间事先可以签订拆借合同,并在系统中配置好规则,当协议一方清算账户余额不足以完成支付的时候,系统将自动的从协议的另一方清算账户拆入资金,完成排队业务的资金清算,这个一般是在清算窗口预关闭时才触发

好,到这一步我们就不再继续展开了,里面的细节实在太多,恐怕一本书都写不完,我们只需要大概简单的了解SAPS的功能就行了,包括资金转移逻辑、排队机制、流动性管理等。SAPS是一个被动系统,需要支付应用系统(大额、小额、网银)触发它它才会运作,一旦运作起来,就意味着资金正在金融机构间发生转移。

支付报文传输平台(PMTS)——传递信息的信使

一代支付系统的时候,每一个支付系统都内置了一套通信模块,其实这些通信模块在各个系统中都是差不多的,所以在二代支付系统开发的时候就把这个通信模块单独独立出来了,形成了一个独立的通信平台,专门负责各个系统间的消息传递,也就是我们这里要介绍的PMTS(Payment Message Transmission System)。不管是参与者自己的内部系统还是部署在NPC&CCPC里面的支付应用等系统,都统一通过PMTS这个平台来完成消息传递(即报文)。

PMTS通信系统单独拿出来的好处显而易见,就跟我们之前介绍过的SWIFT一样,大家统一通信标准,减少重复造轮子的工作量。

对于不同的接入者和场景,PMTS也有不同的方案与之对应,比如:

  • PMTS-NPC:部署在NPC上,也就是我们前面提到过的集中交换网关
  • PMTS-CCPC:部署在CCPC上,也就是区域接入网关,专注的用来转发消息、安全检查等
  • PMTS-MBFE:部署在参与者本地,也就是我们常听说的「前置机」(MBFE=Member Bank Front End),负责打包商业银行行内系统向支付系统发出的各类报文、负责接收&解包&校验支付系统返回的各种报文等
  • PMTS-CLIENT:客户端,大小额等支付系统调用它与PMTS通讯
  • PMTS-Console:管理控制台

下面画一个图来说明一下逻辑上PMTS是怎么把参与者和支付系统串起来的(下左图),以及一个支付指令在各个系统之间是怎么完成消息的传递的(下右图):

PMTS的灵魂是报文,报文是系统间互相对话的语言,根据不同的业务,PMTS定义了若干种报文,具体的报文细节我们这里就不展开了,有兴趣的小伙伴可以搜一下《第二代支付系统报文交换标准》,包括一代的PKG/CMT报文格式,二代的XML报文格式(部分支持ISO20022标准)都有详细的介绍,研究过SWIFT报文的小伙伴相信读起来就不会很烧脑了。

完结撒花

本篇我们大概的了解了一下CNAPS2的基本结构,以及其中最重要的两个子系统:

负责账户间资金转移的系统——SAPS,Settlement Account Processing System,清算账户管理系统

负责传递消息的的通讯系统——PMTS,Payment Message Transmission System,支付报文传输平台

二代支付系统是我国支付清算体系的核心,这两个子系统又是二代支付系统的核心,所以是精华中的精华。从原理上讲,有了这两个系统,其实清算这事就能跑起来了,就像一辆汽车一样,有了动力系统和底盘总成,原理上这辆车就已经可以开动了。

但是显然这么简陋肯定是不行的,没制动系统怎么停下来?没有转向系统怎么拐弯?所以,在此基础之上,根据不同的场景和需求,需要构建很多不同的清算系统才能组成一个完整的支付清算体系,这些清算系统就是我们都听说过的大额、小额、网银、银联、网联、外汇、国债、证券、票据、农信银等等等等,后面我们会逐个介绍(看大家兴趣咯,既然我们的公众号不能留言,那就请有兴趣的小伙伴通过点赞来告诉我们吧)。

最后,放一张中国支付清算全貌图(呃……其实也不是很全,被我们省略掉了很多,不过下图中提到的我们基本都会分享哦),以后我们每分享到一个支付清算系统就点亮它,这样一看就知道它在哪里了(今天聊到的两个系统已经点亮啦)。

中国清算支付清算体系博大精深(这不是客套话,你想想,能支撑13亿人口的支付清算体系那可不是随便搞搞就行的),我们的读者朋友中大仙环伺、高手云集、神人辈出,小编倍感压力,要不是在大家的百般鼓(撺)励(掇)之下,小编真的是没勇气写中国支付清算体系的,如果有写的不对的地方还望大神们不吝赐教,我们在仔细确认后会专门发一篇修正错误的文章。

说实在的,这个系列小编不敢凭经验和记忆随便写写,而是把能找到的、官方披露的所有文档又认认真真梳理了一遍了,力求如实还原又通俗易懂,真的已经尽力了,此时已累晕正在抢救中,呼~


展开全文
相关阅读
资讯查询取消