一种用户身份验证方法及系统

本申请涉及金融安全领域，尤其涉及一种用户身份验证方法及系统。

金融互联网行业，在业务前端基于用户操作向业务后端提交业务申请后，业务后端通知验证模块，验证模块会先对用户身份进行风险验证，在验证通过的情况下，业务后端才会响应于业务前端提交的业务申请，如此，能提高用户业务交易过程中的安全性。

然而，上述方法虽能实现金融交易过程中用户身份的安全验证，但由于业务模块和验证模块紧密耦合，导致若想要修改或添加用于安全验证的验证策略，除了需要更新验证模块外，还要花费大量人力和时间维护业务模块。

本申请实施例公开了一种用户身份验证方法及系统，实现了业务模块和验证模块的解耦，提升了业务模块和验证模块的复用率，提高了系统的开发效率。

第一方面，本申请提供了一种用户身份验证方法，应用于包括业务前端、验证前端、业务后端、验证后端和风控端的系统，该方法包括：风控端接收业务后端发送的第一请求；第一请求是业务后端响应于业务前端提交的目标用户的业务申请发送的；风控端根据第一请求对业务申请进行风险评估，获得评估结果；风控端在评估结果为评估未通过时，确定目标用户的验证方式；风控端向验证前端发送第一信息以使验证前端基于验证方式获得目标用户的身份信息，第一信息包括验证方式；风控端接收验证后端发送的第二信息，第二信息包括验证结果，验证结果是验证后端对身份信息进行验证获得的；风控端向业务后端发送验证结果。

上述方法中，通过风控端实现业务模块(包括业务前端和业务后端)和验证模块(包括验证前端和验证后端)的通信，即由风控端告知验证前端验证方式以及由风控端告知业务后端验证后端的验证结果，从而验证模块只需对用户身份进行验证，业务模块只需处理业务，实现了业务模块和验证模块的解耦，提升了业务模块和验证模块的复用率，方便了对验证模块的更新，提高了系统的开发效率。

在第一方面的一种可能的实现方式中，第一信息还包括风控端确定的第一标识，第一标识与目标用户和业务申请对应；第二信息还包括第一标识；风控端接收验证后端发送的第二信息之后，风控端向业务后端发送验证结果之前，方法还包括：风控端添加第一标识和验证结果之间的映射关系至映射信息；风控端接收业务后端发送的第二请求，第二请求包括第一标识；第二请求是业务后端响应于业务前端提交的业务请求和第一标识发送的；相应地，风控端向业务后端发送验证结果，包括：风控端从映射信息中查第一标识对应的验证结果；风控端向业务后端发送第一标识对应的验证结果。

实施上述实现方式，风控端为目标用户的业务申请分配第一标识，第一标识与目标用户和目标用户的业务申请对应，风控端基于第一标识对目标用户进行第二次身份验证，提升了交互过程的安全性。

在第一方面的一种可能的实现方式中，第一标识为令牌token。

实施上述实现方式，以token作为第一标识，提升了第一标识的分配效率，能有效提升交互过程的安全性。

在第一方面的一种可能的实现方式中，在评估结果为评估通过时，该方法还包括：向业务后端发送第三信息以使业务后端对业务申请进行处理，第三信息指示评估结果为评估通过。

实施上述实现方式，在评估结果为评估通过时，业务后端可对业务申请进行处理，加速了对业务申请的响应速度，提高了业务申请的处理效率。

第二方面，本申请提供了一种装置，该装置包括：接收单元，用于接收业务后端发送的第一请求；第一请求是业务后端响应于业务前端提交的目标用户的业务申请发送的；处理单元，用于根据第一请求对业务申请进行风险评估，获得评估结果；处理单元，还用于在评估结果为评估未通过时，确定目标用户的验证方式；发送单元，用于向验证前端发送第一信息以使验证前端基于验证方式获得目标用户的身份信息，第一信息包括验证方式；接收单元，还用于接收验证后端发送的第二信息，第二信息包括验证结果，验证结果是验证后端对身份信息进行验证获得的；发送单元，还用于向业务后端发送验证结果。

