信息处理方法和装置与流程

本发明涉及信息技术，尤其涉及一种信息处理方法和装置。

背景技术：

随着电子商务的不断发展，在线支付业务的应用也越来越广泛。在线支付在给用户带来便捷体验的同时，也有可能导致一些意外损失，比如：当在线支付账户被盗时，盗取账户者会通过交易这种方式获取被盗账户内的余额，从而使得账户的真正持有者遭受损失。

为了尽量减少这种账户被盗给用户所造成的损失，可以对账户投保保险，从而当账户被盗时，账户安全保险会对账户里所有因被盗发生的直接损失进行赔付。

但现有技术中，需要在发生被盗损失之后，需要用户在线下通过人工进行保险理赔申请的审核，所需的人力成本较高。

技术实现要素：

本发明提供一种信息处理方法和装置，用于解决现有技术中保险理赔所需的人力成本较高的技术问题。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，提供了一种信息处理方法，包括：

当从用户端接收到理赔申请时，获取所述用户端根据推荐的异常交易所确定出的待理赔交易；

根据所述理赔申请的待理赔账户和/或所述待理赔交易，识别所述理赔申请的可信度；

根据所述理赔申请的可信度，对所述待理赔交易执行赔付流程。

第二方面，提供了一种信息处理装置，包括：

推荐模块，用于当从用户端接收到理赔申请时，获取所述用户端根据推荐的异常交易所确定出的待理赔交易；

识别模块，用于根据所述理赔申请的待理赔账户和/或所述待理赔交易，识别所述理赔申请的可信度；

执行模块，用于根据所述理赔申请的可信度，对所述待理赔交易执行赔付流程。

本发明实施例提供的信息处理方法和装置，通过当从用户端接收到理赔申请时，获取用户端根据推荐的异常交易所确定出的待理赔交易，进而根据理赔申请的待理赔账户和/或待理赔交易，识别理赔申请的可信度，由于该理赔申请的可信度能够衡量理赔申请存在欺诈骗保的概率，并据此执行赔付流程，从而完成在线审核的步骤，解决了现有技术中仅能够依赖人工进行审核，所导致的保险理赔所需的人力成本较高的技术问题。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例一提供的一种信息处理方法的流程示意图；

图2为在线服务器运行示意图；

图3为本发明实施例二提供的一种信息处理方法的流程示意图；

图4为本发明实施例三提供的一种信息处理装置的结构示意图；

图5为本发明实施例四提供的一种信息处理装置的结构示意图；

图6为信息处理系统的运行原理图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

下面结合附图对本发明实施例提供的信息处理方法和装置进行详细描述。

实施例一

图1为本发明实施例一提供的一种信息处理方法的流程示意图，本实施所提供的信息处理方法用于实现在线理赔，根据图2所示的在线服务器运行示意图，在线服务器与用户端以及保险公司服务器进行交互从而完成在线理赔的过程。具体来说，可以由在线服务器通过与用户端交互识别理赔申请的可信度从而完成在线审核流程，并由在线服务器与保险公司服务器进行交易赔付流程。

用户可以在用户端上通过在线服务器在保险公司为所使用的账户进行投保，进而当账户出现被盗导致账户损失的情况时，该用户同样可以在用户端上，通过在线服务器在保险公司对账户被盗所导致损失的交易进行理赔。

需要说明的是，用户在进行投保和理赔时所使用的用户端可以是相同或者是不同的用户端，本实施例中对此不做限定。

如图1所示，信息处理方法包括：

步骤101、当从用户端接收到理赔申请时，获取用户端根据推荐的异常交易所确定出的待理赔交易。

其中，异常交易为安全性异常的交易，例如：具体可以为账户被盗等安全事件导致损失的交易。

具体的，用户端所发送的理赔申请仅用作通知在线服务器用户端已发起针对待理赔账户的理赔，在理赔申请中包括有待理赔账户的标识，而不包含所申请理赔的待理赔交易的相关信息。

因此，当从用户端接收到理赔申请时，在线服务器需要从待理赔账户已发生交易中，识别出异常交易，进而向用户端发送用于指示异常交易的推荐列表，以使用户端据此从推荐列表中选择出待理赔交易。另外，用户端可以在推荐列表的基础上补充理赔账户的其他已发生交易，提供给在线服务器。

