背景
美團最初以團購的形式出現，到現在有了很大的業務形態轉變。尤其是經過與大眾點評的業務融合，從單一業務發展成了覆蓋到店餐飲、到店綜合、貓眼、外賣、酒店、旅游等多個垂直領域的綜合性電商，并且在各個領域都處于行業領先的地位。在這背后，美團點評不僅面臨激烈的行業競爭，還有黑色產業（以下簡稱“黑產”）帶來的各種風險，因為我們的業務有這樣一些特點：
- 品類多、覆蓋面廣：包括幾乎所有吃喝玩樂服務，其中不乏容易被銷贓的品類。
- 用戶多、商戶多：美團點評擁有6億以上用戶，400萬以上合作商家，覆蓋了很大部分國內網民和商戶。
- 交易高頻：每日訂單峰值突破千萬。
美團點評對黑產有著巨大的吸引力，歸納起來在這些方面尤其突出：
- 用戶作弊：大家常說的“薅羊毛”，用戶為了騙取促銷優惠的作弊行為。
- 商家刷單：常見的有刷排名、刷銷量、刷好評等違反商家平臺協議的行為。
- 賬戶和支付安全：公民信息盜用形勢已經十分嚴峻，黑產從業者會在電商平臺上盜取用戶的余額，或使用他人支付信息來消費。
這些行為嚴重侵害平臺用戶和商戶的利益、擾亂正常交易秩序，處理結果的好壞將決定整個業務的成敗。所以美團點評需要一套靈活高效的風險控制系統和工作機制來防控這些風險。
歸納一下，風控系統面臨的挑戰有：
- 業務多、風險點多：上面提到的風險涉及到各個業務的購買流程、用戶操作、商家操作等多個場景。
- 變化快：黑產的攻擊手段升級，自身業務在變化，互聯網環境也會不斷變化。
- 我在明、敵在暗：平臺在明處，但攻擊者是誰、會在什么時候出現、用什么方式進攻卻無法預知。
接下來就以風控面臨的這幾個挑戰為出發點，介紹我們在系統構建中所取得的經驗。
系統構建經驗
挑戰一：業務多，風險點多
回到風控工作的起點，在了解業務所面臨的風險類別后，首先要面對的問題就是：怎樣才能知道有風險，并且能夠控制風險？我們很容易想到，為了做到這些必須與業務系統對接，這部分系統我們稱之為“對接系統”，它的目標抽象來說就是：感知風險和控制風險。
“感知風險”是指要收集盡可能完整的數據。風控需要關注：誰、在什么時候、通過什么方式、對什么對象、做了什么？這句話抽象概括了要感知的內容，絕大多數信息都可以套用到這句話。
第二個目標是“控制風險”。如果僅僅站在防守方的角度看，并不容易知道應該控制哪里；我們應該站在攻擊者的角度思考：攻擊者關注什么？答案是利益。以美團點評為例，可帶來的利益有：
- 促銷優惠：相關的風險場景有下單、支付、購買、驗券等。
- 商家銷量和排名等：涉及購買、搜索、銷量展示等頁面。
- 用戶余額：即需要控制登錄、查看余額等動作。
以這樣的角度排查，就不容易漏掉風險點。排查清風險點后，實際對接工作也有很大挑戰：美團點評的細分業務有100多個，很多業務都有多種用戶終端（iPhone, Android，H5，PC等）、多個業務后臺（促銷工具，商家后臺等），需要對接的場景數量很多。所以感知風險、控制風險背后最大的挑戰是如何與業務方緊密配合順利對接。
在配合中，業務團隊常顧慮因風控需求拖慢業務開發速度，而風控也常感到業務團隊配合不足。在配合的問題上，應該先充分認識兩個團隊合作的目的，就好像生產汽車和生產安全氣囊，安全氣囊在大多數國家已經是汽車生產銷售的必須要求；同理，在現今互聯網服務中，安全配備也已經成為了用戶體驗、業務需求的一部分，一個忽略安全的產品，終究會被市場淘汰。另一方面對風控而言，業務發展是風控存在的前提，如果風控的安全需求影響到業務發展也是不合理的，因此風控要提高服務質量，讓對接帶來的負擔降到最低——這就是對接系統設計的核心目標。
總結一下，風控工作經驗一：安全是業務的必要屬性，沒有安全保障的產品，終究會被市場淘汰； 風險控制要服務于業務，減少業務對接負擔。具體而言，業務接入風控的成本主要有接入成本和運行成本兩方面。下面分別來看我們在風控系統構建中的做法。
接入成本
風控系統最早只是業務系統中的一個函數，逐步演化成了獨立的服務。而這個獨立服務與業務后臺的交互最初時也沿用了舊的思路，即業務后臺在關鍵動作前調用風控服務判斷“有沒有風險”。但這樣每次新增加一個業務或新出現一個風險場景時，風控和業務都要重新對接聯調。這樣頻繁地調整給上下游團隊都帶來了不小的負擔，在頻繁的更改中系統質量也難以保證。
換個角度看，其實還有更好的交互方式：當風控要保證賬戶操作環節的安全，可以讓用戶中心直接與風控系統對接。即業務系統調用用戶中心，用戶中心再調用風控透傳風控所需參數，而風控的決策也通過用戶中心返回給業務后臺。這樣的好處是只需要用戶中心與風控對接一次，業務系統甚至不需要明顯感知到風控的存在。同樣的道理，與商戶中心、支付環節的交互也可以采取類似的設計方法。這樣的改造相當于把風險控制的“責任”從業務方移交給了中間件，即由中間件來保證提供安全的服務。這樣理順系統模塊間的關系，從而降低整體開發成本。
運行成本
業務接入風控系統后，尤其關心運行過程中的是否會有問題。風控系統要尤其關注以下這些方面：
- 服務穩定性
- 隔離部署：在對接的眾多后臺服務流程中，哪些是核心流程、哪些是非核心流程，需要隔離開防止相互影響。
- 依賴降級：風控策略需要實時依賴大量外部數據接口和存儲，依賴越多穩定性問題發生的概率越大，相應的熔斷、降級機制不可缺少。
- 限流防刷：業務尤其是高風險業務隨時可能因爬蟲、惡意攻擊而造成流量突增。系統需要具備識別和拒絕這些惡意流量的能力，而不是放任其消耗業務后臺和風控系統的計算資源。為了做到這一點，風控系統不應僅位于業務系統的調用下游，而要在全局流量入口處插入反爬防刷模塊來實現整體控制。
- 服務性能
- 風控與業務對接可以大致分為兩類：
① 同步控制接口，返回風控決策并由上游實時處理。
② 異步信息收集接口，主要目的是收集數據提供風控決策依據。異步接口可以顯著減少上游服務的阻塞時間。 - 最初風控策略硬編碼在代碼中，對運行過程的優化也以人為調整代碼為主，但策略調整頻繁，運行優化無法跟上策略調整，而且策略復雜度提高后，人為優化代碼也不再現實，因此需要在運行時動態決定運行策略才能達到最好的優化效果。這點通過規則平臺來完成，將在后文中“規則平臺”中介紹。
- 風控與業務對接可以大致分為兩類：
- 風控運營
- 風控策略不可能做到完全精確，為了降低業務損失很多情況下要以犧牲一部分用戶體驗為代價，因此完善的用戶運營保障不可或缺。這在后文的“運營系統”中會提到。
挑戰二：變化快
具備感知風險和控制風險的能力后，實現風控策略就是第二個關鍵問題。最初的策略可以很簡單，比如此時我們認定：“穿黑衣服的是壞人”。類似策略運行一段時間后會出現有意思的現象：“壞人會逐漸換上其他顏色衣服”。這也很好理解，攻擊者不會持續做無效的攻擊浪費資源，而是會轉向其他進攻手段。這樣舊策略反而只會影響到一部分正常用戶——觀察到的結果是策略準確率下降。這樣的情況無法避免，因為——風控工作經驗二： 風控是一項長期的對抗性工作。
那么我們首先要加強策略健壯性。還用上面的例子，攻擊者很容易發現后臺針對黑衣人的策略。但如果策略復雜一些，識別“穿黑衣服而且戴黑帽子的人”有問題，那么策略被暴露的概率就低了很多。但這會影響策略的覆蓋面，所以需要更多的策略形成策略網共同作用。假設極端一點，把能想到的識別要素都用上，制定策略也就變成了模型訓練問題，通過機器學習來制定策略會有更好的健壯性。不過這只是理想情況，現實并沒有這么樂觀。風控所面對的真實場景中正樣本和負樣本數量差距懸殊，而且攻擊模式在持續變化，導致這并不是穩定的算法問題。所以實際工作中人工介入制定專家規則并與算法策略結合使用是更有效的方法。
涉及到長期對抗的工作，效率高低將是對抗效果的決定性因素。風控需要多種角色配合，典型如：開發者建設系統、策略制定者制定規則策略、產品角色把策略應用到合適的場景。讓這些角色并行不悖就是工作的理想高效狀態。“規則平臺”就是我們用來達到這一狀態的秘密武器。
規則平臺
為了解耦系統開發和策略開發，需要讓策略執行過程標準化。我們把策略劃分成幾個層次：
- 場景：對應規則集合，一個場景包含若干條規則。
- 規則：是最小的決策單元，一個規則包含多個因子。
- 因子：因子是組成規則的最小邏輯單元。
上下兩層之間都是多對多的關系。這樣劃分后，所有策略都套用標準化的執行過程，并能達到最大程度的配置復用。此外還有一個好處，就是將策略配置從代碼中抽離。舊的策略執行過程是用硬編碼預先編寫好，對執行過程代碼調優十分復雜，即使調優也只能針對特定的策略配置。如果策略改變了，原來的優化可能就不再適用。通過配置執行策略后，執行過程也變成動態的。具體來說，運行時會根據請求來決定需要計算哪些場景、規則和因子，每個元素計算且僅計算一次，沒有相互依賴的部分放入多個線程并行處理。通過這樣的優化，效率和性能得到大幅度提高。
再看策略開發和決策應用。最初實際工作中這兩者耦合在一起不加區分，即針對特定場景開發特定策略。逐漸暴露出一些問題，比如場景會變化、會新增，那原有的策略是否還適用？一個策略是否只能使用固定的決策動作？為了讓這兩部分工作并行，需要從設計定位上就把兩者區分開。即：
- 策略：是為了識別一些特定的問題，例如“是不是模擬器請求”，“該用戶是不是新客”。
- 決策：是針對場景的應用，如拒絕、驗證手機短信等。
規則平臺設計讓每個場景可以應用不同策略，命中策略后的決策也可以靈活定制，甚至可以配置多個決策，并設置不同優先級。
驗證中心
上文中的“決策”代表系統是否信任該請求，風控背后的工作也圍繞這個“信任”而展開。拒絕不信任的，放行信任的。但還有不少情況是中間不足以確定的部分，常見的處理方法是需要讓用戶補充驗證信息來輔助判斷。最初實現的驗證流程是：風控服務識別風險后返回決策給業務系統，由業務系統實現驗證的完整交互過程。這樣存在兩個問題：
- 首先業務方很多，不同的業務需要重復實現驗證流程，造成重復開發。
- 其次驗證種類有很多，從較弱可信度的短信驗證，到較高可信度的銀行卡驗證等——風控能返回什么樣的決策受限于特定場景業務方的實現了什么驗證支持。
這些問題對于業務和風控系統造成了不小麻煩。所以我們需要優化這一過程，讓驗證過程由一個獨立的服務——驗證中心來完成。業務系統從風控服務獲得風險決策，再與驗證中心交互完成驗證。從風控的角度看，以前的處理方式稱作“只管殺，不管埋”，優化后可以稱之為“殺埋一條龍服務”。
除了規則平臺、驗證中心，我們還抽象出了累計服務、處罰中心、算法平臺等服務來提升風控對抗效率。
挑戰三：我在明，敵在暗
風控與黑色產業的對抗有個天然的不利因素，就是風控團隊需要防御所有短板，而對手只需要找到薄弱的環節進攻。面對進攻，我們可以建立相對完善的實時策略體系和工具系統，但如果僅寄希望于實時策略解決所有問題也是不現實的。即使策略再優，黑產、業務、環境都在變化，仍然可能留有漏洞，或者陷于疲于應付的境地。這樣的現實需要風控團隊視角更寬廣一些——風控工作經驗三：要從事中防守擴展到立體事前、事中、事后防御。
在風險事前，要注意提升防御能力，減少防御短板：
- 風險教育：在快速發展的業務中，風險控制的核心在于人，要將風險意識和基本概念傳遞到業務的各個階段，明確告知風控可以提供的服務。
- 參與業務：參與到業務的產品流程中，了解高風險業務、活動的規則，預判風險并給予合適力度的干預。
- 數據準備：打通數據收集流程，制定預警規則、模型策略等。
- 主動防護：關注業界風險動態，發生行業安全事件后，或重大活動、產品改動上線前，制定有針對性的規則，甚至采取鎖定高危賬戶、發送預警消息等措施。
在風險事后，要快速響應，靈活管控。客戶投訴是風控了解策略效果的最重要指標之一。 針對風險場景，風控還要主動關注異常數據，實現“預警”監控。這些反饋都會進入運營工作流做處理。 運營工作流中，盡管各風控產品具體流程不同，都可以劃分為初步受理、核查審理、案件處理三個步驟，對應著以下三個系統。
- 初步受理：主要用作初步篩選案件，決定是否需要進入下一步驟。其流程較為簡單，系統的設計目標是讓風控運營人員可以便捷的處理案件，因此處理效率是其中的重要衡量指標。
- 核查審理：用于詳細核查案件，通常有多步驟流程，不同角色以其專業視角做判斷。核查過程中需要大量數據支持和處理系統支持，因此有了運營支持系統。
- 案件處理：確認且涉及到資金損失的案件需要進入賠付流程。因為涉及到資金賠付，精確的權限管理是系統設計和實現時需要特別注意的問題。
運營平臺的意義不僅在于處理案件本身，更在于將處理結果反饋到線上系統中實現風控線上和線下的運行閉環。除了運營平臺，逆轉信息劣勢還要靠完善的數據體系的幫助。風險控制所使用的數據可以這樣分類：
- 事件快照：原始而完整的信息，用于生成聚合數據，也是支持運營查詢的主要數據源。
- 聚合事實：相比于原始的事件記錄，更多使用場景更關心聚合的結果，例如某用戶、某商家的歷史購買次數。經過聚合整理后的數據，是進一步數據挖掘的基礎。
- 衍生信息：指基于事件快照和聚合事實衍生出的理解信息，例如用戶的作弊風險、設備的可信程度、黑白灰名單等。這些衍生信息可以適配到各個特定場景中使用。
- 基礎數據：除了直接傳遞到風控的數據外，風控處理過程少不了需要業務甚至是外部的輔助信息。例如，業務相關訂單和活動信息、公認的事實數據、外部輔助決策信息等。
小結
把上面三部分融合起來，可以看到風控系統的全景：
風控之道
從上文三條風控工作原則可以看到，風控系統構建過程各個階段的關注點從對接質量，到平臺效率，再過渡到立體的閉環防御。但即使系統發展到了相對成熟的階段，與黑產的斗爭也遠沒有結束。為了更好的對抗，我們要從對手身上學習：
- 黑產鏈條經過長時間的實戰優化，分工極為細致。風控團隊也應該學習這樣的思路，將服務功能切分到細粒度以更好適應變化。
- 黑產對利益極為敏感，甚至很多時候比業務開發者還要了解業務。風控團隊只有比對手更了解“主場”——也就是自身業務，才有可能在對抗中取得主動。
如果把風險控制比喻成一場戰爭，還可以從軍事理論中得到借鑒。《孫子兵法?謀攻篇》中的一段描述就十分貼切：“知可以戰與不可以戰者勝，識眾寡之用者勝，上下同欲者勝，以虞待不虞者勝，將能而君不御者勝。此五者，知勝之道也。”類比到風控工作中，風控團隊需要考量：
- 控制風險是否現實
- 團隊人才質量和數量是否足夠
- 團隊價值觀是否統一
- 對風險是否足夠了解
- 是否得到上層支持
這五點就是風控工作的取勝之道啊。
參考文獻
- Samet O. Introduction to Online Payments Risk Management. O'Reilly. 2013.
- 李俊奎. ArchSummit. 支付寶：敢付敢賠背后的互聯網實時風控技術. 2014.
