CN115358739A - 信息处理方法及装置 - Google Patents

Abstract

本申请实施例提供了一种信息处理方法及装置，该方法将目标账户的限额信息按照个性化限额对象类型和全行级限额对象类型进行区分，从而更高效地确定出与账务交易匹配的目标限额信息，进而根据该限额信息，确定账务交易是否超出限额，有效提升限额检查的处理速度。

Description

信息处理方法及装置

技术领域

本申请涉及数据处理技术领域，具体而言，本申请涉及一种信息处理方法及装置。

背景技术

银行限额指的是对银行客户的单笔交易所设置的金额限制，以保证客户的每一笔交易的合理性，提高资金的安全性。现有的银行限额技术，会为各类业务设计单独的限额判定机制，例如将限额判定机制拆分成各个小的模块，再将各个小的限额模块糅杂在一起，形成一个比较臃肿的业务模型。

这样的限额判定机制在使用时需要重复调用臃肿的业务模型，导致处理耗时过久。

发明内容

本申请实施例的目的旨在能解决如何提升限额判定效率的问题。

根据本申请实施例的一个方面，提供了一种信息处理方法，该方法包括：

获取发生账务交易的目标账户的账户相关信息；

根据账户相关信息，确定目标账户对应的至少一种个性化限额对象类型；

基于至少一种个性化限额对象类型，确定第一限额信息；

若根据第一限额信息，确定账务交易未超出限额，则根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型；

基于至少一种全行级限额对象类型，确定第二限额信息；

根据第二限额信息，确定账务交易是否超出限额。

根据本申请实施例的另一个方面，提供了一种信息处理装置，该装置包括：

获取模块，用于获取发生账务交易的目标账户的账户相关信息；

对象类型确定模块，用于根据账户相关信息，确定目标账户对应的至少一种个性化限额对象类型；

限额确定模块，用于基于至少一种个性化限额对象类型，确定第一限额信息；

对象类型确定模块还用于若根据第一限额信息，确定账务交易未超出限额，则根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型；

限额确定模块还用于基于至少一种全行级限额对象类型，确定第二限额信息；

超额判定模块，用于根据第二限额信息，确定账务交易是否超出限额。

根据本申请实施例的又一个方面，提供了一种电子设备，该电子设备包括存储器、处理器及存储在存储器上的计算机程序，处理器执行计算机程序以实现本申请实施例提供的信息处理方法的步骤。

根据本申请实施例的再一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请实施例提供的信息处理方法的步骤。

根据本申请实施例的还一个方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现本申请实施例提供的信息处理方法的步骤。

本申请实施例提供的信息处理方法及装置，将目标账户的限额信息按照个性化限额对象类型和全行级限额对象类型进行区分，从而更高效地确定出与账务交易匹配的目标限额信息，进而根据该限额信息，确定账务交易是否超出限额，有效提升限额检查的处理速度。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

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

图2为本申请实施例提供的一种限额检查流程的示意图；

图3为本申请实施例提供的一种限额检查流程的使用场景的示意图；

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

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

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”可以实现为“A”，或者实现为“B”，或者实现为“A和B”。

为使本申请的目的、技术方案和优点更加清楚，下面将对本申请实施方式作进一步地详细描述。

首先对本申请涉及的几个名词进行介绍和解释：

(1)客户：是指在银行有账户的用户，一个客户可以有一个或多个账户。

(2)客户号：也可称为客户编号，是指每个客户身份在对应银行拥有的唯一标识号。

(3)客户账号：是指一个客户的每个账户在对应银行拥有的唯一身份标识号。

(4)产品：是指银行提供的与货币相关的商品和/或服务，例如活期产品、定期产品、贷款产品等。

(5)产品类别：对产品进行分类的种类信息，本领域技术人员可以根据实际情况来设置具体的产品类别，本申请实施例在此不做限定。

(6)产品账号：每个账户所使用任意产品类型时对应的唯一身份标识号。

(7)介质：是指能够记录账户内容的实物载体，包括但不限于借记卡、存单、存折等。

(8)名单：是指记录不同资质和/或信用等级账户的账户列表，例如黑名单、白名单等。

(9)机构：是指以银行财产设立的相对独立活动的银行组成部分，包括但不限于省行、分行、支行、网点等。

(10)渠道：是指客户办理银行业务时能够选择的方式，包括但不限于柜台、电子银行、ATM(Automated Teller Machine，自动取款机)等。

在实际应用中，现有的银行限额技术为各类业务设计单独的限额判定机制，除了会导致处理耗时过久之外，还可能具有以下缺陷：

缺陷一：业务分散使得代码及数据冗余，不易维护。

缺陷二：臃肿的业务模型，不易扩展新的限额业务。

针对上述现有银行限额技术中所存在的至少一个技术问题或需要改善的地方，本申请提出一种信息处理方法及装置，通过将银行的限额业务进行整合集中，设计成一套完整的体系，除了能够有效提升限额检查(也可称为检测、判定或判断)的处理速度之外，还能够达到以下效果：

