互聯網金融開源規則引擎

① 決策引擎與規則引擎有什麼區別

區別：

1、運行方式不同
規則引擎是需要電子商城的實際業務的運用人員進行相關的調整版和設置；

決策權引擎雖然能夠根據實際的業務進行相關的人工干預，但是其實現是系統自動化的。

2、用戶不同

規則引擎是針對的是電子商城的某一個或者多個客戶群；

決策引擎則是精準到單個用戶的偏好。

3、意義不同

規則引擎是一個工具，本身是不帶規則的，規則需要人為輸入，可單獨將規則從系統剝離出來放到規則引擎平台單獨進行執行管理。具有一定智能化的使用價值，可以按照需求來進行規則的配置、執行、管理，不同的行業都可以配置出屬於自己不同的規則平台。

決策引擎，就是已經包含了很多的規則、決策條件，具備了對規則的決策能力，如風控決策引擎，就是在金融行業的風險控制環節進行決策的。

② 規則引擎的代表企業

商用規則抄引擎的鼻祖，當然是FICO的Blaze。另外益博睿（益佰利）、iLog的也都很有影響力。
開源規則引擎，就是Drools。基本上國內的引擎都是基於Drools做的二次開發。
國內也有自研的產品，比如七度力量的WindSeeker，不過貌似他們更願意叫決策引擎。

③ drools開源規則引擎比較難上手，有沒有一款容易上手的規則引擎

Drools是一個基於java的規則引擎，開源的，可以將復雜多變的規則從硬編碼中解放出版來，以規則腳本的形式權存放在文件中，使得規則的變更不需要修正代碼重啟機器就可以立即在線上環境生效。
本文所使用的demo已上傳 http://download.csdn.net/source/3002213

④ 互聯網金融風控模型都有哪些

以P2P網貸為例

一、銷售環節

了解客戶申請意願和申請信息的真實性，適用於信貸員模式，專風控關鍵點。

風控關鍵點：屬不同類型的借款申請調用不同的信用評分規則引擎。

二、貸後存量客戶管理環節

存量客戶授信調整是存量客戶管理中的重要一環

風控關鍵點：

1、違約情況觀察，比如是否發生早期逾期，連續多期不還欠款、聯系方式失效等

2、信息關聯排查，比如存量客戶中是否有與新增的黑名單、灰名單數據匹配

三、貸後逾期客戶管理環節

還款意願差和還款能力不足是客戶逾期的主要原因，這個環節主要涉及逾期客戶管理與失聯客戶管理

風控關鍵點：

1、催收模型、策略優化。

2、失聯客戶識別與修復失聯客戶信息。

四、資金流動性管理環節

流動性風險是P2P網貸平台的主要風險，跑路P2P網貸平台的一個重要原因就是發生了擠兌。大數據下的流動性管理其實是實時BI的一個應用。傳統BI數據T+1，大數據是實時BI。

風控關鍵點:

1、資金維度

2、業務維度

⑤ 如何在工作流等開發平台中集成規則引擎

