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

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

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

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

一、定種類，設規則

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

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

1. 定種類

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

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

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

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

2. 立規則

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

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

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

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

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

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

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

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

二、三個架構看全局

要先搞明白，我們做這個系統要實現哪些業務種類和對外能力。

系統沒開始，業務先想明白，業務想明白了，系統也就清晰了。

1. 關系架構

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

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

2. 業務架構

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

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

3. 產品架構

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

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

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

三、五大模塊定乾坤

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

1. 服務標準化

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

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

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

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

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

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

2. 規則配置化

保證金規則，關鍵是規則模型。

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

這里將規則引擎設置成2層模式：

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

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

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

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

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

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

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

3. 交易能力按需化

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

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

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

4. 賬戶管理可選擇

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

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

5. 操作記錄不可抵賴

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

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