效果一：适用性广，可以适配绝大多数业务要求；

效果二：灵活度高，可以进行简单的配置和少量的扩展便可满足新增需求。

下面通过对几个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。

本申请实施例中提供了一种信息处理方法，如图1所示，该方法包括：

步骤S101：获取发生账务交易的目标账户的账户相关信息。

本申请实施例中，账务交易是指在银行业务系统执行的任意一种交易，包括但不限于收入交易和支出交易，其中，收入包括但不限于存款、转账、工资等，支出包括但不限于取款、转账、消费等。

本申请实施例中，银行业务系统中有任意账户发生账务交易，该账户均可作为目标账户采用本申请的方案进行处理。

本申请实施例中，目标账户的账户相关信息是指目标账户发生账务交易时所需的各种账户信息，包括但不限于目标账户所属客户对应的目标客户号、目标账户对应的目标客户账号、账务交易中目标账户使用任意产品类型对应的目标产品账号等。

步骤S102：根据账户相关信息，确定目标账户对应的至少一种个性化限额对象类型；

本申请实施例中，将限额业务按照限额对象类型进行拆分，其中，限额对象类型是指与账户直接挂钩的属性，例如客户、产品、介质、名单等。

本申请实施例中，个性化限额对象类型是指针对单个客户和/或其账户个性化设置或客户自定义设置的限额业务对应的对象类型。其中，个性化限额对象类型可以包括但不限于以下至少一种：客户号、客户账号、产品账号等。

本申请实施例中，在获取到目标账户的账户相关信息后，可以根据账户相关信息来查询目标账户是否设置个性化限额，即目标账户是否对应至少一种个性化限额对象类型，也可以理解为目标账户是否包括至少一种个性化限额对象类型的限额业务。

若根据账户相关信息，确定出目标账户对应至少一种个性化限额对象类型，则执行步骤S103。

相应地，在步骤S101之后，若根据账户相关信息，确定出目标账户未对应个性化限额对象类型，则直接执行步骤S104的相关步骤。

步骤S103：基于至少一种个性化限额对象类型，确定第一限额信息。

本申请实施例中，不同的限额信息可能包含不同的限额规则，也可称为限额值，例如可以包括但不限于以下至少一种规则：累计交易额、单次交易额、账户余额等。其中，累计交易额可以包括累计交易次数与累计交易金额。

其中，一种个性化限额对象类型可能对应一个或多个第一限额信息。

步骤S104：若根据第一限额信息，确定账务交易未超出限额，则根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型。

本申请实施例中，在目标账户发生账务交易时，还可以获取该账务交易的实际交易额。基于实际交易额和第一限额信息，确定账务交易是否超出限额，例如第一限额信息包括单次交易金额的限额，那么判断实际交易额是否超出该单次交易金额的限额；又例如第一限额信息包括账户余额的上限，且该实际交易额是收入交易，那么判断假设实际交易额存入成功后账户余额是否超出该上限，其他的限额规则以此类推，本领域技术人员应能理解上述几种是否超出限额的判断仅为举例，基于这些范例进行的适当变化也可适用于本申请，故也应包含在本申请保护范围以内。

进一步地，根据第一限额信息，确定出此账务交易超出限额，则可以生成提示信息，例如提示报错等，但不限于此，本领域技术人员可以根据实际情况来设置交易超限后的处理方式，本申请实施例在此不做限定。

本申请实施例中，若根据第一限额信息，确定出账务交易未超出限额，则根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型。

此外，由上文中的介绍可知，若根据账户相关信息，确定出目标账户未对应个性化限额对象类型，则也直接执行根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型的步骤。

本申请实施例中，全行级限额对象类型是指针对所有与某账户属性相关联的客户和/或其账户设置的限额业务对应的对象类型。全行级限额对象类型包括但不限于以下至少一种：名单类型、介质类型、产品类型等。

本申请实施例中，目标账户可能对应至少一种全行级限额对象类型，即目标账户包括至少一种全行级限额对象类型的限额业务。相应地，若确定出目标账户没有对应的全行级限额对象类型，则可以结束限额检查流程，执行账务交易的后续处理。

步骤S105：基于至少一种全行级限额对象类型，确定第二限额信息。

本申请实施例中，第二限额信息与第一限额信息类似，具体可以参见上文中对限额信息的介绍，在此不再赘述。

同理地，一种全行级限额对象类型也可能对应一个或多个第二限额信息。

步骤S106：根据第二限额信息，确定账务交易是否超出限额。

本申请实施例中，可以基于上述实际交易额和第二限额信息，确定账务交易是否超出限额，是否超出限额的判断与步骤S104类似，具体可以参见对步骤S104的介绍，此处不再赘述。

同理地，根据第二限额信息，确定出账务交易超出限额，则可以生成提示信息，例如提示报错等，但不限于此，本领域技术人员可以根据实际情况来设置交易超限后的处理方式，本申请实施例在此不做限定。

本申请实施例中，若根据第二限额信息，确定出账务交易未超出限额，则可以结束限额检查流程，执行账务交易的后续处理。

