CN110705988A - 受侵害行为的交互式阻断方法和系统 - Google Patents

Abstract

本公开提供了一种受侵害行为的交互式阻断方法，包括：接收并解析用户的支付请求以获取关于该用户、收款方和当前支付的信息；根据关于该用户、收款方和当前支付的信息确定该当前支付是否存在风险；在确定该当前支付存在风险时触发风险阻断交互；结合该风险阻断交互中该用户的回应确定该当前支付存在风险的风险程度；按照该风险程度处置该当前支付。

Description

受侵害行为的交互式阻断方法和系统

技术领域

本公开主要涉及风险识别，尤其涉及风险阻断。

背景技术

近年来无论是在社会上，还是在网络支付场景中，网络犯罪的气焰比较嚣张，特别是利用网络刷单、网络游戏等手法侵害用户。在此背景下，风控系统开展了卓有成效的工作。

但是，一方面，风控系统难以获知用户在支付前的行为、诈骗者使用的手法等，导致其判断的准确率不够高；另一方面，在很多情况下，即使风险识别系统已经发现某些用户的一些交易存在风险、存在被侵害的可能，并且也通过一些方式提醒了用户，但仍然难以唤醒用户、阻断用户继续被骗。

随着风控技术的进步，对于高风险行为，风控系统可根据风险手法分类并输出相应的个性化风险提示。但是由于这是风控系统的单方面提示，缺乏用户自己掌握的特有信息，风险提示的针对性弱、说服力差，从而使得用户的受侵害行为很难被阻断。

在这种情况下，本领域急需设计新的风险防范和智能管控系统，来提高风险识别准确率和用户受侵害行为阻断率。

发明内容

为解决上述技术问题，本公开提供了一种受侵害行为的交互式阻断方案。该方案能够结合系统掌握的多方面信息和用户掌握的单点信息，从而提高风险识别准确率和用户被骗行为阻断率。

在本公开一实施例中，提供了一种受侵害行为的交互式阻断方法，包括：接收并解析用户的支付请求以获取关于用户、收款方和当前支付的信息；根据关于用户、收款方和当前支付的信息确定当前支付是否存在风险；在确定当前支付存在风险时触发风险阻断交互；结合风险阻断交互中用户的回应确定当前支付存在风险的风险程度；按照风险程度处置当前支付。

在本公开的另一实施例中，该方法还包括：在确定当前支付不存在风险时，完成当前支付。

在本公开的又一实施例中，按照风险程度处置当前支付包括：在确定当前支付存在风险的风险程度为低时，完成当前支付。

在本公开的另一实施例中，按照风险程度处置当前支付包括：在确定当前支付存在风险的风险程度为高时停止当前支付。

在本公开的又一实施例中，按照风险程度处置当前支付包括：在确定当前支付存在风险的风险程度为中等时向用户提示支付风险并允许用户决定是否完成当前支付。

在本公开的另一实施例中，风险阻断交互由风险阻断交互引擎进行。

在本公开的又一实施例中，风险阻断交互引擎包括规则集或者规则引擎。

在本公开的另一实施例中，风险阻断交互引擎包括图谱集。

在本公开的又一实施例中，风险阻断交互引擎包括基于规则集或者规则引擎的学习模型。

在本公开的另一实施例中，风险阻断交互引擎包括基于图谱集的学习模型。

在本公开的又一实施例中，风险阻断交互引擎包括以下一者或多者的组合：规则集、规则引擎、图谱集、基于规则集或者规则引擎的学习模型、以及基于图谱集的学习模型。

在本公开的另一实施例中，风险阻断交互引擎能够进行异常交易结构发现。

在本公开一实施例中，提供了一种受侵害行为的交互式阻断系统，包括：获取模块，接收并解析用户的支付请求以获取关于用户、收款方和当前支付的信息；风险确定模块，根据关于用户、收款方和当前支付的信息确定当前支付是否存在风险；交互模块，在确定当前支付存在风险时触发风险阻断交互；其中风险确定模块结合风险阻断交互中用户的回应确定当前支付存在风险的风险程度；支付处置模块，按照风险程度处置当前支付。

在本公开的另一实施例中，在确定当前支付不存在风险时，支付处置模块完成当前支付。

在本公开的又一实施例中，支付处置模块按照风险程度处置当前支付包括：在确定当前支付存在风险的风险程度为低时，支付处置模块完成当前支付。

在本公开的另一实施例中，支付处置模块按照风险程度处置当前支付包括：在确定当前支付存在风险的风险程度为高时支付处置模块停止当前支付。

在本公开的又一实施例中，支付处置模块按照风险程度处置当前支付包括：在确定当前支付存在风险的风险程度为中等时支付处置模块向用户提示支付风险并允许用户决定是否完成当前支付。

