楠木軒

互金信貸風控體系詳解

由 公冶爾藍 發佈於 財經

編輯導語:互聯網金融發展的時間不長,但在影響規模上可不小。最初的互聯網金融和金融互聯網的爭論是圍繞信貸進行的。在我們日常生活中,信貸的使用還是比較普遍的,信用卡、花唄等,都聚焦於我們的生活中。本文針對信貸話題,分析信貸的風控體系是如何順應時代變化發展的?一起來看。

互聯網金融浩浩蕩蕩不過十載,時間上看雖然不長,但從影響上規模上不可不謂之鉅變。這一點從名字上就可以看出來,廣為人知的是互聯網金融,而不是曾經許多專家學家們激烈爭論的金融互聯網。傳統金融互聯網化實在不足以形容這場震動中國金融體系的鉅變。互聯網金融當然不止於信貸,還包括銀證保基信,及其他全新業態,是名副其實的“金融業的攪局者”。

但不管如何,互聯網金融和金融互聯網最初的爭論,是圍繞信貸而產生的。我們聚焦信貸這個話題。信貸的風控體系是如何順應時代變化而發展的呢?我們今天討論,風控有哪幾種常見的模型策略體系,以及他們的二階問題:為什麼是這樣的體系?

01

2013年橫空出世的“餘額寶”,讓貨幣基金這棵老樹開花,引爆了整個市場,否則互聯網金融還只會是IT圈裏一個並不算熱鬧的子話題。這就是業界普遍將2013年定義為互聯網金融元年的原因。

2014年,第一款互聯網消費金融產品“白條”成立,首家互聯網銀行“微眾銀行”經監管機構批准開業。

這時候互金信貸業務尚在發軔之始,風控能怎麼做呢?新模式下的用户沒有,傳統銀行信貸動輒一年甚至幾年的表現期沒有,標準數據產品更是沒有,別説大數據模型了,統計學模型也無能為力。此時的授信只能去找優質人羣,例如信用卡客羣,例如電商某些高級品類的交易客羣等等。

這個時候的風控可以説成是基於客羣的風控,或者是基於白名單的風控。也由此產生了基於人羣的互聯網消費金融,包括大學生分期、藍領/白領分期、農户分期等,然後又產生了基於場景的互聯網消費金融,如租房分期、家裝分期、旅遊分期、教育分期、醫美分期等。

而後,伴隨着P2P、網貸等互金業務的快速發展,消費金融市場主體進一步豐富。與此同時,移動互聯網的全面發展導致了數據信息的激增,在某種程度上,數據已經成為了和石油一樣重要的戰略資源。在大數據這個冉冉上升的風口上,一大批數據公司成立。算力和大數據的發展引發了機器學習狂潮,風控水平有了大大提升。

17、18年的野蠻期,很多人有點資金夠膽識就敢去放貸,接入幾家三方數據源,設幾個常用規則,做一個授信模型,找幾個人做催收,就可以把流水做起來了。

這時候風控成套的技術都已經相當成熟化。三方數據覆蓋多個維度,例如徵信、銀聯、運營商、公安、司法、工商、税務,還有多頭,等等。抽什麼樣本、定什麼標籤、接入什麼數據、用什麼算法、做什麼通過率,做一個和產品配套的模型策略不是什麼難事,真正重要的是產品本身,也就是額度、定價、期數、還款方式等。

再往後,一系列監管政策相繼出台,行業從高速發展走向了規範整治的新路程。風雨過後,如何在健康的競爭環境和發展空間下行穩致遠成了新的命題,行業進入了並將持續處於精細化運營時代。

這時候風控如何做細、如何服務好業務形態下的需要,又是新的命題。

互聯網時代的變化,用產品的變化來表徵似乎更生動形象。

App時代產品經理的工作可能是畫原型就夠了,把交互做到極致就很厲害;再往後是策略優化、功能演進,ToC業務的產品經理從工作內容上看都是策略產品經理,也要會數據了;那現在和以後呢,悄然變成了負責業務形態和組織關係下的方案梳理了。

風控也是一樣,從跑馬圈地時代,到策略優化、模型迭代,現在已經半隻腳踏入了業務形態下的解決方案。這不,最近騰訊的財報一出,ToB業務(金融科技與企業服務板塊)已經超過了遊戲板塊收入,大家才發現騰訊已經成為了一家ToB的數據技術服務公司了。

説了這麼多,終於把背景講得差不多了。行業在變,風控體系也在變。

這不同的階段、不同的平台、不同的業務場景,風控裏面的模型和策略又是如何去做的呢?

02

過去幾年,信貸行業新的從業者,或者稱之攪局者,何其之多,新上線的信貸產品何其之多,背後的風控玩法也何其之多,無一而足。

但總結起來,常見的靠譜的模型策略體系只有三種。

第一種以規則為主、模型為輔。大多出現在展業初期,樣本較少,數據也較少,風控主要依託於專家經驗,沒場景的現金貸和有場景的消費貸都是如此。

展業初期,或者説冷啓動階段,樣本需要逐漸積累,風險需要較長的時間才能暴露,授信必須嚴入。在知道風險結果之前,嚴入還是寬入的標準就是通過率,所以一般初期通過率都較低。

通過率用什麼來卡?也許你有場景,場景數據卡一道當然可以,但不夠。風險滯後,你終究要去接入一些三方數據。基於這些數據,基於你的場景,基於你的產品定位,制定對應的政策和規則。