本申请实施例提供的信息处理方法，将目标账户的限额信息按照个性化限额对象类型和全行级限额对象类型进行区分，从而更高效地确定出与账务交易匹配的目标限额信息，进而根据该限额信息，确定账务交易是否超出限额，有效提升限额检查的处理速度。

本申请实施例中，为步骤S103提供了一种可行的实施方式，具体地，可以包括步骤：

步骤S1031：基于至少一种个性化限额对象类型，确定至少一个第一限额场景信息；

步骤S1032：在至少一个第一限额场景信息中确定出与账务交易匹配的目标第一限额场景信息，并确定目标第一限额场景信息的第一限额信息；

本申请实施例中，在目标账户发生账务交易时，还可以获取该账务交易实际发生的交易场景信息，其中，交易场景信息中的场景要素包括但不限于机构、渠道、币种、借(收入)贷(支出)方向(借或贷)、交易类型(现金或转账)、公私互转类型(公转私、私转公、公转公等)、周期、地点、时间等要素中的至少一种维度。

本申请实施例中，可以将账务交易的交易场景信息分别与至少一个第一限额场景信息进行比对，在至少一个第一限额场景信息中确定出与账务交易匹配的目标第一限额场景信息。其中，对于确定出与账务交易不匹配的第一限额场景信息场景，后续将不再进行限额检查。在确定出目标第一限额场景信息后，进一步确定目标第一限额场景信息的第一限额信息。

其中，每个第一限额场景信息可分别对应一个限额信息。一种个性化限额对象类型可能对应一个或多个第一限额场景。

本申请实施例中，若在至少一个第一限额场景信息中无法确定出与账务交易匹配的目标第一限额场景信息，即至少一个第一限额场景信息均与交易场景信息不匹配，则直接执行步骤S104的相关步骤，即直接执行根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型的步骤。

本申请实施例中，为步骤S105提供了一种可行的实施方式，具体地，可以包括步骤：

步骤S1051：基于至少一种全行级限额对象类型，确定至少一个第二限额场景信息；

步骤S1052：在至少一个第二限额场景信息中确定出与账务交易匹配的目标第二限额场景信息，并确定目标第二限额场景信息的第二限额信息。

即基于目标账户对应的至少一种个性化限额对象类型全行级限额对象类型，确定至少一个第二限额场景信息，同理地，每个第二限额场景信息可分别对应一个限额信息，一种全行级限额对象类型可能对应一个或多个第二限额场景。

本申请实施例中，可以将上述账务交易的交易场景信息分别与至少一个第二限额场景信息进行比对，在至少一个第二限额场景信息中确定出与账务交易匹配的目标第二限额场景信息。在确定出目标第二限额场景信息后，进一步确定目标第二限额场景信息的第二限额信息。

本申请实施例中，若在至少一个第二限额场景信息中无法确定出与账务交易匹配的目标第二限额场景信息，即至少一个第二限额场景信息均与交易场景信息不匹配，则可以结束限额检查流程，执行账务交易的后续处理。

需要说明的是，账务交易的账户相关信息、交易场景信息和实际交易额可以统称为交易相关信息，其中，各交易相关信息可以是一次性一起获取的，也可以是分别获取的，本领域技术人员可以根据实际情况进行设置，本申请实施例在此不做限定。

不难理解的是，个性化限额对象类型的限额业务与全行级限额对象类型的限额业务可能会有交叉(即有重叠的场景)，且通常个性化限额对象类型的限额业务会少于或包含于全行级限额对象类型的限额业务，本申请实施例提供的信息处理方法，通过先对个性化限额对象类型的限额业务进行判断，可以一定程度上减少数据的处理量，有效提升限额检查的处理速度。同时，通过对个性化限额对象类型的限额业务和全行级限额对象类型的限额业务的分别判断，并且对于确定出与账务交易场景不匹配的限额场景不再进行限额检查，能够避免对限额场景的重复检查，进一步提升限额检查的处理速度。

本申请实施例中，提供了一种限额检测模型，能够用于上述步骤S102、步骤S103(可包括步骤S1031和步骤S1032)、步骤S104、步骤S105(可包括步骤S1051和步骤S1052)中的至少一个步骤。具体地，该限额检测模型是基于对银行相关限额业务场景整合而成的限额数据集进行模型化得到的。其中，该限额检测模型将限额业务按照对象(对应限额对象类型)、限额(对应限额信息)、维度(对应限额场景信息中的场景要素)三个模块进行拆分，每个模块的细分内容可以参见上文中对对应信息的介绍，此处不再赘述。

本申请实施例中，通过表1所示的限额定义表，示出了限额检测模型对应的3个模块的内容，其中，限额对象类型(表1中的对象模块)、限额信息(信息表1中的限额模块)和限额场景信息(表1中的场景模块)，均与唯一限额编号(也可称为限额场景编号)相关联：

表1

