CN114066459A - 一种支付风险管理的方法以及相关装置 - Google Patents

Abstract

本申请公开了一种支付风险管理的方法以及相关装置。通过获取目标用户的用户信息；然后确定目标用户在支付进程中的业务信息；并基于用户信息或业务信息确定对应的标签信息，标签信息用于指示预设的风险项；进一步的将用户信息和动态信息作为指标项输入预设模型，以确定目标用户的风险特征值；进而基于风险特征值确定支付进程的管控操作。由于采用静态信息与动态信息的结合进行风险特征值的评定，可以充分反映目标用户当前的支付状态以及风险情况，保证了风险控制所考虑的维度的完整性以及有效性，从而提高了支付风险控制的准确性。

Description

一种支付风险管理的方法以及相关装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种支付风险管理的方法以及相关装置。

背景技术

随着互联网技术的迅速发展，移动支付在人们的生活中占据了重要的地位，对应的，对于移动支付过程中的违规行为的控制亦成为难题。

一般，对于银行或第三方支付机构等，监管过程中需要对准入的用户进行洗钱类风险评级。其中，银行或支付机构的洗钱类风险评级，大都基于用户本身的信息来进行评级，比如用户信息的完整性、证件信息的有效性、行业或地域信息的危险性等作为风险控制的依据。

但是，采用用户信息进行管控，对于用户本身的信息依赖过重，如果有用户信息缺失或者提交信息不准确，会导致评分结果不准确，从而影响支付过程中风险控制的准确性。

发明内容

有鉴于此，本申请提供一种支付风险管理的方法，可以有效提高支付风险控制过程的准确性。

本申请一方面提供一种支付风险管理的方法，可以应用于终端设备中包含支付风险管理的功能的系统或程序中，具体包括：响应于支付进程的启动，获取目标用户的用户信息；

确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息；

基于所述用户信息或所述业务信息确定对应的标签信息，所述标签信息用于指示预设的风险项；

将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，所述动态信息包括所述业务信息或所述标签信息中的至少一个，所述预设模型用于指示所述指标项与所述风险特征值的对应关系；

基于所述风险特征值确定所述支付进程的管控操作，所述管控操作用于对所述支付进程进行风险控制。

可选的，在本申请一些可能的实现方式中，所述将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，包括：

根据所述预设模型确定所述用户信息中的用户标识项；

基于所述用户标识项查询所述动态信息中指示的用户关联项，所述用户关联项基于所述动态信息中的数量维度或描述维度确定；

根据所述用户标识项和所述用户关联项确定所述指标项，以确定对应的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，包括：

根据所述预设模型确定所述用户信息中的设备标识项；

基于所述设备标识项查询所述动态信息中指示的设备关联项，所述设备关联项基于所述动态信息中的标识维度或位置维度确定；

根据所述设备标识项和所述设备关联项确定所述指标项，以确定对应的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息，包括：

确定所述目标用户在所述支付进程中执行的所述目标操作；

确定所述目标操作对应的数值信息；

基于所述数值信息确定所述业务信息。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

确定所述目标操作在预设时间段内的操作频率；

基于所述操作频率对所述业务信息进行更新。

可选的，在本申请一些可能的实现方式中，所述确定所述目标操作在预设时间段内的操作频率，包括：

根据所述预设时间段确定与所述目标操作相关联的操作集合；

基于额度阈值对所述操作集合进行筛选，以得到有效操作；

根据所述有效操作在所述预设时间段中的分布情况确定所述操作频率。

可选的，在本申请一些可能的实现方式中，所述将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，包括：

确定所述指标项在所述预设模型中对应的权重信息，所述权重信息基于所述支付进程设定；

根据权重信息对所述指标项对应的项目特征值进行加权计算，以得到所述目标用户的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息，包括：

根据所述用户信息确定登录信息；

若所述登录信息满足登录条件，则定所述目标用户在所述支付进程中执行的所述目标操作，以得到所述业务信息。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

基于所述风险特征值确定对应的风险评级；

根据所述风险评级对所述管控操作进行更新。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

确定所述风险评级与所述指标项的对应的关系；

基于预设规则对所述风险评级与所述指标项的对应的关系进行审核，以得到审核结果；

基于所述审核结果对所述预设模型进行更新。

可选的，在本申请一些可能的实现方式中，所述基于预设规则对所述风险评级与所述指标项的对应的关系进行审核，以得到审核结果，包括：

基于所述预设规则确定所述指标项对应的目标评级；

比对所述目标评级和所述风险评级，以得到所述审核结果。

可选的，在本申请一些可能的实现方式中，所述方法还包括：

基于所述管控操作为所述目标用户生成风险标识；

将所述风险标识与所述目标用户的对应关系进行存储，以得到黑名单，所述黑名单用户响应于所述目标用户对于所述支付进程的触发调用对应的管控操作。

本申请第二方面提供一种支付风险管理装置，包括：获取单元，用于响应于支付进程的启动，获取目标用户的用户信息；

确定单元，用于确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息；

所述确定单元，还用于基于所述用户信息或所述业务信息确定对应的标签信息，所述标签信息用于指示预设的风险项；

计算单元，用于将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，所述动态信息包括所述业务信息或所述标签信息中的至少一个，所述预设模型用于指示所述指标项与所述风险特征值的对应关系；

管理单元，用于基于所述风险特征值确定所述支付进程的管控操作，所述管控操作用于对所述支付进程进行风险控制。

可选的，在本申请一些可能的实现方式中，所述计算单元，具体用于根据所述预设模型确定所述用户信息中的用户标识项；

所述计算单元，具体用于基于所述用户标识项查询所述动态信息中指示的用户关联项，所述用户关联项基于所述动态信息中的数量维度或描述维度确定；

所述计算单元，具体用于根据所述用户标识项和所述用户关联项确定所述指标项，以确定对应的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述计算单元，具体用于根据所述预设模型确定所述用户信息中的设备标识项；

所述计算单元，具体用于基于所述设备标识项查询所述动态信息中指示的设备关联项，所述设备关联项基于所述动态信息中的标识维度或位置维度确定；

所述计算单元，具体用于根据所述设备标识项和所述设备关联项确定所述指标项，以确定对应的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述确定单元，具体用于确定所述目标用户在所述支付进程中执行的所述目标操作；