在本公开的另一实施例中，交互模块包括规则集或者规则引擎。

在本公开的又一实施例中，交互模块包括图谱集。

在本公开的另一实施例中，交互模块包括基于规则集或者规则引擎的学习模型。

在本公开的又一实施例中，交互模块包括基于图谱集的学习模型。

在本公开的另一实施例中，交互模块包括以下一者或多者的组合：规则集、规则引擎、图谱集、基于规则集或者规则引擎的学习模型、以及基于图谱集的学习模型。

在本公开的又一实施例中，交互模块能够进行异常交易结构发现。

在本公开一实施例中，提供了一种存储有指令的计算机可读存储介质，当这些指令被执行时使得机器执行如前所述的方法。

提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

本公开的以上发明内容以及下面的具体实施方式在结合附图阅读时会得到更好的理解。需要说明的是，附图仅作为所请求保护的发明的示例。在附图中，相同的附图标记代表相同或类似的元素。

图1示出根据本公开一实施例的受侵害行为的交互式阻断方案的示意图；

图2示出根据本公开一实施例的风险阻断交互引擎的示意图；

图3示出根据本公开一实施例的风险阻断交互引擎进行异常转账结构发现的示意图；

图4示出根据本公开一实施例的受侵害行为的交互式阻断方法的流程图；

图5示出根据本公开一实施例的受侵害行为的交互式阻断系统的框图。

具体实施方式

为使得本公开的上述目的、特征和优点能更加明显易懂，以下结合附图对本公开的具体实施方式作详细说明。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但是本公开还可以采用其它不同于在此描述的其它方式来实施，因此本公开不受下文公开的具体实施例的限制。

本公开中所指的侵害行为是在电信或网络犯罪中，侵害者会使用某些话术和套路来让受害人误以为真，而自愿将资金转移给侵害者，从而蒙受损失的行为。

常见的侵害手法包括以刷单为由，让用户点击购买商品；冒充公检法、领导或亲友让用户进行大额转账；侵害者获取了客户网络购物信息，冒充客服人员以退款为由，向用户发送钓鱼链接等。由此，需要对这类与侵害行为相关的交易和侵害者进行识别，由此产生了受侵害风险识别的需求场景。

受侵害风险识别具有一定的挑战性，主要困难有：受侵害交易之前的行为大多发生在系统或平台外，比如通过即时聊天APP或者被电信欺诈，因此可用数据相对较少；行为特征不明显，由于用户自己被骗，其操作及支付行为都是自己发起的，因此无法获取到用户的明显异常行为；以及受侵害交易中的收益银行卡，有相当多的是新卡，由于新卡信息少，对于风险防控来说更加具有挑战性。

进一步地，即使系统或平台识别出受侵害风险并且向用户发出警告，用户往往因为其掌握有单点信息而难以被唤醒。这是因为风险提示的针对性弱、说服力差，从而使得用户的受侵害行为很难被阻断。

因此，本公开所针对的是如何在用户行将转账之际通过与用户的交互获取其所掌握的单点信息，并结合该单点信息提高风险提示的针对性和说服力，进而基于系统掌握的多方面信息和用户掌握的单点信息的组合，来提高风险识别准确率和用户被骗行为阻断率。

下文将基于附图具体描述根据本公开各个实施例的受侵害行为的交互式阻断方法和系统。

图1根据本公开一实施例的受侵害行为的交互式阻断方法100的示意图。

在根据本公开一实施例的受侵害行为的交互式阻断方法100中，用户提出支付请求。风险识别子系统104接收该支付请求并对该支付请求作出解析，获取相关于用户作为付款方、收款方或即被动方、以及当前支付的信息。这些信息主要包括：用户的账号、收款方的账号、当前支付的金额、备注信息等等。基于双方账号，可获取该两个账号的当前状态、该两个账号持有人的证件号码以及既往历史交易信息等等。

风险识别子系统104基于这些信息，可初步判断当前支付是否存在风险。对于无风险交易及时放行；对于有风险交易，则自动发起请求、请求风险阻断交互引擎102与用户进行交互。

风险阻断交互引擎102根据当前用户的状态、被动方的状态、和当前支付的信息，提出合适并且高效的问题。风险阻断引擎102提出的问题可以是多种多样的，包括但不限于问答式问题(例如，你和对方的关系是？)、选择式的问题(例如，你和对方的关系是以下哪一种：A-好友，B-亲戚)；问题的提出方式也可以包括但不限于文本、语音、或视频等。同样，用户的应答亦是如此。

风险阻断交互引擎102根据用户的应答，确定当前支付所存在风险的风险程度，即进行风险程度判定；或者针对当前可能的侵害手法，提出针对性的风险揭示，提高风险提示的说服力。

