CN109426961A - 一种绑卡风险控制方法及装置 - Google Patents
一种绑卡风险控制方法及装置 Download PDFInfo
- Publication number
- CN109426961A CN109426961A CN201710734945.XA CN201710734945A CN109426961A CN 109426961 A CN109426961 A CN 109426961A CN 201710734945 A CN201710734945 A CN 201710734945A CN 109426961 A CN109426961 A CN 109426961A
- Authority
- CN
- China
- Prior art keywords
- account
- card
- preset
- incidence relation
- risk
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本发明涉及安全技术领域,尤其涉及一种绑卡风险控制方法及装置,该方法为,接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制,这样,快捷支付绑卡时,通过挖掘当前账号和已绑同卡账号之间的关联关系,不仅能够有效识别银行卡盗刷,对绑卡风险进行控制,而且绑卡风险控制的能力可以随着账号规模的扩大而增强。
Description
技术领域
本发明涉及安全技术领域,尤其涉及一种绑卡风险控制方法及装置。
背景技术
目前,由于快捷支付的快速和便捷性,应用非常广泛,使用的用户也越来越多,用户只需提前在第三方支付平台上,注册账号,并绑定银行卡,设置支付密码,每次支付时只需要验证支付密码,即可完成支付。但是,也由于其方便简单,银行卡盗刷的风险也比较高,银行卡盗刷是所有快捷支付面临的共同问题。
现有技术中,绑卡风险控制方法,例如,基于位置或者预设的黑名单的防盗刷策略;对绑卡-支付行为检测的防盗刷策略;快捷支付绑卡和消费时,基于采集到的用户的生物特征的防盗刷策略。
但是,现有技术中的这些绑卡风险控制的方法,虽然在一定程度可以识别银行卡盗刷,但是均是仅针对一个账号的绑卡和消费行为进行的,而实际中,用户往往会使用一张银行卡绑定第三方支付平台中的多个账号,这些账号之间会有一定的关联关系,现有技术中,忽略了这些账号之间的关联关系,识别银行卡盗刷的能力不能随着账号规模的扩大而增强。
发明内容
本发明实施例提供一种绑卡风险控制方法及装置,以解决现有技术中绑卡风险控制的能力不能随着账号规模的扩大而增强的问题。
本发明实施例提供的具体技术方案如下:
一种绑卡风险控制方法,包括:
接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;
检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;
根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
较佳的,获取所述第一账号和所述第二账号的关联关系,具体包括:
获取第一账号和第二账号的信息;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标。
较佳的,根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,具体包括:
确定在至少一个账号关系维度下所述第一账号和第二账号的信息是否满足对应的预设条件,当确定满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,账号关系维度,包括以下至少一种:预设的关键要素、预设的登录环境信息、资金关系和对比活跃度;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,具体包括:
确定所述第一账号和所述第二账号的预设的关键要素信息是否相同,当确定预设的关键要素信息相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为1,当确定预设的关键要素信息不相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的关键要素信息,表示在账号注册时,验证通过的信息;
确定所述第一账号和所述第二账号的登录设备标识和/或登录IP地址是否相同,当确定相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的登录环境信息,包括登录设备标识和/或登录IP地址;
确定所述第一账号和所述第二账号之间的资金往来状态是否满足预设条件,当确定满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为0;
确定所述第一账号和所述第二账号在预设时间段内是否有行为操作,当确定第二账号在预设时间段内出现行为操作的频率小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定第二账号在预设时间段内出现行为操作的频率不小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率不大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级,具体包括:
计算关联关系指标取值为1的个数,当确定所述关联关系指标取值为1的个数不小于预设数目时,确定所述绑卡请求的风险等级为低风险等级,当确定所述关联关系指标取值为1的个数小于预设数目时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,进一步包括:
获取所述绑卡请求的发送请求时间和所述第一账号的账号标识,根据所述账号标识和所述发送请求时间,将所述绑卡请求的风险等级,以及在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标进行保存。
较佳的,进一步包括:
若确定所述银行卡被所述支付平台中至少两个第二账号绑定,则分别基于所述第一账号与每一个第二账号,确定所述绑卡请求的风险等级;
当确定至少一个风险等级为低风险等级时,确定所述绑卡请求的风险等级为低风险等级,当确定所有风险等级均为高风险等级时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制,具体包括:
根据所述绑卡请求的风险等级,采用预设的方式,对所述绑卡请求进行风险控制。
较佳的,进一步包括:
接收用户通过支付平台发送的获取手机验证码请求,并在执行手机验证码下发流程的同时,启动计算所述绑卡请求的风险等级;或者,
接收用户通过支付平台发送的获取手机验证码请求,并在确定手机验证码验证通过后,启动计算所述绑卡请求的风险等级。
一种绑卡风险控制装置,包括:
接收模块,用于接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;
关系计算模块,检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;
风控决策模块,用于根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
较佳的,获取所述第一账号和所述第二账号的关联关系,关系计算模块具体用于:
获取第一账号和第二账号的信息;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,具体为:确定在至少一个账号关系维度下所述第一账号和第二账号的信息是否满足对应的预设条件,当确定满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,账号关系维度,包括以下至少一种:预设的关键要素、预设的登录环境信息、资金关系和对比活跃度;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,关系计算模块具体用于:
确定所述第一账号和所述第二账号的预设的关键要素信息是否相同,当确定预设的关键要素信息相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为1,当确定预设的关键要素信息不相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的关键要素信息,表示在账号注册时,验证通过的信息;
确定所述第一账号和所述第二账号的登录设备标识和/或登录IP地址是否相同,当确定相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的登录环境信息,包括登录设备标识和/或登录IP地址;
确定所述第一账号和所述第二账号之间的资金往来状态是否满足预设条件,当确定满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为0;
确定所述第一账号和所述第二账号在预设时间段内是否有行为操作,当确定第二账号在预设时间段内出现行为操作的频率小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定第二账号在预设时间段内出现行为操作的频率不小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率不大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级,关系计算模块具体用于:
计算关联关系指标取值为1的个数,当确定所述关联关系指标取值为1的个数不小于预设数目时,确定所述绑卡请求的风险等级为低风险等级,当确定所述关联关系指标取值为1的个数小于预设数目时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,关系计算模块进一步用于:
若确定所述银行卡被所述支付平台中至少两个第二账号绑定,则分别基于所述第一账号与每一个第二账号,确定所述绑卡请求的风险等级;
当确定至少一个风险等级为低风险等级时,确定所述绑卡请求的风险等级为低风险等级,当确定所有风险等级均为高风险等级时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,接收模块进一步用于:
接收用户通过支付平台发送的获取手机验证码请求;
关系计算模块,进一步用于在执行手机验证码下发流程的同时,启动计算所述绑卡请求的风险等级;或者,在确定手机验证码验证通过后,启动计算所述绑卡请求的风险等级。
较佳的,根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制,风控决策模块具体用于:
根据所述绑卡请求的风险等级,采用预设的方式,对所述绑卡请求进行风险控制。
较佳的,进一步包括:
关系查询模块,用于获取所述绑卡请求的发送请求时间和所述第一账号的账号标识,根据所述账号标识和所述发送请求时间,将所述绑卡请求的风险等级,以及在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标进行保存。
一种服务器,包括:
至少一个存储器,用于存储程序指令;
至少一个处理器,用于调用所述存储器中存储的程序指令,按照获得的程序指令执行本发明实施例中的绑卡风险控制方法。
本发明实施例中,接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制,这样,在接收到绑卡请求时,判断银行卡是否与其它账号绑卡,计算当前账号和已绑同卡账号之间的关联关系,充分挖掘账号之间的关联关系,从而确定绑卡请求是否存在风险,进而实现对银行卡盗刷的风险控制,不仅可以有效识别绑卡请求的风险,而且,绑卡风险控制的能力可以随着账号规模的扩大而增强。
附图说明
图1为本发明实施例一提供的绑卡风险控制方法的流程图;
图2为本发明实施例二提供的绑卡风险控制方法的执行过程流程图;
图3为本发明实施例三提供的服务器架构环境示意图;
图4为本发明实施例四提供的绑卡请求过程的界面示意图;
图5为本发明实施例五提供的绑卡风险控制装置结构示意图;
图6为本发明实施例六中绑卡风险控制实现流程框架图;
图7为本发明实施例七提供的服务器结构示意图;
图8为本发明实施例八提供的用户终端结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,并不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
为便于对本发明实施例的理解,下面先对几个概念进行简单介绍:
快捷支付:支付平台与银行合作的一种便捷支付功能。用户提供银行卡卡号、身份证、姓名、手机号码,由银行验证通过,并验证银行卡预留手机的短信验证码后即可开通。用户可在第三方支付平台设置支付密码,之后每次支付仅需验证支付密码。开通和支付的过程无需验证银行卡密码,不需开通网银。
银行卡四要素:指快捷支付需要验证的银行卡卡号、身份证、姓名、银行预留手机号码四个静态信息。
银行卡盗刷:表示非法盗取或消费他人银行卡资金的行为。目前,快捷支付由于其便利性,已经成为银行卡盗刷的主流方式和渠道。不法分子通过冒用他人的银行卡四要素,并设法突破短信验证,从而开通快捷支付并盗取资金。支付平台在受理快捷支付的绑卡请求时,除了确保银行卡四要素在银行侧验证通过以及银行卡预留手机验证码验证通过,还需要根据自身业务特性制定相应的风控措施,以防范银行卡盗刷风险。银行卡防盗刷是支付平台的必备、核心的风控能力。
帐号:用户在支付平台开通快捷支付前,首先需要注册帐号,再把帐号与银行卡进行绑定,一旦绑定成功,该帐号可发起支付行为,资金由绑定的银行卡提供。支付平台为了控制风险,可拒绝某些帐号与银行卡的绑定动作。
实施例一:
参阅图1所示,本发明实施例一提供的绑卡风险控制方法,具体包括以下步骤:
步骤100:接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求。
本发明实施例中,主要是针对快捷支付中银行卡盗刷的情况,实际中,随着业务的发展,对于某支付平台,用户可能在该支付平台中同时拥有多个账号,多个账号可能都绑定同一张银行卡。由于这多个账号属于同一个用户,因此,这多个账号之间会存在一定的关联关系,现有技术中的绑卡风险控制的方法,均忽略了这多个账号之间的关联关系,本发明实施例中,充分利用绑定同一张银行卡的多个账号之间的关联关系,提出了一种新的绑卡风险控制方法,其防盗刷能力能够随着账号规模的扩大而增强。
其中,支付平台,可以表示能够提供支付能力的支付软件,例如,微信平台、支付宝平台等。
例如,用户使用第一账号进入某支付平台的绑卡申请界面,需要先填写银行卡四要素,即银行卡卡号、身份证、姓名、银行预留手机号码,由该银行卡相应的银行验证通过,然后请求获取手机验证码,即发送了绑卡请求。
当然,本发明实施例中的绑卡风险控制方法,并不仅限于银行卡,可以是任意能够存储钱或金融数据并且能够支付的卡,例如,信用卡、超市的支付卡等。
步骤110:检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系。
执行步骤110时,具体包括:
首先,检测所述银行卡是否与所述支付平台中的第二账号绑定。
具体地,根据接收到的用户输入的银行卡卡号,在系统中进行查询,判断该银行卡是否有被其它账号绑定过。
然后,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系。
具体为:(1)获取第一账号和第二账号的信息。
例如,可以获取在不同账号关系维度下,第一账号和第二账号的信息。
其中,账号关系维度,表示支付平台中两个或多个账号可能存在的有联系的方面,包括以下至少一种:预设的关键要素、预设的登录环境信息、资金关系和对比活跃度。
具体地:1)预设的关键要素。其中,预设的关键要素信息,表示在账号注册时,验证通过的信息,例如为,手机号、电子邮箱地址等。
则分别获取第一账号和第二账号,在注册时验证通过的信息,例如,手机号、电子邮箱地址等。
2)预设的登录环境信息。其中,预设的登录环境信息,包括登录设备标识和/或登录IP地址。
则分别获取第一账号和第二账号,对应的登录设备标识和/或登录IP。
3)资金关系。分别获取第一账号和第二账号的资金往来状态情况,例如,第一账号和第二账号之间是否有资金往来、资金往来的频率,或资金往来的数目等。
4)对比活跃度。根据第一账号和第二账号在预设时间段内出现行为操作的频率,分别确定第一账号和第二账号的账号活跃度,其中,出现的行为操作,可以为在支付平台上,第一账号和第二账号的任何行为操作,例如,聊天、登录、支付等操作。
当然,也可以根据实际情况,设置其它不同的账号关系维度,本发明实施例中并不进行限制,例如,若业务允许第一账号和第二账号之间存在社交关系,则可以进行社交关系亲密度计算,分别获取第一账号和第二账号的社交信息,计算第一账号和第二账号的社交关系亲密度。
(2)根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标。
具体为:确定在至少一个账号关系维度下所述第一账号和第二账号的信息是否满足对应的预设条件,当确定满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为0。
根据上述账号关系维度,相应地可以分为:
1)确定所述第一账号和所述第二账号的预设的关键要素信息是否相同,当确定预设的关键要素信息相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为1,当确定预设的关键要素信息不相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为0。
也就是说,当两个账号注册时预设的关键要素信息相同,例如,验证的电子邮箱地址相同,这样,两个账号属于相同用户的可能性较大,由于第二账号已绑定该银行卡,则第一账号的绑卡请求风险就比较低,反之,风险可能比较高。
2)确定所述第一账号和所述第二账号的登录设备标识和/或登录IP地址是否相同,当确定相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为0。
也就是说,两个账号的登录环境信息,可以表征是否是相同用户在相同的环境下操作,若登录环境信息相同,则两个账号之间的关联关系比较亲密,第一账号的绑卡请求风险会相较低。
3)确定所述第一账号和所述第二账号之间的资金往来状态是否满足预设条件,当确定满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为0。
本发明实施例中,两个账号的资金往来状态,可以说明两个账号之间在资金上是否有关联关系,例如,若有资金往来,则说明这两个账号有互动,关联关系比较亲密。又例如,资金往来的频率达到设定值,则第一账号和第二账号的资金关系比较亲密,关联关系指标的取值就可以为1。
4)确定所述第一账号和所述第二账号在预设时间段内是否有行为操作,当确定第二账号在预设时间段内出现行为操作的频率小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定第二账号在预设时间段内出现行为操作的频率不小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率不大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为0。
其中,第一预设阈值和第二预设阈值,本发明实施例中,并不进行限制,可以根据实际情况进行设置。
也就是说,这种情况主要针对支付平台中的死账号,可能某个账号用户一直未使用,或已经丢弃,并且,该用户注册了一个新的账号,则新的账号的活跃度就比较高,这时,也可以认为第一账号的绑卡请求的风险比较低。
也就是说,本发明实施例中,针对不同的账号关系维度,相应地设置不同的预设条件,每一个账号关系维度分别进行判断,得到在每一个账号关系维度下,第一账号和第二账号的关联关系指标,这样,可以更准确地描述第一账号和第二账号的关联关系,利用大数据计算挖掘账号之间的深度关联关系特征。
本发明实施例中,确定发起绑卡请求的银行卡已与其它账号绑定,可以计算发起绑卡请求的账号和同卡账号之间的相互关联关系,用于后续对绑卡请求的风险判断,这些账号之间的关联关系可以在识别绑卡请求是否存在风险时,可以发挥关键的识别作用。
进一步地,在执行步骤110时,若确定所述银行卡没有被所述支付平台中的第二账号绑定过,则使用预设的绑卡风险控制方法,对所述绑卡请求进行风险控制。
也就是说,若该银行卡没有被其它账号绑定过,则也可以使用现有技术中的绑卡风险控制方法,进行风险控制,不会降低绑卡风险控制的能力。
步骤120:根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级。
执行步骤120时,具体为:
计算关联关系指标取值为1的个数,当确定所述关联关系指标取值为1的个数不小于预设数目时,确定所述绑卡请求的风险等级为低风险等级,当确定所述关联关系指标取值为1的个数小于预设数目时,确定所述绑卡请求的风险等级为高风险等级。
其中,预设数目,是一个可以调整的系统参数,可以根据实际需求,进行修改,本发明实施例中,并不进行限定。
并且,本发明实施例中,不同的风险等级,可以设置不同的风险指标,例如,高风险等级对应的风险指标为1,低风险等级对应的风险指标为0。
进一步地,若确定银行卡没有与支付平台中的第二账号绑定过,则该绑卡请求的风险等级为未知,风险指标为-1。
例如,有n个账号关系维度,预设数目为m,如果这n个账号关系维度中,其中,关联关系指标取值为1的个数不小于m,则说明第一账号和第二账号关联关系比较亲密,此次绑卡请求判断为低风险,如果小于m,则说明第一账号和第二账号的关联关系不大,此次绑卡请求可以判断为高风险。
本发明实施例中,风险等级由在至少一个账号关系维度下,第一账号和第二账号的关联关系指标取值决定,提高了判断的准确性,快捷支付绑定银行卡时,通过挖掘已绑定账号跟当前账号的关联关系,可以有效识别出银行卡盗刷的风险。
进一步地,获取所述绑卡请求的发送请求时间和所述第一账号的账号标识,根据所述账号标识和所述发送请求时间,将所述绑卡请求的风险等级,以及在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标进行保存。
这样,由于同一个账号,可能会发生多个绑卡情况,因此,将第一账号标识和发送请求时间,同时进行记录,可以便于后续基于第一账号标识和发送请求时间,查询相应的绑卡请求风险等级。
进一步地,若确定所述银行卡被所述支付平台中至少两个第二账号绑定,则计算该绑卡请求的风险等级时,具体为:
分别基于所述第一账号与每一个第二账号,确定所述绑卡请求的风险等级,并当确定至少一个风险等级为低风险等级时,确定所述绑卡请求的风险等级为低风险等级,当确定所有风险等级均为高风险等级时,确定所述绑卡请求的风险等级为高风险等级。
也就是说,本发明实施例中,若该银行卡已与至少两个第二账号绑定,例如,分别为账号b1和b2,则分别计算在至少一个账号关系维度下,第一账号与账号b1的关联关系指标,并确定基于第一账号和账号b1,该绑卡请求的风险等级;以及,分别计算在至少一个账号关系维度下,第一账号与账号b2的关联关系指标,并确定基于第一账号和账号b2,该绑卡请求的风险等级,只要有一个判断为低风险等级,则该绑卡请求就可以判断为低风险等级。
不管有几个判断为高风险等级,只要有一个判断为低风险等级,就说明第一账号与该第二账号比较亲密,可以同意此次第一账号的绑卡请求,这是因为,第二账号都是已经和银行卡绑定的账号,就算同意了第一账号的绑卡请求,也不会额外增加系统的风险。
步骤130:根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
执行步骤130时,具体包括:
根据所述绑卡请求的风险等级,采用预设的方式,对所述绑卡请求进行风险控制。
例如,当判断为高风险等级时,则可以直接拒绝该绑卡请求,当判断为低风险等级时,则同意该绑卡请求。
进一步地,在执行步骤130时,还包括:获取采用预设的防盗刷方法的判断结果,根据所述判断结果和所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
也就是说,本发明实施例中,可以结合本发明实施例中的绑卡风险控制方法和现有技术中的防盗刷方法,共同决策,对绑卡请求进行风险控制,这样,可以将本发明实施例中的绑卡风险控制方法,无缝嵌入到原有的风控系统中,产品逻辑无需改动,可以进一步增加绑卡风险控制的能力。
值得说明的是,执行本发明实施例中的绑卡风险控制方法,可以采用以下两种方式:
第一种方式:异步运算。接收用户通过支付平台发送的获取手机验证码请求,并在执行手机验证码下发流程的同时,启动计算所述绑卡请求的风险等级。
实际中,在支付平台绑卡时,用户需要先输入银行卡四要素,银行侧验证通过后,用户点击获取验证码,发送获取手机验证码请求,等待接收下发的手机验证码。
本发明实施例中,如果账号关系维度比较多,两个账号之间的关联关系需要做多个账号关系维度的计算,可能需要消耗较长的时间,而如果同步等待的时间达到3秒以上,用户会有明显的感知。
因此,在用户点击获取验证码,即接收到用户发送的获取手机验证码请求时,同时启动计算本发明实施例中的绑卡请求的风险等级,计算完成后,将绑卡请求的风险等级进行保存,进而当手机验证码验证通过后,可以直接获取保存的风险等级,不会有等待时间,整个过程用户无感知,无需用户额外验证,绑卡体验不受中断,达到了安全和用户体验的兼顾。
第二种方式:同步运算。接收用户通过支付平台发送的获取手机验证码请求,并在确定手机验证码验证通过后,启动计算所述绑卡请求的风险等级。
本发明实施例中,如果业务流程简单,账号关系维度定义比较明确,可以在很短时间内,例如1s以内就可以计算出来,则也可以不用异步运算,待手机验证码验证通过后,再启动计算绑卡请求的风险等级,由于计算时间比较短,也不会影响用户感知,并且,若手机验证码未验证通过,则不用进行计算,也节省了计算资源。
实施例二:
下面采用一个具体的应用场景对上述实施例作出进一步详细说明。以采用异步运算的方式为例,具体参阅图2所示,本发明实施例二中,绑卡风险控制方法的执行过程具体如下:
步骤200:用户输入银行卡四要素,并点击获取手机验证码。
步骤201:接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求。
步骤202:判断银行卡是否有与支付平台中的第二账号绑定,若是,则执行步骤203,否则,则执行步骤209。
步骤203:获取第一账号和第二账号的信息。
步骤204:根据获取的第一账号和第二账号的信息,获取在至少一个账号关系维度下第一账号与第二账号的关联关系指标。
步骤205:根据在至少一个账号关系维度下第一账号与第二账号的关联关系指标,确定绑卡请求的风险等级。
步骤206:根据第一账号的账号标识和绑卡请求的发送请求时间,将对应的关联关系指标和风险等级进行保存。
其中,保存的形式,例如为,在每个账号关系维度下,关联关系指标取值为0或1,风险等级相应的风险指标取值分别为:-1:未被其它第二账号绑定,0:低风险等级,1:高风险等级,则在保存时,以账号标识和发送请求时间为key,以关联关系指标和风险等级的风险指标为value,其中,value可以分为两个字段,第一个字段用于保存关联关系指标,为若干个(比特)bit位的拼接,每个bit位分别对应每个账号关系维度的关联关系指标的取值,第二个字段用于保存风险等级对应的风险指标取值。
例如,若有四个账号关系维度,并且在这四个账号关系维度下,第一账号和第二账号的关联关系指标取值分别为0、1、1和0,风险等级为高风险等级,则第一个字段保存的为:0101,第二个字段保存的为:1。
本发明实施例中,不仅保存了风险等级,也同时保存账号关系维度下的风险指标,这样,这些风险指标,能够用于案例分析、举证等,可以知道哪些账号关系维度出现了问题,也方便在业务实施时,可以进行有针对的防控措施。
步骤207:确定手机验证码验证通过后,获取保存的该绑卡请求对应的风险等级。
步骤208:根据绑卡请求的风险等级,对绑卡请求进行风险控制。
步骤209:结束。
本发明实施例中,利用手机验证码的验证时间窗口,进行异步运算,避免同步等待,无需用户额外的验证,可以做到用户无感知,对用户体验没有损伤;通过计算第一账号和第二账号的关联关系指标,挖掘两个账号之间的相互关联关系,进而确定绑卡请求的风险等级,这样,充分利用账号之间的关联关系,可以有效提升绑卡风险控制的能力,并且,绑卡风险控制能力可以随着账号规模的扩大而增加。
例如,属于盗刷的绑卡请求被检测出来的概率为r(覆盖率),本发明实施例可以使r达到一个收敛下降的良性状态。这是因为,假设任意一张银行卡已经跟系统中帐号存在绑定关系的概率为p,在此前提下,潜在的盗刷绑定被识别出来的概率为q,那么本发明实施例中的绑卡风险控制方法,对于盗刷的覆盖率将是r=p*q。随着业务的发展,p逐步增加,而随着风控策略的运营,q只要不下降,r将随着业务发展而同步提升,业务规模越大,抵御盗刷风险的能力就越强。
实施例三:
本发明实施例中,参阅图3所示,本发明实施例三中,服务器架构环境示意图。
实际应用中,服务器与用户终端连接,参阅图3所示,以三个用户终端为例,分别为用户终端1、用户终端2和用户终端3,用户在用户终端上,通过支付平台发送将银行与账号绑定的绑卡请求。服务器接收绑卡请求,并基于本发明实施例中的绑卡风险控制方法,对该绑卡请求进行风险控制,以及向用户终端返回反馈结果。
其中,用户终端可以为手机、电脑、ipad等任何智能设备。
其中,支付平台,表示能够提供支付能力的支付软件,本发明实施例中并不进行限制,例如为,微信平台、支付宝平台等。
实施例四:
基于上述实施例,本发明实施例四中,采用一个具体应用场景,对上述实施例进行简单介绍。以用户为手机上的微信账号绑定银行卡为例,参阅图4所示,为用户通过手机上的微信,为账号a绑定银行卡的过程示意图。
首先,用户打开微信,登陆微信账号a,点击“我”,找到“钱包”,并点击“钱包”后,找到“添加银行卡”,参阅图4中(1)图。
然后,输入绑定银行卡所需的银行卡四要素:银行卡卡号、姓名、身份证和银行预留手机号码,并点击“获取验证码”,参阅图4中(2)图。
然后,等待下发验证码的同时,支付平台的服务器接收到绑卡请求,并基于上述本发明实施例中的绑卡风险控制方法,查找该银行卡是否有与其它微信账号绑定,确定有时,例如为微信账号b,则根据微信账号a和微信账号b之间的关联关系计算,若确定微信账号a和微信账号b关联关系比较密切,则确定该绑卡请求的风险等级较低,否则,确定该绑卡请求的风险等级较高,并记录此次绑卡请求对应的风险等级。
最后,当验证码验证通过后,获取记录的此次绑卡请求对应的风险等级,若为高风险等级,则可以直接拒绝该绑卡请求,例如,参阅图4中(3)所示,用户收到“您的绑卡请求存在风险,绑卡失败”的消息。
值得说明的是,图4仅仅是一种可以实现的示例,对于功能按钮或界面的设置等并不进行限制。
实施例五:
基于上述实施例,参阅图5所示,本发明实施例五中,绑卡风险控制装置,具体包括:
接收模块50,用于接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;
关系计算模块51,检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;
风控决策模块52,用于根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
较佳的,获取所述第一账号和所述第二账号的关联关系,关系计算模块51具体用于:
获取第一账号和第二账号的信息;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,具体为:确定在至少一个账号关系维度下所述第一账号和第二账号的信息是否满足对应的预设条件,当确定满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,账号关系维度,包括以下至少一种:预设的关键要素、预设的登录环境信息、资金关系和对比活跃度;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,关系计算模块51具体用于:
确定所述第一账号和所述第二账号的预设的关键要素信息是否相同,当确定预设的关键要素信息相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为1,当确定预设的关键要素信息不相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的关键要素信息,表示在账号注册时,验证通过的信息;
确定所述第一账号和所述第二账号的登录设备标识和/或登录IP地址是否相同,当确定相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的登录环境信息,包括登录设备标识和/或登录IP地址;
确定所述第一账号和所述第二账号之间的资金往来状态是否满足预设条件,当确定满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为0;
确定所述第一账号和所述第二账号在预设时间段内是否有行为操作,当确定第二账号在预设时间段内出现行为操作的频率小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定第二账号在预设时间段内出现行为操作的频率不小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率不大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级,关系计算模块51具体用于:
计算关联关系指标取值为1的个数,当确定所述关联关系指标取值为1的个数不小于预设数目时,确定所述绑卡请求的风险等级为低风险等级,当确定所述关联关系指标取值为1的个数小于预设数目时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,关系计算模块51进一步用于:
若确定所述银行卡被所述支付平台中至少两个第二账号绑定,则分别基于所述第一账号与每一个第二账号,确定所述绑卡请求的风险等级;
当确定至少一个风险等级为低风险等级时,确定所述绑卡请求的风险等级为低风险等级,当确定所有风险等级均为高风险等级时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,接收模块50进一步用于:
接收用户通过支付平台发送的获取手机验证码请求;
关系计算模块51,进一步用于在执行手机验证码下发流程的同时,启动计算所述绑卡请求的风险等级;或者,在确定手机验证码验证通过后,启动计算所述绑卡请求的风险等级。
较佳的,根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制,风控决策模块52具体用于:
根据所述绑卡请求的风险等级,采用预设的方式,对所述绑卡请求进行风险控制。
较佳的,进一步包括:
关系查询模块53,用于获取所述绑卡请求的发送请求时间和所述第一账号的账号标识,根据所述账号标识和所述发送请求时间,将所述绑卡请求的风险等级,以及在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标进行保存。
本发明实施例中,关系计算模块用于计算账号之间的关联关系和绑卡请求的风险等级,关系查询模块保存关系计算模块的结果。
具体实现时,可以为关系计算模块的输入为:账号标识+发送请求时间+账号的信息(例如为各账号关系维度所需的信息),关系计算模块的输出为:以账号标识+发送请求时间为key,以各账号关系维度的关联关系指标和绑卡风险等级对应的风险指标为value,并写入到关系查询模块。
值得说明的是,发送请求时间可以精确到毫秒,便于区分第一账号的多个绑卡请求。关系计算模块从输入到输出结果,时间也可以控制在10秒以内。关系查询模块,用于接收和保存关系计算模块输出的结果,并提供快速查询服务,为纯内存的数据存取,响应时间可以控制在50ms以内。风控决策模块就可以以账号标识+发送请求时间为key,通过关系查询模块查询到风险指标和关联关系指标,进而决策是否需要拦截此次绑卡请求,若拦截,查询到的关系计算结果同时以log的方式记录下来,这样可以便于以后的案例分析和二次运营。
其中,各个模块时间的控制,可以采用预设的数据存储形式,例如通过内存数据库,这样,可以提高计算或查询的时间和效率。
本发明实施例中,快捷支付绑卡时,通过挖掘当前账号和已绑同卡账号之间的关联关系,识别银行卡盗刷风险,考虑支付平台所拥有的账号之间的关联关系,能够有效识别银行卡盗刷,并且,绑卡风险控制的能力可以随着账号规模的扩大而增强。
实施例六:
基于上述实施例,参阅图6所示,本发明实施例六中,绑卡风险控制实现流程框架图。
参阅图6所示,本发明实施例中,从用户侧和服务器侧的交互进行说明。其中,服务器侧包括关系计算模块、关系查询模块和风控决策模块。
首先,用户在支付平台上进入绑卡界面,输入银行卡四要素,并请求获取手机验证码。
然后,服务器若确定该银行卡与支付平台中的其它账号绑定,则进入关系计算模块。
具体为:计算发起绑卡请求的账号和同卡账号,在至少一个账号关系维度下的关联关系指标,并确定绑卡请求的风险等级,以及输出计算结果到关系查询模块。
然后,用户输入获取的验证码。
然后,服务器侧,进入风控决策模块和关系查询模块。
具体地:风控决策模块,从关系查询模块中查询获取绑卡请求对应的风险等级和账号关系维度下的关联关系指标,并对绑卡请求进行风险控制。
最后,用户侧,显示反馈结果,例如为,绑卡成功或绑卡失败。
实施例七:
基于上述实施例,参阅图7所示,本发明实施例七中,一种服务器的结构示意图。
本发明实施例七提供了一种服务器,该服务器可以包括处理器710(CenterProcessing Unit,CPU)、存储器720、输入设备730和输出设备740等,输入设备730可以包括键盘、鼠标、触摸屏等,输出设备740可以包括显示设备,如液晶显示器(Liquid CrystalDisplay,LCD)、阴极射线管(Cathode Ray Tube,CRT)等。
存储器720可以包括只读存储器(ROM)和随机存取存储器(RAM),并向处理器710提供存储器720中存储的程序指令和数据。在本发明实施例中,存储器720可以用于存储绑卡风险控制方法的程序。
处理器710通过调用存储器720存储的程序指令,处理器710用于按照获得的程序指令执行:
接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;
检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;
根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
较佳的,获取所述第一账号和所述第二账号的关联关系,处理器710具体用于:
获取第一账号和第二账号的信息;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标。
较佳的,根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,处理器710具体用于:
确定在至少一个账号关系维度下所述第一账号和第二账号的信息是否满足对应的预设条件,当确定满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,账号关系维度,包括以下至少一种:预设的关键要素、预设的登录环境信息、资金关系和对比活跃度;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,处理器710具体用于:
确定所述第一账号和所述第二账号的预设的关键要素信息是否相同,当确定预设的关键要素信息相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为1,当确定预设的关键要素信息不相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的关键要素信息,表示在账号注册时,验证通过的信息;
确定所述第一账号和所述第二账号的登录设备标识和/或登录IP地址是否相同,当确定相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的登录环境信息,包括登录设备标识和/或登录IP地址;
确定所述第一账号和所述第二账号之间的资金往来状态是否满足预设条件,当确定满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为0;
确定所述第一账号和所述第二账号在预设时间段内是否有行为操作,当确定第二账号在预设时间段内出现行为操作的频率小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定第二账号在预设时间段内出现行为操作的频率不小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率不大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为0。
较佳的,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级,处理器710具体用于:
计算关联关系指标取值为1的个数,当确定所述关联关系指标取值为1的个数不小于预设数目时,确定所述绑卡请求的风险等级为低风险等级,当确定所述关联关系指标取值为1的个数小于预设数目时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,处理器710进一步用于:
获取所述绑卡请求的发送请求时间和所述第一账号的账号标识,根据所述账号标识和所述发送请求时间,将所述绑卡请求的风险等级,以及在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标进行保存。
较佳的,处理器710进一步用于:
若确定所述银行卡被所述支付平台中至少两个第二账号绑定,则分别基于所述第一账号与每一个第二账号,确定所述绑卡请求的风险等级;
当确定至少一个风险等级为低风险等级时,确定所述绑卡请求的风险等级为低风险等级,当确定所有风险等级均为高风险等级时,确定所述绑卡请求的风险等级为高风险等级。
较佳的,根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制,处理器710具体用于:
根据所述绑卡请求的风险等级,采用预设的方式,对所述绑卡请求进行风险控制。
较佳的,处理器710进一步用于:
接收用户通过支付平台发送的获取手机验证码请求,并在执行手机验证码下发流程的同时,启动计算所述绑卡请求的风险等级;或者,
接收用户通过支付平台发送的获取手机验证码请求,并在确定手机验证码验证通过后,启动计算所述绑卡请求的风险等级。
实施例八:
参阅图8所示,本发明实施例八中,一种用户终端的结构示意图。
本发明实施例八提供了一种用户终端,用户终端可以为但不限于手机、平板电脑等。该用户终端可以包括:存储器810、输入模块820、发送模块830、接收模块840、输出模块850、无线通信模块860和处理器870等。具体为:
存储器810可以包括只读存储器(ROM)和随机存取存储器(RAM),并向处理器870提供存储器810中存储的程序指令和数据,还可以存储用户终端的操作系统、应用程序(Application,APP)(例如,支付平台的APP)、模块和用户终端所使用的各种数据等。
输入模块820可以包括键盘、鼠标、触摸屏等,用于接收用户输入的数字、字符信息或触摸操作,以及产生与用户终端的用户设置以及功能控制有关的键信号的输入等,例如,本发明实施例中,输入模块820可以接收用户在用户终端的支付平台上执行的点击操作、输入的银行卡四要素和手机验证码等。
发送模块830可以提供用户终端与服务器之间的接口,例如,本发明实施例中,用于向服务器发送用户的绑卡请求。
接收模块840同样提供用户终端与服务器之间的接口,例如,本发明实施例中,用于接收服务器返回的绑卡请求的审核结果等。
输出模块850可以包括显示模块,如液晶显示器(Liquid Crystal Display,LCD)、阴极射线管(Cathode Ray Tube,CRT)等,其中,显示模块可以用于显示由用户输入的信息或提供给用户的信息,或各种用户终端或支付平台的菜单、用户界面等。例如,本发明实施例中,可以用于向用户展示绑卡请求的审核结果。
无线通信模块860包括但不限于无线保真(wireless fidelity,WiFi)模块、蓝牙模块、红外通信模块等。例如,本发明实施例中,用户终端中接收模块840与发送模块830,向服务器发送绑卡请求并接收服务器返回的绑卡请求的审核结果,是通过wifi模块实现了与服务器之间的通信。
处理器870是用户终端的控制中心,利用各种接口和线路连接整个用户终端的各个部分,通过运行或执行存储在存储器810内的软件程序和/或模块,以及调用存储在存储器810内的数据,执行用户终端的各种功能和处理数据,从而对用户终端进行整体监控。
当然,图8中所示的用户终端的结构,仅仅是其中一种示例,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样,倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (15)
1.一种绑卡风险控制方法,其特征在于,包括:
接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;
检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;
根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
2.如权利要求1所述的方法,其特征在于,获取所述第一账号和所述第二账号的关联关系,具体包括:
获取第一账号和第二账号的信息;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标。
3.如权利要求2所述的方法,其特征在于,根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,具体包括:
确定在至少一个账号关系维度下所述第一账号和第二账号的信息是否满足对应的预设条件,当确定满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为0。
4.如权利要求3所述的方法,其特征在于,账号关系维度,包括以下至少一种:预设的关键要素、预设的登录环境信息、资金关系和对比活跃度;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,具体包括:
确定所述第一账号和所述第二账号的预设的关键要素信息是否相同,当确定预设的关键要素信息相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为1,当确定预设的关键要素信息不相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的关键要素信息,表示在账号注册时,验证通过的信息;
确定所述第一账号和所述第二账号的登录设备标识和/或登录IP地址是否相同,当确定相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的登录环境信息,包括登录设备标识和/或登录IP地址;
确定所述第一账号和所述第二账号之间的资金往来状态是否满足预设条件,当确定满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为0;
确定所述第一账号和所述第二账号在预设时间段内是否有行为操作,当确定第二账号在预设时间段内出现行为操作的频率小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定第二账号在预设时间段内出现行为操作的频率不小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率不大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为0。
5.如权利要求2、3或4所述的方法,其特征在于,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级,具体包括:
计算关联关系指标取值为1的个数,当确定所述关联关系指标取值为1的个数不小于预设数目时,确定所述绑卡请求的风险等级为低风险等级,当确定所述关联关系指标取值为1的个数小于预设数目时,确定所述绑卡请求的风险等级为高风险等级。
6.如权利要求5所述的方法,其特征在于,进一步包括:
获取所述绑卡请求的发送请求时间和所述第一账号的账号标识,根据所述账号标识和所述发送请求时间,将所述绑卡请求的风险等级,以及在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标进行保存。
7.如权利要求5所述的方法,其特征在于,进一步包括:
若确定所述银行卡被所述支付平台中至少两个第二账号绑定,则分别基于所述第一账号与每一个第二账号,确定所述绑卡请求的风险等级;
当确定至少一个风险等级为低风险等级时,确定所述绑卡请求的风险等级为低风险等级,当确定所有风险等级均为高风险等级时,确定所述绑卡请求的风险等级为高风险等级。
8.如权利要求1所述的方法,其特征在于,根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制,具体包括:
根据所述绑卡请求的风险等级,采用预设的方式,对所述绑卡请求进行风险控制。
9.如权利要求1所述的方法,其特征在于,进一步包括:
接收用户通过支付平台发送的获取手机验证码请求,并在执行手机验证码下发流程的同时,启动计算所述绑卡请求的风险等级;或者,
接收用户通过支付平台发送的获取手机验证码请求,并在确定手机验证码验证通过后,启动计算所述绑卡请求的风险等级。
10.一种绑卡风险控制装置,其特征在于,包括:
接收模块,用于接收用户通过支付平台,发送的将银行卡与第一账号绑定的绑卡请求;
关系计算模块,检测所述银行卡是否与所述支付平台中的第二账号绑定,当确定出所述银行卡与所述支付平台中的第二账号绑定时,获取所述第一账号和所述第二账号的关联关系,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级;
风控决策模块,用于根据所述绑卡请求的风险等级,对所述绑卡请求进行风险控制。
11.如权利要求10所述的装置,其特征在于,获取所述第一账号和所述第二账号的关联关系,关系计算模块具体用于:
获取第一账号和第二账号的信息;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,具体为:确定在至少一个账号关系维度下所述第一账号和第二账号的信息是否满足对应的预设条件,当确定满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将相应账号关系维度下所述第一账号与所述第二账号的关联关系指标取值为0。
12.如权利要求11所述的装置,其特征在于,账号关系维度,包括以下至少一种:预设的关键要素、预设的登录环境信息、资金关系和对比活跃度;
根据获取的所述第一账号和第二账号的信息,获取在至少一个账号关系维度下所述第一账号与所述第二账号的关联关系指标,关系计算模块具体用于:
确定所述第一账号和所述第二账号的预设的关键要素信息是否相同,当确定预设的关键要素信息相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为1,当确定预设的关键要素信息不相同时,将在预设的关系要素下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的关键要素信息,表示在账号注册时,验证通过的信息;
确定所述第一账号和所述第二账号的登录设备标识和/或登录IP地址是否相同,当确定相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不相同时,将在预设的登录环境信息下所述第一账号与所述第二账号的关联关系指标取值为0;其中,预设的登录环境信息,包括登录设备标识和/或登录IP地址;
确定所述第一账号和所述第二账号之间的资金往来状态是否满足预设条件,当确定满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为1,当确定不满足预设条件时,将在资金关系下所述第一账号与所述第二账号的关联关系指标取值为0;
确定所述第一账号和所述第二账号在预设时间段内是否有行为操作,当确定第二账号在预设时间段内出现行为操作的频率小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为1,当确定第二账号在预设时间段内出现行为操作的频率不小于第一预设阈值,并且第一账号在预设时间段内出现行为操作的频率不大于第二预设阈值时,将在对比活跃度下所述第一账号与所述第二账号的关联关系指标取值为0。
13.如权利要求11或12所述的装置,其特征在于,根据所述第一账号和所述第二账号的关联关系,确定所述绑卡请求的风险等级,关系计算模块具体用于:
计算关联关系指标取值为1的个数,当确定所述关联关系指标取值为1的个数不小于预设数目时,确定所述绑卡请求的风险等级为低风险等级,当确定所述关联关系指标取值为1的个数小于预设数目时,确定所述绑卡请求的风险等级为高风险等级。
14.如权利要求13所述的装置,其特征在于,关系计算模块进一步用于:
若确定所述银行卡被所述支付平台中至少两个第二账号绑定,则分别基于所述第一账号与每一个第二账号,确定所述绑卡请求的风险等级;
当确定至少一个风险等级为低风险等级时,确定所述绑卡请求的风险等级为低风险等级,当确定所有风险等级均为高风险等级时,确定所述绑卡请求的风险等级为高风险等级。
15.如权利要求10所述的装置,其特征在于,接收模块进一步用于:
接收用户通过支付平台发送的获取手机验证码请求;
关系计算模块,进一步用于在执行手机验证码下发流程的同时,启动计算所述绑卡请求的风险等级;或者,在确定手机验证码验证通过后,启动计算所述绑卡请求的风险等级。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710734945.XA CN109426961B (zh) | 2017-08-24 | 2017-08-24 | 一种绑卡风险控制方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710734945.XA CN109426961B (zh) | 2017-08-24 | 2017-08-24 | 一种绑卡风险控制方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109426961A true CN109426961A (zh) | 2019-03-05 |
CN109426961B CN109426961B (zh) | 2021-08-17 |
Family
ID=65501262
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710734945.XA Active CN109426961B (zh) | 2017-08-24 | 2017-08-24 | 一种绑卡风险控制方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109426961B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110533413A (zh) * | 2019-08-21 | 2019-12-03 | 北京三快在线科技有限公司 | 一种业务执行的系统、方法及装置 |
CN111383025A (zh) * | 2020-03-04 | 2020-07-07 | 支付宝(杭州)信息技术有限公司 | 风控数据转发的方法、装置及电子设备 |
CN113011891A (zh) * | 2021-03-22 | 2021-06-22 | 支付宝(杭州)信息技术有限公司 | 应用于关联支付的核身处理方法及装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101727630A (zh) * | 2009-12-01 | 2010-06-09 | 青岛海信移动通信技术股份有限公司 | 基于rfid技术的移动终端支付系统及方法 |
US20150142667A1 (en) * | 2013-11-16 | 2015-05-21 | Mads Landrok | Payment authorization system |
CN105119886A (zh) * | 2015-07-10 | 2015-12-02 | 腾讯科技(深圳)有限公司 | 账号归属确定方法及装置 |
CN105976180A (zh) * | 2016-04-29 | 2016-09-28 | 宇龙计算机通信科技(深圳)有限公司 | 一种安全支付方法和系统 |
CN107018115A (zh) * | 2016-01-27 | 2017-08-04 | 阿里巴巴集团控股有限公司 | 账户处理方法和装置 |
-
2017
- 2017-08-24 CN CN201710734945.XA patent/CN109426961B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101727630A (zh) * | 2009-12-01 | 2010-06-09 | 青岛海信移动通信技术股份有限公司 | 基于rfid技术的移动终端支付系统及方法 |
US20150142667A1 (en) * | 2013-11-16 | 2015-05-21 | Mads Landrok | Payment authorization system |
CN105119886A (zh) * | 2015-07-10 | 2015-12-02 | 腾讯科技(深圳)有限公司 | 账号归属确定方法及装置 |
CN107018115A (zh) * | 2016-01-27 | 2017-08-04 | 阿里巴巴集团控股有限公司 | 账户处理方法和装置 |
CN105976180A (zh) * | 2016-04-29 | 2016-09-28 | 宇龙计算机通信科技(深圳)有限公司 | 一种安全支付方法和系统 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110533413A (zh) * | 2019-08-21 | 2019-12-03 | 北京三快在线科技有限公司 | 一种业务执行的系统、方法及装置 |
CN111383025A (zh) * | 2020-03-04 | 2020-07-07 | 支付宝(杭州)信息技术有限公司 | 风控数据转发的方法、装置及电子设备 |
CN113011891A (zh) * | 2021-03-22 | 2021-06-22 | 支付宝(杭州)信息技术有限公司 | 应用于关联支付的核身处理方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN109426961B (zh) | 2021-08-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105933266B (zh) | 一种验证方法及服务器 | |
US9558636B1 (en) | Automatic teller machine inventory and distribution system | |
CN105188049B (zh) | 一种虚拟sim卡服务授权方法、终端、服务器以及系统 | |
CN102292932B (zh) | 被动的安全执行 | |
US8666894B1 (en) | Systems and methods for remotely authenticating credit card transactions | |
CN109688186A (zh) | 数据交互方法、装置、设备及可读存储介质 | |
CN109448271A (zh) | 一种无卡取款方法、计算机可读存储介质及服务器 | |
WO2020155839A1 (zh) | 基于区块链对人脸信息进行场景化存证的方法及装置 | |
CN109426961A (zh) | 一种绑卡风险控制方法及装置 | |
CN110838195A (zh) | 授权他人开锁的方法 | |
CN106603327A (zh) | 行为数据分析方法及装置 | |
CN107358763A (zh) | 一种自动取款机验证身份的方法、装置及系统 | |
CN109766152A (zh) | 一种交互方法及装置 | |
CN105992125A (zh) | 一种电子设备安全保护的方法和装置 | |
CN106960385A (zh) | 网贷管理方法、装置及可读存储介质 | |
CN105279694A (zh) | 一种处理用户取款信息的方法及装置 | |
CN107040497A (zh) | 网络账号防盗方法及装置 | |
CN105871840B (zh) | 一种证书管理方法及系统 | |
CN105279414A (zh) | 一种基于指纹应用的验证装置及方法 | |
JP5944891B2 (ja) | ローカル端末と複数の携帯機器との間で通信する携帯通信機器、システムおよび方法 | |
CN105743643A (zh) | 通信安全的检测方法及装置 | |
CA2994833A1 (en) | Systems and methods for interaction authentication using dynamic wireless beacon devices | |
CN107590653A (zh) | 支付方法、终端和系统 | |
KR101232581B1 (ko) | 결제 처리 시스템 및 그 제어방법 | |
KR102272022B1 (ko) | 사용자 인증 방법 및 이를 실행하는 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |