CN116468551A - 一种金融业务管理方法、系统、计算机和可读存储介质 - Google Patents

Abstract

本申请涉及通信技术领域，尤其涉及一种金融业务管理方法、系统、计算机和可读存储介质，该方法包括：接收预授权请求，并获取所述预授权请求对应的账户ID，所述预授权请求包括预授权额度；基于所述账户ID，得到所述账户的当前可用额度；基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号；当接收到放款交易请求时，基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作。本申请中的方法能不仅降低系统的复杂度，减少工作量，提升效率，还便于后续的维护和拓展。

Description

一种金融业务管理方法、系统、计算机和可读存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种金融业务管理方法、系统、计算机和可读存储介质。

背景技术

在金融科技领域中，用户申请贷款额度受可用额度限制，而贷款预授权现象的存在，使得预约放款需提前扣减此部分额度已保证预约放款日时可正常下发贷款。但是，现有技术方案中在用户申请贷款时会将预约放款的金额直接累计到已用额度字段上，而预约放款金额实际并未产生真实的资金交易，累加到已用额度字段上导致字段含义不明，下游系统取数分析或报送需要额外处理，增加了工作量。

发明内容

鉴于上述问题，本申请提出一种金融业务管理方法、系统、计算机和可读存储介质。

本申请实施例提出一种金融业务管理方法，包括：

接收预授权请求，并获取所述预授权请求对应的账户ID，所述预授权请求包括预授权额度；

基于所述账户ID，得到所述账户的当前可用额度；

基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号；

当接收到放款交易请求时，基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作。

进一步地，在上述的金融业务管理方法中，所述预授权额度对应有状态标签，所述基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号，包括：

若所述当前可用额度不小于所述预授权额度，则将所述状态标签设置为已占用；

生成并返回所述预授权额度对应的额度授权流水号。

进一步地，在上述的金融业务管理方法中，所述基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作，包括：

若所述放款交易请求中未含有所述额度授权流水号，则基于所述放款交易请求进行放款操作；

若所述放款交易请求中含有所述额度授权流水号，则基于所述额度授权流水号进行放款操作。

进一步地，在上述的金融业务管理方法中，所述基于所述额度授权流水号进行放款操作，包括：

基于所述额度授权流水号，查询对应所述状态标签是否为已占用；

若所述状态标签为已占用，则将所述状态标签更新为已释放，并确认允许放款操作；

若所述状态标签不为已占用，则确认不允许放款操作。

进一步地，在上述的金融业务管理方法中，所述账户ID关联有账户表和额度表，所述账户表中包括若干个账户ID和每个账户ID对应的占用预授权额度；所述额度表包括若干种类的产品，每个所述预授权额度对应一个产品种类，每种产品关联有若干个预授权额度；所述方法还包括：

若所述当前可用额度不小于所述预授权额度，则将所述预授权额度增加至所述占用预授权额度，和所述额度表中对应的产品下；

若所述状态标签为已占用，则将所述占用预授权额度中对应的预授权额度，以及所述额度表中对应的预授权额度进行删除。

进一步地，在上述的金融业务管理方法中，所述当前可用额度的计算公式为：

K=S-Y-Z；

其中，K为当前可用额度，S为所述账户当前的授信额度，Y为所述账户的已用额度，Z为所述账户当前总占用预授权额度，所述总占用预授权额度为当前所有已占有的预授权额度之和。

进一步地，在上述的金融业务管理方法中，还包括：

记录所述账户的所有额度变更信息，并基于所述额度变更信息，生成并存储所述账户的会计账单。

本申请的另一实施例还提出一种贷款额度管理系统，包括：

接收单元，用于接收预授权请求，并获取所述预授权请求对应的账户ID，所述预授权请求包括预授权额度；

计算单元，用于基于所述账户ID，得到所述账户的当前可用额度；

返回单元，用于基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号；

放款单元，用于当接收到放款交易请求时，基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作。