第三方面，本申请提供了一种用户身份验证的系统，该系统包括业务前端，用于基于目标用户的操作生成业务申请，并向业务后端发送业务申请；业务后端，用于在接收到业务申请后，向风控端发送第一请求，第一请求用于指示风控端对业务申请进行风险评估；风控端，用于对业务申请进行风险评估获得评估结果，在评估结果为评估未通过时，确定目标用户的验证方式；向验证前端发送第一信息，第一信息包括验证方式；验证前端，用于基于验证方式获得目标用户的身份信息，并将身份信息发送给验证后端；验证后端，用于验证身份信息获得验证结果，并向风控端发送第二信息，第二信息包括验证结果；风控端，还用于接收到第二信息后，向业务后端发送验证结果；业务后端，还用于在验证结果为验证成功时，对业务申请进行处理获得处理结果以及向业务前端发送处理结果。

第四方面，本申请提供了一种计算机可读存储介质，所述计算机可读介质存储用于装置执行的程序代码，所述程序代码包括用于执行第一方面或者第一方面的任一可能的实现方式中的方法的指令。

第五方面，本申请实施例提供了一种装置，该装置包括处理器和存储器，处理器和存储器通过总线连接或者耦合在一起；其中，存储器用于存储程序指令；所述处理器调用所述存储器中的程序指令，以执行第一方面或者第一方面的任一可能的实现方式中的方法。

第六方面，本申请实施例提供了一种计算机软件产品，该计算机程序软件产品包括程序指令，当该计算机软件产品被装置执行时，该装置执行前述第一方面或者第一方面的任一可能的实施例中的所述方法。该计算机软件产品可以为一个软件安装包，在需要使用前述第一方面的任一种可能的设计提供的方法的情况下，可以下载该计算机软件产品并在装置上执行该计算机软件产品，以实现第一方面或者第一方面的任一可能的实施例中的所述方法。

可以看到，实施本申请实施例，通过风控端实现业务模块(包括业务前端和业务后端)和验证模块(包括验证前端和验证后端)的通信，实现了业务模块和验证模块的解耦，提升了业务模块和验证模块的复用率，方便了对验证模块的更新，提高了系统的开发效率。

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是一种交易系统的架构图；

图2是本申请实施例提供的一种系统的架构图；

图3是本申请实施例提供的一种用户身份验证方法的流程图；

图4是本申请实施例提供的又一种用户身份验证方法的流程图；

图5是本申请实施例提供的一种系统的示意图；

图6是本申请实施例提供的一种计算装置的结构示意图。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

需要说明的是，在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

参见图1，图1是一种交易系统的架构图，该系统包括业务模块和验证模块，其中，业务模块包括业务前端和业务后端。在该系统架构下，交易流程一般为：业务前端将用户操作生成的业务申请提交至业务后端，业务后端接收到业务申请后向验证模块发送验证请求，验证请求中包括验证方式(例如，交易码、人脸验证、语音验证等中的一种或多种)，验证模块接收到验证请求后基于验证方式获取用户的相关信息进行验证结果，并将验证结果返回给业务后端，当验证结果为验证通过时，业务后端响应于业务申请，对该次业务申请进行相关处理获得处理结果，并将处理结果发送给业务前端；当验证结果为验证未通过时，业务后端忽略该次业务申请，将验证结果发送给业务前端。

由此可以看出，上述流程中，验证模块和业务模块紧密耦合，当需要对验证方式进行修改或添加时，不仅需要更新验证模块的相关代码，还需要对业务模块涉及到验证方式的相关代码进行更新，更新过程复杂，费时费力，大大降低了验证模块的开发效率。

参见图2，图2是本申请提供的一种系统的架构图，该系统包括：业务前端、业务后端、验证前端、验证后端和风控端。其中，业务前端和业务后端组成业务模块，验证前端和验证后端组成验证模块。

在业务模块中，业务前端和业务后端之间可以通过无线的方式进行通信；在验证模块中，验证前端和验证后端可以通过无线的方式进行通信。对于业务模块与验证模块之间的通信可通过风控端实现。

