[转]跨行清算系统的实现原理

标签: 清算 系统 原理 | 发表时间:2016-01-28 16:18 | 作者:CurrentJ
出处:http://www.iteye.com

最近看了很多银联方面的清算系统的设计原理,对于跨行清算系统有了很大的了解,写这篇文章的目的是在于从一个程序员的角度去思考一个跨行清算系统的架构是如何实现的以及整个过程中我们有哪些思想是可以借鉴的。由于金融里面涉及到太多的专业名词,包括借贷,备付金,头寸,调拨等等,这里不会涉及到这些,取而代之的是以大家可以理解的概念去解释。

下面简单的介绍一下两种跨行清算系统的实现原理以及特点。一种跨清算系统是我们最熟悉的银联,还有一种是越来越流行的第三方支付系统,比较典型的是快钱。

首先来拿生活中的一个非常常见的例子来说明跨行清算的整个过程,这里面不涉及交易费等其他概念。

跨行取款流程

张三是工行的持卡人,他需要取现金,但是找不到工行的ATM机器,发现附近有建行的ATM机器,他只能去建行取款,整个过程就是跨行清算的过程,我们以这个场景为例,分析一下业务流程,具体交互流程见下面一张图。

1B3CB2A3 1863 403C AA5A F1F49E7EF416

 

工行持卡人张三在建行ATM机器取款100,ATM请求建行主机,由于是工行的卡,建行不识别,只能请求工行去处理,工行识别持卡人账户并扣款100,然后通知建行,建行则通知atm吐钱。

这里整个系统要解决两个问题:

1 建行如何与工行通信

2 建行和工行之间如何清算,如上图结果,工行欠建行100.

整个系统的分析基于以上两个问题,下面首先解决是通信问题

 

跨行通信的两种模式

我们先假设工行提供接口,只需要建行发送指约定格式的报文,即可于工行通信,这种相当于建行直接通过接口方式与工行通信。如果是这种方式,只能解决建行和工行的单向通信,如果工行和建行通信,则工行要发送建行指定的通信报文格式。可是大家想想,如果银行更多怎么办,下面是三家银行间的通信

39A9848E 13A0 4F15 ABEB F1CE91BBAD73

当有三家银行的时候,通信链路就有3*2=6条,当银行越来越多的时候,这种点对点的通信变的越来越复杂,每新增一家银行,他要做之前银行都要做的很多重复性的劳动,这样的成本非常高,也不经济,那么必须出现一个网络,它能够接入所有的银行,新的银行只需要接入这个网络,就可以和其他所有的银行进行通信。

先把这个网络成为通信网络,这种通信网络有两种方式可以连接所有的银行

  • 1 这个通信网络定义标准接口,所有的银行都必须实现这个通信网络定义的api,新的银行如果想要接入这个通信网络,必须实现通信接口约定的协议。简称公共接口模式
  • 2 这个通信网络主动去连接所有的银行的接口,把所有银行的接口信息都接入里面,就像一个适配器,新的银行如果想要接入这个通信网络,这个通信网络必须主动联系银行,按照银行的接口协议实现通信,简称适配器模式。

  下面一幅图演示了这两种模式的不同:

7BDB9C58 65C9 4F58 B9B0 EA37D977317E

对于这两模式,主要博弈就在于谁强谁弱。显然第三方支付公司属于适配器模式,需要一家一家银行去接入,至于银联,个人认为应该是第一种模式,这种对于银联这种需要稳定的系统来说是最具有优势的。

 

跨行清算保证金模式

解决了通信问题,下面就看如何解决资金的清算问题。一种简单的方案就是工行在建行里面开设一个保证金账户,用这个账户去偿还在整个跨行交易中应付给建行的资金。

88169047 B15D 422F 828E 685ADF9207D7

 

从上图来看,这种方案确实可行。只需要工行在建行里面放足额的保证金,就可以满足跨行的费用。但是这里面实际上存在非常多的问题,

  • 1 如果银行越来也多,每个银行都要在其他银行存钱,太不经济了
  • 2 保证金需要放多少资金?如果一直都没有发生跨行交易,工行就亏大发了
  • 3 如果保证金不够怎么办?交易失败还是记应收款?

对于第一个问题假设银行越来越多,会导致工行需要在其他每个银行里面都开设保证金账户(见下图),是一个很不经济的方案。

66D7CC71 8C84 4621 B234 3E06FAC5856F说明这个在其他银行存保证金的方案是不可行的,和之前通信的问题一样,是不是可以把所有的银行保证金账户单独管理起来,统一放置在一起,方便各个银行之间的清算。我们暂时把这个系统称之为保证金系统。

保证金系统

保证金就是方便各个银行之间的清算,需要单独由一个系统进行管理,解决了跨行之间保证金存放的问题。每个银行只需要在保证金系统中存点钱就可以了。保证金系统也有两种模式。先看看比较好理解的第一种模式:

