互联网金融开源规则引擎

① 决策引擎与规则引擎有什么区别

区别：

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标准。我们不光处理业务逻辑，还把所有业务逻辑层需要处理的操作全部采用规则配置的形式，包括数据库处理逻辑等。