九卦 | 銀行互聯網貸款業務進件如何管理？

作者：老古成都（九卦金融圈專欄作家）

編輯：金明正

來源：老古成都

這兩年有著越來越多的傳統銀行，正在探索實踐開展線上信貸業務（也稱互聯網信貸業務），包括整個流程為純線上的信貸業務以及入口端部分獲客流程是與線下場景相結合的信貸業務。

不管是哪一類的線上信貸業務，強調的都是客戶體驗。因此都是採納客戶自助線上操作以及後續盡可能系統自動化流程的模式。客戶自助操作發起的任何請求，對於後臺系統來說則都是一次某種意義下的業務進件（一般也稱為申請進件），而自動化流程的關鍵就是對於各種類型的申請進件進行數據驅動下的決策，通常也叫做審批。

在這種模式下，對於業務進件的管理，其系統所擁有的功能精度和所提供的服務效率就顯得十分重要。筆者特站在傳統銀行自動化審批決策的視角上，總結以往的經驗，就這個問題的一些細節展開討論。

線上信貸業務的特點及業務進件之龐雜性

首先，那幾個有互聯網基因的新成立的民營銀行如微眾銀行、網商銀行、新網銀行，或幾個帶頭探索走在市場前列的全國性或股份制大行，有著相對完整的自建的或基本上屬於自控的線上信貸獲客渠道，對於大多數開展線上信貸業務的普通的傳統中小銀行，基本上都沒有屬於自己的獲客渠道或場景，都是需要通過與有獲客能力的持牌金融機構開展聯合貸款，或者直接與有良好純線上或線下線上相結合的獲客場景的互聯網類平臺開展合作並由合作方承擔助貸導流一類的角色。這樣的話，在客戶線上發起自助申請後續的數字化審批則是依靠從合作方傳遞過來的業務進件和相幹數據。

第二，大多數傳統銀行，存在互聯網金融相幹的技術人員和數據人員匱乏的問題，並且這個問題也一時半會無法解決。而進入線上信貸業務領域哪怕僅僅只是做一些業務嘗試，對於培養人才規劃業務轉型與升級，也就是越早越好。在這種背景下，傳統銀行與渠道合作方的深度合作在所難免。

這種深度合作就自然而然地產生了深度應用渠道方通過借錢人申請場景獲取及聚集的數據的需求，以及有時候還不得不被綁定了同時應用渠道方自己通過場景之外的第三方數據供應商所獲取和整合的數據，以保證總體合作業務成本在合理水平。

第三，目前市場上在為傳統銀行提供獲客導流助貸服務的平臺也有很多家，其中的確有幾家擁有自我閉環場景且流量充裕，但因其具有某種壟斷性，廣大傳統銀行在與其合作中始終處於商務方面的劣勢地位。而進一步，監管層面也一再希望傳統銀行在選擇獲客導流的助貸服務時候，要把握好集中度。因此客觀上傳統銀行也是希望同時與多家獲客導流助貸平臺合作。然而各家平臺所涉及的場景數據和客戶線上申請流程細節都各不相同，其結果也一定是對於銀行來說線上信貸業務的業務進件和所涉流程與數據往往是八門五花。

第四，從提供獲客導流助貸服務的合作平臺來說，都是希望能夠同時為多家提供信貸資金的金融機構開展合作。從希望通過助貸平臺來獲取信貸服務的借錢人來說，也往往希望能夠通過平臺嘗試多家金融機構以求得較高的最終通過率。因此，在目前尤其是傳統中小銀行與獲客導流助貸平臺的合作中，在借錢人客戶發起自助申請的界面上，很難見到從頭到底幾乎隻屬於一家合作銀行專用的申請流程，而往往只是合作平臺自己的申請流程然後在流程稍後端的某個節點再將客戶分發並導入具體一家銀行的嵌入在助貸合作平臺前端的專用流程。

第五，監管層近兩年一直在強調，商業銀行與各類助貸機構開展互聯網貸款業務的合作，必須做的風控不能外包。在這樣的嚴監管要求下，即便是為商業銀行提供獲客導流助貸合作的各類平臺自己也為了風險管理的目的做過一道篩選，商業銀行必須要建立自身的二道風控流程或終審風控流程。在有條件的情況下，也是盡可能充分利用由合作平臺提供的數據，結合合作平臺的前端申請流程，完成銀行自己的自動化或準自動化的風控審批流程。即使是對於不少能力不足的中小銀行，也還是都要求先將業務進件所相幹的數據先接入進來。這樣的話，對於業務進件及其攜帶的數據，商業銀行都需要落地到細化的層面。

