CN112699353A - 一种金融信息传输方法以及金融信息传输系统 - Google Patents

Abstract

本申请提供了一种金融信息传输方法以及金融信息传输系统，金融风控平台要在对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证通过之后，才能接收请求数据，将对请求数据先加签再加密后得到的请求加密数据发送给数据源，以使每个数据源根据请求加密数据进行解密和验签后得到请求数据，并根据请求数据调用对应的风险评估模型对待查询用户进行风险评估，以得到待查询用户的风险评估结果，对多个风险评估结果进行分析，得到待查询用户的最终查询结果并反馈给请求对象。这样，在金融信息传输的过程中采用平台验证和信息加密的方式，加强了金融风控场景下信息传输的安全性，防止信息在传输的过程中被篡改或丢失。

Description

一种金融信息传输方法以及金融信息传输系统

技术领域

本申请涉及金融风控技术领域，具体而言，涉及一种金融信息传输方法以及金融信息传输系统。

背景技术

随着互联网技术的迅猛发展，金融与互联网的融合是未来的发展趋势。目前，互联网金融已经对传统金融产品和服务等产生了深远的影响，提升了金融行业的运行效率。主要体现在金融风控平台在金融风控场景中的各个应用环节，为用户的个人信息做了安全保护。

现有的金融风控平台在个人信息保护方面，并不是很完善和健全，比如，信息传输的过程中，信息验证简单，有一定的安全隐患，容易造成个人信息泄露，导致金融风控场景下的信息传输的安全性较低。

发明内容

有鉴于此，本申请的目的在于提供一种金融信息传输方法以及金融信息传输系统，在金融信息传输的过程中采用平台验证和信息加密的方式，可以在一定程度上加强金融风控场景下信息传输的安全性，防止信息在传输的过程中被篡改或丢失，从而保证金融信息中涉及的敏感信息能够在安全的金融风控场景下传输。

第一方面，本申请提供了一种金融信息传输方法，所述方法包括：

金融风控平台对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证，其中，所述请求数据包括待查询用户的个人信息；

若所述账号信息验证和所述要素验证均通过，则金融风控平台接收所述请求对象发送的请求数据；

对所述请求数据进行加签，得到所述请求数据的签名；

对所述请求数据和所述签名进行加密，得到所述请求数据对应的请求加密数据；

将所述请求加密数据发送给多个数据源，以使每个数据源根据接收到的请求加密数据进行解密和验签后得到所述请求对象的请求数据，并根据所述请求数据调用对应的风险评估模型对所述待查询用户进行风险评估，以得到所述待查询用户的风险评估结果；

接收多个数据源发送的待查询用户的加密风险评估结果并进行解密，其中，所述加密风险评估结果由所述数据源对风险评估结果进行加签和加密后得到的；

根据多个所述加密风险评估结果解密和验签后得到的风险评估结果，确定所述待查询用户的最终查询结果并进行加密，得到加密最终查询结果；

将所述加密最终查询结果发送给所述请求对象，以使所述请求对象对加密最终查询结果进行解密后得到所述待查询用户的最终查询结果。

优选地，金融风控平台通过以下步骤对请求对象的账号信息进行账号信息验证：

金融风控平台获取请求对象的账号信息；

对所述账号信息分别进行账号权限验证、信息正确性验证和信息可用性验证；

若所述账号权限验证、所述信息正确性验证和所述信息可用性验证均满足金融风控平台的预设账号信息要求，则确定账号信息验证通过；

若所述账号权限验证、所述信息正确性验证和所述信息可用性验证中的任意一项未满足所述预设账号信息要求，则确定账号信息验证未通过。

优选地，金融风控平台通过以下步骤对请求对象发送的请求数据进行要素验证：

金融风控平台获取请求对象发送的待查询用户的个人信息；

对所述待查询用户的个人信息进行信息格式验证和完整性验证；

若所述信息格式验证和所述完整性验证均满足金融风控平台的预设个人信息要求，则确定要素验证通过；

若所述信息格式验证和所述完整性验证中的任意一项未满足金融风控平台的预设个人信息要求，则确定要素验证未通过。

优选地，通过以下步骤对所述待查询用户的个人信息进行完整性验证；

获取所述金融风控平台和所述请求对象之间的共享密钥；

基于所述共享密钥以及所述请求对象发送的待查询用户的个人信息，确定第一消息认证码；

将所述第一消息认证码与所述请求对象预先发送的第二消息认证码进行比对；

若比对结果一致，则确定对所述待查询用户的个人信息的完整性验证通过。

优选地，当所述金融风控平台处于测试时期时，所述方法还包括：

获取请求测试对象的测试账号信息；

基于所述测试账号信息，确定所述金融风控平台对该请求测试对象的平台允许测试条数；

若所述请求测试对象的平台实际测试条数超出所述平台允许测试条数，则限制所述请求测试对象的平台使用权限；

