CN117474338A - 业务处理方法及相关装置 - Google Patents

Abstract

本申请提供一种业务处理方法及装置，该业务处理方法及装置可用于金融领域，业务处理方法包括：接收用于请求查询第一账户被管控的原因的第一请求，第一请求中包括用于指示第一账户的信息；基于确定的风险账户名单库确定M个风险识别模型，风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，M个风险识别模型中的每个风险识别模型为识别所述第一账户为风险账户的风险识别模型；基于第一信息获取M个风险识别模型中的每个风险识别模型对应的管控原因并输出M个风险识别模型中的每个风险识别模型对应的管控原因。该方法可以快速查询第一账户被管控的原因，以实现降低查询第一账户被管控的原因的时长。

Description

业务处理方法及相关装置

技术领域

本申请涉及金融领域，尤其涉及一种业务处理方法及相关装置。

背景技术

银行***构建了大量的风险识别模型来识别有风险的账户，然后对准确率较高的风险识别模型直接实行“先控后核”的策略，被识别为有风险的账户将被管控，以提升用户的资金安全等。

但是，在提升用户的资金安全的同时，存在查询账户被管控的原因时耗时长的问题。

发明内容

本申请提供一种业务处理方法及相关装置，以实现降低查询账户的管控原因时的查询时长。

第一方面，本申请实施例提供一种业务处理方法，该方法应用于银行***，银行***中包括第一信息和至少N个用于识别是否为风险账户的风险识别模型，第一信息指示N个风险识别模型中每个风险识别模型对应的管控原因，N大于1，所述方法包括：接收第一请求，所述第一请求用于请求查询第一账户被管控的原因，所述第一请求中包括用于指示所述第一账户的信息；基于确定的风险账户名单库确定M个风险识别模型，风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，M个风险识别模型中的每个风险识别模型为识别所述第一账户为风险账户的风险识别模型，M个风险识别模型包含于所述N个风险识别模型中；基于第一信息获取M个风险识别模型中的每个风险识别模型对应的管控原因并输出M个风险识别模型中的每个风险识别模型对应的管控原因。

结合第一方面，在一种可能的实现方式中，第一信息还指示与N个风险识别模型一一对应的N个业务***以及对N个风险识别模型中每个风险识别模型识别到的账户进行管控后对应的解控措施，所述方法还包括：接收第二请求，第二请求用于请求从K个业务***中对所述第一账户进行解控，K个业务***与K个风险识别模型一一对应，K个风险识别模型包含于M个风险识别模型中；基于第一信息获取与K个业务***中的各个业务***对应的风险识别模型对应的解控措施；基于与K个业务***中的各个业务***对应的风险识别模型对应的解控措施，从K个业务***中对第一账户进行解控。

结合第一方面，在一种可能的实现方式中，在接收第一请求之前，所述方法还包括：从N个业务***中获取与所述N个业务***一一对应的N个风险识别模型分别识别到的风险账户名单，形成风险账户名单库。

结合第一方面，在一种可能的实现方式中，从N个业务***中获取与N个业务***一一对应的N个风险识别模型分别识别到的风险账户名单，包括：接收N个业务***中的各个业务***批量发送的对应的风险识别模型在第一时段内识别到的风险账户名单。

结合第一方面，在一种可能的实现方式中，所述方法还包括：对风险账户名单库进行更新；其中，更新后的风险账户名单库指示的N个风险识别模型中的K个风险识别模型识别到的风险账户名单中不包括第一账户。

结合第一方面，在一种可能的实现方式中，所述方法还包括：接收第一信息。

结合第一方面，在一种可能的实现方式中，基于与所述K个业务***中的各个业务***对应的风险识别模型对应的解控措施，从K个业务***中对第一账户进行解控，包括：同时调用K个业务***中的解控模块对第一账户进行解控，每个业务***中的解控模块基于对应的风险识别模型对应的解控措施进行解控。

