CN115730826A - 风险控制规则配置方法和装置、电子设备、存储介质 - Google Patents

Abstract

本申请涉及一种风险控制规则配置方法和装置、电子设备、存储介质，该方法包括：获取所有基础规则以及所有风险场景；按照每个风险点对应的风险类型，在所有风险场景中确定出每个基础规则对应的风险场景；按照每个基础规则对应的风险场景，确定出与每个风险场景对应的场景规则组，每个风险场景对应的场景规则组中包括每个风险场景对应的所有基础规则；按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，每个业务场景所对应的所有场景规则组用于对每个业务场景下的业务数据进行风险控制评估。本申请解决了相关技术中风险中台的业务场景风控策略难以适配不同业务的风险控制需求的技术问题。

Description

风险控制规则配置方法和装置、电子设备、存储介质

技术领域

本申请涉及计算机应用技术领域，尤其涉及一种风险控制规则配置方法和装置、电子设备、存储介质。

背景技术

许多业务场景都需要进行风险控制，相关技术中的风险中台希望通过一个业务场景的风控策略解决多个业务在该业务场景下的风控需求。但随着业务发展的多元化，不同业务在业务规模、风控需求、参数完整性、响应耗时等方面都完全不同，业务场景的风控策略通用性下降，难以适配不同业务的需求，即使增加业务场景风控策略的逻辑复杂度，也会造成业务场景风控策略的维护难度进一步增加。

针对上述相关技术中风险中台的业务场景风控策略难以适配不同业务的风险控制需求的问题，目前尚未提出有效的解决方案。

发明内容

本申请提供了一种风险控制规则配置方法和装置、电子设备、存储介质，以至少解决相关技术中风险中台的业务场景风控策略难以适配不同业务的风险控制需求的技术问题。

根据本申请实施例的一个方面，提供了一种风险控制规则配置方法，包括：获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的基础规则和风险点，基础规则用于确定业务数据在风险点的风险评估结果；按照每个风险点对应的风险类型，在所有风险场景中确定出每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型；按照每个基础规则对应的风险场景，确定出与每个风险场景对应的场景规则组，其中，每个风险场景对应的场景规则组中包括每个风险场景对应的所有基础规则；按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，其中，每个业务的业务规则集中，包含每个业务下的每个业务场景所对应的所有场景规则组，每个业务场景所对应的所有场景规则组用于对每个业务场景下的业务数据进行风险控制评估。

根据本申请实施例的另一方面，还提供了一种风险控制规则配置装置，包括：规则获取模块，用于获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的基础规则和风险点，基础规则用于确定业务数据在风险点的风险评估结果；第一确定模块，用于按照每个风险点对应的风险类型，在所有风险场景中确定出每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型；第二确定模块，用于按照每个基础规则对应的风险场景，确定出与每个风险场景对应的场景规则组，其中，每个风险场景对应的场景规则组中包括每个风险场景对应的所有基础规则；第三确定模块，用于按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，其中，每个业务的业务规则集中，包含每个业务下的每个业务场景所对应的所有场景规则组，每个业务场景所对应的所有场景规则组用于对每个业务场景下的业务数据进行风险控制评估。

根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本申请实施例的另一方面，还提供了一种电子设备，包括：处理器、通信接口、存储器和通信总线，其中，所述处理器、通信接口和存储器通过通信总线完成相互间的通信；所述存储器，用于存放计算机程序；所述处理器，用于执行所述计算机程序时，实现如前述任一项所述的方法。

根据本申请的一个方面，提供了一种计算机可读存储介质，所述存储介质包括存储的程序，其中，所述程序运行时执行如前任一项所述的方法。

在本申请实施例中，采用获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的基础规则和风险点，基础规则用于确定业务数据在风险点的风险评估结果；按照每个风险点对应的风险类型，在所有风险场景中确定出每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型；按照每个基础规则对应的风险场景，确定出与每个风险场景对应的场景规则组，其中，每个风险场景对应的场景规则组中包括每个风险场景对应的所有基础规则；按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，其中，每个业务的业务规则集中，包含每个业务下的每个业务场景所对应的所有场景规则组，每个业务场景所对应的所有场景规则组用于对每个业务场景下的业务数据进行风险控制评估的方式，通过按照基础规则对应的风险点的风险类型，将基础规则配置到各个风险场景的场景规则组中，并按照每个业务的风险控制需求，将各个场景规则组配置到与业务对应的业务规则集中，从而可以利用与业务对应的业务规则集，实现对该业务在任意业务场景的风险控制评估，风险控制规则不是按照业务场景配置，而是按照风险类型配置，生成稳定且通用的场景规则组，根据不同业务的需求，可以选用不同的场景规则组配置到业务对应的业务规则集中，既能够适配不同业务的风险控制需求，又便于规则维护。进而解决了相关技术中风险中台的业务场景风控策略难以适配不同业务的风险控制需求的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的风险控制规则配置方法的硬件环境的示意图；