本申请的另一实施例还提出一种计算机，包括存储单元和处理单元，所述存储单元中存储有计算机程序，所述处理单元通过调用所述存储单元中存储的所述计算机程序，执行如上述的金融业务管理方法的步骤。

本申请的另一实施例还提出一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于处理器进行加载，以执行如上述的金融业务管理方法的步骤。

本申请的实施例具有以下的有益效果：

本申请实施例提出一种金融业务管理方法，通过将预授权额度独立出来，使得使用额度划分成2个原子逻辑，分别为已用额度和预授权额度，而不再是一个原子逻辑。已用额度的基础功能可继续保持，借款主流程也无需改动，2个原子逻辑都独立又关联，便于后续的维护和拓展，同时也降低系统的复杂度，减少工作量。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对本申请保护范围的限定。在各个附图中，类似的构成部分采用类似的编号。

图1示出了本申请一些实施方式的金融业务管理方法的第一流程示意图；

图2示出了本申请一些实施方式的金融业务管理方法的第二流程示意图；

图3示出了本申请一些实施方式的金融业务管理方法的第三流程示意图；

图4示出了本申请一些实施方式的金融业务管理方法的第四流程示意图；

图5示出了本申请一些实施方式的金融业务管理系统的结构示意图。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在下文中，可在本申请的各种实施例中使用的术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。

此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本申请的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本申请的各种实施例中被清楚地限定。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互结合。

通常地，将预约放款金额和已用额度混为一谈，不仅导致下游系统取数分析或报送需要额外处理，还会在某些特殊场景预授权失败需回滚已用额度，并发正常借款流程时，导致额度字段冲突增加交易失败的概率，同时额度使用逻辑混杂一起，增加系统各方面的复杂度，不易后续维护和扩展。

因此，为了解决上述的问题，本申请提出可适用于金融科技领域和其他领域的金融业务管理方法。

请参照图1，为本申请实施例提出的金融业务管理方法的一种流程示意图。示范性地，该金融业务管理方法应用于管理贷款额度的管理平台中。

在一些实施方式中，如图1所示，一种金融业务管理方法包括：

S110，接收预授权请求，并获取预授权请求对应的账户ID，预授权请求包括预授权额度。

具体地，当用户需要预授权贷款时，则会发送预授权请求，该预设全请求中包括需要贷款的额度（即预授权额度）和用户的ID。当系统接收到该预授权请求时，则会从预授权请求中提取账户ID，找到账户ID关联的账户ID，其中，账户ID包括账户ID、能贷款的额度（即授信额度）和已用贷款额度（即已用额度）等。

进一步地，为了保证因网络抖动或客户前端错误操作或其他原因产生重复的请求时都能得到一致的结果。需要对接收都的预授权请求进行交易幂等检查。交易幂等检查是根据预授权请求中的交易请求流水号和交易码作为唯一标识来检索数据库中是否已有记录，识别交易是否重复交易，若是已有的交易则直接返回原交易结果，若没有则继续后续的操作。

S210，基于账户ID，得到账户的当前可用额度。

当获取账户ID时，通过账户ID从账户表中找到该账户ID对应的授信额度、已用额度和占用预授权额度，并基于上述获取的数据计算得到该用户的可用额度。其中，账户表包括若干个账户ID和每个账户ID对应的占用预授权额度。需要说明得是，一个账户ID对应有m个预授权额度，m为大于等于0的整数。占用预授权额度为已通过验证后被授权的预贷款额度，代表在后续的规定时刻根据该占用预授权额度进行放款。

示范性地，若当前用户需要贷款50万，则预授权额度为50万，当通过验证后，则该预授权额度50万则为占用预授权额度。

进一步地，在一些实施方式的金融业务管理方法中，当前可用额度的计算公式为：

K=S-Y-Z；

其中，K为当前可用额度，S为账户当前的授信额度，Y为账户的已用额度，Z为账户当前总占用预授权额度，总占用预授权额度为当前所有已占有的预授权额度之和。

