一种业务处理方法及装置与流程

本申请涉及互联网技术领域，尤其涉及一种业务处理方法及装置。

背景技术：

随着互联网信息技术的发展，通过互联网为用户提供业务服务变得越来越普遍，业务服务的场景也越来越多。网络业务服务在为用户带来便利的同时，也带来了一定的风险。为了保证网络业务服务的顺利进行，需要设置风险监控系统来对用户的业务处理请求进行风险识别。

随着风险监控系统需要监控风险的业务场景越来越多、风险形势越来越复杂，对各种风险的监控力度以及监控时效性要求也越来越高，用于进行风险识别的规则模型越来越多，计算复杂度越来越高。这些都导致风险监控系统对系统资源的消耗以及分析耗时显著增加。

可见，目前需要提供一个更合理的风险监控方式来提高风险分析性能，及节省系统资源消耗。

技术实现要素：

本申请实施例提供一种业务处理方法及装置，用以节省系统资源消耗、提高风险识别性能。

本申请实施例提供的一种业务处理方法包括：

在接收到用户的业务处理请求后，基于快速风险识别层的识别算法，对所述业务处理请求进行快速风险识别；

若在进行快速风险识别后，无法确定所述业务处理请求是否存在风险，则基于深度风险识别层的识别算法，对所述业务处理请求进行深度风险识别；其 中，进行深度风险识别所使用的数据量大于进行快速风险识别所使用的数据量，且进行深度风险识别所使用的识别时长大于进行快速风险识别所使用的识别时长；

根据进行深度风险识别的结果，处理所述业务处理请求。

可选地，基于快速风险识别层的识别算法，对所述业务处理请求进行快速风险识别，包括：

基于所述业务处理请求中携带的用户数据，判断所述用户数据是否属于预先存储的可信用户名单或风险用户名单中的用户数据；

若所述用户数据为可信用户名单中的用户数据，则确定所述业务处理请求为安全请求，若所述用户数据为风险用户名单中的用户数据，则确定所述业务处理请求为风险请求。

可选地，若所述用户数据既不属于预先存储的可信用户名单中的用户数据，也不属于预先存储的风险用户名单中的用户数据，则基于快速风险识别层的识别算法，对所述业务处理请求进行快速风险识别，还包括：

基于所述业务处理请求中携带的用户数据、所述用户的历史行为数据、以及用于进行用户行为画像比对的规则模型，判断所述业务处理请求所指示的用户当前操作行为与所述用户的历史习惯性操作行为是否匹配；

若匹配，则确定所述业务处理请求为安全请求，若不匹配，则确定所述业务处理请求为风险请求。

可选地，基于深度风险识别层的识别算法，对所述业务处理请求进行深度风险识别，包括：

根据所述业务处理请求的业务处理类型，从预设的多种风险主题中选择至少一种风险主题；

在选择的每种风险主题下，基于所述业务处理请求对应的业务场景信息，选择用于进行第二层级风险识别的规则模型；

基于选择的规则模型，对所述业务处理请求进行深度风险识别。

可选地，所述方法还包括：

基于全面风险识别层的识别算法，对所述业务处理请求进行全面风险识别；其中，所述全面风险识别与所述快速风险识别和深度风险识别异步执行，进行全面风险识别所使用的数据量大于进行快速风险识别及深度风险识别所使用的数据量，且进行全面风险识别所使用的识别时长大于进行快速风险识别及深度风险识别所使用的识别时长；

基于进行全面风险识别的结果，更新以下信息中的一种或多种：

预设的可信用户名单；

预设的风险用户名单；

所述用户的历史行为数据；

预设的规则模型。

本申请实施例提供一种业务处理装置，包括：

第一识别模块，用于在接收到用户的业务处理请求后，基于快速风险识别层的识别算法，对所述业务处理请求进行快速风险识别；

第二识别模块，用于若在进行快速风险识别后，无法确定所述业务处理请求是否存在风险，则基于深度风险识别层的识别算法，对所述业务处理请求进行深度风险识别；其中，进行深度风险识别所使用的数据量大于进行快速风险识别所使用的数据量，且进行深度风险识别所使用的识别时长大于进行快速风险识别所使用的识别时长；