步骤102、根据理赔申请的待理赔账户和/或待理赔交易，识别理赔申请的可信度。

其中，理赔申请的可信度用于指示理赔申请存在欺诈骗保的概率，可信度越高，则理赔申请存在欺诈骗保的概率越低；反之，若可信度越低，则理赔申请存在欺诈骗保的概率越高。

具体的，可以根据理赔申请的待理赔账户和/或待理赔交易的相关信息，利用可信度识别策略对理赔申请的可信度进行识别。其中，可信度识别策略可以包括但不限于：

(1)根据所述待理赔账户的拒保记录，识别所述理赔申请的可信度。当待理赔交易中存在拒保记录时，则会降低理赔申请的可信度，当待理赔账户的拒保记录越多时，理赔申请的可信度越低。反之，当待理赔交易中不存在拒保记录时，则会适当提高理赔申请的可信度。

(2)根据待理赔交易是否为预先识别出的异常交易，识别所述理赔申请的可信度。当待理赔交易中存在不为预先识别出的异常交易时，则会降低理赔申请的可信度，当待理赔交易中不为预先识别出的异常交易越多时，理赔申请的可信度越低。

步骤103、根据理赔申请的可信度，对待理赔交易执行赔付流程。

可以根据理赔申请的可信度，获得理赔申请是否存在欺诈骗保情况审核结论。具体来说，可以预先结合历史经验设定一个可信度的阈值，当理赔申请的可信度低于该阈值时，则认为该理赔申请存在欺诈骗保的情况，拒绝执行赔付流程。反之，若理赔申请的可信度大于或等于该阈值时，则认为该理赔申请存在账户被盗的情况，开始执行赔付流程。

具体的，在线服务器根据理赔申请的可信度获得审核结论之后，将审核结论发送至保险公司服务器，由保险公司方根据该审核结论进行核赔之后，若核赔确定该理赔申请存在欺诈骗保的情况，则向在线服务器返回拒绝执行赔付流程的通知，进而由在线服务器向客户端发送相应的拒绝执行赔付流程的通知。若核赔确定该理赔申请存在账户被盗的情况，则向在线服务器返回执行赔付流程的进度通知，进而由在线服务器向客户端发送相应的执行赔付流程的进度通知。

如图2所示，本实施例中通过当从用户端接收到理赔申请时，获取用户端根据推荐的异常交易所确定出的待理赔交易，进而根据理赔申请的待理赔账户和/或待理赔交易，识别理赔申请的可信度，由于该理赔申请的可信度能够衡量理赔申请存在欺诈骗保的概率，并据此执行赔付流程，从而完成在线审核的步骤，解决了现有技术中仅能够依赖人工进行审核，所导致的保险理赔所需的人力成本较高的技术问题。

实施例二

图3为本发明实施例二提供的一种信息处理方法的流程示意图，本实施例所提供的方法由如图2所示的在线服务器执行，如图3所示，包括：

步骤201、当从用户端接收到理赔申请时，对理赔申请的待理赔账户进行资格验证。

具体的，由于在线理赔仅针对部分用户适用，因此，在用户端发起理赔申请之后，首先执行前置验证过程，以对理赔申请的待理赔账户是否符合理赔资格进行验证。在通过前置验证后可以执行后续步骤，否则拒绝理赔申请，并通知用户端需进行线下理赔。

其中，理赔资格可以对待理赔账户所属用户的信用等级，还可以对待理赔账户所投保的险种进行限制。

例如：可以将理赔资格规定为同时满足待理赔账户所属用户的芝麻信用等级在700以上，待理赔账户所投保的险种为账户被盗安全险。

步骤202、从理赔申请所指示的待理赔账户已发生交易中，识别出异常交易。

具体地，在线服务器针对待理赔账户近期的已完成交易进行识别，将这些交易的交易信息进行输入交易推荐模型，获得风险值，当风险值高于一定限值时，确定交易为被盗导致损失的异常交易。其中，交易信息可以包括交易的对象、交易的环境、交易的金额和交易的时间等等。

这里的交易推荐模型，可以由多个用于计算风险子值的第一子模型和一个计算交易的风险值的第二子模型构成。风险子值用于基于交易的某一方面，例如：交易环境是否安全，交易对象是否安全来评估交易的安全风险，而风险值用于指示交易为被盗导致损失交易的概率。风险值越高，则交易的安全性越差，该交易为被盗导致损失交易的概率越高。