第二方面，本申请提供一种业务处理装置，应用于银行***，银行***中包括第一信息和至少N个用于识别是否为风险账户的风险识别模型，第一信息指示N个风险识别模型中每个风险识别模型对应的管控原因，所述装置包括：收发模块，用于接收第一请求，第一请求用于请求查询第一账户被管控的原因，第一请求中包括用于指示第一账户的信息；处理模块，用于基于确定的风险账户名单库确定M个风险识别模型，风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，M个风险识别模型中的每个风险识别模型为识别第一账户为风险账户的风险识别模型，M个风险识别模型包含于N个风险识别模型中；所述处理模块，还用于基于第一信息获取M个风险识别模型中的每个风险识别模型对应的管控原因并输出所述M个风险识别模型中的每个风险识别模型对应的管控原因

结合第二方面，在一种可能的实现方式中，第一信息还指示与N个风险识别模型一一对应的N个业务***以及对N个风险识别模型中每个风险识别模型识别到的账户进行管控后对应的解控措施，收发模块还用于：接收第二请求，第二请求用于请求从K个业务***中对第一账户进行解控，K个业务***与K个风险识别模型一一对应，K个风险识别模型包含于M个风险识别模型中；处理模块还用于：基于第一信息获取与K个业务***中的各个业务***对应的风险识别模型对应的解控措施；基于与K个业务***中的各个业务***对应的风险识别模型对应的解控措施，从K个业务***中对第一账户进行解控。

结合第二方面，在一种可能的实现方式中，在接收第一请求之前，所述处理模块还用于：从N个业务***中获取与N个业务***一一对应的N个风险识别模型分别识别到的风险账户名单，形成风险账户名单库。

结合第二方面，在一种可能的实现方式中，处理模块还用于：接收N个业务***中的各个业务***批量发送的对应的风险识别模型在第一时段内识别到的风险账户名单。

结合第二方面，在一种可能的实现方式中，处理模块还用于：对风险账户名单库进行更新；其中，更新后的风险账户名单库指示的N个风险识别模型中的K个风险识别模型识别到的风险账户名单中不包括第一账户。

结合第二方面，在一种可能的实现方式中，收发模块还用于：接收第一信息。

结合第二方面，在一种可能的实现方式中，处理模块还用于：同时调用K个业务***中的解控模块对第一账户进行解控，每个业务***中的解控模块基于对应的风险识别模型对应的解控措施进行解控。

第三方面，本申请提供一种业务处理装置，包括：存储器和处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令执行如第一方面或其中任意一种可能的实现方式所述的方法。

第四方面，本申请提供一种芯片，包括至少一个处理器和通信接口，所述通信接口和所述至少一个处理器通过线路互联，所述至少一个处理器用于运行计算机程序或指令，以执行如第一方面或其中任意一种可能的实现方式所述的方法。

第五方面，本申请提供一种计算机可读介质，所述计算机可读介质存储用于计算机执行的程序代码，该程序代码包括用于执行如第一方面或其中任意一种可能的实现方式所述的方法。

第六方面，本申请提供一种计算机程序产品，所述计算机程序产品中包括计算机程序代码，当所述计算机程序代码在计算机上运行时，使得所述计算机实现如第一方面或其中任意一种可能的实现方式所述的择方法

本申请提供的业务处理方法可以由业务处理装置执行。具体地，该业务处理装置包含于银行***中。更具体地，本实施例提供的业务处理方法中，由于在银行***中存储了第一信息以及会获取账户名单库，其中，第一信息指示了N个风险识别模型中的每个风险识别模型对应的管控原因，风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，使得在接收到查询第一账户被管控的原因的第一请求之后，可以基于风险账户名单库确定出该第一账户被哪些风险识别模型(例如有M个)识别为了风险账户导致该第一账户被管控，然后再确定出了M个风险识别模型后，再基于存储的第一信息获取各自对应的管控原因，并输出M个风险识别模型中的每个风险识别模型对应的管控原因。应理解，在现有的查询第一账户被管控的原因时，当第一账户被M个风险识别模型识别为风险账户导致第一账户被管控后，需要银行操作人员到该M个风险识别模型分别对应的业务***中去查询被管控的原因。例如，若M取3，则需要银行操作人员到与风险识别模型1对应的业务***1中去进行查询，到与风险识别模型2对应的业务***2中去进行查询以及到与风险识别模型3对应的业务***3中去进行查询，即需要逐个查询，串行操作。但是本申请提供的业务处理方法中，当银行操作人员输入第一请求，然后就会向银行操作人员并行输出M个风险识别模型各自对应的管控原因，即第一账户被管控的原因。因此，相比现有的查询方法，本申请提供的业务处理方法可以实现降低查询账户的管控原因时的查询时长。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请一个实施例提供的应用场景的结构性示意图；

