引自博文：https://blog.csdn.net/qq_43036596

互聯網金融的興起，金融科技向傳統金融滲透，智能風控平臺應運而生。決策引擎擔任著智能風控平臺的核心角色，在當代的互聯網金融浪潮中至關重要，本文主要講解了現在市面上主流風控決策引擎產品包含的核心功能模塊，其中主要是規則、評分卡、表達式、模型、決策流等功能模塊。

1、大數據風控概念

在介紹決策引擎之前，首先了解一下大數據風控概念：大數據風控即大數據風險控制，是指通過運用大數據構建模型的方法對借款人進行風險控制和風險提示（百度百科）。

2、什么是風控決策引擎

風控決策引擎是對復雜的業務邏輯抽象化剝離出來的業務規則進行不同的分支組合、關聯，然后層層規則遞進運算，最終輸出決策結果的產品。

傳統的風控決策引擎主要實現規則的邏輯判斷；現有通常使用的風控決策引擎，在傳統的基礎上功能更加豐富，可以實現規則、評分卡、模型、表達式等多種類型的邏輯嵌套，實現層次更加豐富的邏輯運算，滿足現在的互聯網金融業務要求；高階的風控決策引擎，是在現有的風控決策引擎上融入了自言語言處理平臺、流計算平臺等，提升了現有決策引擎的算力和處理時效；

下面主要介紹通常使用的風控決策引擎平臺，包含的常用功能模塊主要是規則、評分卡、模型、表達式、決策流。

規則模塊
規則模塊常用的產品實現方式主要有規則集、規則表、規則樹。

規則集
其中規則集分為普通規則、循環規則，普通規則由變量、表達式、條件值、決策結果組成，如下：

變量：會員年齡表示、表達式：大于等于、條件值：18，這只是規則集的一條規則，其中規則與規則之間存在且、或邏輯關系，然后就是決策結果?：滿足rule1，輸出會員名名稱“金牌會員”，不滿足輸出會員名稱“普通會員”。?

循環規則可以對集合對象進行循環的執行規則，一個循環規則可以有一個或者多個循環單元，每個循環單元都是一個普通的規則，定義的方式同普通規則。只是在執行的循環規則時，需要添加循環條件，以及循環結束后輸出的決策結果，在風控決策引擎中，循環規則運用的較少，這里不做詳細的講解，感興趣的可以留言討論。

規則表
規則表是一種表格形式的規則工具，在處理判斷條件較多的時候，決策結果較多的情況時，可以快速定義出決策規則。

?

規則表分為條件列、決策列，其中上圖借款人年齡、借款人是否有駕照、借款人命中黑名單是條件列，決策結果是決策列。

現在雖然風控決策結果輸出的結果類型不要求多樣化，但是規則種類、數量很多，采用規則表方案實現規則的決策配置可以更加便捷、清晰。

規則樹
規則樹也是規則集的另一種表現形式，在展示上更加形象，在風控業務上通過規則樹、規則表進行規則的配置可以更加形象、快捷。

?

其中每條規則的實現方式同普通規則，都有變量、表達式（條件）、條件值、決策結果（變量賦值）構成。

評分卡模塊
評分卡是對目標的信息進行分析打分的表達方式，表示此人或此機構由于信用活動的拒付行為所造成損失風險的可能性，評分通常用于對個人或機構的風險管理與評估。

?

評分卡實際也是規則的變形，通過有變量、表達式、條件值、得分四部分組成，當然評分卡還會有得分的計算方式，例如求和、加權求和等。

模型模塊
通過主觀意識借助實體或者虛擬表現構成客觀闡述形態結構的一種表達目的的物件（物件并不等于物體，不局限于實體與虛擬、不限于平面與立體），風控決策引擎中使用的模型更多的是數據模型，描述的是目標的行為和特征。

模型在決策引擎中，對于決策引擎平臺實際是一個已經封裝好了的產品，決策引擎只會負責入參變量的配置、出參變量的配置以及模型的調用，所以這個模塊的核心主要是考慮模型的類型（py、model）、調用邏輯、入參以及出參變量的配置。