风险阻断交互引擎102可以是简单的规则集，也可以是基于强化学习实时训练的复杂模型。具体的风险阻断交互引擎102将参照图2在下文中描述。

风险阻断引擎102根据用户的应答所确定的风险程度可以有低风险支付、中等风险支付以及高风险支付。风险处置子系统106在不同的系统或平台中，针对不同风险程度的支付请求可进行不同的风险处置。

在本公开一实施例中，风险处置子系统106针对低风险的支付请求，准予进行支付；针对中等风险的支付请求，则生成合适的风险提示；用户根据接收到的风险提示内容，结合自己的转账信息，判断当前自身被侵害的可能性，并最终决定是否继续支付；而针对高风险的支付请求，风险处置子系统106停止该支付，并向用户说明原因。

本领域技术人员可以理解，不同的系统或平台对风险程度的判断是不同的，并且可依据涉及产品、时段等的不同而变化，在此不做赘述。

图2示出根据本公开一实施例的风险阻断交互引擎200的示意图。如图1所示的风险阻断交互引擎102可以是简单的规则集、基于强化学习实时训练的复杂模型，也可以是规则集和复杂模型的组合。

风险阻断解决方案可按需从简单的黑名单规则、规则引擎、到有监督机器学习模型、再到无监督机器学习模型进行选择。进一步地，风险阻断解决方案可纳入图谱集，如下所述。图2中示出的根据本公开一实施例的风险阻断交互引擎200可按需包括以上的规则集、图谱集、规则引擎以及复杂机器学习模型。本领域技术人员可以理解，随着风险阻断技术的不断进步，风险阻断交互引擎200可纳入更为先进和高效的风险阻断技术。

风险阻断交互引擎200的规则集可基于交叉验证来进行风险阻断。交叉验证主要由人工判断规则，系统检验是否符合实际情况。例如，用户身份信息(例如，姓名、身份证号、手机号码、账户等信息)和用户基本信息(例如，昵称、出生日期、性别、密码、邮箱、地址信息、公司名称、公司电话、联系人信息和电话等)的交叉校验规则、设备关联性交叉验证规则(例如，设备指纹校验)、多信息源地理位置校验、用户行为数据校验(例如，注册行为、登录行为、浏览行为、支付行为等等)、第三方数据(例如，电商记录、社交网络数据、银行及信用卡数据、司法数据等等)。

黑名单规则演进到规则引擎使得黑名单随着规则的指引而动态扩展。但是，新的侵害模式则需要通过机器学习模型来训练获知。在本公开中，在大数据所收集的大量异构、多样化的信息的基础上，利用图的数据结构将不同渠道的碎片化、异构数据整合成为机器可以理解的知识，构建关系图谱并借助规则集或引擎，可实现侵害行为的识别与防御。

进一步地，风险阻断交互引擎200可基于与当前用户账户相关的数据构建关系图谱。该图谱集可涵盖静态关系结构、行为序列图和动态关系结构。

在防侵害场景中，关系图谱聚合各类数据源，逐步绘制出当前用户(即支付请求中的支付方、或即主动方)的关系网络，从而针对性地识别出受侵害风险。以一支付方举例，该支付方有身份证号、手机号、学历等个人信息，属于个人的属性信息；而该支付方可以有亲属好友，支付方与其亲属好友之间的关系是父亲、母亲、同事、同学等关系；该支付方也具有住址、银行流水、工作单位等信息。这些信息可以来自于多个渠道，例如可以由支付方自己填写，或是积累的历史数据，或是数据提供商提供，或是在互联网上获得，甚至通过推理得到，往往具有冗余性；信息通过图的形式连结，展示出了支付方的关系网络。此外，关系图谱还可用来描述人和物的关系(例如，电话号码与人的关系)以及时间与事件的关系(例如，某人开通一电话号码的时间)等等。这样的关系网络往往是静态关系结构。

当融合来自不同数据源的信息构成关系图谱时，有一些实体会同时属于两个互斥的类别(例如同时在两个不同的城市工作)，或某个实体所对应的一个属性(例如，同一个人的住址)对应多个值，这样就会出现不一致性，该不一致性即可判定为潜在的可疑点。

通过这种不一致性检测，利用绘制出的关系图谱可识别潜在的侵害风险，包括个人信息造假、工作单位虚假、代办包装、虚假联系人、组团骗贷等。举例而言，利用关系图谱可通过收款方的身份信息PII(Personal Identifiable Information)，例如手机号或身份证号，直接索引到个人的全部信息，并以此与收款方的填写信息进行不一致性检测；也可以通过收款方的其他信息进行推理出其相关信息进行验证，例如可通过收款方的身份证号和姓名可以获得其学历信息和年龄，从而推算出其工作年限，再根据其所在城市、行业、职位，结合互联网上的招聘网站数据推理出其薪水范围，进而验证其收入水平等等。

