CN115271735A - 代理支付业务场景下的日志分析方法及系统 - Google Patents

Abstract

本发明公开了一种代理支付业务场景下的日志分析方法及系统，日志分析平台根据接收到的关联每笔代理支付业务的唯一交易ID的数量计算指定时间段内的总交易量，并根据关联每笔代理支付业务的交易开始时间和交易结束时间计算每笔代理支付业务的交易耗时，同时根据代理日志判断所关联的代理支付业务是否出现异常，并根据不同的异常类型生成不同的异常日志，以提示代理支付业务的相关方当前的代理支付行为出现异常，以收款方编码‑随机编码为委托方、代理方、收款方三方信息交互的基础媒介，同时基于拉格朗日多项式的插值方法，通过层层递进的分析、判断，实现了对每笔代理支付业务的异常精准识别和定位。

Description

代理支付业务场景下的日志分析方法及系统

技术领域

本发明涉及交易安全监测技术领域，具体涉及一种代理支付业务场景下的日志分析方法及系统。

背景技术

代理支付，即代理方(如集团型财务公司、银行等)接受支付业务发起方(如企业)，将付款单位或付款人在代理方开设的资金存管账户中的资金按约定时间一次或分次划转给收款方的资金结算业务。例如，银行接受企业委托向员工代付工资等。代理支付的流程通常为：支付业务发起方向代理方提供包括收款方名称、收款账号、约定支付时间等收款方信息，代理方指定具体的业务操作人员根据提供的收款方信息生成代理支付订单并经审核人员审核通过后在约定时间向相应收款人划转相应款项。上述现有的代理支付业务中会产生一些代理日志，代理方、支付业务发起方等业务相关方希望基于对这些代理日志的分析能够快速计算出指定时间段内的业务总交易量、交易成功率、每笔代理支付业务的交易耗时等指标值，并希望能够精准识别出代理支付异常行为并对异常点进行精准定位，但目前针对代理支付业务场景能够快速识别异常支付行为并定位的日志分析方法非常少。且上述现有的代理支付流程中，代理方与支付业务发起方的信息交互很少，通常支付业务发起方提供收款方信息后就不再介入后续的代理支付行为，更无法对代理方的代理支付行为是否正确进行验证。但由于代理方生成代理支付订单的过程需要人工核对信息，存在人为介入因素，因此可能出现代理支付错误，比如可能出现将A员工当月待发的10000元工资发放给B员工等错误。

另外，现有的代理支付流程中没有收款方与代理方、支付业务发起方三方通过信息交互以验证代理支付行为是否异常的方案。实际上，三方联动进行信息交互验证需要代理方在三方间开放数据接口，这可能带来新的技术问题——开放的接口可能成为网络攻击的入口，进而给资金安全交易带来风险，这也是目前尚没有通过三方交互验证代理支付行为是否异常的方案出现的主要原因。此外，三方若信息交互过多(比如反复验证判断代理支付行为是否异常等措施)，虽能有效降低代理支付的差错率，但会使得代理支付流程复杂化，进而影响代理支付的及时性。因此，三方间如何进行信息交互、如何平衡三方间的信息交互深度与代理支付及时性的矛盾，以在有效降低代理支付出错率的同时尽可能不对资金交易安全产生影响成为目前代理支付监测技术领域亟待破解的一道难题。

发明内容

本发明以在支付业务发起方(即委托方)、代理方、收款方三方信息交互基础上，通过层层递进分析、判断，快速且准确地监测到代理支付异常行为，并确定异常事由、快速锁定出现异常的责任方，降低代理支付差错率为目的，提供了一种代理支付业务场景下的日志分析方法及系统。

为达此目的，本发明采用以下技术方案：

提供一种代理支付业务场景下的日志分析方法，步骤包括：

M1，日志分析平台采集每笔代理支付业务产生的日志，内容包括关联每笔代理支付业务的唯一交易ID、交易类型、服务接口名称、交易指令编号、交易开始时间、交易结束时间、代理支付业务交易结果返回信息以及日志分析平台根据委托方提供的代理支付对象信息生成的对应每个收款方的代理日志；

M2，所述日志分析平台根据接收到的所述唯一交易ID的数量计算指定时间段内的总交易量，并根据关联每个所述代理支付业务的所述交易开始时间和所述交易结束时间计算每笔所述代理支付业务的交易耗时，并计算交易结果返回状态为“成功”的所述代理支付业务的数量与所述总交易量的比值作为交易成功率，同时根据所述代理日志判断所关联的所述代理支付业务是否出现异常，并根据不同的异常类型生成不同的异常日志，以提示代理支付业务的相关方当前的代理支付行为出现异常；

M3，根据所述日志以及所述异常日志生成日志分析结果以可视化方式展示给用户。

作为优选，步骤M2中，根据所述代理日志判断所关联的所述代理支付业务是否出现异常的方法步骤包括：

S1，所述日志分析平台根据委托方提供的代理支付对象信息生成对应每个收款方的所述代理日志后发送给每个对应的所述收款方；

S2，运行在智能终端上的收款方监测APP解析出所接收的所述代理日志中携带的随机编码后，生成输入框并提示所述收款方在所述输入框中输入其专属的收款方编码；

S3，所述日志分析平台接收到所述收款方输入的所述收款方编码后，通过拉格朗日多项式的插值方法验证其生成的所述随机编码是否正确，以此而建立起所述委托方、代理方和所述收款方三方之间判断代理支付行为是否异常的信息交互，

若验证失败，则判定收款对象出错，并生成第一异常日志推送给所述收款方监测APP和委托方监测平台，并同步显示给代理支付业务操作人员，所述第一异常日志包括对收款对象出错的判定结果、所述收款方输入的第一收款方编码、作为所述日志分析平台生成所述随机编码依据的第二收款方编码以及关联所述第二收款方编码的待代理支付信息；

若验证成功，则不生成所述第一异常日志并终止针对所述收款方的代理支付监测流程。

