CN110264212A - 一种风控方法、装置及电子设备 - Google Patents

Abstract

本申请实施例提供一种风控方法、装置及电子设备。其中，风控方法包括：响应于客户端发起的交易请求，确定所述交易请求的交易方式；获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

Description

一种风控方法、装置及电子设备

技术领域

本申请实施例涉及网络支付技术领域，尤其涉及一种风控方法、装置及电子设备。

背景技术

在国际信用卡的网上交易过程中，商户端首先对交易进行风险评估，对高风险的交易进行拦截，对中等风险的交易请求银行3D安全协议(3DS，3-Domain Secure)验证，对无风险的交易直接发送至银行。银行收到商户端的请求，对于需要3D验证的交易进行校验，对于商户端放过的交易再次进行风险评估，拦截其自身认为高危的交易。在这个过程中，商户端与银行的决策是“与”的关系，任何一方认为交易有风险都会使得交易失败。但目前商户端对银行的风控能力无感知，会造成支付决策的非最优化。比如：某些银行不支持直接放行的交易，必须进行3D校验，如果商户端不请求3D交易，将导致银行拦截全部交易。再比如：某些银行发行的部分卡的网络支付不具备3D验证能力，因此商户端输出的3D验证全部在银行全部通过，并没有起到验证风险的作用。再比如：某些银行对自己发行的银行卡的风险识别能力优于商户端，而商户端并没有把更多不确定风险的交易释放到银行进行判断。

有鉴于此，如何让商户端选择与银行侧风控能力相适宜的安全验证方式对交易请求进行验证，是当前亟待解决的技术问题。

发明内容

本申请实施例目的是提供一种风控方法、装置及电子设备，能够使商户端选择与银行侧风控能力相适宜的安全验证方式对交易请求进行验证。

为了实现上述目的，本申请实施例是这样实现的：

第一方面，提供一种风控方法，包括：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

第二方面，提供一种风控装置，包括：

交易方式确定模块，响应于客户端发起的交易请求，确定所述交易请求的交易方式；

风控能力评估模块，获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

安全验证模块，选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

第三方面，提供一种电子设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

第四方面，提供一种算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如下步骤：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

本申请实施例的方案在接收到客户端所发起的交易请求后，为该交易请求配置合适交易方式，并主动感知交易机构针对该交易方式的风控能力，从而合理决策出本地需要对交易请求执行的安全验证方式。在实际应用中，本申请实施例的方案可以应用于商户端，可避免商户端高估交易机构的风控能力，而轻易地将交易请求放行给交易机构；或者，避免商户端低估交易机构的风控能力，而无意义地浪费资源对交易请求进行本地安全验证。

附图说明

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

图1为本申请实施例提供的风控方法的流程示意图。

图2为本申请实施例提供的风控方法在具体应用场景中的功能示意图。

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

图4为本申请实施例提供的电子设备的结构示意图。

具体实施方式

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

如前所述，目前的网上交易需要在商户端和银行完成安全验证，在这个过程中，商户端与银行的决策是“与”的关系，任何一方认为交易有风险都会使得交易失败。但目前商户端对银行的风控能力无感知，会造成支付决策的非最优化。比如：某些银行不支持直接放行的交易，必须进行3D校验，如果商户端不请求3D交易，将导致银行拦截全部交易。再比如：某些银行发行的部分卡的网络支付不具备3D验证能力，因此商户端输出的3D验证全部在银行全部通过，并没有起到验证风险的作用。再比如：某些银行对自己发行的银行卡的风险识别能力优于商户端，而商户端并没有把更多不确定风险的交易释放到银行进行判断。有鉴于此，本申请旨在提供一种解决方案，能够基于银行端的风控能力，合理配置商户端对交易请求所需进行的安全验证方式。

图1是本申请实施例风控方法的流程图。图1所示的方法可以由下文相对应的装置执行，包括：

步骤S102，响应于客户端发起的交易请求，确定交易请求的交易方式。

其中，交易请求可以但不限于是客户端购买商户端的商品所发起的。

