智能風控決策引擎-中後台設計策略1：設計原則、業務解構、服務抽象

本系列分享是基於我們SaaS平台建設中因業務需要在智能風控引擎方向的產品設計、研發建設及系統落地中踩過的坑，以及持續迭代中的業務思考和產品處理策略的覆盤總結，進而幫助大家達到以下內容。

1）澄清風控系統的相關術語概念、底層原理，概念理清了，原理明白了，我們的知識圖譜就建立起來，知識圖譜有了，我們對風控系統的很多未知和疑慮也就蕩然無存。

2）掌握智能風控的業務鏈路、業務解構、設計原則、設計策略、架構設計、迭代建設策略等；結合一些具有代表意義的實踐case（採坑、填坑打怪之路），縱向上分別從“貸前-貸中-貸後”和“准入-反欺詐攔截-信用評分-信用定價-資產定價-利率定價-電核-放款-貸後風險預警”兩個角度向大家分享智能風控決策引擎中後台的建設經驗。

橫向上從指標設計、規則設計、流程設計、策略設計、計費策略設計、用户授權設計、數據表結構設計等場景進行服務抽象；幫助大家吃透智能風控中後台的產品設計、研發建設、迭代演進知識體系，從而實務中少走彎路或不走彎路。

3）延展思維：傳統的風控模型主要是告訴你是否能放行，我們的設計策略則是除了“申請A時告訴你A是否可行”還需要做到“告訴你，A不行還有B、C、D業務可行”；智能風控系統與我們的業務推薦系統、CRM系統、信審系統無縫連接。

4）具備從0到1的“需求挖掘、業務抽象、前後端及中後台產品的整體考量及設計能力”，並能將這種優秀的產品基本功變成自己的慣性從業能力；方法論相通，空降到任何以個項目上都可快速上手併成為該領域的產品專家、賦能業務前行。

閲讀對象：從事互金行業的運營人員、風控人員、貸後管理人員、產品經理、架構師。

一、開篇三問1. 優秀的對手在哪裏？

“命中率高、誤殺率低”是考量一個風控決策引擎是否有價值的核心指標，業內做風控的頭部玩家基本都能做到這一點，不足為奇。

因為這些頭部玩家是基於海量數據（陽光手段、非陽光手段獲取的），一般的互金平台或正規金融公司限於數據獲取的能力（財力、人力、持續投入和法規的敬畏），在數據儲備方面必然落後於螞蟻、同盾、百融、天機等獨立玩家。

2. 我們的錨究竟要設在哪裏？

作為科技金融眾多中小玩家，採用大數據做風控、自動化批貸是一個必然命題；然而很多互金平台甚至所接觸的銀行、信託等合作機構依舊採用地球上最原始的方案，採購進行大數據風控；做的好的是API自動對接，做的差的是登錄商户後台人工查詢。

此外，業務不同，批貸控制條件不同，直接採用第三方大數據評測結果只能告訴這個用户有多大的風險無法做出是否要放貸、放多少款定多高利率合適——這是因為風控數據廠商不瞭解業務無法深度涉足；譬如信用貸、車抵貸、房抵貸三個完全不同的業務，信貸模型不一樣。

前者可控性差追求高可靠用户，業務特點是：優質用户（徵信無瑕疵）、低額度（5萬以內）、高利率（踩着國家線走）、短時間（最長一年，多為1個月週轉）、流程簡（秒批）；後者的業務特點是：資質有瑕疵、額度大（10萬起）、利率低（12%左右）、附加收費多（擔保費、保險費、服務費等）、流程多（下户、抵押、公證、擔保等）。

而且，我們的機構不像傳統金融或傳統科技金融，只做自己的資金業務，而是類似“淘寶”的一個B2C撮合業務，公司談不同的資金合作方給用户提供不同尺度的資金方案；這就決定我們不能像傳統風控引擎因為風控系統對用户申請“業務A”被風控拒絕而直接將客户PASS；還需要基於平台接入的“其它資金通道”向用户推薦最合適的“資金業務”，風控系統不能簡單的回答“YES or NO”,更需Recommendation；智能風控系統需要與我們SaaS平台的推薦系統、CRM系統、信審系統無縫連接，不是做業務的剎車器而是做業務的離合器。