处理模块，用于根据进行深度风险识别的结果，处理所述业务处理请求。

上述风险识别方法及装置提供了一种对用户的业务处理请求进行分层级风险识别的方案，在快速风险识别层，采用较少的数据及较短的识别时间进行识别，针对无法确认是风险请求还是安全请求的业务处理请求，再采用较多的数据及较长的时间进行深度风险识别。由于对于较为明显的风险请求或安全请求，可以在快速风险识别层中采用较少的数据快速识别出来，因此相比直接执行较复杂的风险识别算法的方式，可以提高识别效率，节省系统资源消耗；另 外，对于不容易识别的业务处理请求，再进行较复杂的深度风险识别，从而可以保证风险识别的准确性。

另外，在本申请优选的实施方式中，进一步提供了基于全面风险识别层的识别算法进行全面风险识别的方式，全面风险识别与快速风险识别和深度风险识别异步进行，可以在优化整个风险识别算法的同时，保证业务处理的顺利进行。

附图说明

图1为本申请实施例一提供的业务处理方法流程图；

图2为本申请实施例二提供的风险识别方法流程图；

图3为本申请实施例提供的风险识别装置结构示意图。

具体实施方式

本申请实施例对用户的业务处理请求进行分层级的风险识别，在快速风险识别层，采用较少的数据及较短的识别时间进行识别，针对无法确认是风险请求还是安全请求的业务处理请求，再采用较多的数据及较长的时间进行深度风险识别。由于对于较为明显的风险请求或安全请求，可以在快速风险识别层中采用较少的数据快速识别出来，相比直接执行较复杂的风险识别算法的方式，可以提高识别效率，节省系统资源消耗，而对于不容易识别的业务处理请求，再进行较复杂的深度风险识别，可以提高风险识别的准确性。另外，在本申请优选的实施方式中，进一步提供了基于全面风险识别层的识别算法进行全面风险识别的方式，全面风险识别与快速风险识别和深度风险识别异步进行，可以在优化整个风险识别算法的同时，保证业务处理的顺利进行。

下面结合说明书附图对本申请实施例作进一步详细描述。

实施例一

如图1所示，为本申请实施例一提供的业务处理方法流程图，包括以下步 骤：

S101：在接收到用户的业务处理请求后，基于快速风险识别层的识别算法，对所述业务处理请求进行快速风险识别。

在具体实施过程中，可以首先基于预先存储的可信用户名单和风险用户名单，对所述业务处理请求进行快速风险识别。这里的可信用户名单中可以包括用户的可信互联网协议(Internet Protocol，IP)地址、可信媒体接入控制(Media Access Control，MAC)地址、可信终端位置等用户数据；相应地，风险用户名单中可以包括风险应用账号、风险银行卡号、风险IP地址等用户数据。若业务处理请求中的用户数据既不属于可信用户名单中的用户数据，也不属于风险用户名单中的用户数据，则可以继续基于所述业务处理请求中携带的用户数据和所述用户的历史行为数据，通过进行用户行为画像比对对所述业务处理请求进行快速风险识别，若能够通过用户行为画像比对确认所述业务处理请求是安全请求还是风险请求，则基于快速风险识别的结果，处理所述业务处理请求，否则进入S102。

比如，首先查看发起业务处理请求的用户当前使用的IP地址是否是该用户(这里可以采用账号来标识用户)之前经常使用的可信IP地址，如果是，则认为当前的业务处理请求无风险。如果不是，则查看该IP地址是否是风险IP地址，如果是，则说明当前的业务处理请求存在风险。如果不是，则可以基于预设的用于进行用户行为画像比对的规则模型，通过比对用户当前操作行为和历史习惯性操作行为的差异来确定当前操作是否存在风险，比如，在该规则模型中，可以判断用户本次操作时间是否在用户历史习惯操作时间段内、用户本次交易物品类型与用户历史交易兴趣的匹配情况，用户输入密码的敲键盘速度与用户历史习惯的匹配情况等。这里，用户的历史习惯性操作行为可以是指在用户的安全历史操作记录中出现的次数在设定阈值以上的操作行为。如果规则模型的判断结果为用户本次操作行为与历史习惯性操作行为的差异过大，则认为当前业务处理请求存在风险，如果差异很小，则认为当前业务处理请求是 安全的。如果差异介于存在风险和不存在风险所分别对应的差异之间，则无法确认当前的业务处理请求是安全请求还是风险请求，此时，进入深度风险识别。