图2是根据本申请实施例的一种可选的风险控制规则配置方法的流程图；

图3是根据本申请实施例的一种可选的风险控制规则配置流程的示意图；

图4是根据本申请实施例的一种可选的风险控制规则配置系统的示意图；

图5是根据本申请实施例的一种可选的风险控制规则配置装置的示意图；以及，

图6是根据本申请实施例的一种电子设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本申请实施例的一方面，提供了一种风险控制规则配置的方法实施例。

可选地，在本实施例中，上述风险控制规则配置方法可以应用于如图1所示的由终端101和服务器103所构成的硬件环境中。如图1所示，服务器103通过网络与终端101进行连接，可用于为终端或终端上安装的客户端提供风险控制规则配置服务，可在服务器上或独立于服务器设置数据库105，用于为服务器103提供数据存储服务，上述网络包括但不限于：广域网、城域网或局域网，终端101并不限定于PC、手机、平板电脑等。本申请实施例的风险控制规则配置方法可以由服务器103来执行，也可以由终端101来执行，还可以是由服务器103和终端101共同执行。其中，终端101执行本申请实施例的风险控制规则配置方法也可以是由安装在其上的客户端来执行。后续以在服务器上执行本申请实施例的一种风险控制规则配置方法为例进行说明。

图2是根据本申请实施例的一种可选的风险控制规则配置方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤S202，获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的基础规则和风险点，基础规则用于确定业务数据在风险点的风险评估结果；

步骤S204，按照每个风险点对应的风险类型，在所有风险场景中确定出每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型；

步骤S206，按照每个基础规则对应的风险场景，确定出与每个风险场景对应的场景规则组，其中，每个风险场景对应的场景规则组中包括每个风险场景对应的所有基础规则；

步骤S208，按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，其中，每个业务的业务规则集中，包含每个业务下的每个业务场景所对应的所有场景规则组，每个业务场景所对应的所有场景规则组用于对每个业务场景下的业务数据进行风险控制评估。

通过上述步骤S202至步骤S208，通过按照基础规则对应的风险点的风险类型，将基础规则配置到各个风险场景的场景规则组中，并按照每个业务的风险控制需求，将各个场景规则组配置到与业务对应的业务规则集中，从而可以利用与业务对应的业务规则集，实现对该业务在任意业务场景的风险控制评估，风险控制规则不是按照业务场景配置，而是按照风险类型配置，生成稳定且通用的场景规则组，根据不同业务的需求，可以选用不同的场景规则组配置到业务对应的业务规则集中，既能够适配不同业务的风险控制需求，又便于规则维护。进而解决了相关技术中风险中台的业务场景风控策略难以适配不同业务的风险控制需求的技术问题。

在步骤S202提供的技术方案中，服务器获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的基础规则和风险点，基础规则用于确定业务数据在风险点的风险评估结果。

风险点是用于指示存在风险的规则，或导致不安全事件的因素，例如，IP归属地不一致，使用模拟器设备、使用代理IP等。

基础规则作为最细粒度的规则，用于识别、评估具体业务数据在风险点的风险高低。

在步骤S204提供的技术方案中，服务器按照每个风险点对应的风险类型，在所有风险场景中确定出每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型。

风险场景指的是将一类风险点归类产生的场景，例如，风险场景为“场景设备”，是指用户使用设备相关的场景，该风险场景包含所有设备相关的风险点，如，使用正常手机设备、平板设备以及异常使用模拟器设备、异常使用改机设备等。

基于基础规则的输入条件以及作用范围可以判断基础规则对应的风险点，通过风险点对应的风险类型进而判断基础规则对应的风险场景，或基于基础规则的输入条件以及作用范围直接判断基础规则对应的风险场景。

例如，关于设备类型的基础规则都属于“场景设备”这一风险场景，与高频相关的基础规则都属于“场景高频”这一风险场景，“场景高频”这一风险场景包括的风险点为同一个账户、设备、IP地址等在一段时间内高频次的请求业务接口。

在步骤S206提供的技术方案中，服务器按照每个基础规则对应的风险场景，确定出与每个风险场景对应的场景规则组，其中，每个风险场景对应的场景规则组中包括每个风险场景对应的所有基础规则。

每个风险场景对应的场景规则组中包括一个或多个基础规则。

通过上述步骤S202至S206中的方式，从大量的基础规则中抽取共性，将属于一个抽象模块的基础规则归并在一起生成稳定且通用的风险场景及其场景规则组。

风险场景可以为通用场景，也可以为业务定制场景，通用场景指的是各个业务都可以使用的场景，例如“场景设备”、“场景高频”等风险场景。而业务定制场景指的是某个具体业务所需要的特定风控需求的场景，例如，在业务A中需要移动端app_version(应用程序版本)缺失高危规则，而这条基础规则由于其特定性，对应风险点的类型不属于任何一个通用的风险场景，因此将其归类于一种特殊的风险场景，即业务A的业务定制场景。不同的业务可能具有不同的业务定制场景。