关系图谱不仅可以整合支付方的基本信息，还可将支付方的消费记录、行为记录、网上的浏览记录等整合到关系图谱里，从而进行分析和预测。

在针对支付请求的防侵害场景中，图谱集还可纳入支付方和收款方的行为序列图，从而引入基于操作、支付以及浏览行为的事件序列，深入刻画支付方/主动方以及收款方/被动方的异常行为链，以提升整体的欺诈风险识别能力。

在防侵害场景中，图谱集还包括动态关系结构。举例而言，基于海量转账交易，能够寻找到一些异常资金结构：频繁汇入/汇出、链式交易结构、集中转入/分散转出、分散转入/集中转出、环状交易结构以及其他复杂异常交易结构。异常转账结构发现的过程将在下文中参照图3详细描述。

由此，图2所示的风险阻断交互引擎200可以是简单的规则集、关系图谱、以及借助规则集或引擎、关系图谱基于强化学习(包括有监督学习和无监督学习)实时训练的复杂模型。

图3示出根据本公开一实施例的风险阻断交互引擎进行异常转账结构发现的示意图。

异常转账结构发现由风险阻断交互引擎基于连通子图算法进行。连通性是当今网络和系统最普遍的特点，并且连接不是均匀分布的、也不是静态的，从社交关系网到交易网络均如是。图形算法利用连通关系及其动态特性，得以充分描述、乃至预测连通系统中的行为。

在本公开一实施例中，采用连通子图算法来初步发现不同的交易结构，例如链式交易结构、嵌套环状交易结构、集中转入分散转出交易结构、分散转入集中转出交易结构等等。其中，链式交易结构属于正常交易结构的可能性相对较大。本领域技术人员可以理解，可采用其他图形算法来发现这些交易结构。在此，将不对本领域技术人员可以理解的连通子图算法等图形算法进行详细描述。

如图所示，对于分散转入/集中转出和集中转入/分散转出的异常交易结构，可采用例如基于阈值过滤的算法。在交易图中，存在比较大量的转账孤岛(即两账户节点之间仅发生互相转账而与其他账户没有任何转账关系)，因此可事先过滤掉这些转账孤岛。通常，过滤后的节点规模至少缩减一半以上。接着，可以设定相应的阈值，将风险度极小的交易边删除，例如两账号之间的交易金额小于一定阈值的边全部过滤，由此很多原本非常复杂的交易网络就被缩减甚至拆分。对于中心交易节点(即分散转入/集中转出的模式)来说，一定是入度较小、出度较大。此时只需要设定相应的阈值(比如入度<θ1且出度>θ2)，而对于分散转入/集中转出的模式则条件正好相反，就可根据此类条件筛选出可疑的节点，寻找出与这些可疑节点的相关交易，便有可能发现相关的异常交易账户。

而对于环状交易结构，可使用例如基于Tarjan和Kosaraju算法来寻找环状强连通子图，再结合相应的阈值过滤即可得到相应的异常结构。同样本领域技术人员可以理解，可采用其他算法来发现这些异常环状交易结构。

然而，常常会发现符合这类条件的账户不在少数，但是真正的涉及侵害行为的交易账户往往还可基于附加的约束条件来发现，即收窄搜索范围。一个常用的约束条件是中心点折损率(即转出金额/转入金额)。一个涉及侵害行为的交易账户作为中介节点，往往起过渡作用，大部分转入的钱都会经过各种手段转出。因此如果上述筛选出来的可疑节点的中心折损率接近1，那么该账户就有很大的风险。由于侵害行为实施者总是想在较短的时间内完成侵害行为，因此时间约束是另一个常用的约束条件。如果一条线上的上下两笔交易差的时间相差太大，则可认为该结构的风险较低，可以过滤掉，由此大大精简搜索范围。

图4根据本公开一实施例的受侵害行为的交互式阻断方法的流程图。

面对疑似侵害行为，现有技术方案通常针对高风险行为，会根据风险手法分类，输出个性化的风险提示。但是由于是安全系统单方面提示，缺乏用户自己掌握的特有信息，这样的风险提示针对性弱、说服力差，用户的被侵害行为很难被阻断。

受侵害风险识别具有挑战性，由于受侵害交易之前的行为大多发生在系统或平台外(比如通过即时聊天APP或者被电信侵害)，因此可用数据相对较少；行为特征不明显，由于用户自己受侵害，其操作及支付行为都是自己发起的，因此无法获取到用户的明显异常行为；以及受侵害交易中的收益银行卡，有相当多的是新卡，新卡信息少，从而对于风险防控来说更加具有挑战性。

进一步地，即使系统或平台识别出受侵害风险并且向用户发出警告，用户往往因为其掌握有单点信息而难以被唤醒。这是因为风险提示的针对性弱、说服力差，从而使得用户的受侵害行为很难被阻断。