其中，限额对象类型可根据码值自由扩展，无需改变模型(表)结构。可以看到，本申请实施例提供的限额检测模型，包括每个限额场景与所属的限额对象类型的关联关系(可用于步骤S1031和步骤S1051)、每个限额场景及其限额信息的关联关系(可用于步骤S1032和步骤S1052)、每个限额场景及其场景要素的关联关系(可用于步骤S1032和步骤S1052)等。即限额检测模型直接按照限额编号集成了上述3个模块的信息(将限额对象类型和限额场景信息集成到限额定义表这一张表中)，无需二次获取或查询限额对象绑定的场景，以及场景相关的信息，有效提升限额检查的处理速度。

本申请实施例中，若需要扩展场景，可增加限额编号及其限额定义表，亦可直接在限额定义表中增加对应场景字段等，但不限于此。基于此，本申请实施例提供的限额检测模型适用性广，可以适配绝大多数限额业务，且灵活度高，通过简单的配置和少量的扩展便可满足场景扩展需求。

本申请实施例中，为步骤S1031提供了一种可行的实施方式，具体地，基于至少一种个性化限额对象类型，确定至少一个第一限额场景信息，可以包括：基于至少一种个性化限额对象类型的优先级，依次确定对应的第一限额场景信息。

进一步地，在步骤S1032中，若在至少一个第一限额场景信息中包括多个与账务交易匹配的第一限额场景信息，则基于至少一种个性化限额对象类型的优先级，在多个与账务交易匹配的第一限额场景信息中确定目标第一限额场景信息。

可选地，个性化限额对象类型的优先级从高到低依次为：客户号、客户账号、产品账号。简单来说，优先级等级是客户号>客户账号>产品账号。

即本申请实施例中，个性化限额对象类型的匹配中也存在先后关系。若存在高层次(即优先级更高)的限额对象类型，则以高层次对象为准进行限额。

作为示例地，根据账户相关信息，确定目标账户是否设置有限额对象类型为客户号的限额场景。若是，则获取客户号限额对应的第一限额场景信息，在客户号限额对应的第一限额场景信息中确定出与账务交易匹配的目标第一限额场景信息，若目标账户没有设置限额对象类型为客户号的限额场景，或者在客户号限额对应的第一限额场景信息中没有与账务交易匹配的目标第一限额场景信息，或者根据客户号限额对应的目标第一限额场景信息的第一限额信息确定账务交易没有超出限额，则确定目标账户是否设置有限额对象类型为客户账号的限额场景，后续步骤依次类推，在此不再赘述。

那么对于本申请实施例，在确定出目标账户没有设置限额对象类型为产品账号的限额场景，或者在产品账号限额对应的第一限额场景信息中没有与账务交易匹配的目标第一限额场景信息，或者根据产品账号限额对应的目标第一限额场景信息的第一限额信息确定账务交易没有超出限额，再直接执行步骤S104的相关步骤。

其他实施例中，以高层次对象为准进行限额的实施方式并不限于上述示例，也可以采用其他方式。

本申请实施例中，为步骤S1051提供了一种可行的实施方式，具体地，基于至少一种全行级限额对象类型，确定至少一个第二限额场景信息，可以包括：基于至少一种全行级限额对象类型分别相关联的个性化限额对象类型的优先级，依次确定对应的第二限额场景信息。

进一步地，在步骤S1052中，若在至少一个第二限额场景信息中包括多个与账务交易匹配的第二限额场景信息，则基于至少一种全行级限额对象类型分别相关联的个性化限额对象类型的优先级，在多个与账务交易匹配的第二限额场景信息中确定目标第一限额场景信息。

本申请实施例中，客户号与名单类型相关联；客户账号与介质类型相关联；产品账号与产品类型相关联，其中，个性化限额对象类型的优先级从高到低依次为：客户号、客户账号、产品账号。简单来说，优先级等级是名单类型>介质类型>产品类型。

同理地，本申请实施例中，全行级限额对象类型的匹配中也存在先后关系。若存在高层次的限额对象类型，则以高层次对象为准进行限额。

作为示例地，根据账户相关信息，确定目标账户是否设置有限额对象类型为目标账户的名单类型的限额场景。若是，则获取名单限额对应的第二限额场景信息，在名单限额对应的第二限额场景信息中确定出与账务交易匹配的目标第二限额场景信息，若目标账户没有设置限额对象类型为名单类型的限额场景，或者在名单限额对应的第二限额场景信息中没有与账务交易匹配的目标第二限额场景信息，或者根据名单限额对应的目标第二限额场景信息的第二限额信息确定账务交易没有超出限额，则确定目标账户是否设置有限额对象类型为介质类型的限额场景，后续步骤依次类推，在此不再赘述。

那么对于本申请实施例，在确定出目标账户没有设置限额对象类型为产品类型的限额场景，或者在产品限额对应的第二限额场景信息中没有与账务交易匹配的目标第二限额场景信息，或者根据产品限额对应的目标第二限额场景信息的第二限额信息确定账务交易没有超出限额，则可以结束限额检查流程，执行账务交易的后续处理。