作为优选，步骤M2中，根据所述代理日志判断所关联的所述代理支付业务是否出现异常的方法还包括步骤：

S4，所述收款方监测APP解析出所述第一异常日志中携带的所述第二收款方编码、所述第一收款方编码后生成提示框推送给所述收款方，所述提示框中显示有所述第二收款方编码并带有输入框，以提示所述收款方再次输入其专属的收款方编码；

S5，当所述收款方再次输入其专属的所述收款方编码后，所述收款方监测APP开始比对所述收款方再次输入的第三收款方编码是否与所述第二收款方编码、所述第一收款方编码一致，

若与所述第二收款方编码比对一致，则判定所述收款方输入所述第一收款方编码时出错，将判定结果生成为第二异常日志推送给所述日志分析平台；

若与所述第一收款方编码比对一致，则判定所述代理方的代理支付对象错误或所述委托方提供的代理支付对象信息出错，然后将所述第一收款方编码、判定结果和所述待代理支付信息生成为第三异常日志推送给所述日志分析平台和所述委托方监测平台。

作为优选4.根据权利要求3所述的代理支付业务场景下的日志分析方法，其特征在于，步骤M2中，根据所述代理日志判断所关联的所述代理支付业务是否出现异常的方法还包括步骤：

S6，所述委托方监测平台解析出所述第三异常日志中携带的所述第一收款方编码和所述待代理支付信息，然后根据所述第一收款方编码与待支付信息的绑定关系，从数据库中匹配出所解析的所述第一收款方编码对应的待支付信息，所述待代理支付信息和所述待支付信息包括支付类型、支付金额和收款人账号；

S7，所述委托方监测平台对所述待代理支付信息和所述待支付信息作信息一致性比对，

若全部比对成功，则判定所述委托方针对所述收款方提供的所述收款方编码错误或所述代理方输入给随机编码生成器的所述第二收款方编码错误，然后将比对结果生成为第四异常日志显示给所述委托方和/或推送给所述日志分析平台；

若任意一项比对失败，则判定所述代理方的代理支付对象错误并生成第一告警信息推送给所述日志分析平台。

作为优选，步骤S7中，当所述收款方编码由所述代理方分配得到时，若所述委托方监测平台判定所述待代理支付信息和所述待支付信息的所有信息项比对成功时，直接判定所述代理方输入给随机编码生成的所述收款方编码出错，并将判定结果生成为第二告警信息推送给所述日志分析平台。

作为优选，步骤S3中，所述收款方输入所述第一收款方编码完成与所述代理方的首次信息交互后，所述日志分析平台验证代理支付行为是否异常的方法步骤包括：

S31，获取随机编码生成器针对每个所述收款方的输入、输出数据，所述随机编码生成器的输入数据为委托方或代理方为每个所述收款对象分配的专属的所述收款人编码，记为UC_x，输出数据为针对每个所述收款人编码所生成的所述随机编码，记为UC_y；

S32，形成每个所述收款方的收款方编码-随机编码数据对(UC_x,UC_y)，然后通过拉格朗日多项式的插值方法并通过以下表达式(1)拟合得到一随机编码曲线：

表达式(1)中，

表示第i个所述收款方编码对应的所述随机编码；

表示第i个所述收款方编码；

表示第j个所述收款方编码；

n表示所述收款对象名单中的所述收款方的数量；

S33，将所述收款方输入的所述第一收款方编码作为UC_x代入到H_n(UC_x)中，得到UC_x对应的拟合结果UC_y′；

S34，判断步骤S2解析得到的所述随机编码是否与UC_y′一致，

若一致，则判定验证成功；

若不一致，则判定验证失败。

作为优选，在步骤S2生成所述输入框以及在步骤S4生成所述提示框之前，还包括针对所述收款方的身份验证过程，验证所述收款方的身份的方法具体包括步骤：

L1，在步骤S2解析出所述代理日志中携带的所述随机编码，以及在步骤S4解析出所述第一异常日志中携带的所述第二收款方编码、所述第一收款方编码后，激活所述智能终端的指纹输入功能，以提示所述收款方触摸指纹输入区域以输入指纹；

L2，所述收款方监测APP从所述代理日志或所述第一异常日志中进一步解析出所携带的关联所述第二收款方编码的具有固定宽、高尺寸的标准指纹图像；

L3，所述收款方监测APP按照预设的空间离散方法，将解析出的所述标准指纹图像离散为若干个矩形块并对每个所述矩形块进行标号；

L4，所述收款方监测APP根据事先确定的每个指纹采集触点与所述标准指纹图像上的每个所述矩形块的空间位置映射关系，搜寻出所述收款方输入指纹时所述智能终端响应的每个触点分别对应的所述矩形块；

L5，从所述标准指纹图像中截取步骤L4搜寻到的各个所述矩形块表征的指纹特征图像，并将截取的各所述指纹特征图像形成为指纹区域图像，然后与采集到的指纹图像作指纹特征比对，

若比对成功，则所述收款方监测APP在步骤S2生成所述输入框，或在步骤S4中生成所述提示框；

若比对失败，则将比对失败结果生成为第五异常日志推送给所述日志分析平台。

作为优选，步骤L3中，将所述标准指纹图像离散为若干个所述矩形块的方法如下：

对所述标准指纹图像的每条边进行等分，得到若干个等分点；

从相互垂直的两条边上的每一个所述等分点引出一条线分别连接至其相对边的相对等分点上，若干条连线相互平行或垂直交织将所述标准指纹图像离散为若干个所述矩形块，然后对每个所述矩形块按由左往右、由上往下方式按序进行标号。

本发明还提供了一种代理支付业务场景下的日志分析系统，可实现所述的代理支付业务场景下的日志分析方法，所述日志分析系统包括相互间通信连接的运行在智能终端上的日志分析平台、收款方监测APP和委托方监测平台，其中，

所述日志分析平台，用于根据委托方提供的代理支付对象信息生成对应每个收款方的代理日志后发送给每个对应的收款方；

