跨行清算系統的實現原理

最近看了不少銀聯方面的清算系統的設計原理，對於跨行清算系統有了很大的瞭解，寫這篇文章的目的是在於從一個程序員的角度去思考一個跨行清算系統的架構是如何實現的以及整個過程當中咱們有哪些思想是能夠借鑑的。因爲金融裏面涉及到太多的專業名詞，包括借貸，備付金，頭寸，調撥等等，這裏不會涉及到這些，取而代之的是以你們能夠理解的概念去解釋。

下面簡單的介紹一下兩種跨行清算系統的實現原理以及特色。一種跨清算系統是咱們最熟悉的銀聯，還有一種是愈來愈流行的第三方支付系統，比較典型的是快錢。

首先來拿生活中的一個很是常見的例子來講明跨行清算的整個過程，這裏面不涉及交易費等其餘概念。

跨行取款流程

張三是工行的持卡人，他須要取現金，可是找不到工行的ATM機器，發現附近有建行的ATM機器，他只能去建行取款，整個過程就是跨行清算的過程，咱們以這個場景爲例，分析一下業務流程，具體交互流程見下面一張圖。

 

工行持卡人張三在建行ATM機器取款100，ATM請求建行主機，因爲是工行的卡，建行不識別，只能請求工行去處理，工行識別持卡人帳戶並扣款100，而後通知建行，建行則通知atm吐錢。

這裏整個系統要解決兩個問題：

1 建行如何與工行通訊

2 建行和工行之間如何清算，如上圖結果，工行欠建行100.

整個系統的分析基於以上兩個問題，下面首先解決是通訊問題

 

跨行通訊的兩種模式

咱們先假設工行提供接口，只須要建行發送指約定格式的報文，便可於工行通訊，這種至關於建行直接經過接口方式與工行通訊。若是是這種方式，只能解決建行和工行的單向通訊，若是工行和建行通訊，則工行要發送建行指定的通訊報文格式。但是你們想一想，若是銀行更多怎麼辦，下面是三家銀行間的通訊

當有三家銀行的時候，通訊鏈路就有3*2=6條，當銀行愈來愈多的時候，這種點對點的通訊變的愈來愈複雜，每新增一家銀行，他要作以前銀行都要作的不少重複性的勞動，這樣的成本很是高，也不經濟，那麼必須出現一個網絡，它可以接入全部的銀行，新的銀行只須要接入這個網絡，就能夠和其餘全部的銀行進行通訊。

先把這個網絡成爲通訊網絡，這種通訊網絡有兩種方式能夠鏈接全部的銀行

• 1 這個通訊網絡定義標準接口，全部的銀行都必須實現這個通訊網絡定義的api，新的銀行若是想要接入這個通訊網絡，必須實現通訊接口約定的協議。簡稱公共接口模式
• 2 這個通訊網絡主動去鏈接全部的銀行的接口，把全部銀行的接口信息都接入裏面，就像一個適配器，新的銀行若是想要接入這個通訊網絡，這個通訊網絡必須主動聯繫銀行，按照銀行的接口協議實現通訊，簡稱適配器模式。

  下面一幅圖演示了這兩種模式的不一樣：

對於這兩模式，主要博弈就在於誰強誰弱。顯然第三方支付公司屬於適配器模式，須要一家一家銀行去接入，至於銀聯，我的認爲應該是第一種模式，這種對於銀聯這種須要穩定的系統來講是最具備優點的。

 

跨行清算保證金模式

解決了通訊問題，下面就看如何解決資金的清算問題。一種簡單的方案就是工行在建行裏面開設一個保證金帳戶，用這個帳戶去償還在整個跨行交易中應付給建行的資金。

 

從上圖來看，這種方案確實可行。只須要工行在建行裏面放足額的保證金，就能夠知足跨行的費用。可是這裏面實際上存在很是多的問題，

• 1 若是銀行越來也多，每一個銀行都要在其餘銀行存錢，太不經濟了
• 2 保證金須要放多少資金？若是一直都沒有發生跨行交易，工行就虧大發了
• 3 若是保證金不夠怎麼辦？交易失敗仍是記應收款？

對於第一個問題假設銀行愈來愈多，會致使工行須要在其餘每一個銀行裏面都開設保證金帳戶（見下圖），是一個很不經濟的方案。

說明這個在其餘銀行存保證金的方案是不可行的，和以前通訊的問題同樣，是否是能夠把全部的銀行保證金帳戶單獨管理起來，統一放置在一塊兒，方便各個銀行之間的清算。咱們暫時把這個系統稱之爲保證金系統。