表達式模塊
表達式模塊主要是規則、評分卡等邏輯判斷實現困難時，可以直接通過代碼自由編輯實現決策的規則判斷，其中規則的表達式、條件值、決策結果都是通過編碼實現，通過這樣的方式可以運用于更多小眾難實現的決策場景，靈活性更大。

表達式模塊類似模型模塊，規則的入參和出參配置也是重點。

決策流模塊
決策流它實現整個分開工決策引擎的工作流配置，用來對已有的規則、評分卡、模型、表達式進行執行順序的編排，清晰直觀的實現大型、復雜的風控規則。

決策流核心的構成包含“開始節點、規則/評分卡/模型等已封裝好的規則包節點、決策節點、分支節點、聚合節點。

開始節點為一個決策流開始的地方，決策流程必須有始有終且必須以開始節點作為開始；
規則包節點，實際就是用來添加之前在規則、評分卡、模型、表達式中已經創建好的規則產品；
決策節點是在決策時，根據為其下流出連接配置的條件來決定究竟應該走哪條連接的節點，所以根據這一特性，決策節點下流出連接至少要有兩條，否則決策節點就沒有意義了；
分支節點實現規則流多條并行的節點，通過這個節點，可以根據當前節點下流出連線數量，將當前規則流實現拆分成若干條子的規則流實例并行運行；
聚合節點用來聚合由分支節點拆分出來的多個子的規則流，實現多條規則流的匯合；
有始有終，決策流程的結束，一般是伴隨著決策總、分的流程的執行，執行到最后節點自動結束，輸出決策結果。

決策引擎除了以上核心功能模塊以外，實際上為了風控決策引擎靈活多變，能夠實現盡可能多的風控業務場景，通常會實現規則、評分卡、表達的相互嵌套調用，這樣可以更好應對不同的風控業務場景。

以上只是對風控決策引擎做了簡要的介紹，其中的規則、評分卡等功能在風控業務復雜的情況下還可以對規則和評分卡進行產品升級，實現復雜規則、復雜評分卡的決策能力。實際應用中的產品只靠風控決策引擎是遠遠不夠的，風控決策引擎的應用還會搭配指標平臺、接口管理平臺、風控報告等產品一同服務于風控業務。

實際業務中的風控流程依靠決策引擎通過規則、評分卡、模型、表達式、決策流等功能模塊是無法完全達到風控目的，成熟的風控方案有一套嚴謹的策略體系，風控決策引擎要結合風控策略體系，最終才能達到風險控制的目標。

?

大數據風控通用流程主要為貸前、貸中、貸后全信貸生命周期風控，分別對應的評分卡有A卡（Application score card）申請評分卡、B卡（Behavior score card）行為評分卡、C卡（Collection score card）催收評分卡。評分卡的開發需要豐富的數據支撐，在信貸業務初期由于數據不充分，則不具備評分卡的開發，這時候就會選擇規則判斷進行初期的風控。

信貸通用的風控都是包含了規則和評分卡兩部分，貸前流行的風控策略流如下：

基于準入、反欺詐（黑名單）、信用評級、定額定價四部分構成，具體的信貸場景在此基礎上也會有部分調整，在自有存量客戶較大的時候，新上線信貸產品之前很多廠家都會在準入之前加入預授信策略。

無論是準入、反欺詐、授信評級中的規則還是評分卡，通常是都是通過決策引擎進行邏輯判斷，在智能風控平臺之決策引擎（一）中介紹了四個常用的決策引擎功能模塊，其中決策流配置模塊就是用來配置信貸風控策略流，評分卡模塊配置評分卡模型進行封裝成規則包、規則模塊配置規則進行封裝成規則包，在通過決策流配置模塊配置風控流程。

信貸風控流程就是決策引擎對于傳入數據的組合運算，有風控策略流程就有規則的優先級運算也就有數據傳入的優先級概念，優先級制定的原則主要是從數據源、規則的強弱（強規則命中直接拒絕、弱規則需要組合判斷決策）、數據成本、效率、數據積累等方面進行考慮：

自有數據源對應的規則優于三方數據源對應的的規則