所述收款方监测APP，用于在解析出所接收的所述代理日志中携带的随机编码后，生成输入框并提示所述收款方在所述输入框中输入其专属的收款方编码；

所述日志分析平台，还用于在接收到所述收款方输入的所述收款方编码后，通过拉格朗日多项式的插值方法验证其生成的所述随机编码是否正确，以此而建立起所述委托方、代理方和所述收款方三方之间判断代理支付行为是否异常的信息交互，

若验证失败，则判断收款对象出错，并生成第一异常日志推送给所述收款方监测APP和所述委托方监测平台，并同步显示给代理支付业务操作人员，所述第一异常日志包括对收款对象出错的判定结果、所述收款方输入的第一收款方编码、作为所述日志分析平台生成所述随机编码依据的第二收款方编码以及关联所述第二收款方编码的待代理支付信息；

若验证成功，则不生成所述第一异常日志并终止针对所述收款方的代理支付监测流程。

本发明具有以下有益效果：

1、以形成的关联每个收款方的收款方编码-随机编码数据对为委托方、代理方、收款方三方间信息交互以及在代理支付中出现异常时识别异常事由和明确责任方的主线，并基于拉格朗日多项式的插值方法，通过层层递进的分析、判断，最终确定异常事由和出现异常的责任方，通过三方联动实现了对代理支付业务异常的及时、有效监控。

2、由于本发明以收款方编码-随机编码为三方信息交互的媒介，作为交互媒介的数据类型、数据量单一，交互深度可控，平衡了交互深度与代理支付及时性之间的矛盾。

3、生成的代理支付订单中，以随机编码指代具体的收款人，隐匿了收款人信息，一定程度上确保了代理支付交易的安全。

4、利用智能终端的指纹采集触点与在每个收款人对应的标准指纹图像上离散得到的对应矩形块间的空间位置映射关系，针对代理支付监测这一对身份验证准确度要求不高的场景，改进了指纹识别的身份验证方式，使得指纹识别中作为识别依据的指纹特征数据量大幅减少，在兼顾身份验证准确率的同时，有利于促进提升代理支付监测的效率。

附图说明

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

图1是本发明一实施例提供的代理支付业务场景下的日志分析方法的实现步骤图；

图2是本发明一实施例提供的根据代理日志判断所关联的代理支付业务是否出现异常的方法步骤图；

图3是截取与所响应的每个指纹采集触点具有空间位置映射关系的各矩形块表征的指纹特征图像并形成为指纹区域图像的示意图；

图4是本发明一实施例提供的基于在线日志分析的代理支付监测系统的结构示意图。

具体实施方式

下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。

其中，附图仅用于示例性说明，表示的仅是示意图，而非实物图，不能理解为对本专利的限制；为了更好地说明本发明的实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；对本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。

本发明实施例的附图中相同或相似的标号对应相同或相似的部件；在本发明的描述中，需要理解的是，若出现术语“上”、“下”、“左”、“右”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此附图中描述位置关系的用语仅用于示例性说明，不能理解为对本专利的限制，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语的具体含义。

在本发明的描述中，除非另有明确的规定和限定，若出现术语“连接”等指示部件之间的连接关系，该术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个部件内部的连通或两个部件的相互作用关系。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

以下以不同的代理支付场景分别为一个单独的实施例，对本发明提供的基于在线日志分析的代理支付监测方法的具体实现进行说明。

实施例一

本实施例一以员工工资代理支付为应用场景。目前，对于员工工资的代发方式普遍为：企业在银行开立一个专门账户，在每个月的工资发放当日或之前日向银行提供待发放工资的员工名单信息，包括每个员工的员工姓名、员工收款账号、代发工资额等，银行根据收到的员工名单信息生成每个员工的代理支付订单并经相关人员审核通过后，在约定工资发放日从企业专门账户划转指定的代发工资到对应员工的账户。但这种普遍的工资代付方式存在诸如以下的问题：

1、代理支付订单的生成需要银行工作人员人工录入、核对信息，存在出错可能，比如，可能将原本打给A员工的10000元工资错误打入到B员工的账户，或者原本希望打给A员工10000元工资，但银行实际打给A员工1000元工资等，发生类似的资金划转错误后，代理方事后救济需要层层把关、审批，会非常麻烦。

2、企业提供给银行的员工信息同样可能出错，比如，企业希望给以英文字母表示的A-Y总共25个员工发放当月工资，但提供给银行的工资代发员工名单中将上月已离职的员工Z同样纳为工资发放对象，且拟为其发放工资比如5000元。由于银行难以发现类似错误，若银行还是按照错误提供的名单发放工资，将会造成企业5000元的损失，企业后续追偿该笔资金会显得非常被动。

通过现有的工资代发模式代发工资时可能还会出现其他错误。为了避免出现这些错误，多方对代理支付行为是否正确进行验证可能是比较良好地办法。现有的多方验证方法一般仅限于委托方和代理方的信息交互验证，比如代理方为每个收款方生成待代理支付订单后再发回给委托方确认，确认无误后再代发工资，但这种信息交互验证过程人为介入因素过多，验证过程可能还是会出现错误，验证结果也并不一定正确。因此，希望利用技术手段，尽量避免人为介入验证环节，但由于涉及到资金交易安全，代理方(如银行)对外不会轻易开放数据接口，即便开放接口，接入方接入后获取数据的权限也非常有限，因此如何在数据获取权限有限的前提下，通过委托方、代理方、收款方三方的信息交互，实现对代理支付是否出现异常的监测成为代理支付监测技术领域亟待破解的一道难题。

为了解决这个问题，本实施例一以银行代发企业员工工资为例，对本发明提供的代理支付业务场景下的日志分析方法进行详细阐述。如图1所示，该日志分析方法的步骤包括：

M1，日志分析平台采集每笔代理支付业务产生的日志，内容包括关联每笔代理支付业务的唯一交易ID、交易类型、服务接口名称、交易指令编号、交易开始时间、交易结束时间、代理支付业务交易结果返回信息以及日志分析平台根据委托方提供的代理支付对象信息生成的对应每个收款方的代理日志；