其他实施例中，以高层次对象为准进行限额的实施方式并不限于上述示例，也可以采用其他方式。

本申请实施例中，根据账户相关信息，确定目标账户是否对应至少一种个性化限额对象类型的方式，可以是根据账户相关信息，与限额范围类型为指定对象类型的限额对象类型的限额值进行匹配，确定目标账户是否对应至少一种个性化限额对象类型，指定对象表征目标账号为与相应限额对象类型相关联的单个客户。

结合上述表1所示的限额检测模型，以客户号为例，若根据账户相关信息中包括的目标客户号，基于限额检测模型(对象模块)查询到某个限额编号对应的限额范围为指定对象类型，且该限额编号对应的对象类型为客户号，对象值为该目标客户号，则可以确定目标账户包括个性化限额对象类型为客户号的限额业务，且该限额编号对应的限额场景信息为一个第一限额场景信息。其他个性化限额对象类型以此类推，在此不再赘述。

本申请实施例中，根据账户相关信息，确定目标账户是否对应至少一种全行级限额对象类型的方式，可以是根据账户相关信息，与限额范围类型为全部对象的限额对象类型的限额值进行匹配，确定目标账户对应的至少一种全行级限额对象类型，全部对象类型表征目标账号属于与相应限额对象类型相关联的客户之一，限额范围类型为全部对象的限额对象类型的限额值包括与相应限额对象类型相关联的多个客户信息。

结合上述表1所示的限额检测模型，以名单类型为例，某限额编号对应的对象类型为名单类型，则该限额编号对应的限额范围为全部对象类型，该限额编号对应的对象值为多个客户号，可以基于限额检测模型(对象模块)查询该限额编号对应的对象值中是否有目标账户的账户相关信息中包括的目标客户号，即需要将目标客户号与该多个客户号进行匹配，确定该多个客户号中是否有客户号与目标客户号相同。若是，则可以确定目标账户包括全行级限额对象类型为名单类型的限额业务，且该限额编号对应的限额场景信息为一个第二限额场景信息。其他全行级限额对象类型以此类推，在此不再赘述。

本申请实施例中，针对第一限额场景信息和第二限额场景信息中的每种限额场景信息，即针对步骤S1031和步骤S1051中相同的处理过程，也就是在至少一个限额场景信息中确定出与账务交易匹配的目标限额场景信息的过程，可以包括：获取账务交易的交易场景信息；将交易场景信息中的场景要素与至少一个限额场景信息中的场景要素进行一一匹配；将场景要素均匹配成功的限额场景信息确定为与账务交易匹配的目标限额场景信息。

结合上述表1所示的限额检测模型，场景要素可以是指表1中场景模块的各种要素信息。若确定出某限额编号对应的限额场景信息为一个第一限额场景信息或一个第二限额场景信息，则将该限额编号对应的限额场景信息中的场景要素与交易场景信息中的场景要素进行一一匹配，确定是否能够全部匹配上。若是，则将该限额编号对应的场景确定为与账务交易匹配的目标限额场景。否则可以确定场景不满足，此该限额编号对应的场景不再进行限额检查。

本申请实施例中，针对第一限额信息和第二限额信息中的每种限额信息，即针对步骤S104和步骤S106中相同的处理过程，也就是根据限额信息，确定账务交易是否超出限额的过程，可以包括：获取账务交易的实际交易额以及限额信息对应的限额场景在其限额周期内的累计交易额；将实际交易额与累计交易额进行汇总；比对汇总结果和限额信息，确定账务交易是否超出限额。

本申请实施例中，限额信息对应的限额场景在其限额周期内的累计交易额可以通过如下表2所示的限额累计表进行记录和查询：

字段名称	字段码值	字段描述
			限额编号		限额编号+对象值，构成唯一索引
对象值		具体账号
			已累计额度		金额或者次数累计额
上次限额日期		记录上次累计限额的日期，检查是否跨周期

表2

结合上述表1所示的限额检测模型，限额信息可以是指表1中限额模块记录的限额信息。若确定出某限额编号对应的限额信息为一个第一限额信息或一个第二限额信息，需要先将当前场景的实际交易额与历史累计交易额进行汇总，再与设定的该限额编号对应的限额信息进行比较，确定账务交易是否超出限额。

作为示例地，以限额信息包括累计交易金额的限额为例，根据该限额编号以及表1中目标账户对应该限额编号的对象值查询表2，获取已累计交易金额和上次限额日期，确定该限额编号对应的限额场景在其限额周期内的历史累计交易金额，将当前场景的实际交易今额与历史累计交易金额进行汇总，判断汇总结果是否超出该限额编号对应的限额信息，其他类型的限额信息以此类推，在此不再赘述。

本申请实施例中，若结束限额检查流程，执行账务交易的后续处理后该账务交易成功，则需要将此次账务交易的交易信息更新到表2中，以便下次限额检测的可靠执行。

本申请实施例中，通过图2示出了银行账务交易的限额检查流程的一个完整示例，具体地，主要包括以下步骤：