第六，在自動化模式下的線上信貸業務的申請流程所提供給後臺系統的業務進件，本來就隨著線上信貸業務的不同產品、不同申請類型、不同自助操作環節和不同輔助數據的接入，有著很多的不同。可以有授信額度或單筆貸款資格申請、額度項下提款資格申請、放款驗證申請、提前還款申請和提前終止額度申請等等。有的時候助貸平臺的流程，還會出現預申請的流程。有些流程又會中間被折回前端合作平臺並需要先完成某一個插入的操作才能繼續等等。

總之可以看出，傳統銀行開展線上信貸業務，在業務進件及所攜帶入的數據方面，在業務進件的系統流程方面，比起傳統的線下信貸業務來說，要龐雜得很多。

進件管理與信貸管理主系統分離的理念

基於線上信貸業務在業務進件處理端的龐雜性，尤其是所涉及的數據的多樣性和流程的多樣性，筆者一直認為在系統層面，進件管理所需的功能要與信貸業務管理所需的其他主要功能，盡可能在系統架構上分離開，並且業務進件管理自身能夠成為一個完備的子系統或系統模塊。

這裡指的線上信貸業務管理的主要功能，是指包括額度帳戶管理、貸款帳戶管理、支用管理、放款回款管理、還款計劃管理、利息罰息核算結算管理、逾期狀態管理、授信和貸款合同管理、擔保與理賠管理等一系列直接與每一筆貸款層面相幹的管理功能。如果還有聯合貸款業務的話，則可能還涉及到在每筆放款層面的後續與聯合出資方的清算和對帳等。部分線上信貸業務平臺還可能包括徵信上報管理的功能。

在傳統線下模式下，客戶來銀行申請信貸服務，首先由客戶經理負責進行一系列的線下審核步驟。當客戶經理將客戶的這筆借錢需求錄入系統時候，基本上是已經有了這筆申請最終會被審批通過的眉目。系統中錄入的貸款申請最終依舊會作為拒絕記錄留存下來的占比不高。貸款資格審批通過後的放款、提前還款和提前額度終止等客戶需求，基本上也都是屬於客戶經理在系統中在客戶貸款帳戶下面的一個操作而已，不存在數據和自動化流程方面的龐雜性。

所以我國以往傳統商業銀行的個人信貸管理系統，通常是不需要有專門獨立出來的針對信貸申請進件的管理模塊。更也有個人信貸平臺是將信貸客戶的管理和催收的管理，都強耦合在一個系統框架內的。

不過以往在信用卡業務管理系統中，已有不少較大規模的商業銀行，採用了將發卡系統和主卡系統分離的模式。這裡的發卡系統其實就是一個獨立的業務（申請）進件管理系統。因為在信用卡的業務中，多年前即便是尚未採用數據驅動自動化審批的模式，但已經採用了後臺集中審批的模式，由此也造成了在審批環節，可以產生大量的申請進件被拒絕案例並將長期留存在系統中，而對於歷史拒絕案例與原因的分析則對於標準化的風控框架是必不可少的。隨著技術和理念的不斷更新，也進一步建立了在發卡系統之上的以決策引擎為核心的自動化審批系統或稱為風控系統，並且是以在發卡系統中的工作流程管理來驅動對風控系統的調用。

所以我們看到在今天的互聯網信貸業務系統的解決方案中，不少解決方案就像是從信用卡業務系統解決方案中衍生出來的。不少線上信貸平臺，就是將業務進件管理、貸款帳務管理、智能化風控管理（審批決策管理）、外部大數據管理、互聯網客戶管理和催收管理等，都各自以獨立的模塊來設計和配置，從而形成一個完備的線上信貸業務平臺。

而更進一步，為了滿足商業銀行更為有效地與各種外部場景相互結合，目前比較熱門的開放平臺，其實也可以理解為是我們這裡所指的業務進件管理的一個強力提升。在開放平臺上，銀行所希望的是具備一套盡可能標準化的接口去對接眾多的外部信貸場景。關於將業務進件的管理提升為開放平臺，筆者在此不予展開。

但當我們回頭來看國內傳統銀行，其中大多數是沒有能力為了很快開展線上信貸業務的探索就去建設一整套完備的系統平臺，不少傳統銀行還都是採納從現有的系統群中盡可能去做一些改造和增添模塊，或者還是擺脫不了傳統個人信貸系統的思路來簡單設計線上信貸的業務系統功能需求。同時，一些參與線上信貸業務系統建設的傳統開發商，也都還習慣於只是在傳統的業務邏輯和系統框架長進行改造。