在本公开的受侵害行为的交互式阻断方法中，在接收到用户的支付请求之后，系统将在初步判断当前支付存在风险时，触发风险阻断交互引擎向用户提问，由此结合用户的应答进一步判断当前支付的风险程度，并依据风险程度来进行相应的处置，例如向用户发出警告，由于结合了用户所掌握的信息，因此该警告所具有的针对性和说服力都得以增强，从而使得用户的被侵害行为得以成功阻断。

在402，接收并解析用户的支付请求以获取关于用户、收款方和当前支付的信息。

在转账到账户的场景中，以侵害者通过伪造身份方式要求用户转账至安全账户为例，当侵害者告知用户其账户涉嫌洗钱且其身份为国家安全人员时，用户往往会被要求遵从其指令，将钱转账至所谓安全账户。

此时风险识别子系统所接收到的支付请求应当包含收款方、支付方、关于当前支付的详细信息等等。关于收款方(即被动方)的信息可包括姓名和账户(系统由此可获得相应的身份证号码、联系电话、转账历史、名下其他账户以及社交关系等)等。关于支付方(即用户或主动方)的信息同样可包括姓名和账户(系统同样可获得相应的身份证号码、联系电话、转账历史、名下其他账户以及社交关系等)等。关于当前支付的详细信息可包括，例如，支付金额、诸如支付用途的备注等。

在以上所述的示例中，举例而言，支付用途的备注可能含有“安全账户”等敏感字样，支付金额相对较大，或者收款方的账户可能是新账户。

由此，在风险识别子系统接收到用户的支付请求后，需要解析该支付请求，并提取其中关于用户、收款方和当前支付的详细信息。

在404，根据关于用户、收款方和当前支付的信息确定当前支付是否存在风险。

在转账到账户的场景中，还以侵害者通过伪造身份方式要求用户转账至安全账户为例，当支付用途的备注含有“安全账户”等敏感字样，支付金额相对较大，或者收款方的账户可能是新账户时，风险识别子系统可确定当前支付存在风险。

同样在转账到账户的场景中，以侵害者以投资获取高额利润为饵要求用户转账至其账户为例，当支付用途的备注含有“投资”等敏感字样，支付金额相对较大，收款方的账户可能是新账户或者并非是涉及投资的账户时，风险识别子系统可确定当前支付存在风险。

在406，在确定当前支付存在风险时触发风险阻断交互。

在确定当前支付存在风险时，风险阻断交互被触发。此时，风险阻断交互引擎可针对支付用途的备注含有“安全账户”敏感字样的情形，向用户提问：“您与收款方是什么关系？”、“收款方的安全账户是什么机构的安全账户？”等等。

在支付用途的备注含有“投资”敏感字样的情形中，风险阻断交互引擎可向用户提问：“您与收款方是什么关系？”、“收款方的投资账户是什么机构的投资账户？”等等。

本领域技术人员可以理解，针对存在不同风险的支付请求，风险阻断交互引擎可相应地向用户进行提问。

在408，结合风险阻断交互中用户的回应确定当前支付存在风险的风险程度。

依据用户对风险阻断交互引擎的提问做出的回应，该风险阻断交互引擎可进一步确定当前支付所存在风险的风险程度。

在支付用途的备注含有“安全账户”敏感字样的情形中，当用户回应“收款方为陌生人但其为安全机构的执法人员”时，该风险阻断交互引擎可查询收款方账户的所有者的背景信息，即该账户是否的确是该执法人员所称的机构所有。如果不是，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是安全机构，则确定当前支付存在风险的风险程度为高。如果风险阻断交互引擎确定该收款方账户所属机构存疑，则确定当前支付存在风险的风险程度为中等。如果确定该收款方账户的确为该执法人员所称的机构所有，则确定当前支付存在风险的风险程度为低。

在支付用途的备注含有“投资”敏感字样的情形中，当用户回应“收款方为陌生人但其为投资机构的合法人员”时，该风险阻断交互引擎可查询收款方账户的所有者的背景信息，即该账户是否的确是该人员所称的金融机构所有。如果不是，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是金融机构，则确定当前支付存在风险的风险程度为高。在本公开的另一实施例中，当收款方账户隶属异常交易结构中的一环时，确定当前支付存在风险的风险程度为高。

如果风险阻断交互引擎确定该收款方账户所属机构是金融机构、但该金融机构的投资行为的风险等级相对较高，或者该金融机构近期的资金周转存疑，则确定当前支付存在风险的风险程度为中等。如果确定该收款方账户的确为该人员所称的金融机构所有，且该金融机构正常运营、其投资行为风险等级正常，则确定当前支付存在风险的风险程度为低。