所述确定单元，具体用于确定所述目标操作对应的数值信息；

所述确定单元，具体用于基于所述数值信息确定所述业务信息。

可选的，在本申请一些可能的实现方式中，所述确定单元，具体用于确定所述目标操作在预设时间段内的操作频率；

所述确定单元，具体用于基于所述操作频率对所述业务信息进行更新。

可选的，在本申请一些可能的实现方式中，所述确定单元，具体用于根据所述预设时间段确定与所述目标操作相关联的操作集合；

所述确定单元，具体用于基于额度阈值对所述操作集合进行筛选，以得到有效操作；

所述确定单元，具体用于根据所述有效操作在所述预设时间段中的分布情况确定所述操作频率。

可选的，在本申请一些可能的实现方式中，所述计算单元，具体用于确定所述指标项在所述预设模型中对应的权重信息，所述权重信息基于所述支付进程设定；

所述计算单元，具体用于根据权重信息对所述指标项对应的项目特征值进行加权计算，以得到所述目标用户的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述确定单元，具体用于根据所述用户信息确定登录信息；

所述确定单元，具体用于若所述登录信息满足登录条件，则定所述目标用户在所述支付进程中执行的所述目标操作，以得到所述业务信息。

可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于基于所述风险特征值确定对应的风险评级；

所述管理单元，具体用于根据所述风险评级对所述管控操作进行更新。

可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于确定所述风险评级与所述指标项的对应的关系；

所述管理单元，具体用于基于预设规则对所述风险评级与所述指标项的对应的关系进行审核，以得到审核结果；

所述管理单元，具体用于基于所述审核结果对所述预设模型进行更新。

可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于基于所述预设规则确定所述指标项对应的目标评级；

所述管理单元，具体用于比对所述目标评级和所述风险评级，以得到所述审核结果。

可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于基于所述管控操作为所述目标用户生成风险标识；

所述管理单元，具体用于将所述风险标识与所述目标用户的对应关系进行存储，以得到黑名单，所述黑名单用户响应于所述目标用户对于所述支付进程的触发调用对应的管控操作。

本申请一方面提供一种计算机设备，包括：存储器、处理器以及总线系统；所述存储器用于存储程序代码；所述处理器用于根据所述程序代码中的指令执行上述第一方面或第一方面任一项所述的支付风险管理的方法。

本申请一方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述支付风险管理的方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的支付风险管理的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

通过响应于支付进程的启动，获取目标用户的用户信息；然后确定目标用户在支付进程中执行的目标操作，以得到业务信息；并基于用户信息或业务信息确定对应的标签信息，标签信息用于指示预设的风险项；进一步的将用户信息和动态信息作为指标项输入预设模型，以确定目标用户的风险特征值，动态信息包括业务信息或标签信息中的至少一个，预设模型用于指示指标项与风险特征值的对应关系；进而基于风险特征值确定支付进程的管控操作，管控操作用于对支付进程进行风险控制。由于采用静态信息与动态信息的结合进行风险特征值的评定，可以充分反映目标用户当前的支付状态以及风险情况，保证了风控控制所考虑的维度的完整性以及有效性，从而提高了支付风险控制的准确性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为支付风险管理系统运行的网络架构图；

图2为本申请实施例提供的一种支付风险管理的的流程架构图；

图3为本申请实施例提供的一种支付风险管理的方法的流程图；

图4为本申请实施例提供的一种支付风险管理的场景示意图；

图5为本申请实施例提供的另一种支付风险管理的方法的流程图；

图6为本申请实施例提供的一种支付风险管理的场景流程图；

图7为本申请实施例提供的一种支付风险管理的方法的时序图；

图8为本申请实施例提供的一种支付风险管理的系统架构图；

图9为本申请实施例提供的另一种支付风险管理的系统架构图；

图10为本申请实施例提供的一种支付风险管理装置的结构示意图；

图11为本申请实施例提供的一种终端设备的结构示意图；

图12为本申请实施例提供的一种服务器的结构示意图。

具体实施方式

本申请实施例提供了一种支付风险管理的方法以及相关装置，可以应用于终端设备中包含支付风险管理的功能的系统或程序中，通过响应于支付进程的启动，获取目标用户的用户信息；然后确定目标用户在支付进程中执行的目标操作，以得到业务信息；并基于用户信息或业务信息确定对应的标签信息，标签信息用于指示预设的风险项；进一步的将用户信息和动态信息作为指标项输入预设模型，以确定目标用户的风险特征值，其中，动态信息包括业务信息或标签信息中的至少一个，预设模型用于指示指标项与风险特征值的对应关系；进而基于风险特征值确定支付进程的管控操作，管控操作用于对支付进程进行风险控制。由于采用静态信息与动态信息的结合进行风险特征值的评定，可以充分反映目标用户当前的支付状态以及风险情况，保证了风控控制所考虑的维度的完整性以及有效性，从而提高了支付风险控制的准确性。

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

应理解，本申请提供的支付风险管理的方法可以应用于终端设备中包含支付风险管理的功能的系统或程序中，例如支付软件，具体的，支付风险管理系统可以运行于如图1所示的网络架构中，如图1所示，是支付风险管理系统运行的网络架构图，如图可知，支付风险管理系统可以提供与多个信息源的支付风险管理的过程，即对终端侧的支付操作对对应的目标用户进行风险分析，从而确定目标用户的支付权限等参数，以实现支付过程中的风险控制；可以理解的是，图1中示出了多种终端设备，在实际场景中可以有更多或更少种类的终端设备参与到支付风险管理的的过程中，具体数量和种类因实际场景而定，此处不做限定，另外，图1中示出了一个服务器，但在实际场景中，也可以有多个服务器的参与，特别是在多模型训练交互的场景中，具体服务器数量因实际场景而定。

本实施例中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

可以理解的是，上述支付风险管理系统可以运行于个人移动终端，例如：作为第三方支付平台这样的应用，也可以运行于服务器，还可以作为运行于第三方设备以提供支付风险管理的，以得到信息源的支付风险管理的处理结果；具体的支付风险管理系统可以是以一种程序的形式在上述设备中运行，也可以作为上述设备中的系统部件进行运行，还可以作为云端服务程序的一种，具体运作模式因实际场景而定，此处不做限定。