其中，业务模块仅用于处理业务，具体地，业务前端用于根据用户操作生成业务申请并将业务申请提交至业务后端，业务后端用于在对用户身份验证通过的情况下对业务申请进行相应处理，并将处理结果返回给业务前端。风控端用于评估基于用户操作生成的业务申请的风险以确定是否对用户的身份进行验证以及验证方式(在确定需要对用户的身份进行验证时)，在一些可能的实施例中，风控端还用于接收验证模块发送的验证结果并将验证结果返回给业务模块的业务后端，且验证模块是基于风控端确定的验证方式进行用户的身份验证的。验证模块用于对用户的身份进行验证，具体地，验证前端基于风控端确定的验证方式采集用户的身份信息并将采集到的用户的身份信息发送给验证后端，验证模块用于对接收到的用户的身份信息进行验证，获得验证结果，并将验证结果返回给风控端。

需要说明的是，业务前端和验证前端位于第一服务器，业务后端、验证后端和风控端所在的服务器与第一服务器不同。例如，一具体实施中，业务后端、验证后端和风控端三者均位于第二服务器。另一具体实施中，业务后端和验证后端位于第二服务器，风控端位于第三服务器。但业务后端、验证后端和风控端中任意两者可以位于相同的服务器也可以位于不同的服务器，本申请不做具体限定。由此可以看出，风控端、业务后端、验证后端具有多种部署方式，使得风控端、业务后端、验证后端的部署具有多样性。

基于上文所描述的系统架构，下面描述本申请提供的一种用户身份验证方法，参见图3，图3是本申请提供的一种用户身份验证方法的流程图，该方法包括但不限于以下步骤：

S101、业务前端响应于目标用户的操作，生成业务申请。

在本申请实施例中，目标用户在用户设备的显示界面上执行相应地操作以选择对应的业务，用户设备的业务前端检测到目标用户选择业务的操作，响应于该操作，生成业务申请。其中，业务申请包括目标用户的身份标识号(Identity Document，ID)、用户设备标识、业务标识和业务内容，业务标识与业务一一对应，业务包括账户登陆、转账、基金购买、基金赎回、积分兑换、话费充值、水电缴费、信用卡还款等中的任意一种，本申请不做具体限定。

举例来说，目标用户在用户设备(例如，手机、平板、智能手表等)的显示界面上点击某银行App的“转账”按钮并设置转账金额为伍万元整、对方账户为账户B和转账方式为实时到账，用户设备中的业务前端响应于该操作，生成一条业务申请，该业务申请包括目标用户ID，用户设备标识、转账业务对应的标识以及转账内容，其中，转换内容为“伍万元整人民币转入账户B且实时到账”。需要说明的是，目标用户的操作还可以是滑动、输入、选中拖动等。

S102、业务前端向业务后端发送业务申请。

在本申请实施例中，业务前端将生成的业务申请发送给业务后端。相应地，业务后端接收业务前端发送的业务申请。

S103、业务后端向风控端发送第一请求。

在本申请实施例中，业务后端接收到来自业务前端的业务申请后，向风控端发送第一请求，第一请求用于指示风控端对目标用户的业务申请进行风险评估，以判断目标用户的业务申请是否需要进行用户身份验证以及验证方式(在需要进行用户身份验证的情况下)。

第一请求至少包括业务申请的信息，如目标用户ID、用户设备标识和业务标识。

S104、风控端对业务申请进行风险评估，获得评估结果。

具体地，风控端在接收到第一请求后，第一请求包括目标用户ID、用户设备标识、业务标识和业务内容。风控端从预先建立的风险评估数据库中获取目标用户ID的相关信息，例如，目标用户ID的常用设备、信用分、用户操作习惯信息等，基于目标用户ID的相关信息对目标用户的业务申请进行风险评估，获得评估结果。评估结果包括评估通过和评估未通过中的一种。

需要说明的是，当评估结果为评估通过时，则说明目标用户的业务申请没有风险或者风险较低；当评估结果为评估未通过时，则说明目标用户的业务申请存在一定的风险。