此外，付費調用第三方API只做簡單的查詢和決策，而不對獲取的“元數據做加工入庫處理再利用”將極大的降低數據的複用價值，這不是一個有情懷的產品經理的應有的行事方式。

基於我們的業務現狀，風控只是業務中的一環，在有限財力、有限人力如何設計、落地一款“低成本、高可用、自進化、智能決策的風控引擎”是我們的產品明線。

基於我們的SaaS演進戰略、初期內部業務用、孵化成功後平滑支持外部調用，將外採數據成本平滑對沖掉是我們的暗線。

3. 你打算怎麼做？

基於我們的客觀現況，借鑑行業主流做法，我們梳理如下幾個設計原則，整個智能風控決策引擎建設將圍繞幾個原則進行迭代演進、邊行進邊射擊的策略進行落地：

1）不可漏殺：自己沒有的，外採第三方。

2）自動式梯度查詢：多級串行准入規則，上一級命中“絕對禁止”規則，自動終止流程。

3）人機耦合：命中“相對禁止”時，自動觸發人工審批機制，智能風控走完後送審人工信審進行分級審批。

4）成本節流內控：先查自有數據源，自有數據源無數據時再轉發查詢第三方數據。

5）成本開源內控：查詢第三方數據後自動更新我方自有數據源。

6）有損查詢：針對每個指標配置自有數據源的初審時效性（15天）、終審時效性（1天）參數，也即自有數據源的更新時差在初審時差內直接放行，譬如“批貸場景我方的司法引擎、公安刑事案件引擎、車輛維修事故引擎、查詢安全後則不再查詢第三方數據源”；但在平台放款節點，則取終審時效性，依舊跳過第三方，否則再強制查詢第三方。

7）可配置：所有規則的條件參數、所有流程的條件參數可配置，無需動用研發修改。

8）可審計：生產環境任意運營參數調整都需要審批通過後方可放行、歷史版本可追溯。

9）可透視：當事人可透視、規則調用結果可透視、案件質量可透視。

10）可回朔：由於數據量不夠海量、由於機器算法不絕對自信，我們對所有放款案件進行動態監控，回朔批貸指令，為後續修正算法提供“非常規數據”。

11）可商用：部分指標可對外封裝支持外部渠道調用，部分指標只對內部使用。

12）隱私與合規：數據獲取上我們採用了三種授權方式：用户主動查詢授權策略、用户被動查詢授權策略、商户保證金線下授權策略。

13）可擴展：這裏的擴展指的用户在申請“業務A（如招商銀行業務）”被風控攔截，我們要自動檢測是否符合“業務B（農商銀行放款）或業務C（X信託放款）”是否符合避免將用户一棒子打死。

14）財務互通：計費引擎與SaaS財務引擎互通，支持商户預付費（詳見《金融支付財務融合業務-實踐分享2：SaaS租户、資金賬户、財務賬套、記賬及對賬系統架構設計》、單次計費。

二、需求挖掘、業務解構1. 用户是誰？

客户維度：上班族、個體工商户、小企業主。

用户維度：運營配置人員、風控人員、面籤人員、信審人員、電核人員、貸後管理人員、產品經理、研發工程師、財務人員。

渠道維度：測試使用、自有孵化使用、SaaS商户使用、公開API市場調用。

業務維度1：消費場景、信用貸場景、車抵貸場景、房抵貸場景、供應鏈金融場景（不涉及，但須考慮）。

業務維度2：自有資金放款、銀行渠道A資金放款、銀行渠道B資金放款、信託渠道C資金放款、小貸渠道D資金放款、P2P平台E資金放款、典當渠道F資金放款。

業務維度3：額度測評、信用查詢、進件准入、反欺詐查詢、放款安全自查、貸後動態預警。

2. 業務解構

1）人羣解構

有哪些人？分別要幹什麼？如何落實到系統上？