图2为本申请一个实施例提供的业务处理方法的流程性示意图；

图3为本申请一个实施例提供的形成风险账户名单库的过程示意图；

图4为本申请一个实施例提供的第一信息的一种示意图；

图5为本申请一个实施例提供的查询被管控原因时的过程示意图；

图6为本申请一个实施例提供的解控时的过程示意图；

图7为本申请一个实施例提供的业务处理装置的结构性示意图；

图8为本申请另一个实施例提供的业务处理装置的结构性示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

需要说明的是，本申请的业务处理方法及相关装置可用于金融领域，也可用于除金融领域之外的任意领域，本申请对业务处理方法及相关装置的应用领域不做限定。

图1为本申请的可以应用的场景示意图。如图1所示，用户可以通过银行***进行银行交易。由于近年来账户异常交易风险形势险峻，严重影响金融机构或者用户的资金安全。因此，基于目前对账户管控愈来愈严的要求，目前的银行***中都构建了大量的风险识别模型(也称为风险识别管控模型、管控模型)以对有风险的账户进行识别，然后对其中准确率较高的模型直接实行“先控后核”策略，即当某个客户/用户的账户命中风险识别管控模型后，该客户/用户的账户将直接被管控，以保证该客户/用户资金安全等。

作为一种示例，例如风险识别模型为一个黑名单，当用户通过账户发起交易时，若银行***识别到该发起交易的用户是黑名单里面的用户，则对该用户的账户进行管控。

在此说明的是，本实施例对客户/用户如何向银行***发起交易的方式不做限制。例如是通过手机银行渠道发起的，或者是通过网上银行渠道发起的，或者是通过柜面渠道发起的，或者是通过ATM渠道发起的，又或者是通过自主终端渠道发起的。

但是，在提升资金安全的同时，引发了对账户查询和解控的难题：

一方面，客户/用户的账户被管控的原因存储在各个风险识别模型各自对应的业务***中，此时为了定位被管控的原因，需要银行操作人员到各个业务***中去进行查询才能定位出被管控的原因。例如，若某个账户命中了风险识别模型1和风险识别模型2，若要查询被管控的原因，需要银行操作人员到风险识别模型1所在的业务***1中查询被管控的原因以及需要到风险识别模型2所在的业务***2中查询被管控的原因。这增加了对客户/用户解释管控原因的难度，同时也导致了解除管控之前查询管控原因耗时较长的问题。

另一方面，当客户/用户的账户命中多个风险识别模型时，当进行解控时，需要到各个风险识别模型各自对应的业务***中通过不同的交易去进行解控，需要重复提供证明材料，重复进行相同的解控认证步骤，逐个进行解控，导致存在耗时长的问题，影响客户/用户体验。例如，若某个账户命中了管控模型1和管控模型2，若要进行解控时，需要银行操作人员到管控模型1所在的业务***1中进行解控以及需要到管控模型2所在的业务***2中进行解控，导致解控耗时较长。

鉴于此，本申请提供一种业务处理方法，以期降低查询账户的管控原因时的查询时长以及降低解控账户时的时长。

图2为本申请一个实施例提供的业务处理方法的流程性示意图。该方法可以由业务处理装置执行，其中，该业务处理装置包含于银行***中。

具体地，该银行***中包括至少N个用于识别是否为风险账户的风险识别模型。换言之，该银行***中包括N个风险识别模型，其中，每个风险识别模型用于识别有风险的账户。本申请中，银行***会对风险识别模型识别到的有风险的账户(称为风险账户)进行管控以提升安全性。

本申请中，银行***中还存储有第一信息，其中，第一信息指示了上述N个风险识别模型中每个风险识别模型对应的管控原因，即，第一信息指示了N个风险识别模型中每个风险识别模型识别到的风险账户被管控的原因。例如，银行***中包括3个风险识别模型，称为风险识别模型1、风险识别模型2和风险识别模型3，那么第一信息会指示通过风险识别模型1识别到的风险账户被管控时的管控原因、通过风险识别模型2识别到的风险账户被管控时的管控原因以及通过风险识别模型3识别到的账户被管控时的管控原因。