一具体实施中，风控端基于目标用户ID的相关信息对业务申请的风险进行评估获得该业务申请的评分，然后根据业务申请的评分获得评估结果。业务申请的评分可以是第一参数、第二参数和第三参数的加权求和，其中，第一参数用于表示目标用户使用的用户设备的稳定度，当业务申请中的用户设备标识不属于目标用户ID的常用设备时，第一参数记作0，当业务申请中的用户设备标识属于目标用户ID的常用设备时，第一参数表示为1与目标用户ID的常用设备的数量的比值，第一参数越大，用户设备的稳定度越高；第二参数用于表示目标用户的信用度，第二参数可以为目标用户的信用分与预设信用阈值的比值，第二参数越大，目标用户的信用大也越大；第三参数用于表示目标用户的操作相似度，第三参数可以基于业务内容和目标用户的用户操作习惯信息进行计算，第三参数越大，则说明该次业务内容与历史操作习惯越相似。由此可以看出，业务申请的评分越高，该次业务申请存在的风险就越低，因此，当业务申请的评分大于等于第一阈值时，则确定评估结果为评估通过；当业务申请的评分小于第一阈值时，则确定评估结果为评估未通过。需要说明的是，第一阈值由人工经验确定。

在一些可能的实施例中，风控端可以利用人工智能模型基于目标用户ID的相关信息对业务申请的风险进行评估以输出业务申请对应的风险概率，业务申请对应的风险概率越高，业务申请存在的风险也越大。在此情况下，当业务申请对应的风险概率小于等于第二阈值时，则确定评估结果为评估通过；当业务申请对应的风险概率大于第二阈值时，则确定评估结果为评估未通过。需要说明的是，第二阈值由人工经验确定。人工智能模型可以是随机森林算法、卷积神经网络、支持向量机等，本申请不做具体限定。

S105、风控端判断评估结果是否为“评估通过”。

在本申请实施例中，风控端判断评估结果是否为“评估通过”，在评估结果为“评估通过”时，执行S106；在评估结果为“评估未通过”时，执行S109。

S106、风控端向业务后端发送第三信息。

在本申请实施例中，在评估结果为“评估通过”时，风控端向业务后端发送第三信息，第三信息用于指示评估结果为“评估通过”。相应地，业务后端接收第三信息。

S107、业务后端对业务申请进行处理，获得处理结果。

在本申请实施例中，当业务后端接收到第三信息后，响应于业务前端提交的业务申请，业务后端对业务申请进行处理，获得处理结果。

例如，若业务前端提交的业务申请是一条用于转账的业务申请，用于指示将五万元整的人民币金额从本地账户A转入账户B，当业务后端接收到风控端发送的第三信息后，第三信息指示对该业务申请的风险评估的评估结果为评估通过，业务后端才对业务前端提交的业务申请进行处理，即从本地账户A划出五万元整的人民币金额至账户B，将处理结果发送给业务前端，处理结果用于指示本次业务申请已成功处理。

S108、业务后端向业务前端发送处理结果。

在本申请实施例中，业务后端在获得处理结果后，将处理结果发送给业务前端，处理结果用于指示本次业务申请成功处理。

S109、风控端确定目标用户的验证方式。

在本申请实施例中，在评估结果为评估未通过时，则说明目标用户的业务申请存在一定的风险，需要进行后续的身份验证，故风控端为目标用户确定验证方式。其中，验证方式包括指纹验证、人脸验证、交易码验证、虹膜验证、语音验证等中的至少一种。

一具体实施中，风控端可以根据业务申请的评分为目标用户确定验证方式。例如，基于S104中提供的评估方法可以获得业务申请的评分，且业务申请的评分小于第一阈值，风控端可以根据业务申请的评分为目标用户确定至少一种验证方式，且业务申请的评分越低，则风控端为其确定的验证方式的数量就越多。在一些可能的实施例中，风控端还可以预先为各个验证方式设置等级，等级越高，该验证方式的可信度越高，例如，等级设置可以是：虹膜验证>人脸验证>语音验证等。当业务申请的评分越低，则风控端可以选择等级较高的一个或多个验证方式作为目标用户的验证方式。

例如，在业务申请的评分小于第一阈值时，业务申请的评分越低，业务申请存在的风险越大。若业务申请的评分为p1小于第一阈值，风控端确定的目标用户的验证方式为交易码验证；若业务申请的评分为p2，且p2小于p1，风控端确定的目标用户的验证方式包括：交易码验证和人脸验证。

另一具体实施中，风控端可以根据业务申请的风险概率为目标用户确定验证方式。例如，基于S104中提供的评估方法可以获得业务申请的风险概率，且业务申请的风险概率大于第二阈值，风控端可以根据业务申请的风险概率为目标用户确定至少一种验证方式，且业务申请的风险概率越高，则风控端为其确定的验证方式的数量就越多。

S110、风控端向验证前端发送第一信息。

在本申请实施例中，风控端在确定目标用户的验证方式后，风控端向验证前端发送第一信息，第一信息包括验证方式。相应地，验证前端接收来自风控端的第一信息。

在一些可能的实施例中，由于业务前端和验证前端位于同一个服务器中，风控端在确定目标用户的验证方式后，风控端可以向业务后端发送第一信息，第一信息包括验证方式，业务后端接收到第一信息后，业务后端将第一信息发送给业务前端，业务前端接收到第一信息后，业务前端唤起验证前端以使验证前端基于验证方式获取目标用户的身份信息。

S111、验证前端基于验证方式获取目标用户的身份信息。

在本申请实施例中，验证前端基于验证方式获取目标用户的身份信息。身份信息包括人脸图像、指纹信息、交易码、虹膜信息和语音信息等中的至少一种。可以理解，目标用户的身份信息与验证方式对应。

例如，当验证方式为交易码验证时，验证前端调取交易码输入界面在用户设备上显示，以提示目标用户输入交易码(例如，密码)，由此，验证前端即可获取目标用户的交易码。

例如，当验证方式为交易码验证和人脸验证，验证前端除了调取交易码输入界面以获取目标用户的交易码外，验证前端还打开用户设备的前置摄像头，相应地，用户设备的显示界面上显示拍照框提示目标用户将人脸对准拍照框，验证前端即可获取目标用户的人脸图像。

S112、验证前端向验证后端发送身份信息。

在本申请实施例中，验证前端将采集到的目标用户的身份信息发送给验证后端，以使验证后端对身份信息进行验证。相应地，验证后端接收验证前端发送的身份信息。

S113、验证后端验证身份信息获得验证结果。

在本申请实施例中，验证后端接收到验证前端发送的身份信息后，验证后端将身份信息与预设的验证比对数据库中的想关联信息进行比对，若两者一致，则验证结果为验证通过；若两者不一致，则验证结果为验证未通过。

需要说明的是，验证比对数据库中有多个库，例如，人脸比对库、指纹比对库、交易码比对库、虹膜比对库等。验证后端可以根据验证方式从验证比对数据库选择对应的库对身份信息进行验证获得验证结果。

例如，若身份信息为人脸图像，验证后端从验证比对数据库的人脸对比库中获取目标用户ID的标准人脸图像，然后利用算法(例如，神经网络算法)计算验证前端采集到的人脸图像和标准人脸图像之间的匹配度，当匹配度大于等于第三阈值，则确定人脸图像和标准人脸图像一致，故验证结果为验证通过；当匹配度小于第三阈值，则确定人脸图像和标准人脸图像不一致，故验证结果为验证未通过。

S114、验证后端向风控端发送第二信息。

在本申请实施例中，验证后端在获得验证结果后，向风控端发送第二信息，其中，第二信息包括验证结果。相应地，风控端接收验证后端发送的第二信息。

S115、风控端向业务后端发送验证结果。

S116、在验证结果为验证通过时，业务后端对业务申请进行处理获得处理结果。

在本申请实施例中，在验证结果为验证通过时，业务后端对业务申请进行处理获得处理结果。具体步骤可参考S107的相关描述，在此不再赘述。

本申请的一种实施例中，在验证结果为验证未通过时，业务后端向业务前端发送提示信息，提示信息用于指示目标用户的业务申请请求失败。

S117、业务后端向业务前端发送处理结果。本步骤具体可参考S108的相关描述，在此不再赘述。

可以看到，实施本申请实施例，通过风控端实现业务模块(包括业务前端和业务后端)和验证模块(包括验证前端和验证后端)的通信，实现了业务模块和验证模块的解耦，提升了业务模块和验证模块的复用率，方便了对验证模块的更新，提高了系统的开发效率。

参见图4，图4是本申请实施例提供的又一种用户身份验证方法的流程图。需要说明的是，图4实施例可以独立于图3实施例，也可以是对图3实施例的补充。该方法包括但不限于以下步骤：

S201、业务前端响应于目标用户的操作，生成业务申请。本步骤具体可参考S101的相关描述，在此不再赘述。

S202、业务前端向业务后端发送业务申请。本步骤具体可参考S102的相关描述，在此不再赘述。

S203、业务后端向风控端发送第一请求。本步骤具体可参考S103的相关描述，在此不再赘述。

S204、风控端对业务申请进行风险评估，获得评估结果。本步骤具体可参考S104的相关描述，在此不再赘述。

S205、风控端判断评估结果是否为“评估通过”。

在本申请实施例中，风控端判断评估结果是否为“评估通过”，在评估结果为“评估通过”时，执行S206；在评估结果为“评估未通过”时，执行S209。

S206、风控端向业务后端发送第三信息。本步骤具体可参考S106的相关描述，在此不再赘述。

S207、业务后端对业务申请进行处理，获得处理结果。本步骤具体可参考S107的相关描述，在此不再赘述。

S208、业务后端将处理结果发送给业务前端。本步骤具体可参考S108的相关描述，在此不再赘述。

S209、风控端确定目标用户的验证方式以及第一标识。

在本申请实施例中，在评估结果为评估未通过时，风控端需要确定目标用户的验证方式，有关风控端确定目标用户的验证方式的方法具体可参考S109的相关描述，为了说明书的简洁，在此不再赘述。

另外，在评估结果为评估未通过时，风控端还需要确定目标用户的业务申请对应的第一标识。一具体实施中，风控端为目标用户的业务申请分配一个第一标识，且第一标识与目标用户和业务申请对应，换句话说，第一标识唯一表示目标用户以及该次的业务申请。

在一些可能的实施例中，第一标识可以是令牌token，token可以是风控端生成的一串字符串，以使业务前端后续重新提交本次业务申请时带上这个token即可。在另一可能的实施例中，第一标识还可以是风控端生成的随机数，以唯一表示目标用户以及目标用户的业务申请。

S210、风控端经业务后端和业务前端向验证前端发送第一信息。

在本申请实施例中，与S110不同的是，第一信息除了包括验证方式外，第一信息还包括第一标识。具体地，由于业务前端和验证前端位于同一个服务器中，风控端向业务后端发送第一信息，第一信息包括验证方式和第一标识，业务后端接收到第一信息后，业务后端将第一信息发送给业务前端，响应于第一信息，业务前端唤起验证前端以使验证前端基于验证方式获取目标用户的身份信息。

S211、验证前端基于验证方式获取目标用户的身份信息。本步骤具体可参考S111的相关描述，在此不再赘述。

S212、验证前端向验证后端发送身份信息和第一标识。

S213、验证后端验证身份信息获得验证结果。本步骤具体可参考S113的相关描述，在此不再赘述。

S214、验证后端分别向风控端和验证前端发送第二信息。

在本申请实施例中，在验证后端获得验证结果后，验证后端分别向风控端和验证前端发送第二信息，与S114不同的是，第二信息除了包括验证结果外，第二信息还包括第一标识。其中，验证后端向风控端发送第二信息是为了同步验证结果至风控端，验证后端向验证前端发送第二信息是为了反馈验证结果至验证前端以重新唤起业务前端。相应地，风控端接收来自验证后端的第二信息，验证前端接收来自验证后端的第二信息。

需要说明的是，在验证前端接收到验证后端发送的第二信息后，验证前端发起的验证过程已完成，由于验证前端和业务前端位于同一服务器，业务前端被重新唤起。

在一些可能的实施例中，验证后端除了可以同时向验证后端和验证前端发送第二信息外，验证后端也可以先向风控端发送第二信息，再向验证前端发送第二信息，本申请不做具体限定。

S215、风控端将第一标识和验证结果之间的映射关系添加至映射信息。

在本申请实施例中，风控端在接收到验证后端发送的第二信息，在映射信息中添加第二信息中第一标识和第二信息中验证结果之间的映射关系。其中，映射信息中记录了历史已分配的标识以及该标识对应的目标用户的验证结果。

在一些可能的实施例中，映射信息可以是映射信息表。例如，假设第二信息中的第一标识为“a53r2e”，第二信息中的验证结果为“验证通过”，将“a53re-验证通过”这条映射关系添加至表1所示的映射关系表，如表1所示，表1中罗列的两条映射关系，一条“a53r2e-验证通过”是刚刚添加的，另一条“qwe243-验证未通过”历史已添加的，其中，“qwe243”为风控端历史分配的标识，该标识与某用户以及该用户某次的业务申请对应，“验证未通过”为“qwe243”对应的用户的验证结果。

表1

序号 标识 验证结果 1 qwe243 验证未通过 2 a53r2e 验证通过 … … …

S216、业务前端向业务后端发送业务申请和第一标识。

在本申请实施例中，业务前端被重新唤起后，业务前端确定验证前端接收到第二信息，在业务申请未得到业务后端响应的情况下，业务前端重新向业务后端发送业务申请，且此次发送还携带有第一标识。

S217、业务后端向风控端发送第二请求。

在本申请实施例中，业务后端在接收到业务前端发送的业务申请和第一标识后，业务后端向风控端发送第二请求，第二请求包括第一标识，第二请求用于指示风控端确定第一标识对应的验证结果。

S218、风控端从映射信息中查第一标识对应的验证结果。

在本申请实施例中，风控端在接收到业务后端发送的第二请求后，由于映射信息中记录了风控端历史已分配的标识以及该标识对应的目标用户的验证结果，因此，根据第一标识可以从映射信息中查到第一标识对应的验证结果。

例如，假设第二请求中的第一标识为“a53r2e”，映射信息为上述表1所示的映射关系表，从表1中查到第一标识为“a53r2e”对应的验证结果为“验证通过”。

在一些可能的实施例中，风控端从映射信息中未查到第一标识(例如，业务前端发送第一标识的过程中第一标识被恶意篡改)，在此情况下，风控端向业务后端发送第四信息，第四信息用于指示第一标识无效，相应地，业务后端接收到风控端发送的第四信息后，业务后端向业务前端发送提示信息，提示信息用于指示目标用户的业务申请请求失败。

S219、风控端向业务后端发送第一标识对应的验证结果。

S220、在第一标识对应的验证结果为验证通过时，业务后端对业务申请进行处理获得处理结果。

在本申请实施例中，在第一标识对应的验证结果为验证通过时，业务后端对业务申请进行处理获得处理结果。具体步骤可参考S107的相关描述，在此不再赘述。

本申请的一种实施例中，在第一标识对应的验证结果为验证未通过时，业务后端向业务前端发送提示信息，提示信息用于指示目标用户的业务申请请求失败。

S221、业务后端向业务前端发送处理结果。本步骤具体可参考S108的相关描述，在此不再赘述。

可以看出，实施本申请实施例，通过风控端实现业务模块(包括业务前端和业务后端)和验证模块(包括验证前端和验证后端)的通信，实现了业务模块和验证模块的解耦，提升了业务模块和验证模块的复用率，方便了对验证模块的更新，提高了系统的开发效率。另外，风控端基于给用户分配的标识对目标用户进行第二次身份验证，提升了交互过程的安全性。

参见图5，图5是本申请实施例提供的一种系统的示意图，该系统100至少包括多个服务器，且多个服务器的数量最小为2，多个服务器的数量最大为4。上述验证前端、业务前端、业务后端、验证后端以及风控端可分别部署于系统100的服务器中，其中，业务前端和验证前端需部署在同一个服务器中。

不妨以多个服务器的数量为4这种情况进行示例性阐述，但本申请并不限定多个服务器的数量仅为4。当多个服务器的数量为4时，即系统100包括服务器1、服务器2、服务器3和服务器4。其中，上述业务前端和验证前端可部署在服务器1中，业务后端可部署在服务器2中，验证后端可部署在服务器3中，风控端可部署在服务器4中。需要说明的是，业务前端和验证前端所在的服务器1为用户设备，例如，手机、平板、笔记本等可支持无线通信的设备，服务器2、服务器3和服务器4均可以为边缘计算机、或者服务中心计算机，本申请不做具体限定。

在一些可能的实施例时，若系统100仅包括两个服务器，例如，服务器1和服务器2，在此情况下，上述业务前端和验证前端可部署在服务器1中，业务后端、验证后端和风控端均可部署在服务器2中。

在一些可能的实施例中，若系统100包括的服务器的数量为3，例如，服务器1、服务器2和服务器3，其中，上述业务前端和验证前端可部署在服务器1中，业务后端、验证后端和风控端中的任意两者可部署在服务器2，不妨假设业务后端和验证后端部署于服务器2中，则风控端部署在服务器3中。