所有风险场景中的通用场景不受具体业务影响，通用场景对应的场景规则组是一种通用、稳定的规则组合，可以适用于多种业务。

所有风险场景中的业务定制场景满足了具体业务的特殊风控需求，业务定制场景对应的场景规则组可以适用于与其对应的业务。

在步骤S208提供的技术方案中，服务器按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，其中，每个业务的业务规则集中，包含每个业务下的每个业务场景所对应的所有场景规则组，每个业务场景所对应的所有场景规则组用于对每个业务场景下的业务数据进行风险控制评估。

不同的业务按照实际的风险防控需求选择风险场景，可以将通用场景与业务定制场景进行自定义编排组合，得到包含一个或多个场景规则组的业务规则集，利用目标业务的业务规则集，可以对目标业务在各个业务场景下的业务数据进行风险控制评估，满足实际业务的风控需求。

一个业务可能会在多个业务场景下对接风险中台，例如，业务B需要在账号登陆、邮箱换绑、拉新邀请等业务场景中对接风险中台，利用业务B对应的业务规则集对这些业务场景下的业务数据进行风险控制评估，以满足业务B的风控需求。

作为一种可选的实施例，步骤S208，按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，还包括如下所述的步骤：

步骤S11，在预设策略集中确定出与每个业务对应的决策策略，其中，决策策略是根据业务数据在每个风险场景下的风险评估结果，确定出决策策略所对应业务的风险评估总结果的策略；

步骤S12，基于与每个业务对应的决策策略以及与每个业务对应的场景规则组，得到每个业务的业务规则集，其中，每个业务的业务规则集中包括至少一个场景规则组和决策策略。

决策策略用于指示业务在每个风险场景下的风险评估结果与业务的风险评估总结果之间关系，预设策略集包括多种决策策略，可以为评分策略，也可以为定级策略，也可以为评分策略和定级策略的结合。评分策略如：(1)最大值决策策略：业务的风险评估总结果是业务在所有风险场景下的风险评估结果中的最大值；(2)求和决策策略：业务的风险评估总结果是业务在所有风险场景下的风险评估结果之和；(3)最小值决策策略：业务的风险评估总结果是业务在所有风险场景下的风险评估结果中的最小值；(4)嵌套决策策略：依据最大值、最小值、求和等决策策略的组合策略，例如，对业务在部分风险场景下的风险评估结果求和，得到求和结果，将求和结果与业务在剩余风险场景下的风险评估结果求最大值，得到业务的风险评估总结果。定级策略如：(1)多数决策策略：根据业务在所有风险场景下的风险评估结果(风险级别)，将出现次数最多风险评估结果(风险级别)作为业务的风险评估总结果；(2)比例决策策略：根据业务在所有风险场景下的风险评估结果(风险级别)，在风险评估结果为高风险的比例超过预设阈值，则业务的风险评估总结果为高风险。评分策略和定级策略的结合如：根据业务在所有风险场景下的风险评估结果(风险评分)确定出业务的风险评估总结果(风险总分、风险总分对应的风险等级)。

通过业务规则集中的决策策略，可以将业务在每个风险场景下的风险评估结果汇总成一个风险评估总结果。

若业务规则集中只包含一个风险场景对应的场景规则集，可以直接将该风险场景下的风险评估结果作为风险评估总结果。

可选地，在本实施例中，在完成每个业务的业务规则集的配置后，可以将业务规则集发布到规则仓储中，规则仓储中包括与每个业务对应的业务规则集，并为每个业务规则集设置与对应业务相匹配的业务标识，每个业务唯一对应有一个业务标识。通过风控接口对接具体业务，在风控接口接收到具体业务传入的业务数据时，可以通过业务数据中携带的业务标识，从规则仓储中所有业务规则集中找到该业务数据所需的业务规则集。

可选地，在本实施例中，在步骤S12，基于与每个业务对应的决策策略以及与每个业务对应的场景规则组，得到每个业务的业务规则集之后，该方案还包括按照如下所述的步骤使用业务规则集对业务数据进行风险评估：

步骤S21，获取目标风险评估请求，其中，目标风险评估请求携带有来自目标业务的目标业务数据，目标风险评估请求用于请求对目标业务数据进行风险控制评估；

步骤S22，按照目标风险评估请求中的目标业务标识，从所有业务规则集中确定出目标业务标识对应的目标业务规则集，其中，目标业务规则集用于对来自目标业务的业务数据进行风险控制评估，目标业务规则集包括预设的目标决策策略以及多个目标场景规则组；

步骤S23，并发执行多个目标场景规则组，得到所有目标风险场景中每个目标风险场景的目标风险评估结果，其中，目标风险场景与目标场景规则组一一对应；

步骤S24，按照每个目标风险场景的目标风险评估结果和目标业务的目标决策策略，确定出目标风险评估请求的目标风险评估总结果。