示范性地，一个账户ID可能关联有多个占用预授权额度，例如ID666关联有50万的占用预授权额度A、30万的占用预授权额度B，则ID666的当前总占用预授权额度为80万。若该账户当前的授信额度为200万，而当前已经放款60万，则当前可用额度为60万。当然当前授信额度可随时调整，即使当前的总占用预授权额度和已用额度不变，不同时间的可用额度也可能不一样。

S310，基于当前可用额度和预授权额度，生成并返回对应的额度授权流水号。

具体地，预授权额度通过验证后即可授权，授权后都会生成唯一一个额度授权流水号，即每个授权后的预授权额度对应唯一一个额度授权流水号。然后将该额度授权流水号返回至对应的系统，当到达预先设定的时间时，则会产生放款交易请求，该放款交易请求中包括该额度授权流水号。

在一些实施方式的金融业务管理方法中，如图2所示，预授权额度对应有状态标签，基于当前可用额度和预授权额度，生成并返回对应的额度授权流水号，包括：

S311，若当前可用额度不小于预授权额度，则将状态标签设置为已占用。

S312，生成并返回预授权额度对应的额度授权流水号。

具体地，对预授权额度进行验证即判断预授权额度是否小于等于当前可用额度，若是，则验证通过，当状态标签设置为已占用时，则代表该预授权额度已被授权。

S410，当接收到放款交易请求时，基于放款交易请求和额度授权流水号，以控制对所述账户的放款操作。

具体地，考虑到接收到的放款交易请求有两类，第一类是非预授权额度占用，第二类是预授权额度占用。因此需要根据放款交易请求和额度授权流水号来进行不同类别的放款流程。

在一些实施方式的金融业务管理方法中，如图3所示，基于放款交易请求和额度授权流水号，对账户进行放款，包括：

S411，若放款交易请求中未含有额度授权流水号，则基于放款交易请求进行放款操作。

具体地，由于有的放款交易请求并不是预授权的交易请求，而是普通的交易请求，因此，当放款交易请求中未含有额度授权流水号时，则判定为非预授权额度占用，则提取放款交易请求中的关键字段，根据这些关键字段进行放款操作。其中，关键字段包括账户ID、放款金额、借款套餐、优惠折扣、出资机构等字段。

进一步地，当提取出关键字段后，基于这些关键字段生成借据相关信息并持久化至数据库中，其中，借据相关信息包括借据信息、还款计划和优惠折扣等信息。

将本次借款交易的相关数据持久化至数据库中。然后更新账户表中最近一次的借款日期和最近一次借款交易流水等信息。基于上述的借款日期、借款交易流水等信息，生成会记账单，并创建支付订单。对该账户ID对应的已用额度进行更新。最后，将预授权额度（放款金额）对应的资金放款至用户的预设账户中。

S412，若放款交易请求中含有额度授权流水号，则基于额度授权流水号进行放款操作。

具体地，若放款交易请求中含有额度授权流水号，则判定为预授权额度占用，则基于额度授权流水号进一步地进行确认是否允许放款操作。

在一些实施方式的金融业务管理方法中，如图4所示，基于额度授权流水号进行放款操作，包括：

S4121，基于额度授权流水号，查询对应状态标签是否为已占用。

具体地，由于预授权额度对应有唯一的额度授权流水号，因此通过额度授权流水号找到对应的预授权额度，然后再找到预授权额度对应的状态标签，即可查询到对应的标签的状态。

S4122，若状态标签为已占用，则将所述状态标签更新为已释放，并确认允许放款操作。

具体地，状态标签为已占用，则代表该放款交易请求对应的预授权额度是已授权的，且可进行放款的，则确认允许放款操作，然后执行上述普通交易请求的放款逻辑。

S4123，若状态标签不为已占用，则确认不允许放款操作。

具体地，状态标签不为已占用，则代表该放款交易请求不可进行放款。则不允许放款操作。

在一些实施方式的金融业务管理方法中，账户ID关联有账户表和额度表，账户表中包括若干个账户ID和账户ID对应的占用预授权额度，额度表包括若干种类的产品，每个预授权额度对应一个产品种类，每种产品关联有若干个预授权额度，还包括：