参见图6，图6是本申请实施例提供的一种计算装置的结构示意图，计算装置30至少包括包括处理器301、存储器302、接收器303和发送器304，该接收器303和发送器304也可以替换为通信接口，用于为处理器301提供信息输入和/或输出。可选的，存储器302、接收器303、发送器304和处理器301通过总线连接或耦合。计算装置30可以是图5中的任意一个服务器。不妨假设计算装置30上仅部署了风控端进行示例性说明。

接收器303用于接收业务后端发送的第一请求以及验证后端发送的验证结果，在一些可能的实施例中，接收器303还用于接收验证后端发送的第二信息以及业务后端发送的第二请求。发送器304用于向业务后端发送第三信息以及验证结果等。接收器303和发送器304可包括用于直接或通过空中接口与其它实体设备通信的天线和芯片集。发送器304和收发器303组成通信模块，通信模块可被配置为根据一个或多个其它类型的无线通信(例如，协议)来接收和发送信息，所述无线通信诸如蓝牙、IEEE 802.11通信协议、蜂窝技术、全球微波互联接入(Worldwide Interoperability for Microwave Access，WiMAX)或LTE(Long Term Evolution，长期演进)、ZigBee协议、专用短程通信(Dedicated Short RangeCommunications，DSRC)以及RFID(Radio Frequency Identification，射频识别)通信，等等。

处理器301执行各操作的具体实现可参考上述方法实施例中对业务申请进行风险评估、确定目标用户的验证方式、确定第一标识、记录第一标识与验证结果的对应关系等具体操作。处理器301可以由一个或者多个通用处理器构成，例如中央处理器(CentralProcessing Unit，CPU)，或者CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路(Application-Specific Integrated Circuit，ASIC)、可编程逻辑器件(ProgrammableLogic Device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(ComplexProgrammable Logic Device，CPLD)、现场可编程门阵列(Field-Programmable GateArray，FPGA)、通用阵列逻辑(Generic Array Logic，GAL)或其任意组合。

存储器302可以包括易失性存储器(Volatile Memory)，例如随机存取存储器(Random Access Memory，RAM)；存储器302也可以包括非易失性存储器(Non-VolatileMemory)，例如只读存储器(Read-Only Memory，ROM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；存储器302还可以包括上述种类的组合。存储器302可以存储程序以及数据，其中，存储的程序包括：风险评估程序(例如，人工智能算法等)、判断程序等，存储的数据包括：第一标识、目标用户ID、业务申请的相关信息等。存储器302可以单独存在，也可以集成于处理器301内部。

在一些可能的实施例中，当计算装置30为上述图5中部署了业务前端和验证前端的服务器时，计算设备30的存储器302存储的程序包括：身份信息采集程序、业务申请生成程序等，存储的数据包括：第一标识、目标用户ID、身份信息等。需要说明的是，计算装置30的存储器302存储的程序和数据与计算装置30上部署的模块相关，本申请不做具体限定。

在一些可能的实施例中，当计算装置30为部署了业务前端和验证前端的服务器时，计算装置30还包括显示屏305，用于显示业务选择接界面以及用于显示验证前端调取的界面以采集目标用户的身份信息。显示屏305可以是液晶显示器(Liquid CrystalDisplay，LCD)、有机或无机发光二极管(Organic Light-Emitting Diode，OLED)、有源矩阵有机发光二极体面板(Active Matrix/Organic Light Emitting Diode，AMOLED)等。

本申请实施例中，当计算装置30为仅图5中仅部署了风控端的服务器时，计算装置30用于实现上述图3实施例所描述的风控端的方法和图4实施例所描述的风控端的方法。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤。

本申请实施例还提供一种计算机程序产品，上述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤。该计算机程序产品可以为一个软件安装包，上述计算机包括电子设备。

需要说明的是，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质包括只读存储器(Read-Only Memory，ROM)、随机存储器(Random AccessMemory，RAM)、可编程只读存储器(Programmable Read-only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、一次可编程只读存储器(One-time Programmable Read-Only Memory，OTPROM)、电子抹除式可复写只读存储(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。

在上述的实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是个人计算机，服务器，或者网络设备、机器人、单片机、芯片、机器人等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

以上对本申请实施例公开的进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。