一种支付业务风险控制方法及装置与流程

本申请涉及电子支付
技术领域：
，具体地，涉及一种支付业务风险控制方法及装置。
背景技术：
：电子支付业务不仅是电子商务发展的重要环节，也是支撑电子经济发展的重要因素。随着我国互联网技术的发展，电子商务已经成为当前经济发展的重要内容之一，电子支付的规模在不断扩大。电子支付在快速发展的背后产生了诸多因电子支付安全问题而产生的各种风险问题。电子支付，是指从事电子商务交易的当事人，包括支付方、收款方和支付机构，通过信息网络，使用安全的信息传输手段，采用数字化方式进行的货币支付或资金流转。在网络环境下进行电子支付业务(有卡/无卡)时，支付业务是指账户a向账户b进行资金划转的过程。现有技术中存在的问题：由于距离的限制，建立交易各方的安全和信任关系相当困难，电子支付业务各方都面临安全威胁。技术实现要素：本申请实施例中提供了一种支付业务风险控制方法及装置，以解决上述技术问题。根据本申请实施例的第一个方面，提供了一种支付业务风险控制方法，包括：接收支付系统发送支付数据；根据所述支付数据以及预先建立的多维度支付业务风险控制模型对支付业务的风险进行判断；将所述支付业务的风险判断结果发送给支付系统。根据本申请实施例的第二个方面，提供了一种支付业务风险控制装置，包括：接收模块，用于接收支付系统发送支付数据；判断模块，用于根据所述支付数据以及预先建立的多维度支付业务风险控制模型对支付业务的风险进行判断；控制模块，用于将所述支付业务的风险判断结果发送给支付系统。采用本申请实施例中提供的支付业务风险控制方法及装置，从支付方、接收方、支付机构、监管机构等不同关系角度对某项支付是否存在风险进行综合判断，可支持金融、行业应用等不同功能形态的支付平台、支付产品和支付方式。附图说明此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：图1示出了本申请实施例中支付业务风险控制方法实施的流程示意图；图2示出了基于关联矩阵的风险点等级设置的结构示意图；图3示出了本申请实施例中支付业务风险控制装置的结构示意图；图4示出了本申请实施例中判断模块的结构示意图。具体实施方式现有技术通常仅仅是支付机构，例如：银行，对用户的支付业务进行控制管理，当出现账户异常时提醒用户存在交易风险。针对现有技术存在的技术问题，本申请实施例中提供了一种支付业务风险控制方法及装置，针对电子支付业务，通过建立多维度支付业务风险控制模型，从支付方、收款方、支付机构、监管机构等不同关系的多个维度对某项支付是否存在风险进行综合判断。本申请实施例中的方案可以采用各种计算机语言实现，例如，面向对象的程序设计语言java和直译式脚本语言javascript等。为了使本申请实施例中的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。实施例1本申请实施例提供了一种支付业务风险控制方法，下面进行说明。图1示出了本申请实施例中支付业务风险控制方法实施的流程示意图，如图所示，所述方法可以包括：步骤101、接收支付系统发送支付数据；步骤102、根据所述支付数据以及预先建立的多维度支付业务风险控制模型对支付业务的风险进行判断；步骤103、将所述支付业务的风险判断结果发送给支付系统。具体的，可以采用接口的方式接收支付系统传递过来的需要判断的支付数据，在判断结束后再将风险判断结果通过接口返回给支付系统。本申请实施例不需要从支付系统后台数据库提取数据，只基于支付系统提供的相关数据进行风险判断。具体实施时，可以将支付系统每次支付业务的支付数据存储到数据库中，作为历史数据保存，在后续判断风险时，若涉及到历史数据的风险点判断，可以利用所述历史数据进行综合判断。本申请实施例中提供了一种支付业务风险控制方法，从支付方、收款方、支付机构、监管机构等不同关系的多个维度对某项支付是否存在风险进行综合判断，适用于网络环境下的有卡/无卡电子支付，可支持金融、行业应用等不同功能形态的支付平台、支付产品和支付方式。实施中，所述多维度支付业务风险控制模型的建立过程，包括：确定多个风险点以及多个维度；将所述风险点与预设维度建立关联矩阵；根据所述关联矩阵确定所述风险点的风险等级。具体的，风险点设置可以指在支付业务中，可能存在的风险情况。本申请对风险点的设置举例如下表所示：具体的，关联矩阵指在风险识别与风险评价中，某维度与某风险点间是否存在需考虑的风险判断问题。需要考虑，发生关联；不需要考虑，不发生关联。是否需要考虑，由管理方判断确定。本申请实施例对维度与风险点的关联矩阵举例如下表所示：注：“√”指关联，“-”指不关联。实施中，所述维度包括支付方、收款方、支付机构和监管机构。本申请实施例中多维度风控模型的维度设置可以围绕支付业务的关联方展开，主要体现支付过程中从不同立场考虑可能存在的风险点。风控的目标是满足各关联方的业务要求和资金安全。实施中，所述风险点的风险等级包括定性等级和定量等级。本申请实施例中，对风险点进行等级化处理的过程，等级化可以采用定性与定量相结合的方式进行，实现风险点等级化可度量处理。例如：等级采取5级定性描述，同时采用可度量的5分制定量描述进行设置，如下表所示。序号风险等级分值备注1高5严重的风险事件2较高4较严重的风险事件3中3一般的风险事件4较低2较轻微的风险事件5低1轻微的风险事件6无0无风险事件风险点等级设置，可采取专家评定法或其它方法评定(历史数据训练法、主观评价法等)。有两种方案，一是基于风险点的直接设置，二是基于关联矩阵的风险点等级设置。其中，基于风险点的风险等级直接设置，可以指不考虑维度只基于风险点进行等级设置。下表为一种基于风险点的直接设置的结果示例。序号风险点风险分值是否一票备注1风险点1■高□较高□中□较低□低□无5是专家评定2风险点2□高□较高■中□较低□低□无3否3风险点3■高□较高□中□较低□低□无5是4风险点4□高□较高□中■较低□低□无2否5风险点5□高□较高□中□较低□低■无0否基于关联矩阵的风险点等级设置，风险点等级设置时需基于关联矩阵设置进行等级设置。是否采取此方案，取决应用情况。图2示出了基于关联矩阵的风险点等级设置的结构示意图。基于关联矩阵的风险点等级设置结果示例如下表所示。实施中，根据所述支付数据以及预先建立的多维度支付业务风险控制模型对支付业务的风险进行判断，包括：根据预先建立的多维度支付业务风险控制模型识别出所述支付数据对应的风险点；确定所识别出的风险点中是否存在一票否决的风险点，如果存在则确定该支付业务的风险等级为最高等级；否则，将所述风险点中最高的风险等级作为该支付业务的风险等级。具体的，风险评估是基于识别的出各项风险，实现综合评估。综合评估采取等级化与一票否决相结合的评估方法。即：若识别的风险点中没有一票否决的风险点，采取等级化可度量评价机制；若识别的风险点中存在一票否决的风险点，则采取整体判断存在重大风险需一票否决的机制。a.存在一票否决的风险点某项支付，在识别的风险点中存在一项一票否决的风险点，则总评价为风险等级“高”，分值为“5”，如下表。具体的，实际处理时，本申请实施例可以发现一项一票否决的风险点时，即停止识别，也可以进行全部识别。b.不存在一票否决的风险点具体的，本申请实施例可以对每笔支付业务的风险识别及评估的结果进行记录。具体实施时，本申请实施例可以采用多线程工作模式，接收支付系统的交易数据，从初始线程池里获取线程，评估交易风险。线程池可以根据当前业务量自动增加、减少活动的线程数。本申请实施例可以采用接口方式支持支付系统调用，接收支付系统发送的每笔支付业务数据，根据风控模型的配置进行风险识别与评估，并将结果反馈给支付系统。支付系统可参考反馈结果，自行决定是否放行或阻断支付业务。实施例2基于同一发明构思，本申请实施例提供了一种支付业务风险控制装置，其解决技术问题的原理与一种支付业务风险控制方法相似，重复之处不再赘述。图3示出了本申请实施例中支付业务风险控制装置的结构示意图，如图所示，所述装置可以包括：接收模块301，用于接收支付系统发送支付数据；判断模块302，用于根据所述支付数据以及预先建立的多维度支付业务风险控制模型对支付业务的风险进行判断；控制模块303，用于将所述支付业务的风险判断结果发送给支付系统。具体的，接收模块可以采用接口方式与支付系统建立连接，接收支付系统每次发送过来的支付业务的支付数据。本申请实施例中提供了一种支付业务风险控制装置，从支付方、收款方、支付机构、监管机构等不同关系的多个维度对某项支付是否存在风险进行综合判断，适用于网络环境下的有卡/无卡电子支付，可支持金融、行业应用等不同功能形态的支付平台、支付产品和支付方式。实施中，进一步包括：建模模块304，用于确定多个风险点以及多个维度；将所述风险点与预设维度建立关联矩阵；根据所述关联矩阵确定所述风险点的风险等级。本申请实施例中评估交易数据风险分值时，需要获取系统配置的风险等级、风险维度、风险点、风险管理等参数，使用缓存机制将配置参数提前写到内存来提高调用效率，每个线程共享此数据内存。配置参数有更新时，通过接口方式，将数据从数据库更新到内存中。实施中，所述维度包括支付方、收款方、支付机构和监管机构。实施中，所述风险点的风险等级包括定性等级和定量等级。图4示出了本申请实施例中判断模块的结构示意图，如图所示，所述判断模块，包括：识别单元401，用于根据预先建立的多维度支付业务风险控制模型识别出所述支付数据对应的风险点；判断单元402，用于确定所识别出的风险点中是否存在一票否决的风险点；处理单元403，用于如果所识别出的风险点中存在一票否决的风险点，则确定该支付业务的风险等级为最高等级；否则，将所述风险点中最高的风险等级作为该支付业务的风险等级。本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。本申请由国家重点研发计划资助，项目编号为2017yfb0802600。当前第1页12