M2，日志分析平台根据接收到的唯一交易ID的数量计算指定时间段内的总交易量，并根据关联每个代理支付业务的交易开始时间和交易结束时间计算每笔代理支付业务的交易耗时，并计算交易结果返回状态为“成功”的代理支付业务的数量与总交易量的比值作为交易成功率，同时根据代理日志判断所关联的代理支付业务是否出现异常，并根据不同的异常类型生成不同的异常日志，以提示代理支付业务的相关方当前的代理支付行为出现异常；

M3，根据日志以及异常日志生成日志分析结果以可视化方式展示给用户。

步骤M2中，根据代理日志判断所关联的代理支付业务是否出现异常的方法步骤，如图2所示，具体包括：

S1，日志分析平台(本实施例一中代理方即银行)根据委托方(即企业)提供的代理支付对象信息(即待发工资的员工名单信息)生成对应每个收款方(即员工)的代理日志后发送给每个对应的收款方；

发送给收款方的代理日志为实现委托方、代理方、收款方三方信息交互的基础媒介，由于代理方开放的数据获取权限有限，又同时要确保资金交易安全，因此，代理日志中记载的内容不宜暴露收款方过多信息，但必须又能作为三方验证代理支付行为是否出现异常的依据。为了实现这个目的，本发明通过事先分配给每个收款方专属的收款方编码，并在处理每笔代理支付业务时为每个专属的收款方编码生成随机编码以表征收款方的用户信息。为每个收款方生成对应的随机编码的目的有两个：一是将收款方的收款方编码-随机编码形成的数据对作为代理日志的一项内容，除委托方、代理方和收款方之外的其他人员即便拦截该代理日志也无法根据收款方编码或随机编码知晓该笔代理支付订单的委托方和收款方信息，有利于确保代理支付的资金交易安全；二是本发明以收款方编码-随机编码形成的数据对为三方验证代理支付行为是否异常的主线，收款方编码-随机编码形成的数据对的数据类型单一、数据量较少，三方信息交互深度合理、可控，平衡了三方间信息交互的深度与代理支付及时性的矛盾。

以下对本实施例一如何以收款方编码-随机编码为主线实现三方信息交互，进而验证代理支付行为是否异常的方法进行具体说明：

如图2所示，日志分析平台向每个收款方发送代理日志后转入步骤：

S2，运行在智能终端上的收款方监测APP解析出所接收的代理日志中携带的随机编码后，生成输入框并提示收款方在输入框中输入其专属的收款方编码；

收款方监测APP是为三方验证代理支付行为专门开发的一款智能终端(包括手机、平板电脑等)APP软件。日志分析平台向收款方监测APP推送代理日志后，该收款方监测APP会自动解析出代理日志中携带的随机编码，该随机编码由日志分析平台根据收款方专属的收款方编码通过随机算法随机生成，比如将收款方编码“001”随机生成为“0002”。收款方编码由委托方自行编码或由代理方编码，每个收款方具有唯一且固定不变的收款方编码，比如姓名为“小王”的员工，其专属的收款方编码比如为“001”，这个收款方编码指代的具体收款方，委托方、代理方和收款方三方都清楚，但除此之外的其他人员无法知晓指代人员。由于步骤S1中发送给收款方的代理日志中携带的指代收款人的信息为随机编码，即便该日志被拦截，拦截人员也无法通过随机编码推断出实际的指代人员，由此而保护了收款方隐私不泄露，一定程度上确保了代理支付交易的安全。

日志分析平台生成随机编码的现有方法有许多，因此关于日志分析平台如何为每个收款方编码生成随机编码在此不做说明。需要强调的是，日志分析平台生成随机编码的主要目的不在于保护收款方的隐私数据不泄露，而在于在委托方、代理方和收款方三方之间建立验证代理支付异常行为的信息交互关系，具体方法为：

运行在智能终端上的收款方监测APP解析出所接收的代理日志中携带的随机编码后，生成输入框并提示收款方在输入框中输入其专属的收款方编码，然后转入如图2所示的步骤：

S3，日志分析平台接收收款方输入的收款方编码后，然后通过拉格朗日多项式的插值方法验证其生成的随机编码是否正确，以此而建立起委托方、代理方和收款方三方之间判断代理支付行为是否异常的信息交互，

若验证失败，则判定收款对象出错，并生成第一异常日志推送给收款方监测APP和委托方监测平台，并同步显示给代理支付操作人员，第一异常日志包括对收款对象出错的判定结果、收款方输入的第一收款方编码和作为日志分析平台生成随机编码依据的第二收款方编码以及关联第二收款方编码的待代理支付信息；

若验证成功，则不生成第一异常日志并终止针对该收款方的代理支付监测流程。

以下对日志分析平台在接收到收款方输入的第一收款方编码完成与收款方的首次信息交互后，验证代理方的代理支付行为是否异常的过程通过举例进行详细说明：

假设，作为代理方的某银行需要在20日这一工资发放当日为某企业的A、B、C、D、E总共5名员工代发工资，代理方或委托方事先为这5名员工分别分配了专属的收款方编码，假设收款方编码分别为：001、002、003、004和005，在操作代理支付业务时，日志分析平台假设为001、002、003、004和005这5个收款方编码分别生成了0005、0004、0003、0002、0001这5个随机编码，即员工A在这次代理支付行为中的收款方编码-随机编码数据对为(001、0005)，员工B的收款方编码-随机编码数据对为(002,0004)，员工C的收款方编码-随机编码数据对为(003,0003)，员工D的收款方编码-随机编码数据对为(004,0002)，员工E的收款方编码-随机编码数据对为(005,0001)。

然后，通过拉格朗日多项式的插值方法，基于所形成的各组收款方编码-随机编码数据对并通过以下表达式(1)拟合得到一随机编码曲线：

表达式(1)中，