随着互联网技术的迅速发展，移动支付在人们的生活中占据了重要的地位，对应的，对于移动支付过程中的违规行为的控制亦成为难题。

一般，对于银行或第三方支付机构等，监管过程中需要对准入的用户进行洗钱类风险评级。其中，银行或支付机构的洗钱类风险评级，大都基于用户本身的信息来进行评级，比如用户信息的完整性、证件信息的有效性、行业或地域信息的危险性等作为风险控制的依据。

但是，采用用户信息进行管控，对于用户本身的信息依赖过重，如果有用户信息缺失或者提交信息不准确，会导致评分结果不准确，从而影响支付过程中风险控制的准确性。

为了解决上述问题，本申请提出了一种支付风险管理的方法，该方法应用于图2所示的支付风险管理的的流程框架中，如图2所示，为本申请实施例提供的一种支付风险管理的的流程架构图，用户通过终端进行支付操作，此时会调用该用户对应的静态信息，即用户信息；以及动态信息，即操作信息或标签信息对该用户的支付操作进行风险特征值的分析，从而根据该风险特征值对用户的支付行为进行对应的风险控制。

可以理解的是，本申请所提供的方法可以为一种程序的写入，以作为硬件系统中的一种处理逻辑，也可以作为一种支付风险管理装置，采用集成或外接的方式实现上述处理逻辑。作为一种实现方式，该支付风险管理装置通过响应于支付进程的启动，获取目标用户的用户信息；然后确定目标用户在支付进程中执行的目标操作，以得到业务信息；并基于用户信息或业务信息确定对应的标签信息，标签信息用于指示预设的风险项；进一步的将用户信息和动态信息作为指标项输入预设模型，以确定目标用户的风险特征值，其中，动态信息包括业务信息或标签信息中的至少一个，预设模型用于指示指标项与风险特征值的对应关系；进而基于风险特征值确定支付进程的管控操作，管控操作用于对支付进程进行风险控制。由于采用静态信息与动态信息的结合进行风险特征值的评定，可以充分反映目标用户当前的支付状态以及风险情况，保证了风控控制所考虑的维度的完整性以及有效性，从而提高了支付风险控制的准确性。

结合上述流程架构，下面将对本申请中支付风险管理的方法进行介绍，请参阅图3，图3为本申请实施例提供的一种支付风险管理的方法的流程图，该支付风险管理方法可以由终端设备或服务器执行，也可以由终端设备和服务器共同执行，本申请实施例以该方法由终端设备执行为例进行说明，本申请实施例至少包括以下步骤：

301、响应于支付进程的启动，获取目标用户的用户信息。

本实施例中，支付进程的启动包括支付的操作，例如点击支付按钮或转账按钮；也包括支付过程中对应的用户注册或绑卡等环节；或者商户入驻、提现、付汇等环节，具体的启动时机因具体场景而定，此处不做限定。

具体的，对于目标用户的用户信息即为用户的基本信息，例如在第三方支付的场景中，用户信息可以是目标用户的账户、密码或账户绑定的身份证号，还可以是其他具体指示性功能的标识。

在一种可能的场景中，对于注册或入驻的用户，用户信息可以包括个人的姓名、性别、出生日期、证件类型及号码、国籍、地址、职业等，商户的名称、注册日期、证件类型及号码、注册或营业地址、营业范围等。

302、确定目标用户在支付进程中执行的目标操作，以得到业务信息。

本实施例中，目标操作即为目标用户在支付进程中的操作信息，具体可以包括转账、支付、绑定等动作；也可以包括上述动作对应的具体数据，例如转账的金额；还可以包括上述动作对应的目标对象，例如转账的目标账号。而由上述操作信息所产生的数据即为业务信息，例如向用户A转账100元。

具体的，对于业务信息的确定过程，可以通过确定目标用户在支付进程中执行的目标操作；然后确定目标操作对应的数值信息；进而基于数值信息确定业务信息，例如支付50元。

可选的，为了进一步反应支付情况的频繁程度，该可以从频率维度对业务信息进行描述；即首先确定目标操作在预设时间段内的操作频率；然后基于操作频率对业务信息进行更新；例如业务信息为最近24小时内转账10次，从而提高了业务信息的完整性。

另外，考虑到一般风险较高的支付过程为大额交易，故在确定操作频率的过程中还可以对其进行筛选，即首先根据预设时间段确定与目标操作相关联的操作集合；然后基于额度阈值对操作集合进行筛选，以得到有效操作；从而根据有效操作在预设时间段中的分布情况确定操作频率；例如预设时间段24小时内交易了100次，但其中只有20次大于额度阈值一万元，故操作频率基于上述大于额度阈值的20次确定，从而提高了业务信息的准确性。

在一种可能的场景中，支付进程为第三方支付软件的支付进程，此时需要首先对用户的身份进行验证，即登录验证；通过验证后才能继续交易的操作，故确定也业务信息的过程还可以首先根据用户信息确定登录信息；若登录信息满足登录条件，则定目标用户在支付进程中执行的目标操作，以得到业务信息，从而避免了无效的资源占用的发生。

具体的，业务信息可以包括个人的账户注册或注销行为、银行卡绑定或解绑行为、资金出入的交易行为等。

303、基于用户信息或业务信息确定对应的标签信息。

本实施例中，标签信息用于指示预设的风险项；其中，预设的风险项即事先设定的对应于高风险操作的标签，例如虚拟手机号、代理IP、洗钱交易、赌博等。

具体的，确定标签信息的过程即基于用户信息或业务信息遍历是否包含上述风险项的项目，例如用户信息指示目标用户为高风险职业，而预设的风险项中包含高风险职业，则对应的标签信息即为高风险职业。

在一种可能的场景中，标签信息可以包括用户信息、操作或行为可能命中反洗钱或风险控制的风险项，比如洗钱、黑名单、欺诈、赌博等。

304、将用户信息和动态信息作为指标项输入预设模型，以确定目标用户的风险特征值。