在本步骤中，可以基于交易请求的风险等级，来确定适合的交易方式。比如：交易请求的风险等级较高，则可以确定一个安全验证手段较为繁琐的交易方式，以保证交易的安全性。交易请求的风险等级较低，则可以确定一个安全验证手段较为简易的交易方式，以保证交易的快捷性。

步骤S104，获取交易请求对应的交易机构中关于该交易方式的风控能力评估结果。

其中，交易机构可以但不限于是银行、支付宝等能够为交易请求提供支付的单位。

在本步骤中，可以基于交易机构的历史交易数据，本地评估交易机构关于上述交易方式的风控能力。或者，直接向交易机构获取由该交易机构自己评估的关于上述交易方式的风控能力。

步骤S106，选择与风控能力评估结果匹配的安全验证方式对上述交易请求进行安全验证。

应理解，本步骤中所选取是前端(如商户端)需要执行的安全验证方式，与交易结构(后端)执行的安全验证方式不同。

在本步骤中，如果风控能力评估结果指示交易机构中关于上述交易方式的风控能力较强，则可以选择较为简单的安全验证方式对上述交易请求进行安全验证，甚至是直接向交易机构放行上述交易请求。如果风控能力评估结果指示交易机构关于上述交易方式的风控能力较弱，则可以选择较为繁琐的安全验证方式对上述交易方式进行安全验证，并根据安全验证结果，决定是否向交易机构放行上述交易请求。

基于图1所示的方法，本申请实施例的方案在接收到客户端所发起的交易请求后，为该交易请求配置合适交易方式，并主动感知交易机构针对该交易方式的风控能力，从而合理决策出本地需要对交易请求执行的安全验证方式。在实际应用中，本申请实施例的方案可以应用于商户端，可避免商户端高估交易机构的风控能力，而轻易地将交易请求放行给交易机构；或者，避免商户端低估交易机构的风控能力，而无意义地浪费资源对交易请求进行本地安全验证。

下面对本申请实施例的方法进行详细介绍。

本申请实施例的风控方法构建了一种交易机构的风险识别能力画像，对银行进行多个维度的风险识别能力评估，应用到支付风险决策系统中，帮助商户端更好的进行风险决策。

其中，风控方法的主要流程包括：

步骤S201，商户端响应于客户端发起的交易请求，确定交易请求的交易方式。

在本步骤中，商户端可以根据客户端对应的客户画像(如客户信用信息、客户经济信息等)，来评估交易请求的风险等级。

之后，根据评估获得风险等级，确定相匹配的候选交易方式。应理解，候选交易方式是商户端基于本地策略所确定得到的，并不以一定保证呗交易机构支持。因此，商户端还需要进一步判断交易机构是否支持该候选交易方式。若支持，则将该候选交易方式作为交易请求最终的交易方式。若不支持，则选取交易机构支持的其他交易方式作为交易请求最终的交易方式。其中，重新选取到的其他交易方式的安全等级以不低于候选交易方式的安全等级为宜。

下面对判断交易机构是否支持候选交易方式进行示例性介绍。

一般情况下，如果交易机构不支持商户端所配置的交易方式，会直接决绝客户端发起的交易请求。极个别的特殊机制下，一些交易机构可能只接收白名单的客户所发起的交易请求。因此，在实际应用中，交易机构针对不支持的交易方式的支付成功率会远远低于其他支持的交易方式。

针对这一特点，可以基于交易机构针对候选交易方式的支付拒绝率，来评估交易机构关于候选交易方式的风控能力。即，支付拒绝率越高，则反映交易机构针对候选交易方式的风控能力越强。

显然，如果某个交易机构关于候选交易方式的的风控能力评分过高，已与其他交易机构孤立，则可以认定该交易机构不支持候选交易方式。

因此，通过上述方法可以快速确定出交易机构是否支持候选交易方式。在具体实施过程中，商户端可以基于离群点异常检测算法，以针对候选交易方式的支付拒绝率为异常检测维度，对样本交易机构集合(样本交易机构集合包含多个交易机构)进行异常检测，得到异常样本交易机构集合。

若本次交易请求对应的交易机构属于异常样本交易机构集合，且该交易机构针对候选交易方式的支付通过率(比如某一时期内的平均支付通过率)未达到预设要求，则确定该交易机构不支持候选交易方式；否则，确定支付机构支持候选交易方式。