具体的，在模型训练阶段，将作为样本的各条交易的交易信息输入各个第一子模型中分别计算出风险子值，将所计算出的风险子值作为第二子模型的输入参数，结合理赔数据中指示作为样本的每一笔交易是否为被盗交易的标签，对第二子模型进行训练，从而建立二分类或多分类的第二子模型。

在模型的使用阶段，用户端在发起理赔申请并前置验证通过后，在线服务器首先查询用户在最近一段时间内的交易记录，得到已发生交易的交易信息，然后将交易信息，输入各第一子模型实时计算出每一笔交易的各个风险子值，继而将这些风险子值输入第二子模型并在线计算得到每笔已发生交易的风险值；将风险值与业务人员根据经验所设定的阀值进行比较，最终给出每笔已发生交易是否为被盗导致损失的异常交易。

例如，其中一个第一子模型可以通过训练获得如下风险评估策略：基于交易的环境是否安全进行安全风险评估，具体根据交易的环境判断是否在常用的ip和mac地址，采用常用的设备，若未采用常用的设备、ip或mac则认为交易安全风险高，所计算出的风险子值也就是较高。

又例如，其中另一个第一子模型可以通过训练获得如下风险评估策略：可以基于交易的对象是否安全进行风险评估，若交易双方信息中存在黑名单中的用户，则认为交易安全风险高，所计算出的风险子值也就是较高。其中，黑名单用于记录疑似不法分子所使用的用于转移账户余额的账户。

步骤203、根据所识别出的异常交易，向用户端发送推荐列表，以使用户端依据推荐列表确定出待理赔交易。

由于后续还需要根据待理赔交易是否为异常交易识别理赔申请的可信度，因此，作为一种可能的实现方式，可以在推荐列表包括全部异常交易的基础上，引入作为干扰项的其他非异常交易，由用户端从推荐列表中选择出待理赔交易。

另外，作为另一种可能的实现方式，可以在用户端所显示的推荐列表的界面上，设置用于补充其他已发生交易的窗格，从而允许用户端在推荐列表的基础上补充理赔账户的其他已发生交易。在此种方式下，推荐列表中可以仅包括部分异常交易，由用户端补充其他异常交易作为待理赔交易。

步骤204、提示用户端补充提供理赔详细信息，并对用户端进行身份验证。

在用户端依据推荐列表，进行选择和/或补充确定出待理赔交易之后，首先提示用户端补充提供包括账户被盗过程等在内的理赔详细信息，进而后置验证。后置验证是对用户端进行身份验证，以确定当前操作用户端的用户是否为待理赔账户的所属用户，也就是投保保险的用户本人，从而保证所填写资料的有效性。

具体的，可以通过用户端采集用户信息，包括实名认证资料，如证件照片等，以及用户生物特征，如人脸等。

步骤205、在通过身份验证后，从用户端接收依据所述推荐列表所确定出的待理赔交易和理赔详细信息。

步骤206、识别理赔申请的可信度。

具体的，可以根据理赔申请的待理赔账户和待理赔交易的相关信息，利用可信度识别策略对理赔申请的可信度进行识别。在具体实现上，可以将理赔申请的待理赔账户和待理赔交易的相关信息，输入到预先训练好的案件分类器模型中，该案件分类器模型已经训练获得了可信度识别策略，从而经过案件分类器模型进行计算，能够输出理赔申请的可信度的取值。

其中，可信度识别策略可以包括：

根据所述待理赔账户的拒保记录，识别所述理赔申请的可信度。当待理赔交易中存在拒保记录时，则会降低理赔申请的可信度，当待理赔账户的拒保记录越多时，理赔申请的可信度越低。反之，当待理赔交易中不存在拒保记录时，则会适当提高理赔申请的可信度。

根据待理赔交易是否为预先识别出的异常交易，识别所述理赔申请的可信度。当待理赔交易中存在不为预先识别出的异常交易时，则会降低理赔申请的可信度，当待理赔交易中不为预先识别出的异常交易越多时，理赔申请的可信度越低。

步骤207、根据理赔申请的可信度，生成审核结论。