EB1C0D6C C30F 4B7D A120 7CB46AC33DD3

在这种模式下,银行先把一部分钱存放在保证金系统里面,同时银行内部建立一个虚拟账户,记录存放了多少钱,主要是方便对账,万一这个保证金系统钱算错了怎么办。你可以想象一下,银行是很小气的,为啥愿意把钱存放到这保证金系统里面,这部分钱干啥不好,能够银行这么干的只有国家了,这个系统就是央行的备付金管理系统。每个新增的银行都要存一份钱在这里。

另外一种方案是倒过来思考,既然没有牛逼的央行作支撑,那可以在每个商业银行都建立一个账户,用这个账户负责和银行进行清算。每新增一家银行,就在那个银行里面开一个保证金账户。

EBA5972D 06C6 4DC7 A7E4 4CC68455988B

这两种方式有本质的不同,一个是银行把资金的一部分转出到保证金,银行建立虚拟账户和保证金里面真实的资金映射。一个是保证金系统把资金转出到各个银行,自己内部建立一个虚拟账户和银行中真实的资金账户进行映射。这个间接的银行了后续的对账机制,这里先不叙述。

所有的第三方支付公司跨行清算的流程都是第二种方式,只有国家级清算公司(比如银联)是第一种方式,这是一种资源和权力上的不平等,不过是可以理解的。

清算系统

保证金系统解决了保证金存放的问题,接下来就是解决如何清算的问题。假设保证金转账是实时的,就要面对上面说的问题,保证金不够的情况下,跨行交易是成功还是失败。这是一个业务上问题,有很多种解决方案,我们暂不说。从技术上来讲,如果每一笔交易都要保证金实时记账,那么保证金系统的负载太大,事务如何保证等等一些列的问题。所以一个最简单的方案就是:一天结算一次。

每天由一个系统记录这些跨行交易信息,汇总出来,统一记账。这样一天只需要调用一次保证金系统即可。那么整个清算过程则是下面的流程:

  • 1 系统T日发生建行和工行的跨行交易100

08F9F26D 11BC 4BCA 9FAD F5C9F7B9691C

  • 2 清算系统T+1日汇总T日工行和建行之间发生的交易明细数据,并且发这些数据发给建行和工行进行确认

111356A9 ECA8 490A 977A 1FCD613F054F

 

  • 3 工行建行分别对明细对账确认之后,通知清算系统确认交易明细无误,清算系统开始清算,调用保证金支付系统转账。
  • 4 清算完成之后,工行和建行分别获取保证金系统的真实金额和自身系统内部的映射账户进行余额对账。

C84544CD AE52 4D98 999C C8B587B3E6AE

 

清算中心最主要干得事情就是统计谁欠谁多少钱,以及触发保证金系统的调拨操作。

 

对账流程

对账包括两个部分,一个是跨行交易明细的对账以及保证金余额的对账。

首先要思考的是:对账是谁发起的 ? 这个是了解对账的本质。

我们举生活中的一个例子,我们把钱投资到一个人,那个人负责公司的日常运作。你肯定会主动了解公司的账务,因为那个是你的钱。对账的发起人也是如此,对于银联的清算过程,对账的发起者是商业银行,因为你把钱放在保证金系统里面,这是你的钱,你需要去关心这个的,银联可不关心这个。

对于另外一种保证金系统,把钱放在各个银行里面了,那么对账的发起者就是这个保证金系统维护者了。目前普遍的第三方支付公司都是这个模式,所以他要找各个银行要结果明细进行对账,确认自己的资金安全无误。

 

以上就是一个简单的跨行清算系统的雏形,从一个就简单的例子入手,说明一个清算过程。目前银联的第三方支付公司的清算过程大致如此,但是实现细节远比这个复杂。但是一个基本的清算系统的本质模型大体上是不会变的。当然这个只是对于同币种的清算,不同币种或者虚拟货币的清算会涉及到汇率的问题,这些就很复杂,有机会在研究一下,后续在分享。

PS:以上很多名词都是自己的随意写的,里面很多专业名词这里不提及,有兴趣的可以自己去了解。

GodIsCoder 
博客园blog地址: http://www.cnblogs.com/aigongsi/ 
独立Blog:  God Is Coder 
个人网站:  iphone发码网 
本人版权归作者和博客园所有,欢迎转载,转载请注明出处



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [清算 系统 原理] 推荐:

[转]跨行清算系统的实现原理

- - 行业应用 - ITeye博客
最近看了很多银联方面的清算系统的设计原理,对于跨行清算系统有了很大的了解,写这篇文章的目的是在于从一个程序员的角度去思考一个跨行清算系统的架构是如何实现的以及整个过程中我们有哪些思想是可以借鉴的. 由于金融里面涉及到太多的专业名词,包括借贷,备付金,头寸,调拨等等,这里不会涉及到这些,取而代之的是以大家可以理解的概念去解释.