自有數據源在接口請求、性能、價格等方面都優于三方數據源，如自有 的黑名單庫數據，在命中黑名單規則可以直接拒絕。

強規則（強規則命中直接拒絕）優于弱規則（弱規則需要組合判斷決策）

很多決策引擎的性能伴隨著規則數量的增加下降，考慮更好的利用決策引擎的資源，強規則決策優于弱規則決策。例如命中前科拒絕這種強規則，應該優于命中多頭借貸且命中逾期3次拒絕這種組合的弱規則。

低成本數據對應的規則優于高成本數據對應的規則

大數據風控，數據的費用在整個智能風控中占據著較重的比列，在制定的風控策略流程的時候，低成本規則優于高成本規則。三方數據服務主要由查得、查詢兩種計費模式，其中查得是指三方數據返回有結果進行計費；查詢是指請求三方數據，不管三方數據是否返回結果就進行計費，因此查得對應的規則優于查詢對應的規則。

效率高的規則優于效率低規則

有些規則比如規則甲只需要一個接口A就能做出決策，而規則乙則需要三個接口B/C/E才能做出決策，因為接口的請求是需要時間，這時候就需要考慮規則效率，效率高的由于效率低的規則。

?

需要積累數據的規則優于無需積累數據的規則

在模型冷啟動的時候，有些變量作為后期模型潛在核心變量，需要盡可能多的收集這些數據，此時需要積累數據的規則優于無需積累數據的規則。

以上的優先級原則不都是固定不變的，很多規則優先級的制定都是基于幾個原則的綜合考慮。

由規則的優先級原則，對于風控決策引擎在決策運算時的功能要求是，能夠對于決策流程命中拒絕結果后實現決策流程的決策終斷以及決策繼續，決策流程不僅可以在大的決策流上實現決策流程開關，而且也可以對小的支流某條規則實現決策流程的開關。

數據接入優先級確認，傳入決策引擎進行規則、評分卡、模型的決策，此時還需考慮數據缺失時，數據缺失太多規則、評分卡等的風控也會失靈，那此情形下的決策引擎應該怎么處理呢？

通常規則類的策略，在命中數據缺失的時候，可以在規則中配置決策結果直接輸出缺失的結果。但是評分卡類的策略，如果在數據缺失時通過配置其得分，最后計算總得分，依據總分進行評分卡的結果決策，這樣很難保證評分卡的效果。例如評分卡中的變量豐富的時候，其中核心變量是不能允許缺失，但是如果決策引擎沒有對于的判斷機制，在核心變量缺失時，其他變量沒有缺失同時其他變量的得分較高，此時拉高了整體的評分卡的得分，最后的得分做出決策為通過，實際該客戶因為核心變量缺失需要通過人工審核，因此在這種情形下并不能準確的判斷客戶的征信情況。那么決策引擎應該怎么去解決這個問題呢？

設計決策引擎產品下到規則集、評分卡的每一條決策判斷，上到規則包、模型包的決策判斷都需要進行數據信息值的計算，在決策引擎中的規則、評分卡配置上需要具備信息值的配置、信息值的閾值配置以及信息值的決策結果配置等。決策引擎在進行規則的判斷的時候，首先應該計算的是信息值，然后在進行策略的運算，通過對缺失值的管控，實現更精準的風控效果。

決策引擎主要的用戶是模型策略人員，風控策略伴隨著業務的發生，會進行不斷地調整、迭代，同時不同的業務場景所使用的模型策略也是不同的，因此決策引擎還需要滿足模型版本管理、模型對比的功能，可以更方便用戶配置操作、支撐更多的業務場景。

模型的優化、迭代是需要豐富的歷史數據作為支撐，這里的歷史數據可以分為兩部分：一是傳入決策引擎的元數據，二是決策引擎計算出來的結果數據包含規則、評分卡等數據。數據在傳入決策引擎進行計算后需要對元數據和結果數據進行存儲，這里的存儲也會存在兩種方式：一是緩存，這樣可以避免同一個客戶在規定的時間內重復調用三方數據，造成不必要的成本浪費；二是存儲所有的風控數據，便于后期模型的調優、迭代，同時也可以用于貸中、貸后的管理。數據存儲的功能，更多的規劃在決策引擎的配套產品接口管理平臺中，在后面決策引擎配套產品介紹中會詳細的介紹。