在风险阻断交互引擎确定当前支付存在风险的风险程度后，该风险程度可被传送至风险处置子系统。

在410，按照风险程度处置当前支付。

根据所确定的当前支付的风险程度，风险处置子系统可相应地处置当前支付。

在支付用途的备注含有“安全账户”敏感字样的情形中，当确定当前支付存在风险的风险程度为高时，风险处置子系统可停止当前交易，并向用户明示，该账户不是该执法人员所称的机构所有，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是安全机构。

在本公开的另一实施例中，当收款方账户隶属异常交易结构中的一环、确定当前支付存在风险的风险程度为高时，风险处置子系统可停止当前交易，并向用户明示，该账户涉及异常交易。

当确定当前支付存在风险的风险程度为中等时，风险处置子系统可警告用户，该账户所属机构是否是安全机构存疑，请进一步向该执法人员索要详细信息；该交易是否继续可请用户判定。当确定当前支付存在风险的风险程度为低时，风险处置子系统可准予当前支付。

类似地，在支付用途的备注含有“投资”敏感字样的情形中，当确定当前支付存在风险的风险程度为高时，风险处置子系统可停止当前交易，并向用户明示，该账户不是该人员所称的金融机构所有，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是金融机构。

当确定当前支付存在风险的风险程度为中等时，风险处置子系统可警告用户，该账户所属金融机构的投资行为或资金链存疑，请进一步向该人员索要详细信息；该交易是否继续可请用户判定。当确定当前支付存在风险的风险程度为低时，风险处置子系统可准予当前支付。

本领域技术人员可以理解，针对不同情况的用户，风险阻断交互引擎对不同风险的支付请求可作不同地处置。同样，针对不同的支付请求，风险阻断交互引擎对相似风险程度的支付请求可作不同地处置。

图5示出根据本公开一实施例的受侵害行为的交互式阻断系统500的框图。

受侵害行为的交互式阻断系统500包括获取模块502、风险确定模块504、交互模块506以及支付处置模块508。

获取模块502接收并解析用户的支付请求以获取关于用户、收款方和当前支付的信息。

在转账到账户的场景中，以侵害者通过伪造身份方式要求用户转账至安全账户为例，当侵害者告知用户其账户涉嫌洗钱且其身份为国家安全人员时，用户往往会被要求遵从其指令，将钱转账至所谓安全账户。

此时获取模块502所接收到的支付请求应当包含收款方、支付方、关于当前支付的详细信息等等。关于收款方(即被动方)的信息可包括姓名和账户(系统由此可获得相应的身份证号码、联系电话、转账历史、名下其他账户以及社交关系等)等。关于支付方(即用户或主动方)的信息同样可包括姓名和账户(系统同样可获得相应的身份证号码、联系电话、转账历史、名下其他账户以及社交关系等)等。关于当前支付的详细信息可包括，例如，支付金额、诸如支付用途的备注等。

在以上所述的示例中，举例而言，支付用途的备注可能含有“安全账户”等敏感字样，支付金额相对较大，或者收款方的账户可能是新账户。

由此，在获取模块502接收到用户的支付请求后，需要解析该支付请求，并提取其中关于用户、收款方和当前支付的详细信息。

风险确定模块504根据关于用户、收款方和当前支付的信息确定当前支付是否存在风险。

在转账到账户的场景中，还以侵害者通过伪造身份方式要求用户转账至安全账户为例，当支付用途的备注含有“安全账户”等敏感字样，支付金额相对较大，或者收款方的账户可能是新账户时，风险识别子系统可确定当前支付存在风险。

同样在转账到账户的场景中，以侵害者以投资获取高额利润为饵要求用户转账至其账户为例，当支付用途的备注含有“投资”等敏感字样，支付金额相对较大，收款方的账户可能是新账户或者并非是涉及投资的账户时，风险确定模块504可确定当前支付存在风险。

在确定当前支付存在风险时交互模块506触发风险阻断交互。

在确定当前支付存在风险时，风险阻断交互被触发。此时，风险阻断交互引擎可针对支付用途的备注含有“安全账户”敏感字样的情形，向用户提问：“您与收款方是什么关系？”、“收款方的安全账户是什么机构的安全账户？”等等。

在支付用途的备注含有“投资”敏感字样的情形中，风险阻断交互引擎可向用户提问：“您与收款方是什么关系？”、“收款方的投资账户是什么机构的投资账户？”等等。

本领域技术人员可以理解，针对存在不同风险的支付请求，交互模块506可相应地向用户进行提问。

风险确定模块504结合风险阻断交互中用户的回应确定当前支付存在风险的风险程度。

依据用户对风险阻断交互引擎的提问做出的回应，风险确定模块504可进一步确定当前支付所存在风险的风险程度。