表示第i个收款方编码对应的随机编码；

表示第i个收款方编码；

表示第j个收款方编码；

n表示收款对象名单中的收款方的数量；

将上述5个员工的收款方编码-随机编码数据对代入到上述表达式中，H_n(UC_x)表达如下：

由H₅(UC_x)可以得到一条拟合曲线，然后将接收到的收款方输入的收款方编码代入到H₅(UC_x)中，可以得到输入的该收款方编码对应的拟合结果UC_y′。

最后判断，拟合得到的UC_y′与步骤S2中解析出的随机编码是否一致，

若一致，则判定验证成功；

若不一致，则判定验证失败。

验证失败可能有以下3个原因：1、委托方提供的收款方编码本身是错误的，比如把员工A专属的收款方编码“001”误写为“002”，而代理方因此生成了“002”对应的随机编码，并将包含有该误生成的随机编码的代理日志推送给了员工A，此时，员工A输入其专属的收款人编码“001”后，拟合得到的随机编码与此前生成的随机编码将出现不一致的情况，所以可以验证委托方出现的该种代理支付异常情况。2、代理方输入给随机编码生成器的收款方编码出错，比如委托方提供的收款方编码为“001”，但代理支付业务操作人员误将“001”看成“007”输入给随机编码生成器，生成的随机编码与根据A员工输入的“001”拟合得到的随机编码会出现不一致的情况，因此也可以验证在代理方出现的该种代理支付异常情况。3、收款方输入的收款方编码有误。比如，分配给A员工的真实收款方编码为“001”，但A员工为新入职员工，由于记忆出错，误认为其专属的收款方编码为“002”，此时其在步骤S2中输入第一收款方编码后，拟合得到的随机编码自然与代理方通过随机编码生成器生成的随机编码不一致，因此也可以验证收款方出现的该种代理支付异常情况。

为了区分可能出现在委托方、代理方、收款方的这3种代理支付异常情况，优选地，本实施例一提供的基于在线日志分析的代理支付检测方法如图2所示，还包括步骤：

S4，收款方监测APP解析出第一异常日志中携带的第二收款方编码、第一收款方编码后生成提示框推送给收款方，提示框中显示有第二收款方编码并带有输入框，以提示收款方再次输入其专属的收款方编码；

比如，在提示框中的输入框的上方显示有日志分析平台认定的该收款方专属的“002”这一第二收款方编码(即日志分析平台作为生成该收款方的随机编码依据的收款方)，该收款方看到显示的该第二收款方编码后会下意识核对分配给自己的专属的收款方编码是否为显示的“002”。

S5，当收款方再次输入其专属的收款方编码后，收款方监测APP开始比对收款方再次输入的第三收款方编码是否与第二收款方编码、第一收款方编码一致，

若与第二收款方编码比对一致，则判定收款方输入第一收款方编码时出错，将判定结果生成为第二异常日志推送给日志分析平台；

若与第一收款方编码比对一致，则判定代理方的代理支付对象错误或委托方提供的代理支付对象信息出错，然后将第一收款方编码、判定结果和待代理支付信息生成为第三异常日志推送给日志分析平台和委托方监测平台。

这里需要说明的是，步骤S5中，若第三收款方编码与第二收款方编码、第一收款方编码比对均不一致时，代表收款方前后两次输入的收款方编码(即第一收款方编码与第三收款方编码不一致，此时收款方监测APP将会立即生成提示信息提示收款方编码输入错误需要重新进行输入)。

代理方接收到第二异常日志后即可知晓此次代理支付异常告警为收款方输入收款方编码时出错。委托方和代理方接收到第三异常日志后可知晓可能是提供给代理方的代理支付对象信息有误，也可能是代理方输入代理支付对象时出错，委托方和代理方根据第三异常日志进行线上或线下沟通后即可排查出究竟哪个环节出现了哪种代理支付异常的情况。

但线上或线下排查的方式不够智能，当代理支付异常情况出现较多时，来回沟通对确保代理支付的及时性带来极大影响，因此希望通过技术手段来解决这个问题。为了解决这个问题，优选地，本实施例提供的基于在线日志分析的代理支付监测方法还包括步骤：

S6，委托方监测平台解析出第三异常日志中携带的第一收款方编码和待代理支付信息，然后根据第一收款方编码与待支付信息的绑定关系，从数据库中匹配出所解析的第一收款方编码对应的待支付信息，待代理支付信息和待支付信息包括支付类型(如工资代发)、支付金额和收款人账号；

S7，委托方监测平台对待代理支付信息和待支付信息作信息一致性比对，

若全部比对成功，则判定委托方提供的该收款方的收款方编码错误或代理方输入给随机编码生成器的第二收款方编码错误，然后将比对结果生成为第四异常日志显示给委托方和/或推送给日志分析平台，委托方根据第四异常日志的提示自主去验证提供给代理方的收款方编码是否错误。当收款方编码由代理方分配时，此时便可直接判定是代理方输入给随机编码生成器的收款方编码错误，委托方监测平台此时直接将第四异常日志推送给日志分析平台，由代理方去核对输入的收款方编码是否出错；

若任意一项比对失败，则判定代理方的代理支付对象错误并生成第一告警信息推送给日志分析平台。

综上，在本实施例一中，以形成的关联每个收款方的收款方编码-随机编码数据对为委托方、代理方、收款方三方间信息交互以及在代理支付中出现异常时识别异常事由和明确责任方的主线，并基于拉格朗日多项式的插值方法，通过层层递进的分析、判断，最终确定异常事由和出现异常的责任方，通过三方联动实现了对代理支付业务异常的及时、有效监控。且由于本发明以收款方编码-随机编码为三方信息交互的基础媒介，以代理方生成的待代理支付信息和委托方事先录入的待支付信息为辅助媒介，作为交互媒介的数据量单一，交互深度可控，平衡了交互深度与代理支付及时性之间的矛盾。且生成的代理支付订单中，以随机编码指代具体的收款人，隐匿了收款人信息，一定程度上确保了代理支付交易的安全。