某证券清算系统的一次性能调优

- - Java - 编程语言 - ITeye博客
上线前,用户预估平均一天交易量约一万条,峰值约两万条. 项目上线第一天,交易量有4万条. 对于这4万条左右的交易信息的清算,花了一个多小时(清算时需要我们系统发指令给清算所,由清算所按照我们系统的指令进行清算,最后把结果通过MQ返回给我们). 用户提出以后交易的峰值可能达到一天5万条. 我们按照2倍的处理能力,定下一天10万条交易信息的处理量的目标.

网上支付跨行清算系统(第二代支付系统)与大小额支付系统有什么区别?

- - 知乎每日精选
题主已经在说明里大体列出了各个系统的主要却别. 我尝试说明下我所认知的各个支付系统之间的区别吧. 有不周到的地方,欢迎指正和讨论. 二代支付系统是一个很庞大的系统,题主所列举出的这些系统都包涵在二代支付系统里. 前段时间升级的二代支付系统,主要是解决小额系统的批量定时问题以及清算中心迁移问题,其中还包括由于一代支付系统建成时间长了以后不能应对现在业务需求以及接口紧张的问题等等.

分布式开放消息系统(RocketMQ)的原理与实践

- - 编程语言 - ITeye博客
备注:1.如果您此前未接触过RocketMQ,请先阅读附录部分,以便了解RocketMQ的整体架构和相关术语2.文中的MQServer与Broker表示同一概念.   分布式消息系统作为实现分布式系统可扩展、可伸缩性的关键组件,需要具有高吞吐量、高可用等特点. 而谈到消息系统的设计,就回避不了两个问题:  .

两万字深度介绍分布式系统原理

- -
在具体的工程项目中,一个节点往往是一个操作系统上的进程. 在本文的模型中,认为节点是一个完整的、不可分的整体,如果某个程序进程实际上由若干相对独立部分构成,则在模型中可以将一个进程划分为多个节点. 机器宕机:机器宕机是最常见的异常之一. 在大型集群中每日宕机发生的概率为千分之一左右,在实践中,一台宕机的机器恢复的时间通常认为是24 小时,一般需要人工介入重启机器.

分布式文件系统FastDFS设计原理及技术架构

- - mysqlops
FastDFS是一个开源的轻量级分布式文件系统,由跟踪服务器(tracker server)、存储服务器(storage server)和客户端(client)三个部分组成,主要解决了海量数据存储问题,特别适合以中小文件(建议范围:4KB < file_size <500MB)为载体的在线服务. Storage server(后简称storage)以组(卷,group或volume)为单位组织,一个group内包含多台storage机器,数据互为备份,存 储空间以group内容量最小的storage为准,所以建议group内的多个storage尽量配置相同,以免造成存储空间的浪费.

揭秘Facebook 广告系统核心算法Pacing工作原理 (含案例)

- - 互联网的那点事
Pacing是Facebook广告系统中花费预算的节奏的一个算法,Google Adwords里面有一个功能是设定好预算和最高出价,Adwords就可以自动通过出价调节,让你在这个限定的预算下获取最多的点击,Pacing这个算法和Adwords的这个功能很类似,都是通过调节出价,让广告主获得最大的ROI.

基于XMPP协议的Android即时通信系统原理分析

- - CSDN博客Web前端推荐文章
设计基于开源的XMPP即时通信协议,采用C/S体系结构,通过GPRS无线网络用TCP协议连接到服务器,以架设开源的Openfn'e服务器作为即时通讯平台.          系统主要由以下部分组成:一是服务器,负责管理发出的连接或者与其他实体的会话,接收或转发XML(ExtensibleMarkup Language)流元素给授权的客户端、服务器等;二是客户终端.

<转>推荐系统原理介绍-用户画像简介 - CSDN博客

- -
最近在做推荐系统,在项目组内做了一个分享. 今天有些时间,就将逻辑梳理一遍,将ppt内容用文字沉淀下来,便于接下来对推荐系统的进一步研究. 推荐系统确实是极度复杂,要走的路还很长. 为什么需要推荐系统——信息过载. 随着互联网行业的井喷式发展,获取信息的方式越来越多,人们从主动获取信息逐渐变成了被动接受信息,信息量也在以几何倍数式爆发增长.

我记录网站综合系统 -- 技术原理解析[2:C# 水印和验证码的制作]

- brett80 - 博客园-首页原创精华区
代码位置:wojilu\Drawing\Watermark.cs. 水印的定义:水印一般是指在图片上的一些版权信息文字,或者为了某种目的而对原始图片上附加一些图形或者文字. 水印的基本制作方法就是使用GDI+的方法在图片的制定位置上绘制文字或者图片. 说到GDI+,一般用于Winform对于GUI的绘制,例如文本编辑器的制作,就是使用GDI函数绘制文字在窗体表面.