一种信息风险防控方法及装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种信息风险防控方法及装置。
背景技术
随着网络技术的不断发展,网络服务商(如:网站)在接收用户提供的用户信息后,可以为用户提供各类丰富的网络服务,与此同时,网络服务商会对用户提供的信息进行风险评估与防控。
目前,网络服务商接收到的用户信息会存在一定的风险(如:用户的账户信息可能被盗),网络服务商为了保证用户信息的安全,会对用户在业务系统上的操作行为进行风险识别,并采取相应的防控措施。
现有技术中,业务系统可将用户的操作行为以事件的方式记录下来,如:用户的登录事件、注册事件等,并将记录的事件发送给风险控制(简称风控)处理系统,风控处理系统对表征用户操作行为的事件进行分析与处理,如果事件存在异常,则说明用户的操作行为存在一定的风险,或者说,用户的用户信息(如:账号信息)存在一定的风险,后续可采取相应的风控措施。
例如,在某电商网站中,用户在该电商网站上进行账号登录操作,假设其常用登录地是北京,而在当前时刻下,其登录地是上海,则该电商网站的业务系统将当前的登录行为以事件的方式记录下来,该事件中包含当前的登录地(即,上海),并将该事件发送给风控处理系统,风控处理系统分析出该用户当前的登录地不同于其常用登录地,则可确定该用户的账号信息存在一定的风险,有可能被盗,对此,网络服务商会采取相应的风控措施。
但是,在现有技术中,对于用户量巨大的网络服务商来说,如果海量的用户操作行为数据均由业务系统来采集,就势必会造成业务系统的压力过大,因此,为了减轻业务系统的压力,业务系统采集的事件的种类也就较少(一般仅采集登录、注册、交易等事件),这会导致后续基于这些事件而进行风控的准确性降低。
发明内容
本申请实施例提供一种信息风险防控方法及装置,用以解决基于采集的事件进行风控的准确性较低的问题。
本申请实施例提供的一种信息风险防控方法,包括:
第一系统接收客户端采集并发送的用户行为数据以及第二系统发送的事件;
根据指定的风控主体信息,从接收到的事件中提取包含所述风控主体信息的事件,从接收到的用户行为数据中提取包含所述风控主体信息的用户行为数据;
根据预设的事件与行为信息的对应关系,以及用户行为数据与行为信息的对应关系,将提取的事件和用户行为数据转换为相应的行为信息;
根据转换得到的行为信息,对所述风控主体信息进行风控处理。
本申请实施例提供的一种信息风险防控方法,第二系统保存的网页代码中预先被插入了调用代码,所述调用代码用于调用第一系统中的调用脚本,所述方法包括:
所述客户端在加载插入有所述调用代码的网页代码时,通过所述调用代码向所述第一系统发送第一调用请求;
所述客户端接收所述第一系统根据所述第一调用请求返回的调用脚本;
通过所述调用脚本向第一系统发送第二调用请求;
接收第一系统根据所述第二调用请求返回的各采集脚本;
通过所述各采集脚本采集用户行为数据,并发送给第一系统,使所述第一系统根据所述用户行为数据和从第二系统接收到的事件进行风控处理。
本申请实施例提供的一种信息风险防控装置,包括:
接收模块,用于接收客户端采集并发送的用户行为数据以及第二系统发送的事件;
提取模块,用于根据指定的风控主体信息,从接收到的事件中提取包含所述风控主体信息的事件,从接收到的用户行为数据中提取包含所述风控主体信息的用户行为数据;
转换模块,用于根据预设的事件与行为信息的对应关系,以及用户行为数据与行为信息的对应关系,将提取的事件和用户行为数据转换为相应的行为信息;
处理模块,用于根据转换得到的行为信息,对所述风控主体信息进行风控处理。
本申请实施例提供的一种信息风险防控装置,第二系统保存的网页代码中预先被插入了调用代码,所述调用代码用于调用第一系统中的调用脚本,包括:
第一请求发送模块,用于在加载插入有所述调用代码的网页代码时,通过所述调用代码向所述第一系统发送第一调用请求;
调用脚本接收模块,用于接收所述第一系统根据所述第一调用请求返回的调用脚本;
第二请求发送模块,用于通过所述调用脚本向第一系统发送第二调用请求;
采集脚本接收模块,用于接收第一系统根据所述第二调用请求返回的各采集脚本;
数据发送模块,用于通过所述各采集脚本采集用户行为数据,并发送给第一系统,使所述第一系统根据所述用户行为数据和从第二系统接收到的事件进行风控处理。
本申请实施例提供一种信息风险防控方法及装置,该方法由客户端采集用户行为数据,第一系统接收客户端发送的用户行为数据以及第二系统发送的事件,并根据指定的风控主体信息,提取包含该风控主体信息的事件和用户行为数据,将提取的事件和用户行为数据转换为相应的行为信息,根据转换得到的行为信息,对该风控主体信息进行风控处理。通过上述方法,由客户端采集用户行为数据,可在降低第二系统压力的同时,提高采集的用户行为数据的种类,基于多种用户行为数据和第二系统记录的事件,可有效提高风控的准确性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的信息风险防控过程;
图2为本申请实施例提供的第一系统接收客户端采集的用户行为数据的具体过程;
图3为本申请实施例提供的信息风险防控装置的结构示意图;
图4为本申请实施例提供的另一种信息风险防控装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
图1为本申请实施例提供的信息风险防控过程,具体包括以下步骤:
S101:第一系统接收客户端采集并发送的用户行为数据以及第二系统发送的事件。
其中,所述第一系统可以是风险控制系统(即,风控系统)或安全系统,用于对风险控制主体信息(简称风控主体信息)进行分析评估与处理,所述第二系统可以是业务系统,用于以事件的方式记录用户的操作行为,以下实施例以第一系统为风控系统,第二系统为业务系统进行说明。
在本申请实施例中.接收客户端采集并发送的用户行为数据以及业务系统发送的事件,是由风控系统完成的,并由风控系统对接收到的用户行为数据和事件进行后续的处理。
例如,某用户通过客户端打开某电商网站的网页,客户端会采集该用户的用户行为数据,业务系统会采集该用户的事件,并将采集到的用户行为数据和事件发送给风控系统。
S102:根据指定的风控主体信息,从接收到的事件中提取包含所述风控主体信息的事件,从接收到的用户行为数据中提取包含所述风控主体信息的用户行为数据。
在本申请实施例中,所述风控主体信息,指的是风控系统进行风险评估的对象,如,用户的互联网协议地址(internet protocol address,ip),风控系统接收到客户端采集到的用户行为数据和业务系统采集到的事件,从接收到的事件中,将包含风控主体信息(如,用户的ip地址)的事件提取出来,并从接收到的用户行为数据中,将包含风控主体信息的用户行为数据提取出来。
延续上例,假设风控主体信息是用户的ip地址,风控系统接收到客户端采集到的用户行为数据和业务系统采集到的事件后,可从接收到的事件中,将包含该用户的ip地址的事件提取出来,并从接收到的用户行为数据中,将包含该用户的地址ip的用户行为数据也提取出来。
S103:根据预设的事件与行为信息的对应关系,以及用户行为数据与行为信息的对应关系,将提取的事件和用户行为数据转换为相应的行为信息。
在本申请实施例中,所述行为信息,指的是用户操作行为,每一个用户操作行为都会对应一定的事件(或用户行为数据),可在风控系统中预设事件与行为信息的对应关系,预设用户行为数据与行为信息的对应关系,并根据上述的对应关系,将提取出来的包含风控主体信息的事件转换成对应的行为信息,将提取出来的包含风控主体信息的用户行为数据转换成对应的行为信息。
延续上例,假设提取出来的事件中包含的是用户点击了支付按钮的操作行为数据,则将该事件转换成用户的支付操作行为信息,提取出来的用户行为数据中包含的是用户点击了搜索按钮的操作行为数据,则将该用户行为数据转换成搜索操作行为信息。
S104:根据转换得到的行为信息,对所述风控主体信息进行风控处理。
在本申请实施例中,所述风控处理,包括但不限于对风控主体信息进行风险评估,对有风险的风控主体信息进行相应的控制处理,如进行预警。风控系统根据转换得到的行为信息,对风控主体信息进行风控处理。
延续上例,风控系统根据转换得到的行为信息:浏览操作行为、下单操作行为,对用户的ip地址进行风控处理。
考虑到在实际应用场景中,用户一般是通过其客户端访问业务系统中的网页时,客户端才采集用户行为数据的,因此,本申请实施例中可在业务系统保存的网页代码中插入采集脚本,使客户端在访问网页时,根据网页代码中插入的采集脚本来采集用户行为数据。但是,如果风控系统更新或升级,要采集的用户行为数据发生变更,则风控系统就需要修改插入在业务系统中的采集脚本,而每次风控系统更新或升级都修改业务系统中的采集脚本,就会导致更新或升级过于繁琐,难以维护。
为了便于风控系统的更新和升级,降低风控系统和业务系统的维护难度,在本申请实施例中,风控系统可预先将调用代码插入到业务系统的网页代码中,该调用代码用于调用风控系统中的调用脚本,则风控系统在接收客户端采集的用户行为数据时,可采用如图2所示的过程进行接收。
图2为本申请实施例提供的风控系统接收客户端采集的用户行为数据的具体过程,包括以下步骤:
S1011:第一系统接收客户端通过所述调用代码发送的第一调用请求。
其中,所述第一系统可以是风险控制系统(即,风控系统)或安全系统,主要用于对风控主体信息进行分析评估与处理,所述第二系统可以是业务系统,主要用于以事件的方式记录用户的操作行为,以下实施例以第一系统为风控系统,第二系统为业务系统进行说明。
所述调用代码用于调用风控系统中的调用脚本。所述的第一调用请求,是客户端在加载所述业务系统中的网页代码时,通过该网页代码中插入的调用代码发送的。
在本申请实施例中,当客户端在加载包含有调用代码的网页代码时,也会加载网页代码中插入的该调用代码,而由于该调用代码的功能就是向风控系统发送第一调用请求,因此,风控系统会接收到客户端通过调用代码发送的第一调用请求,也就会对发送过来的第一请求做出相应的响应。
例如,假设调用代码为<scrip charset=“utf-8”type=“text/javascript”src=https://www.site.com/behavivor.js?sessionid=20150427171213547&var=.....></script>,则某用户打开插入了该调用代码的网页时,客户端在加载该网页的过程中,就会加载该调用代码,通过该调用代码,客户端会向风控系统发送第一调用请求,该第一调用请求中携带要求调用的调用脚本的名称为behavior.js,也就是说,该第一调用请求的功能就是向风控系统调用名为behavior.js的调用脚本,相应的,风控系统会接收到该第一调用请求。
S1012:根据所述第一调用请求,向所述客户端返回调用脚本。
在本申请实施例中,所述的调用脚本是用于调用风控系统中的采集脚本的,所述的调用脚本可以是Javascript脚本,当然也可以是其他脚本,当风控系统接收到第一调用请求时,就会根据该第一调用请求,将该调用脚本返回给客户端,而客户端则会运行接收到的该调用脚本。
延续上例,风控系统接收到第一调用请求时,根据该第一调用请求中携带的调用脚本的名称behavior.js,将名为behavior.js的调用脚本返回客户端,客户端接收到behavior.js后,则运行behavior.js。
S1013:接收所述客户端通过所述调用脚本发送的第二调用请求。
客户端接收到该调用脚本后,运行该调用脚本,以通过该调用脚本向风控系统发送第二调用请求,其中,第二调用请求携带所要调用的采集脚本的名称。
延续上例,客户端接收到该调用脚本后,可通过该调用脚本向风控系统发送第二调用请求,该第二调用请求中携带的采集脚本的名称为A.js和B.js,用于调用名称分别为A.js和B.js的两个采集脚本。
S1014:根据所述第二调用请求,向所述客户端返回各采集脚本。
在本申请实施例中,所述的各采集脚本用于使运行采集脚本的设备采集用户行为数据,所述的采集脚本可以是Javascript脚本,当然也可以是其他脚本。不同的采集脚本所采集的用户行为数据可以是不同的,也可以是相同的,各采集脚本之间相互独立、互不影响。
风控系统接收到第二调用请求后,则可根据该第二调用请求中携带的采集脚本的名称,将相应的采集脚本返回给客户端。
延续上例,风控系统接收到第二调用请求后,可根据该第二调用请求中携带的采集脚本的名称A.js和B.js,将采集脚本A.js和B.js返回给客户端。
S1015:接收所述客户端通过所述采集脚本采集并发送的用户行为数据。
客户端接收到采集脚本后,可运行该采集脚本,用以通过采集脚本采集用户行为数据。其中,所述的用户行为数据包括但不限于:鼠标点击行为数据、鼠标移动行为数据、键盘行为数据、焦点行为数据。
延续上例,假设采集脚本A.js是用于采集鼠标点击、鼠标移动行为数据的,则客户端接收到A.js后,通过运行A.js,可采集到用户的鼠标点击行为数据、鼠标移动行为数据。采集脚本B.js是用于采集键盘行为、焦点行为数据的,则客户端接收到B.js后,通过运行B.js,可采集到用户的键盘行为数据、焦点行为数据。
上述示例中,只以采集脚本A.js和采集脚本B.js为例,但在实际应用中,并不局限于两个采集脚本,风控系统中保存的调用脚本会调用大量的采集脚本,也就是说,客户端上会运行大量不同类型的采集脚本,用于采集不同用户行为的用户行为数据。
例如,用户通过客户端打开网页时,通过如图1所示的过程会接收到大量的采集脚本,也就会通过各采集脚本采集各种不同的用户行为数据,这些用户行为数据可包括静态数据和动态数据。
其中,静态数据如表1所示:
表1
以上表1只是示例性的一些静态数据,在实际应用中,静态数据可能不止如表1所示。
动态数据可包括:鼠标点击行为数据、鼠标移动行为数据、键盘行为数据、焦点行为数据。其中,鼠标点击行为数据如表2所示:
表2
鼠标移动行为数据如表3:
表3
键盘行为数据如表4:
表4
焦点行为数据如表5:
表5
通过上述方法,由客户端通过采集脚本采集用户行为数据,可在降低业务系统压力的同时,提高采集的用户行为数据的种类,基于多种用户行为数据和业务系统记录的事件,可有效提高风控的准确性。与此同时,风控系统只在业务系统初始化时,将调用代码插入,后续风控系统更新或升级时,无论调用脚本的内容发生改变,还是采集脚本改变,调用脚本的名称不发生改变,那么调用代码就仍然能调用到调用脚本,调用脚本也可调用到采集脚本,这样风控系统就不会频繁的修改业务系统,更新或升级也不会过于繁琐,降低了维护难度。
例如,之前调用脚本功能是调用采集脚本A.js和采集脚本B.js,风控系统升级后,调用脚本的功能是调用采集脚本A.js、B.js、C.js,显然,调用脚本的内容发生了改变,与之前的采集脚本相比多调用了一个采集脚本C.js,但是调用脚本名称仍为behavior.js,因此,调用代码是不需要改变的,风控系统升级时无需修改业务系统。
考虑到风控系统在进行风控处理时,往往会基于最近的某一个或某几个时间的用户行为数据进行风控处理,因此,为了保证风控处理的效率,在图1所示的步骤S102中,风控系统在提取包含该风控主体信息的事件和用户行为数据时,可采用以下两种方式提取用户行为数据和事件:
第一种,根据接收到的事件中携带的时间戳,从接收到的事件中提取出包含该风控主体信息、且在过去指定时间段内的事件,根据接收到的用户行为数据中携带的时间戳,从接收到的用户行为数据中提取出包含该风控主体信息、且在过去指定时间段内的用户行为数据。
第二种,根据接收到的事件和用户行为数据中携带的时间戳,对接收到的各事件和用户行为数据按时间先后顺序进行排序,根据排序后的事件和用户行为数据确定出若干个数据组,其中,每个数据组中的用户行为数据和事件均包含该风控主体信息,且一个数据组中每两个相邻的用户行为数据或事件之间的时间间隔不超过预设时长,从确定出的所述若干个数据组中选择满足指定条件的数据组,并从选择出的数据组中提取用户行为数据和事件。其中,指定条件包括离当前时刻最近的一个数据组、离当前时刻最近的若干个相邻数据组、包含的事件和用户行为数据最多的数据组等,具体可根据实际需要进行设定。
也可结合上述第一种和第二种方法提取用户行为数据和事件。
例如,采用上述第一种方法提取用户行为数据和事件时,假设指定的风控主体信息为会话1,即sessionid为1,过去指定时间段为12:00—12:10,则风控系统可从业务系统接收到的各事件中,提取包含sessionid为1,且包含的时间戳在12:00—12:10内的事件(如,事件1),从接收到的各用户行为数据中,提取包含sessionid为1,且包含的时间戳在12:00—12:10内的用户行为数据(如,行为数据1和行为数据2)。
采用上述第二种方法提取用户行为数据和事件时,假设指定的风控主体信息为会话1,即sessionid为1,预设时长为5分钟,满足的指定条件包括离当前时刻最近的一个数据组,则风控系统根据各用户行为数据和事件中携带的时间戳,按时间先后顺序排序后得到:行为数据3、事件2、行为数据1、行为数据2、事件1。假设行为数据3和事件2中携带的时间戳之间的时间间隔小于5分钟,事件2和行为数据1中携带的时间戳的时间间隔大于5分钟,而行为数据1、行为数据2和事件1中携带的时间戳相邻的两个之间的时间间隔均小于5分钟,则风控系统将行为数据3和事件2划分为第一个数据组,将行为数据1、行为数据2、事件1划分为第二个数据组。由于第二个数据组距离当前时刻的时间最近,因此,风控系统提取出第二个数据组中的用户行为数据和事件。
考虑到在实际应用中,风控系统通过各采集脚本采集到的用户行为数据会有缺失,即各采集脚本无法采集到一些用户行为数据,如,用户的介质访问控制(Media AccessControl,MAC)地址、用户的账号(如,email),客户端中的各采集脚本虽然无法采集到这些缺失的数据,但是业务系统会以事件的方式记录下来这些数据,因此,本申请实施例为了更准确的进行信息防控,可采用提取的事件对提取的用户行为数据进行数据补全,并根据补全后的用户行为数据和事件进行风险防控。
在进行数据补全时,可对比用户行为数据和事件中包含的各数据项,如果事件中存在某个数据项,而用户行为数据中不存在该数据项,则可将事件中的该数据项添加到用户行为数据中,完成对该用户行为数据的补全。
具体的,可以先根据携带的时间戳,按照时间先后顺序对提取的用户行为数据和事件进行排序(若之前已经按照时间先后顺序进行过排序,则此处也可以不再进行排序),根据排序后的用户行为数据和事件,采用前向补全或后向补全的方法对用户行为数据进行补全。
延续上例,采用事件前向补全的方法时,假设提取出的事件和用户行为数据经过排序后如表6所示。
sessionid |
数据源 |
MAC |
账号 |
具体数据 |
1 |
采集脚本 |
|
|
行为数据1 |
1 |
采集脚本 |
|
|
行为数据2 |
1 |
业务系统 |
Aaaaaaa |
xxx@alipay.com |
事件1 |
表6
从表6可以看出,排序后,事件1排在最后,风控系统提取出的客户端通过采集脚本采集到的行为数据1和2中缺失了MAC和账号这两个数据项,而业务系统采集到的事件1中是包含MAC和账号这两个数据项的,因此,可采用事件1,对排在之前的行为数据1和2进行数据补全,也即,前向补全。补全后的用户行为数据如表7所示。
sessionid |
数据源 |
MAC |
账号 |
具体数据 |
1 |
采集脚本 |
Aaaaaaa |
xxx@alipay.com |
行为数据1 |
1 |
采集脚本 |
Aaaaaaa |
xxx@alipay.com |
行为数据2 |
1 |
事件数据 |
Aaaaaaa |
xxx@alipay.com |
事件1 |
表7
类似的,采用后向补全的方法时,假设提取出的事件和用户行为数据经过排序后如表8所示。
sessionid |
数据源 |
MAC |
账号 |
具体数据 |
1 |
业务系统 |
Aaaaaaa |
xxx@alipay.com |
事件1 |
1 |
采集脚本 |
|
|
行为数据1 |
1 |
采集脚本 |
|
|
行为数据2 |
表8
从表8可以看出,事件1排在最前,行为数据1和行为数据2排在后边,则可依据事件1,将行为数据1和行为数据2从前向后进行补全,也即,后向补全。补全后的行为数据如表9所示:
sessionid |
数据源 |
MAC |
账号 |
具体数据 |
1 |
业务系统 |
Aaaaaaa |
xxx@alipay.com |
事件1 |
1 |
采集脚本 |
Aaaaaaa |
xxx@alipay.com |
行为数据1 |
1 |
采集脚本 |
Aaaaaaa |
xxx@alipay.com |
行为数据2 |
表9
当然,将用户行为数据和事件按携带的时间戳进行时间先后排序,事件也有可能处于若干个用户行为数据之间,如,行为数据1、事件1、行为数据2,因此,可结合上述的前向补全和后向补全的方法对用户行为数据进行补全,这里就不再一一赘述。
当然,上例只是以风控主体信息为会话为例进行说明的,在实际应用中,风控主体信息也可以是其他的信息,如,IP地址、账号、客户端所在的计算机等。
通过上述数据补全方法,将用户行为数据进行补全后,在根据事件和补全之后的数据进行风险防控时,可根据预设的事件与行为信息的对应关系,以及用户行为数据与行为信息的对应关系,将提取的事件和用户行为数据转换为相应的行为信息,具体为:根据提取的事件和用户行为数据中携带的时间戳,按照时间先后顺序,将提取的事件和用户行为数据进行排序(类似的,如果之前的步骤已经按时间先后顺序对事件和用户行为数据进行了排序,则此处的排序可以不再执行),根据预设的事件与行为信息的对应关系,以及用户行为数据与行为信息的对应关系,将排序后的事件和用户行为数据转换为相应的行为信息,得到行为信息序列。
仍以表7为例进行说明,假设行为数据1携带的时间戳是12:00,用户行为数据2携带的时间戳是12:02,事件1携带的时间戳是12:05,则按照时间先后顺序排序后,可得到这样一个序列:行为数据1、行为数据2、事件1。
风控系统可预先保存用户行为数据的属性或类型与行为信息的对应关系,如:当用户行为数据的类型为点击“搜索”按钮时,该用户行为数据对应的行为信息就是搜索,当用户行为数据的类型为点击某个商品信息时,该用户行为数据对应的行为信息就是浏览。类似的,风控系统也可预先保存事件与行为信息的对应关系,这样,风控系统可根据这些对应关系,将排序后的事件和用户行为数据转换为相应的行为信息,得到行为信息序列。
继续沿用上例,假设行为数据1的具体数据是用户点击了某个商品信息,则其对应的行为信息为浏览,行为数据2的具体数据是用户点击了“下单”按钮,则其对应的行为信息为下单,事件1的具体数据是用户发生了支付事件,则其对应的行为信息为支付,从而,风控数据得到的行为信息序列为:浏览、下单、支付。后续,风控系统则可根据得到的行为信息序列进行风控处理。
具体的,在将用户行为数据和事件得到行为信息序列后,在根据得到的行为信息序列进行风控主体信息防控时,具体为:根据行为信息序列以及预设的风险评估模型,判断所述风控主体信息是否存在风险,并根据判断结果进行相应处理。
继续沿用上例,用户在12:00到12:05时间段内的行为信息序列为:浏览、下单、支付,假设风险评估模型为:如果在支付行为之前20分钟内,存在一个浏览行为,则风控主体信息不存在风险,否则该风控主体信息存在风险。则根据上述得到的行为信息序列可知,在支付行为之前的20分钟之内是存在浏览行为的,因此可判定风控主体信息(也就是sessionid1)不存在风险。
上例只是以一个简单的风险评估模型为例说明的,在实际应用中,风险评估模型可能取决于很多因素,这些因素如表10所示。
表10
其中,上述表10中,A类、B类、某类指标可以根据实际需要进行设定。
在对风控主体信息进行风控处理时,具体可针对不同的风控主体信息进行不同的风控处理,如,当风控处理信息是某次交易的交易标识时,可针对该交易标识所代表的交易行为进行终止,当风控主体信息是某个账号时,可冻结该账号,这里就不再一一举例说明。
以上为本申请实施例提供的信息风险防控方法,基于同样的思路,本申请实施例还提供一种信息风险防控装置,如图3、图4所示。
图3为本申请实施例提供的信息风险防控装置结构示意图,所述装置具体包括:
接收模块301,用于接收客户端采集并发送的用户行为数据以及第二系统发送的事件;
提取模块302,用于根据指定的风控主体信息,从接收到的事件中提取包含所述风控主体信息的事件,从接收到的用户行为数据中提取包含所述风控主体信息的用户行为数据;
转换模块303,用于根据预设的事件与行为信息的对应关系,以及用户行为数据与行为信息的对应关系,将提取的事件和用户行为数据转换为相应的行为信息;
处理模块304,用于根据转换得到的行为信息,对所述风控主体信息进行风控处理。
所述装置预先将调用代码插入到第二系统保存的网页代码中,所述调用代码用于调用所述装置中的调用脚本;
所述接收模块301具体包括:
第一请求接收单元3011,用于接收客户端通过所述调用代码发送的第一调用请求,其中,所述第一调用请求是所述客户端在加载所述第二系统中的网页代码时,通过所述网页代码中插入的所述调用代码发送的;
调用脚本返回单元3012,用于根据所述第一调用请求,向所述客户端返回调用脚本;
第二请求接收单元3013,用于接收所述客户端通过所述调用脚本发送的第二调用请求;
采集脚本返回单元3014,用于根据所述第二调用请求,向所述客户端返回各采集脚本;
接收单元3015,用于接收所述客户端通过所述采集脚本采集并发送的用户行为数据。
所述调用脚本、采集脚本包括Javascript脚本。
所述提取模块302,具体用于根据接收到的事件中携带的时间戳,从接收到的事件中提取出包含该风控主体信息、且在过去指定时间段内的事件,根据接收到的用户行为数据中携带的时间戳,从接收到的用户行为数据中提取出包含该风控主体信息、且在过去指定时间段内的用户行为数据。
,所述提取模块302,具体用于根据接收到的事件和用户行为数据中携带的时间戳,对接收到的各事件和用户行为数据按时间先后顺序进行排序,根据排序后的事件和用户行为数据确定出若干个数据组,其中,每个数据组中的用户行为数据和事件均包含该风控主体信息,且一个数据组中每两个相邻的用户行为数据或事件之间的时间间隔不超过预设时长,从确定出的所述若干个数据组中选择满足指定条件的数据组,并从选择出的数据组中提取用户行为数据和事件。
所述装置还包括:
数据补全模块305,用于在所述转换模块303将提取的事件和用户行为数据转换为相应的行为信息之前,采用提取的事件对提取的用户行为数据进行数据补全。
所述转换模块303具体包括:
排序单元3031,用于根据提取的事件和用户行为数据中携带的时间戳,按照时间先后顺序,将提取的事件和用户行为数据进行排序。
转换单元3032,用于根据预设的事件与行为信息的对应关系,以及用户行为数据与行为信息的对应关系,将排序后的事件和用户行为数据转换为相应的行为信息,得到行为信息序列。
所述处理模块304,具体用于根据所述行为信息序列以及预设的风险评估模型,判断所述风控主体信息是否存在风险,并根据判断结果进行相应处理。
具体的,如图3所示的信息风险防控装置可以位于第一系统中。
图4为本申请实施例提供的另一种信息风险防控装置结构示意图,第二系统保存的网页代码中预先被插入了调用代码,所述调用代码用于调用第一系统中的调用脚本,所述装置包括:
第一请求发送模块401,用于在加载插入有所述调用代码的网页代码时,通过所述调用代码向所述第一系统发送第一调用请求;
调用脚本接收模块402,用于接收所述第一系统根据所述第一调用请求返回的调用脚本;
第二请求发送模块403,用于通过所述调用脚本向第一系统发送第二调用请求;
采集脚本接收模块404,用于接收第一系统根据所述第二调用请求返回的各采集脚本;
数据发送模块405,用于通过所述各采集脚本采集用户行为数据,并发送给第一系统,使所述第一系统根据所述用户行为数据和从第二系统接收到的事件进行风控处理。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。