若所述请求测试对象的平台实际测试条数未超出所述平台允许测试条数，开放所述请求测试对象的平台使用权限；或所述请求测试对象的平台实际测试条数在超出所述平台允许测试条数后，接收所述请求测试对象发起的继续使用请求，在所述继续使用请求通过以后，继续开放所述请求测试对象的平台使用权限。

优选地，所述对所述请求数据进行加签，得到所述请求数据的签名，包括：

根据所述请求数据，计算所述请求数据的哈希值；

获取当前时刻的请求数据所对应的当下时间戳；

根据数字证书、所述请求数据的哈希值以及所述当下时间戳，生成所述请求数据的签名。

优选地，所述对所述请求数据进行加签，得到所述请求数据的签名，包括：

对所述请求数据中包括的所有请求参数进行排序，其中，每个所述请求参数中的名称和数值使用等号进行连接；

将所有请求参数按照排序后的顺序进行拼接，得到拼接后的请求数据；

对所述拼接后的请求数据进行哈希计算，得到拼接后的请求数据对应的哈希运算消息认证码；

将所述哈希运算消息认证码的值编码为字符串，得到所述请求数据的签名。

优选地，金融风控平台通过以下步骤获取请求对象的账号信息和请求数据：

金融风控平台对请求对象发送的请求信息进行解密，得到所述请求对象的账号信息和请求数据，其中，所述请求信息通过请求对象对自身的账号信息和请求数据进行加密得到的。

优选地，所述待查询用户的风险评估结果由数据源通过以下方式获得：

对所述金融风控平台的平台信息进行平台信息验证；

若所述平台信息验证通过，则所述数据源接收所述金融风控平台发送的请求加密数据；

对所述请求加密数据进行解密，得到解密后的请求数据和签名；

数据源对解密后的签名进行验签；

若签名验证通过，则所述数据源根据所述请求数据调用对应的风险评估模型，以得到所述风险评估模型对所述待查询用户的风险评估结果。

第二方面，本申请提供了一种金融信息传输系统，所述系统包括金融风控平台和数据源；

所述金融风控平台用于对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证，其中，所述请求数据包括待查询用户的个人信息；若所述账号信息验证和所述要素验证均通过，则金融风控平台接收所述请求对象发送的请求数据；对所述请求数据进行加签，得到所述请求数据的签名；对所述请求数据和所述签名进行加密，得到所述请求数据对应的请求加密数据；将所述请求加密数据发送给多个数据源，以使每个数据源根据接收到的请求加密数据进行解密和验签后得到所述请求对象的请求数据，并根据所述请求数据调用对应的风险评估模型对所述待查询用户进行风险评估，以得到所述待查询用户的风险评估结果；接收多个数据源发送的待查询用户的加密风险评估结果并进行解密，其中，所述加密风险评估结果由所述数据源对风险评估结果进行加签和加密后得到的；根据多个所述加密风险评估结果解密和验签后得到的风险评估结果，确定所述待查询用户的最终查询结果并进行加密，得到加密最终查询结果；将所述加密最终查询结果发送给所述请求对象，以使所述请求对象对加密最终查询结果进行解密后得到所述待查询用户的最终查询结果；

所述数据源用于对所述金融风控平台的平台信息进行平台信息验证；若所述平台信息验证通过，则所述数据源接收所述金融风控平台发送的请求加密数据；对所述请求加密数据进行解密，得到解密后的请求数据和签名；数据源对解密后的签名进行验签；若签名验证通过，则所述数据源根据所述请求数据调用对应的风险评估模型，以得到所述风险评估模型对所述待查询用户的风险评估结果。

第三方面，本申请还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如上述的金融信息传输方法的步骤。

第四方面，本申请还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如上述的金融信息传输方法的步骤。

本申请提供了一种金融信息传输方法以及金融信息传输系统，金融风控平台要在对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证通过之后，才能接收请求对象的请求数据，将对请求数据先加签再加密后得到的请求加密数据发送给数据源，以使每个数据源根据接收到的请求加密数据进行解密和验签后得到请求对象的请求数据，并根据请求数据调用对应的风险评估模型对待查询用户进行风险评估，以得到待查询用户的风险评估结果；金融风控平台对接收到的多个风险评估结果进行综合分析，得到待查询用户的最终查询结果并反馈给请求对象。

这样一来，本申请在金融信息传输的过程中采用平台验证和信息加密的方式，可以在一定程度上加强金融风控场景下信息传输的安全性，防止信息在传输的过程中被篡改或丢失，从而保证金融信息中涉及的敏感信息能够在安全的金融风控场景下传输。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例所提供的一种金融信息传输方法的流程图；

图2为本申请实施例所提供的一种金融风控平台进行信息验证的流程图；

图3为本申请实施例所提供的一种金融风控平台进行完整性验证的流程图；

图4为本申请实施例所提供的一种金融风控平台加签的流程图；