本实施例中，动态信息包括业务信息或标签信息中的至少一个，预设模型用于指示指标项与风险特征值的对应关系；其中，动态信息即基于目标用户当前的状态确定的信息，具体包括业务信息或标签信息中的至少一个，例如目标用户当前的交易金额(业务信息)或目标用户当前处于高风险地区(标签信息)。

具体的，确定动态信息的过程可以基于用户信息进行关联所得，进而确定对应的风险特征值。具体关联的维度可以包括用户标识的维度或设备的维度。在用户标识维度关联得到风险特征值的过程中，可以首先根据预设模型确定用户信息中的用户标识项；然后基于用户标识项查询动态信息中指示的用户关联项，用户关联项基于动态信息中的数量维度或描述维度确定；进而根据用户标识项和用户关联项确定指标项，以确定对应的风险特征值。其中，用户标识项可以包括用户的身份证号，而基于该身份证号即可以查询得到绑定的账户数目(数量维度)或对应的职业信息(描述维度)，从而根据身份证号的对应的情况以及身份证号绑定的账户数目确定风险特征值。

另外，对于设备关联的维度，可以首先根据预设模型确定用户信息中的设备标识项；然后基于设备标识项查询动态信息中指示的设备关联项，设备关联项基于动态信息中的标识维度或位置维度确定；进而根据设备标识项和设备关联项确定指标项，以确定对应的风险特征值。其中，设备标识项可以为手机号。对应的设备关联项可以是手机号是否为虚拟手机号(标识维度)或该手机号所处的位置(位置维度)，从而根据虚拟手机号的判定结果以及手机号所处的位置确定风险特征值。

可以理解的是，指标项即为输入预设模型的信息，其包括用户信息和动态信息中的一种或多种的组合，而对于预设模型的计算过程则可以是不同指标项对应的风险特征值的累加即预设模型为y＝a+b，其中y为风险特征值，a为第一指标项的特征值，b为第二指标项的特征值，例如当前支付进程对应的手机号为虚拟手机号则风险特征值为+10，手机号所处的位置为高风险地区则风险特征值为+20等。

可选的，考虑到不同指标项对应的风险指示程度可能不同，故可以对指标项进行加权，即首先确定指标项在预设模型中对应的权重信息，该权重信息基于支付进程设定；然后根据权重信息对指标项对应的项目特征值进行加权计算，以得到目标用户的风险特征值。其中，考虑到支付进程的不同对应的权重设定也不相同，例如在注册场景中，对于用户身份证绑定的账号数可以设定为高权重，即绑定的账号数越多说明该操作风险越高；而在支付场景中，则可以为跨境交易提高权重等，具体的权重设定因具体的支付场景而定，此处不做限定。

在一种可能的场景中，可用采用如表1所述的指标项设定以及对应的权重、指标评分(特征值)。

表1指标项、权重信息以及特征值的对应关系表

例如，对于支付进程中用户信息指示证照号码正常、证照信息比对不一致，则用户信息对应的特征值为3/10*6+0.5/10*0＝1.8；而业务信息指示当前操作为短时高频交易则对应的特征值为2/10*5＝1；标签信息指示当前操作为高风险国家发生，则对应的特征值为2/10*5＝1；则风险特征值为1.8+1+1＝4.8。

通过对于风险特征值的计算即可以得到全局的相对风险描述，从而进行对应的管控操作。

可选的，可以根据上述风险特征值进行风险评级，从而便于风险识别的过程。具体的，对于用户的操作或交易行为，以及各类命中反洗钱或风控策略而设定的标签，一方面丰富了用户风险评级的指标项，另一方面也实现了基于最新情况对用户持续和动态的评级，而不是只基于用户基本的静态身份信息去做判断。不同评级指标和权重占比的组合，构成了预设模型的基本逻辑，也会产生不同的评分结果和等级划分，详细见表2。

表2风险评分与风险等级的对应关系

风险评分	风险等级
		0～59	非高风险
60～89	高风险
		90～100	禁入

其中，上述计算所得的风险特征值即为风险评分；而在风险等级中，禁入指的是该类用户禁止在第三方支付机构开户，已开户的用户需要进行清退；高风险指的是该类用户整体风险较高，需要特别关注或进行处置；非高风险指的是该类用户整体风险较低，基本属于体系内质量比较好的用户。具体的划分方式因实际场景而定，此处不做限定。

305、基于风险特征值确定支付进程的管控操作。

本实施例中，管控操作用于对支付进程进行风险控制。具体的管控操作可以是重点关注，即对于该用户进行标记，以提醒相关人员进行审查，管控操作还可以是禁止支付进程的进行，即检测到目标用户执行的操作高风险，故需要禁止。

具体的，对于管控操作的确定可以是基于风险特征值确定的，例如风险特征值大于风险阈值则判定为高风险；管控操作的确定还可以是基于上述风险评级确定的，即风险特征值在风险评级对应的范围内则执行对应的管控操作。

对在一种可能的场景中，对于不同风险等级的用户，例如在电子钱包账户体系内，可以施行差异化管理。对于非高风险用户，可以在体系内自由开展各类业务；对于高风险用户，会被列入重点关注名单范围，在体系内开展各类业务时，会针对评分较高的指标项进行独特策略部署，比如某高风险用户的交易命中反洗钱黑名单，故针对该用户需要单独部署基于不同类型黑名单的策略监控，一旦命中高危的制裁黑名单，该用户可能会被处罚。同时，被评级为高风险的用户，可以对用户进行加强尽调，收集更多资料进一步判断其风险严重程度，而且需要执行半年度或年度重检，确保其提供的基本信息及时得到更新。加强尽调和半年度/年度重检，都通过尽调系统触发对用户的通知提醒，用户填写和更新资料后，由审核人员在尽调系统完成资料核验，并将合格的资料传输至预设模型用于持续评级；对于禁入用户，会被列入体系黑名单，该类用户不允许在支付进程对应的体系内开展任何业务。具体的管控操作的确定可以参考表3。

表3风险评级与管控操作的对应关系

在另一种可能的场景中，在确定目标用户对应的风险评级后，可以对其对应关系进行保存，在该用户再次进行支付操作时，即可以直接调用对应的风险评级，从而确定对应的管控操作。即基于管控操作为目标用户生成风险标识；然后将风险标识与目标用户的对应关系进行存储，以得到黑名单，黑名单用户响应于目标用户对于支付进程的触发调用对应的管控操作。