步骤S202，商户端获取交易请求对应的交易机构中关于交易方式的风控能力评估结果。

在本步骤中，商户端可以基于交易请求的支付机构在第一时期(比如最近的历史交易数据统计周期)内对应交易方式的支付拒绝率和支付报案率，评估支付机构中关于交易方式的风控能力，得到风控能力评估结果。其中，支付拒绝率与支付机构中关于交易方式的风控能力呈正相关，支付报案率与支付机构中关于交易方式的风控能力呈负相关。

在实际应用中，商户端可以将在第一时期内对应交易方式的支付拒绝率和支付报案率输入至预先构建的评估模型，由评估模型直接输出支付机构中关于交易方式的风控能力评估结果。

应理解，评估模型的具体实现方式并不唯一，本申请实施例不对此不作具体限定。作为示例性介绍：评估模型可以是学习模型，比如：迭代决策树模型、逻辑回归模型、随机森林模型、朴素贝叶斯型和支持向量机模型等；或者，评估模型也可以是如非学习模型，比如：主成分分析技术模型。

此外，若商户端无法确定交易请求的风险等级，则可以基于交易请求的交易机构在第二时期内针对所有交易方式的支付拒绝率和支付报案率，评估交易机构的综合风控能力。之后，将综合风控能力评估结果作为支付机构中关于上述交易方式的风控能力评估结果。

应理解，综合风控能力也可以按照上文介绍的评估方式获得，由于原理相同，本文不再举例赘述。

步骤S203，选择与风控能力评估结果匹配的安全验证方式对交易请求进行安全验证。

下面结合实际的应用场景，对本申请实施例的风控方法进行示例性介绍。

本应用场景中，如图2所示，客户通向商户端发起交易请求后，由商户端对交易请求进行风险识别，并根据风险识别结果，选择本地对应的风险决策。

其中，交易方式可以包括2D安全协议交易方式(一种无密交易方式，下文简称2D交易)和3D安全协议交易方式(一种有密交易方式，下文简称3D交易)。

显然，针对低风险的交易请求，商户端优先选择2D交易方式，以快速完成支付。针对中高风险的交易请求，商户端优先选择3D交易方式，以降低盗刷发生的概率。针对无法风险无法判断的交易请求，则商户端需要在评估银行的综合风控能力后，选择需要发起的交易方式或本地拒绝客户端发起的交易请求。

其中，商户端风险决策对银行的风控能力给出三种画像，包括：2D交易支持性、3D交易风控能力、综合风控能力。

针对2D交易支持性：

一般情况下，某些银行卡不支持2D交易，会直觉拒绝商户端直接放行的2D交易。因此，通过如下指标计算银行的2D支持性：

2D支付拒绝率＝(商户端放行2D交易后被银行拒绝的银行卡数量)/(商户端放行2D交易的银行卡总数量)。

在上述公式中，还可以进一步加入时间窗口。举例来说，某电商平台在3月份对某家银行发行的50张银行卡发起2D交易，其中被该银行拒绝支付的银行卡数量25张，则3月份该银行的2D支付拒绝率＝25/50＝25％。

这里应用one-class SVM(单分类的支持向量机算法)算法，将银行的变量(包括上述2D支付拒绝率)进行one-class SVM建模，并对多家银行进行打分，高分银行是孤立点。并校验孤立点的2D支付通过率是否接近于0。如果，接近于0，则孤立点表征的银行不支持2D交易。

显然，对于支持2D交易的银行，商户端可以直接向银行发起2D交易，或本地执行简易的安全验证后再向银行发起2D交易。对于不支持2D交易的银行，商户端直接发起3D交易，或者本地执行简易的安全验证后再向银行发起3D交易。

针对3D交易风控能力：

可通过如下指标计算银行的3D交易风控能力：

3D支付拒绝率＝(商户端向银行发起3D交易后被银行拒绝的数量)/(商户端向银行发起3D交易的总量)。

3D支付报案率＝(银行通过商户端发起的3D交易后被报案的数量)/(商户端向银行发起3D交易的总量)。