在支付用途的备注含有“安全账户”敏感字样的情形中，当用户回应“收款方为陌生人但其为安全机构的执法人员”时，风险确定模块504可查询收款方账户的所有者的背景信息，即该账户是否的确是该执法人员所称的机构所有。如果不是，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是安全机构，则确定当前支付存在风险的风险程度为高。如果风险阻断交互引擎确定该收款方账户所属机构存疑，则确定当前支付存在风险的风险程度为中等。如果确定该收款方账户的确为该执法人员所称的机构所有，则确定当前支付存在风险的风险程度为低。

在支付用途的备注含有“投资”敏感字样的情形中，当用户回应“收款方为陌生人但其为投资机构的合法人员”时，风险确定模块504可查询收款方账户的所有者的背景信息，即该账户是否的确是该人员所称的金融机构所有。如果不是，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是金融机构，则确定当前支付存在风险的风险程度为高。如果风险阻断交互引擎确定该收款方账户所属机构是金融机构、但该金融机构的投资行为的风险等级相对较高，或者该金融机构近期的资金周转存疑，则确定当前支付存在风险的风险程度为中等。如果确定该收款方账户的确为该人员所称的金融机构所有，且该金融机构正常运营、其投资行为风险等级正常，则确定当前支付存在风险的风险程度为低。

在风险确定模块504确定当前支付存在风险的风险程度后，该风险程度可被传送至支付处置模块508。

支付处置模块508按照风险程度处置当前支付。

根据所确定的当前支付的风险程度，支付处置模块508可相应地处置当前支付。

在支付用途的备注含有“安全账户”敏感字样的情形中，当确定当前支付存在风险的风险程度为高时，支付处置模块508可停止当前交易，并向用户明示，该账户不是该执法人员所称的机构所有，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是安全机构。

当确定当前支付存在风险的风险程度为中等时，支付处置模块508可警告用户，该账户所属机构是否是安全机构存疑，请进一步向该执法人员索要详细信息；该交易是否继续可请用户判定。当确定当前支付存在风险的风险程度为低时，支付处置模块508可准予当前支付。

类似地，在支付用途的备注含有“投资”敏感字样的情形中，当确定当前支付存在风险的风险程度为高时，支付处置模块508可停止当前交易，并向用户明示，该账户不是该人员所称的金融机构所有，并且收款方账户的所有者为自由职业者，或者所在企业或单位根本不是金融机构。

当确定当前支付存在风险的风险程度为中等时，支付处置模块508可警告用户，该账户所属金融机构的投资行为或资金链存疑，请进一步向该人员索要详细信息；该交易是否继续可请用户判定。当确定当前支付存在风险的风险程度为低时，支付处置模块508可准予当前支付。

本领域技术人员可以理解，针对不同情况的用户，交互式阻断系统500对不同风险的支付请求可作不同地处置。同样，针对不同的支付请求，交互式阻断系统500对相似风险程度的支付请求可作不同地处置。

在本公开的受侵害行为的交互式阻断系统中，在接收到用户的支付请求之后，系统将在初步判断当前支付存在风险时，触发交互模块向用户提问，由此结合用户的应答进一步判断当前支付的风险程度，并依据风险程度来进行相应的处置，例如向用户发出警告，由于结合了用户所掌握的信息，因此该警告所具有的针对性和说服力都得以增强，从而使得用户的被侵害行为得以成功阻断。

以上描述的受侵害行为的交互式阻断方法和系统的各个步骤和模块可以用硬件、软件、或其组合来实现。如果在硬件中实现，结合本发明描述的各种说明性步骤、模块、以及电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、或其他可编程逻辑组件、硬件组件、或其任何组合来实现或执行。通用处理器可以是处理器、微处理器、控制器、微控制器、或状态机等。如果在软件中实现，则结合本发明描述的各种说明性步骤、模块可以作为一条或多条指令或代码存储在计算机可读介质上或进行传送。实现本发明的各种操作的软件模块可驻留在存储介质中，如RAM、闪存、ROM、EPROM、EEPROM、寄存器、硬盘、可移动盘、CD-ROM、云存储等。存储介质可耦合到处理器以使得该处理器能从/向该存储介质读写信息，并执行相应的程序模块以实现本发明的各个步骤。而且，基于软件的实施例可以通过适当的通信手段被上载、下载或远程地访问。这种适当的通信手段包括例如互联网、万维网、内联网、软件应用、电缆(包括光纤电缆)、磁通信、电磁通信(包括RF、微波和红外通信)、电子通信或者其他这样的通信手段。

还应注意，这些实施例可能是作为被描绘为流程图、流图、结构图、或框图的过程来描述的。尽管流程图可能会把诸操作描述为顺序过程，但是这些操作中有许多操作能够并行或并发地执行。另外，这些操作的次序可被重新安排。