具体的，对于风险等级为高风险和禁入的用户，高风险用户重点关注，在高风险用户的评分指标中，对于评分超过4分的指标项，需要单独部署策略进行监控，一旦发现频繁命中(比如一个月内命中超过五次以上)或者命中指标项下的高危细项(比如一天内转入或转出金额达到60W以上)，需要进行关闭入账或出账等资金出入管控；禁入用户需要进行已开户清退和新开户拦截，并列入永久黑名单，不提供任何服务和业务。具体的可以参考表4进行管控操作的调用。

表4调用过程中风险评级与对应的分类管控操作

风险评级	分类管控
		禁入	强制管控：清退，拦截
高风险	严格管控：策略监控，资金出入限制
		非高风险	不管控

结合上述实施例可知，通过响应于支付进程的启动，获取目标用户的用户信息；然后确定目标用户在支付进程中执行的目标操作，以得到业务信息；并基于用户信息或业务信息确定对应的标签信息，标签信息用于指示预设的风险项；进一步的将用户信息和动态信息作为指标项输入预设模型，以确定目标用户的风险特征值，其中，动态信息包括业务信息或标签信息中的至少一个，预设模型用于指示指标项与风险特征值的对应关系；进而基于风险特征值确定支付进程的管控操作，管控操作用于对支付进程进行风险控制。由于采用静态信息与动态信息的结合进行风险特征值的评定，可以充分反映目标用户当前的支付状态以及风险情况，保证了风控控制所考虑的维度的完整性以及有效性，从而提高了支付风险控制的准确性。

在一种可能的场景中，在进行管控操作之后，还可以对预设模型进行审核，即判断该预设模型确定的风险特征值是否准确，具体的过程见图4，图4为本申请实施例提供的一种支付风险管理的场景示意图。即在预设模型确定后，确定利用该预设模型所得风险评级(或风险特征值)，然后对风险评级与输入该预设模型的指标项进行审核，即指标项对应的目标评级与风险评级是否对应，从而得到审核结果，若审核结果指示不对应则对预设模型的参数进行调整，具体的可以是指标项对应权重的调整、指标项对应特征值的调整或指标项的新增或删除等。

具体的，即对于预设模型产生的风险评级，为了保证其准确性和有效性，可以引入人工核验的机制(预设规则)。即确定风险评级与指标项的对应的关系；然后基于预设规则对风险评级与管控操作的对应的关系进行审核，以得到审核结果；从而基于审核结果对预设模型进行更新。其中，所有核验流程均在风险等级审核系统完成，模型产生的数据推送至审核系统，系统自动派单至审核人员，从而基于预设规则确定管控操作对应的目标评级；进而比对目标评级和风险评级，以得到审核结果。即由制定审核人员完成风险等级的一审初审和二审复合工作，审核的时候会参考评级命中的详细指标和命中指标的详细内容，并综合分析用户的基本信息、历史行为和风险特征，对高风险和禁入两个等级的用户进行等级核验。如果发现等级评定有误，则可以由预设模型重新调整参数后进行再次评级，从而可以不断完善预设模型。

具体的，上述预设模型审核的过程可以参阅图5，图5为本申请实施例提供的另一种支付风险管理的方法的流程图，本申请实施例至少包括以下步骤：

501、获取目标用户的指标项。

本实施例中，目标用户的指标项即包括图3所示实施例的用户信息、业务信息、标签信息中的一个或多个的组合，具体形式因实际场景而定。

502、将指标项输入预设模型，以确定目标用户的风险特征值，并确定风险评级。

本实施例中，步骤502与图3所示实施例的步骤304-305相似，具体特征可以进行参考，此处不做赘述。

503、基于指标项对风险评级进行审核。

本实施例中，审核的过程即根据预设规则确定指标项对应的目标评级，例如预设规则指示对于跨境交易额达到10万的操作(指标项)的目标评级为高风险，然后查看对应的基于预设模型所得的风险评级是否为高风险。

504、判断审核是否通过。

本实施例中，判断审核是否通过即判定上述目标评级与风险评级是否一致，若一致则执行步骤505，若不一致则执行步骤506.

505、执行风险评级对应的管控操作。

本实施例中，管控操作可以参考表3所示的风险评级与管控操作的对应关系，此处不再赘述。

506、对预设模型进行参数调整。

本实施例中，参数调整的过程可以是指标项权重信息的调整，例如对于用户信息中外籍用户的权重增加。

具体的，对于参数调整的结束，即当调整后的预设模型所得的风险评级与目标评级一致即可以完整调整，从而实现持续调整的过程，保证了预设模型的准确性。

上述实施例指出了用户在支付过程中的风险管理过程，在一种可能的场景中，也可以对用户以及对应的支付对象(商户)，进行多方的风险管理过程，如图6所示，图6为本申请实施例提供的一种支付风险管理的场景流程图；图中示出了对于模型产生的风险评级，发生在用户执行目标操作，例如注册、绑卡、支付等环节时，或者商户入驻、提现、付汇等环节时。具体的，当用户平台采集数据并将数据传输至支付风险管理系统，并发起风险识别请求时，支付风险管理系统可以调用风险等级数据用于判断请求咨询的用户或商户是否有问题，并根据不同等级下的管控操作，并进行风险的实时判定过程，从而得到用户与商户双方的风险评级。

具体的，上述支付风险管理可以参见图7，图7为本申请实施例提供的一种支付风险管理的方法的时序图，该过程包括如下步骤：

701、第一终端设备向服务器发送支付指令。

本实施例中，第一终端设备即为用户操作的终端，具体的支付软件可以是银行系统或第三方支付平台，而支付方式可以是二维码识别、脸部识别、密码输入等支付操作，从而产生对应的支付指令，即触发了支付进程。

702、服务器调用预设模型确定第一风险评级。

本实施例中，通过预设模型确定第一风险评级的过程可以参考图3所示的实施例中步骤304的相关描述，此处不做赘述。

703、服务器向第二终端设备发送风险评级。

本实施例中，第二终端设备即为商户对应的终端，具体的可以是搭载网商平台的终端，也可以是自助收银设备等。