同理，上述3D支付拒绝率和3D支付报案率也可以进一步引入时间窗口，本文不再举例赘述。

本应用场景中可以将银行针对上述两个指标的特征值输入至PCA模型，由PCA模型对上述两个指标进行加权计算，得到银行的3D交易风控能力评分。其中，3D支付拒绝率的加权系数为正值，以与3D交易风控能力评分呈正相关，D支付报案率的加权系数为负值，以与3D交易风控能力评分呈负相关。

显然，对于3D交易风控能力强的银行，商户端可以放心发起3D交易，让银行决策用户支持的风险；或者，本地执行交易的安全验证后再向银行发起3D交易。对于3D交易风控能力弱的银行，商户端需要本地进行多个维度的安全验证后再向银行发起3D交易，或者是直接本地拒绝交易请求。

针对综合风控能力:

综合风险识别能力与3D交易风控能力的计算过程类似，包括如下两个指标：

支付拒绝率＝(商户端放行任意交易请求后被银行拒绝的数量)/(商户端发出交易请求的总数量)

支付报案率＝(银行通过商户端发出的交易请求后被报案的数量)/(商户端发出交易请求的总数量)

同理，本应用场景中可以将银行针对上述两个指标的特征值输入至PCA模型，由PCA模型进行加权机选，得到银行的综合风控能力评分。

显然，对于综合风控能力强的银行，商户端可以放心发起2D交易，让银行决策用户支持的风险；或者，商户端本地执行简易的安全验证后再向银行发起2D交易。对于综合风控能力弱的银行，商户端本地执行多维度的安全验证后再向银行发起3D交易。

综上所述，本应用场景中，银行接收或拒绝的交易请求，以及客户报案被盗刷的交易请求对于商户端来讲都是公开信息，因此本申请实施例的方案在不需要对银行进行改动的情况下，在商户端实现感知银行风控能力的技术效果。

以上是对本申请实施例的方法的介绍。应理解，在不脱离本文上述原理基础之上，还可以进行适当的变化，这些变化也应视为本申请实施例的保护范围。

与上述方法相对应地，如图3所示，本申请实施例还提供一种风控装置300，包括：

交易方式确定模块310，响应于客户端发起的交易请求，确定所述交易请求的交易方式；

风控能力获取模块320，获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

安全验证模块330，选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

基于图3所示的风控装置，本申请实施例的方案在接收到客户端所发起的交易请求后，为该交易请求配置合适交易方式，并主动感知交易机构针对该交易方式的风控能力，从而合理决策出本地需要对交易请求执行的安全验证方式。在实际应用中，本申请实施例的方案可以应用于商户端，可避免商户端高估交易机构的风控能力，而轻易地将交易请求放行给交易机构；或者，避免商户端低估交易机构的风控能力，而无意义地浪费资源对交易请求进行本地安全验证。

可选地，所述风控能力获取模块320在执行时，具体基于所述交易请求的支付机构在第一时期内对应所述交易方式的支付拒绝率和支付报案率，评估所述支付机构中关于所述交易方式的风控能力，得到风控能力评估结果。

可选地，交易方式确定模块310在执行时，先确定所述交易请求的风险等级，并基于所述风险等级，确定相匹配的候选交易方式。之后，判断所述交易请求的交易机构是否支持所述候选交易方式。若支持，则将所述候选交易方式作为所述交易请求最终的交易方式；若不支持，则选取所述交易机构支持的其他交易方式作为所述交易请求最终的交易方式，其中，选取到的所述其他交易方式的安全等级不低于所述候选交易方式的安全等级。

可选地，交易方式确定模块310判断所述交易请求的交易机构是否支持所述候选交易方式可以包括:交易方式确定模块310基于离群点异常检测算法，以针对所述候选交易方式的支付拒绝率为异常检测维度，对样本交易机构集合进行异常检测，得到异常样本交易机构集合；若所述交易机构属于所述异常样本交易机构集合，且所述交易机构针对所述候选交易方式的支付通过率未达到预设要求，则确定所述支付机构不支持所述候选交易方式，否则确定所述支付机构支持所述候选交易方式。