根据统计，在所有用户操作行为中，至少有80％的操作行为可以通过快速风险识别层获得风险识别结果。由于快速风险识别层所需要的数据量及计算量都是很少的，消耗的系统计算资源和存储资源也较少，因此可以极大提升风险分析性能，减少无谓的资源消耗。

S102：若在进行快速风险识别后，无法确定所述业务处理请求是安全请求还是风险请求，则基于深度风险识别层的识别算法，对所述业务处理请求进行深度风险识别；其中，进行深度风险识别所使用的数据量大于进行快速风险识别所使用的数据量，且进行深度风险识别所使用的识别时长大于进行快速风险识别所使用的识别时长。

相比快速风险识别，在深度风险识别进行更精细化的风险分析，为了匹配到更精细化的规则模型，深度风险识别所采用的数据量较多，比如，使用的数据包括业务处理类型信息(比如转账、支付、发红包等业务处理类型)、业务场景信息(比如即时到账、担保交易等交易类型信息，再比如余额支付、快捷支付、网银支付等支付渠道信息，再比如实物交易、虚拟交易等物流类型信息，自营、外部商户等交易来源信息)等。

具体地，可以执行以下步骤：

步骤一：根据所述业务处理请求的业务处理类型，从预设的多种风险主题中选择至少一种风险主题。

这里，风险主题包括比如盗账户风险(盗用应用注册账户)、盗卡风险(盗用银行卡)、欺诈风险(比如修改他人银行卡密码)等。比如，当业务处理类型为支付时，涉及的风险可能包括盗账户风险、盗卡风险、欺诈风险，因此当处理支付类业务时，可以自动选择盗账户风险、盗卡风险、欺诈风险三种风险主题。再比如，当业务处理类型为转账时，可以自动选择盗账户风险、盗卡风险两种风险主题。

步骤二：在选择的每种风险主题下，基于所述业务处理请求对应的业务场景信息，选择用于进行深度风险识别的规则模型。

这里，不同的业务场景所对应的用于进行深度风险识别的规则模型是不同的；在不同的风险主题下，即使同样的业务场景所对应的用于进行深度风险识别的规则模型也有可能是不同的。比如，即时到账和担保交易(比如货到付款)的风险性是不同的，因此所对应的用于进行深度风险识别的规则模型是不同的，余额支付和快捷支付所对应的用于进行深度风险识别的规则模型也是不同的；在盗账户风险和盗卡风险中，同样是担保交易，其所对应的用于进行深度风险识别的规则模型也是不同的。

步骤三：基于选择的规则模型，对所述业务处理请求进行深度风险识别。

这里，进行深度风险识别时匹配选择的规则模型的数据，可以包括用户是否异地操作的信息、商户营业状态信息等多种线上已有的信息。

该步骤中，针对选择的每一种风险主题，选择用于进行深度风险识别的规则模型。若选择的风险主题有多个，则分别针对每一种风险主题进行深度风险识别，若在任意一个风险主题下的风险识别结果为当前的业务处理请求为风险请求，则认为当前的业务处理请求为风险请求。

S103：根据进行深度风险识别的结果，处理所述业务处理请求。

深度风险识别可以利用快速风险识别节省的系统资源进行更精细的数据计算，获得更准确的风险识别结果。由于深度风险识别只需针对快速风险识别无法确定识别结果的业务处理请求进行风险识别，因此，可以在保证节省系统资源的前提下，减少风险漏过概率。

实施例二

在本申请实施例二中，为了进一步提高风险识别的准确率，设计了全面风险识别层，该风险识别过程与快速风险识别和深度风险识别异步进行，也即不影响业务处理进程。全面风险识别的结果可以用于优化执行快速风险识别和深度风险识别的用户数据及规则模型。