例如，业务C的业务标识为003，业务C向风控接口传入了风险评估请求C，风险评估请求C中携带有业务标识003、业务C的业务数据，按照业务标识003，从所有业务规则集中确定出业务标识003对应的业务规则集C，业务规则集C中包括场景规则组C1、场景规则组C2、场景规则组C3、决策策略C123，并发执行场景规则组C1、场景规则组C2、场景规则组C3，得到各个风险场景下的风险评估结果，即风险评估结果C1、风险评估结果C2、风险评估结果C3，按照风险评估结果C1、风险评估结果C2、风险评估结果C3以及决策策略C123，确定出风险评估请求C的风险评估总结果C123，若决策策略C123为求和决策策略，则风险评估总结果C123＝风险评估结果C1+风险评估结果C2+风险评估结果C3。

在此过程中，由于风险场景是相互独立的，每个场景规则组可以并发执行，提高执行效率，有利于快速得到风险评估结果。

可选地，在本实施例中，步骤S12，基于与每个业务对应的决策策略以及与每个业务对应的场景规则组，得到每个业务的业务规则集，还包括如下所述的步骤：

步骤S121，获取与每个业务对应的阻断策略，其中，阻断策略是按照与每个业务对应的黑名单和白名单，确定出阻断策略所对应业务的风险评估总结果的策略；

步骤S122，基于与每个业务对应的决策策略、与每个业务对应的黑名单和白名单以及与每个业务对应的场景规则组，得到每个业务的业务规则集。

每个业务对应的黑名单和白名单的名单类型不限，可以是登录账号名单，也可以是设备ID名单，还可以是IP地址名单。例如，业务D设置有测试账号1、测试账号2、测试账号3，这几个账号均为业务平台内部使用的测试账号，无需进行风险防控，则将测试账号1、测试账号2、测试账号3设置为业务D的白名单。又如，IP地址1、IP地址2、IP地址3有利用业务E进行不良活动的风险，则将IP地址1、IP地址2、IP地址3设置为业务E的黑名单。

可选地，在本实施例中，在步骤S122，基于与每个业务对应的决策策略、与每个业务对应的黑名单和白名单以及与每个业务对应的场景规则组，得到每个业务的业务规则集之后，该方案还包括按照如下所述的步骤使用业务规则集对业务数据进行风险评估：

步骤S31，获取指定风险评估请求，其中，指定风险评估请求携带有来自指定业务的指定业务数据，指定风险评估请求用于请求对指定业务数据进行风险控制评估；

步骤S32，按照指定风险评估请求中的指定业务标识，从所有业务规则集中确定出指定业务标识对应的指定业务规则集，其中，指定业务规则集用于对来自指定业务的业务数据进行风险控制评估，指定业务规则集包括预设的指定阻断策略、指定决策策略以及多个指定场景规则组；

步骤S33，按照指定阻断策略，在指定业务数据命中指定黑名单或指定白名单的情况下，得到指定风险评估请求对应的指定风险评估总结果，其中，指定黑名单是指定业务对应的黑名单，指定白名单是指定业务对应的白名单；

步骤S34，在指定业务数据未命中指定黑名单、且未命中指定白名单的情况下，按照多个指定场景规则组和指定决策策略确定出指定风险评估请求对应的指定风险评估总结果。

阻断策略是一种“命中即退出”的风险控制策略，在命中名单时无需采用场景规则集进行风险评估，可以直接得到风险评估总结果，例如，当业务数据命中黑名单时，直接得到风险评估总结果为高风险，当业务数据命中白名单时，直接得到风险评估总结果为无风险。

可选地，在本实施例中，步骤S33，按照指定阻断策略，在指定业务数据命中指定黑名单或指定白名单的情况下，得到指定风险评估请求对应的指定风险评估总结果，还包括如下所述的步骤：

步骤S331，在指定业务数据命中指定黑名单的情况下，确定出指定风险评估总结果为第一风险结果，其中，第一风险结果用于指示指定风险评估请求为高风险请求；

步骤S332，在指定业务数据命中指定白名单的情况下，确定出指定风险评估总结果为第二风险结果，其中，第二风险结果用于指示指定风险评估请求为无风险请求。

通过业务规则集中的阻断策略，可以快速识别业务数据中的风险，在业务数据命中黑名单时，无需执行后续的场景规则集，实现了对高风险请求的快速拦截。

可选地，在本实施例中，步骤S121，获取与每个业务对应的阻断策略，还包括如下所述的步骤：

步骤S1211，获取与每个业务对应的历史请求数据；

步骤S1212，在每个业务对应的历史请求数据中，按照历史请求数据确定出历史风险评估总结果高于或等于风险上限的高风险账户，按照历史请求数据确定出历史风险评估总结果低于或等于风险下限的低风险账户；

步骤S1213，按照与每个业务对应的高风险账户和低风险账户，配置得到与每个业务对应的黑名单和白名单；

步骤S1214，按照与每个业务对应的黑名单和白名单，确定出每个业务对应的阻断策略。