若当前可用额度不小于预授权额度，则将预授权额度增加至占用预授权额度，和额度表中对应的产品下。

示范性地，若账户表中有账户E、账户F和账户G，而账户E当前的占用预授权额度有占用预授权额度m和占用预授权额度n，假设当前的预授权额度为预授权额度x，若当前可用额度不小于预授权额度x，则将占用预授权额度x（即预授权额度x）增加至账户E中，此时账户E对应有3个占用预授权额度，分别为占用预授权额度m、占用预授权额度n和占用预授权额度x。

示范性地，若额度表中有三个产品，分别为产品A、产品B和产品C，若产品A对应有三个预授权额度，分别为预授权额度a、预授权额度b和预授权额度c，假设当前的预授权额度为预授权额度d且对应的产品类型为A，则若当前的可用额度不小于预授权额度d，则将预授权额度d增加至产品A下，即此时产品A对应有四个预授权额度，分别为预授权额度a、预授权额度b、预授权额度c和预授权额度d。

进一步地，可将“将预授权额度增加至占用预授权额度，和额度表中对应的产品下”步骤置于上述提到的“则将所述状态标签设置为已占用”步骤之前，也可同时进行。

若状态标签为已占用，则将占用预授权额度中对应的预授权额度，以及额度表中对应的预授权额度进行删除。

示范性地，若账户表中有账户E、账户F和账户G，而账户E当前的占用预授权额度有占用预授权额度m和占用预授权额度n，假设当前的预授权额度为预授权额度m，若预授权额度m的状态标签为已占用，则将占用预授权额度m（即预授权额度m）从账户E中删除，此时账户E对应只有1个占用预授权额度n。

示范性地，若额度表中有三个产品，分别为产品A、产品B和产品C，若产品A对应有三个预授权额度，分别为预授权额度a、预授权额度b和预授权额度c，假设当前的预授权额度为预授权额度b且对应的产品类型为A，则若当前的预授权额度b的状态标签为已占用，则将预授权额度b从额度表中删除，即此时产品A对应有2个预授权额度，分别为预授权额度a和预授权额度c。

在一些实施方式中，金融业务管理方法还包括：

记录账户的所有额度变更信息，并基于额度变更信息，生成并存储账户的会计账单。

具体地，额度变更信息包括账户ID对应的可用额度、授信额度、总占用预授权额度、已用额度、预授权额度等额度的变更，例如预授权额度的状态变更，从空状态变为占用状态，从占用状态变为释放状态等，以及每个额度变更的时间，预授权额度对应的产品等信息。

本申请实施例提出一种金融业务管理方法，从系统交互流程上看，通过将预授权额度独立出来，使得使用额度划分成2个原子逻辑，分别为已用额度和预授权额度，而不再是一个原子逻辑。已用额度的基础功能可继续保持，借款主流程也无需改动，2个原子逻辑都独立又关联，便于后续的维护和拓展，同时也降低系统的复杂度，减少工作量。

从数据结构上看表、字段拆分更细致，数据变更有迹可巡，数据使用更明确，简化对数据库的处理，也便于后续数据分析报送。

从业务场景上看，用户仍然从前端页面选择预约放款，系统收到请求后将预约放款的金额放到预授权额度上，放款日时上游系统依旧调用系统放款接口，系统处理时，先释放预授权额度再处理放款，对用户无感知，不影响用户的体验。

另外，本申请通过账户表独立的计算贷款额度的相关数据，能更好更方便的维护贷款额度相关数据以及后续的算法。同时，本申请还考虑到不同产品的相关贷款数据，因此增加额度表用于统计，便于数据的维护和调用，以及便于相关人员更直观地参考和实施后续的活动。

本申请的另一实施例还提出一种贷款额度管理系统500，如图5所示，系统500包括：

接收单元510，用于接收预授权请求，并获取所述预授权请求对应的账户ID，所述预授权请求包括预授权额度。