如图2所示，为本申请实施例二提供的风险识别方法流程图，包括：

S201：业务服务器在接收到用户的业务处理请求后，基于可信用户名单/风险用户名单/用户行为画像比对，对所述业务处理请求进行快速风险识别。若该步骤能够确定所述业务处理请求是安全请求或风险请求，则进入S202，否则进入S203。

在具体实施中，首先基于所述业务处理请求中携带的用户数据，判断所述用户数据是否属于预先存储的可信用户名单或风险用户名单中的用户数据；若所述用户数据为可信用户名单中的用户数据，则确定所述业务处理请求为安全请求，若所述用户数据为风险用户名单中的用户数据，则确定所述业务处理请求为风险请求。若所述用户数据既不属于预先存储的可信用户名单中的用户数据，也不属于预先存储的风险用户名单中的用户数据，则基于所述业务处理请求中携带的用户数据、所述用户的历史行为数据、以及用于进行用户行为画像比对的规则模型，判断所述业务处理请求所指示的用户当前操作行为与所述用户的历史习惯性操作行为是否匹配，若匹配，则确定所述业务处理请求为安全请求，若不匹配，则确定所述业务处理请求为风险请求。这里，所述用户的历史习惯性操作行为可以是指在用户的安全历史操作记录中出现的次数在设定阈值以上的操作行为。

S202：根据进行快速风险识别的结果，处理所述业务处理请求。

在具体实施中，若确定所述业务处理请求是安全请求，则响应所述业务处理请求，为用户提供业务服务，若确定所述业务处理请求是风险请求，则可以拒绝所述业务处理请求。

S203：若在进行快速风险识别后，无法确定所述业务处理请求是安全请求还是风险请求，则根据所述业务处理请求的业务处理类型，从预设的多种风险主题中选择至少一种风险主题，在选择的每种风险主题下，基于所述业务处理请求对应的业务场景信息，选择用于进行深度风险识别的规则模型，基于选择的规则模型，对所述业务处理请求进行深度风险识别。

S204：根据进行深度风险识别的结果，处理所述业务处理请求。

这里，快速风险识别和深度风险识别都是线上执行的识别过程，若没有在快速风险识别层确认所述业务处理请求是安全请求还是风险请求，一定会在深度风险识别层确认所述业务处理请求是安全请求还是风险请求，以便于基于识别结果处理所述业务处理请求。但是，出于响应时间的考虑，用于进行快速风险识别和深度风险识别的数据基本都是线上已有的，仍然会存在漏过风险的情况。比如，如果可信用户名单出现异常，将会造成针对后续大量业务处理请求，执行快速风险识别的识别结果出现错误。为了进行更全面的风险挖掘，本申请实施例异步执行全面风险识别，该全面风险识别可以在处理完所述业务处理请求之后执行，也可以在处理所述业务处理请求的过程中执行，总之，不会影响所述业务处理请求的执行过程。

S205：基于全面风险识别层的识别算法，对所述业务处理请求进行全面风险识别；其中，所述全面风险识别与所述快速风险识别和深度风险识别异步执行，进行全面风险识别所使用的数据量大于进行快速风险识别及深度风险识别所使用的数据量，且进行全面风险识别所使用的识别时长大于进行快速风险识别及深度风险识别所使用的识别时长。

在进行全面风险识别时，可以通过向其它业务服务器获取用户在其它服务网站的一些数据，计算和挖掘更丰富的数据特征。全面风险识别相比快速风险识别和深度风险识别，进行风险计算及分析更全面和复杂，耗时也更长。

举例说明，进行全面风险识别的过程可以为：

向其它业务服务器获取用户在其它服务网站的用户数据，并计算用户关系网络数据、用户累计行为数据等；基于获取的用户在其它服务网站的用户数据、计算的用户关系网络数据、用户累计行为数据、以及进行快速风险识别和深度风险识别时使用的用户数据等，进行全面风险识别；