實際業務中，風控的結果輸出，不僅僅只是“通過”、“拒絕”、“人工審核”，還會有很多詳細的內容包含觸發的規則、預警的規則等，這就要求需要一個詳細的風控報告輸出，以備人工審核的人員獲取數據，這也是決策引擎配套的風控報告產品。

下面繼續介紹風控決策引擎核心功能模塊如下所示：

除了模型、規則、評分卡、表達式、決策流管理功能模塊，還需要指標管理、接口管理、模型監控、風控報告等模塊的輔助支撐，風控決策引擎才能在實際的業務中運行。

下面會對指標管理模塊做一個詳盡解讀，在介紹指標管理模塊前首先要理解什么是變量、什么是指標？

什么是變量、什么是指標？

什么是變量？

變量來源于數學，是計算機語言中能儲存計算結果或能表示值抽象概念，變量讓你能夠把程序中準備使用的每一段數據都賦給一個簡短、易于記憶的名字。通俗的理解成某一類值抽象后所賦予的名字，例如接口文檔中的參數就是變量。

什么是指標？

衡量目標的方法；預期中打算達到的指數、規格、標準，一般用數據表示。風控指標可以理解是對于風險因子（風險因子是促使或引起風險事件發生的條件，以及風險事件發生時，致使損失增加、擴大的條件）的定性描述。

變量和指標的區別是什么？

變量和指標在風控的作用上其實沒有區別，在業務解讀上指標具有業務屬性，變量基本不帶業務屬性，在數量變得多的時候，指標更加利于管理。

決策引擎常說的通過變量配置規則、或者通過指標配置規則，實際上意思是相同的。指標管理模塊的打造，對變量賦予了更多的業務屬性，使其更加利于管理、更加成體系，利于對風控業務的解讀。

風控指標貫穿整個信貸生命周期，指標也是風控決策引擎進行運算的最小維度，在智能風控平臺核心之風控決策引擎（一）中介紹了規則的組成包含了變量、表達式、條件值、決策結果四部分，其中的變量就是指標，信貸風控中常用的指標如下所示

不同的信貸場景使用的指標是不同的，一個成熟的指標池需要支撐很多信貸業務場景，因此會有成百上千的指標，此時就需要一個完善的指標管理模塊進行體系的管理。

指標管理模塊的核心功能點主要是增、刪、改、查、分類管理、數據源/參數映射、指標計算、上/下線。

?

指標分類

成百上千的指標數量眾多，指標模塊就需要實現指標分類的管理，指標的分類沒有具體的方法，但是比較常見地有以下方式：

有的按照信貸場景劃分例如：現金貸、消費分期、汽車分期、房抵貸等；
有的按照業務場景劃分例如：貸前、貸中、貸后；
有的按照風控策略流程劃分例如：準入、反欺詐、信用評級、貸后監控；
有的按照數據屬性、類型劃分例如：互聯網行為、社交關系、黑名單、基本信息等劃分；
目前主流的指標類型是按照數據屬性、類型劃分，這樣利于指標在業務上的擴展性。
指標的增、刪、改、查

指標管理模塊肯定是需要實現指標的新增、修改、編輯、查詢、刪除等功能，如上圖中的線下維護的指標是需要添加到風控決策引擎系統中，其中需要格外注意指標的唯一性識別編號，機器是通過每個指標的唯一編號識別指標，一般編號都是由機器默認生成，指標的線上線下維護通過編號進行確認。

指標的數據源/參數映射

指標的數據源/參數映射，風控指標都會對應數據源的參數，可能是一對多也可能是一對多的關系，在指標生成的時候需要綁定其對應的數據源參數，這樣規則運行的時候才能定位具體的參數，獲取到參數下的值。

指標的計算

如上指標的映射會有一對多的關系，最終規則判斷的數據實際上是一對多指標處理后的參數。