图5为本申请实施例所提供的一种金融信息传输系统的结构示意图；

图6为本申请实施例所提供的一种金融信息传输系统的传输方法流程图；

图7为本申请实施例所提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的每个其他实施例，都属于本申请保护的范围。

首先，对本申请可适用的应用场景进行介绍，本申请可应用于金融风控场景。随着互联网技术的迅猛发展，金融与互联网的融合是大势所趋。互联网金融对传统金融产品、服务等产生了深远的影响，提升了金融行业的运行效率，金融风控平台在金融风控场景中的各个环节，为用户的个人信息做了安全保护。由于风控平台是一种基于大数据分析技术，提供全面、多维度的动态指标体系与行业风控数据模型的完全可定制的平台，可以将其应用在金融风控领域，以提升金融风控方面信息的防护，以及金融领域敏感数据的加密、存储和传输。

以实际的金融风控场景为例，用户A想向银行B借钱，但是银行B不确定能否贷款给用户A，银行B需要向金融风控平台C了解用户A的征信以及消费记录等，所以，银行B的工作人员就会把用户A的身份证号码、银行卡号和手机号等个人信息输入至金融风控平台C上面，就可以从金融风控平台C上获取信息，这里，金融风控平台C本身是没有数据的，需要向数据源D申请获取信息，比如淘宝和京东等电商平台，这些平台上可能保留了一些用户A的个人信息以及消费记录等，金融风控平台C可以请求淘宝发送用户A近期一年的所有消费记录，从而了解用户A每个月的消费记录，每次付费是否正常稳定等，数据源D将获取的这一系列信息发送给风险评估模型E进行评估，风险评估模型E根据这些消费记录，购买记录和物流信息等，可以得到用户A的风险评估结果，然后风险评估模型E将用户A的风险评估结果在返回给数据源D，多个数据源D将用户A的风险评估结果都返回给金融风控平台C进行综合分析处理，得到用户A的最终查询结果，最后，金融风控平台C将用户A的最终查询结果返回给银行B，B银行根据返回的最终查询结果判断用户A的借贷风险，从而决定是否给用户A放贷。

这里，由于在这个信息收发的过程中，多次涉及敏感数据（如消费记录等）以及隐私数据（如身份证号，手机号等）的传输，在信息传输的过程中，信息面临了许多威胁，也具有许多对应的受威胁特性，如：窃听（秘密泄露）对应的机密性，篡改（信息被修改）对应的完整性，伪装（伪装成真正的发送者）对应的认证性，否认（事后称自己没有做）对应的不可否认性，这些威胁都会导致用户信息的安全性得不到保障。即，现有的金融风控平台在个人信息保护方面，并不是很完善和健全，比如，信息传输的过程中，信息验证简单，有一定的安全隐患，容易造成个人信息泄露，导致金融风控场景下的信息传输的安全性较低。

基于此，本申请实施例提供了一种金融信息传输方法以及金融信息传输系统，在信息传输前，平台进行信息验证，在信息传输过程中，对信息进行加密，使得在金融风控这个场景下，结合密码学，可以对个人信息进行安全防护，从而提升信息在金融风控场景下传输的安全性。

请参阅图1，图1为本申请实施例所提供的一种金融信息传输方法的流程图。如图1中所示，本申请实施例提供的金融信息传输方法，包括：

S110、金融风控平台对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证，其中，所述请求数据包括待查询用户的个人信息。

该步骤中，请求对象可以为某个公司或者某个机构，如某银行、公积金管理中心以及借贷公司等。账号信息可以包括请求对象的账号和密码，请求数据可以包括待查询用户的个人信息，如姓名、身份证号和手机号等。

这里，金融风控平台对某个公司或者某个机构发来的请求信息进行解密，得到请求对象的账号信息和请求数据，然后分别对账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证。

S120、若所述账号信息验证和所述要素验证均通过，则金融风控平台接收所述请求对象发送的请求数据。

这里，如果金融风控平台对请求对象发送的账号信息和请求数据的验证都合格，符合平台的预设要求，则金融风控平台可以接收请求对象发送的请求数据。

S130、对所述请求数据进行加签，得到所述请求数据的签名。

该步骤中，对请求数据进行加签，可以在签名前增加时间戳或伪随机数等信息后，再进行签名；也可以直接对请求数据进行签名，无论采用哪种方式，都可以保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。

具体地，本申请实施例中的数字签名技术是将摘要信息用请求对象的私钥加密，与请求数据一起传送给金融风控平台，金融风控平台只有用请求对象的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的请求数据产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的请求数据是完整的，在传输过程中没有被修改，否则说明请求数据被修改过，因此数字签名能够验证信息的完整性。

S140、对所述请求数据和所述签名进行加密，得到所述请求数据对应的请求加密数据。