(1)在限额检测模型构建阶段，进行全行级限额参数配置和个性化限额参数配置，限额检测模型构建完成后，基于限额检测模型进行限额检查。

(2)当有账户发生账务交易时，账务交易数据会存入支取组件，进而便可将该账户作为目标账户执行下述限额检查。

(3)查询目标账户是否设置限额，首先检查客户的个性化限额设置(即针对个性化限额对象类型进行检查)，在个性化限额设置检查完后，确定交易额没有超出限额额度，则再检查全行级限额设置(即针对全行级限额对象类型进行检查)。其中，对于个性化限额设置检查，客户号限额优先级高于客户账号限额，客户账号限额优先级高于产品账号限额，若存在优先级高的限额设置，则以优先级高的限额设置为准进行限额；同理地，对于全行级限额设置，名单限额优先级高于介质限额，介质限额优先级高于产品账号，若存在优先级高的限额设置，则以优先级高的限额设置为准进行限额。

(4)对于每种对象类型的限额设置，检查交易场景与设置的限额场景是否匹配，即交易场景发送的场景要素与匹配对象类型设定的场景要素一一匹配，若能全部匹配上，则需要对匹配对象类型设定的此场景进行下一步的限额检查，否则场景不满足，此场景不再进行限额检查。

(5)对于与交易场景匹配上的场景的下一步限额检查，可以获取该场景的限额信息，例如是否设置了金额限制，若是则计算累计交易金额，并与交易场景的交易金额进行汇总来判断交易额是否在限额额度内；或者是否设置了次数限制，若是则计算累计交易次数，并将此次交易场景作为一次交易次数进行叠加，来判断交易额是否在限额额度内；或者是否设置了额度限制，若是则计算交易后账户余额(可以只针对贷方交易进行计算，也可以不限于此)，来判断交易额是否在限额额度内。

(6)重复执行上述(3)、(4)、(5)的步骤，直至检查出此次账务交易超出设置的额度，则进行提示报错，或者直至已检查完全部限额对象均未超出设置的额度，则可以结束限额检查流程，执行账务交易的后续处理。

本申请实施例中，通过图3给出部分上述限额检查流程的使用场景，具体地，可以包括但不限于以下场景：

(1)商业银行个性化限额，包括但不限于渠道限额、名单限额、公私互转限额等；

(2)央行规定的限额，包括但不限于Ⅱ/Ⅲ类账户限额、ATM限额、第三方支付限额等；

(3)客户自定义限额，包括但不限于单位结算卡限额、副卡限额、时间地点限额等。

需要说明的是，商业银行个性化限额和央行规定的限额的场景属于全行级限额对象类型对应的限额场景，客户自定义限额的场景属于个性化限额对象类型对应的限额场景，但不限于此。

本申请实施例提供了一种信息处理装置，如图4所示，该信息处理装置40可以包括：获取模块401、对象类型确定模块402、限额确定模块403以及超额判定模块404，其中，

获取模块401用于获取发生账务交易的目标账户的账户相关信息；

对象类型确定模块402用于根据账户相关信息，确定目标账户对应的至少一种个性化限额对象类型；

限额确定模块403用于基于至少一种个性化限额对象类型，确定第一限额信息；

对象类型确定模块402还用于若根据第一限额信息，确定账务交易未超出限额，则根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型；

限额确定模块403还用于基于至少一种全行级限额对象类型，确定第二限额信息；

超额判定模块404，用于根据第二限额信息，确定账务交易是否超出限额。

在一种可选的实施方式中，限额确定模块403在用于基于至少一种个性化限额对象类型，确定第一限额信息时，具体用于：

基于至少一种个性化限额对象类型，确定至少一个第一限额场景信息；

在至少一个第一限额场景信息中确定出与账务交易匹配的目标第一限额场景信息，并确定目标第一限额场景信息的第一限额信息；

在一种可选的实施方式中，限额确定模块403在用于基于至少一种全行级限额对象类型，确定第二限额信息时，具体用于：

基于至少一种全行级限额对象类型，确定至少一个第二限额场景信息；

在至少一个第二限额场景信息中确定出与账务交易匹配的目标第二限额场景信息，并确定目标第二限额场景信息的第二限额信息。

在一种可选的实施方式中，在获取模块401获取发生账务交易的目标账户的账户相关信息之后，对象类型确定模块402还用于若根据账户相关信息，确定出目标账户未对应个性化限额对象类型，则直接执行根据账户相关信息，确定目标账户对应的至少一种全行级限额对象类型的步骤。

在一种可选的实施方式中，限额确定模块403在用于基于至少一种个性化限额对象类型，确定至少一个第一限额场景信息时，具体用于：基于至少一种个性化限额对象类型的优先级，依次确定对应的第一限额场景信息；

限额确定模块403在用于在至少一个第一限额场景信息中确定出与账务交易匹配的目标第一限额场景信息时，具体用于：若在至少一个第一限额场景信息中包括多个与账务交易匹配的第一限额场景信息，则基于至少一种个性化限额对象类型的优先级，在多个与账务交易匹配的第一限额场景信息中确定目标第一限额场景信息。