业务对应的黑名单和白名单可以是业务方设置的，也可以是根据历史请求数据自动生成的，例如，账号007在业务F的多次历史风险评估总结果中都被判定为高风险，则将账号007加入业务F的黑名单。

作为一种可选的实施例，下文结合具体实施方式示意性的描述本申请的技术方案：

风险中台希望通过一个场景解决一类业务的风控需求。但该模式会带来场景通用性下降、维护困难以及发布风险高等问题。

例如，在某风险中台中，通过拉新邀请业务场景对接了十六个业务。这些业务在业务规模、风控需求、参数完整性、响应耗时等方案都完全不一样。那么在这些业务的迭代过程中，拉新邀请业务场景中会存在大量的if-else(条件分支结构)逻辑以支持各个业务的特定需求，变得难以维护。同时，业务场景的发布会同时影响十六个业务，无法验证改动在各个业务的正确性。

日常业务对接风险中台的需求很大，而每个风控业务的风险点涉及到多个方面。风控业务是指具体对接风险中台的业务，例如，账号登陆、邮箱换绑、影片预约等。风险点是指具体存在风险的规则，例如，IP归属地不一致，使用模拟器设备、使用代理IP等。为优化风险业务接入流程，减轻运营人员压力。本实施例抽象关联风险点作为风险模块，业务接入时通过对风险模块的编排实现业务的风险防控能力。风险模块是指将一类风险点归类产生的模块，例如，设备模块就包含了所有设备相关的风险点。实际业务场景的风控需求往往会涵盖多个风险模块，例如，设备、环境、行为等。

本实施例提出将通用规则进行组合抽象为风控场景(即风险模块)。风控场景不受具体业务影响，是一种通用、稳定的规则集组合，最终产出场景评分。业务按照实际的风险防控需求选择风控场景，同时与业务特定场景进行自定义编排组合以满足实际业务的风控需求。同时，由于抽象出的风控场景之间没有关联关系，因此可以并发执行，提高了引擎执行效率。这种高维度多层次的规则编排方式在极大提高了业务接入效率的同时，降低了规则的维护成本。

如图3所示，对于风控业务策略，可以分为阻断层(T1快速识别)、场景层(T2深度识别)与决策层(T3策略决策)。阻断层一般为名单信息，命中立即产出风险结果，例如，命中白名单，那么该条风控请求就是一条无风险请求，命中黑名单就是一条高风险请求，命中名单后，风控请求随即产生阻断，直接产出结果，不进入场景层(T2深度识别)。场景层(T2深度识别)由通用场景与业务定制场景构成。通用场景指的是各个业务都可以使用的场景，例如设备、高频等风控场景，而业务定制场景指的是某个具体业务所需要的特定风控需求，例如，在账号登陆业务中需要移动端app_version(应用程序版本)缺失高危规则，而这条规则由于其特定性不能属于通用场景。决策层(T3策略决策)可以自定义组合通用场景与业务定制场景，由此产出的评分决定最终风险结果。

如图3所示，本实施例可以包括以下三个主要流程：

1、场景抽象

在此阶段，需要从大量的规则中抽取共性，将属于一个抽象模块的规则归并在一起生成稳定且通用的场景。基于规则的输入条件以及作用范围判断规则的所属模块，例如设备类型的规则都属于设备模块、与高频相关的规则都属于高频模块。

风控场景(风险模块)可以包括以下几种通用场景：

场景设备：用户使用设备相关的场景，例如，使用正常手机设备、平板设备以及异常使用模拟器设备、异常使用改机设备。

场景高频：包括同一个账户、设备、IP地址等在一段时间内高频次的请求业务接口。

场景关系：指账号、设备等关联关系，例如，某个账号的常用设备。

场景信誉：指用户行为的信誉分数，包括账号信誉、设备信誉等。

场景突变：指前后置业务维度发生改变。比如，登录时的IP地址与支付时的不一致。

2、规则编排

基于三层策略体系，针对不同的业务可以选择任意的通用场景以及创建自定义场景进行编排，得到每个业务对应的业务规则集，业务规则集包含阻断层(T1快速识别)、场景层(T2深度识别)、决策层(T3策略决策)。场景层(T2深度识别)中的每个风控场景会产出一个风险评分，T3策略决策根据业务需求可以直接对每个风控场景的风险评分取最大或求和作为风险结果，编排方式有多种，包括最大、最小以及求和，同时支持嵌套逻辑，例如，也可以对部分场景进行求和后与剩余场景求最大。编排后产出一个业务规则集推送至引擎的规则仓储中。

3、并发执行

风控接口会提取规则仓储中的业务规则集进行编译与执行。每个业务都有对应的业务规则集，可以按照业务名称确定需要使用的业务规则集。在此过程中，由于每个风控场景是相互独立的，因此可以并发执行，提高执行效率。即在一个风控请求中，由于场景层(T2深度识别)的各个风控场景之间是相互独立的，因此可以采用并发执行的方式，而在决策层(T3策略决策)，会对并发执行的结果进行归并产出最终结果。