这里，将请求数据和签名一起进行加密，得到请求加密数据，发送给数据源。其中，本申请实施例中的金融风控平台采用混合加密算法对传输的请求数据进行加密，采用对称加密算法AES对传输的消息进行加密，可以提高数据加密的速度，采用非对称加密算法RSA对对称加密算法中的密钥进行传输，可以保护会话密钥。

进而，对请求数据和签名进行加密，可以保证只有金融风控平台才可以查看这个信息，始终保证数据的安全性；除此之外，还可以保证数据的完整性。

S150、将所述请求加密数据发送给多个数据源，以使每个数据源根据接收到的请求加密数据进行解密和验签后得到所述请求对象的请求数据，并根据所述请求数据调用对应的风险评估模型对所述待查询用户进行风险评估，以得到所述待查询用户的风险评估结果。

该步骤中，金融风控平台对接收到的请求数据进行加签和加密之后，得到请求加密数据并发送给数据源，数据源对接收到的请求加密数据进行解密验签，如果验签通过，则可以根据请求数据调用对应的风险评估模型对待查询用户进行风险评估，从而得到待查询用户的风险评估结果。

这里，数据源可以是淘宝和京东等电商平台，也可以是支付宝和微信等聊天平台，也可以是银行等金融机构等等，由于数据源的种类很多，这里只列举出部分，其他类型不再赘述。

举例说明，金融风控平台向淘宝（数据源）发送请求数据，淘宝会对平台的权限进行验证，可以采用对比签名信息以及用户鉴权的方式等，这里，并不是每个平台都能够拿到淘宝反馈的数据，淘宝也要进行权限筛选和鉴别，看哪个平台有权限，哪个平台能请求到数据。等验证无误后，淘宝会调用对应的风险评估模型，对待查询用户相应的用户标签进行计算，确定待查询用户的风险评估结果，即用户风险分数。

其中，用户标签指的是可以表征待查询用户的属性特征记录，比如，在淘宝上一个月的支出记录，一个月的购买记录，或者是历史上使用过的手机型号，购物的时间，购物的种类，购物的数量以及运费等。

S160、接收多个数据源发送的待查询用户的加密风险评估结果并进行解密，其中，所述加密风险评估结果由所述数据源对风险评估结果进行加签和加密后得到的。

这里，为了保证数据传输的过程中，数据不被篡改和丢失，需要对数据进行加密，进而，在数据源把待查询用户的风险评估结果发送给金融风控平台时，需要先对风险评估结果进行加密，得到加密风险评估结果，然后多个数据源再将其各自的加密风险评估结果发送给金融风控平台。

具体地，这里也可以采用先加签再加密的方式，即与金融风控平台向数据源传输数据的过程相同。

S170、根据多个所述加密风险评估结果解密和验签后得到的风险评估结果，确定所述待查询用户的最终查询结果并进行加密，得到加密最终查询结果。

这里，金融风控平台对接收到的加密风险评估结果进行解密，得到风险评估结果，根据数据源对待查询用户的重要程度，为每个数据源对应的风险评估结果赋予权重值，然后根据权重比例，生成针对待查询用户的最终查询结果。其中，这个最终查询结果可以是一个表征诚信的分数值。

具体地，再将这个最终查询结果反馈给请求对象时，也需要进行加密，得到加密最终查询结果，然后再将加密最终查询结果发送给请求对象，以使请求对象对加密最终查询结果进行解密后得到待查询用户的最终查询结果。

S180、将所述加密最终查询结果发送给所述请求对象，以使所述请求对象对加密最终查询结果进行解密后得到所述待查询用户的最终查询结果。

具体地，步骤S160至步骤S180的数据处理方式与步骤S130至步骤S150的数据处理方式相同，都是采用数据加签加密以及解密验签的安全方式，将加密风险评估结果返回到金融风控平台，金融风控平台对数据源返回的加密风险评估结果进行解密处理、二次建模等操作后，返回加密最终查询结果给请求对象（公司或者机构），其中，在返回待查询用户的最终查询结果时，为了保证数据的安全性，金融风控平台也要对最终查询结果进行加密后，再发送给请求对象。

本申请实施例提供了一种金融信息传输方法，在金融信息传输的过程中采用平台验证和信息加密的方式，可以在一定程度上加强金融风控场景下信息传输的安全性，防止信息在传输的过程中被篡改或丢失，从而保证金融信息中涉及的敏感信息能够在安全的金融风控场景下传输。

请参阅图2，图2为本申请实施例所提供的一种金融风控平台进行信息验证的流程图，如图2中所示，金融风控平台通过以下步骤对请求对象的账号信息进行账号信息验证：

金融风控平台获取请求对象的账号信息；对所述账号信息分别进行账号权限验证、信息正确性验证和信息可用性验证；若所述账号权限验证、所述信息正确性验证和所述信息可用性验证均满足金融风控平台的预设账号信息要求，则确定账号信息验证通过；若所述账号权限验证、所述信息正确性验证和所述信息可用性验证中的任意一项未满足所述预设账号信息要求，则确定账号信息验证未通过。

