(12)发明专利申请
(10)申请公布号 CN 111544891 A(43)申请公布日 2020.08.18
(21)申请号 202010347934.8(22)申请日 2020.04.27
(71)申请人 盛趣信息技术(上海)有限公司
地址 201210 上海市浦东新区中国（上海）
自由贸易试验区海趣路36、58号1号楼1-2层、4-14层(72)发明人 程钦辉 郑佳男
(74)专利代理机构 上海金盛协力知识产权代理
有限公司 31242
代理人 严帅(51)Int.Cl.
A63F 13/75(2014.01)G06Q 10/06(2012.01)
权利要求书2页 说明书5页 附图1页
(54)发明名称
一种统一的业务风控系统、风控方法(57)摘要
本发明公开了一种统一的业务风控系统以及相应的风控方法。该业务风控系统对于需要跨业务数据进行风险判断的业务处理请求所触发的风控请求设置有带插件服务的风控规则；所述风控系统的风控引擎获取与该风控请求匹配的风控规则，调用所述匹配的风控规则内部配置的插件服务来获取跨业务数据以针对该业务处理请求进行跨业务风险判断。通过在风控规则内配置获取跨业务数据的插件服务来实现在业务处理方无感知的情况下对不同业务进行解耦；并且通过采用大量插件服务实现风控模块复用，解决企业内风控系统重复建设的问题。CN 111544891 ACN 111544891 A
权 利 要 求 书
1/2页
1.一种统一的业务风控系统，其特征在于，所述业务风控系统对于需要跨业务数据进行风险判断的业务处理请求所触发的风控请求设置了带插件服务的风控规则；所述风控系统的风控引擎获取与该风控请求匹配的风控规则，调用所述匹配的风控规则内部配置的插件服务来获取跨业务数据以便针对该业务处理请求进行跨业务风险判断。
2.如权利要求1所述的业务风控系统，其特征在于，其中对需要跨业务进行风险判断的业务处理请求所触发的风控请求，与其匹配的风控规则内配置的所述插件服务的入参为所述业务处理请求对应的JSON串，调用所述插件服务所获取的响应数据也为JSON串。
3.如权利要求1或2所述的业务风控系统，其特征在于，对任一业务请求进行风险判断时，业务处理方将待判断风险的业务处理请求的所有字段转换成一个JSON串随所述风控请求发送给所述风控引擎；所述风控引擎根据接收到的所述业务处理请求的业务标识查找出对应的一组风控规则；根据所述业务处理请求对应的JSON串与该组风控规则进行第一级匹配、命中出一级风控规则，若未匹配到任何规则、则放行该业务处理请求；对于所述命中的一级风控规则、所述风控引擎将调用其内部的所有插件服务来获取JSON格式的跨业务数据，并将所述JSON格式的跨业务数据与所述业务处理请求对应的JSON串合并；根据合并后JSON串对所述一级风控规则进行第二级匹配、以命中二级风控规则，获取执行所述二级风控规则所需的业务参数值进行阈值匹配以得出风险判断的结果。
4.如权利要求3所述的业务风控系统，其特征在于，所述业务风控系统还将对任一业务处理请求的风险判定结果返回给对应的业务处理方，由该业务处理方确定中断该业务处理请求还是放过该业务处理请求。
5.如权利要求4所述的业务风控系统，其特征在于，该业务风控系统还支持插件化开发来实现对业务处理请求的风险判定结果进行处理。
6.一种实现统一业务风控的方法，其特征在于，所述方法包括：为需要跨业务数据进行风险判断的业务处理请求设置带插件服务的风控规则；风控引擎通过获取与该业务请求匹配的风控规则后调用所述匹配的风控规则内的插件服务来获取跨业务数据以便针对该业务请求进行跨业务风险判断。
7.如权利要求6所述的方法，其特征在于，所述方法还包括：对需要跨业务进行风险判断的业务处理请求，与其匹配的风控规则内配置的所述插件服务的入参设置为所述业务处理请求对应的JSON串，调用所述插件服务所获取的响应数据也设置为JSON串。
8.如权利要求6或7所述的方法，其特征在于，所述方法还包括：对任一业务请求进行风险判断时，将待判断风险的业务处理请求的所有字段转换成一个JSON串随所述风控请求发送给所述风控引擎；所述风控引擎根据接收到的所述业务处理请求的业务标识查找出对应的一组风控规则；根据所述业务处理请求对应的JSON串与该组风控规则进行第一级匹配命中一级风控规则，若未匹配到任何规则、则放行该业务处理请求；对于所述命中的一级风控规则、通过调用其内部配置的所有插件服务来获取JSON格式的跨业务数据，并将所述JSON格式的跨业务数据与所述业务处理请求对应的JSON串合并；根据合并后JSON串对所述一级风控规则进行第二级匹配命中二级风控规则，根据执行所述二级风控规则所需的业务参数值进行阈值匹配以得出风险判断的结果。
9.如权利要求8所述的方法，其特征在于，所述方法还包括：将对任一业务处理请求的风险判定结果返回给对应的业务处理方，由该业务处理方确定中断该业务处理请求还是放
2
CN 111544891 A
权 利 要 求 书
2/2页
过该业务处理请求。
10.如权利要求9所述的方法，其特征在于，所述方法还包括：可以采用开发的插件服务来实现对业务处理请求的风险判定结果进行处理。
3
CN 111544891 A
说 明 书
一种统一的业务风控系统、风控方法
1/5页
技术领域
[0001]本发明涉及企业内部的业务风险控制领域，具体涉及一种统一的业务风控系统、风控方法，应用于企业内部存在的需要进行跨业务数据风险判断的场景。背景技术
[0002]目前，采用互联网进行业务处理越来越普遍，在进行业务处理时存在的风险越来越大、造成的损失也越来越严重，为此、针对企业内部业务处理的风控系统日益受到各互联往企业的关注。各个互联网公司内部均存在多种业务，比如账号注册与登录、会员积分、充值、计费、交易等多种业务。除此之外，每个业务请求进行风控判断时绝大多数会有跨业务数据参与风控判断的需求。因此，一个公司内部如果对各种业务分别实现相应的风控系统，除了会带来重复建设的成本投入问题，也会导致带来极大的业务耦合问题。[0003]曾经为了解决业务耦合问题，每个业务发展了一套自己业务对应的风控模块或风控系统。该方案虽然解决了当前业务的耦合问题，但不同业务体系重复维护多套风控系统，对一个公司带来的维护成本巨大，各自为政也导致了每一套风控系统均有各自的局限性、不能发展壮大，同时也会造成各个风控系统之间的数据孤岛现象。[0004]考虑以上这些痛点，构建一个在各种业务之上进行抽象的统一风控系统势在必行。某一个业务的风控判断需要联合多个业务的数据进行综合判断，比如一笔充值请求、属于充值业务，但也需要关注发起这笔充值请求的账号的登录行为是否正常、是否符合玩家登录习惯，这就涉及到了账号业务。目前针对业务处理的风控系统虽然实现了风控规则的判断，即统一风控系统可以判定风控结果；但在进行风控规则判断前需要发送风控请求的业务方把执行相应风控规则判断所需的所有业务数据提前准备好，这导致了接入了风控系统的业务需要与其他业务进行耦合，这就又成了改进点。发明内容
[0005]本发明提供一种统一的业务风控系统，在需要进行跨业务风险判断时，实现业务解耦、实现业务处理方无感知以及风控模块复用以减少重复建设的目的。采用所述业务风控系统处理业务处理方发送的风控请求时，业务处理方不需要了解风控策略的实现细节，仅需要发送业务的原始请求；所述业务风控系统自行匹配出对应的风控规则，执行风险判定并结果反馈给业务处理方进行后续处理。同时本发明提供的业务风控系统也支持事后纠偏，给予风险造成者予以惩罚。
[0006]本发明提供的统一的业务风控系统包括：风控引擎和风控规则。其中，与需要跨业务数据进行风险判断的业务处理请求所触发的风控请求对应的风控规则内部配置有获取跨业务数据的插件服务。所述风控引擎在获取与该风控请求匹配的风控规则后调用所述匹配的风控规则内部配置的插件服务来获取跨业务数据以便针对该业务处理请求进行跨业务风险判断以便针对该业务处理请求进行风险判断。[0007]进一步地、对任一业务请求进行风险判断时，业务处理方将待判断风险的业务处
4
CN 111544891 A
说 明 书
2/5页
理请求的所有字段转换成一个JSON串随所述风控请求发送给所述风控引擎；所述风控引擎根据接收到的所述业务处理请求的业务标识查找出对应的一组风控规则；然后根据所述业务处理请求对应的JSON串与该组风控规则进行第一级匹配命中一级风控规则，若未匹配到任何规则、则放行该业务处理请求。对于所述命中的一级风控规则、所述风控引擎将调用其内部的所有插件服务来获取JSON格式的跨业务数据，并将所述JSON格式的跨业务数据与所述业务处理请求对应的JSON串合并；根据合并后JSON串对所述一级风控规则进行第二级匹配命中二级风控规则，获取执行所述二级风控规则所需的本业务内的参数值进行阈值匹配以得出风险判断的结果。
[0008]所述业务风控系统在获得风险判定的结果后返回给对应的业务处理方，由该业务处理方确定中断该业务处理请求还是放过该业务处理请求。[0009]进一步地，对于业务方不关心对造成风险者采取惩罚措施的情况，本发明提供的业务风控系统对风控的惩罚措施支持插件化的开发，由所述业务风控系统在判断风控命中后自动触发惩罚措施，从而也做到了业务无感知。[0010]与上述业务风控系统相对应，本发明还提供一种实现业务风控的方法，其特征在于，所述方法包括:为需要跨业务数据进行风险判断的业务处理请求设置带插件服务的风控规则；风控引擎通过获取与该业务请求匹配的风控规则后调用所述匹配的风控规则内的插件服务来获取跨业务数据以便针对该业务请求进行跨业务风险判断。
[0011]本发明还提供的上述实现业务风控的方法具体过程与上述统一的业务风控系统进行风险判断时的处理细节相对应。
附图说明
[0012]图1为本发明提供的业务风控系统的工作过程示意图。
具体实施方式
[0013]为了使本发明所解决的技术问题、技术方案以及有益效果更加清楚明白，以下结合附图对本发明进行进一步详细说明。应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0014]软件行业的业务处理基本都是通过请求、响应这种模式来实现的，请求和响应均由多个键值对来定义业务模型。不同的业务，不同的接口会有不同的请求字段、响应字段。而对不同的业务请求进行的风险判定是有共性的，比如可能都需要阈值判断、都需要限定周期内的累计判断等等，一般都满足以下条件：(1)、询问风控，(2)、风控判定结果，(3)、好的结果放过，坏的结果进行惩罚。
[0015]本发明提供的业务风控系统通过在业务之上进行抽象，把请求的所有字段扁平化(以JSON串形式传递)，并且把风控的常用规则给提取出来支持通用配置。在进行规则配置时业务的原始请求字段可以首先参与对应业务的一组规则匹配(第一级匹配)；对于某个风控请求需要获得跨业务数据才能获取风险判断结果时，其对应的风控规则内配置有相应的插件服务；将通过调用该插件服务获取其他业务的字段信息追加入JSON串中，继续参与对应业务的同一组规则的第二次匹配(第二级匹配)，这2级匹配均命中同一规则了表示触发风控。
5
CN 111544891 A[0016]
说 明 书
3/5页
所述风控系统将得到的风险判定结果通知给业务处理方，由业务处理方根据风险
判定结果来确定放行还是中断当前的业务处理请求，后续由业务处理方根据实际需要进行处理。有些业务处理方对于风险判定结果为负面的风控请求，有时后续的处罚措施它不想参与；比如有一个业务是充值业务、已经判断当前这笔充值涉嫌诈骗了，对于充值业务处理方来说中断这笔充值请求就结束了；后续把骗子账号纳入黑名单就不是它需要关心的。本发明提供的风控系统对风控的惩罚措施支持插件化的开发，由所述业务风控系统在判断风控命中后自动触发惩罚措施，从而也做到了业务无感知。
[0017]本发明提供的风控系统的工作过程示意图如图1所示，本发明提供的统一的业务风控系统包括：风控引擎和风控规则(未示出)。其中，与需要跨业务数据进行风险判断的业务处理请求所触发的风控请求对应的风控规则内配置有获取跨业务数据的插件服务。所述风控引擎在获取与该风控请求匹配的风控规则后调用所述匹配的风控规则内部配置的插件服务来获取跨业务数据以便针对该业务处理请求进行跨业务风险判断以便针对该业务处理请求进行风险判断。[0018]如图1所示，各类业务系统在接到业务处理请求时触发向本发明提供的业务风控系统发送对应的风控请求，所述风控请求包含原始的业务处理请求的业务标识等所有字段，并且所述所有字段以JSON格式来传输。业务风控系统的风控引擎接收到所述风控请求后，根据其中的业务标识字段先匹配到一组风控规则(比如充值业务对应的一组风控规则的列表可以包括几十个风控规则；对应登录业务的一组风控规则的列表可以包括上百个风控规则)。然后、根据当前原始的业务处理请求与上面拿到的一组风控规则进行第一级匹配，根据所述第一级匹配到的风控规则进行下一步处理；如果第一级匹配没有任何匹配到任何规则，则对该风控请求进行放行。
[0019]本发明提供的风控业务系统支持对原始的业务请求的任意字段进行多种表达式配置以匹配指定规则的数据，例如，业务风控系统在进行风控规则匹配时支持以下逻辑操作运算符：＝＝(等于)、！＝(不等于)、<>(不等于)、<(小于)、>(大于)、<＝(小于等于)、>＝(大于等于)、in(在…里面)、not_in(不在…里面)、in_lookup(模糊匹配，类似like)、not_in_lookup(排除模糊匹配，类似not like)以及以上逻辑运算符的任意组合。[0020]现实中一般是满足某个条件的目标用户触发了某种规则，则判断为触发风控。举一个例子来说明针对特定风控请求进行上述风控规则匹配，比如为了保护新用户，限定VIP＝0且注册时间小于7天且用支付宝扫码支付的用户，每天充值金额限定50元。[0021]首先风控引擎在接收到针对该充值业务的风控请求后，根据其中的业务标识字段识别出为充值业务，进而匹配到对应于充值业务的一组风控规则。“限定VIP＝0且注册时间小于7天且用支付宝扫码支付的用户”这个即是筛选条件。其中“用支付宝扫码支付的用户”这个筛选条件是可以从原始业务处理请求的JSON字串中识别出来的，在进行风控规则的第一级匹配时，筛选“用支付宝扫码支付”，不满足这个条件的业务请求跳过该风控规则。[0022]第一级规则过滤的配置参考如下；[0023]FILTER_EXPR:[0024]paySubChannel in[3300 13300]
[0025]其中由于支付宝的扫描支付子通道为[3300 13300]，以上配置就代表“用支付宝扫码支付”这样的限定条件。
6
CN 111544891 A[0026]
说 明 书
4/5页
根据所述第一级匹配到的风控规则进行下一步处理时，当该业务处理请求的风险
判断需要跨业务数据时，在相应的每一个风控规则里都可以配置插件服务来获取跨业务数据。其中、所述插件服务的请求入参可以设置为业务原始业务处理请求的JSON串，其获取的响应数据的形式也为JSON串；所述插件服务可由其他模块提供，也可以集成在所述业务风控系统里。本发明提供的风控系统内部约定了插件服务的标准的请求和响应参数，每个插件服务均通过服务名+消息名来注册服务，实现了在本发明提供的风控系统内部基于“服务名.消息名”进行插件服务调用。所述风控引擎调用所述插件服务获取响应消息中的JSON串形式的跨业务数据后，将其与原始的业务处理请求的JSON串合并。根据合并后的JSON字串对上述第一级匹配得到的风控规则继续进行第二次匹配，以便再次匹配到相应的风控规则，即完成风控规则的第二级匹配。[0027]延续上述举例进行说明，在根据原始业务处理请求进行第一级筛选之后，还需要判断“限定VIP＝0且注册时间小于7天的用户”。而上述这些信息在支付的原始业务处理请求里就没有了，业务风控系统会事先开发好多个接口来实现指定功能，比如获取一个指定用户的VIP等级的接口，获取一个用户的注册信息包括注册时间的接口等。这些接口都有统一的实现协议约定，所有插件服务的入参均为原始请求的JSON串，响应的信息也是JSON串格式，这样就可以把这些接口以“服务名.消息名”的插件形式配置具体的风控规则中。在需要进行第二级匹配时，由风控引擎调用具体风控规则内配置的插件服务，获取到用户的VIP等级、用户的注册时间等信息，将这些信息与业务原始请求的JSON字串合并。然后根据合并后的字串对所述第一级匹配得到的符合“用支付宝扫码支付”的风控规则进行第二次的筛选、过滤(匹配“VIP＝0且注册时间小于7天的用户”)。上述这些操作都是在本发明提供的风控系统内部实现，业务调用方无感知，从而做到了不入侵原始代码。[0028]获取VIP等级以及用户相关信息的插件服务的配置参考如下[0029]PRE_RISK_SERVICES：
[0030]preRiskService.getVipGrade,preRiskService.checkWhiteConsigneeUser[0031]第二级过滤的配置参考如下：[0032]FILTER_EXPR2：
[0033]vipGrade＝＝0&®Days<7[0034]其中、vipGrade和regDays分别为preRiskService.getVipGrade和preRiskService.checkWhiteConsigneeUser返回字串中的数据信息。以上第二级匹配就代表“限定VIP＝0且注册时间小于7天的用户”这一条件。
[0035]通过将获取跨业务数据的处理逻辑以风控规则内部插件化的形式来实现，业务处理方不需要关心进行跨业务风险判断所涉及到的其他业务的数据信息。此外、通过插件服务可提供通用功能，在不同的风控模型或策略中可即插即用，减少重复开发。[0036]在完成风控规则的第二级匹配后，需要进行业务参数值是否满足阈值的判定。这一阶段可以通过各种周期内的各种通用计算规则来判断是否满足相应的阈值条件。例如每笔限额100，每天仅能充值5笔，密码在1分钟内输错3次则30分内不允许登录等。业务风控系统对这些规则进行了高度抽象，均通过配置就可以达成。在上述阈值条件判定完成了，就可以给出风险判断结果。将风险判断的结果反馈给业务处理方后，业务处理方可以根据风控判断结果来决定当前这笔请求是继续还是中断。也有业务处理方不关心当前风控结果，由
7
CN 111544891 A
说 明 书
5/5页
风控系统继续执行惩罚措施就可以。比如充值业务、有时处于保护新用户的考虑，对于新注册用户可以充值成功，这里业务方不关心风控结果，但需要限制这些新用户充值的点券只能消费不能交易，这里的限制可由风控系统执行。[0037]对于图1中的惩罚服务，是指对命中规则的用户或其他资源进行限制的服务。比如将造成风险的用户加入黑名单、不允许其交易，频繁输错密码后限制15分钟内不允许登录等。这些惩罚服务作为独立服务插件开发出来、供业务风控系统动态配置，即相同的惩罚服务原则上只开发一次，即可接入业务风控系统内供所有业务的事后风控使用。事后风控大体上有两种方式，一种是经过一段时间大数据分析和挖掘(比如通过聚类算法等)发现异常行为的账号或IP等(不是上面实时业务每一笔进行风控处理)进行惩罚。还有一种是跟外部公司合作，有外部公司的风控系统事后通知一些风险信息，进行追加相应的处罚。比如跟支付宝风控体系对接，由支付宝风控事后通知一些风险信息，事后追加处罚；这里种不限于支付宝这一家公司，还可以其他风控公司。
[0038]本发明提供的业务风控系统除支持线上实时风控需求外，也支持事后风控惩罚处理。
[0039]通过在风控规则内配置获取跨业务数据的插件服务来实现在业务处理方无感知的情况下对不同业务进行解耦；并且采用大量插件服务实现风控模块复用，解决企业内风控系统重复建设的问题。
[0040]与上述业务风控系统相对应，本发明还提供一种实现业务风控的方法，其特征在于，所述方法包括:为需要跨业务数据进行风险判断的业务处理请求设置带插件服务的风控规则；风控引擎通过获取与该业务请求匹配的风控规则后调用所述匹配的风控规则内的插件服务来获取跨业务数据以针对该业务请求进行跨业务风险判断。
[0041]本发明还提供的上述实现业务风控的方法具体过程与上述业务风控系统进行风险判断时的处理细节相对应。
8
CN 111544891 A
说 明 书 附 图
1/1页
图1
9
因篇幅问题不能全部显示，请点此查看更多更全内容