本实施例还提供了一种规则配置系统，如图4所示，数据层中的规则配置指的是持久化的具体规则。在配置层中，具体规则作为最细粒度的风险点组成阻断策略、场景策略以及业务策略。业务策略集中是根据不同的业务定制的业务定制场景(即T2深度识别中的场景)，业务策略层的作用有二，其一是设置业务特有的风险规则，其二是对上述场景进行归并，产出最后的风险结果。应用层指的是具体业务对接风控策略。由具体业务带来的请求参数，按上述的编排方式在业务规则集中执行，由风险分数最终产出风险结果，比如低中高危。业务可以根据风控结果对请求进行相应的处置，常见的有对高危请求进行拦截。

本实施例基于抽象场景构建风控业务规则集，增强了抽象场景的风险概括性，通过抽象场景的沉淀，减少了业务接入风控的成本；并采用三层策略体系进行风险控制评估，可以叠加场景风险，有效提高了风险拦截率(基于策略分层体系，叠加不同模块之间的风险，有效的提高了风险拦截率)。在本实施例的基础上，可以进行权限控制，对非风险运营人员开发平台，各业务线可以按需求构建简单的风控业务。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

根据本申请实施例的另一个方面，还提供了一种用于实施上述风险控制规则配置方法的风险控制规则配置装置。图5是根据本申请实施例的一种可选的风险控制规则配置装置的示意图，如图5所示，该装置可以包括：

规则获取模块22，用于获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的基础规则和风险点，基础规则用于确定业务数据在风险点的风险评估结果；

第一确定模块24，用于按照每个风险点对应的风险类型，在所有风险场景中确定出每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型；

第二确定模块26，用于按照每个基础规则对应的风险场景，确定出与每个风险场景对应的场景规则组，其中，每个风险场景对应的场景规则组中包括每个风险场景对应的所有基础规则；

第三确定模块28，用于按照多个业务中每个业务对应的风险场景和每个风险场景对应的场景规则组，确定出每个业务的业务规则集，其中，每个业务的业务规则集中，包含每个业务下的每个业务场景所对应的所有场景规则组，每个业务场景所对应的所有场景规则组用于对每个业务场景下的业务数据进行风险控制评估。

需要说明的是，该实施例中的规则获取模块22可以用于执行本申请实施例中的步骤S202，该实施例中的第一确定模块24可以用于执行本申请实施例中的步骤S204，该实施例中的第二确定模块26可以用于执行本申请实施例中的步骤S206，该实施例中的第三确定模块28可以用于执行本申请实施例中的步骤S208。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

通过上述模块，可以解决相关技术中风险中台的业务场景风控策略难以适配不同业务的风险控制需求的技术问题。

作为一种可选的实施例，第三确定模块28还包括：决策策略确定单元，用于在预设策略集中确定出与每个业务对应的决策策略，其中，决策策略是根据业务数据在每个风险场景下的风险评估结果，确定出决策策略所对应业务的风险评估总结果的策略；业务规则集确定单元，用于基于与每个业务对应的决策策略以及与每个业务对应的场景规则组，得到每个业务的业务规则集，其中，每个业务的业务规则集中包括至少一个场景规则组和决策策略。

可选地，在本实施例中，该装置还包括风险控制单元，用于：获取目标风险评估请求，其中，目标风险评估请求携带有来自目标业务的目标业务数据，目标风险评估请求用于请求对目标业务数据进行风险控制评估；按照目标风险评估请求中的目标业务标识，从所有业务规则集中确定出目标业务标识对应的目标业务规则集，其中，目标业务规则集用于对来自目标业务的业务数据进行风险控制评估，目标业务规则集包括预设的目标决策策略以及多个目标场景规则组；并发执行多个目标场景规则组，得到所有目标风险场景中每个目标风险场景的目标风险评估结果，其中，目标风险场景与目标场景规则组一一对应；按照每个目标风险场景的目标风险评估结果和目标业务的目标决策策略，确定出目标风险评估请求的目标风险评估总结果。

可选地，在本实施例中，业务规则集确定单元，还用于：获取与每个业务对应的阻断策略，其中，阻断策略是按照与每个业务对应的黑名单和白名单，确定出阻断策略所对应业务的风险评估总结果的策略；基于与每个业务对应的决策策略、与每个业务对应的黑名单和白名单以及与每个业务对应的场景规则组，得到每个业务的业务规则集。