在上述银行***包括N个用于识别是否为风险账户的风险识别模型以及第一信息的基础之上，如图2所示，该方法包括：

S201，接收第一请求，第一请求用于请求查询第一账户被管控的原因，第一请求中包括用于指示第一账户的信息。

其中，第一账户需要查询被管控的原因的被管控的账户。

本实施例中，银行***会接收用于请求查询第一账户被管控的原因的请求，本实施例中也称为第一请求。

在此说明的是，本实施例对银行***如何接入第一请求的方式不做限制。例如，银行***可以提供用于查询账户被管控的原因的UI界面，然后银行操作人员在该UI界面上输入第一请求，该第一请求用于请求(或者称为指示)查询第一账户被管控的原因。

在实施时，该第一请求中包括用于指示第一账户的信息，以使得银行***基于该信息获知是需要对第一账户被管控的原因进行查询。

作为一种示例，指示第一账户的信息例如是用于唯一标识第一账户的标识。

S202，基于确定的风险账户名单库确定M个风险识别模型，风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，M个风险识别模型中的每个风险识别模型为识别第一账户为风险账户的风险识别模型，M个风险识别模型包含于N个风险识别模型中。

本实施例中，银行***会执行确定风险账户名单库的操作。其中，风险账户名单库指示了上述N个风险识别模型中每个风险识别模型识别的风险账户名单。其中，每个风险识别模型识别的风险账户名单指示了识别的至少一个风险账户。

在实现时，每个风险识别模型识别的风险账户名单中例如包括识别的风险账户的标识，以通过风险账户的标识指示识别的风险账户。换言之，只要被N个风险识别模型识别到的有风险的账户，那么该有风险账户的标识都会被包括在风险账户名单库中。

应理解，目前，对于各个风险识别模型，各个风险识别模型识别到的风险账户名单都是存储在各自的业务***中的，即风险识别模型与业务***是一一对应的。例如，N取3，称为风险识别模型1、风险识别模型2和风险识别模型3。那么该风险识别模型1识别到的风险账户名单都是存储在业务***1中，风险识别模型2识别到的风险账户名单都是存储在业务***2中，风险识别模型3识别到的风险账户名单都是存储在业务***3中的。因此，在实施时，可以通过从N个风险识别模型一一对应的N个业务***中获取各个风险识别模型识别到的风险账户名单然后进行聚合，以形成账户名单库。其中，有关更具体的如何获取N个业务***中的各个风险识别模型识别到的风险账户名单的方式本申请不做限制。

应理解，由于风险账户名单库指示了N个风险识别模型中每个风险识别模型识别的风险账户名单，因此，当银行***接收到第一请求后，就可以确定出该第一账户都被哪些风险识别模型识别为了有风险的账户。本实施例中，将确定出第一账户为风险账户的风险识别模型的数量表示为M个。应理解，该M个风险识别模型包含于所述N个风险识别模型中。

S203，基于第一信息获取M个风险识别模型中的每个风险识别模型对应的管控原因并输出M个风险识别模型中的每个风险识别模型对应的管控原因。

可以理解的是，由于本申请的银行***中存储了用于指示N个风险识别模型中每个风险识别模型对应的管控原因，因此，当银行***确定出了将第一账户识别为有风险的账户的M个风险识别模型后，可以基于第一信息确定出与该M个风险识别模型分别对应的管控原因并输出M个风险识别模型中的每个风险识别模型对应的管控原因。

应理解，在现有的查询第一账户被管控的原因时，当第一账户被M个风险识别模型识别为风险账户导致第一账户被管控后，需要银行操作人员到该M个风险识别模型分别对应的业务***中去查询被管控的原因。例如，若M取3，则需要银行操作人员到与风险识别模型1对应的业务***1中去进行查询，到与风险识别模型2对应的业务***2中去进行查询以及到与风险识别模型3对应的业务***3中去进行查询，即需要银行操作人员逐个查询，串行操作。但是本申请提供的业务处理方法中，当银行操作人员输入第一请求后，银行***就会向银行操作人员并行输出M个风险识别模型各自对应的管控原因，即第一账户被管控的原因。因此，相比现有的查询方法，本申请提供的业务处理方法可以实现降低查询账户的管控原因时的查询时长。