具体的，可以根据理赔申请的可信度，获得理赔申请是否存在欺诈骗保情况审核结论。具体来说，可以预先结合历史经验设定一个可信度的阈值，当理赔申请的可信度低于该阈值时，则认为该理赔申请存在欺诈骗保的情况。反之，若理赔申请的可信度大于或等于该阈值时，则认为该理赔申请存在账户被盗的情况。将理赔申请是否存在欺诈骗保的情况、账户被盗的情况记录到审核结论中。

步骤208、将理赔申请的待理赔账户、待理赔交易和理赔详细信息记录到审核结论中，当保险公司服务器根据审核结论通过核赔后，针对存在账户被盗的情况的理赔申请执行赔付流程。

具体的，在执行赔付流程时，针对存在账户被盗的情况的理赔申请所需赔付的待理赔交易，进行核算赔付金额，将相应的金额赔付至待理赔账户中。

实施例三

图4为本发明实施例三提供的一种信息处理装置的结构示意图，本实施例所提供的装置包括：推荐模块31、识别模块32和执行模块33。

推荐模块31，用于当从用户端接收到理赔申请时，获取所述用户端根据推荐的异常交易所确定出的待理赔交易。

识别模块32，用于根据所述理赔申请的待理赔账户和/或所述待理赔交易，识别所述理赔申请的可信度。

具体地，识别模块32具体用于根据所述待理赔交易是否为预先识别出的异常交易，识别所述理赔申请的可信度。和/或，识别模块32具体用于根据所述待理赔账户的拒保记录，识别所述理赔申请的可信度。

执行模块33，用于根据所述理赔申请的可信度，对所述待理赔交易执行赔付流程。

具体地，执行模块33可以根据理赔申请的可信度，获得理赔申请是否存在欺诈骗保情况审核结论。具体来说，可以预先结合历史经验设定一个可信度的阈值，当理赔申请的可信度低于该阈值时，则认为该理赔申请存在欺诈骗保的情况，拒绝执行赔付流程。反之，若理赔申请的可信度大于或等于该阈值时，则认为该理赔申请存在账户被盗的情况，开始执行赔付流程。

实施例四

图5为本发明实施例四提供的一种信息处理装置的结构示意图，如图5所示，在图4的基础上，推荐模块31包括：识别单元311、发送单元312和接收单元313。

识别单元311，用于从所述待理赔账户已发生交易中，识别出异常交易。

发送单元312，用于向所述用户端发送用于指示所述异常交易的推荐列表。

接收单元313，用于从所述用户端接收所确定出的待理赔交易；所述待理赔交易是所述用户端依据所述推荐列表，进行选择和/或补充所确定出的。

其中，识别单元311包括：评估子单元3111和识别子单元3112。

评估子单元3111，用于根据所述待理赔账户已发生交易的交易信息，利用预先训练的评估模型进行安全风险评估，获得各条已发生交易的风险值。

具体的，评估子单元3111，具体用于利用至少两个第一子模型，对每一条已发生交易进行安全风险评估；利用第二子模型，根据所述至少两个第一子模型所获得的风险子值，计算每一条已发生交易的风险值。

作为一种可能的实现方式，至少两个第一子模型中的一个第一子模型，用于根据交易的对象进行安全风险评估；所述至少两个第一子模型中的另一个第一子模型，用于根据交易的环境进行安全风险评估。

识别子单元3112，用于根据所述风险值，从所述已发生交易中识别出所述异常交易。

进一步，信息处理装置还包括：第一验证模块34和第二验证模块35。

第一验证模块34，用于验证所述待理赔账户是否符合预设的理赔资格。

第二验证模块35，用于根据从所述用户端所获取到的用户信息，对所述用户端进行身份验证。

实施例五

本发明实施例五提供了一种信息处理系统，包括用户端、在线服务器和保险公司服务器。

图6为信息处理系统的运行原理图，如图6所示：

步骤501、用户端向在线服务器发起理赔申请。

具体的，用户端所发送的理赔申请仅用作通知在线服务器用户端已发起针对待理赔账户的理赔，在理赔申请中包括有待理赔账户的标识，而不包含所申请理赔的待理赔交易的相关信息。

步骤502、在线服务器接收到理赔申请后，对用户端进行前置验证。