可选地，在本实施例中，该装置还包括风险控制单元，用于：获取指定风险评估请求，其中，指定风险评估请求携带有来自指定业务的指定业务数据，指定风险评估请求用于请求对指定业务数据进行风险控制评估；按照指定风险评估请求中的指定业务标识，从所有业务规则集中确定出指定业务标识对应的指定业务规则集，其中，指定业务规则集用于对来自指定业务的业务数据进行风险控制评估，指定业务规则集包括预设的指定阻断策略、指定决策策略以及多个指定场景规则组；按照指定阻断策略，在指定业务数据命中指定黑名单或指定白名单的情况下，得到指定风险评估请求对应的指定风险评估总结果，其中，指定黑名单是指定业务对应的黑名单，指定白名单是指定业务对应的白名单；在指定业务数据未命中指定黑名单、且未命中指定白名单的情况下，按照多个指定场景规则组和指定决策策略确定出指定风险评估请求对应的指定风险评估总结果。

可选地，在本实施例中，风险控制单元，还用于：在指定业务数据命中指定黑名单的情况下，确定出指定风险评估总结果为第一风险结果，其中，第一风险结果用于指示指定风险评估请求为高风险请求；在指定业务数据命中指定白名单的情况下，确定出指定风险评估总结果为第二风险结果，其中，第二风险结果用于指示指定风险评估请求为无风险请求。

可选地，在本实施例中，业务规则集确定单元，还用于：获取与每个业务对应的历史请求数据；在每个业务对应的历史请求数据中，按照历史请求数据确定出历史风险评估总结果高于或等于风险上限的高风险账户，按照历史请求数据确定出历史风险评估总结果低于或等于风险下限的低风险账户；按照与每个业务对应的高风险账户和低风险账户，配置得到与每个业务对应的黑名单和白名单；按照与每个业务对应的黑名单和白名单，确定出每个业务对应的阻断策略。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

根据本申请实施例的另一个方面，还提供一种电子设备，用于实现上述风险控制规则配置方法，包括：如图6所示，电子设备可以包括：处理器1501、通信接口1502、存储器1503和通信总线1504，其中，处理器1501，通信接口1502，存储器1503通过通信总线1504完成相互间的通信。

存储器1503，用于存放计算机程序；

处理器1501，用于执行存储器1503上所存放的程序时，实现上述方法实施例的步骤。

上述电子设备提到的总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本领域普通技术人员可以理解，图6所示的结构仅为示意，并不对上述电子设备的结构造成限定。例如，电子设备还可包括比图6中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图6所示不同的配置。

本申请实施例还提供一种计算机可读存储介质，存储介质包括存储的程序，其中，程序运行时执行上述方法实施例的方法步骤。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

采用本申请实施例，提供了一种风险控制规则配置的方案。通过按照基础规则对应的风险点的风险类型，将基础规则配置到各个风险场景的场景规则组中，并按照每个业务的风险控制需求，将各个场景规则组配置到与业务对应的业务规则集中，从而可以利用与业务对应的业务规则集，实现对该业务在任意业务场景的风险控制评估，风险控制规则不是按照业务场景配置，而是按照风险类型配置，生成稳定且通用的场景规则组，根据不同业务的需求，可以选用不同的场景规则组配置到业务对应的业务规则集中，既能够适配不同业务的风险控制需求，又便于规则维护。进而解决了相关技术中风险中台的业务场景风控策略难以适配不同业务的风险控制需求的技术问题。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种风险控制规则配置方法，其特征在于，包括：

获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的所述基础规则和所述风险点，所述基础规则用于确定业务数据在所述风险点的风险评估结果；

按照每个风险点对应的风险类型，在所述所有风险场景中确定出所述每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型；

按照所述每个基础规则对应的风险场景，确定出与所述每个风险场景对应的场景规则组，其中，所述每个风险场景对应的场景规则组中包括所述每个风险场景对应的所有基础规则；

按照多个业务中每个业务对应的风险场景和所述每个风险场景对应的场景规则组，确定出所述每个业务的业务规则集，其中，所述每个业务的业务规则集中，包含所述每个业务下的每个业务场景所对应的所有场景规则组，所述每个业务场景所对应的所有场景规则组用于对所述每个业务场景下的业务数据进行风险控制评估。

2.根据权利要求1所述的方法，其特征在于，所述按照多个业务中每个业务对应的风险场景和所述每个风险场景对应的场景规则组，确定出所述每个业务的业务规则集，包括：

在预设策略集中确定出与每个业务对应的决策策略，其中，所述决策策略是根据业务数据在每个风险场景下的风险评估结果，确定出所述决策策略所对应业务的风险评估总结果的策略；

基于与每个业务对应的决策策略以及与每个业务对应的场景规则组，得到所述每个业务的业务规则集，其中，所述每个业务的业务规则集中包括至少一个所述场景规则组和所述决策策略。

3.根据权利要求2所述的方法，其特征在于，在所述得到所述每个业务的业务规则集之后，所述方法还包括：

获取目标风险评估请求，其中，所述目标风险评估请求携带有来自目标业务的目标业务数据，所述目标风险评估请求用于请求对所述目标业务数据进行风险控制评估；

按照所述目标风险评估请求中的目标业务标识，从所有业务规则集中确定出所述目标业务标识对应的目标业务规则集，其中，所述目标业务规则集用于对来自所述目标业务的业务数据进行风险控制评估，所述目标业务规则集包括预设的目标决策策略以及多个目标场景规则组；