应理解，除了有查询被管控的账户的管控原因的需求之外，有时候还有需要对被管控的账户从对应的业务***中进行解控的需求。鉴于此，本申请中，第一信息还指示与N个风险识别模型一一对应的N个业务***以及对N个风险识别模型中每个风险识别模型识别到的账户进行管控后对应的解控措施。之后，当查询出第一账户被上述M个风险识别为风险账户并要从K个业务***中对第一账户进行解控时，该K个业务***与M个风险识别模型中的K个风险识别模型一一对应，该业务处理方法还包括：接收第二请求，第二请求用于请求从K个业务***中对第一账户进行解控；基于第一信息获取与K个业务***中的各个业务***对应的风险识别模型对应的解控措施；基于与K个业务***中的各个业务***对应的风险识别模型对应的解控措施，从K个业务***中对第一账户进行解控。

应理解，该业务处理方法提供的解控方式中，由于第一信息还指示了N个风险识别模型中每个风险识别模型识别到的账户进行管控后对应的解控措施，因此，当银行***接收到了第二请求后，就可以基于第一信息确定出K个业务***对应的K个风险识别模型以及K个风险识别模型中每个风险识别模型对应的解控措施，然后基于K个风险识别模型中每个风险识别模型对应的解控措施，从K个业务***中对第一账户进行解控。

应理解，在现有的从K个业务***中解控第一账户时，需要银行操作人员到该K个业务***中分别去进行解控。例如，若M取2，则需要银行操作人员到与风险识别模型1对应的业务***1中去进行解控，到与风险识别模型2对应的业务***2中去进行解控，串行操作。但是本申请提供的业务处理方法中，当银行操作人员输入第二请求，然后就会并行获取到K个业务***进行解控时分别对应的解控措施，再并行解控。因此，相比现有的解控方法，本申请提供的业务处理方法可以实现降低解控时的时长。

下面，结合一个详细的实施例，说明本申请提供的业务处理方法。其中，该业务处理方法中包括查询管控原因的方法和解控账户的方法。

前提条件1：建立个人客户统一风险视图

其中，建立个人客户统一风险视图即可以理解为建立/确定上述所述的风险账户名单库，该个人客户统一风险视图是共享数据基础，可以形成跨领域、跨专业的个人客户统一风险视图，向银行***包括的各业务***提供专业的共享数据和服务。

在一种实现方式中，该个人客户统一风险视图的建立(即风险账户名单库的确定)可以由个人客户统一风险视图模块执行。具体地，本实施例中，如图3所示，个人客户统一风险视图模块中包括批量处理子模块、联机处理子模块、队列消费进程子模块。下面，结合图4，说明如何通过批量处理子模块、联机处理子模块、队列消费进程子模块建立个人客户统一风险视图的过程。

其中，批量处理模块的主要任务是将首次接入到个人客户统一风险视图模块的业务***包括的存量(批量)风险账户名单加载到风险账户名单库中。具体地，如图4所示，采用批量预加载方式，首次部署时可以将银行***中的各个业务***(例如包括客户交易监测***、个人金融***、个人客户信息***)中存量的风险账户名单进行入湖处理，批量处理模块基于上游风险账户名单入湖表导出存量文件，导出文件通过批量队列写入进程纳入到批量队列中。

其中，联机处理模块的主要任务是将已接入到个人客户统一风险视图模块的业务***识别的增量风险名单加载到风险账户名单库中。具体地，如图4所示，联机处理模块使用KAFKA消息队列技术，实现风险账户名单库与各源业务***之间的准实时同步。通过消费上游业务***的KAFKA队列，过滤、解析队列中的消息，生成联机名单更新记录，将其纳入到联机队列中。

批量处理模块和联机处理模块所产生的批量、联机队列中的消息，通过队列消费进程模块完成风险账户名单库中相关名单状态的更新。

可选的，更新涉及时间戳判断机制，仅当消息时间戳大于风险账户名单库中名单的时间戳时，才会更新风险账户名单库中的名单信息。可选的，队列消费进程模块优先消费联机队列，保证联机名单同步时效性。

可以看出，本实施例中，各个业务***(例如包括信用、异常交易、操作、运营等领域)将账户粒度的账户名单数据同步至数据湖，个人客户统一风险视图模块基于各个业务***入湖的数据链路实时抽取被管控的风险账户清单并聚合形成风险账户名单库。例如，可选择实时、准实时、批量方式将各个业务***识别的风险账户名单同步至风险账户名单库中。