这里，请求对象指的是金融风控平台的使用用户，比如公司或者机构。账号信息可以为账号和密码等，账号信息可以表征请求对象是否具有平台的使用权限。

具体地，对请求对象的账号信息进行验证（账号信息验证），包括用户的基本信息验证和账号权限验证，基本信息验证包括信息正确性验证（账号密码对不对）、信息可用性验证（以前具有该平台的服务，但是现在服务过期了，就不能对该平台开通权限），账号权限验证包括请求具体的风险评估模型的权限，即根据账号权限能选择调用该平台的哪一个风险评估模型的产品。

进一步地，金融风控平台通过以下步骤对请求对象发送的请求数据进行要素验证：

金融风控平台获取请求对象发送的待查询用户的个人信息；对所述待查询用户的个人信息进行信息格式验证和完整性验证；若所述信息格式验证和所述完整性验证均满足金融风控平台的预设个人信息要求，则确定要素验证通过；若所述信息格式验证和所述完整性验证中的任意一项未满足金融风控平台的预设个人信息要求，则确定要素验证未通过。

这里，要素验证即为验证被查询人的个人信息，包括信息格式验证（不符合平台要求的身份证的信息长度等或是格式不正确）和完整性验证（是否符合系统规定的格式，被查询人的个人信息是否完整、完善，符合风险评估模型要求）。

具体地，请参阅图3，图3为本申请实施例所提供的一种金融风控平台进行完整性验证的流程图，如图3中所示，通过以下步骤对所述待查询用户的个人信息进行完整性验证；

获取所述金融风控平台和所述请求对象之间的共享密钥；基于所述共享密钥以及所述请求对象发送的待查询用户的个人信息，确定第一消息认证码；将所述第一消息认证码与所述请求对象预先发送的第二消息认证码进行比对；若比对结果一致，则确定对所述待查询用户的个人信息的完整性验证通过。

该步骤是使用消息认证码进行完整性验证的过程，可以防止消息进行篡改。金融风控平台可以将发送的信息（待查询用户的个人信息）结合共享密钥，生成消息认证码（Message authentication code，MAC）。其中，数据源或风险评估模型采用相同的方式对接收到的消息（待查询用户的个人信息）进行加密，生成自己的消息认证码。数据源或风险评估模型将接收到的消息认证码（第二消息认证码）和自身计算生成的消息认证码（第一消息认证码）进行对比，如果一致，则认证成功，确定对待查询用户的个人信息的完整性验证通过。

进一步地，如图2所示，当所述金融风控平台处于测试时期时，所述方法还包括：

获取请求测试对象的测试账号信息；基于所述测试账号信息，确定所述金融风控平台对该请求测试对象的平台允许测试条数；若所述请求测试对象的平台实际测试条数超出所述平台允许测试条数，则限制所述请求测试对象的平台使用权限；若所述请求测试对象的平台实际测试条数未超出所述平台允许测试条数，开放所述请求测试对象的平台使用权限；或所述请求测试对象的平台实际测试条数在超出所述平台允许测试条数后，接收所述请求测试对象发起的继续使用请求，在所述继续使用请求通过以后，继续开放所述请求测试对象的平台使用权限。

具体地，如果请求对象处于金融风控平台的测试期间，使用相应的测试账号，平台会对账号的测试条数进行验证，对用户的测试数量进行管控。

具体地，若请求测试对象的平台实际测试条数超出平台允许测试条数，请求测试对象向金融风控平台发起继续使用请求，金融风控平台在接收到该继续使用请求后与请求测试对象进行协商，若协商通过，金融风控平台可以给请求测试对象开通正式账号信息并开放使用权限，以使请求测试对象可以继续使用该平台。

举例说明：该平台上的某些APP只有7天试用期（测试条数是7），试用期过后就要收费，除非进行续费。拥有测试账号的请求测试对象就相当于可以免费的使用7天，7天过后就没有APP的使用权限了，APP也就不对该请求测试对象提供服务了，除非再联系平台加入这个测试账号的条数，或者是决定买入权限转成正式账号，正式账号就不对测试条数进行限制。

除此之外，还可以对请求对象发起消息的IP地址进行验证，判断请求对象是否注册过金融风控平台，防止未知主机访问金融风控平台，提高安全性。

优选地，步骤S130包括：

根据所述请求数据，计算所述请求数据的哈希值；获取当前时刻的请求数据所对应的当下时间戳；根据数字证书、所述请求数据的哈希值以及所述当下时间戳，生成所述请求数据的签名。

这里，时间戳是使用数字签名技术产生的数据，签名的对象包括了原始文件信息、签名参数、签名时间等信息。时间戳系统用来产生和管理时间戳，对签名对象进行数字签名产生时间戳，以证明原始文件在签名时间之前已经存在。

进而，在数据签名时就使用时间戳，使得时间戳与签名一同发送出去，具有一定的客观性和可信性。