而向第二终端设备发送第一终端设备的风险评级，即为了使得第二终端设备识别对应的交易对象，以便于第二终端设备主动进行交易对象的筛选。

704、第二终端设备向服务器发送交易请求。

本实施例中，若第一终端设备的风险评级满足第二终端设备对于交易对象的需求，则向服务器发送交易请求，即可以与第一终端设备进行交易。

705、服务器调用预设模型确定第二风险评级。

本实施例中，通过预设模型确定第二风险评级的过程可以参考图3所示的实施例中步骤304的相关描述，此处不做赘述。

706、服务器基于风险评级进行风险控制管理。

本实施例中，风险控制管理的过程即判断第一终端设备与第二终端设备的风险评级是否匹配，例如当第一终端设备与第二终端设备的风险评级不相同，或有一方为高风险时，对双方进行交易提醒，从而保证交易的安全性。

707、第一终端设备与第二终端设备之间执行支付进程。

本实施例中，第一终端设备与第二终端设备之间执行支付进程的过程也涉及服务器中对应的虚拟账号信息的修改，或对应的修改信息的生成，例如银行卡余额的修订。

可以理解的是，上述支付风险管理的过程不限于两个终端设备之间，还可以涉及更多的终端设备之间的支付进程，具体数量因实际场景而定。

通过对于支付进程各方的风险管理，从不同的维度提高了支付进程的安全性。

在一种可能的场景中，上述服务器可以采用图8所示的架构，图8为本申请实施例提供的一种支付风险管理的系统架构图；即包括业务数据库、风控数据库、模型数据库、模型开发模块、模型部署模块、模型运行模块、等级审核模块以及评级应用模块。

具体的，业务数据库即用于存储用户信息和业务数据，该用户信息和业务信息来自前端业务系统的采集；而风控数据库则用户存储风险标签数据，该数据产生自支付风险管理系统，即由历史数据中发生高风险操作时总结所得。对于预设模型所使用的数据，用户信息和业务信息来自业务数据库，风险标签数据来自风控数据库，业务数据库和风控数据库均通过数据表自动同步的方式，将上一次管理过程涉及的数据进行存储。

对于模型开发模块，即在模型数据库中，首先进行数据读取和加载，加载完成后进行数据预处理。数据预处理依赖特征，作为数据和模型之间的接口，特征告诉模型如何使用数据。原数据可能包含各类特征，特征计算和处理完成后，适用模型工具按照给定评级逻辑构建模型，并完成训练。同时，不断进行模型代码调试，以确保模型逻辑的准确和有效。

而对于模型部署模块以及模型运行模块，在构建完成并调试通过的模型，将其部署到线上服务中，实现自动化运行。模型按照预设规则，不断从数据仓库获取数据并进行计算，将计算结果存储到数据仓库，同时将其同步至等级审核模块或其它系统用于评级结果的审核应用。

评级应用模块即用于保存风险特征值与风险评级的对应关系，从而确定对应的风险评级。

另外，在服务器与外部业务平台进行交互的过程中，可以参考图9，图9为本申请实施例提供的另一种支付风险管理的系统架构图；其中，业务平台获取用户信息和业务数据并存住在业务数据库内。

具体的，在不同业务场景、不同业务环节，业务平台向支付风险管理系统发起风险识别请求，支付风险管理系统做出判断后，将风险决策结果返回给业务平台，该风险决策即为管控操作。然后支付风险管理系统将风险识别和决策数据存储在风控数据库内。

进一步的，业务数据库和风控数据库将存储的数据传输至模型数据库，并在模型数据库完成预设模型的开发和验证，发布到线上服务器正式运行。对于预设模型产生的结果，首先会推送至审核系统进行核验，核验无误正式生效。之后会对高风险用户通过尽调系统进行加强尽调或者半年度/年度重检，完成资料补充或更新。

另外，审核系统和尽调系统产生和获取的数据也会存储在风控数据库。预设模型的结果，可以作为用户分级管理和分类管控的依据，以及作为用户黑名单，供风控策略调用，增强风险识别和决策能力。其中，尽调系统用于触发对特定用户的尽调，已加强监管要求下对该类用户的风险识别和判断，并完成尽调过程中所收集信息的审核和结果评定。

结合上述实施例可知，本申请首先对用于生成风险特征值的预设模型进行了改进，除了使用用户本身的静态信息外，同时加入动态业务信息和动态风险标签来丰富评级指标，更完整、客观、动态的对用户进行风险评级。在评级结束后，通过审核系统引入人工核验机制，确保评级结果的准确性、有效性。

而对于风险评级，一方面作为静态数据存储起来作为评级凭证，另一方面也会应用在用户分级管理、分类管控(设定黑名单等)，以及风控策略识别、决策中发挥作用，能够提前识别和拦截洗钱相关类风险，或者对高风险用户重点关注，通过加强尽调和重检方式确保对该类用户的持续监控和处置。

为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。请参阅图10，图10为本申请实施例提供的一种支付风险管理装置的结构示意图，支付风险管理装置1000包括：

获取单元1001，用于响应于支付进程的启动，获取目标用户的用户信息；

确定单元1002，用于确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息；

所述确定单元1002，还用于基于所述用户信息或所述业务信息确定对应的标签信息，所述标签信息用于指示预设的风险项；

计算单元1003，用于将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，所述动态信息包括所述业务信息或所述标签信息中的至少一个，所述预设模型用于指示所述指标项与所述风险特征值的对应关系；

管理单元1004，用于基于所述风险特征值确定所述支付进程的管控操作，所述管控操作用于对所述支付进程进行风险控制。

可选的，在本申请一些可能的实现方式中，所述计算单元1003，具体用于根据所述预设模型确定所述用户信息中的用户标识项；

所述计算单元1003，具体用于基于所述用户标识项查询所述动态信息中指示的用户关联项，所述用户关联项基于所述动态信息中的数量维度或描述维度确定；

所述计算单元1003，具体用于根据所述用户标识项和所述用户关联项确定所述指标项，以确定对应的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述计算单元1003，具体用于根据所述预设模型确定所述用户信息中的设备标识项；

所述计算单元1003，具体用于基于所述设备标识项查询所述动态信息中指示的设备关联项，所述设备关联项基于所述动态信息中的标识维度或位置维度确定；