例如上表中的逾期次數類指標，可能對應的是一個接口下的多個逾期狀態的次數的統計，就需要對多個狀態進行累加，此時指標就需要對映射的參數進行計算，其中計算的表達式可以根據自有指標情形進行內置，同時還應滿足腳本形式的編輯。

指標的上/下線

風控目標就是對風險的管控，指標創建后不能直接使用，一般是需要重復的檢查，確保指標的正確性后才能進行使用，所以指標需要實現上/下線功能，應對風控業務應急事項的處理。

指標還有一個固有的屬性，根據指標的值可以將指標劃分為連續性指標（指標值是連續的數值）、離散型指標（指標值是枚舉型），這兩種類型的區分主要是影響到規則的計算。

以上就是指標管理模塊核心的功能點介紹，指標管理在產品層面不管是定義成功能模塊，還是定義成平臺，其實際的作用都是支撐風控決策引擎的運算。

復雜規則表

在智能風控平臺核心之風控決策引擎（一）中講到了普通規則表的實現原理，復雜規則表與普通規則表相比，復雜規則表的條件由縱向和橫向兩個維度決定，而普通規則表的條件只是由縱向維度決定。

但在普通規則表的動作部分可以是三種類型，分別是賦值、輸出和執行方式，而在復雜規則表中動作部分就是縱向和橫向兩個維度交叉后的單元格的值，然后對這些值統一進行批量執行設置，如下所示：

在上圖中，單元格中的值C由橫向和縱向兩個維度的上箭頭對應的條件決定。相比普通的規則表，復雜規則表是從橫向和縱向兩個維度來唯一確定一個值，所以它更加簡單，也更為直觀，相同類型的復雜規則表實現的多維邏輯規則，如果換成普通規則表來定義，那將大大增加定義的復雜度。

復雜評分卡

在智能風控平臺核心之風控決策引擎（一）中介紹了普通評分卡，它可以針對某個對象的一些屬性值進行評分，但只能針對是單個對象屬性進行條件判斷，如果需要對多個對象屬性進行條件疊加判斷，那么普通評分卡就無法實現了。復雜評分卡就能很好的解決這個問題，它可以實現評分時多條件疊加判斷，進而使得評分卡的功能更加的完善和強大。如下所示：

相比普通評分卡不同的地方在于，復雜評分卡的條件列可以有多列，可以在通過”插入條件列“項來增加條件列，對每個條件列都可以選擇不同的對象與之綁定，每個條件列下條件單元格中又可以選擇對應的對象屬性，再配置相關的條件，這樣每個分值的條件計算就可以形成多條件疊加效果，從而大大增加評分卡定義的靈活性，滿足多變業務需求。

接著繼續介紹風控報告、模型監控、接口管理等核心功能模塊組成。如下圖所示：

風控報告功能模塊的作用是呈現風險決策結果、風險明細內容，方便風控審核人員使用。模型監控功能模塊的作用是對策略、模型的實時分析統計，方便策略、模型的異常洞察和迭代優化。接口管理功能模塊是決策引擎的數據傳輸管道，不管是數據的輸入和輸出都是通過接口管理功能模塊實現。下面會對風控報告、模型監控、接口管理三個功能模塊分別進行介紹。

風控報告
風控報告的產品目的是提供給風控業務人員查看詳細的風險內容，對象主要包含反欺詐人員、風險審批人員、模型人員、策略人員等。
風控決策引擎的規則、評分卡、表達式主要用于數據的決策計算，風控決策引擎每完成一次決策就會輸出相應的決策結果，通常這些決策結果都是簡單的判斷結果，目前市場上決策結果主流劃分有“通過、拒絕、人工審核”。風控人員對于風險的洞察如果只是基于決策結果還遠遠不夠，風控報告承載的詳細風險也是風險審核的重點。
風控報告是除接口外，決策引擎對外輸出結果的另一渠道。風控報告的核心是服務風控業務，本質是展示風險內容。充分考慮風控報告使用的業務場景，風險內容的展示只是基礎，還涉及報告的下載以及風險內容脫敏、變更。風險內容根據不同的數據來源渠道通常分為業務信息、三方信息、決策信息、名單信息、關系網絡信息，根據智能風控策略模塊分為產品信息、個人信息、準入信息、黑名單信息、反欺詐信息、評級信息、額度價格信息、風險監控信息、催收評級信息、盈利預測信息等。拿市場上最常用的風控報告內容的布局來說，通常風控報告的頂部是產品信息、基本信息，然后是根據風控策略流程的順序分布的決策信息，包括規則、模型的結果信息，最后是根據策略模塊顯示的原始詳細信息即原數據信息。如圖所示