请参阅图4，图4为本申请实施例所提供的一种金融风控平台加签的流程图，如图4中所示，步骤S130包括：

对所述请求数据中包括的所有请求参数进行排序，其中，每个所述请求参数中的名称和数值使用等号进行连接；将所有请求参数按照排序后的顺序进行拼接，得到拼接后的请求数据；对所述拼接后的请求数据进行哈希计算，得到拼接后的请求数据对应的哈希运算消息认证码；将所述哈希运算消息认证码的值编码为字符串，得到所述请求数据的签名。

这里，加签指金融风控平台发送请求数据之前，对当前发送的请求数据进行签名，防止伪造。在金融风控平台，加签主要用于请求数据源或风险评估模型时，进行验证。如果验证签名失败，则金融风控平台无法完成数据源或风险评估模型的访问。金融风控平台中的加签主要应用于金融风控平台请求数据源或风险评估模型，以及数据源或风险评估模型返回金融风控平台时的消息传输。

具体地，对要传输的请求数据中的所有请求参数进行排序，参数的格式为JSON格式，其中，排序的顺序可以按照首字母进行；

将每个请求参数中的名称和值使用“=”进行连接；将所有的请求参数使用“&”进行拼接，如：姓名=123&电话号码=234567&身份证号码=2139978596584785904；对拼接后的请求数据采用SHA1算法计算签名，得到哈希运算消息认证码（HMAC），将HMAC值编码为字符串，此字符串即为签名，是一个由数字和字母组成的字符串。

最后，将签名加入到请求数据中，如果请求参数信息发生改变，签名就会发生改变，从而防止信息传输的过程中，有人把信息篡改。

优选地，金融风控平台通过以下步骤获取请求对象的账号信息和请求数据：

金融风控平台对请求对象发送的请求信息进行解密，得到所述请求对象的账号信息和请求数据，其中，所述请求信息通过请求对象对自身的账号信息和请求数据进行加密得到的。

这里，请求对象（公司或者机构）会对待查询用户的信息进行加密发送给金融风控平台，比如身份证号码、姓名、电话号码，以及消费信息等，具体地，以SHA256或者MD5实现的消息摘要的格式封装成消息，经过AES加密后，发送到金融风控平台。

优选地，所述待查询用户的风险评估结果由数据源通过以下方式获得：

对所述金融风控平台的平台信息进行平台信息验证；若所述平台信息验证通过，则所述数据源接收所述金融风控平台发送的请求加密数据；对所述请求加密数据进行解密，得到解密后的请求数据和签名；数据源对解密后的签名进行验签；若签名验证通过，则所述数据源根据所述请求数据调用对应的风险评估模型，以得到所述风险评估模型对所述待查询用户的风险评估结果。

这里，数据源或风险评估模型接收消息后的流程说明如下：

对平台信息进行平台信息验证，包括平台正确性验证和平台可用性验证，即平台的账号密码是否正确，平台是否有使用权限等。平台信息验证通过，数据源接收金融风控平台发送的请求加密数据，然后对该请求加密数据实行解密和验签处理，签名验证的方式是将金融风控平台发送的签名和数据源已有的签名进行对比，如果一致，则签名验证通过，调用相应的风险评估模型，否则，签名验证失败，若签名验证失败，则数据有可能会篡改。

本申请实施例提供的金融信息传输方法，在金融风控方面为了加强信息的防护，以及敏感数据的加密，以及存储和传输等用到了加签验签以及加密解密的处理方式，进而，在金融信息传输的过程中采用平台验证和信息加密的方式，可以在一定程度上加强金融风控场景下信息传输的安全性，防止信息在传输的过程中被篡改或丢失，从而保证金融信息中涉及的敏感信息能够在安全的金融风控场景下传输。

基于同一发明构思，本申请实施例还提供了一种金融信息传输系统，由于本申请实施例中的系统解决问题的原理与本申请实施例上述方法相似，因此系统的实施可以参见方法的实施，重复之处不再赘述。

参阅图5，图5为本申请实施例所提供的一种金融信息传输系统的结构示意图，如图5中所示，金融信息传输系统500包括金融风控平台510和数据源520；

金融风控平台510用于对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证，其中，所述请求数据包括待查询用户的个人信息；若所述账号信息验证和所述要素验证均通过，则金融风控平台接收所述请求对象发送的请求数据；对所述请求数据进行加签，得到所述请求数据的签名；对所述请求数据和所述签名进行加密，得到所述请求数据对应的请求加密数据；将所述请求加密数据发送给多个数据源，以使每个数据源根据接收到的请求加密数据进行解密和验签后得到所述请求对象的请求数据，并根据所述请求数据调用对应的风险评估模型对所述待查询用户进行风险评估，以得到所述待查询用户的风险评估结果；接收多个数据源发送的待查询用户的加密风险评估结果并进行解密，其中，所述加密风险评估结果由所述数据源对风险评估结果进行加签和加密后得到的；根据多个所述加密风险评估结果解密和验签后得到的风险评估结果，确定所述待查询用户的最终查询结果并进行加密，得到加密最终查询结果；将所述加密最终查询结果发送给所述请求对象，以使所述请求对象对加密最终查询结果进行解密后得到所述待查询用户的最终查询结果；