基於web應用來說，通常分為三部分：界面層、業務邏輯層和持久層。在製作開發平台是，我們都是在這三方面做工作。由於這三層的特點有些不同，因此我們會採用不同的實現方式來實現。
界面層，強調的是操作界面，因此我們注重採用所見即所得的方式來調整界面布局以及界面樣式。更多的我們可以會做一個表單設計器。
業務邏輯層，我們強調邏輯調整的便利性，我們會採用動態語言或者規則引擎來實現邏輯的配置。
在持久層，我們會採用領域模型，根據定義MetaData來定義結構，從而實現和持久層的訪問。當然持久層不全代表是資料庫。
所有的開發平台都是在這三方面做工作，本文主要研究業務邏輯層的實現，我們在國內出現的開發平台中，看到基本都是用代碼來實現業務邏輯層的。不過是動態語言還是連接外部程序。比如工作流中一些前續事件和後續事件等。很少看到採用規則引擎來實現業務邏輯的配置。
究其原因就是基於推理方式的規則引擎並不適合普通業務邏輯的編寫。
因此我們需要製作一個不採用推理方式的規則引擎，而採用我們傳統的編碼邏輯方式的規則引擎。我們可以稱之為簡單規則引擎。
沒有了沖突推理後的規則系統，將更加簡單的來實現業務邏輯。因此其不用再考慮規則優先順序，沖突、關聯之類的事情，無需再擔心某處的一個簡單的改變帶來了大量無發確定的後果。實現了易用以及靈活性的完美結合。
由於目前並沒有成熟的開源項目來滿足這類需求，因此我們需要自己來實現這類引擎。
如何來實現呢，我們可以從當前已經實現的基於語言的配置入手。
當前我們已經實現編寫腳本來實現業務邏輯。我們現在要做的就是規則的配置界面，可以自動生成這類腳本。
因此，第一步，我們需要建立一個業務語言和腳本語言的映射，如果我們是基於java的項目，就可以直接採用java語言作為腳本語言，然後利用java的動態載入機制，實現規則實時應用。
第一個java中的對象和業務語言的對應，這在目前各類商業的規則引擎已經做的很好，可以參考。實現BOM和XOM的對應關系。
然後我們只要做一個配置界面，可以來定義調用這些java的對象，由於已經建立了java對象和業務語言的對應關系。因此配置後的邏輯界面其描述就是以業務語言來描述。
最後，我們就是將配置的邏輯，存儲到我們的業務系統中，供工作流的某個節點調用。工作流的節點中只要指定了規則名稱以及需要傳遞的對象，就可以將數據傳遞到規則中進行處理。
如果能夠將當前工作流的腳本編輯界面直接替換成規則的開發界面，當然更加好一些。

⑥ 什麼時候使用規則引擎drools

規則引擎一般是一下情況使用
1.為提高效率，管理流程必須自動化，即使現代商業規則異常復雜。
2.市場要求業務規則經常變化，IT系統必須依據業務規則的變化快速、低成本的更新。
3.為了快速、低成本的更新，業務人員應能直接管理IT系統中的規則，不需要程序開發人員參與。

使用規則引擎後有哪些好處
分離商業決策者的商業決策邏輯和應用開發者的技術決策；
能有效的提高實現復雜邏輯的代碼的可維護性；
在開發期間或部署後修復代碼缺陷；
應付特殊狀況，即客戶一開始沒有提到要將業務邏輯考慮在內；
符合組織對敏捷或迭代開發過程的使用；

規則引擎產品的代表
大多數規則引擎都支持規則的次序和規則沖突檢驗，支持簡單腳本語言的規則實現，支持通用開發語言的嵌入開發。目前業內有多個規則引擎可供使用，其中包括商業和開放源碼選擇。開源的代表是Drools，商業的代表是旗正規則引擎VisualRules ,iLog。

⑦ 互聯網金融反欺詐規則引擎從哪些方面定義

1、從央復行獲取個人徵信報告；
2、必制須得有一個信用信息系統，要麼自建，要麼依靠第三方。比如阿爾法象的智能反欺詐系統，它結合當前網路黑產的欺詐特徵，基於機器學習模型、大數據關聯分析和多樣智能演算法，通過OCR識別、四要素驗證等方式的身份識別，以及黑名單篩選、身份真實性判斷、行為異常檢測、多頭共債檢測、團伙欺詐識別等技術手段，全方位大數據技術掃描去黑，築立堅固的反欺詐防護盾。目前擁有100萬+黑名單數據，反欺詐規則100+條。多條規則交叉驗證，讓欺詐無處遁形。
3、冒名欺詐（非申請人本人的欺詐）
4、合夥欺詐（此類欺詐往往多為復雜）
5、第三方數據對接

⑧ 互聯網金融反欺詐規則引擎從哪些方面定義