風控報告記錄的是客戶的個人隱私信息，因此在信息的展示時需要充分地考慮數據的安全性，如身份證號碼、手機號碼等身份標識數據展示的時候應該脫敏處理；風控報告主要用于內部風控人員對風險的審核,因此通常限制風控報告在內網使用;風控報告的使用對象包含模型人員、策略人員、反欺詐人員、審核人員甚至是業務人員，不同角色關注的風險內容不同，并且規則和模型等詳細內容也是屬于高度機密信息，因此在對風險報告內容展示的時候還需要充分考慮決策引擎內容的脫敏,通常會在報告和原始內容中間制定一層映射，并且對內容模塊劃分數據權限。業務中風控報告可能需要打印出紙質文檔或者生成電子文檔進行傳遞，因此有些場景也會涉及風險報告的打印和導出。

模型監控
模型監控的產品目的是為模型人員和策略人員提供模型和規則的實時分析、監控以及為后續模型和規則的迭代優化提供數據支撐。規則、模型上線后相關人員需要對其進行高頻地分析檢查，以便于精準地判斷新規則和模型的影響。

模型監控的核心是業務，其本質是通過模型監控了解規則和模型對業務的影響。模型監控主要分為業務、模型內容、數據三方面的監控：

業務是指業務流程的監控，包含通過率、轉化率、人數與金額的數量以及占比的監控，常用指標有準入、黑名單、反欺詐、信用評級的通過率/拒絕率/基比/環比，審核、核準、撥貸的金額/件數/占比/基比/環比等；
模型內容是指對規則和模型的結果、命中情況、穩定性的監控，包含決策結果分布監控、規則和模型結果分布監控、指標和規則命中監控、變量穩定性監控，常用指標有模型和規則結果的分布/占比/混淆矩陣/PSI/AUC/KS等；
三方數據是指輸入決策引擎的風控數據的監控，包含數據借口穩定性、異常的監控，常用的指標有借口的有效調用數量/占比，數據變量的分布/缺失值/平均值/最大值/最小值等。

機構的實際業務通常會有多條并且單條業務的風控規則和模型也會時常調整，模型監控和風控報告是對單一業務、單一規則、單一模型的監控和展示，因此業務、規則、模型的變動模型監控和風控報告也會隨之改變。

模型監控和風控報告的產品設計都需要考慮自定義配置功能，以便監控或展示內容的靈活變動，但是風控報告和模型監控的自定義配置功能不同。

風控報告的自定義配置功能設計核心是數據層級結構、內容顯示模板、數據權限三部分：
數據層級結構至少有三層，從最頂層的自定義數據字段映射到中間層的規則、模型、指標字段在到底層的原始數據逐級關聯，以指標、規則、模型為基礎字段錨定原始數據值，從而實現報告內容的配置字典表；
內容現實模板是給予數據層級結構抽象的產品展示模塊，其承載了報告內容的顯示，包含本文框、形狀、多層級表單、圖標等類型組件，并且不同組件都具有各自的屬性，如顏色、文字、邊框的編輯屬性；
數據權限是上文提到的不同角色根據配置字典表確認擁有的風控報告內容查看權限。