这里，全面风险识别的算法具体可以与深度风险识别的算法相同，区别在于使用的用户数据不同。所述从其它业务服务器获取的用户数据可以包括用户 在外部服务网站的交易和支付信息、指示用户在外部服务网站是否有异常操作的信息等，用户关系网络数据包括指示用户是否与其它用户有直接关系往来或间接关系往来的数据，用户累计行为数据可以包括用户在最近设定时长内对同一IP地址的登录次数、在设定时长内的异地支付总金额等。

S206：基于进行全面风险识别的结果，更新以下信息中的一种或多种：预设的可信用户名单；预设的风险用户名单；所述用户的历史行为数据；预设的规则模型。

这里，全面风险识别的结果可用于优化进行快速风险识别和深度风险识别的用户数据及规则模型。比如，当针对某个业务处理请求，进行全面风险识别的结果是该业务处理请求为风险请求，可以提取该业务处理请求涉及的应用账号，将其列入风险用户名单中；再比如，针对对应的IP地址被列入风险用户名单中的某个业务处理请求，若全面风险识别的结果是该业务处理请求为安全请求，则将该IP地址从风险用户名单中剔除；再比如，可以将统计的用户累计行为数据列入用户的历史行为数据中；再比如，若基于多个业务处理请求，统计出原来的用于进行用户行为画像比对的规则模型输出的识别结果，和/或用于进行深度风险识别的规则模型所输出的识别结果，与进行全面风险识别的结果匹配性较差，则可以基于全面风险识别的结果，对上述规则模型进行优化，以使其更匹配全面风险识别的结果。

基于同一发明构思，本申请实施例中还提供了一种与风险识别方法对应的风险识别装置，由于该装置解决问题的原理与本申请实施例风险识别方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

如图3所示，为本申请实施例提供的风险识别装置结构示意图，包括：

第一识别模块31，用于在接收到用户的业务处理请求后，基于快速风险识别层的识别算法，对所述业务处理请求进行快速风险识别；

第二识别模块32，用于若在进行快速风险识别后，无法确定所述业务处理请求是否存在风险，则基于深度风险识别层的识别算法，对所述业务处理请求 进行深度风险识别；其中，进行深度风险识别所使用的数据量大于进行快速风险识别所使用的数据量，且进行深度风险识别所使用的识别时长大于进行快速风险识别所使用的识别时长；

处理模块33，用于根据进行深度风险识别的结果，处理所述业务处理请求。

可选地，所述第一识别模块31具体用于：

基于所述业务处理请求中携带的用户数据，判断所述用户数据是否属于预先存储的可信用户名单或风险用户名单中的用户数据；若所述用户数据为可信用户名单中的用户数据，则确定所述业务处理请求为安全请求，若所述用户数据为风险用户名单中的用户数据，则确定所述业务处理请求为风险请求。

可选地，所述第一识别模块31具体用于：

若所述用户数据既不属于预先存储的可信用户名单中的用户数据，也不属于预先存储的风险用户名单中的用户数据，则基于所述业务处理请求中携带的用户数据、所述用户的历史行为数据、以及用于进行用户行为画像比对的规则模型，判断所述业务处理请求所指示的用户当前操作行为与所述用户的历史习惯性操作行为是否匹配；若匹配，则确定所述业务处理请求为安全请求，若不匹配，则确定所述业务处理请求为风险请求。

可选地，所述第二识别模块32具体用于：

根据所述业务处理请求的业务处理类型，从预设的多种风险主题中选择至少一种风险主题；在选择的每种风险主题下，基于所述业务处理请求对应的业务场景信息，选择用于进行深度风险识别的规则模型；基于选择的规则模型，对所述业务处理请求进行深度风险识别。

可选地，所述装置还包括：

第三识别模块34，用于基于全面风险识别层的识别算法，对所述业务处理请求进行全面风险识别；其中，所述全面风险识别与所述快速风险识别和深度风险识别异步执行，进行全面风险识别所使用的数据量大于进行快速风险识别及深度风险识别所使用的数据量，且进行全面风险识别所使用的识别时长大于 进行快速风险识别及深度风险识别所使用的识别时长；

基于进行全面风险识别的结果，更新以下信息中的一种或多种：

预设的可信用户名单；

预设的风险用户名单；

所述用户的历史行为数据；

预设的规则模型。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。