需要说明的是，实施例一中虽强调了应用场景为银行对企业的工资代发，但实施例一提供的监控代理支付异常行为的技术方案不仅限于应用在该场景。其他类似的场景，比如票据承兑等场景均可以应用该技术方案进行代理支付异常监控。

实施例二

实施例一提供的技术方案其实存在一个问题：收款方不需要进行身份验证在步骤S2生成的输入框或步骤S4生成的提示框中可直接输入其专属的收款方编码，但日志分析平台、收款方监测APP和委托方监测平台均无法判断输入收款方编码的是否真实为收款方本人，对于收款人在代理支付监测中的行为异常监控比较困难。比如，假设输入收款方编码的为非收款方本人，后续所有的代理支付监测行为都会出错，不仅达不到监测效果，还额外给委托方、代理方、收款方增添了不必要的麻烦。所以为了解决这个问题，在本实施例二中，在步骤S2和步骤S4的收款方编码输入环节增加了对编码输入人员的身份验证。

身份验证目前应用较为成熟的有指纹识别、虹膜识别、人脸图像识别等技术。但现有的身份识别方法对于身份的识别、验证比较全面，比如，当人脸识别验证通过后才能够进入手机操作界面，此时才能够对手机各项功能进行操作，类似的身份识别场景对于身份验证的准确度要求非常高，因为一旦识别错误可能出现资金被盗刷等难以挽回的后果，所以这些身份识别场景需要捕捉、比对的身份细节特征比较多，身份验证的算法也相对复杂，通常会出现要求多次重复验证的情况。但在代理支付的应用场景中，对于支付对象是否正确以及代理支付操作行为是否规范等在委托方提供支付对象名单、代理方制作代理支付订单时已作了初步的核验，出现代理支付异常的情况相对较少，比如委托方在提供给代理方的代理支付对象名单时一般具有核验机制，代理方在生成代理支付订单时同样具有更为严格的核验机制，通常不会出错，因此在步骤S2和步骤S4收款方输入专属的收款方编码之前增加对其身份的验证，主要目的是为了防止非收款人本人与委托方、代理方的信息交互可能对后续代理支付异常监控流程产生的不良影响，相对于身份验证的准确度，本实施例二中更加注重对收款人的身份验证速度，进而确保对整个代理支付异常监测的效率。

为了满足上述的身份验证需求，本实施例二中抛弃了人脸识别和虹膜识别等因需要捕捉较多细节特征，识别速度相对较低，且容易出现要求二次识别的身份验证方案，而利用指纹因每次点按输入的特征不同且且输入指纹特征数量相对较少的特点，对现有的指纹识别方式作了进一步改进，在基本保证指纹识别准确率的前提下，更加注重提升指纹识别的速度，进而确保代理支付监测的效率。

本实施例二中改进的指纹识别方法具体包括步骤：

L1，在步骤S2解析出代理日志中携带的随机编码以及在步骤S4解析出第一异常日志中携带的第二收款方编码和第一收款方编码后，激活智能终端的指纹输入功能，以提示收款方触摸指纹输入区域以输入指纹；

L2，收款方监测APP从代理日志或第一异常日志中进一步解析出所携带的关联第二收款方编码的具有固定宽、高尺寸的标准指纹图像(即代理方认定的收款方的标准指纹图像)；标准指纹图像为该收款方事先录入并提供给代理方的完整指纹图像，包含了某个手指所有点位的所有指纹特征；

L3，收款方监测APP按照预设的空间离散方法，将解析出的标准指纹图像离散为若干个矩形块并对每个矩形块进行标号，离散方法具体为：

对如图3中的b图所示的标准指纹图像的每条边进行等分，得到若干个等分点10；

然后，从相互垂直的两条边(如图3中的b图所示的边b1、b2)上的每一个等分点10引出一条线s1分别连接至其相对边的相对等分点上，若干条连线s1相互平行或垂直交织将标准指纹图像离散为若干个矩形块，然后对各个矩形块按由左往右、由上往下方式按序进行标号。

L4，收款方监测APP根据事先确定的每个指纹采集触点与标准指纹图像上的每个矩形块的空间位置映射关系，搜寻出收款方输入指纹时智能终端响应的每个触点分别对应的矩形块；例如，事先确定图3中的a图中的触点1与图3中的b图中的标序为“10”的矩形块具有空间位置映射关系；触点2与标序为“11”的矩形块具有空间位置映射关系；触点3与标序为“14”的矩形块具有空间位置映射关系；触点4与标序为“15”的矩形块具有空间位置映射关系。

L5，从标准指纹图像中截取步骤L4搜寻到的各个矩形块表征的指纹特征图像，并将截取的各指纹特征图像形成为指纹区域图像，然后与采集到的指纹图像作指纹特征比对，

若比对成功，则收款方监测APP在步骤S2生成输入框，或在步骤S4中生成提示框；

若比对失败，则将比对失败结果生成为第五异常日志推送给日志分析平台，日志分析平台接收到第五异常日志后即可知晓当前操作智能终端的并非为第二收款方编码对应的收款人本人。

这里需要说明的是，为了提升所截取的指纹区域图像与采集的指纹图像的比对准确率，可以对截取区域进行扩增后再进行指纹比对，比如将原本截取图3的b图中所示的10、11、14、15标号的矩形块扩增为截取1-16标号的矩形块并形成指纹区域图像后(标号10、11、14、15的的指纹特征图像在指纹区域图像中的位置保持不变)进行指纹比对。

本实施例二中，通过事先确定的每个指纹采集触点与在标准指纹图像上离散的矩形块的空间位置映射关系，从标准指纹图像上截取具有空间位置映射关系的矩形块构成指纹区域图像与采集的指纹图像进行指纹特征比对，由于参与比对的指纹区域图像相交完整的标准指纹图像尺寸大幅减少，抛弃了部分指纹细节特征，使得指纹比对过程更加快速。同时，通过为每个指纹采集触点与标准指纹图像中的相应矩形块建立空间位置映射关系，能够快速且较为精准地截取到采集的指纹部位在标准指纹图像上的指纹特征，不仅加快了指纹比对速度还一定程度上确保了指纹比对的准确率，适于在代理支付监测这种对身份验证准确度要求相对宽松的场景中使用。