模型監控的自定義配置功能設計核心是數據源、設計器、監控預警三部分。數據源簡單主要是囊括監控需要的所有數據包含規則和模型的結果、變量明細、業務流程狀態、借貸明細等；設計器分為兩部分，一是監控指標的預處理主要涉及函數自動計算結果的圖表顯示，以及監控數據分析結果的圖表顯示，二是圖表的顏色、文字、形狀等屬性編輯功能；監控預警是對預警風險觸達解決人員的方案設計，包含短信、郵件、電話以及及時通訊等方式。
接口管理
接口管理的產品目的是實現智能風控平臺輸入、輸出數據的標準化統一管理，核心是建設能夠自主靈活配置的接口管理平臺。接口管理功能的核心用戶是研發人員，根據市場上金融信貸業務的共同性，接口管理的常用功能包含IP管理、接口配置、自動測試、Mock sever、文檔管理、接口適配、碼值管理、流量管理、監控預警等。

接口管理我們都知道是用于智能風控平臺接口接入和輸出的管理，但是接口管理在智能風控平臺中怎么運作的呢？接下來帶著這份疑惑，我會為大家詳細解答，如下圖智能風控平臺的核心邏輯所示

在整個智能風控平臺中接口管理串聯起了決策引擎、業務系統、三方數據。決策引擎系統執行決策計算的數據來源于業務系統渠道、三方數據渠道、自有平臺渠道等多種渠道。每一次的風險決策，接口的請求調用順序基本都是首先進行API1請求，再進行API2的請求，然后接口管理系統把API1傳入的數據和API2返回的數據進行統一整合后，在進行API3的請求,最后決策引擎系統拿到接口管理系統傳入的數據進行決策計算，輸出的結果再返回到接口管理系統，接口管理系統再將結果返回給業務系統。以上的核心系統邏輯如果逐步打造成成熟完善的系統產品，接口管理也可作為單獨的系統進行建設，但是接口管理無論是單獨的系統還是融合在決策引擎中的功能模塊，其核心系統邏輯并不會發生改變。

接口管理的功能很多涉及的產品內容較多，全面的接口管理會被單獨地打造成一個系統平臺，具有一個成熟完善的產品體系。由于內容較多，這里我只會選取接口管理的核心功能接口配置、接口適配進行介紹。
接口配置
接口配置功能負責前端和后端接口的基本信息、AppKey、接口參數、訪問路徑、存儲路徑等的配置。其中前端基本信息是指API1的信息包括接口ID、接口名稱、緩存機制等，后端基本信息是指API3的信息包括后端名稱、請求地址、請求類型、請求方式等；AppKey是接口請求的密鑰，三方應用通過接口訪問路徑和請求密鑰來實現智能風控平臺的調用，只有路徑和密鑰都正確請求才會成功；接口參數分為請求參數和返回參數，參數根據常用接口格式通常分為header和body兩部分；訪問路徑就是接口的訪問地址，通常以http或者https的類型提供，接口需要聯調因此產品設計之初需要考慮到正式和測試環境的兼容與切換；存儲路徑是指接口與數據庫應用如MongDB/Kafka/MySql等的設置關系，接口輸入、輸出數據都需要進行存儲落檔，因此對應的數據褲應用的配置必不可少，不同的應用之間產品的屬性不同，如數據褲地址、用戶名、密碼等信息，具體內容請自行查閱熟悉。
接口適配
接口適配實際也是接口配置中的一部分，但是作為信貸業務的借口管理核心功能，有必要單獨拎出來說下接口適配。接口適配在借口管理中主要解決上圖智能風控平臺的核心邏輯中API2的自動化調用，產品方案是適配功能映射API1中的傳入參數到API2中作為API2的請求參數，接口管理根據預先配置好的的映射邏輯實現API2接口的自動調用。
不管是接口配置還是接口適配，產品設計都會涉及的重點功能是字段的映射和接口請求轉發，把API1的請求轉化為API2的請求再轉化為API3的請求，最終實現多個功能模塊或者多個系統的相互聯動。
綜合概括各功能模塊的功能點如下：
風控報告的核心功能包括風控報告模版的增/刪/改/查，報告模版的屬性編輯，報告模版的內容配置，報告下載，報告內容權限管理；
模型監控的核心功能包括監控模板的增/刪/改/查，監控模板的屬性編輯，監控模板的數據配置，監控模板的預警管理；
接口管理的核心功能包括接口的增/刪/改/查，接口的適配管理，參數映射，請求轉接；

總結

以上是生活随笔為你收集整理的大数据智能风控的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。