在一种可选的实施方式中，限额确定模块403在用于基于至少一种全行级限额对象类型，确定至少一个第二限额场景信息时，具体用于：基于至少一种全行级限额对象类型分别相关联的个性化限额对象类型的优先级，依次确定对应的第二限额场景信息；

限额确定模块403在用于在至少一个第二限额场景信息中确定出与账务交易匹配的目标第二限额场景信息时，具体用于：若在至少一个第二限额场景信息中包括多个与账务交易匹配的第二限额场景信息，则基于至少一种全行级限额对象类型分别相关联的个性化限额对象类型的优先级，在多个与账务交易匹配的第二限额场景信息中确定目标第一限额场景信息。

在一种可选的实施方式中，个性化限额对象类型包括以下至少一种：客户号、客户账号、产品账号；

全行级限额对象类型包括以下至少一种：名单类型、介质类型、产品类型；

其中，客户号与名单类型相关联；

客户账号与介质类型相关联；

产品账号与产品类型相关联。

在一种可选的实施方式中，个性化限额对象类型的优先级从高到低依次为：客户号、客户账号、产品账号。

在一种可选的实施方式中，该信息处理装置40还可以包括对象匹配模型405，用于根据账户相关信息，确定目标账户是否对应至少一种个性化限额对象类型。

其中，对象匹配模型405具体用于根据账户相关信息，与限额范围类型为指定对象类型的限额对象类型的限额值进行匹配，确定目标账户是否对应至少一种个性化限额对象类型，指定对象表征目标账号为与相应限额对象类型相关联的单个客户。

在一种可选的实施方式中，对象匹配模型405还用于根据账户相关信息，确定目标账户是否对应至少一种全行级限额对象类型。

其中，对象匹配模型405具体用于根据账户相关信息，与限额范围类型为全部对象的限额对象类型的限额值进行匹配，确定目标账户对应的至少一种全行级限额对象类型，全部对象类型表征目标账号属于与相应限额对象类型相关联的客户之一，限额范围类型为全部对象的限额对象类型的限额值包括与相应限额对象类型相关联的多个客户信息。

在一种可选的实施方式中，针对第一限额场景信息和第二限额场景信息中的每种限额场景信息，限额确定模块403在用于在至少一个限额场景信息中确定出与账务交易匹配的目标限额场景信息时，具体用于：

获取账务交易的交易场景信息；

将交易场景信息中的场景要素与至少一个限额场景信息中的场景要素进行一一匹配；

将场景要素均匹配成功的限额场景信息确定为与账务交易匹配的目标限额场景信息。

在一种可选的实施方式中，针对第一限额信息和第二限额信息中的每种限额信息，超额判定模块404在用于根据限额信息，确定账务交易是否超出限额时，具体用于：

获取账务交易的实际交易额以及限额信息对应的限额场景在其限额周期内的累计交易额；

将实际交易额与累计交易额进行汇总；

比对汇总结果和限额信息，确定账务交易是否超出限额。

本申请实施例的装置可执行本申请实施例所提供的方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述以及产生的有效效果具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

本申请实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现前述各实施例的方法中的步骤。

在一种可选的实施方式中，提供了一种电子设备，如图5所示，图5所示的电子设备500包括：处理器501和存储器503。其中，处理器501和存储器503相连，如通过总线502相连。可选地，电子设备500还可以包括收发器504，收发器504可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器504不限于一个，该电子设备500的结构并不构成对本申请实施例的限定。

处理器501可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器501也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线502可包括一通路，在上述组件之间传送信息。总线502可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线502可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器503可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器503用于存储执行本申请实施例的计算机程序，并由处理器501来控制执行。处理器501用于执行存储器503中存储的计算机程序，以实现前述方法实施例所示的步骤。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (12)

1.一种交易处理方法，其特征在于，包括：

获取发生账务交易的目标账户的账户相关信息；

根据所述账户相关信息，确定所述目标账户对应的至少一种个性化限额对象类型；

基于所述至少一种个性化限额对象类型，确定第一限额信息；

若根据所述第一限额信息，确定所述账务交易未超出限额，则根据所述账户相关信息，确定所述目标账户对应的至少一种全行级限额对象类型；

基于所述至少一种全行级限额对象类型，确定第二限额信息；

根据所述第二限额信息，确定所述账务交易是否超出限额。

2.根据权利要求1所述的信息处理方法，其特征在于，所述基于所述至少一种个性化限额对象类型，确定第一限额信息，包括：

基于所述至少一种个性化限额对象类型，确定至少一个第一限额场景信息；

在所述至少一个第一限额场景信息中确定出与所述账务交易匹配的目标第一限额场景信息，并确定所述目标第一限额场景信息的第一限额信息；

所述基于所述至少一种全行级限额对象类型，确定第二限额信息，包括：

基于所述至少一种全行级限额对象类型，确定至少一个第二限额场景信息；