前提条件2：配置银行***中包括各个风险识别模型分别对应的业务***、每个业务***的风险识别模型对应的管控原因、以及每个吸引的风险识别模型对应的解控措施。

即，可以认为是在银行***中配置上述所述的第一信息。

应理解，针对不同的管控类型，各个源头业务***有着不同的解控要求及策略。这些解控策略在各个源头业务***分散维护，存在模板不统一、管理较分散、查询使用存在壁垒的问题。因此，本申请中提供的业务处理方法中，银行***为银行操作人员提供可以配置第一信息的功能，以针对每种管控类型设置解控策略、管控原因等信息，并支持灵活配置及修改。

示例性的，一种配置的第一信息的示例如表1所示：

表1

可以理解的是，当有了该第一信息后，当要查询某个被管控的风险账户的管控原因或者要对被管控的风险账户在某几个业务***中进行解控时，就可以同时并行处理。

在支持上述两个前提条件后，详细说明查询被管控的账户的管控原因的方法。

结合图5说明查询方法：

基于风险账户名单库和第一信息，按照风险管理要求，在多渠道(例如包括柜面、网上银行、手机银行、电话银行等渠道)建立风险账户的一键查询功能，如图5所示，具体描述如下：

步骤S01：接收银行操作人员通过银行各渠道发送的查询请求，该查询请求指示查询第一账户被管控的原因，该查询请求中包括被管控的第一账户的相关信息。

其中，被管控的第一账户的相关信息是指用于标识第一账户的信息。

在此说明的是，本实施例中，还可以一次有其他查询请求，该其他查询请求用于请求对其他风险账户的一些信息进行查询。其中，对其他风险账户进行查询的实现可以类比对该第一账户进行查询的方式，此处不再赘述。

可选的，查询的信息例如还指示对风险账户被哪些风险识别模型识别为了风险账户(本申请中，将涉及到的将该账户识别为风险账户的风险识别模型也称为涉及的风险识别模型)，以及涉及的风险识别模型中的每个风险识别模型对应的解控措施、解控要求及方法等。

步骤S02：银行***调用查询模块查询第一账户的管控原因。

具体地，银行***调用查询模块进行查询时，查询模块先根据查询请求中包括的第一账户的相关信息接入到风险账户名单库中，以从风险账户名单库中获取到识别该第一账户为风险账户的M个风险识别模型(也称为获取账户的风险控制信息)。之后，查询模块基于第一信息，获取该M个风险识别模型分别对应的管控原因。

步骤S03：查询模块将S02中获取到M个风险识别模型分别对应的管控原因输出。

可选的，在查询的信息还指示对风险账户被哪些风险识别模型识别为了风险账户(本申请中，将涉及到的将该账户识别为风险账户的风险识别模型也称为涉及的风险识别模型)，以及涉及的风险识别模型中的每个风险识别模型对应的解控措施、解控要求及方法等，还输出该第一账户被管控的管控依据、管控措施、解控要求以及方法等。

在获得上述查询结果后，结合图6，说明解控方法：

步骤S21，接收银行操作人员通过银行各渠道发送的解控请求，该解控请求指示需从K个业务***中对第一账户进行解控。

其中，该K个业务***与K个风险识别模型一一对应，该K个风险识别模型即为上述查询方法中的S01中确定的M个风险识别模型。

在此说明的是，本实施例中，还可以一次有其他解控请求，该其他解控请求用于请求对其他风险账户进行解控。其中，对其他风险账户进行解控的实现可以类比对该第一账户进行解控的方式，此处不再赘述。

步骤S22，银行***调用解控模块进行解控。

具体地，银行***调用解控模块进行查询时，解控模块根据第一信息确定与K个业务***对应的K个风险识别模型各自对应的解控策略及对应的解控步骤，开展客户的身份认证(联网核查)，补充完善相关材料(增强型尽职调查)并经过授权完成后，调用各业务***的风控解除功能进行解控并对K个业务***中的各个业务***中的风险账户名单进行更新。

步骤S23，银行***对风险账户名单库进行更新。

具体地，更新后的风险账户名单库指示的K个风险识别模型识别到的风险账户名单中不包括第一账户。换言之，从风险账户名单库包括的K个风险识别模型识别的账户名单中删除了第一账户。