隨著市場上對於線上信貸業務的數字化風控和自動化審批的依賴性的普遍認可，現在絕大多數線上信貸平臺已經實現了運用獨立的決策引擎進行數字化風控策略及其模型的部署和決策，但一般傳統銀行還尚不能全力搭建完備的開放平臺。因此，優化線上信貸業務場景申請進件的管理，則應該成為一項重要且現實可行的工作。

線上信貸業務進件管理系統的重心

筆者認為，線上信貸業務的業務進件管理系統的重心，應該就是配合和支持自動化決策的落實。業務進件管理系統將從客戶申請端及合作渠道端傳送過來的各種數據及其每個申請子流程的相幹環節節點的狀態資訊予以整理好，並且在自身系統中設計和配置好業務工作流程的調用，為自動化審批決策系統進行風控決策和其他相幹業務決策提供服務。

傳統個人信貸系統中即使有的申請管理模塊，因實質上的審批決策是靠人工在做的，故其主要作用往往就是為後續的貸款帳戶開立核算結算這些貸後業務主要功能提供資訊過濾，所以一般也就結構不龐雜。但是對於線上信貸業務的整個系統平臺來說，業務進件管理這塊對於後續的貸款主要管理功能所起到的銜接作用則要相對小於對於自動化審批決策所起到的銜接作用。

對於線上信貸業務來說，尤其是對於與多方獲客導流渠道合作的線上信貸業務來說，其實貸款產品本身核心要素與傳統信貸業務相比沒有多大的不同，還就是圍繞著諸如放款額、利率、期限、放款方式、還款頻率與方式等等的參數配置，通過業務進件管理系統需要傳遞到貸款業務主系統去的參數不見得增加多少，並且也還基本上屬於標準化的。而變化多的都是前端渠道的場景特性及其由此帶來的客戶特性，由此需要在自動化審批決策系統中使用的數據和資訊增添不少，並且往往是八門五花非標準化的。

當然線上信貸業務的自動化審批決策在起作用的時候，也還是非常依賴於非申請發起渠道傳送過來的數據，這個是今日線上信貸業務的特點，與傳統信貸業務的管理系統很不一樣。不過現在一般開展線上信貸業務的傳統銀行，基本上都已經有了獨立的外部數據接入管理模塊，並且與信貸業務主系統是分離的。進一步，個人徵信的獲取和解析也都是分離的。而比較容易受到疏忽的則是業務進件管理自身這一塊。

線上信貸業務的文檔保管存儲也都是採用電子文檔。對於與獲客導流場景方合作的線上信貸業務，其電子文檔也會是多種多樣並且格式很不一致。這些文檔中除了授信合同與貸款合同，還有比如貸款須知確認書、徵信和第三方數據獲取授權書、身份證及個人在借貸現場照片、個人持消費貸款對應消費購置產品或發票的照片、個人與消費場景分期貸款店員的合影、借錢人個人合規承諾視訊錄像、消費退貨或撤銷憑證等等，若業務有第三方的融資擔保公司參與並提供保證保險的話，則還有諸如對應於每筆貸款層面的保證保險協議的電子文檔等。所有這些既然都是電子文檔，都是需要在貸款審核審批環節或貸款發放環節作為對照對比校驗使用的，則都應該建立起相應的電子文檔存儲與索引功能。

另外還有一點，所有上述這些電子文檔的獲取節點和傳送節點，又也都是很不統一的。

一般地講，除了授信合同和貸款合同，上述提到的其他各種各類的電子文檔，都是在申請審批過程中使用的，與貸款業務管理的主系統功能則關聯度不大，並且在線上信貸業務整體中，的確存在大量的業務申請進件最終並不能被批準通過從而最終不需要在系統中建立起相應的貸款帳戶。所以此時建立起獨立的業務進件管理系統，則可以把這些附帶的各種各類與申請審批相幹的電子文檔也一並管理起來，而讓線上信貸業務的主系統模塊專註於在每筆貸款批準發放後的綜合管理。

獨立的業務進件管理系統，除了直接支持審批決策系統的決策流程運行決策之外，還有一個重要作用，就是支持線上信貸業務對於申請進件和合作渠道綜合狀況的實時監控和歷史分析。傳統個人信貸系統在這方面是很弱的，一般現在銀行擁有的綜合監控系統還就是主要針對貸款產品層面的一些主要指標。而在開展有大量渠道合作方的線上信貸業務中，有很多細節點需要監控和分析，包括對於歷史拒絕案例的分析都很重要。這些與申請進件直接相幹的原始資訊的積累和合理存儲，最好是由業務進件管理系統來實現。