2）訴求解構

老闆關心什麼？客户關心什麼？風控關心什麼？信審關心什麼？銷售關係什麼？財務關心什麼？研發關心什麼？運營關心什麼？

3）術語解構

貸前、貸中、貸後是什麼？寬限期、M1、呆賬是什麼？黑名單、准入、欺詐、多頭是什麼？指標、規則、規則集是什麼？絕對命中、相對命中、自動批貸、人工批貸是什麼？版本、定價決策、引擎、計費、數據層、特徵層、策略層、決策層是什麼？路由、配置、參數又是什麼？

上述概念有的是業務概念、有的是前台業務概念、有的是中台業務概念、有的是後台業務概念、有的是技術概念，有的是交差概念，這裏不再一一展開講。

如果這裏術語不理清吃透、不深入業務一線體驗，將很難設計出接地氣的系統，因為你顧及了A，可能漏掉了B，當把B的補丁打齊時，又出問題C，疲與應酬C時，D右迎面撲來；業務吃透了，則可運籌帷幄、優雅有序的梯度佈局、迭代演進。

4）場景解構

消費場景、信用貸場景、車抵貸場景、房抵貸場景、供應鏈金融場景（不涉及，但須考慮），每個場景都有每個場景的行業屬性；是每個場景都開發一遍，還是通過需求挖掘，將叫法不同但可以抽象為同一類的進行配置化管理，通過條件及流程設置來控制不同的業務路由呢？

5）主流程解構

貸前流程是什麼？貸中流程是什麼？貸後流程是什麼？

何時自動化授信、自動化批貸？何時人工介入審批？何時移交銷售地面跟進？

通過上述貸款流程的梳理，我們可以透視整個貸款業務所涉及的節點及各節點之間的業務鏈路關係；通過梳理業務，將自己下沉到業務中去，和具體的業務操作人員、業務管理人員進行訪談、去挖掘每個節點下面更細的業務知識，自上而下透視整個業務。

譬如准入流程是什麼？反欺詐流程如何做？黑名單如何維護？信用評分如何做？資產定價如何做？動態預警流程如何做？

例如風控崗的人員會告訴我們“XX類型客户”不能過，“YYY類型客户”需要增加人工審批，“ZZ客户額度可以高一點”，如果我們只從風控這個方向設計會把我們框進去。

因為銷售崗或業務的老大甚至老闆某一天會拍拍你的肩膀説，“招商銀行業務拒貸的客户為什麼不讓走北京農商行、或者咱們的信託通道或者咱們合作的某P2P平台信託放款呢？”這其實是要求我們將“業務訴求”與“風控訴求”整合考慮。

要求我們具有系統思維、要求我們具有很好的抽象能力、要求我們在產品設計之初應當極盡可能的做好“架構處理”，譬如將上述場景逐級抽象為“風控引擎”、“推薦引擎”，而“推薦引擎”與“風控引擎”抽象後的共同模型是“規則引擎”。

通過逐級抽象，我們會發現看似完全不一樣的需求，其實可以用同一個模型處理，我們只需在模型中多配置幾個場景參數即可。

6）子流程解構

大的流程只是一個框架指導，具體實施需要將上述每個節點進一步解構，如同俄羅斯套娃，層層嵌套。

下面我抽取幾個典型流程分別同大家分享下：

case1：准入流程解構

准入流程的關鍵點不在於准入規則、准入尺度的設計，因為這些是“准入引擎”的入門要求。

有想法的產品經理應該重點考慮“性能”與“成本”；“性能”代表“對用户負責”，“成本”代表“對老闆負責”，成本節省機制做好了，這一個功能點一年就能幫老闆節省個幾十萬。

如何提升性能、如何控制成本是考驗產品經理整體考慮、系統整合的架構設計能力，上面的“准入引擎業務鏈路圖”設計原則凝練如下：