下面，结合图7，说明本申请提供的业务处理装置。该业务处理装置700可以应用于银行***，银行***中包括第一信息和至少N个用于识别是否为风险账户的风险识别模型，第一信息指示N个风险识别模型中每个风险识别模型对应的管控原因。如图7所示，装置700包括：收发模块701和处理模块702。

其中，收发模块701，用于接收第一请求，第一请求用于请求查询第一账户被管控的原因，第一请求中包括用于指示第一账户的信息；处理模块702，用于基于确定的风险账户名单库确定M个风险识别模型，风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，M个风险识别模型中的每个风险识别模型为识别第一账户为风险账户的风险识别模型，M个风险识别模型包含于N个风险识别模型中；处理模块702，还用于基于第一信息获取M个风险识别模型中的每个风险识别模型对应的管控原因并输出所述M个风险识别模型中的每个风险识别模型对应的管控原因。

在一种可能的实现方式中，第一信息还指示与N个风险识别模型一一对应的N个业务***以及对N个风险识别模型中每个风险识别模型识别到的账户进行管控后对应的解控措施，收发模块701还用于：接收第二请求，第二请求用于请求从K个业务***中对第一账户进行解控，K个业务***与K个风险识别模型一一对应，K个风险识别模型包含于M个风险识别模型中；处理模块702还用于：基于第一信息获取与K个业务***中的各个业务***对应的风险识别模型对应的解控措施；基于与K个业务***中的各个业务***对应的风险识别模型对应的解控措施，从K个业务***中对第一账户进行解控。

在一种可能的实现方式中，在接收第一请求之前，处理模块702还用于：从N个业务***中获取与N个业务***一一对应的N个风险识别模型分别识别到的风险账户名单，形成风险账户名单库。

在一种可能的实现方式中，处理模块702还用于：接收N个业务***中的各个业务***批量发送的对应的风险识别模型在第一时段内识别到的风险账户名单。

在一种可能的实现方式中，处理模块702还用于：对风险账户名单库进行更新；其中，更新后的风险账户名单库指示的N个风险识别模型中的K个风险识别模型识别到的风险账户名单中不包括第一账户。

在一种可能的实现方式中，收发模块701还用于：接收第一信息。

在一种可能的实现方式中，处理模块702还用于：同时调用K个业务***中的解控模块对第一账户进行解控，每个业务***中的解控模块基于对应的风险识别模型对应的解控措施进行解控。

图7为本申请另一个实施例提供的事件单编号的生成装置的结构性示意图。图7所示的装置可以用于执行前述任意一个实施例所述的方法。

如图8所示，本实施例的装置800包括：存储器801、处理器802、通信接口803以及总线804。其中，存储器801、处理器802、通信接口803通过总线804实现彼此之间的通信连接。

存储器801可以是只读存储器(read only memory，ROM)，静态存储设备，动态存储设备或者随机存取存储器(random access memory，RAM)。存储器801可以存储程序，当存储器81中存储的程序被处理器802执行时，处理器802用于执行图2至图6所示的方法的各个步骤。

处理器802可以采用通用的中央处理器(central processing unit，CPU)，微处理器，应用专用集成电路(application specific integrated circuit，ASIC)，或者一个或多个集成电路，用于执行相关程序，以实现本申请图2至图6所示的方法。

处理器802还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，本申请实施例图2至图6的方法的各个步骤可以通过处理器802中的硬件的集成逻辑电路或者软件形式的指令完成。

