保證金，這個詞想必大家都聽過，在日常生活中也有繳納過。本文正是為您講解“保證金”的系統(tǒng)結構，有需要的可以看看。

我想大家對保證金都不陌生，從最早的淘寶開店要繳納店鋪保證金，然后的共享單車要繳納騎車押金。

這也是平臺為了增加商家、用戶的信用等級或者風險兜底，而向收取的一筆擔保資金。

車壞啦、商家被投訴啦，這筆錢就排上用場了。

一、定種類，設規(guī)則

平臺一般會基于不同場景，繳納不同類型的保證金，這就是保證金的種類。

所以在設計保證金系統(tǒng)之前先了解清楚貴司的保證金種類以及拓展性。

1. 定種類

比如內容分銷保證金，是基于分銷市場場景而設立的，主要是為了提高分銷商的信用擔保。

再比如店鋪保證金，是為需要開店的商家設立的，為提高店鋪的信用，兜底平臺和用戶的基本權益

因此，不同的業(yè)務種類或者普通的場景需要設定不同類型的保證金。

就需要一個“保證金類型”管理，來不斷地拓展保證金類型。

2. 立規(guī)則

有了保證金類型以后，接下來就是保證金的繳納規(guī)則，也就是制定一份規(guī)范。

誰，在什么時候，什么地方，做什么事，要繳什么保證金，繳多少錢。

比如可能不同的城市消費水平不同，那么繳納的金額可能就不一樣。

不同的城市可能不一樣，比如同樣是跑滴滴，在一線城市繳納的保證金和一個五線城市就可能不一樣。

不同的服務品類可能不一樣，比如同樣是在一線城市，跑快車和跑專車要繳納的保證金金額不一樣。

比如下圖是某電商平臺針對不同品類及商家主體類型設定了不同金額的保證金。

為了通過系統(tǒng)化實現上述保證金的充值、繳納、管理等一系列業(yè)務，就需要一個保證金系統(tǒng)。

接下來，我們從業(yè)務框架、產品架構、具體模塊設計展開對該系統(tǒng)的設計分析。

二、三個架構看全局

要先搞明白，我們做這個系統(tǒng)要實現哪些業(yè)務種類和對外能力。

系統(tǒng)沒開始，業(yè)務先想明白，業(yè)務想明白了，系統(tǒng)也就清晰了。

1. 關系架構

第1個架構是關系架構，我們看清楚整個系統(tǒng)與外界“基于服務”的聯(lián)系，誰會通過什么服務來與我建立關系，我就明白了，我要做這些能力。

從圖中可以看出，保證金需要依賴商家中心的通知進行開戶，然后基于自己的規(guī)則告知商家需要繳納什么保證金，繳多少錢，以及后續(xù)的業(yè)務發(fā)生后對保證金繳納情況的檢驗查詢、違規(guī)扣除、風控凍結、審批等一系列的業(yè)務關聯(lián)。

2. 業(yè)務架構

第2個是業(yè)務架構，通過這個架構看清楚保證金系統(tǒng)與各系統(tǒng)之間更清晰的業(yè)務關系。

從圖中可以更清晰的看出來，保證金的什么服務模塊為哪些上下游系統(tǒng)提供什么樣的服務，比如為錢包提供查詢服務、為支付系統(tǒng)提供交易服務、為商家中心及風控系統(tǒng)提供基礎服務，而自己的所有服務都是基于保證金規(guī)則和賬戶為基礎。

3. 產品架構

第3個架構就是產品架構，看清楚保證金系統(tǒng)的所有功能模塊，便于后面的詳細產品設計和項目落地。

整個保證金劃分為5大模塊，分別是保證金服務管理、保證金規(guī)則管理、保證金交易能力管理、保證金賬戶管理、保證金操作記錄。

這里要特別說明的是保證金賬戶管理，如果說保證金賬戶由賬戶中心承接，那么這一部分就應該是“保證金賬務處理”的管理，與賬戶中心形成交互，而保證金系統(tǒng)就成了一個單純的業(yè)務系統(tǒng)，管理保證金業(yè)務相關的事務。

三、五大模塊定乾坤

接下來就應該針對上述的每一個模塊做詳細的產品設計。

1. 服務標準化

對于保證金服務模塊其實就是抽象出的服務種類，以標準接口的形式提供給外界系統(tǒng)調用。

例如開戶、銷戶就是來申請開通保證金賬戶，并匹配對應的規(guī)則，知道這個賬戶需要繳納多少金額的保證金。

交易服務就是充值、提現、扣除、解凍、凍結保證金的能力，這是保證金能力的核心所在，畢竟有了保證金你是要輔助業(yè)務做事情的，去兜底的。

狀態(tài)查詢是保證金是否已繳納的查詢，提供給業(yè)務側做業(yè)務的判斷，比如商家要上架商品時，需要判斷有沒有繳納足額保證金，以控制商家能不能正常上架商品。

賬戶查詢是提供給錢包使用，獲取保證金的賬戶余額、流水數據。

報表服務是提供給財務使用，用于保證金業(yè)務的會計記賬。

2. 規(guī)則配置化

保證金規(guī)則，關鍵是規(guī)則模型。

前面也介紹了，不同的業(yè)務及場景需要繳納的保證金種類和保證金金額不同，所以需要一套規(guī)則配置工具，靈活的配置出保證金的規(guī)則條目。

這里將規(guī)則引擎設置成2層模式：

第一層是規(guī)則模版層，是為每一個保證金場景，設置一個規(guī)則模版，也就是這個場景下的保證金規(guī)則需要哪些維度的參與決定。

比如條目1的含義就是分銷保證金的規(guī)則只需要配置一個參數即可，也就是品類，不同的品類保證金規(guī)則不同。

所以，一個條目能配置出多少條規(guī)則，跟該條目的參數數量以及每個參數的枚舉值有關系。

所以需要一個定義“參數”的配置，例如增加商品、用戶等級、時間等各類參數，這里就不贅述了。

在新增條目時，可以為每一類保證金類型增加一個條目，為該條目選擇需要配置的參數。

有了條目以后就是為各類保證金場景設置規(guī)則了。

比如店鋪保證金的條目是002，那么設置店鋪保證金規(guī)則時就需要配置“業(yè)務線、品類、城市”3個維度的元素，他們不同保證金規(guī)則不同。

3. 交易能力按需化

這里的能力就是交易的能力，充值、提現、凍結解凍、扣除等操作保證金賬戶的能力。

這個能力都可以做成標準化的交易能力，當然可以基于實際需要去建設，比如凍結能力，如果沒有凍結場景，那就不需要去建設。

這里特別說明一下，保證金的凍結和解凍可以做成自動化的任務，在約定好凍結和解凍的條件，定期巡檢全部保證金賬戶，然后執(zhí)行凍結或者自動解凍。

4. 賬戶管理可選擇

這是保證金的核心，前面也說了，可以保證金系統(tǒng)自己管理，也可以交付給賬戶中心承接，不同的模式下，保證金的賬戶管理要做的事情不同。

如果是保證金自己管理自己的賬戶，那么就需要做一個基礎的賬戶模塊，有余額、流水、開戶銷戶、出入賬等相應的能力。

5. 操作記錄不可抵賴

最后就是保證金的操作記錄，這里的操作記錄更詳一個保證金系統(tǒng)的日志，記錄的誰、在什么時候、對系統(tǒng)里的那個模塊做了什么。

好了，以上就是保證金系統(tǒng)的建設方法論，如何從0到1把這個系統(tǒng)做出來，你學會了么。