前段時間，終於完成了兩個 P2P 平臺的銀行存管設計，總算可以歇一下了。今天對工作做一個覆盤，對P2P 業務流程設計進行一個梳理。
「流程分析」主要分為「業務流程」和「頁面流程」。「業務流程」（Transaction Flow）是通過產品經理在業務調研的基礎上，對相關業務點進行梳理並鏈接呈現的過程，更多用來與後端開發同事對接業務邏輯。「頁面流程」（Page Flow）則是前端用戶界面跳轉的展現，更多用來與 UI 設計師、前端工程師溝通。本文的「流程分析」主要從「業務流程」這個方面對 P2P理財端核心流程進行分析。
P2P 理財端業務的核心流程
應該這麼說，對於 P2P 平臺來說，功能模塊並不複雜（如果你非要在 P2P 平臺上加一個社交/電商/即時通訊，這就不在我們討論的範圍內了）。其核心是「投資賺收益」，核心業務就是「投資」和「資產管理」。我們就主要從「投資」的角度去梳理下其在銀行存管系統下的業務流程。
在設計業務流程的時候，一般有兩種展示方式：1.是單純的用戶操作行為流程圖，這種圖一般只涉及用戶角色，不涉及跨部門或者跨功能的業務展示。2.是泳道圖，這種圖按照職責或功能將活動進行組織，可以直觀的描述整個系統中的各個子系統或者各活動之間的邏輯關係，便於使用者理解業務邏輯，適合跨部門或跨功能的業務展示。本文將主要以泳道圖來為大家展示。
設計基於銀行存管系統的 P2P 平臺時，有一個作弊碼：信息流在平臺，資金流在存管。記住小璋的這「十二字真經」（不知道是不是原創，如有雷同，純屬巧合）理論上可以應對各家銀行的存管系統。不多說先上圖：
本流程主要以投資用戶在平臺的操作流程（「用戶註冊並實名開戶」-「充值」-「投資」-「提現」）作為分析的重點，這個流程也是整個平臺對接存管系統變動最大的地方。
用戶註冊並實名開戶：
這裡需要關注的有三點：
- 用戶需要在業務系統（即平臺）和存管系統（即銀行）分別開立賬戶，開立存管系統賬戶的活動可以隱藏在實名綁卡的步驟中來完成，一般情況下，這一步驟需要跳轉銀行的頁面來完成。也有部分銀行徹底將所有業務的步驟均隱藏在平臺的頁面內，全部數據通過接口方式傳遞（平臺—>銀行），在一定程度上提升了體驗，可以做到用戶的「無感知」，但是也容易引起用戶的懷疑：你究竟做沒做存管？不同的銀行有不同的考慮，這一點上來看，並沒有絕對的優劣。
- 實名信息的認證，同樣，不同銀行有不同的認證方式。有的銀行依託公安機關的戶籍系統（比如使用「國政通」），僅需進行身份認證即可完成開戶，開戶完成後在由用戶進行出入金借記卡的綁定。另外一些銀行直接利用合作的支付通道來通過銀行卡四要素（或三要素）認證，來完成出入金借記卡的綁定。
- 途中將返回結果合併成一個（實名開戶和綁卡結果一起返回），但在實際業務中，可能有多種情況，甚至還有需要平臺主動查詢的可能，需要產品經理根據存管系統接口實際來設計。
充值
說完開戶，用戶就該充錢了。這是一個平臺運營者最激動的時刻（滿眼的小錢錢），畢竟只有用戶資金進入，這個平臺才能真正的運轉起來。
這裡需要關注的有兩點：
- 判斷是否綁卡的步驟需要根據存管系統要求來設計，我遇到過有的銀行並不會給平臺返回用戶是否綁卡（對，你沒看錯）的信息，那麼這一步就會有存管系統來判斷，業務系統只需要進行「充值轉發」就可以了。當然如果提前在業務系統裡進行判斷，用戶沒有綁卡直接跳轉綁卡頁面，或提示用戶綁卡。這樣的流程比較流程，體驗上也比較好。
- 大家可以看到，在流程圖中，不管充值成功還是失敗，業務系統都會進行記錄，這一點也需要注意，不但可以為用戶提供更詳實的展示外，一旦出現賬務處理異常也可以很方便的去排查。
投資
用戶開完戶，充完錢，我們一定要讓他花出去！那就涉及到「投資」流程了。這也是整個業務中「核心中的核心」（張老師敲小黑板，注意聽講啦）！
這裡有一點注意：
- 標的可投的校驗：為了防止出現溢標（就是投資額超出實際需要募集的金額）的狀況，一般情況下，需要兩次以上的校驗——前端根據可投額度校驗一次，對大於可投金額的資金直接提示；後端在收到前端傳過來的值後，在進行一次校驗。雙保險，更安全！之所以說是兩次以上，是因為存管系統可能還會對標的實際募集金額進行校驗，有的銀行不允許溢標，有的銀行又允許溢標。不過從實操和法律規定上來看，不溢標會好一些。其實在未收到結果時先減少可投餘額，再根據結果反饋進行調整和最後當「可投金額=0」時變更標的狀態，同樣也是為了防止溢標。
提現
用戶投完資，標的也到期正常還款了。理論上就應該進行下一步了，也是作為產品和運營最不想看到的一件事（你們看到我的淚了麼？每天就想著怎麼不給用戶錢，呸，怎麼能不給錢呢。我們是想讓用戶復投，不提現……）。但是最終用戶還是要提現的，真不讓提現那不是詐騙或者搶劫了麼，張小璋一直是遵紀守法的好公民！
這裡需要說明的兩點：
- 因為我們的系統經歷了「支付通道」—>「第三方支付託管」—>「銀行存管」的變更，所以在提現審核之後立刻就減少用戶資金記錄後期在根據反饋結果進行調整的做法是個歷史遺留的問題，主要是在支付通道的時候防止用戶在操作之後結果反饋之前的時間內（可能很短，也可能很長），利用時間差不斷提現，造成不必要的資金損失。其實大家可以理解成在沒有記過之前先凍結掉提現金額。
- 業務系統的提現審核，這一步其實在存管體系下的作用越來越小，畢竟資金在銀行。不過為了用戶安全，還是可以根據業務需要由平臺相關業務人員或者業務系統進行一次提現審核。還是那句話：雙保險，更安全！
另外兩個重要的地方
上邊的四個步驟基本涵蓋了用戶的在平臺的「全生命」流程，但是對於平臺來說，參與到這個流程中還需要兩個重要的步驟：「標的管理」和「還款」
標的管理
「標的管理」又分為「標的發佈」和「標的成立和出賬」兩塊。一般情況下，「標的發佈」時，存管系統介入較少，僅需要「業務系統」將標的的信息傳遞給「存管系統」進行存儲。而「標的成立和出賬」因為涉及到資金操作，所以會較多的涉及存管系統。廢話少說，上圖：
這裡需要說明的兩點：
- 流標流程是一個單獨的流程，但是一般平臺上用的幾率不是很大。在這裡不細說，其實就是解凍用戶資金，並原路返還，這標的廢掉的一個流程。
- 開始計息的時間：這一點大家可以根據自己的業務實習來處理。有投資後計息、標滿後計息和圖中表示的出賬後計息多種。
標的還款
回款會涉及到正常還款、提前還款、墊付和逾期。以正常還款為例。
這裡有一點需要注意：
- 借款人還款的時間：因為銀行清結算需要時間，所以借款人還款時間一定要早於最晚的標的還款時間，不然會有極大的可能造成因銀行清結算延誤造成標的逾期。
最後要說的話
不知道大家有沒有注意到，我畫的流程圖中反覆用到一句話：記錄結果並返回給用戶。這可不是我偷懶，在「存管系統」中業務平臺僅僅作為信息流的記錄者，並不實際操控資金流。甚至你完全依賴銀行存管系統的記錄也是可以的（比如我就這麼幹過……）。但是平臺最好還是有一份記錄，不但可以幫助運營同事通過數據去分析用戶，更重要的是這些數據是賬務系統中用來對賬重要數據。
呃呃呃，我現在正在想之後寫什麼？不過現在已經有了選題。寫點溼貨，大（zhuang）氣（bi）一點，不在這麼侷限於業務層。也是最近和一個朋友在一起討論一件很複雜很費腦筋的事後的一點想法。歡迎大家繼續關注。沒事點個贊啥的。
#About Me
張小璋，野蠻生長成世界500強企業供應鏈金融產品經理的法語學畢業生。公眾號：張小璋碎碎念（ID: SylvainZhang ）。一直在互聯網金融公司從事產品經理工作並負責互聯網金融產品線，深耕互聯網金融和區塊鏈領域。「PMCAFF」、「人人都是產品經理」專欄作家、「PmTalk」簽約作家。
閱讀更多 張小璋 的文章