所公开的方法、装置和系统不应以任何方式被限制。相反，本发明涵盖各种所公开的实施例(单独和彼此的各种组合和子组合)的所有新颖和非显而易见的特征和方面。所公开的方法、装置和系统不限于任何具体方面或特征或它们的组合，所公开的任何实施例也不要求存在任一个或多个具体优点或者解决特定或所有技术问题。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多更改，这些均落在本发明的保护范围之内。

Claims (24)

1.一种受侵害行为的交互式阻断方法，包括：

接收并解析用户的支付请求以获取关于所述用户、收款方和当前支付的信息；

根据关于所述用户、收款方和当前支付的信息确定所述当前支付是否存在风险；

在确定所述当前支付存在风险时触发风险阻断交互；

结合所述风险阻断交互中所述用户的回应确定所述当前支付存在风险的风险程度；

按照所述风险程度处置所述当前支付。

2.如权利要求1所述的方法，其特征在于，还包括：

在确定所述当前支付不存在风险时，完成所述当前支付。

3.如权利要求1所述的方法，其特征在于，按照所述风险程度处置所述当前支付包括：在确定所述当前支付存在风险的风险程度为低时，完成所述当前支付。

4.如权利要求1所述的方法，其特征在于，按照所述风险程度处置所述当前支付包括：在确定所述当前支付存在风险的风险程度为高时停止所述当前支付。

5.如权利要求1所述的方法，其特征在于，按照所述风险程度处置所述当前支付包括：在确定所述当前支付存在风险的风险程度为中等时向用户提示支付风险并允许所述用户决定是否完成所述当前支付。

6.如权利要求1所述的方法，其特征在于，风险阻断交互由风险阻断交互引擎进行。

7.如权利要求6所述的方法，其特征在于，所述风险阻断交互引擎包括规则集或者规则引擎。

8.如权利要求6所述的方法，其特征在于，所述风险阻断交互引擎包括图谱集。

9.如权利要求6所述的方法，其特征在于，所述风险阻断交互引擎包括基于规则集或者规则引擎的学习模型。

10.如权利要求6所述的方法，其特征在于，所述风险阻断交互引擎包括基于图谱集的学习模型。

11.如权利要求6所述的方法，其特征在于，所述风险阻断交互引擎包括以下一者或多者的组合：规则集、规则引擎、图谱集、基于规则集或者规则引擎的学习模型、以及基于图谱集的学习模型。

12.如权利要求6所述的方法，其特征在于，所述风险阻断交互引擎能够进行异常交易结构发现。

13.一种受侵害行为的交互式阻断系统，包括：

获取模块，接收并解析用户的支付请求以获取关于所述用户、收款方和当前支付的信息；

风险确定模块，根据关于所述用户、收款方和当前支付的信息确定所述当前支付是否存在风险；

交互模块，在确定所述当前支付存在风险时触发风险阻断交互；

其中所述风险确定模块结合所述风险阻断交互中所述用户的回应确定所述当前支付存在风险的风险程度；

支付处置模块，按照所述风险程度处置所述当前支付。

14.如权利要求12所述的系统，其特征在于，在确定所述当前支付不存在风险时，所述支付处置模块完成所述当前支付。

15.如权利要求13所述的系统，其特征在于，支付处置模块按照所述风险程度处置所述当前支付包括：在确定所述当前支付存在风险的风险程度为低时，所述支付处置模块完成所述当前支付。

16.如权利要求13所述的系统，其特征在于，支付处置模块按照所述风险程度处置所述当前支付包括：在确定所述当前支付存在风险的风险程度为高时所述支付处置模块停止所述当前支付。

17.如权利要求13所述的系统，其特征在于，支付处置模块按照所述风险程度处置所述当前支付包括：在确定所述当前支付存在风险的风险程度为中等时所述支付处置模块向用户提示支付风险并允许所述用户决定是否完成所述当前支付。

18.如权利要求13所述的系统，其特征在于，所述交互模块包括规则集或者规则引擎。

19.如权利要求13所述的系统，其特征在于，所述交互模块包括图谱集。

20.如权利要求13所述的系统，其特征在于，所述交互模块包括基于规则集或者规则引擎的学习模型。

21.如权利要求13所述的系统，其特征在于，所述交互模块包括基于图谱集的学习模型。

22.如权利要求13所述的系统，其特征在于，所述交互模块包括以下一者或多者的组合：规则集、规则引擎、图谱集、基于规则集或者规则引擎的学习模型、以及基于图谱集的学习模型。

23.如权利要求13所述的系统，其特征在于，所述交互模块能够进行异常交易结构发现。

24.一种存储有指令的计算机可读存储介质，当所述指令被执行时使得机器执行如权利要求1-12中任一项所述的方法。

Images