保證金系統

保證金就是方便各個銀行之間的清算，須要單獨由一個系統進行管理，解決了跨行之間保證金存放的問題。每一個銀行只須要在保證金系統中存點錢就能夠了。保證金系統也有兩種模式。先看看比較好理解的第一種模式：

在這種模式下，銀行先把一部分錢存放在保證金系統裏面，同時銀行內部創建一個虛擬帳戶，記錄存放了多少錢，主要是方便對帳，萬一這個保證金系統錢算錯了怎麼辦。你能夠想象一下，銀行是很小氣的，爲啥願意把錢存放到這保證金系統裏面，這部分錢幹啥很差，可以銀行這麼幹的只有國家了，這個系統就是央行的備付金管理系統。每一個新增的銀行都要存一份錢在這裏。

另一種方案是倒過來思考，既然沒有牛逼的央行做支撐，那能夠在每一個商業銀行都創建一個帳戶，用這個帳戶負責和銀行進行清算。每新增一家銀行，就在那個銀行裏面開一個保證金帳戶。

這兩種方式有本質的不一樣，一個是銀行把資金的一部分轉出到保證金，銀行創建虛擬帳戶和保證金裏面真實的資金映射。一個是保證金系統把資金轉出到各個銀行，本身內部創建一個虛擬帳戶和銀行中真實的資金帳戶進行映射。這個間接的銀行了後續的對帳機制，這裏先不敘述。

全部的第三方支付公司跨行清算的流程都是第二種方式，只有國家級清算公司（好比銀聯）是第一種方式，這是一種資源和權力上的不平等，不過是能夠理解的。

清算系統

保證金系統解決了保證金存放的問題，接下來就是解決如何清算的問題。假設保證金轉帳是實時的，就要面對上面說的問題，保證金不夠的狀況下，跨行交易是成功仍是失敗。這是一個業務上問題，有不少種解決方案，咱們暫不說。從技術上來說，若是每一筆交易都要保證金實時記帳，那麼保證金系統的負載太大，事務如何保證等等一些列的問題。因此一個最簡單的方案就是：一天結算一次。

天天由一個系統記錄這些跨行交易信息，彙總出來，統一記帳。這樣一天只須要調用一次保證金系統便可。那麼整個清算過程則是下面的流程：

• 1 系統T日發生建行和工行的跨行交易100

• 2 清算系統T+1日彙總T日工行和建行之間發生的交易明細數據，而且發這些數據發給建行和工行進行確認

 

• 3 工行建行分別對明細對帳確認以後，通知清算系統確認交易明細無誤，清算系統開始清算，調用保證金支付系統轉帳。
• 4 清算完成以後，工行和建行分別獲取保證金系統的真實金額和自身系統內部的映射帳戶進行餘額對帳。

 

清算中心最主要幹得事情就是統計誰欠誰多少錢，以及觸發保證金系統的調撥操做。

 

對帳流程

對帳包括兩個部分，一個是跨行交易明細的對帳以及保證金餘額的對帳。

首先要思考的是：對帳是誰發起的 ？ 這個是瞭解對帳的本質。

咱們舉生活中的一個例子，咱們把錢投資到一我的，那我的負責公司的平常運做。你確定會主動了解公司的帳務，由於那個是你的錢。對帳的發起人也是如此，對於銀聯的清算過程，對帳的發起者是商業銀行，由於你把錢放在保證金系統裏面，這是你的錢，你須要去關心這個的，銀聯可不關心這個。

對於另一種保證金系統，把錢放在各個銀行裏面了，那麼對帳的發起者就是這個保證金系統維護者了。目前廣泛的第三方支付公司都是這個模式，因此他要找各個銀行要結果明細進行對帳，確認本身的資金安全無誤。

 

以上就是一個簡單的跨行清算系統的雛形，從一個就簡單的例子入手，說明一個清算過程。目前銀聯的第三方支付公司的清算過程大體如此，可是實現細節遠比這個複雜。可是一個基本的清算系統的本質模型大致上是不會變的。固然這個只是對於同幣種的清算，不一樣幣種或者虛擬貨幣的清算會涉及到匯率的問題，這些就很複雜，有機會在研究一下，後續在分享。

PS：以上不少名詞都是本身的隨意寫的，裏面不少專業名詞這裏不說起，有興趣的能夠本身去了解。