一种对业务属性进行风险识别的方法及装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种对业务属性进行风险识别的方法及装置。
背景技术
随着互联网技术的日益成熟,可以通过互联网开展的业务也越来越多。比如,用户可以通过向服务器发送业务请求的方式,完成缴费、购物、观影、娱乐等业务;又比如,存在协同工作关系的不同服务器之间,可以通过传递业务指令的方式,进行某种业务——例如,商户服务器可以向支付服务器发送包含用户银行电子账户和支付金额等订单信息的付款业务指令,以使得支付服务器根据订单信息完成对用户银行电子账户的扣款操作;等等。需要说明的是,用户向服务器发送的业务请求、服务器之间传递的业务指令,以及其他任何与业务相关的消息,均可以统称为“业务消息”。
目前,出于保证网络安全以及保证互联网的合法使用者的利益不受到损害等方面的考虑,需要对互联网中的业务消息进行风险识别。其中,风险识别,是指在风险事故发生之前,认识可能面临的各种风险;对业务消息进行风险识别,是指运用风险识别方法,识别业务消息中包含的业务属性是否存在风险。其中,业务属性,可以是指与业务相关的用户属性,如在进行购物业务时,商户服务器以及支付服务器之间传递的业务消息包含的业务属性为:用户账号、注册账号时使用的媒体访问控制(Media Access Control,MAC)地址、账号的收货地址以及账号关联的银行卡信息,等。
一般地,若业务属性存在风险,则对包含该业务属性的业务消息的处理可能会导致产生风险事故等不好的结果。对业务消息进行风险识别的意义在于,针对识别出的可能存在风险的业务消息,可以通过对其进行拦截、丢弃或更改等操作,避免产生不好的结果。
举例而言,一种典型的、需要对业务属性进行风险识别的场景如下:
购物网站的卖方用户为了提升自己的卖家信用等级,可能会注册多个买家账号,并利用多个买家账号在卖方自己的店铺内购买商品。在购物完成后,卖家不会真正发货,而只会在假装发货后,利用多个买家账号确认收货并针对货物发表较高评价,从而提升卖家信用等级。这样的业务过程中传输的诸如付款业务指令等业务消息显然会导致“产生虚假评价”的风险,因此需要进行风险识别。
发明内容
本申请实施例提供一种对业务属性进行风险识别的方法,用以识别业务属性是否存在风险。
本申请实施例还提供一种对业务属性进行风险识别的装置,用以识别业务属性是否存在风险。
本申请实施例采用下述技术方案:
一种对业务属性进行风险识别的方法,包括:
获取风险业务属性簇;所述风险业务属性簇由存在关联关系的业务属性构成,且单个风险业务属性簇至少包含一个被识别出存在风险的业务属性;获取待识别的业务属性;通过分布式并行计算方法,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性;在判断结果为是时,确定待识别的业务属性存在风险。
一种对业务属性进行风险识别的装置,包括:
风险业务属性簇获取单元,用于获取生成的风险业务属性簇;所述风险业务属性簇由存在关联关系的业务属性构成,且单个风险业务属性簇至少包含一个被识别出存在风险的业务属性;待识别业务属性获取单元,用于获取待识别的业务属性;风险识别单元,用于通过分布式并行计算方法,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性;在判断结果为是时,确定待识别的业务属性存在风险。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
通过判断获取的各种风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性,并在判断结果为是时,确定待识别的业务属性存在风险,从而达到识别业务属性是否存在风险的目的。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的一种对业务属性进行风险识别的方法的具体实现流程示意图;
图2为本申请实施例提供一种风险业务属性簇的示意图;
图3为本申请实施例提供的一种风险业务属性簇的示意图;
图4为本申请实施例提供的一种风险业务属性簇的示意图;
图5为本申请实施例提供的一种对支付业务进行风险识别的方法的具体实现流程示意图;
图6为本申请实施例提供的一种连通子图的示意图;
图7为本申请实施例提供的连通子图的示意图;
图8为本申请实施例提供的一种对业务属性进行风险识别的装置的具体结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
实施例1
本申请实施例提供一种对业务属性进行风险识别的方法,用以识别业务属性是否存在风险。该方法的具体实现流程示意图如图1所示,主要包括下述步骤:
步骤11,获取风险业务属性簇;
其中,所述的风险业务属性簇是由存在关联关系的业务属性构成的业务属性簇(也称业务属性集合)。由于获取的单个这样的业务属性簇中,至少包含一个被识别出存在风险的业务属性,因此这样的业务属性簇也称为“风险业务属性簇”。
本申请实施例中,采用“将具备关联关系的业务属性聚为一类”的聚类规则,可以实现对业务属性进行聚类,从而得到至少一个业务属性簇。其中,业务属性具备关联关系,可以是指不同业务属性之间满足下述至少一个条件:
所述不同业务属性,是从同一业务消息中获取到的;
所述不同业务属性,是同一业务事件中传递的业务消息(同一业务事件中可能会传递不止一个业务消息)包含的业务属性——这里所说的业务事件,可以是基于互联网完成的任何业务事件,比如是某次购物业务、转账业务等等;
所述不同业务属性之间的相似度大于预设的相似度阈值——比如,作为业务属性的网际协议地址(Internet Protocol Address,IP地址),其中,IP地址1为:192.168.1.112,IP地址2为:192.168.1.115,均属于同一网段(192.168.1.110~192.168.1.120),则称IP地址1与IP地址2之间的相似度大于预设的相似度阈值;
等等。
本申请实施例中,用于进行聚类的业务属性,可以是从作为样本的历史业务消息中获取的。
在完成对于业务属性的聚类后,针对各业务属性簇,可以分别判断其中是否包含至少一个被识别出存在风险的业务属性。针对任一业务属性簇而言,若判断出其包含至少一个被识别出存在风险的业务属性(比如为业务属性a),则由于业务属性a与该业务属性簇具有关联关系,从而可以认为该业务属性簇中的其他业务属性也很可能存在风险,从而将该业务属性簇称为风险业务属性簇。
下文以单个待进行风险识别的样本业务属性簇(后文称该样本业务属性簇)为例,说明如何利用整体同步并行计算模型(Bulk Synchronous Parallel,BSP模型)以及获取到的存在风险的样本业务属性,确定该样本业务属性簇是否为风险业务属性簇:
首先,按照将业务属性分配给连通子图的节点,将业务属性之间的关联关系作为节点之间的边的方式,根据所述待识别的业务属性和所述风险业务属性簇构建连通子图。
然后,根据BSP模型,在所述连通子图的各节点之间,传递各节点分别被分配的业务属性,以使得各节点通过比较自身被分配的业务属性和接收的业务属性是否一致,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。若有至少一个被分配了该样本业务属性簇的样本业务属性的节点得到的判断结果为是,则确定该样本业务属性簇为风险业务属性簇。
例如,假设如图2所示,若节点a1判断出自身分配的业务属性与某个被识别出存在风险的样本业务属性相同,则判定节点a1所在的、如图2所示的样本业务属性簇为风险业务属性簇。
在一种实施方式中,可以将生成的风险业务属性簇保存在风险业务属性库中,以便可以从风险业务属性库中获取生成的风险业务属性簇。
步骤12,获取待识别的业务属性;
其中,所述待识别的业务属性,比如可以为待进行风险识别的业务消息所包含的业务属性。本申请实施例中,可以对互联网中传递的待进行风险识别的业务消息进行抓取或拦截,从而获得待进行风险识别的业务消息。或者,可以是直接接收其他设备发送来的业务消息。
例如,若待进行风险识别的业务消息为用户在进行网上购物时产生的支付业务消息,则该支付业务消息中包含的用户注册的账号信息的业务属性、注册账号时使用的MAC地址的业务属性、用户账号关联的邮箱的业务属性、用户账号关联的银行卡号的业务属性等业务属性,均为待识别的业务属性。还比如,若待进行风险识别的业务消息为用户在网上观看影片时产生的业务消息,则该业务消息中包含的用户注册的账号信息的业务属性、用户账号关联的邮箱的业务属性、用户观看影片所在的网页的业务属性等业务属性,均为待识别的业务属性。
步骤13,通过分布式并行计算方法,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。
当判断结果为是时,执行步骤14;否则,可以确定待识别的业务属性不存在风险,并结束流程。
步骤14,当判断结果为是时,则确定待识别的业务属性存在风险。
需要说明的是,所述分布式并行计算方法是一种利用互联网,使用多台计算设备、服务器或则存储设备,同步进行计算的方法。采用分布式并行计算方法,可以提高在大数据的环境下的对数据的计算效率。
需要说明的是,通过分布式并行计算方法,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性,包括:按照将业务属性分配给连通子图的节点,将业务属性之间的关联关系作为节点之间的边的方式,根据所述待识别的业务属性和所述风险业务属性簇构建连通子图;通过在所述连通子图中采用分布式并行计算方法,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。
在一种实施方式中,本申请实施例提供的分布式并行计算方法可以是:BSP模型。则可以通过BSP模型,对业务属性进行聚类生成风险业务属性簇。
其中,所述的BSP模型是英国计算机科学家Viliant在上世纪80年代提出的一种并行计算模型。它主要有三个部分:一组处理器(Processors)、各处理器所能支持的运算行为(Local Computation)和处理器之间的通讯(Communication)。其中,Processors指的是并行计算进程,它对应到集群中的多个节点,每个节点可以有多个Processor;LocalComputation就是单个Processor的计算,每个Processor都会切分一些节点作计算;Communication指的是Processor之间的通讯。由于BSP模型的实现原理已经是一种比较成熟的技术,此处对该模型的实现原理不再赘述。
则,通过在连通子图中采用所述BSP模型,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性,包括:根据BSP模型,在所述连通子图的各节点之间,传递各节点分别被分配的业务属性,以使得各节点通过比较自身被分配的业务属性和接收的业务属性是否一致,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。
基于BSP模型,风险业务属性簇具体的生成方式包括:
子步骤1,利用BSP模型,对样本业务属性进行聚类,生成样本业务属性簇;
其中,样本业务属性,是指用于进行聚类的业务属性。其可以是从历史业务消息中获取的。需要说明的是,从同一业务事件的业务消息中获取的不同业务属性,默认是彼此具备关联关系的业务属性。
将各样本业务消息中所包含的各业务属性,分别分配到BSP模型的各个节点上,且BSP模型上的每个节点上除了包括被分配的业务属性(后称主业务属性)外,还被分配有默认与该业务属性具有关联关系的业务属性(后称附属业务属性),并在BSP模型的各个节点之间,传递各个节点被分配的主业务属性,以使得相互具有关联的节点聚类成一个簇。需要说明的是,其中的主业务属性是用于在各个节点之间进行传递的。
其中,假设某节点1被分配主业务属性a以及附属业务属性c,节点3被分配主业务属性c以及附属业务属性a,且节点1向其他所有节点发送该节点1被分配的主业务属性a,其中因为节点3上被分配有附属业务属性a,则节点3在收到节点1发送的主业务属性a后,将可以向BSP模型中用于对BSP模型中的节点关系进行统一管理的主节点发送通知信息,以使得主节点获知节点1与节点3是相互具有关联的节点。基于主节点的该功能,后续通过对主节点的访问,即可获知BSP模型中各节点之间的关联关系。
例如,假设如图2所示,节点A分别与节点a1、节点a2以及节点a3相互具有关联,节点B分别与节点b1、节点b2以及节点b3相互具有关联,而节点ab分别有节点a1以及节点b3相互具有关联,则上述节点通过BSP模型所执行的上述处理,将聚类为一个簇。其中,这里为了便于描述,将被分配有各业务属性的各个节点,称为节点;则通过BSP模型执行上述处理,将节点聚类为一个簇,即为业务属性簇。
为便于描述,后文将通过子步骤1生成的样本业务属性簇,称为待进行风险识别的样本业务属性簇。
子步骤2,获取被识别出存在风险的样本业务属性;
其中,所述的被识别出存在风险的样本业务属性,一般为被识别出存在风险的历史业务消息中所包含的业务属性。
例如,在进行购物支付业务时,根据用户投诉,确定出:商户服务器与支付服务器之间传递的业务消息中:买家注册账号时使用的MAC地址这一业务属性存在风险,则可以认定该支付业务消息存在风险,则该支付业务消息中所包含的各业务属性均可以被确定为识别出的存在风险的样本业务属性。
本申请实施例中,被识别出存在风险的样本业务属性可以保存在风险业务属性库中,以便于后续查找。一般地,该风险业务属性库可以支持被定期或不定期地更新。
子步骤3,利用BSP模型、获取到的被识别出存在风险的样本业务属性(后称存在风险的样本业务属性),从待进行风险识别的样本业务属性簇中,确定风险业务属性簇。
下文以单个风险业务属性簇为例,说明如何通过特定的判断方法,判断该风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性:
首先,按照向各个节点分别分配单个业务属性的方式(采用该方式,各节点仅获得单个业务属性,因此不存在主业务属性和附属业务属性的区别),将获取的该风险业务属性簇分别包含的各业务属性,以及获取的各待识别的业务属性,按照将业务属性分配给连通子图的节点,将业务属性之间的关联关系作为节点之间的边的方式,根据所述待识别的业务属性和所述风险业务属性簇构建连通子图;
然后,根据BSP模型,在所述连通子图的各节点之间,传递各节点分别被分配的业务属性,以使得各节点通过比较自身被分配的业务属性和接收的业务属性是否一致,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。针对得到的判断结果为是的、被分配了待识别的业务属性的节点,可以确定该节点被分配的待识别的业务属性存在风险。
仍然以单个风险业务属性簇为例,通过特定的判断方法,判断该风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性的另一种方式如下:
首先,按照向各个节点分别分配主业务属性和附属业务属性的方式,将获包含的各业务属性均可以被确定为识别出的存在风险的样本业务属性。
本申请实施例中,被识别出存在风险的样本业务属性可以保存在风险业务属性库中,以便于后续查找。一般地,该风险业务属性库可以支持被定期或不定期地更新。
子步骤3,利用BSP模型、获取到的被识别出存在风险的样本业务属性(后称存在风险的样本业务属性),从待进行风险识别的样本业务属性簇中,确定风险业务属性簇。
下文以单个风险业务属性簇为例,说明如何通过特定的判断方法,判断该风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性:
首先,按照向各个节点分别分配单个业务属性的方式(采用该方式,各节点仅获得单个业务属性,因此不存在主业务属性和附属业务属性的区别),将获取的该风险业务属性簇分别包含的各业务属性,以及获取的各待识别的业务属性,按照将业务属性分配给连通子图的节点,将业务属性之间的关联关系作为节点之间的边的方式,根据所述待识别的业务属性和所述风险业务属性簇构建连通子图;
然后,根据BSP模型,在所述连通子图的各节点之间,传递各节点分别被分配的业务属性,以使得各节点通过比较自身被分配的业务属性和接收的业务属性是否一致,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。针对得到的判断结果为是的、被分配了待识别的业务属性的节点,可以确定该节点被分配的待识别的业务属性存在风险。
仍然以单个风险业务属性簇为例,通过特定的判断方法,判断该风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性的另一种方式如下:
首先,按照向各个节点分别分配主业务属性和附属业务属性的方式,将获取的该风险业务属性簇分别包含的各业务属性,以及获取的各待识别的业务属性,按照将业务属性分配给连通子图的节点,将业务属性之间的关联关系作为节点之间的边的方式,根据所述待识别的业务属性和所述风险业务属性簇构建连通子图;
然后,根据BSP模型,按照单个节点向其他所有节点传递被分配的业务属性的信息传递方式,在待识别的业务属性被分配的节点以及获取的风险业务属性簇中的业务属性被分配的节点之间,相互发送各节点被分别分配的主业务属性。各节点将接收到的主业务属性分别与自身被分配的主业务属性以及附属业务属性进行比较。假设:节点y所在的簇为获取的风险业务属性簇、待识别的业务属性被分配到节点x、被分配到节点x的待识别的业务属性与节点y被分配的业务属性存在关联关系,则判断风险业务属性簇包含的业务属性中,存在与待识别的业务属性相同的业务属性,则可以确定待识别的业务属性存在风险。
需要说明的是,当确定待识别的业务属性存在风险时,为了避免产生风险事故,在一种实施方式中,在确定出待识别的业务属性存在风险时,可以执行一些预定的操作。以执行图1所示的方法以及所述预定的操作的执行主体为服务器为例,所述服务器可以执行的所述预定的操作,包括下述操作中的至少一个:
1、拦截包含所述业务属性的业务消息;
例如,假设在用户在进行网上交易时,产生的支付业务消息中包含的收货地址被识别为风险业务属性,则当商户服务器再次向支付服务器发送包含该收货地址的支付业务消息请求支付时,支付服务器可以对该支付业务消息进行拦截,从而达到拒绝此次交易的目的。
2、修改所述业务消息;
例如,假设用户在网上观看视频时,产生的业务消息中包含的视频网站网址业务属性被识别为风险业务属性,则当用户向服务器发送该业务消息请求访问该视频网站时,服务器将对该业务消息中包含的视频网站网址进行修改,以使得用户可以安全正常的访问该视频网站。
3、丢弃所述业务消息;
4、发送风险告警消息。
还需要说明的是,为了保证利用风险业务属性簇,能够更为全面地对待识别的业务属性是否存在风险进行识别,在一种实施方式中,本申请实施例提供的方法还包括:当判断出获取的各风险业务属性簇包含的业务属性中,存在与待识别的业务属性相同的业务属性时,根据待识别的业务属性,对所述待更新连通子图进行更新。通过利用存在风险的待识别的业务属性,对风险业务属性簇进行更新,可以使得风险业务属性簇中包含的存在风险的业务属性更为丰富,从而后续可以利用更新后的风险业务属性簇,识别更多的存在风险的业务属性。
例如,假设如图3所示,获取到的风险业务属性簇包括:节点D、节点d1、节点d2以及节点d3,节点E被分配到的业务属性为待识别的业务属性,且该待识别的业务属性与节点d3被分配的业务属性相同,即确定该待识别的业务属性存在风险,则将该待识别的业务属性所在的节点E并入风险业务属性簇,生成更新后的风险业务属性簇。更新后的风险业务属性簇如图4所示。
在一种实施方式中,本申请实施例提供还提供一种风险业务属性簇的命名规则,以便对通过步骤11获取到的风险业务属性簇以及更新后的风险业务属性簇进行命名,以使得风险业务属性簇以及更新后的风险业务属性簇,均具备全局唯一的名称。
其中,对通过步骤11获取到的风险业务属性簇进行命名的具体规则为:将聚类生成风险业务属性簇的所有节点中,被分配的业务属性信息最多的节点的节点的名称,作为该风险业务属性簇的名称。需要说明的是,其中节点的名称由“当前系统时间+节点ID”表示。
而对更新后的风险业务属性簇进行命名的具体规则为:将进行合并前,包含节点数最多的簇的名称作为更新后的风险业务属性簇的名称。例如,假设原风险业务属性簇包含10个节点,与该风险业务属性簇进行合并的业务属性簇包含5个节点,则将原风险业务属性簇的名称作为更新后的风险业务属性簇的名称。
目前,现有技术中在对待识别的业务属性进行分类时,往往利用传统的聚类算法(如k-means聚类算法),并通过多次的迭代,计算出待识别的业务属性与通过对样本业务属性进行聚类得到的聚类中心的相似度,以达到对待识别的业务属性进行分类的目的。由于目前互联网环境正趋于大数据化,通过上述现有方法,无法在短时间内完成多次迭代计算,从而导致对于待识别的业务属性的分类效率较低。而通过本申请实施例1提供的方法,通过采用BSP模型,判断获取的各种风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性,并在判断结果为是时,确定待识别的业务属性存在风险,从而可以快速、方便地对待识别的业务属性的分类。
需要说明的是,实施例1所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤11和步骤12的执行主体可以为设备1,步骤13的执行主体可以为设备2;又比如,步骤11的执行主体可以为设备1,步骤12和步骤13的执行主体可以为设备2;等等。
实施例2
本申请实施例提供一种对支付业务进行风险识别的方法,用以识别支付业务是否存在风险。该方法的具体实现流程示意图如图5所示,主要包括下述步骤:
步骤21,获取生成的风险支付业务属性簇。
利用BSP模型,对风险支付业务属性样本进行聚类,生成风险支付业务属性簇。
其中,所述的风险支付业务属性样本,为从数据库中获取到的曾经出现过风险支付操作的业务消息中所包含的业务属性。
需要说明的是,利用BSP模型,本申请实施例可以将支付业务消息中包含的业务属性转换成类似于图6所示的连通子图进行计算。其中,将业务属性(如:USERID(包括图6中的USERID-1~USERID-4)、Email(包括图6中的Email-1~Email-3)、CreditCard(包括图6中的CC-1~CC-3)、收货地址(包括图6中的收货地址-1~收货地址-2)、UMID(包括图6中的UMID-1~UMID-3)、DFPrint(包括图6中的DFPrint-1~DFPrint-2),等)抽象成连通子图中的节点,将存在关联关系(如:登录、注册、付款,等)的业务属性所抽象成的节点用直线连接。
例如,假设在注册业务中,与业务属性USERID-1存在关联关系的业务属性为MAC2;在交易业务中,与业务属性USERID-1存在关联关系的业务属性为收货地址-3;则可以按照上述方式,将业务属性USERID-1、MAC2和收货地址-3抽象成连通子图中的节点,并根据这三个业务属性之间的关联,生成如图7所示的连通子图。其中,业务属性USERID-1、业务属性MAC2以及业务属性收货地址-3之间存在的关联关系如下表所示。
主体1 |
主体2 |
关联类型 |
关联次数 |
USERID-1 |
mac2 |
注册 |
1 |
USERID-1 |
收货地址-3 |
支付 |
1 |
步骤22,拦截待识别风险的业务消息,并从业务消息中获取待识别的支付业务属性。
例如,获取到的支付业务属性可以包括下述业务属性的至少一种:
收货地址、注册账户时的MAC地址、账户关联邮箱、账户关联手机号以及账户关联银行卡,等等。
步骤23,判断获取的风险业务属性簇包含的业务属性中是否存在与待识别的业务属性相同的业务属性。当判断结果为是时,执行步骤24;当判断结果为否时,执行步骤25。
步骤23中判断过程的具体实现方式,可以参照实施例1中步骤13的具体实现方式,此处不再赘述。
步骤24,对判断出的存在风险的业务属性执行特定操作。
其中所述特定操作,可以是对包含上述业务属性的业务消息进行拦截,也可以是对所述业务消息进行修改,或者对所述业务消息进行丢弃,等等。
步骤25,对拦截的待识别风险的业务消息进行放行。
通过本申请实施例2提的方法,将待识别的业务消息中的业务属性与获取到的风险业务属性簇进行比较,判断获取的各种风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性,并将判断结果为是的业务属性确定为风险业务属性,从而达到了对支付业务进行风险识别的目的。
实施例3
本申请实施例提供一种对业务属性进行风险识别的装置,用以识别业务属性是否存在风险。该装置的具体结构示意图如图8所示,包括风险业务属性簇获取单元31、待识别业务属性获取单元32以及风险识别单元33。
其中,风险业务属性簇获取单元31,用于获取风险业务属性簇;所述风险业务属性簇由存在关联关系的业务属性构成,且单个风险业务属性簇至少包含一个被识别出存在风险的业务属性;
待识别业务属性获取单元32,用于获取待识别的业务属性;
风险识别单元33,用于通过通过分布式并行计算方法,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性;在判断结果为是时,确定待识别的业务属性存在风险。。
在一种实施方式中,风险识别单元,用于:按照将业务属性分配给连通子图的节点,将业务属性之间的关联关系作为节点之间的边的方式,根据所述待识别的业务属性和所述风险业务属性簇构建连通子图;通过在所述连通子图中采用分布式并行计算方法,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。
在一种实施方式中,风险识别单元,用于:根据BSP模型,在所述连通子图的各节点之间,传递各节点分别被分配的业务属性,以使得各节点通过比较自身被分配的业务属性和接收的业务属性是否一致,判断获取的各风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性。
在一种实施方式中所述风险业务属性簇构成待更新连通子图;则
所述装置还包括:风险业务属性簇更新单元,用于:在风险识别单元判断出获取的各风险业务属性簇包含的业务属性中,存在与待识别的业务属性相同的业务属性时,根据待识别的业务属性,对所述待更新连通子图进行更新。
在一种实施方式中,所述装置还包括:风险处理单元,用于在风险识别单元确定出待识别的业务属性存在风险后,执行下述操作中的至少一个操作:拦截包含所述业务属性的其他业务消息;修改所述业务消息;丢弃所述业务消息;发送风险告警消息。
在一种实施方式中,待识别业务属性获取单元,具体用于:获得业务消息;从获得的业务消息中获取待识别的业务属性。。
采用本申请实施例3提供的上述装置,通过风险识别单元将风险业务属性簇获取单元获取到的风险业务属性簇包含的业务属性与待识别业务属性获取单元获取的待识别的业务属性进行比较,判断获取的风险业务属性簇包含的业务属性中,是否存在与待识别的业务属性相同的业务属性,并将判断结果为是的业务属性确定为风险业务属性,从而达到了对业务属性进行风险识别的目的
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。