数据源520用于对所述金融风控平台的平台信息进行平台信息验证；若所述平台信息验证通过，则所述数据源接收所述金融风控平台发送的请求加密数据；对所述请求加密数据进行解密，得到解密后的请求数据和签名；数据源对解密后的签名进行验签；若签名验证通过，则所述数据源根据所述请求数据调用对应的风险评估模型，以得到所述风险评估模型对所述待查询用户的风险评估结果。

具体地，请参阅图6，图6为本申请实施例所提供的一种金融信息传输系统的传输方法流程图，如图6中所示，金融风控平台先进行信息验证，只有信息验证通过后，才能接收请求对象发送的请求数据；金融风控平台对接收到的请求数据进行加签和加密操作后得到请求加密数据，将该请求加密数据发送给数据源，数据源需要先进行平台信息验证，只有在平台信息验证通过后才能接收请求加密数据，并对该请求加密数据进行解密和验签操作，根据验签的结果确定是否进行相应模型的调用。

进而，本申请实施例中的请求数据采用SHA256格式和兼容MD5格式进行消息摘要和封装，然后传递的时候进行加密，加密传输到金融风控平台后进行解密，再然后金融风控平台进行一些处理，如加签和加密，再向数据源（比如淘宝京东）等机构传输信息，在传输的时候涉及平台有没有权限，解密，签名验证等，结果返回的时候也要考虑安全隐私问题，以保证数据传输的时候不被修改，丢失和篡改。

本申请实施例提供的金融信息传输系统，在金融信息传输的过程中采用平台验证和信息加密的方式，可以在一定程度上加强金融风控场景下信息传输的安全性，防止信息在传输的过程中被篡改或丢失，从而保证金融信息中涉及的敏感信息能够在安全的金融风控场景下传输。

请参阅图7，图7为本申请实施例所提供的一种电子设备的结构示意图。如图7中所示，所述电子设备700包括处理器710、存储器720和总线730。

所述存储器720存储有所述处理器710可执行的机器可读指令，当电子设备700运行时，所述处理器710与所述存储器720之间通过总线730通信，所述机器可读指令被所述处理器710执行时，可以执行如上述图1所示方法实施例中的金融信息传输方法以及图6所示方法实施例中的金融信息传输系统的传输方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时可以执行如上述图1所示方法实施例中的金融信息传输方法以及图6所示方法实施例中的金融信息传输系统的传输方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种金融信息传输方法，其特征在于，所述方法包括：

金融风控平台对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证，其中，所述请求数据包括待查询用户的个人信息；

若所述账号信息验证和所述要素验证均通过，则金融风控平台接收所述请求对象发送的请求数据；

对所述请求数据进行加签，得到所述请求数据的签名；

对所述请求数据和所述签名进行加密，得到所述请求数据对应的请求加密数据；

将所述请求加密数据发送给多个数据源，以使每个数据源根据接收到的请求加密数据进行解密和验签后得到所述请求对象的请求数据，并根据所述请求数据调用对应的风险评估模型对所述待查询用户进行风险评估，以得到所述待查询用户的风险评估结果；

接收多个数据源发送的待查询用户的加密风险评估结果并进行解密，其中，所述加密风险评估结果由所述数据源对风险评估结果进行加签和加密后得到的；

根据多个所述加密风险评估结果解密和验签后得到的风险评估结果，确定所述待查询用户的最终查询结果并进行加密，得到加密最终查询结果；

将所述加密最终查询结果发送给所述请求对象，以使所述请求对象对加密最终查询结果进行解密后得到所述待查询用户的最终查询结果。

2.根据权利要求1所述的方法，其特征在于，金融风控平台通过以下步骤对请求对象的账号信息进行账号信息验证：

金融风控平台获取请求对象的账号信息；

对所述账号信息分别进行账号权限验证、信息正确性验证和信息可用性验证；

若所述账号权限验证、所述信息正确性验证和所述信息可用性验证均满足金融风控平台的预设账号信息要求，则确定账号信息验证通过；

若所述账号权限验证、所述信息正确性验证和所述信息可用性验证中的任意一项未满足所述预设账号信息要求，则确定账号信息验证未通过。

3.根据权利要求1所述的方法，其特征在于，金融风控平台通过以下步骤对请求对象发送的请求数据进行要素验证：

金融风控平台获取请求对象发送的待查询用户的个人信息；

对所述待查询用户的个人信息进行信息格式验证和完整性验证；

若所述信息格式验证和所述完整性验证均满足金融风控平台的预设个人信息要求，则确定要素验证通过；

