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

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

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

跨行取款流程

張三是工行的持卡人，他需要取現金，但是找不到工行的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：以上很多名詞都是自己的隨意寫的，裡面很多專業名詞這裡不提及，有興趣的可以自己去了解。