本发明还提供了一种代理支付业务场景下的日志分析系统，可以实现上述的日志分析方法，如图4所示，该日志分析系统包括相互间通信连接的运行在智能终端(如PC、平板电脑、手机等)上的日志分析平台、收款方监测APP和委托方监测平台，其中，

日志分析平台，用于根据委托方提供的代理支付对象信息生成对应每个收款方的代理日志后发送给每个对应的收款方；

收款方监测APP，用于在解析出所接收的代理日志中携带的随机编码后，生成输入框并提示收款方在输入框中输入其专属的收款方编码；

日志分析平台，还用于在接收到收款方输入的收款方编码后，通过拉格朗日多项式的插值方法验证其生成的随机编码是否正确，以此而建立起委托方、代理方和收款方三方之间判断代理支付行为是否异常的信息交互，

若验证失败，则判定收款对象出错，并生成第一异常日志推送给收款方监测APP和委托方监测平台，并同步显示给代理支付业务操作人员，第一异常日志包括对收款对象出错的判定结果、收款方输入的第一收款方编码、作为日志分析平台生成随机编码依据的第二收款方编码以及关联第二收款方编码的待代理支付信息；

若验证成功，则不生成第一异常日志并终止针对该收款方的代理支付监测流程。

关于代理支付监测系统以形成的收款方编码-随机编码数据对为代理支付异常监测的主线，通过层层递交分析、判断出现的代理支付异常事由及识别出相关责任方的方法在上述的代理支付监测方法中作了非常详细的说明，在此不再赘述。

需要声明的是，上述具体实施方式仅仅为本发明的较佳实施例及所运用技术原理。本领域技术人员应该明白，还可以对本发明做各种修改、等同替换、变化等等。但是，这些变换只要未背离本发明的精神，都应在本发明的保护范围之内。另外，本申请说明书和权利要求书所使用的一些术语并不是限制，仅仅是为了便于描述。

Claims (9)

1.一种代理支付业务场景下的日志分析方法，其特征在于，步骤包括：

M1，日志分析平台采集每笔代理支付业务产生的日志，内容包括关联每笔代理支付业务的唯一交易ID、交易类型、服务接口名称、交易指令编号、交易开始时间、交易结束时间、代理支付业务交易结果返回信息以及日志分析平台根据委托方提供的代理支付对象信息生成的对应每个收款方的代理日志；

M2，所述日志分析平台根据接收到的所述唯一交易ID的数量计算指定时间段内的总交易量，并根据关联每个所述代理支付业务的所述交易开始时间和所述交易结束时间计算每笔所述代理支付业务的交易耗时，并计算交易结果返回状态为“成功”的所述代理支付业务的数量与所述总交易量的比值作为交易成功率，同时根据所述代理日志判断所关联的所述代理支付业务是否出现异常，并根据不同的异常类型生成不同的异常日志，以提示代理支付业务的相关方当前的代理支付行为出现异常；

M3，根据所述日志以及所述异常日志生成日志分析结果以可视化方式展示给用户。

2.根据权利要求1所述的代理支付业务场景下的日志分析方法，其特征在于，步骤M2中，根据所述代理日志判断所关联的所述代理支付业务是否出现异常的方法步骤包括：

S1，所述日志分析平台根据委托方提供的代理支付对象信息生成对应每个收款方的所述代理日志后发送给每个对应的所述收款方；

S2，运行在智能终端上的收款方监测APP解析出所接收的所述代理日志中携带的随机编码后，生成输入框并提示所述收款方在所述输入框中输入其专属的收款方编码；

S3，所述日志分析平台接收到所述收款方输入的所述收款方编码后，通过拉格朗日多项式的插值方法验证其生成的所述随机编码是否正确，以此而建立起所述委托方、代理方和所述收款方三方之间判断代理支付行为是否异常的信息交互，

若验证失败，则判定收款对象出错，并生成第一异常日志推送给所述收款方监测APP和委托方监测平台，并同步显示给代理支付业务操作人员，所述第一异常日志包括对收款对象出错的判定结果、所述收款方输入的第一收款方编码、作为所述日志分析平台生成所述随机编码依据的第二收款方编码以及关联所述第二收款方编码的待代理支付信息；

若验证成功，则不生成所述第一异常日志并终止针对所述收款方的代理支付监测流程。

3.根据权利要求2所述的代理支付业务场景下的日志分析方法，其特征在于，步骤M2中，根据所述代理日志判断所关联的所述代理支付业务是否出现异常的方法还包括步骤：

S4，所述收款方监测APP解析出所述第一异常日志中携带的所述第二收款方编码、所述第一收款方编码后生成提示框推送给所述收款方，所述提示框中显示有所述第二收款方编码并带有输入框，以提示所述收款方再次输入其专属的收款方编码；

S5，当所述收款方再次输入其专属的所述收款方编码后，所述收款方监测APP开始比对所述收款方再次输入的第三收款方编码是否与所述第二收款方编码、所述第一收款方编码一致，

若与所述第二收款方编码比对一致，则判定所述收款方输入所述第一收款方编码时出错，将判定结果生成为第二异常日志推送给所述日志分析平台；

若与所述第一收款方编码比对一致，则判定所述代理方的代理支付对象错误或所述委托方提供的代理支付对象信息出错，然后将所述第一收款方编码、判定结果和所述待代理支付信息生成为第三异常日志推送给所述日志分析平台和所述委托方监测平台。

4.根据权利要求3所述的代理支付业务场景下的日志分析方法，其特征在于，步骤M2中，根据所述代理日志判断所关联的所述代理支付业务是否出现异常的方法还包括步骤：