做好線上信貸業務進件管理的抓手

筆者認為，做好線上信貸業務進件管理的關鍵抓手是，對於線上信貸業務從前端發送過來的申請進件，做好其分層分類，重視和理順各個單元之間的邏輯與流程關係。這裡所指的前端包括在客戶申請貸款時候所面對的線上自助界面，以及獲客導流場景合作方的後臺系統。

在業務進件管理系統中，要分別樹立起申請過程流和申請進件流的概念，並將申請過程流和申請進件流與申請進件管理系統所負責的工作流以及審批決策系統所配置的決策流相互對應起來。申請過程流更多地是對應一個業務需求需要完成的整個業務流程，而申請進件流則更多地是指在系統中相對應的流程的概念。

對於線上信貸業務，不管其獲客場景如何龐雜，不管其貸款產品設計如何花樣，對於由前端向信貸業務平臺發起的各式各樣的申請需求，就完成申請審批並最終可以傳遞到信貸業務主系統的角度來看，無非就是可分為額度申請（或單筆貸款申請）、額度項下提款申請、放款（驗證）申請、提前還款申請和提前終止額度申請等。在不少場合，放款申請也是由單筆貸款申請或額度項下提款申請通過後直接觸發的，不過在有諸如第三方擔保公司參與的情況下，或有多家金融機構共同出資的聯合貸款情況下，可能就需要多一步最終放款申請並由系統完成放款驗證審批。

這裡也註明一下，不是必須需要所有的申請進件的最終審批都是由架在申請進件管理系統上的審批決策系統來完成的，一些上線後一般不需要再去做調整相應決策規則的而只是簡單判別極少數資訊是與否的審批步驟，由業務進件管理系統自身的自動化工作流程中的程序直接判斷往往更有效。但是我們在此解釋整個相幹的管理理念，則還是通過強調業務進件管理系統與審批決策系統之間的協作來解釋。

然後一個申請進件流則是以由前端客戶界面操作或合作方平臺界面操作或合作方平臺系統觸發所發起的一個申請請求為起點，一直到由審批決策系統給出一個結論性的決策結果並返回前端或由前端通過異步查詢獲得決策結果為終點的一個延續性流程為一個單位。

如果由於在整個申請過程中前端需要做一些進一步的配合操作，則一個完整的申請過程流程也可能需要分拆成多個申請進件流來完成。在這種情況下往往有一個特點就是，前面一個申請進件流所獲得的審批結果是拒絕或否定的話，則整個申請過程流程到此為止不會再繼續下去。

由於數據調用和接口等等的原因，由於決策結論與外部數據調用成本之間的考慮，還由於目前的自動化審批中依舊會考慮穿插一些人工輔助的審核步驟，所以進入了申請管理系統後的一個申請進件流，也可能是對應於多個審批決策系統中的審批決策流，並且由申請管理系統的工作流管理功能來實現分派調用管理。

於是一個申請進件流的最終狀態，則是在完成了所調用的多個審批決策流之後的最終狀態。而一個申請過程流的最終狀態，則是完成了所有申請進件流後的最終狀態。

我們有必要要說明，其實申請過程流的最終狀態亦可以區分為兩種，一種是實際的最終狀態，一種是我方的最終狀態。因為在多方的合作過程中，一個申請過程流的最後一段申請進件流可能是在我方有了最終狀態結果後的因為合作方繼續需要做某項審批決策後的結果反饋，其實對於我方來說此時接下來並沒有實質性的審批決策，而只是一個登記最多加個驗證而已。

上述這種情況常常發生在我方審批通過後合作方繼續做一次審批然後再進入放款。以筆者的經驗來看，此時這個申請進件流可以不被看成是前面的貸款申請過程中餘下的一個申請進件流，而看成是另外一個放款驗證申請過程下的申請進件流。這樣的區別就做到了在上一邏輯層面的分離。

既然我們講到線上信貸申請進件管理系統的重心應該是支持（我方）的自動化審批決策，那麼對於我方結果狀態的關註要遠比對於實際結果狀態的關註來得重要。當然如果在上一邏輯層面就分離了的話，則也容易理解和處置。

總之，做好線上信貸業務進件管理，不要簡單地將各種類型各個層級的申請進件及其相幹資訊捏在一起，搭建清晰的分層分類數據結構，則將非常有助於線上信貸業務的自動化審批決策及其後續的監控與分析，從而能夠更有效地提升傳統銀行自主風控的基礎能力。

點「在看」給我一朵小黃花

預覽時標簽不可點