• 先調自有庫再調用第三方庫（基本上所有的競品都這樣幹）；
• 先簡單後複雜：年齡>行業>黑名單>司法准入>刑事准入>欺詐准入>逾期行為（差的平台就一馬平川或順序隨意了）；
• 時間安全線：我方庫中有數據要看我方更新庫的時間是否在安全線內（絕大多數平台無）；
• 粒度要足夠細：譬如上面2提到的各節點，每個節點都有更新時間安全線（彈性可編輯）；
• 割韭菜：只要我們查詢第三方，就增量更新我方庫（每家的更新策略不一樣，能做到及時更新即可）。

case2：評分流程解構

評分卡設計原則及實務中的應對策略如下：

• 數據庫層：粒度足夠細；
• 數據庫層：聚類分組：譬如個人類、家庭類、收入類、負債類、工作類、行業類等；
• 策略層1：權重係數；
• 策略層2：先自有再第三方數據；
• 策略層3：數據複用，查詢第三方時，異步更新我方數據；
• 策略層4：分級原則與分值設計綜合考慮；
• 策略層5：定性與定量雙維度考慮；
• 策略層6：多個三方平台競賽校正“算法合理性”；
• 策略層7：分場景案件數據回朔來校正“算法合理性”。

case3：信用額度引擎-流程解構

額度環節主要基於信用評分計算，但是不能一刀切，也即張三和李四都是700分，系統給一樣的額度為什麼呢？

大家看如下兩個例子：

例1：假如張三的700分，但是“月淨可供”指標只有“6000元”，李四“月淨可供”指標是“20000元”；兩者的授信額度將會非常大，懶惰的思維模式給一個額度是不可以的。

例2：同樣是張三，但其買手機的授信和買二手車兩個場景的授信額度也必將不一樣，前者是個小額消費金融，後者是個大額汽車金融，兩者所依託的模型不一樣。

那是不是還有其他控制因素呢？這些因素是否和評分卡的因素重疊了呢？這兩個問題是非常考驗產產品經理的抽象能力和大複雜系統架構的駕馭能力。

萬變不離其宗，只要我們思路清晰，善於抽象，上述問題可以簡化為兩個模型“評分是一個一刀切的純計量行為，也即他是個尺子”、“約束條件是一個定性的方向性條件，相當於變速箱”；基於此我們可以抽象凝練出“額度引擎”的幾個關鍵設計原則，如下：

• 對象：人羣定權重；
• 場景：場景定梯度；
• 悲觀修正指標：用户命中我們額度引擎中的悲觀指標，在上述1、2額度基礎上下修；
• 樂觀修正指標：用户命中我們額度引擎中的樂觀指標，在上述1、2、3額度基礎上上修；
• 資產淨值安全修正指標：基於用户資產淨值（如有）對上述1~4計算額度進行安全修正；
• 月供上限安全修正指標：基於用户月淨可支配收入對上述對上述1~5計算額度進行安全修正；
• 機器不是萬能：人羣萬變，數據源不絕對可靠，工程師的算法絕非完美，產品經理永遠不要相信XX平台的算法多牛叉；只需相信一點，策略總有遺憾，把主動權交給司機（如果額度不理想，支持用户申請提額進入人工審核流程）。

tips：大家可能注意到這個例子中引用了大量新概念“悲觀指標”、“樂觀指標”、“安全修正”，產品經理一定要具備“無中生有（把瑣碎的事情整合為一個有價值的物件）、造概念（高中數學中的設未知數解函數）”這種能力；關於“造概念的產品能力case”可以看下我的《集合理財計劃：資金資產撮合系統、財務分潤清結算產品架構設計》這篇文章中有更多關於這方面的case分享。

case4：押品額度引擎-流程解構

case3向大家分享的是信貸場景的信用定價，抵押貸款業務場景中，更多的是參考押品進行資產定價。

這裏不再展開説明，方法論相通，核心要點如下：

• 前端路由攔截：無效房源應優先做路由攔截，而非查無結果時再給反饋；
• 成本與場景：弱需場景查自有庫；強需場景查專業庫（付費）；
• 查不中是高概率事件：汽車不斷推出新型號、房產不斷推出新樓盤，第三方查不中是大概率事件；

case5：合規計費流程