并发执行所述多个目标场景规则组，得到所有目标风险场景中每个目标风险场景的目标风险评估结果，其中，所述目标风险场景与所述目标场景规则组一一对应；

按照所述每个目标风险场景的目标风险评估结果和所述目标业务的目标决策策略，确定出所述目标风险评估请求的目标风险评估总结果。

4.根据权利要求2所述的方法，其特征在于，所述基于与每个业务对应的决策策略以及与每个业务对应的场景规则组，得到所述每个业务的业务规则集，包括：

获取与每个业务对应的阻断策略，其中，所述阻断策略是按照与每个业务对应的黑名单和白名单，确定出所述阻断策略所对应业务的风险评估总结果的策略；

基于与每个业务对应的决策策略、与每个业务对应的黑名单和白名单以及与每个业务对应的场景规则组，得到所述每个业务的业务规则集。

5.根据权利要求4所述的方法，其特征在于，在所述基于与每个业务对应的决策策略、与每个业务对应的黑名单和白名单以及与每个业务对应的场景规则组，得到所述每个业务的业务规则集之后，所述方法还包括：

获取指定风险评估请求，其中，所述指定风险评估请求携带有来自指定业务的指定业务数据，所述指定风险评估请求用于请求对所述指定业务数据进行风险控制评估；

按照所述指定风险评估请求中的指定业务标识，从所有业务规则集中确定出所述指定业务标识对应的指定业务规则集，其中，所述指定业务规则集用于对来自所述指定业务的业务数据进行风险控制评估，所述指定业务规则集包括预设的指定阻断策略、指定决策策略以及多个指定场景规则组；

按照所述指定阻断策略，在所述指定业务数据命中指定黑名单或指定白名单的情况下，得到所述指定风险评估请求对应的指定风险评估总结果，其中，所述指定黑名单是所述指定业务对应的黑名单，所述指定白名单是所述指定业务对应的白名单；

在所述指定业务数据未命中所述指定黑名单、且未命中所述指定白名单的情况下，按照所述多个指定场景规则组和所述指定决策策略确定出所述指定风险评估请求对应的指定风险评估总结果。

6.根据权利要求5所述的方法，其特征在于，所述按照所述指定阻断策略，在所述指定业务数据命中指定黑名单或指定白名单的情况下，得到所述指定风险评估请求对应的指定风险评估总结果，包括：

在所述指定业务数据命中所述指定黑名单的情况下，确定出所述指定风险评估总结果为第一风险结果，其中，所述第一风险结果用于指示所述指定风险评估请求为高风险请求；

在所述指定业务数据命中所述指定白名单的情况下，确定出所述指定风险评估总结果为第二风险结果，其中，所述第二风险结果用于指示所述指定风险评估请求为无风险请求。

7.根据权利要求4所述的方法，其特征在于，所述获取与每个业务对应的阻断策略，包括：

获取与所述每个业务对应的历史请求数据；

在所述每个业务对应的历史请求数据中，按照所述历史请求数据确定出历史风险评估总结果高于或等于风险上限的高风险账户，按照所述历史请求数据确定出历史风险评估总结果低于或等于风险下限的低风险账户；

按照与所述每个业务对应的所述高风险账户和所述低风险账户，配置得到与所述每个业务对应的黑名单和白名单；

按照与所述每个业务对应的黑名单和白名单，确定出所述每个业务对应的阻断策略。

8.一种风险控制规则配置装置，其特征在于，包括：

规则获取模块，用于获取所有基础规则以及所有风险场景，其中，每个基础规则具有唯一对应的风险点，对于相互对应的所述基础规则和所述风险点，所述基础规则用于确定业务数据在所述风险点的风险评估结果；

第一确定模块，用于按照每个风险点对应的风险类型，在所述所有风险场景中确定出所述每个基础规则对应的风险场景，其中，每个风险场景具有唯一对应的风险类型；

第二确定模块，用于按照所述每个基础规则对应的风险场景，确定出与所述每个风险场景对应的场景规则组，其中，所述每个风险场景对应的场景规则组中包括所述每个风险场景对应的所有基础规则；

第三确定模块，用于按照多个业务中每个业务对应的风险场景和所述每个风险场景对应的场景规则组，确定出所述每个业务的业务规则集，其中，所述每个业务的业务规则集中，包含所述每个业务下的每个业务场景所对应的所有场景规则组，所述每个业务场景所对应的所有场景规则组用于对所述每个业务场景下的业务数据进行风险控制评估。

9.一种电子设备，其特征在于，包括：处理器、通信接口、存储器和通信总线，其中，所述处理器、通信接口和存储器通过通信总线完成相互间的通信；

所述存储器，用于存放计算机程序；

所述处理器，用于执行所述计算机程序时，实现权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1至7中任一项所述的方法。

Images