计算单元520，用于基于所述账户ID，得到所述账户的当前可用额度。

返回单元530，用于基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号。

放款单元540，用于当接收到放款交易请求时，基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作。

本申请的另一实施例还提出一种计算机，包括存储单元和处理单元，存储单元中存储有计算机程序，处理单元通过调用存储单元中存储的计算机程序，执行上述的金融业务管理方法的步骤。

本申请的另一实施例还提出一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序适于处理器进行加载，以执行上述的金融业务管理方法的步骤。

可以理解，本实施例的方法步骤对应于上述实施例中的金融业务管理方法，其中，上述金融业务管理方法的可选项同样适用于本实施例，这里不再重复描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和结构图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或更多个模块集成形成一个独立的部分。

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

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

Claims (10)

1.一种金融业务管理方法，其特征在于，包括：

接收预授权请求，并获取所述预授权请求对应的账户ID，所述预授权请求包括预授权额度；

基于所述账户ID，得到所述账户的当前可用额度；

基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号；

当接收到放款交易请求时，基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作。

2.根据权利要求1所述的金融业务管理方法，其特征在于，所述预授权额度对应有状态标签，所述基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号，包括：

若所述当前可用额度不小于所述预授权额度，则将所述状态标签设置为已占用；

生成并返回所述预授权额度对应的额度授权流水号。

3.根据权利要求2所述的金融业务管理方法，其特征在于，所述基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作，包括：

若所述放款交易请求中未含有所述额度授权流水号，则基于所述放款交易请求进行放款操作；

若所述放款交易请求中含有所述额度授权流水号，则基于所述额度授权流水号进行放款操作。

4.根据权利要求3所述的金融业务管理方法，其特征在于，所述基于所述额度授权流水号进行放款操作，包括：

基于所述额度授权流水号，查询对应所述状态标签是否为已占用；

若所述状态标签为已占用，则将所述状态标签更新为已释放，并确认允许放款操作；

若所述状态标签不为已占用，则确认不允许放款操作。

5.根据权利要求4所述的金融业务管理方法，其特征在于，所述账户ID关联有账户表和额度表，所述账户表中包括若干个账户ID和每个账户ID对应的占用预授权额度；所述额度表包括若干种类的产品，每个所述预授权额度对应一个产品种类，每种产品关联有若干个预授权额度；所述方法还包括：

若所述当前可用额度不小于所述预授权额度，则将所述预授权额度增加至所述占用预授权额度，和所述额度表中对应的产品下；

若所述状态标签为已占用，则将所述占用预授权额度中对应的预授权额度，以及所述额度表中对应的预授权额度进行删除。

6.根据权利要求2所述的金融业务管理方法，其特征在于，所述当前可用额度的计算公式为：

K=S-Y-Z；

其中，K为当前可用额度，S为所述账户当前的授信额度，Y为所述账户的已用额度，Z为所述账户当前总占用预授权额度，所述总占用预授权额度为当前所有已占有的预授权额度之和。

7.根据权利要求1~6任一项所述的金融业务管理方法，其特征在于，还包括：

记录所述账户的所有额度变更信息，并基于所述额度变更信息，生成并存储所述账户的会计账单。

8.一种贷款额度管理系统，其特征在于，包括：

接收单元，用于接收预授权请求，并获取所述预授权请求对应的账户ID，所述预授权请求包括预授权额度；

计算单元，用于基于所述账户ID，得到所述账户的当前可用额度；

返回单元，用于基于所述当前可用额度和所述预授权额度，生成并返回对应的额度授权流水号；

放款单元，用于当接收到放款交易请求时，基于所述放款交易请求和所述额度授权流水号，以控制对所述账户的放款操作。

9.一种计算机，其特征在于，包括存储单元和处理单元，所述存储单元中存储有计算机程序，所述处理单元通过调用所述存储单元中存储的所述计算机程序，执行如权利要求1至7任一项所述的金融业务管理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于处理器进行加载，以执行如权利要求1至7任一项所述的金融业务管理方法的步骤。