若所述信息格式验证和所述完整性验证中的任意一项未满足金融风控平台的预设个人信息要求，则确定要素验证未通过。

4.根据权利要求3所述的方法，其特征在于，通过以下步骤对所述待查询用户的个人信息进行完整性验证；

获取所述金融风控平台和所述请求对象之间的共享密钥；

基于所述共享密钥以及所述请求对象发送的待查询用户的个人信息，确定第一消息认证码；

将所述第一消息认证码与所述请求对象预先发送的第二消息认证码进行比对；

若比对结果一致，则确定对所述待查询用户的个人信息的完整性验证通过。

5.根据权利要求1所述的方法，其特征在于，当所述金融风控平台处于测试时期时，所述方法还包括：

获取请求测试对象的测试账号信息；

基于所述测试账号信息，确定所述金融风控平台对该请求测试对象的平台允许测试条数；

若所述请求测试对象的平台实际测试条数超出所述平台允许测试条数，则限制所述请求测试对象的平台使用权限；

若所述请求测试对象的平台实际测试条数未超出所述平台允许测试条数，开放所述请求测试对象的平台使用权限；或所述请求测试对象的平台实际测试条数在超出所述平台允许测试条数后，接收所述请求测试对象发起的继续使用请求，在所述继续使用请求通过以后，继续开放所述请求测试对象的平台使用权限。

6.根据权利要求1所述的方法，其特征在于，所述对所述请求数据进行加签，得到所述请求数据的签名，包括：

根据所述请求数据，计算所述请求数据的哈希值；

获取当前时刻的请求数据所对应的当下时间戳；

根据数字证书、所述请求数据的哈希值以及所述当下时间戳，生成所述请求数据的签名。

7.根据权利要求1所述的方法，其特征在于，所述对所述请求数据进行加签，得到所述请求数据的签名，包括：

对所述请求数据中包括的所有请求参数进行排序，其中，每个所述请求参数中的名称和数值使用等号进行连接；

将所有请求参数按照排序后的顺序进行拼接，得到拼接后的请求数据；

对所述拼接后的请求数据进行哈希计算，得到拼接后的请求数据对应的哈希运算消息认证码；

将所述哈希运算消息认证码的值编码为字符串，得到所述请求数据的签名。

8.根据权利要求1所述的方法，其特征在于，金融风控平台通过以下步骤获取请求对象的账号信息和请求数据：

金融风控平台对请求对象发送的请求信息进行解密，得到所述请求对象的账号信息和请求数据，其中，所述请求信息通过请求对象对自身的账号信息和请求数据进行加密得到的。

9.根据权利要求1所述的方法，其特征在于，所述待查询用户的风险评估结果由数据源通过以下方式获得：

对所述金融风控平台的平台信息进行平台信息验证；

若所述平台信息验证通过，则所述数据源接收所述金融风控平台发送的请求加密数据；

对所述请求加密数据进行解密，得到解密后的请求数据和签名；

数据源对解密后的签名进行验签；

若签名验证通过，则所述数据源根据所述请求数据调用对应的风险评估模型，以得到所述风险评估模型对所述待查询用户的风险评估结果。

10.一种金融信息传输系统，其特征在于，所述系统包括金融风控平台和数据源；

所述金融风控平台用于对请求对象的账号信息进行账号信息验证以及对请求对象发送的请求数据进行要素验证，其中，所述请求数据包括待查询用户的个人信息；若所述账号信息验证和所述要素验证均通过，则金融风控平台接收所述请求对象发送的请求数据；对所述请求数据进行加签，得到所述请求数据的签名；对所述请求数据和所述签名进行加密，得到所述请求数据对应的请求加密数据；将所述请求加密数据发送给多个数据源，以使每个数据源根据接收到的请求加密数据进行解密和验签后得到所述请求对象的请求数据，并根据所述请求数据调用对应的风险评估模型对所述待查询用户进行风险评估，以得到所述待查询用户的风险评估结果；接收多个数据源发送的待查询用户的加密风险评估结果并进行解密，其中，所述加密风险评估结果由所述数据源对风险评估结果进行加签和加密后得到的；根据多个所述加密风险评估结果解密和验签后得到的风险评估结果，确定所述待查询用户的最终查询结果并进行加密，得到加密最终查询结果；将所述加密最终查询结果发送给所述请求对象，以使所述请求对象对加密最终查询结果进行解密后得到所述待查询用户的最终查询结果；

所述数据源用于对所述金融风控平台的平台信息进行平台信息验证；若所述平台信息验证通过，则所述数据源接收所述金融风控平台发送的请求加密数据；对所述请求加密数据进行解密，得到解密后的请求数据和签名；数据源对解密后的签名进行验签；若签名验证通过，则所述数据源根据所述请求数据调用对应的风险评估模型，以得到所述风险评估模型对所述待查询用户的风险评估结果。

Images