風險千萬條，合規第一條；自主開發大數據項目是個極容易進監獄的行業，購買三方數據也並不是花錢這麼簡單；故此無論您的大數據平台是對接第三方還是通過爬蟲自檢，如果產品經理在合規這不下足功夫，將給業務和老闆挖巨坑。

下面我們通過層層逆推的方式，來向大家分享合規如何做：

• 監管或用户告我們怎麼辦？tips：需有用户授權，民事領域，契約做好就是護身符；
• 用户怎麼授權的？tips：B端通道還是C端通道？B端高可信商户，走保證金模式；B端低可信商户，走用户授權模式；C端直接走用户授權模式；
• 同一個用户涉及申請、批貸、電核、放款、貸後、循環復借，可能需要多次查，每次都授權太麻煩。tips：通過“法律文本設計”+“查詢快照產品封裝”+“操作權移交使用着”來解決。

case6：案件回朔流程

磨刀不誤砍柴工，通過前述若干場景的case分享，我們廢了九牛二虎之力將風控模型設計好了，研發吭哧吭哧開發完了，效果好不好，這個時候需要用數據説話；所以“案件回溯”是一個可自學習的“風控系統”基礎環節，案件回溯系統的設計要點如下：

• 哪個模型、哪個案件來的（對象）：caseid、userid、ruleid；
• 採集哪些信息（定量）：還款狀態（當前狀態）、逾期狀態（歷史狀態）、ROI數據（毛利貢獻）；
• 有什麼問題（定性）：偏差區間計算；
• 問題定位準不準（分析）：人工標定；
• 模型反驗（推演）；模型的哪些參數和規則做調整可以降低此類事件發生的概率；

三、服務抽象、策略設計

哲學上講“看山是山、看山不是山、看山還是山”，乍一聽，講這話的人腦子有些毛病，哲學家淨搞些虛無縹緲的東西。

實則不然，這句話的白話版本是“透過現象看本質”、“表面看着不相同的東西要看他們背後的本質是否相同”、“找出共同點”，也即產品經理的從業方法論中的核心能力素養“抽象能力”——一個有素養的產品經理要習慣將原始的事物抽象化，再將抽象的東西具象化的表現出來——抽象其實是把繁複的事物用盡可能簡明的方式進行闡述。

上節通過多個case向大家分享如何“解構我們的研究對象，完成了對現象的認知；但我們的的認知不能停留在這個層面，在不斷思考本質的過程中我們逐步對研究對象建立一個更加清晰的模型，形成我們對於事物的抽象。

抽象更多是偏向於邏輯表達，但終須要讓團隊聽得懂、讓用户輕鬆上手用，考驗的是產品經理的另一個能力素養“具象(表達)”。

具象是對抽象的表達，我們經常可以看到一些產品宣傳“無卡支付”、“會計智能分錄”、“智能支付路由”、“智能風控”、“電話AI助理”；但你瞭解後發現其實就是一個“一個參數”、“一個函數”、“一個規則(集)”、“一個工具”、“一個功能”而已。

智能風控引擎設計中我們用到的抽象這些諸如“角色抽象”、“業務抽象”、“場景抽象”、“概念抽象”、“規則抽象”、“模型抽象”也是其它領域中最主流的、最核心的通識方法；通過這些抽象將上述“上節解構”出來五花八門的術語、概念、場景進行統一考量、整體設計、系統集成，以“最小服務（可以解耦的功能)”的具象形式進行產品落地，進而達到相對的“以不變應萬變”的產品設計目標。

case1：規則配置引擎-服務抽象-業務鏈路圖

上一節內容的業務解構中的很多規則都可以抽象為規則，我們只要把規則的核心功能點抽象為具體的字段，各個字段之間以規則的方式進行組合，即可滿足業務層面的任意場景的任意訴求。

具體到“規則配置引擎”這個服務中，經過抽象，有如下6個核心概念：