一、合作前的徵信。
從央行獲取個人徵信報告。央行的個人徵信報告可通過合作的金融機構獲取；至於上海資信，據說一般的P2P廠商都可以接入這個平台，從而可以達到信息共享的目的。
二、合作後的打擊（違約披露）。
通過央行或上海資信的徵信系統披露違約信息；當然一般企業也都會搭建自己的黑名單資料庫。
總的來講，必須得有一個信用信息系統，要麼自建，要麼依靠第三方。金融公司反欺詐針對不同的欺詐情況會有不同的應對策略。根據不同的業務可能遇到的欺詐客戶建立相對的策略。既然說到欺詐就先不講違約和高風險的問題 。惡意欺詐借貸不同信用卡包括以下幾個問題 。通常是通過輪崗和審計排查，針對批貸客戶進行回訪和確認。對拒貸或者查詢出來的黑名單客戶的負責人 審批人盡興專項調查，逐一篩查高風險單子。
冒名欺詐
非申請人本人的欺詐。
該類問題 在自動審批過程中較難查出，需要人工電話審核進行復審針對提供的聯系人 及客戶所在公司和電話進行復核。盡量和申請人本人取得聯系。
合夥欺詐
此類欺詐往往多為復雜
申請貸款往往互為聯系人，互相掩護欺詐，該類問題 需要在系統級別注意聯系人關系和聯系電話及公司出現頻率，及時觀測。系統級別上需要建立申請單信息和申請聯系人的關聯關系查詢。

第三方數據對接
此處不做詳談簡單來說就是第三方的黑名單導入和共享。

⑨ 可以和你討論規則引擎的開發嗎

可能很多人還不了解規則引擎是什麼東西，或者不知道規則引擎究竟有什麼用。我們都知道工作流引擎，也聽說過JBoss下面有個Drools，或者我們知道 weblogic或者Oracle也有自己的Business Rule，我們可能還聽說過ILOG被IBM收購了，如果我們研究微軟的WWF，可能也知道其中有RuleSet等內容。國內的一些web快速開發平台，也提到了規則引擎。
在我們的印象中，我們感覺規則引擎就是解決業務邏輯層的實現問題的。因此我們理所當然的覺得工作流中的某個節點的邏輯處理，應該可以用規則引擎來解決，那麼工作流本身的邏輯也應該可以由規則引擎來解決。另外我們也會覺得，平時項目當中的業務邏輯應該都可以用規則引擎來解決。
但是當我們在使用上述這些規則引擎，卻發現很難和我們實際應用的業務邏輯層的業務邏輯實現相對應。
我們以JBoss的Drools為例，由於其規則引擎使用了匹配規則的方式來進行，因此在應用這些規則引擎時。首先需要將我們具體應用中的業務邏輯做抽象，抽象成一條條規則之後，再打包成一個規則包。一個規則包相當於一個智能塊。當數據傳遞給這個智能塊後，系統會以匹配的方式應用滿足條件的邏輯處理。
當採用這種方式時，應該說邏輯更抽象了，在一個更高的層次加以抽象化的定義。但是也使得規則引擎的應用得到了很大的限制。
首先這種抽象本身需要一個復雜的分析過程，這需要有很強的分析設計能力。另外我們平時具體應用中的業務邏輯層，大量的邏輯都是對實際數據的處理，很多時候還是一個批量數據的處理，甚至有些邏輯需要的參數我們並不能定義在規則中，而是在資料庫表中進行配置。因此我們常見的業務邏輯層的開發，並不能先設計出一個數據模型，然後再在此基礎上抽象邏輯。
因此我們發現Drools等規則引擎很難用，根本不是我們所需要的那樣。
我們研究規則引擎也有一段時間了。有時候我們發現自己做的規則引擎並不是一個規則引擎。因為我們和像Drools這些規則引擎有很大的差別。但我們確實解決了業務邏輯層的業務邏輯配置問題。應該說我們的更實用一些。但是我們卻沒法去實現JSR94標准。我們不光處理業務邏輯，還把所有業務邏輯層需要處理的操作全部採用規則配置的形式，包括資料庫處理邏輯等。