然後隨着還款日的到來,一批一批用户開始表現,新户的數據在經分上一定是要虧錢的,你會想要去優化。你知道風險跟你的產品、跟你配套的運營,都息息相關,你會認為標準產品不夠用,你要自己建模。

樣本有限,數據接入太多沒有意義,這個時候的模型談不上大數據模型,只能是小數據模型。如果你的產品不發生大的變化,模型開發沒有任何差錯,這個模型可能能帶來一些增益。隨着業務規模的增加,模型得以頻繁地被刷新和調優。

但不管如何,這個時候,整個風控體系是規則為主、模型為輔的。白名單也好,黑名單也好,年齡地域限制也好,多頭也好,公安司法信息也好,標準產品評分也好,你的風控是建立在行業通用的專家規則之上的,模型只是輔助。説白了,你的安全感來自各種規則。

這類體系不僅僅是出現在展業初期,很多平台長期處於甚至至死都屬於這個階段。它的代表場景是發薪日貸款,及由其衍生發展來的系列網貸,風險較高,通過高定價短週期來彌補資損。

03

第二種以模型為主、策略為輔。在樣本相對豐富後,模型的重要性會逐漸升高,尤其是行業內卷,客羣質量越來越下沉之後,精準識別成為必須。

在原有的專家經驗系列規則外,一些可變規則不斷地被調整,在這些規則之後,如何依據模型作更精細化決策呢?

一種做法是把模型效果做的儘可能好,然後所有人通過這個模型進一步篩選。為了效果足夠好,模型複雜度就會變高,缺陷就是你説不出來為什麼這個人被通過、那個人被拒絕。不管解釋性工具再怎麼做事後工作,這個缺陷本質上彌補不了。

另一種法是把模型做的效果足夠好且可解釋性足夠強,為了追求可解釋性,可以將數據也就是特徵分類,基於每一類特徵構建對應的模型,例如逾期模型,例如多頭模型,例如交易模型,等等。同一維度的特徵組合,保留了一定程度的該維度可解釋。串行的過每個模型,得以判定這個用户逾期上表現不行,或者多頭很嚴重,或者銀聯交易評分有風險。

在這類風控體系中,你的安全感來自模型。只要模型AUC、KS保持高位,不管每天放款流水多少,你都會比較安心。

這類體系中,模型重要性很高,策略依靠模型做差異化。一個模型為主的風控團隊往往最終會走向這種做法,很多銀行也會走向這種做法。因為真正的策略人才是很稀缺的。

04

第三種以策略為主、模型為輔。注意和第一種的區別,第一種説的是規則為主,這裏説的是策略為主。規則為主的規則,是簡單的,是通用的,是經驗的,是串行不交叉的。

這個階段,樣本非常豐富,場景內不斷挖掘用户數據,接入各種有效的三方數據,大數據模型效果很好,且不斷追求更好。模型的重要性很高,就如同“工欲善其事,必先利其器”的器很重要一樣。

這時的模型充當策略的工具。模型可以不追求解釋性了,策略為主,策略保持決策的可解釋。

決策要有可解釋性,是因為未來不一定會像現在一樣,我們無法承擔極端情況的傷害。就像投資,你可以數據化出一套決策避開所有的熊市,找到所有的牛市,但例子才多少呢,你敢用在當下嗎?決策一定是儘量簡單的,它可以犯錯,但犯的錯要小,獲的利要大。

策略的精髓在於分羣,年齡是分羣,收入是分羣,多頭是分羣,模型也是分羣,是風險的分羣。無論是授信,還是貸中管理,無論是你對用户做什麼,還是希望用户做什麼,你都要區分用户。

這類體系的標誌是決策體系中有很多重要的分羣,也就是決策分支,模型用作最後的保障。模型作為策略的工具,可以需多少有多少,一個工具可以用的範圍很大,也可以用的範圍很小。

決策分支的意思是,策略對模型的應用不是一刀切的,不是所有小於600分的用户都要被拒絕的。

你的安全感來自策略,再具體一點,就是策略分羣。

在行業強監管下,非持牌機構不斷倒下,只有巨頭才能勉強活着,越來越多的風控都是這種體系。無他,精細化要求而已。

05

我們上面的討論已經涵蓋了這些體系發展的背景,不同的階段、不同的平台、不同的業務場景下,風控體系不一樣。

為什麼發展出了這樣的體系?這個二階問題,似乎答案就是數據。樣本的多少、數據維度的多少、特徵數量的多少決定了背後模型和策略的關係。

但,這不是問題的本質。我認為問題的本質在於風險回報比

資料來源:招銀國際證券

如果你是“714”高炮那樣的玩法,搭幾條規則,讓錢出去利滾利就是最賺錢的,週期短流動性強,年化利率好幾倍甚至十幾倍,風險再高也就是一個本金,不算什麼問題。目標客户裏就沒有優質人羣,還做什麼模型精準識別。

當這種玩法不再合法,風險回報越來越低,銀行的對客定價一般在年化18%以內,消費金融公司基本在20%出頭, 若要在這個範圍內盈利,就要風險平穩可控,服務目標要鎖定優質客羣,沒有大數據模型是不行的。當然,不缺優質流量的巨頭光白名單就夠用了。

後來流量越來越貴,客户不斷被多平台滲透,做好存量就至關重要。省一份流量算一份流量,漲一點餘額算一點餘額,開始把每個用户挖掘到極致。客户分羣精細化運營成為當下的趨勢。

只是,這樣的挖掘,這樣的運營,是客户需要的嗎?

舉目向去處,多是坎坷。回首望來路,皆是坦途。

本文由@雷帥 原創發佈於人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基於CC0協議