在所述至少一个第二限额场景信息中确定出与所述账务交易匹配的目标第二限额场景信息，并确定所述目标第二限额场景信息的第二限额信息。

3.根据权利要求1所述的信息处理方法，其特征在于，在获取发生账务交易的目标账户的账户相关信息的步骤之后，所述方法还包括：

若根据所述账户相关信息，确定出所述目标账户未对应个性化限额对象类型，则直接执行所述根据所述账户相关信息，确定所述目标账户对应的至少一种全行级限额对象类型的步骤。

4.根据权利要求2所述的信息处理方法，其特征在于，所述基于所述至少一种个性化限额对象类型，确定至少一个第一限额场景信息，包括：

基于所述至少一种个性化限额对象类型的优先级，依次确定对应的第一限额场景信息；

所述在所述至少一个第一限额场景信息中确定出与所述账务交易匹配的目标第一限额场景信息，包括：

若在所述至少一个第一限额场景信息中包括多个与所述账务交易匹配的第一限额场景信息，则基于所述至少一种个性化限额对象类型的优先级，在所述多个与所述账务交易匹配的第一限额场景信息中确定所述目标第一限额场景信息。

5.根据权利要求2所述的信息处理方法，其特征在于，所述基于所述至少一种全行级限额对象类型，确定至少一个第二限额场景信息，包括：

基于所述至少一种全行级限额对象类型分别相关联的个性化限额对象类型的优先级，依次确定对应的第二限额场景信息；

所述在所述至少一个第二限额场景信息中确定出与所述账务交易匹配的目标第二限额场景信息，包括：

若在所述至少一个第二限额场景信息中包括多个与所述账务交易匹配的第二限额场景信息，则基于所述至少一种全行级限额对象类型分别相关联的个性化限额对象类型的优先级，在多个与所述账务交易匹配的第二限额场景信息中确定所述目标第一限额场景信息。

6.根据权利要求1所述的信息处理方法，其特征在于，所述个性化限额对象类型包括以下至少一种：客户号、客户账号、产品账号；

所述全行级限额对象类型包括以下至少一种：名单类型、介质类型、产品类型；

其中，客户号与名单类型相关联；

客户账号与介质类型相关联；

产品账号与产品类型相关联。

7.根据权利要求6所述的信息处理方法，其特征在于，所述个性化限额对象类型的优先级从高到低依次为：所述客户号、所述客户账号、所述产品账号。

8.根据权利要求1所述的信息处理方法，其特征在于，根据所述账户相关信息，确定所述目标账户是否对应至少一种个性化限额对象类型，包括：

根据所述账户相关信息，与限额范围类型为指定对象类型的限额对象类型的限额值进行匹配，确定所述目标账户是否对应至少一种个性化限额对象类型，所述指定对象表征所述目标账号为与相应限额对象类型相关联的单个客户。

9.根据权利要求8所述的信息处理方法，其特征在于，根据所述账户相关信息，确定所述目标账户是否对应至少一种全行级限额对象类型，包括：

根据所述账户相关信息，与限额范围类型为全部对象的限额对象类型的限额值进行匹配，确定所述目标账户对应的至少一种全行级限额对象类型，所述全部对象类型表征所述目标账号属于与相应限额对象类型相关联的客户之一，所述限额范围类型为全部对象的限额对象类型的限额值包括与相应限额对象类型相关联的多个客户信息。

10.根据权利要求2所述的信息处理方法，其特征在于，针对第一限额场景信息和第二限额场景信息中的每种限额场景信息，在至少一个限额场景信息中确定出与所述账务交易匹配的目标限额场景信息，包括：

获取所述账务交易的交易场景信息；

将所述交易场景信息中的场景要素与所述至少一个限额场景信息中的场景要素进行一一匹配；

将场景要素均匹配成功的限额场景信息确定为与所述账务交易匹配的目标限额场景信息。

11.根据权利要求2所述的信息处理方法，其特征在于，针对第一限额信息和第二限额信息中的每种限额信息，根据限额信息，确定所述账务交易是否超出限额，包括：

获取所述账务交易的实际交易额以及所述限额信息对应的限额场景在其限额周期内的累计交易额；

将所述实际交易额与所述累计交易额进行汇总；

比对所述汇总结果和所述限额信息，确定所述账务交易是否超出限额。

12.一种信息处理装置，其特征在于，包括：

获取模块，用于获取发生账务交易的目标账户的账户相关信息；

对象类型确定模块，用于根据所述账户相关信息，确定所述目标账户对应的至少一种个性化限额对象类型；

限额确定模块，用于基于所述至少一种个性化限额对象类型，确定第一限额信息；

对象类型确定模块还用于若根据所述第一限额信息，确定所述账务交易未超出限额，则根据所述账户相关信息，确定所述目标账户对应的至少一种全行级限额对象类型；

限额确定模块还用于基于所述至少一种全行级限额对象类型，确定第二限额信息；

超额判定模块，用于根据所述第二限额信息，确定所述账务交易是否超出限额。

Images