其中，前置验证过程用以对理赔申请的待理赔账户是否符合理赔资格进行验证。在通过前置验证后可以执行后续步骤，否则拒绝理赔申请，并通知用户端需进行线下理赔。

步骤503、前置验证通过后，在线服务器从待理赔账户已发生交易中，识别出异常交易，进而向用户端发送用于指示异常交易的推荐列表，以及提示用户端填写理赔详细信息。

其中，理赔详细信息包括但不限于：账户被盗过程和/或账户被盗原因。

具体从理赔申请所指示的待理赔账户已发生交易中，识别出异常交易的方法参见前述实施例二中步骤202的相关描述，本实施例中对此不再赘述。

步骤504、用户端依据推荐列表确定出待理赔交易，并填写理赔详细信息。

具体的，用户端可以从推荐列表中选择出待理赔交易，还可以在推荐列表的基础上，对待理赔交易进行补充。在确定出待理赔交易之后，填写理赔详细信息。

步骤505、用户端向在线服务器发送提交请求，以将待理赔交易以及理赔详细信息提交给在线服务器。

步骤506、用户端与在线服务器交互，完成后置验证。

后置验证是对用户端进行身份验证，以确定当前操作用户端的用户是否为待理赔账户的所属用户，也就是投保保险的用户本人，从而保证所填写资料的有效性。

具体的，在线服务器接收到用户端发送的提交请求之后，从用户端获取用户信息，根据所获取到的用户信息进行身份验证。

步骤507、身份验证通过后，在线服务器识别理赔申请的可信度，生成审核结论。

具体的，可以根据理赔申请的可信度，获得理赔申请是否存在欺诈骗保情况审核结论。具体来说，可以预先结合历史经验设定一个可信度的阈值，当理赔申请的可信度低于该阈值时，则认为该理赔申请存在欺诈骗保的情况。反之，若理赔申请的可信度大于或等于该阈值时，则认为该理赔申请存在账户被盗的情况。将理赔申请是否存在欺诈骗保的情况、账户被盗的情况记录到审核结论中。

其中，具体识别理赔申请的可信度的方法，参见前述实施例一中步骤302和实施例二中步骤206的相关描述，本实施例中对此不再赘述。

步骤508、在线服务器向保险公司服务器发送审核结论。

步骤509、保险公司服务器根据审核结论进行核赔。

步骤510、核赔通过时，保险公司向在线服务器发送赔付通知，以通知在线服务器执行赔付流程。

需要说明的是，若核赔不通过，保险公司向在线服务器发送拒赔通知，以通知在线服务器不执行赔付流程。相应地，在线服务器接收到拒赔通知后向用户端发送拒赔提示消息。

步骤511、在线服务器执行赔付流程。

具体的，在线服务器在执行赔付流程时，针对存在账户被盗的情况的理赔申请所需赔付的待理赔交易，进行核算赔付金额，将相应的金额赔付至待理赔账户中。

在以上步骤执行的过程中，在线服务器将这一过程划分为几个进度节点，例如：执行步骤501至步骤508时，为在线服务器审核；执行步骤509至步骤510时，为保险公司服务器核赔；执行步骤511时，为在线服务器赔付。在线服务器对所执行至的进度节点进行监测，从而在用户端请求理赔进度时，向用户端返回所执行至的进度节点。

作为一种可能的应用场景，在保险公司服务器根据审核结论进行核赔时，若发现用户端存在需补充的资料的情况，保险公司服务器可以通过在线服务器对用户端进行通知，具体包括：

步骤512、保险公司服务器向在线服务器发送资料补充通知。

该资料补充通知用于指示所需补充的资料。

步骤513、在线服务器向用户端发送资料补充提示消息。

步骤514、用户端根据资料补充提示消息向在线服务器发送所需补充的资料。

步骤515、在线服务器将所需补充的资料发送至保险公司服务器。

用户可以在用户端上通过在线服务器在保险公司对账户被盗所导致损失的交易进行理赔。具体由在线服务器通过与用户端交互识别理赔申请的可信度从而完成在线审核流程，并由在线服务器与保险公司服务器进行交易赔付流程，解决了现有技术中仅能够依赖人工进行审核，所导致的保险理赔所需的人力成本较高的技术问题。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。