我從事銀行IT行業十餘年，目前從事銀行IT項目管理的工作，後期我會持續輸出關於銀行業務和IT系統知識及項目經驗分享的文章和視頻，感興趣的朋友可以關注一下！
Hello大家好！我是程序員瓦力，專注分享商業銀行業務和IT系統知識。
今天的文章主要想和大家聊一聊銀行產品與賬戶的關係，為幫助大家理解後面的內容，咱先來看看關於銀行產品、賬戶的概念。
一、相關概念
1、產品
銀行產品是指由銀行創造、供市場和客戶選擇、能滿足客戶進行金融交易和服務的各種需求、銀行可從中賺取各種實際、潛在收益的綜合金融服務。
2、賬戶
銀行向客戶提供的產品服務有很多，一部分產品在客戶購買或享受服務時會引起客戶在銀行的資產、負債或其它非貨幣權益類東西的數量變化。銀行賬戶就是記錄這些資產、負債或權益類東西的現狀與變化歷史的電子簿記。
3、核算
銀行的核算功能就是對各種銀行賬戶進行簿記。
銀行的核算可分為兩大類：明細核算和綜合核算。對應的銀行賬戶也可以分為兩大類：明細核算對應分戶賬，綜合核算對應總賬。銀行客戶的分戶賬與銀行客戶在銀行的某類資產、負債或非貨幣權益類東西對應，記錄其現狀及變化歷史；銀行總賬根據銀行管理會計的要求，按科目分設，部分科目與銀行相應產品對應，可記錄銀行不同產品不同分類粒度的總體銷售現狀與變化歷史。
二、銀行產品與銀行賬戶的關係
根據上述定義，我們可以進一步分析銀行產品與銀行賬戶的關係：
1、 產品與分戶賬的關係
產品與分戶賬的關係
從上圖可見，產品與分戶賬的關係有幾種：
- 一個產品對應一個分戶賬
如：存款類產品對應客戶的存款分戶賬。對某一客戶而言，某類存款產品對應他的某個分戶賬。
- 一個產品對應多個分戶賬
如：跨賬戶的結算產品。這類產品可以對應某一客戶的幾個不同賬戶，也可以對應不同客戶的不 同賬戶。
- 一類賬戶對應多種產品
如：存款類賬戶。某客戶的存款賬戶，除了可以對應存款產品外，還可以對應各種結算產品。
2、產品與總賬的關係
產品可以按需要與要求進行不同粒度的分類與細分，總賬裡與產品對應的科目，也可以按需要與要求進行不同粒度的細分，以與產品形成對應關係。舉例如下：
不同粒度分類的產品與不同粒度細分的科目的對應關係
從上圖可見，如果從管理精細化的要求出發，我們把產品進行細分，那麼，總賬的對應科目也可以進行同樣的細分，以滿足管理會計分類管理的要求。
三、產品與核算的分離與難點
在銀行電子化進程的初期，銀行業務的計算機處理基本是模仿人工操作流程進行同樣的處理。那時候的銀行計算機應用系統，在架構上，產品與核算、特別是與明細核算是緊耦合的。
實際上，核算，尤其是交易系統的綜合核算，是銀行內部管理的需要，與銀行客戶的關係不大。此外，銀行交易系統綜合核算的具體實施細則，會根據銀行的管理水平、不同時期市場與監管的需要，與時俱進、不斷調整。如果在應用架構上與產品耦合太緊，那麼一旦核算規則變化，就會引起交易程序的大量修改。所以，筆者在上世紀90年代初就提出，銀行交易系統的應用架構應該實行產品與核算分離。這一觀點也是當前業界普遍認同的觀點。
對於銀行信息系統來說，在應用架構上把產品與綜合核算分離，相對比較容易。據瞭解，當前許多銀行的信息系統、許多在建的銀行新系統，均號稱已經實現了產品與核算（綜合核算）分離。但信息系統在應用架構上真正實現產品與明細核算分離，也許是筆者孤陋寡聞，好像還沒有聽說過。
對比起綜合核算，在架構上實現產品與明細核算分離，確實比較困難。需要考慮以下幾個因素：
1、產品與明細核算關係密切
首先，相對綜合核算，產品與明細核算的關係要密切得多。為了安全與可靠，所有涉及核算的交易，幾乎都要求實時同步進行明細核算，也就是需要實時同步更新明細核算對應的分戶賬。反觀綜合核算，如果該交易不涉及嚴格的風險敞口或頭寸管理，完全可以異步或事後更新相關科目。
所以，要把產品與明細核算徹底分離，就是要把兩件必須同時做的事情分開到兩個地方去做，如果沒有充分理由，好像沒有這個必要。
2、概念模糊
要實現產品與明細核算分離，首先要弄清楚，什麼是產品，什麼是明細核算。
關於什麼是產品、賬戶、核算，本文在開頭已經給出相對嚴格的定義，特別是綜合核算，概念比較清晰。但對於一些具體的功能，應該算是產品，還是核算，好像又不容易分清。如果沒法分清，又如何分離呢？舉例來說：
（1）非核算類的賬戶修改
非核算的賬戶修改，包括賬戶的開銷戶，算是產品還是核算的功能？
根據核算的定義，核算是對賬戶進行簿記。狹義的核算，僅涉及核算簿記的實施。但簿記動作從廣義上講，可以包括所有對賬戶進行增、刪、改動作的實施。
應明確的是，所有對賬戶的增、刪、改、查，包括開銷戶的操作，其實施細則、運算過程等，應該由產品負責。核算通常僅根據產品的簿記要求，用產品的運算結果，對賬戶進行更新。
（2）利息計算、計提
其實上面第（1）點已回答了這個問題。利息計算涉及的要素繁多，包括產品的種類、客戶持有產品的狀態（如沒到期、逾期）、特殊客戶與特殊賬戶的個性化優惠等。從概念來說，所有涉及利息的計算與計算規則均應該是產品的功能。如：存款賬戶的利息計算應該由存款產品負責，貸款賬戶的利息計算應該由貸款產品負責。至於明細核算，只負責對利息計算的結果進行簿記。
當然，在具體落地方案中，可以綜合考慮，進行一定調整。例如，如果是批量計息，且計算的方法與利率取得的途徑是標準的話，那麼在設計物理架構時，批量利息計算模塊可以放到核算系統中，以提高效率。在這種架構下，產品提交利息計算要求與計息標準，計息動作與利息簿記則同時在核算系統裡進行。
這裡涉及一個概念：信息系統架構的規劃有不同的模型層次，包括概念模型、邏輯模型、以及物理模型。產品與核算的劃分，也有這幾個不同的模型層次。概念模型上屬於相同的東西，在落實到物理模型時，未必都需要放在一起。反之，在物理上放在一起的東西，在概念上未必是同一樣東西。
（3）賬戶關係
客戶在銀行裡的分戶賬，有些相互之間存在某種關係。包括：特定的轉賬關係，或特定的主從關係等。例如，個人對外轉賬時，一些銀行會提供所謂的註冊賬戶的概念；向已註冊的第三方賬戶轉賬，其責權（安全認證、轉賬金額等）與沒有註冊的賬戶是不一樣的。又如，一些銀行對企業提供現金管理服務時，根據與企業的約定，允許企業子公司的資金按某種規則進行自動的調撥，而無需企業逐次提交申請。
從概念上來說，賬戶之間的關係屬於客戶信息裡的賬戶關係信息，該信息由對應產品去訪問核對。如上面所提到的註冊賬戶，應該由轉賬產品去訪問核對；主從賬戶關係，應該由現金管理產品去訪問核對。這些賬戶之間的核算要求，應該由產品向核算系統提交，由其進行簿記。
還有各種的具體功能需要我們去釐清其產品或核算屬性，在此就不一一列舉了。只有把產品與核算功能區分清楚，才能為在系統架構上實現產品與核算分離打好基礎。
3、應用架構的複雜度
把產品與核算分離後，應用架構在宏觀上好像簡單了很多。如下圖：
產品與核算
但在實際的編程方面，原來一個程序就把產品與核算都搞定了，現在卻要分為兩個程序、或者兩個應用、甚至是兩個不同的子系統才能搞定。既然是兩個不同的程序，之間還會存在信息傳遞的環節。也就是說，在微觀上，程序反而複雜了。
4、影響效率
原來一個程序能搞定的東西，產品與明細核算分離後，要兩個程序才能搞定，再加上信息傳遞環節，系統的開銷肯定比不分離要大。
正因為上述幾點，可能還有其他原因，所以到目前為止，還沒有聽說哪個銀行的信息系統已經實現產品與明細核算分離。那麼，長遠來看，產品與明細核算是否確實應該分離呢？歡迎大家留言討論。
我從事銀行IT行業十餘年，目前從事銀行IT項目管理的工作，後期我會持續輸出關於銀行業務和IT系統知識及項目經驗分享的文章和視頻，感興趣的朋友可以關注一下！
閱讀更多 程序員瓦力 的文章