其中，上述离群点异常检测算法可以但不限于包括单分类的支持向量机算法。

此外，交易方式确定模块310若无法确定所述交易请求的风险等级，则可以基于所述交易请求的交易机构在第二时期内针对所有交易方式的支付拒绝率和支付报案率，评估所述交易机构的综合风控能力，并将综合风控能力评估结果作为所述支付机构中关于所述交易方式的风控能力评估结果。

显然，本申请实施例的风控装置可以作为上述图1所示的风控方法的执行主体，因此所述风控装置能够实现风控方法在图1和图2所实现的功能。由于原理相同，本文不再赘述。

图4是本申请的一个实施例电子设备的结构示意图。请参考图4，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述风控装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

基于图4所示的电子设备，本申请实施例的方案在接收到客户端所发起的交易请求后，为该交易请求配置合适交易方式，并主动感知交易机构针对该交易方式的风控能力，从而合理决策出本地需要对交易请求执行的安全验证方式。在实际应用中，本申请实施例的方案可以应用于商户端，可避免商户端高估交易机构的风控能力，而轻易地将交易请求放行给交易机构；或者，避免商户端低估交易机构的风控能力，而无意义地浪费资源对交易请求进行本地安全验证。

上述如本申请图1所示实施例揭示的风控方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

应理解，本申请实施例的电子设备可以实现上述风控装置在图1和图2所示的实施例的功能，本文不再赘述。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

此外，本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1所示实施例的方法，并具体用于执行以下方法：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

应理解，上述指令当被包括多个应用程序的便携式电子设备执行时，能够使上文所述的风控装置实现图1和图2所示实施例的功能，本文不再赘述。

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

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。

Claims (10)

1.一种风控方法，包括：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

2.根据权利要求1所述的方法，

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果，包括：

基于所述交易请求的支付机构在第一时期内对应所述交易方式的支付拒绝率和支付报案率，评估所述支付机构中关于所述交易方式的风控能力，得到风控能力评估结果。

3.根据权利要求1所述的方法，

确定所述交易请求的交易方式，包括：

确定所述交易请求的风险等级；

基于所述风险等级，确定相匹配的候选交易方式；

判断所述交易请求的交易机构是否支持所述候选交易方式；

若支持，将所述候选交易方式作为所述交易请求最终的交易方式；

若不支持，选取所述交易机构支持的其他交易方式作为所述交易请求最终的交易方式，其中，选取到的所述其他交易方式的安全等级不低于所述候选交易方式的安全等级。

4.根据权利要求3所述的方法，

判断所述交易请求的交易机构是否支持所述候选交易方式，包括：

基于离群点异常检测算法，以针对所述候选交易方式的支付拒绝率为异常检测维度，对样本交易机构集合进行异常检测，得到异常样本交易机构集合；

若所述交易机构属于所述异常样本交易机构集合，且所述交易机构针对所述候选交易方式的支付通过率未达到预设要求，则确定所述支付机构不支持所述候选交易方式，否则确定所述支付机构支持所述候选交易方式。

5.根据权利要求4所述的方法，

所述离群点异常检测算法包括单分类的支持向量机算法。

6.根据权利要求3所述的方法，还包括：

若无法确定所述交易请求的风险等级，则基于所述交易请求的交易机构在第二时期内针对所有交易方式的支付拒绝率和支付报案率，评估所述交易机构的综合风控能力，并将综合风控能力评估结果作为所述支付机构中关于所述交易方式的风控能力评估结果。

7.根据权利要求1-6任一项所述的方法，

交易方式包括2D安全协议交易方式和3D安全协议交易方式。

8.一种风控装置，包括：

交易方式确定模块，响应于客户端发起的交易请求，确定所述交易请求的交易方式；

风控能力获取模块，获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

安全验证模块，选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

9.一种电子设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如下步骤：

响应于客户端发起的交易请求，确定所述交易请求的交易方式；

获取所述交易请求对应的交易机构中关于所述交易方式的风控能力评估结果；其中，所述客户端基于所述交易机构完成所述交易请求的支付；

选择与所述风控能力评估结果匹配的安全验证方式对所述交易请求进行安全验证。