上述处理器802还可以是通用处理器、数字信号处理器(digital signalprocessing，DSP)、专用集成电路(ASIC)、现成可编程门阵列(field programmable gatearray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器801，处理器802读取存储器801中的信息，结合其硬件完成本申请装置包括的单元所需执行的功能，例如，可以执行图2至图6所示实施例的各个步骤/功能。

通信接口803可以使用但不限于收发器一类的收发装置，来实现装置800与其他设备或通信网络之间的通信。

总线804可以包括在装置800各个部件(例如，存储器801、处理器802、通信接口803)之间传送信息的通路。

应理解，本申请实施例所示的装置800可以是电子设备，或者，也可以是配置于电子设备中的芯片。

需要说明的是，本申请中的均值聚类方法及装置可用于大数据领域，也可用于除大数据领域以外的任意领域。本申请对该均值聚类方法及装置的应用领域不作限定。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行所述计算机指令或计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A,B可以是单数或者复数。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系，但也可能表示的是一种“和/或”的关系，具体可参考前后文进行理解。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

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

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

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种业务处理方法，其特征在于，应用于银行***，所述银行***中包括第一信息和至少N个用于识别是否为风险账户的风险识别模型，所述第一信息指示N个风险识别模型中每个风险识别模型对应的管控原因，N大于1，所述方法包括：

接收第一请求，所述第一请求用于请求查询第一账户被管控的原因，所述第一请求中包括用于指示所述第一账户的信息；

基于确定的风险账户名单库确定M个风险识别模型，所述风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，所述M个风险识别模型中的每个风险识别模型为识别所述第一账户为风险账户的风险识别模型，所述M个风险识别模型包含于所述N个风险识别模型中；

基于所述第一信息获取所述M个风险识别模型中的每个风险识别模型对应的管控原因并输出所述M个风险识别模型中的每个风险识别模型对应的管控原因。

2.根据权利要求1所述的方法，其特征在于，所述第一信息还指示与所述N个风险识别模型一一对应的N个业务***以及对所述N个风险识别模型中每个风险识别模型识别到的账户进行管控后对应的解控措施，所述方法还包括：

接收第二请求，所述第二请求用于请求从K个业务***中对所述第一账户进行解控，所述K个业务***与K个风险识别模型一一对应，所述K个风险识别模型包含于所述M个风险识别模型中；

基于所述第一信息获取与所述K个业务***中的各个业务***对应的风险识别模型对应的解控措施；

基于与所述K个业务***中的各个业务***对应的风险识别模型对应的解控措施，从所述K个业务***中对所述第一账户进行解控。

3.根据权利要求2所述的方法，其特征在于，在接收第一请求之前，所述方法还包括：

从所述N个业务***中获取与所述N个业务***一一对应的所述N个风险识别模型分别识别到的风险账户名单，形成所述风险账户名单库。

4.根据权利要求3所述的方法，其特征在于，所述从所述N个业务***中获取与所述N个业务***一一对应的所述N个风险识别模型分别识别到的风险账户名单，包括：

接收所述N个业务***中的各个业务***批量发送的对应的风险识别模型在第一时段内识别到的风险账户名单。

5.根据权利要求3所述的方法，其特征在于，所述方法还包括：

对所述风险账户名单库进行更新；

其中，更新后的风险账户名单库指示的N个风险识别模型中的所述K个风险识别模型识别到的风险账户名单中不包括所述第一账户。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：

接收所述第一信息。

7.根据权利要求6所述的方法，其特征在于，所述基于与所述K个业务***中的各个业务***对应的风险识别模型对应的解控措施，从所述K个业务***中对所述第一账户进行解控，包括：

同时调用所述K个业务***中的解控模块对第一账户进行解控，每个业务***中的解控模块基于对应的风险识别模型对应的解控措施进行解控。

8.一种业务处理装置，其特征在于，应用于银行***，所述银行***中包括第一信息和至少N个用于识别是否为风险账户的风险识别模型，所述第一信息指示所述N个风险识别模型中每个风险识别模型对应的管控原因，所述装置包括：

收发模块，用于接收第一请求，所述第一请求用于请求查询第一账户被管控的原因，所述第一请求中包括用于指示所述第一账户的信息；

处理模块，用于基于确定的风险账户名单库确定M个风险识别模型，所述风险账户名单库指示N个风险识别模型中每个风险识别模型识别到的风险账户名单，所述M个风险识别模型中的每个风险识别模型为识别所述第一账户为风险账户的风险识别模型，所述M个风险识别模型包含于所述N个风险识别模型中；

所述处理模块，还用于基于所述第一信息获取所述M个风险识别模型中的每个风险识别模型对应的管控原因并输出所述M个风险识别模型中的每个风险识别模型对应的管控原因。

9.一种业务处理装置，其特征在于，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如权利要求1至7中任一项所述的方法。

10.一种计算机可读介质，其特征在于，所述计算机可读介质存储用于计算机执行的程序代码，该程序代码包括用于执行如权利要求1至7中任一项所述的方法的指令。