• 變量（誰）：如年齡、如收入、如逾期情況；
• 場景（哪裏用）：如消金場景、信貸場景、房抵貸場景、車抵貸場景；
• 條件（如何觸發）：策略上需支持條件組合、邏輯運算；
• 動作（觸發後果）：需要做哪些動作，如絕對禁止、人工干預、執行評分；
• 收費（商業化考慮）：選配字段；
• API（商業化、可維護考慮）：選配字段；

case2：策略配置引擎-服務抽象-業務鏈路圖

規則服務抽象是最小粒度的抽象，將多種規則進行集成、組合為“一個個策略”，相當於“不同規格的樂高積木”搭建為“不同的空間的玩具”。

規則可以單條執行，多用於低級判斷或強路由場景中；單條策略多用於高級判斷，多條策略形成的“策略組合”多用與更高級的智能路由判斷或面向業務的“完整業務鏈路”——如前述中的各個層級的業務流程。

具體到“策略配置引擎”這個服務中，經過抽象，有如下5個核心概念：

• 開始：輸入指令；
• 對象：選擇策略；
• 輸出：輸出策略運行結果
• 路由判斷：根據輸出結果，選擇下一策略，如此循環；
• 結束：輸出最終結果。

規則與策略的3個最核心區別：

• 策略的對象多是規則、規則的對象是字段；
• 策略是多個規則的組合；
• 規則節點線程段，策略節點線程分叉多。

case3：規則/策略狀態管理-服務抽象-業務鏈路圖

無論是規則還是策略，其核心在於自學習、隨着數據增加、場景的變化、算法都在實施調整；這就要求，“服務抽象”時額外抽象出一個“審計、追朔”的概念，具象到業務中也即“變更需要審批”、“歷史快照可回溯”。

不同的抽象表達方式對研發下游的開發理解有着不同的友好度，如何優雅的抽象，是高階產品與普通產品的核心能力區別，下圖與上圖相比，哪個更易閲讀呢？哪個表達的信息更豐富呢？哪個對具體的產品設計和編碼設計更友好呢？

case4：智能風控引擎-服務抽象-整體業務鏈路圖

業務解構上從到小，服務抽象上從小到，最終我們將若干個抽象出來的子服務再次抽象，也即上圖的整體技術業務鏈路圖。

前面的“貸前/中/後業務流程圖”、“自動批貸授信業務流程圖”是一個面向業務的語言；上圖是一個面向技術的語言，通過服務抽象我們將業務轉換為技術語言。

case5：智能風控引擎向快貸SaaS雲平台-整體集成架構圖

下圖為快貸SaaS雲平台的整體價格設計圖，在這裏，智能風控引擎決策平台只是一個獨立的服務，把這個服務close掉，整個平台依託人工審批可以獨立運行。

通過抽象服務，我們在產品層面將“智能風控決策引擎”封裝為一個服務，即支持內部系統調用，也能對外公開提供接入能力；無他，整個信貸雲平台依託人工審批路由依舊可以完美運轉。

以上是我們在“智能風控決策引擎中後台”方面的一些設計思想和實踐分享，限於篇幅原因，具體的“詞典設計”、“表結構設計”、“規則設計”、“策略設計”、“用户畫像”、“數據報表”、“貸中動態風控預警設計”、“貸後管理設計”等模塊將在《智能風控決策引擎-中後台設計策略2：表結構設計、規則設計、策略設計》、《智能風控決策引擎-中後台設計策略3：貸中動態風控預警設計及任務調度系統》、《智能風控決策引擎-中後台設計策略4：貸後逾期風險處置系統設計》以專題方式向大家展開講解。

不同的行業、不同的業務場景、不同的崗位角色，會面臨不同的產品任務。

但萬變不離其宗，方法相通，只要我們有產品盤感、業務敏感、邏輯嚴謹、靈通好學、幹練帶風、狠下功夫，放到哪我們都一樣熠熠生輝。

產品之路很艱辛，也更能鍛鍊人，尤其是中後台、尤其是B端複雜業務場景！在此祝廣大產品兄弟姐妹們不辱“產品”之title，做出好產品！

作者：九天牧人，個人微信unifarm

本文由 @九天牧人 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議