所述计算单元1003，具体用于根据所述设备标识项和所述设备关联项确定所述指标项，以确定对应的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述确定单元1002，具体用于确定所述目标用户在所述支付进程中执行的所述目标操作；

所述确定单元1002，具体用于确定所述目标操作对应的数值信息；

所述确定单元1002，具体用于基于所述数值信息确定所述业务信息。

可选的，在本申请一些可能的实现方式中，所述确定单元1002，具体用于确定所述目标操作在预设时间段内的操作频率；

所述确定单元1002，具体用于基于所述操作频率对所述业务信息进行更新。

可选的，在本申请一些可能的实现方式中，所述确定单元1002，具体用于根据所述预设时间段确定与所述目标操作相关联的操作集合；

所述确定单元1002，具体用于基于额度阈值对所述操作集合进行筛选，以得到有效操作；

所述确定单元1002，具体用于根据所述有效操作在所述预设时间段中的分布情况确定所述操作频率。

可选的，在本申请一些可能的实现方式中，所述计算单元1003，具体用于确定所述指标项在所述预设模型中对应的权重信息，所述权重信息基于所述支付进程设定；

所述计算单元1003，具体用于根据权重信息对所述指标项对应的项目特征值进行加权计算，以得到所述目标用户的所述风险特征值。

可选的，在本申请一些可能的实现方式中，所述确定单元1002，具体用于根据所述用户信息确定登录信息；

所述确定单元1002，具体用于若所述登录信息满足登录条件，则定所述目标用户在所述支付进程中执行的所述目标操作，以得到所述业务信息。

可选的，在本申请一些可能的实现方式中，所述管理单元1004，具体用于基于所述风险特征值确定对应的风险评级；

所述管理单元1004，具体用于根据所述风险评级对所述管控操作进行更新。

可选的，在本申请一些可能的实现方式中，所述管理单元1004，具体用于确定所述风险评级与所述指标项的对应的关系；

所述管理单元1004，具体用于基于预设规则对所述风险评级与所述指标项的对应的关系进行审核，以得到审核结果；

所述管理单元1004，具体用于基于所述审核结果对所述预设模型进行更新。

可选的，在本申请一些可能的实现方式中，所述管理单元1004，具体用于基于所述预设规则确定所述指标项对应的目标评级；

所述管理单元1004，具体用于比对所述目标评级和所述风险评级，以得到所述审核结果。

可选的，在本申请一些可能的实现方式中，所述管理单元1004，具体用于基于所述管控操作为所述目标用户生成风险标识；

所述管理单元1004，具体用于将所述风险标识与所述目标用户的对应关系进行存储，以得到黑名单，所述黑名单用户响应于所述目标用户对于所述支付进程的触发调用对应的管控操作。

通过响应于支付进程的启动，获取目标用户的用户信息；然后确定目标用户在支付进程中执行的目标操作，以得到业务信息；并基于用户信息或业务信息确定对应的标签信息，标签信息用于指示预设的风险项；进一步的将用户信息和动态信息作为指标项输入预设模型，以确定目标用户的风险特征值，其中，动态信息包括业务信息或标签信息中的至少一个，预设模型用于指示指标项与风险特征值的对应关系；进而基于风险特征值确定支付进程的管控操作，管控操作用于对支付进程进行风险控制。由于采用静态信息与动态信息的结合进行风险特征值的评定，可以充分反映目标用户当前的支付状态以及风险情况，保证了风控控制所考虑的维度的完整性以及有效性，从而提高了支付风险控制的准确性。

本申请实施例还提供了一种终端设备，如图11所示，是本申请实施例提供的另一种终端设备的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端可以为包括手机、平板电脑、个人数字助理(personal digital assistant，PDA)、销售终端(point of sales，POS)、车载电脑等任意终端设备，以终端为手机为例：

图11示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图11，手机包括：射频(radio frequency，RF)电路1110、存储器1120、输入单元1130、显示单元1140、传感器1150、音频电路1160、无线保真(wireless fidelity，WiFi)模块1170、处理器1180、以及电源1190等部件。本领域技术人员可以理解，图11中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图11对手机的各个构成部件进行具体的介绍：

RF电路1110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1180处理；另外，将设计上行的数据发送给基站。通常，RF电路1110包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(low noiseamplifier，LNA)、双工器等。此外，RF电路1110还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(globalsystem of mobile communication，GSM)、通用分组无线服务(general packet radioservice，GPRS)、码分多址(code division multiple access，CDMA)、宽带码分多址(wideband code division multiple access,WCDMA)、长期演进(long term evolution，LTE)、电子邮件、短消息服务(short messaging service，SMS)等。

存储器1120可用于存储软件程序以及模块，处理器1180通过运行存储在存储器1120的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1130可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1130可包括触控面板1131以及其他输入设备1132。触控面板1131，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1131上或在触控面板1131附近的操作，以及在触控面板1131上一定范围内的隔空触控操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1131可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1180，并能接收处理器1180发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1131。除了触控面板1131，输入单元1130还可以包括其他输入设备1132。具体地，其他输入设备1132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1140可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1140可包括显示面板1141，可选的，可以采用液晶显示器(liquidcrystal display，LCD)、有机发光二极管(organic light-emitting diode，OLED)等形式来配置显示面板1141。进一步的，触控面板1131可覆盖显示面板1141，当触控面板1131检测到在其上或附近的触摸操作后，传送给处理器1180以确定触摸事件的类型，随后处理器1180根据触摸事件的类型在显示面板1141上提供相应的视觉输出。虽然在图11中，触控面板1131与显示面板1141是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1131与显示面板1141集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1150，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1141的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1141和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1160、扬声器1161，传声器1162可提供用户与手机之间的音频接口。音频电路1160可将接收到的音频数据转换后的电信号，传输到扬声器1161，由扬声器1161转换为声音信号输出；另一方面，传声器1162将收集的声音信号转换为电信号，由音频电路1160接收后转换为音频数据，再将音频数据输出处理器1180处理后，经RF电路1110以发送给比如另一手机，或者将音频数据输出至存储器1120以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图11示出了WiFi模块1170，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1180是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1120内的软件程序和/或模块，以及调用存储在存储器1120内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1180可包括一个或多个处理单元；可选的，处理器1180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1180中。