S6，所述委托方监测平台解析出所述第三异常日志中携带的所述第一收款方编码和所述待代理支付信息，然后根据所述第一收款方编码与待支付信息的绑定关系，从数据库中匹配出所解析的所述第一收款方编码对应的待支付信息，所述待代理支付信息和所述待支付信息包括支付类型、支付金额和收款人账号；

S7，所述委托方监测平台对所述待代理支付信息和所述待支付信息作信息一致性比对，

若全部比对成功，则判定所述委托方针对所述收款方提供的所述收款方编码错误或所述代理方输入给随机编码生成器的所述第二收款方编码错误，然后将比对结果生成为第四异常日志显示给所述委托方和/或推送给所述日志分析平台；

若任意一项比对失败，则判定所述代理方的代理支付对象错误并生成第一告警信息推送给所述日志分析平台。

5.根据权利要求4所述的代理支付业务场景下的日志分析方法，其特征在于，步骤S7中，当所述收款方编码由所述代理方分配得到时，若所述委托方监测平台判定所述待代理支付信息和所述待支付信息的所有信息项比对成功时，直接判定所述代理方输入给随机编码生成的所述收款方编码出错，并将判定结果生成为第二告警信息推送给所述日志分析平台。

6.根据权利要求2所述的代理支付业务场景下的日志分析方法，其特征在于，步骤S3中，所述收款方输入所述第一收款方编码完成与所述代理方的首次信息交互后，所述日志分析平台验证代理支付行为是否异常的方法步骤包括：

S31，获取随机编码生成器针对每个所述收款方的输入、输出数据，所述随机编码生成器的输入数据为委托方或代理方为每个所述收款对象分配的专属的所述收款人编码，记为UC_x，输出数据为针对每个所述收款人编码所生成的所述随机编码，记为UC_y；

S32，形成每个所述收款方的收款方编码-随机编码数据对(UC_x，UC_y)，然后通过拉格朗日多项式的插值方法并通过以下表达式(1)拟合得到一随机编码曲线：

表达式(1)中，

表示第i个所述收款方编码对应的所述随机编码；

表示第i个所述收款方编码；

表示第j个所述收款方编码；

n表示所述收款对象名单中的所述收款方的数量；

S33，将所述收款方输入的所述第一收款方编码作为UC_x代入到H_n(UC_x)中，得到UC_x对应的拟合结果UC_y′；

S34，判断步骤S2解析得到的所述随机编码是否与UC_y′一致，

若一致，则判定验证成功；

若不一致，则判定验证失败。

7.根据权利要求3或4所述的代理支付业务场景下的日志分析方法，其特征在于，在步骤S2生成所述输入框以及在步骤S4生成所述提示框之前，还包括针对所述收款方的身份验证过程，验证所述收款方的身份的方法具体包括步骤：

L1，在步骤S2解析出所述代理日志中携带的所述随机编码，以及在步骤S4解析出所述第一异常日志中携带的所述第二收款方编码、所述第一收款方编码后，激活所述智能终端的指纹输入功能，以提示所述收款方触摸指纹输入区域以输入指纹；

L2，所述收款方监测APP从所述代理日志或所述第一异常日志中进一步解析出所携带的关联所述第二收款方编码的具有固定宽、高尺寸的标准指纹图像；

L3，所述收款方监测APP按照预设的空间离散方法，将解析出的所述标准指纹图像离散为若干个矩形块并对每个所述矩形块进行标号；

L4，所述收款方监测APP根据事先确定的每个指纹采集触点与所述标准指纹图像上的每个所述矩形块的空间位置映射关系，搜寻出所述收款方输入指纹时所述智能终端响应的每个触点分别对应的所述矩形块；

L5，从所述标准指纹图像中截取步骤L4搜寻到的各个所述矩形块表征的指纹特征图像，并将截取的各所述指纹特征图像形成为指纹区域图像，然后与采集到的指纹图像作指纹特征比对，

若比对成功，则所述收款方监测APP在步骤S2生成所述输入框，或在步骤S4中生成所述提示框；

若比对失败，则将比对失败结果生成为第五异常日志推送给所述日志分析平台。

8.根据权利要求7所述的代理支付业务场景下的日志分析方法，其特征在于，步骤L3中，将所述标准指纹图像离散为若干个所述矩形块的方法如下：

对所述标准指纹图像的每条边进行等分，得到若干个等分点；

从相互垂直的两条边上的每一个所述等分点引出一条线分别连接至其相对边的相对等分点上，若干条连线相互平行或垂直交织将所述标准指纹图像离散为若干个所述矩形块，然后对每个所述矩形块按由左往右、由上往下方式按序进行标号。

9.一种代理支付业务场景下的日志分析系统，可实现如权利要求1-8任意一项所述的代理支付业务场景下的日志分析方法，其特征在于，所述日志分析系统包括相互间通信连接的运行在智能终端上的日志分析平台、收款方监测APP和委托方监测平台，其中，

所述日志分析平台，用于根据委托方提供的代理支付对象信息生成对应每个收款方的代理日志后发送给每个对应的收款方；

所述收款方监测APP，用于在解析出所接收的所述代理日志中携带的随机编码后，生成输入框并提示所述收款方在所述输入框中输入其专属的收款方编码；

所述日志分析平台，还用于在接收到所述收款方输入的所述收款方编码后，通过拉格朗日多项式的插值方法验证其生成的所述随机编码是否正确，以此而建立起所述委托方、代理方和所述收款方三方之间判断代理支付行为是否异常的信息交互，

若验证失败，则判断收款对象出错，并生成第一异常日志推送给所述收款方监测APP和所述委托方监测平台，并同步显示给代理支付业务操作人员，所述第一异常日志包括对收款对象出错的判定结果、所述收款方输入的第一收款方编码、作为所述日志分析平台生成所述随机编码依据的第二收款方编码以及关联所述第二收款方编码的待代理支付信息；

若验证成功，则不生成所述第一异常日志并终止针对所述收款方的代理支付监测流程。

Images