手机还包括给各个部件供电的电源1190(比如电池)，可选的，电源可以通过电源管理系统与处理器1180逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该终端所包括的处理器1180还具有执行如上述页面处理方法的各个步骤的功能。

本申请实施例还提供了一种服务器，请参阅图12，图12是本申请实施例提供的一种服务器的结构示意图，该服务器1200可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)1222(例如，一个或一个以上处理器)和存储器1232，一个或一个以上存储应用程序1242或数据1244的存储介质1230(例如一个或一个以上海量存储设备)。其中，存储器1232和存储介质1230可以是短暂存储或持久存储。存储在存储介质1230的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1222可以设置为与存储介质1230通信，在服务器1200上执行存储介质1230中的一系列指令操作。

服务器1200还可以包括一个或一个以上电源1226，一个或一个以上有线或无线网络接口1250，一个或一个以上输入输出接口1258，和/或，一个或一个以上操作系统1241，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由管理装置所执行的步骤可以基于该图12所示的服务器结构。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有支付风险管理的指令，当其在计算机上运行时，使得计算机执行如前述图3至图9所示实施例描述的方法中支付风险管理装置所执行的步骤。

本申请实施例中还提供一种包括支付风险管理的指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如前述图3至图9所示实施例描述的方法中支付风险管理装置所执行的步骤。

本申请实施例还提供了一种支付风险管理系统，所述支付风险管理系统可以包含图10所描述实施例中的支付风险管理装置，或图11所描述实施例中的终端设备，或者图12所描述的服务器。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，支付风险管理装置，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-onlymemory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (15)

1.一种支付风险管理的方法，其特征在于，包括：

响应于支付进程的启动，获取目标用户的用户信息；

确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息；

基于所述用户信息或所述业务信息确定对应的标签信息，所述标签信息用于指示预设的风险项；

将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，所述动态信息包括所述业务信息或所述标签信息中的至少一个，所述预设模型用于指示所述指标项与所述风险特征值的对应关系；

基于所述风险特征值确定所述支付进程的管控操作，所述管控操作用于对所述支付进程进行风险控制。

2.根据权利要求1所述的方法，其特征在于，所述将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，包括：

根据所述预设模型确定所述用户信息中的用户标识项；

基于所述用户标识项查询所述动态信息中指示的用户关联项，所述用户关联项基于所述动态信息中的数量维度或描述维度确定；

根据所述用户标识项和所述用户关联项确定所述指标项，以确定对应的所述风险特征值。

3.根据权利要求1所述的方法，其特征在于，所述将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，包括：

根据所述预设模型确定所述用户信息中的设备标识项；

基于所述设备标识项查询所述动态信息中指示的设备关联项，所述设备关联项基于所述动态信息中的标识维度或位置维度确定；

根据所述设备标识项和所述设备关联项确定所述指标项，以确定对应的所述风险特征值。

4.根据权利要求1所述的方法，其特征在于，所述确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息，包括：

确定所述目标用户在所述支付进程中执行的所述目标操作；

确定所述目标操作对应的数值信息；

基于所述数值信息确定所述业务信息。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

确定所述目标操作在预设时间段内的操作频率；

基于所述操作频率对所述业务信息进行更新。

6.根据权利要求5所述的方法，其特征在于，所述确定所述目标操作在预设时间段内的操作频率，包括：

根据所述预设时间段确定与所述目标操作相关联的操作集合；

基于额度阈值对所述操作集合进行筛选，以得到有效操作；

根据所述有效操作在所述预设时间段中的分布情况确定所述操作频率。

7.根据权利要求1所述的方法，其特征在于，所述将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，包括：

确定所述指标项在所述预设模型中对应的权重信息，所述权重信息基于所述支付进程设定；

根据权重信息对所述指标项对应的项目特征值进行加权计算，以得到所述目标用户的所述风险特征值。

8.根据权利要求1所述的方法，其特征在于，所述确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息，包括：

根据所述用户信息确定登录信息；

若所述登录信息满足登录条件，则定所述目标用户在所述支付进程中执行的所述目标操作，以得到所述业务信息。

9.根据权利要求1-8任一项所述的方法，其特征在于，所述方法还包括：

基于所述风险特征值确定对应的风险评级；

根据所述风险评级对所述管控操作进行更新。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

确定所述风险评级与所述指标项的对应的关系；

基于预设规则对所述风险评级与所述指标项的对应的关系进行审核，以得到审核结果；

基于所述审核结果对所述预设模型进行更新。

11.根据权利要求10所述的方法，其特征在于，所述基于预设规则对所述风险评级与所述指标项的对应的关系进行审核，以得到审核结果，包括：

基于所述预设规则确定所述指标项对应的目标评级；

比对所述目标评级和所述风险评级，以得到所述审核结果。

12.根据权利要求1-8任一项所述的方法，其特征在于，所述方法还包括：

基于所述管控操作为所述目标用户生成风险标识；

将所述风险标识与所述目标用户的对应关系进行存储，以得到黑名单，所述黑名单用户响应于所述目标用户对于所述支付进程的触发调用对应的管控操作。

13.一种支付风险管理装置，其特征在于，包括：

获取单元，用于响应于支付进程的启动，获取目标用户的用户信息；

确定单元，用于确定所述目标用户在所述支付进程中执行的目标操作，以得到业务信息；

所述确定单元，还用于基于所述用户信息或所述业务信息确定对应的标签信息，所述标签信息用于指示预设的风险项；

计算单元，用于将所述用户信息和动态信息作为指标项输入预设模型，以确定所述目标用户的风险特征值，所述动态信息包括所述业务信息或所述标签信息中的至少一个，所述预设模型用于指示所述指标项与所述风险特征值的对应关系；

管理单元，用于基于所述风险特征值确定所述支付进程的管控操作，所述管控操作用于对所述支付进程进行风险控制。

14.一种计算机设备，其特征在于，所述计算机设备包括处理器以及存储器：

所述存储器用于存储程序代码；所述处理器用于根据所述程序代码中的指令执行权利要求1至12任一项所述的支付风险管理的方法。

15.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述权利要求1至12任一项所述的支付风险管理的方法。

Images