Supplement control method for resource application and related device

Abstract

This application discloses a method and related equipment for supplementary document control in resource applications. The method includes: acquiring application context data of the target resource application; determining a valid stage supplementary document rule set corresponding to the current approval stage based on a preset stage supplementary document rule base when an approval stage change event is determined based on the application context data; performing document status identification processing on the submitted document set in the application context data based on the valid stage supplementary document rule set; generating a valid supplementary document task set for the current approval stage based on the result of the document status identification processing; and outputting a supplementary document control result based on the valid supplementary document task set for the current approval stage. This application uses the approval stage change event as the basis for supplementary document rule switching to trigger supplementary document control, enabling supplementary document requirements to automatically switch with the approval stage. Supplementary document control is more consistent with real approval logic, improving application completion rate and application experience.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method and related equipment for controlling supplementary materials in resource applications. Background Technology

[0002] With the development of online resource allocation services (such as online lending, online services, and credit loans), the corresponding resource application process has gradually shifted from offline manual processing to intelligent online processing. During this intelligent online processing, applicants can submit resource applications through applications (APPs), web pages, or offline data entry points, and upload relevant documents (such as identity verification, contact information, business licenses, and asset certificates). The relevant resource allocation backend then processes the application according to a predetermined approval process, sequentially moving it to different approval stages such as acceptance, preliminary review, secondary review, final review, and pre-disbursement verification.

[0003] The handling of supplementary materials (hereinafter referred to as supplementary documents) in the approval process in related technologies leads to problems such as low approval efficiency, low application completion rate and poor application experience. Summary of the Invention

[0004] To address the problems of existing technologies, this application provides a method and related equipment for controlling supplementary materials in resource applications. The technical solution is as follows: On the one hand, a method for controlling supplementary documents in resource applications is provided, the method comprising: Obtain the application context data of the target resource application; If an approval stage change event is determined based on the application context data, a valid set of supplementary rules for the current approval stage is determined based on a preset supplementary rule base for stage-specific supplementary documents. Based on the valid stage supplementary document rule set, the submitted document set in the application context data is processed for document status identification, and based on the result of the document status identification, the valid supplementary document task set for the current approval stage is generated. Based on the set of valid supplementary documents for the current approval stage, output the supplementary document control result.

[0005] On the other hand, a supplementary document control device for resource requests is provided, the device comprising: The context data acquisition module is used to acquire the application context data of the target resource application; The effective stage supplementary document rule determination module is used to determine the effective stage supplementary document rule set corresponding to the current approval stage based on a preset stage supplementary document rule library when an approval stage change event is determined based on the application context data. The valid supplementary document task generation module is used to perform document status identification processing on the submitted document set in the application context data based on the valid stage supplementary document rule set, and generate the valid supplementary document task set for the current approval stage based on the result of the document status identification processing. The supplementary document control module is used to output supplementary document control results based on the set of valid supplementary document tasks in the current approval stage.

[0006] In some embodiments, the approval stage change events include: forward stage switching events, reverse stage switching events, and intra-stage recalculation events; the apparatus further includes: The approval stage change event determination module is used to determine that an approval stage change event has occurred if any of the forward stage switching event, the reverse stage switching event, or the intra-stage recalculation event is identified based on the application context data.

[0007] In some implementations, each valid stage supplementary document rule includes a target data definition field and multiple dimensions of data status identification fields; the valid supplementary document task generation module includes a data status identification module, which is specifically used for: extracting target data items based on the target data definition fields in each valid stage supplementary document rule to obtain a target data item set; for each target data item in the target data item set, identifying whether there is target submitted data matching the target data item in the submitted data set to obtain an existence identification result; based on the existence identification result and the multiple dimensions of data status identification fields in the valid stage supplementary document rule corresponding to the target data item, performing data status identification on each submitted data item to obtain the data status identification result corresponding to the target data item in the current approval stage; wherein, the data status identification result corresponding to each target data item in the current approval stage constitutes a data status identification result set.

[0008] In some implementations, the application context data further includes a historical supplementary document task set; the valid supplementary document task generation module further includes a task reconstruction module, which is specifically used to: perform candidate supplementary document task generation processing based on the document status indicated by each document status identification result in the document status identification result set, to obtain a candidate supplementary document task item set for the current approval stage; compare the candidate supplementary document task item set for the current approval stage with the historical supplementary document task set, and perform a dynamic reconstruction operation on the historical supplementary document task set based on the comparison result, to obtain a valid supplementary document task set for the current approval stage. The dynamic reconstruction operation includes: task retention operation, task termination operation, task addition operation, task replacement operation, task merging operation, and task priority adjustment operation.

[0009] In some implementations, when the task reconstruction module compares the set of candidate supplementary task items in the current approval stage with the set of historical supplementary task items, and performs a dynamic reconstruction operation on the historical supplementary task set based on the comparison result to obtain the set of valid supplementary task items in the current approval stage, it specifically performs the following: for each candidate supplementary task item in the set of candidate supplementary task items, it identifies the associated historical supplementary task items in the historical supplementary task set that are related to the candidate supplementary task item, and obtains the associated task identification result; based on the associated task identification result, it performs task comparison processing from multiple task comparison dimensions to obtain the task comparison result corresponding to the candidate supplementary task item; the multiple task comparison dimensions include: retention dimension, termination dimension, addition dimension, replacement dimension, merging dimension, and priority adjustment dimension; based on the task comparison result corresponding to each candidate supplementary task item, it performs a dynamic reconstruction operation on the historical supplementary task set to obtain the set of valid supplementary task items in the current approval stage.

[0010] In some implementations, the supplementary document control module is specifically used to: generate a first supplementary document control result, a second supplementary document control result, and a stage progress control result based on the valid supplementary document task set of the current approval stage; the first supplementary document control result indicates the supplementary document name, supplementary document reason, upload entry, document example, and deadline; the second supplementary document control result indicates the task source, rule basis, historical task reconstruction results, and current document completion status; the stage progress control result indicates whether to proceed to the next approval stage; send the first supplementary document control result to the application end of the target resource application via message notification; send the second supplementary document control result to the approval end via interface call; and perform process control on the approval process of the target resource application based on the stage progress control result.

[0011] In some embodiments, the apparatus further includes: The feedback processing module is used to respond to a component feedback event for the component control result and perform feedback processing based on the component feedback event; the feedback processing includes: updating the submitted data set, data status re-identification processing, updating the valid component task set, and stage progress control.

[0012] On the other hand, an electronic device is provided, including a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the supplementary control method for resource requests of any of the above aspects.

[0013] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or the at least one program being loaded and executed by a processor to implement the supplementary control method for resource requests as described in any of the above aspects.

[0014] On the other hand, a computer program product is provided, which includes a computer program that, when executed by a processor, implements the supplementary control method for resource requests according to any of the above aspects.

[0015] This application embodiment obtains the application context data of the target resource application, and then, when an approval stage change event is determined based on the application context data, determines the effective stage supplementary document rule set corresponding to the current approval stage based on a preset stage supplementary document rule base. Based on this effective stage supplementary document rule set, it performs document status identification processing on the submitted document set in the application context data. Based on the result of this document status identification processing, it generates a valid supplementary document task set for the current approval stage, and outputs supplementary document control results based on this valid supplementary document task set for the current approval stage. This allows the approval stage change event to be used as the basis for supplementary document rule switching to trigger supplementary document control, enabling supplementary document requirements to automatically switch with the approval stage. Supplementary document control is more in line with actual approval logic, reducing the excessive collection of documents in the early stages, lowering the applicant's submission costs, reducing the burden on reviewers to handle invalid documents, and improving approval efficiency. Since applicants only need to submit the corresponding documents at the corresponding stage, and the reason for supplementary document matching the stage goal, it is easier to understand the necessity of each supplementary document notification. This avoids problems such as low application completion rate and poor application experience caused by too many supplementary documents, chaotic supplementary document content, or excessive document requirements, thus improving the application completion rate and application experience. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a supplementary document control method for resource applications provided in an embodiment of this application; Figure 2 This is a flowchart illustrating another method for controlling supplementary documents in resource applications provided in an embodiment of this application; Figure 3 This is a flowchart illustrating another method for controlling supplementary documents in resource applications provided in an embodiment of this application; Figure 4 This is a flowchart illustrating another method for controlling supplementary documents in resource applications provided in an embodiment of this application; Figure 5 This is a flowchart example of a supplementary document control method for resource applications provided in an embodiment of this application; Figure 6 This is a schematic diagram of a system architecture for supplementary control of resource requests provided in an embodiment of this application; Figure 7 This is a structural block diagram of a supplementary component control device for resource applications provided in an embodiment of this application; Figure 8 This is a hardware structure block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0020] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0021] It is understood that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0022] With the development of online resource allocation services (such as online lending, online services, and credit loans), the corresponding resource application process has gradually shifted from offline manual processing to intelligent online processing. During this intelligent online processing, applicants can submit resource applications through applications (APPs), web pages, or offline data entry points, and upload relevant documents (such as identity verification, contact information, business licenses, and asset certificates). The relevant resource allocation backend then processes the application according to a predetermined approval process, sequentially moving it to different approval stages such as acceptance, preliminary review, secondary review, final review, and pre-disbursement verification.

[0023] In some embodiments, the processing methods for supplementary materials (hereinafter referred to as supplementary documents) in the approval process mainly include the following categories: (1) Unified Fixed Document Submission Method: When an applicant submits a resource application for the first time, the system lists all the documents that need to be submitted at once according to a preset unified document template. For example, the system is pre-configured to require ID card, bank card, income certificate, employment certificate, contact information, etc. for a certain type of product, and the applicant is required to upload as many documents as possible when submitting for the first time. This method is mainly implemented through a document template configuration table or a rule engine. The core principle is to predefine a fixed mapping relationship between products and document items.

[0024] (2) Manually triggered supplementary document method by reviewers: After a resource application enters the approval process, the reviewers decide whether to require the applicant to supplement materials based on whether the materials are complete, clear, valid, and meet risk control requirements. If the reviewers find that the materials are missing, expired, or have doubts, they will manually initiate a supplementary document task in the approval system, and the system will notify the applicant to submit the corresponding materials. The core principle of this method is that the reviewers combine their review experience to determine what materials are needed for the current case, and then initiate the supplementary document task through the task system and message system.

[0025] (3) Static automatic document supplementation method based on missing fields or format verification: Some systems introduce automated verification logic to verify the completeness of fields, file format, and whether the upload was successful after the application materials are uploaded. When a missing document, an empty field, a format error, or a corrupted file is detected, the system automatically triggers a document supplementation notification. The core principle of this method is: as long as the materials do not meet the preset completeness standards, document supplementation is triggered.

[0026] (4) Submission methods differentiated by product type: Different resource products often have different document requirements. For example, some resource products (such as microcredit loans) require identity and basic income information, while others (such as business loans) require business licenses, business transaction records, tax records, etc. Usually, different submission templates are loaded based on the product type, and then corresponding submission tasks are generated. The core principle is to control the submission requirements from the product dimension.

[0027] (5) Supplementing information based on risk rules: Some systems, in addition to basic information, combine risk control scores or anti-fraud results to supplement certain information for high-risk applications. For example, when the system determines that the authenticity of the applicant's income is questionable, it requires supplementary bank statements for the past three months; when the system determines that the authenticity of the business is insufficient, it requires supplementary photos of the business premises, tax certificates, etc. This method is usually implemented through the linkage of the risk engine and the rule engine, and its core principle is to add static information requirements based on the risk results.

[0028] Although the above-mentioned method for handling replacement parts can achieve the basic function of replacement parts, the inventors found the following shortcomings during the actual resource application and approval process:

[0029] (1) The supplementary document requirements are disconnected from the approval stage and cannot change dynamically with the approval stage: supplementary documents are required all at once, are fixed according to the product, or are temporarily initiated by the reviewer at a certain point. There is no dynamic linkage between the "approval stage - supplementary document rules - supplementary document task". It is impossible to dynamically adjust the document requirements for different approval stages. Instead, all documents are collected at once or repeatedly submitted manually at multiple stages. For example, some documents are not required in the initial review stage, and only identity verification and basic information verification are required; but in the review or final review stage, it is necessary to further supplement bank statements, business certificates, asset certificates or proof of purpose.

[0030] (2) Inaccurate timing of supplementary document requests, which easily leads to invalid supplementary documents: As soon as a missing document is detected, a supplementary document request is immediately initiated without distinguishing whether the document is truly necessary at the current stage. For example, when only the authenticity of the identity and basic admission conditions need to be determined in the preliminary review stage, the system requires the applicant to submit complex business transaction records, proof of fund usage, or guarantee documents in advance, resulting in premature document collection and an increase in invalid supplementary documents.

[0031] (3) Historical supplementary document tasks cannot be automatically adjusted after the approval stage changes: Resource applications may undergo stages such as advancement, regression, manual review, and supplementary audit during the approval process. After the stage changes, the document requirements usually also change. Since most supplementary document tasks are generated once and remain fixed after generation, there is a lack of dynamic processing capabilities for historical supplementary document tasks. For example: supplementary document tasks generated in the initial review stage are still retained after entering the second review stage, even if they are no longer necessary; supplementary document tasks added in the second review stage overlap with the existing tasks in the initial review stage, resulting in duplicate supplementary documents; some documents need to be upgraded to a higher priority after entering the final review stage, but the system will not adjust automatically.

[0032] Due to the aforementioned defects in the supplementary document processing methods of related technologies, the approval efficiency for resource applications is low, the application completion rate is low, and the application experience is poor.

[0033] In view of this, this application provides a method for controlling supplementary documents for resource applications. By acquiring the application context data of the target resource application, and then, if a change in approval stage is determined based on the application context data, a set of valid supplementary document rules corresponding to the current approval stage is determined based on a preset supplementary document rule base. Based on this set of valid supplementary document rules, the submitted data set is processed for data status identification. Based on the result of this data status identification processing, a set of valid supplementary document tasks for the current approval stage is generated. The supplementary document control result is output based on this set of valid supplementary document tasks for the current approval stage, thereby treating the change in approval stage as supplementary documents. The rule-based switching mechanism triggers supplementary document control, enabling supplementary document requirements to automatically switch with the approval stage. This supplementary document control is more in line with the actual approval logic, reducing the excessive collection of materials in the early stages, lowering the submission costs for applicants, and reducing the burden on reviewers to process invalid materials, thereby improving approval efficiency. Since applicants only need to submit the corresponding materials at the corresponding stage, and the reasons for supplementary documents match the stage objectives, it is easier to understand the necessity of each supplementary document notification. This avoids problems such as low application completion rates and poor application experience caused by too many supplementary documents, chaotic supplementary document content, or excessive material requirements, thus improving both the application completion rate and the application experience.

[0034] It should be noted that the supplementary document control method for resource applications provided in this application embodiment can be applied to a supplementary document control device for resource applications. This device can be deployed on a resource application approval and processing platform, which at least includes a server, a storage device, and application data sources, an approval workflow engine, a data management module, a rule management module, a task management module, and a message notification module that are communicatively connected to the server. It is understood that the above modules can be implemented by different program units within the same server, or by multiple service nodes in a distributed manner, with communication between modules through interface calls, message queues, or shared data tables.

[0035] Among them, the supplementary document control device for resource applications can be used to automatically identify, match, reconstruct and control supplementary document tasks when switching between different approval stages during the resource application approval process.

[0036] It should be noted that the server involved in the embodiments of this application can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0037] The technical solutions of the embodiments of this application will be described in detail below.

[0038] Please see Figure 1 The diagram illustrates a flowchart of a supplementary document control method for resource applications provided in this application. This method can be applied to a server in a resource application approval and processing platform. It should be noted that this specification provides the operational steps described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many steps and does not represent the only execution order. In actual system or product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 1 As shown, the method may include: S101, Obtain the application context data of the target resource application.

[0039] The target resource application can be any pending resource application in the resource application approval and processing platform. The resource requested in this application can be financial resources, server resources, energy resources, etc. Specifically, the target resource application could be a loan application, a server resource application, an energy resource application, etc. It should be noted that the resources and target resource applications listed above are only illustrative. In actual implementation, depending on the specific application scenario and processing requirements, the resources mentioned above may also include other types of resource data; correspondingly, the target resource application may also include applications based on other types of resource data.

[0040] The target resource application can be submitted by the applicant through an application platform, such as an application running on a terminal or a webpage. The application context data corresponding to the target resource application can be an application context object obtained by normalizing the multi-source input data participating in the supplementary document control calculation in this application embodiment. This application context data may include approval process status data, submitted document sets, and supplementary document control parameters, etc.

[0041] Specifically, for the target resource application, the server first collects multi-source input data for the component control calculations involved in this application embodiment. This multi-source input data may include one or more of the following: (1) Application master data, which is used to characterize the basic business attributes of the target resource application. Specifically, it may include: application number, applicant number, product number, product type, application resource quantity (such as amount), application period, channel identifier, customer type identifier, etc.

[0042] (2) Process status data, which is used to characterize the current and historical position of the target resource application in the approval process. Specifically, it may include: current approval stage identifier, previous approval stage identifier, current node number, stage entry timestamp, historical stage switching record, approval action record, return record, approval opinion code, etc.

[0043] (3) Data metadata, used to characterize the submitted data objects, may include: data identifier, data item number, data group number, data source, data category, data file summary value, upload timestamp, original data status, review status, effective deadline, associated application number, associated approval stage, and data source type. Among them, the data source type may include: user-uploaded data, data reused from historical applications, third-party interface data, OCR (Optical Character Recognition) parsed data, offline supplementary data, etc.

[0044] (4) Historical supplementary document task data, used to represent the generated supplementary document task objects, which may include: task number, application number to which the task belongs, document item number corresponding to the task, proof purpose number corresponding to the task, task generation stage, current status of the task, task priority, task deadline, and task change record.

[0045] (5) Supplement control parameter data, used to participate in supplement judgment and task control, may include: risk level, anti-fraud label, customer risk classification, product rule version number, stage rule version number, timeout threshold, reuse threshold, data validity period threshold, etc.

[0046] Normalization of the above multi-source input data may include: uniformly mapping stage identifiers from different sources; uniformly converting data category codes; uniformly converting time fields to standard time formats; standardizing data status enumeration in data metadata; and standardizing historical task status.

[0047] The standard data status enumeration is used to unify the description of data object status across different source systems. Specifically, the system maps the original status values ​​from the image system, database, OCR parsing system, and review system to unified status values. These unified status values ​​include one or more of the following: submitted, pending review, approved, failed review, rejected review, expired, insufficient completeness, insufficient clarity, currently unsuitable, reusable, already satisfied by alternative data, and conflict awaiting correction. The standard data status enumeration serves as the basic status input for subsequent data status identification and supplementary document candidate generation.

[0048] After the above normalization process, the application context object corresponding to the target resource application, i.e., the application context data, can be obtained. The application context object includes at least the following fields: current approval stage field, historical approval stage field, submitted data set, historical supplementary document task set, current risk parameter set, and current rule version parameter set.

[0049] The current risk parameter set is derived from one or more of the risk level, anti-fraud label, and customer risk classification in the control parameter data. It is used to determine the applicable risk conditions for the current application during subsequent stages of change identification, stage-specific supplementary document rule retrieval, and supplementary document candidate generation. The current rule version parameter set is derived from one or more of the product rule version number, stage rule version number, data validity threshold, reuse threshold, and timeout threshold in the control parameter data. It is used to determine the subsequently loaded stage-specific supplementary document rule version, data validity judgment criteria, data reuse judgment criteria, and task deadline control criteria.

[0050] By unifying and abstracting the raw data that was originally scattered across different systems, different table structures, and different interfaces into a computable object, a unified data foundation is provided for subsequent component control.

[0051] S103, if it is determined that an approval stage change event has occurred based on the application context data, determine the valid stage supplementary document rule set corresponding to the current approval stage based on the preset stage supplementary document rule base.

[0052] Specifically, the approval stage change event serves as the trigger condition for supplementary document processing in this application embodiment. The following stage change identification data can be read from the application context data: current approval stage identifier (Stage_cur), previous approval stage identifier (Stage_pre), current stage entry time, and historical stage switching logs. Based on the read stage change identification data, it is determined whether an approval stage change event has occurred. Therefore, if an approval stage change event is determined, a valid set of supplementary document rules corresponding to the current approval stage can be determined based on a preset stage supplementary document rule base.

[0053] In some implementations, approval stage change events include: forward stage switching events, reverse stage switching events, and intra-stage recalculation events; then, the method may further include: if any one of the forward stage switching events, the reverse stage switching events, and the intra-stage recalculation events is identified based on the application context data, then it is determined that an approval stage change event has occurred.

[0054] Specifically, if the current approval stage identifier (Stage_cur) is inconsistent with the previous approval stage identifier (Stage_pre), and the current approval stage is located after the previous approval stage in the approval process definition, it is determined as a forward stage switch event. If the current approval stage identifier (Stage_cur) is inconsistent with the previous approval stage identifier (Stage_pre), and the current approval stage is located before the previous approval stage in the approval process definition, it is determined as a reverse stage switch event.

[0055] If the current approval stage identifier (Stage_cur) is the same as the previous approval stage identifier (Stage_pre), and any of the following recalculation conditions within the stage are met, then it is determined to be a recalculation event within the stage: the risk level changes, a key document fails to be reviewed, a key task times out, the approval opinion code changes, the approver triggers a recalculation instruction, or new documents are added to the database, resulting in a change in the document status.

[0056] If any of the aforementioned forward stage switching events, reverse stage switching events, and intra-stage recalculation events are identified, supplementary processing can be triggered. For example, the value "1" can be assigned to the supplementary processing trigger flag Trigger_flag, i.e., Trigger_flag=1. Conversely, if none of the aforementioned events are identified, supplementary processing is not triggered. For example, the value "0" can be assigned to the supplementary processing trigger flag Trigger_flag, i.e., Trigger_flag=0. Thus, the value of the supplementary processing trigger flag Trigger_flag can indicate whether supplementary processing is triggered. In specific implementation, when the supplementary processing trigger flag Trigger_flag=1, a stage change description object can be further generated. This stage change description object includes at least: the current approval stage identifier, the previous approval stage identifier, the stage change type, the stage change occurrence time, and the stage change trigger source. The stage change type is any of the identified forward stage switching events, reverse stage switching events, and intra-stage recalculation events. This allows the change description object and the supplementary document calculation trigger flag (Trigger_flag) of this stage to be used as the result of the approval stage change event identification. In turn, the question of "whether the approval stage has changed" is transformed from a business process phenomenon into a calculable event object, which is the technical entry point for subsequent initiation of staged supplementary document control.

[0057] After obtaining the results of the above-mentioned approval stage change event identification, if the supplementary document calculation trigger flag Trigger_flag=1, then the valid stage supplementary document rule set corresponding to the current approval stage can be determined based on the preset stage supplementary document rule base. The preset stage supplementary document rule base includes stage supplementary document rule sets corresponding to each approval stage of the approval process; each preset supplementary document rule in this set can be understood as a rule template. The valid stage supplementary document rule set corresponding to the current approval stage is obtained by instantiating the stage supplementary document rule set corresponding to the current approval stage from the preset stage supplementary document rule base based on dynamic parameters in the application context data of the target resource application.

[0058] Specifically, when retrieving the set of supplementary rules for the current approval stage from the preset supplementary rule library, joint matching can be performed based on one or more of the following dimensions to improve the accuracy of the matching results: current approval stage, product type, customer type, risk level range, application resource volume range, channel type, and rule version number.

[0059] In some implementations, each rule record in the stage complement rule set includes at least: a target data definition field, an applicable condition field, and multiple dimensions of data status identification fields.

[0060] Specifically, the target data definition fields may include: data item number, data group number, proof purpose number, whether it is mandatory, and whether it is optional.

[0061] The applicable conditions field may include: applicable product conditions, applicable resource quantity conditions, applicable risk conditions, applicable customer conditions, and applicable approval action conditions.

[0062] Data status identification fields with multiple dimensions can include the following dimensions: (1) Validity judgment fields may include: data validity period, minimum time span of data, data approval requirements, data completeness threshold, and data clarity threshold.

[0063] (2) Reuse judgment fields may include: whether cross-stage reuse is allowed, whether cross-application reuse is allowed, reuse validity period, and reuse restriction conditions.

[0064] (3) Substitution relationship field, which may include: whether substitution is allowed, list of substituted data, substitution priority order, and substitution satisfaction threshold.

[0065] In some implementations, each rule record may also include a task control field, which may specifically include: default priority, default deadline, whether to block phase advancement, whether to allow automatic merging, and whether to allow automatic termination.

[0066] After retrieving the matching stage supplementary document rule set, it is instantiated by combining the dynamic parameters in the application context data to obtain the effective stage supplementary document rule set for the current approval stage used in this supplementary document processing. For example, it can be represented as RuleSet(Stage_cur). This transforms the abstract configuration rules into calculation rules that actually take effect under the risk conditions determined by the current application, the current approval stage, and the current risk parameter set in the application context data, providing a basis for subsequent processing steps.

[0067] S105, based on the valid stage supplementary document rule set, perform document status identification processing on the submitted document set in the application context data.

[0068] Among them, the data status identification process is used to identify the data status of the data required in the current approval stage.

[0069] Specifically, the submitted data set in the application context data can be matched item by item and its status identified according to the RuleSet(Stage_cur) of the valid stage supplementary document rule set. In some embodiments, step S105 may include the following steps (1) to (3) when performing data status identification processing on the submitted data set based on the valid stage supplementary document rule set:

[0070] (1) Extract target data items based on the target data definition fields in each effective stage supplementary rules to obtain a set of target data items.

[0071] Specifically, based on the target data definition fields in the supplementary document rules of each valid stage, the set of target data items required for the current approval stage can be extracted from the supplementary document rule set RuleSet(Stage_cur) of the valid stage. For example, the set of target data items can be represented as DocTargetSet.

[0072] (2) For each target data item in the target data item set, identify whether there is target submitted data in the submitted data set that matches the target data item, and obtain the existence identification result;

[0073] Specifically, when performing existence identification, the target data item set DocTargetSet can be mapped and matched with the submitted data set DocExistSet. In order to improve the accuracy of existence identification, the mapping and matching can be performed from at least one of the following dimensions: data item number, data group number, proof purpose number, data category, and data subcategory.

[0074] Understandably, the existence identification result indicates whether a target data item exists in the submitted data set as a corresponding target submitted data item.

[0075] (3) Based on the existence identification result and the multiple dimensions of the data status identification fields in the valid stage supplementary rules corresponding to the target data item, perform data status identification on each submitted data item to obtain the data status identification result of the current approval stage corresponding to the target data item; wherein, the data status identification result set of the current approval stage corresponding to each target data item constitutes the data status identification result set.

[0076] Specifically, for each target data item Doc_i in the target data item set DocTargetSet, if the existence identification result indicates that there is no corresponding target submitted data in the submitted data set DocExistSet, then the data status of the target data item Doc_i is marked as "missing".

[0077] If the existence identification result indicates that a corresponding target submitted document exists in the submitted document set DocExistSet, then the data status identification of the target submitted document is performed based on multiple dimensions of the data status identification fields in the valid stage supplementary document rule corresponding to the target data item Doc_i. These multiple dimensions may include data existence, validity, completeness, clarity, adaptability, reusability, and conflict. Specifically, the data status identification includes:

[0078] Validity period identification: Determine whether the upload time, issuance time, or validity deadline of the submitted data for the target meets the validity period requirements in the supplementary document rules for the corresponding valid stage of the target data item Doc_i. If not, mark the data status of the target data item Doc_i as "expired".

[0079] Review Status Identification: Determine whether the review status of the submitted materials for the target is "Review Approved". If it is not "Review Approved", it is further classified as: Pending Review, Review Failed, or Review Rejected. For the embodiments of this application, when the review status is identified as "Review Failed" or "Rejected", the data status of the target data item Doc_i can be marked as "Review Failed" or "Rejected", which can be marked as "Does not meet the requirements of the current approval stage".

[0080] Completeness identification: Based on parameters such as the number of pages of the submitted data for the target, the completeness rate of key fields, and the success rate of OCR extraction, it can be determined whether the completeness of the submitted data for the target meets the threshold requirements in the supplementary document rules for the effective stage corresponding to the target data item Doc_i. If it does not meet the threshold, the data status of the target data item Doc_i is marked as "insufficient completeness".

[0081] Clarity Identification: Based on the image clarity score, key area recognition rate, or image quality score of the submitted data for the target, it can be determined whether the submitted data for the target meets the clarity requirements in the supplementary rules for the effective stage corresponding to the target data item Doc_i. If it does not meet the requirements, the data status of the target data item Doc_i is marked as "insufficient clarity".

[0082] Stage Adaptability Identification: Determine whether the submitted data for the target is applicable to the current approval stage. If the submitted data for the target was available in the previous approval stage but does not meet the data time range, proof strength or proof purpose requirements of the current approval stage, then mark the data status of the target data item Doc_i as "not suitable for the current stage".

[0083] Reusability identification: If the submitted data for the target is not newly uploaded in the current approval stage, but meets the reuse rules, then the data status of the target data item Doc_i is marked as "reusable".

[0084] Substitute satisfaction identification: If the target data item can be satisfied by substitute data, then it can be further checked whether there is a data object in the submitted data set that meets the substitution conditions. If it does, the data status of the target data item Doc_i is marked as "satisfied by substitute data".

[0085] Conflict identification: The key fields in the target submitted data are compared with the fields filled in by the user, the OCR parsing results, the results returned by third-party data, and the key fields of historical data. If the field conflict exceeds the preset threshold in the supplementary rules of the effective stage corresponding to the target data item Doc_i, the data status of the target data item Doc_i is marked as "conflict pending correction".

[0086] Through the above-described document status identification, for each target document item, a document status identification result corresponding to that target document item in the current approval stage can be generated. This document status identification result includes at least: target document item number, document matching result, current status code, status reason code, corresponding document object number, substitute document object number, and stage adaptability flag. Therefore, based on the document status identification result for each target document item in the target document item set, the document status identification result set for the current approval stage can be obtained, for example, it can be represented as DocStateSet(Stage_cur).

[0087] The above implementation method does not simply determine "whether there is data", but constructs a data status model under the current approval stage from multiple dimensions such as data existence, validity, completeness, clarity, adaptability, reusability and conflict, which ensures the accuracy and completeness of the data status under the current approval stage and helps to improve the accuracy of supplementary document control.

[0088] S107, Based on the result of the data status identification process, generate the set of valid supplementary documents for the current approval stage.

[0089] For example, to avoid applicants receiving similar or duplicate requests for additional documentation multiple times, and to improve the consistency and controllability of the submitted documents, such as... Figure 2 As shown, the application context data also includes a historical supplementary document task set. Therefore, step S107, when generating the valid supplementary document task set for the current approval stage based on the result of the document status identification processing, may include: S201, based on the data status indicated by each data status identification result in the data status identification result set, perform candidate supplementary task generation processing to obtain the candidate supplementary task item set for the current approval stage.

[0090] Specifically, rules can be evaluated based on the valid stage supplementary document rule set RuleSet(Stage_cur) and the document status identification result set DocStateSet(Stage_cur) to generate a set of candidate supplementary document task items for the current approval stage, which can be represented as CandidateSet(Stage_cur). In specific implementation, for each target document item Doc_i, subsequent supplementary document task generation processing can be performed as follows: If the target data item Doc_i is mandatory data and its data status is "missing", a corresponding candidate supplementary data task item is generated. If the target data item Doc_i's data status is "expired" and the current approval stage requires data within its validity period, a corresponding candidate supplementary data task item is generated. If the target data item Doc_i's data status is "approval failed" or "approval rejected", a resubmission candidate supplementary data task item is generated. If the target data item Doc_i's data status is "insufficient completeness" or "insufficient clarity", a quality correction candidate supplementary data task item is generated; if the target data item Doc_i's data status is "incompatible with the current stage", an upgrade candidate supplementary data task item is generated; if the target data item Doc_i's data status is "conflict pending correction", a conflict correction candidate supplementary data task item is generated. If the target data item Doc_i's data status is not marked as "satisfied by alternative data" and it allows substitution, an alternative candidate supplementary data task item is generated.

[0091] In some examples, each candidate supplementary document task includes at least: candidate number, current approval stage, target document item number or document group number, proof purpose number, trigger reason type, whether it is mandatory, default priority, default deadline, whether it blocks stage progress, whether substitution is allowed, and the scope of substitution documents.

[0092] In some examples, to improve the efficiency of supplementary task control, after obtaining the set of candidate supplementary task items, the set of candidate supplementary task items can be deduplicated and grouped. Specifically, if multiple candidate supplementary task items correspond to the same proof purpose, they are merged according to the proof purpose; if multiple candidate supplementary task items belong to the same data group, they are aggregated according to the data group; if the same data item hits multiple triggering reasons at the same time, the primary triggering reason is retained according to the highest priority reason, and the rest are recorded as additional reasons.

[0093] Candidate supplementary document tasks are generated by using the document status indicated by each document status identification result in the document status identification result set, thereby converting the document status result into "theoretically, the target task set that the applicant should be required to supplement at the current approval stage". However, in this application embodiment, this set is not the final supplementary document task set, and it is still necessary to reconstruct it in a consistent manner with the historical task set. See step S203 for details.

[0094] S203, compare the set of candidate supplementary document tasks in the current approval stage with the set of historical supplementary document tasks, and perform dynamic reconstruction operation on the set of historical supplementary document tasks based on the comparison result to obtain the set of valid supplementary document tasks in the current approval stage.

[0095] The dynamic reconfiguration operations include: retaining tasks, terminating tasks, adding tasks, replacing tasks, merging tasks, and adjusting task priorities.

[0096] For example, step S203 may include the following steps (1) to (3) when comparing the set of candidate supplementary task items in the current approval stage with the set of historical supplementary task items, and dynamically reconstructing the historical supplementary task set based on the comparison result to obtain the set of valid supplementary task items in the current approval stage: (1) For each candidate replacement task in the candidate replacement task set, identify the associated historical replacement tasks in the historical replacement task set that are associated with the candidate replacement task to obtain the associated task identification result.

[0097] Specifically, for each candidate supplementary task item C_i in the candidate supplementary task item set, the identification of its corresponding associated historical supplementary task T_i can be performed from the following dimensions: target data item number, data group number, proof purpose number, stage identifier, and substitution relationship identifier.

[0098] Among them, the associated task identification result indicates whether there is an associated historical replacement task T_i.

[0099] (2) Based on the associated task identification results, task comparison processing is performed from multiple task comparison dimensions to obtain the task comparison results corresponding to the candidate supplement task items; the multiple task comparison dimensions include: retention dimension, termination dimension, addition dimension, replacement dimension, merging dimension, and priority adjustment dimension.

[0100] Specifically, the task comparison process can include the following operations: If the associated task identification result indicates the existence of an associated historical supplementary task T_i, and the associated historical supplementary task T_i is currently still valid, and its target data requirements are consistent with C_i, then the candidate supplementary task item is marked as "retained"; if the associated task identification result indicates the existence of an associated historical supplementary task T_i, and the historical data requirements of task T_i have already met the target data requirements of candidate supplementary task item C_i, then the candidate supplementary task item is marked as "terminated". For example, the historical supplementary task originally required the user to submit a certain type of data, but the system now finds that the user has already submitted other valid data, and this data is sufficient to prove the proof purpose corresponding to the historical task, so the user does not need to submit the data again; wherein, the target data requirements are used to represent the data content that the candidate supplementary task item C_i currently requires the user to supplement and the standards it meets, the standards for meeting include data type, data name, data validity requirements, field integrity requirements, format requirements and / or the proof purpose corresponding to the data; the historical data requirements are used to represent the associated historical supplementary task T_i The information that users are required to provide during the generation process and the standards that they must meet.

[0101] If the associated task identification result indicates that there is no associated historical supplementary task T_i, then the candidate supplementary task item is marked as "new"; if the associated task identification result indicates that there is an associated historical supplementary task T_i, and the historical data item corresponding to the associated historical supplementary task T_i (the data corresponding to the generation of task T_i, also known as historical data) is present, but the candidate supplementary task item C_i requires to be changed to replacement data or upgraded data, then the candidate supplementary task item is marked as "replace"; if multiple candidate supplementary task items or multiple historical supplementary tasks correspond to the same proof purpose, the multiple candidate supplementary task items and / or multiple associated historical supplementary tasks are merged into one supplementary task, and the merged supplementary task is marked as "merged"; if the associated task identification result indicates that there is an associated historical supplementary task T_i, and the associated historical supplementary task T_i and the candidate supplementary task item C_i correspond to the same proof purpose, but the priority of the candidate supplementary task item C_i is higher than the priority of the associated historical supplementary task T_i, or the blocking attribute changes, then the candidate supplementary task item is marked as "priority adjustment".

[0102] The task comparison results for candidate supplementary task items obtained based on the above task comparison processing include at least: processing type, original task number, candidate number, old and new priority, old and new blocking attributes, old and new deadlines, and processing reason code. Furthermore, the task comparison results for each candidate supplementary task item constitute a task comparison result set, which can be represented as TaskActionSet(Stage_cur). This allows for the calculation and connection between "what should be supplemented in the current approval stage" and "what has been required historically," avoiding the direct overwriting of old tasks or the indiscriminate addition of new tasks after a stage switch.

[0103] (3) Based on the task comparison results corresponding to each candidate supplementary task item, the historical supplementary task set is dynamically reconstructed to obtain the effective supplementary task set of the current approval stage.

[0104] The dynamic restructuring operations include: task retention, task termination, task addition, task replacement, task merging, and task priority adjustment. Specifically, for task retention: the original task number, original task submission record, and original task status chain are retained, only the stage identifier or update time is updated; for task termination: the original task status is set to "terminated" or "invalid," and its control over the current approval stage is cancelled; for task addition: a new task object is generated, and when generating this task object, the following are written: new task number, application number, stage identifier, target data item, priority, deadline, blocking attribute, and trigger reason; for task replacement: the original task is closed, and a replacement task is created, or the target data requirements and task attributes are updated within the original task object; for task merging: multiple task objects are aggregated to generate a new data group task object, and the merged tasks are set to merge termination status; for task priority adjustment: the priority field, deadline field, reminder frequency field, and blocking attribute field in the task object are updated.

[0105] The above dynamic reconstruction operation can filter out task objects with valid task status and form a set of valid supplementary documents tasks for the current approval stage, which can be represented as TaskEffectiveSet(Stage_cur). In this way, a strong correlation between supplementary document control and changes in the approval stage is achieved through task-level reconstruction rather than simple overwriting. This makes supplementary document control applicable to the entire approval lifecycle, avoids applicants receiving similar or duplicate supplementary document notices multiple times, and improves the consistency and controllability of supplementary documents.

[0106] In some examples, when generating the set of valid supplementary documents for the current approval stage, a task change log corresponding to this dynamic refactoring operation can also be generated. This task change log records at least: the original task number, the new task number, the processing type, the processing time, the approval stage, the rule version number, and the processing reason code, thereby improving the reliability of supplementary document control.

[0107] S109, based on the valid supplementary document task set of the current approval stage, output the supplementary document control result.

[0108] In some implementations, such as Figure 3 As shown, step S109, when outputting the supplementary document control result based on the valid supplementary document task set of the current approval stage, may include:

[0109] S301, based on the valid supplementary document task set of the current approval stage, generate the first supplementary document control result, the second supplementary document control result, and the stage progress control result.

[0110] The first supplementary document control result indicates the supplementary document name, reason for supplementation, upload entry, document example, and deadline; the second supplementary document control result indicates the task source, rule basis, historical task reconstruction results, and current document completion status; and the stage progress control result indicates whether the process has progressed to the next approval stage.

[0111] S303, the first supplementary document control result is sent to the application end of the target resource application via message notification; the second supplementary document control result is sent to the approval end via interface call; and the approval process of the target resource application is controlled based on the stage progress control result.

[0112] In specific implementation, a set of supplementary document control instructions can be generated based on the set of valid supplementary document tasks in the current approval stage, and the corresponding set of supplementary document control instructions can be sent to at least one of the following execution modules: supplementary document task execution module, approval control module, stage progress control module, reminder notification module, and manual review assistance module, so that the corresponding execution module responds to the received supplementary document control instructions.

[0113] Each supplementary document control instruction includes at least: task number, application number, stage identifier, target data item or data group, instruction type, whether to block stage progress, deadline, priority, alternative data parameters, and display parameters. The instruction type may include: create task instruction, update task instruction, terminate task instruction, merge task instruction, and increase priority instruction.

[0114] Specifically, when controlling the approval process of the target resource application based on the phase advancement control results, if a valid supplementary task is marked as "blocking phase advancement", a blocking signal is output to the phase advancement control module before the task is completed; if all blocking tasks have been satisfied, an advance signal is output.

[0115] The above implementation method converts the effective supplementary document task set into executable supplementary document control instructions, enabling the three functions of supplementary document, approval and process control to share a unified control basis, thereby improving the consistency of supplementary document control.

[0116] In some implementations, such as Figure 4 As shown, after outputting the component control result in step S109, the method may further include step S401, which, in response to a component feedback event for the component control result, performs feedback processing based on the component feedback event; the feedback processing includes: updating the submitted data set, data status re-identification processing, updating the valid component task set, and stage advancement control.

[0117] Specifically, the types of supplementary document feedback events include at least: new document upload event, alternative document upload event, document approval event, document approval failure event, task timeout event, manual task change event, and risk reassessment event.

[0118] The feedback processing process may specifically include: (1) Update the submitted data set: write the new data into the database and update the submitted data set DocExistSet; (2) Re-identify the data status: re-execute the data status identification logic in step S105 for the affected target data items; (3) Update the effective supplementary task set: update the status of the corresponding task to submitted for review, completed, to be resubmitted, expired, or timed out; (4) Stage progress control: perform a completion check on all blocked tasks in the current approval stage. If all are satisfied, output a stage progress flag; (5) If the supplementary feedback event causes any of the following situations to occur, the aforementioned steps S103 to S109 can be re-executed: the current stage data status changes, the current stage task status changes, the approval opinion changes, the risk result changes, or the approval stage is switched again.

[0119] Through the above feedback processing, we can obtain: the updated data status result set, the updated set of valid supplementary tasks for the current stage, the current stage progress determination result, and whether to enter the next round of supplementary calculation. This enables the supplementary control in this application embodiment to form a closed-loop iteration, that is, the supplementary control is not a single static calculation, but is continuously updated with data feedback, review feedback and stage changes.

[0120] This application uses changes in the approval stage as trigger conditions for supplementary document control. It jointly processes the supplementary document rule set for each stage, the status of submitted materials, and the historical supplementary document task set to dynamically adjust supplementary document tasks as the approval stage changes. This allows for the requirement of only basic access materials in the initial review stage, more in-depth verification materials in the secondary review stage, and final confirmation materials in the final review or pre-disbursement verification stage, making the supplementary document pace more consistent with the actual business process of loan approval. Furthermore, by dynamically reconstructing historical supplementary document tasks, it can automatically identify which tasks should be retained, which should be invalidated, and which should be merged or replaced after a stage change, significantly reducing duplicate supplementary documents, conflicting supplementary documents, and task delays. Additionally, since not all missing materials are immediately supplemented, but only those truly needed in the current approval stage,… Initiating supplementary documentation reduces the need for excessive data collection in the early stages, lowering the applicant's submission costs and reducing the burden on reviewers to handle invalid documents, thus improving approval efficiency. Since applicants only need to submit the relevant documents at the appropriate approval stage, and the reason for supplementary documentation aligns with the stage's objectives, the necessity of each supplementary notification is easier to understand. This reduces customer churn caused by excessive supplementary documentation, disorganized content, or overly demanding requirements, improving customer experience and application completion rates. By shifting the supplementary documentation logic from "relying on human experience" to "relying on stage rules, document status analysis, and task restructuring mechanisms," inconsistencies between different reviewers are significantly reduced, improving the consistency and traceability of supplementary documentation decisions, and enhancing automation and consistency of review standards.

[0121] To facilitate understanding of the technical solutions in the embodiments of this application, the following uses a resource application as an example of a loan application, combined with... Figure 5 and Figure 6 An example is provided.

[0122] like Figure 5 The diagram illustrates a flowchart of a supplementary document control method for resource applications provided in this application, specifically including the following steps S1 to S9: Step S1: Obtain loan application context data, including application information, approval stage, submitted materials, historical supplementary document tasks, and risk tags; Step S2: Identify approval stage change events, which can be identified by judging forward progress, reverse rollback, recalculation within the same stage, or first entry into the stage. Based on the identification result, determine whether the supplementary document task needs to be recalculated. If yes, proceed to Step S3; otherwise, maintain the existing formal supplementary document task, only perform status inspection or wait for the next event; Step S3: Load the supplementary document rule set for the current approval stage, which can match the supplementary document rules for the current approval stage according to product type, approval stage, customer type, and risk registration; Step S4: Perform stage-based verification on existing materials, including completeness, format compliance, content quality, validity period, stage adaptability, reusability, and conflict resolution; Step S5: Step S6: Generate candidate supplementary documents for the current approval stage to retain only the document items or groups that are truly required for the current approval stage; Step S7: Dynamically reconstruct historical supplementary document tasks, including retention, termination, merging, replacement, upgrading, downgrading, adding, deduplication, and inheritance; Step S8: Generate a formal supplementary document task list, which can set task type, priority, deadline, and whether to block the approval process; Step S9: Synchronize supplementary document tasks with the applicant and the approval end, including sending notifications, displaying the reason for supplementary documents, upload entry, and approval basis; Step S10: Receive supplementary document feedback and re-verify the documents to determine whether all mandatory supplementary document tasks for the current approval stage have been completed. If so, allow the next approval action or generate a mark indicating that the conditions for advancement have been met. Otherwise, maintain the current approval stage and continue to wait for supplementary documents or re-enter steps S5 to S8 due to new events.

[0123] This approach uses changes in the approval stage as the trigger source for document supplementation control, and bases document supplementation on the necessity of the current approval stage rather than simply missing documents. By dynamically reconstructing tasks, it avoids duplicate document supplementation and task conflicts.

[0124] like Figure 6 The diagram shows a system architecture for supplementary document control of resource applications provided in an embodiment of this application. This system can be used to automatically identify, match, reconstruct, and control supplementary document tasks during the loan application approval process, when switching between different approval stages. Specifically, the system includes the following modules: Module M1: Application Context Construction Module This application context construction module collects multi-source input data corresponding to the target loan application and normalizes the multi-source input data to construct an application context object. The input data includes at least: basic application data, approval process data, document data, historical supplementary document task data, and auxiliary control data. The basic application data includes at least the application number, applicant identifier, product type, application amount, application period, and channel source; the approval process data includes at least the current approval stage, previous approval stage, stage entry time, approval opinion, and reason for return; the document data includes at least the set of uploaded documents, document type, document upload time, document review status, document validity period, and document source type; the historical supplementary document task data includes at least the historical task identifier, task source stage, task status, task priority, and task deadline; and the auxiliary control data includes at least the risk level, anti-fraud result, document completeness score, and rule version number. The output of this module is a uniformly formatted application context object, which can be directly called by subsequent modules. This module can correspond to the aforementioned... Figure 5 Method step S1.

[0125] Module M2: Stage Event Recognition Module The stage event identification module reads the approval process data from the application context object and identifies whether a stage event has occurred in the target loan application. The stage events include at least: forward stage switching, reverse stage switching, recalculation within the same stage, and initial stage entry. This module preferably compares the current approval stage identifier with the previous approval stage identifier, and combines this with risk update events, document review failure events, supplementary document timeout events, and manual review events to output the stage event type and a control signal indicating whether supplementary document recalculation needs to be triggered. The module output includes: current approval stage, previous approval stage, stage change type, and trigger time. This module can correspond to the aforementioned... Figure 5 Method step S2.

[0126] Module M3: Stage Rule Loading Module The stage rule loading module, upon receiving the stage recalculation signal from the stage event identification module, loads the corresponding stage supplementary rule set from the rule configuration service to obtain a valid supplementary rule set based on the current approval stage, product type, customer type, risk level, application amount range, and channel type. The stage supplementary rule set includes at least: document item definition parameters, trigger condition parameters, validity judgment parameters, task control parameters, and substitution relationship parameters. The module's input is the current approval stage identifier and control parameter data from the application context object; its output is the set of rule objects for the current approval stage. This module can correspond to the aforementioned... Figure 5 Step S3 in the method.

[0127] Module M4: Data Status Recognition Module The document status identification module is used to perform multi-dimensional status identification on existing documents based on the set of submitted documents in the application context object and the set of valid supplementary document rules output by the stage rule loading module. The status identification includes at least: completeness identification, format compliance identification, content quality identification, timeliness identification, stage adaptability identification, reusability identification, and conflict identification. Preferably, this module identifies each document item as one or more of the following states: submitted and valid, submitted but expired, submitted but invalid, submitted but not suitable for the current stage, submitted and reusable, not submitted, and conflicting and awaiting correction. The output of this module is a set of document status results, which serves as the direct basis for subsequently generating supplementary document candidates. This module can correspond to the aforementioned... Figure 5 Step S4 in the method.

[0128] Module M5: Replacement Part Candidate Generation Module The supplementary document candidate generation module generates a supplementary document candidate set for the current approval stage based on the rule set output by the stage rule loading module and the document status result set output by the document status identification module. The generation logic includes at least: missing document trigger logic, expired document trigger logic, invalid document trigger logic, stage mismatch trigger logic, conflict trigger logic, and alternative document trigger logic. For each supplementary document candidate, the module preferably generates a candidate identifier, the approval stage to which it belongs, the corresponding document item or document group, the reason for supplementation, whether it is mandatory, its priority, deadline, whether substitution is allowed, and an associated historical task identifier. The output of this module is the supplementary document candidate set for the current stage, which can correspond to the aforementioned... Figure 5 Step S5 in the method.

[0129] Module M6: Historical Task Matching and Dynamic Reconstruction Module The historical task matching and dynamic reconstruction module is used to match the current stage's set of supplementary document candidates output by the supplementary document candidate generation module with the historical supplementary document task set provided by the application context construction module, and to dynamically reconstruct the historical supplementary document tasks. The dynamic reconstruction includes at least: task retention, task termination, task merging, task replacement, task upgrading, task downgrading, task addition, and task deduplication. Preferably, this module also generates a task reconstruction log to record the original task identifier, new task identifier, reconstruction type, reconstruction reason, and rule version number. The output of this module is the set of valid supplementary document tasks after reconstruction in the current stage. This module can correspond to the aforementioned... Figure 5 Step S6 in the method.

[0130] Module M7: Complementary Parts Control Output Module The supplementary document control output module is used to generate a formal supplementary document task list based on the valid supplementary document task set output by the historical task matching and dynamic reconstruction module, and to set corresponding task control parameters. The formal supplementary document task list includes at least: task number, application number, current approval stage, document item or document group, task type, task status, priority, deadline, whether substitution is allowed, whether reuse is allowed, whether approval progress is blocked, reminder strategy, and rule version number. Preferably, the module outputs control results to both the applicant and the approval end simultaneously. It outputs the supplementary document name, reason for supplementary document submission, upload entry, document example, and deadline to the applicant end via message notification or interface call, and outputs the task source, rule basis, historical task reconstruction results, and current document completion status to the approval end. This module can correspond to the aforementioned... Figure 5 Method steps S7 and S8.

[0131] Module M8: Feedback Closed-Loop Module The feedback loop module receives supplementary document feedback data submitted by the applicant and re-verifies and controls the supplementary document results. The supplementary document feedback data includes at least: newly uploaded materials, alternative materials, re-uploaded materials, supplementary explanations, and upload results. This module preferably re-performs integrity, validity, stage adaptability, and conflict identification on newly submitted materials, and then updates the corresponding supplementary document task status. Task status includes at least: submitted for review, approved, rejected, continuing supplementary documents, and completed. Further, this module determines whether all mandatory supplementary document tasks in the current approval stage are completed; if all are completed, it outputs a control instruction that meets the stage advancement conditions; if not all are completed, it maintains the current stage or re-triggers the supplementary document candidate generation module and the historical task matching and dynamic reconstruction module to execute the next round of calculations. This module can correspond to the aforementioned... Figure 5 Method step S9.

[0132] In one implementation, the output of module M1 serves as the common input for modules M2, M3, M4, and M6; module M2 outputs stage event control signals to module M3; module M3 outputs the stage supplementary document rule set to modules M4 and M5; module M4 outputs the data status result set to module M5; module M5 outputs the supplementary document candidate set to module M6; module M6 outputs the reconstructed set of valid supplementary document tasks to module M7; module M7 synchronizes the formal supplementary document task list to the applicant and approval ends; module M8 receives supplementary document feedback from the applicant and, if necessary, re-invokes modules M4, M5, M6, and M7. This forms a complete system processing chain of "context construction—stage identification—rule loading—data identification—candidate generation—task reconstruction—control output—feedback closed loop".

[0133] Corresponding to the supplementary component control methods for resource applications provided in the above embodiments, this application also provides a supplementary component control device for resource applications. Since the supplementary component control device for resource applications provided in this application corresponds to the supplementary component control methods for resource applications provided in the above embodiments, the implementation methods of the aforementioned supplementary component control methods for resource applications are also applicable to the supplementary component control device for resource applications provided in this embodiment, and will not be described in detail in this embodiment.

[0134] Please see Figure 7 The diagram shows a structural schematic of a supplementary component control device for resource requests provided in an embodiment of this application. This device has the function of implementing the supplementary component control method for resource requests described in the above method embodiments. This function can be implemented in hardware or by hardware executing corresponding software. Figure 7 As shown, the supplementary document control device 700 for resource requests may include:

[0135] The context data acquisition module 710 is used to acquire the application context data of the target resource application; The effective stage supplementary document rule determination module 720 is used to determine the effective stage supplementary document rule set corresponding to the current approval stage based on a preset stage supplementary document rule library when an approval stage change event is determined based on the application context data. The valid supplementary document task generation module 730 is used to perform document status identification processing on the submitted document set in the application context data based on the valid stage supplementary document rule set, and generate the valid supplementary document task set for the current approval stage based on the result of the document status identification processing. The supplementary document control module 740 is used to output supplementary document control results based on the set of valid supplementary document tasks in the current approval stage.

[0136] In some embodiments, the approval stage change events include: forward stage switching events, reverse stage switching events, and intra-stage recalculation events; the device 700 further includes: The approval stage change event determination module is used to determine that an approval stage change event has occurred if any of the forward stage switching event, the reverse stage switching event, or the intra-stage recalculation event is identified based on the application context data.

[0137] In some implementations, each valid stage supplementary document rule includes a target data definition field and multiple dimensions of data status identification fields; the valid supplementary document task generation module 730 includes a data status identification module, which is specifically used for: extracting target data items based on the target data definition fields in each valid stage supplementary document rule to obtain a target data item set; for each target data item in the target data item set, identifying whether there is target submitted data matching the target data item in the submitted data set to obtain an existence identification result; based on the existence identification result and the multiple dimensions of data status identification fields in the valid stage supplementary document rule corresponding to the target data item, performing data status identification on each submitted data item to obtain the data status identification result corresponding to the target data item in the current approval stage; wherein, the data status identification result set corresponding to each target data item in the current approval stage constitutes a data status identification result set.

[0138] In some implementations, the application context data further includes a historical supplementary document task set; the valid supplementary document task generation module 730 further includes a task reconstruction module, which is specifically used to: perform candidate supplementary document task generation processing based on the document status indicated by each document status identification result in the document status identification result set, to obtain a candidate supplementary document task item set for the current approval stage; compare the candidate supplementary document task item set for the current approval stage with the historical supplementary document task set, and perform a dynamic reconstruction operation on the historical supplementary document task set based on the comparison result, to obtain a valid supplementary document task set for the current approval stage. The dynamic reconstruction operation includes: task retention operation, task termination operation, task addition operation, task replacement operation, task merging operation, and task priority adjustment operation.

[0139] In some implementations, when the task reconstruction module compares the set of candidate supplementary task items in the current approval stage with the set of historical supplementary task items, and performs a dynamic reconstruction operation on the historical supplementary task set based on the comparison result to obtain the set of valid supplementary task items in the current approval stage, it specifically performs the following: for each candidate supplementary task item in the set of candidate supplementary task items, it identifies the associated historical supplementary task items in the historical supplementary task set that are related to the candidate supplementary task item, and obtains the associated task identification result; based on the associated task identification result, it performs task comparison processing from multiple task comparison dimensions to obtain the task comparison result corresponding to the candidate supplementary task item; the multiple task comparison dimensions include: retention dimension, termination dimension, addition dimension, replacement dimension, merging dimension, and priority adjustment dimension; based on the task comparison result corresponding to each candidate supplementary task item, it performs a dynamic reconstruction operation on the historical supplementary task set to obtain the set of valid supplementary task items in the current approval stage.

[0140] In some implementations, the supplementary document control module 740 is specifically used to: generate a first supplementary document control result, a second supplementary document control result, and a stage progress control result based on the valid supplementary document task set of the current approval stage; the first supplementary document control result indicates the supplementary document name, supplementary document reason, upload entry, document example, and deadline; the second supplementary document control result indicates the task source, rule basis, historical task reconstruction result, and current document completion status; the stage progress control result indicates whether to proceed to the next approval stage; send the first supplementary document control result to the application end of the target resource application via message notification; send the second supplementary document control result to the approval end via interface call; and perform process control on the approval process of the target resource application based on the stage progress control result.

[0141] In some embodiments, the device 700 further includes: The feedback processing module is used to respond to a component feedback event for the component control result and perform feedback processing based on the component feedback event; the feedback processing includes: updating the submitted data set, data status re-identification processing, updating the valid component task set, and stage progress control.

[0142] It should be noted that the device provided in the above embodiments is only illustrated by the division of the above functional modules when realizing its functions. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. For example, Figure 6 The functional modules shown are as follows. Furthermore, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, and will not be repeated here.

[0143] This application provides an electronic device including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement any of the supplementary control methods for resource requests provided in the above method embodiments.

[0144] The methods and embodiments provided in this application can be executed in a computer terminal, server, or similar computing device; that is, the aforementioned electronic device may include a computer terminal, server, or similar computing device. Taking running on a server as an example... Figure 8 This is a hardware structure block diagram of a server that runs a supplementary control method for resource requests, as provided in an embodiment of the present invention. Figure 8As shown, the server 800 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 810 (CPUs 810 may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), a memory 830 for storing data, and one or more storage media 820 (e.g., one or more mass storage devices) for storing application programs 823 or data 822. The memory 830 and storage media 820 may be temporary or persistent storage. The program stored in the storage media 820 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the CPU 810 may be configured to communicate with the storage media 820 and execute the series of instruction operations stored in the storage media 820 on the server 800. Server 800 may also include one or more power supplies 860, one or more wired or wireless network interfaces 850, one or more input / output interfaces 840, and / or one or more operating systems 821, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0145] The input / output interface 840 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of server 800. In one example, the input / output interface 840 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 840 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0146] Those skilled in the art will understand that Figure 8 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 800 may also include... Figure 8 The more or fewer components shown, or having the same Figure 8 The different configurations shown.

[0147] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a supplementary control method for resource requests. The at least one instruction or the at least one program is loaded and executed by the processor to implement any of the supplementary control methods for resource requests provided in the above-described method embodiments.

[0148] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements any of the supplementary control methods for resource requests provided in the above-described method embodiments.

[0149] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0150] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0151] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0152] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0153] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for controlling supplementary documents in resource applications, characterized in that, The method includes: Obtain the application context data of the target resource application; If an approval stage change event is determined based on the application context data, a valid set of supplementary rules for the current approval stage is determined based on a preset supplementary rule base for stage-specific supplementary documents. Based on the valid stage supplementary document rule set, the submitted document set in the application context data is processed for document status identification, and based on the result of the document status identification, the valid supplementary document task set for the current approval stage is generated. Based on the set of valid supplementary documents for the current approval stage, output the supplementary document control result.

2. The method of claim 1, wherein, The approval stage change events include: forward stage switching events, reverse stage switching events, and intra-stage recalculation events; the method further includes: If any of the following events is identified based on the application context data: the forward stage switching event, the reverse stage switching event, or the intra-stage recalculation event, then an approval stage change event is determined to have occurred.

3. The method of claim 1, wherein, Each valid stage supplementary document rule includes a target data definition field and multiple dimensions of data status identification fields; the data status identification processing of the submitted data set based on the valid stage supplementary document rule set includes: Based on the target data definition fields in the supplementary rules of each effective stage, target data items are extracted to obtain a set of target data items. For each target data item in the target data item set, identify whether there is target submitted data in the submitted data set that matches the target data item, and obtain the existence identification result; Based on the existence identification result and the multiple dimensions of the data status identification fields in the valid stage supplementary document rules corresponding to the target data item, the data status identification is performed on each submitted data to obtain the data status identification result corresponding to the target data item in the current approval stage. The current approval stage corresponds to the data status identification result set consisting of the data status identification results of each target data item.

4. The method of claim 3, wherein, The application context data also includes a historical set of supplementary document requests; the generation of a valid set of supplementary document requests for the current approval stage based on the result of the document status identification processing includes: Based on the document status indicated by each document status identification result in the document status identification result set, candidate supplementary document task generation processing is performed to obtain the candidate supplementary document task item set for the current approval stage. The candidate supplementary document task set in the current approval stage is compared with the historical supplementary document task set. Based on the comparison result, the historical supplementary document task set is dynamically reconstructed to obtain the effective supplementary document task set in the current approval stage. The dynamic reconfiguration operations include: retaining tasks, terminating tasks, adding tasks, replacing tasks, merging tasks, and adjusting task priorities.

5. The method of claim 4, wherein, The step of comparing the current set of candidate supplementary document tasks with the historical set of supplementary document tasks, and dynamically reconstructing the historical set of supplementary document tasks based on the comparison result to obtain the current set of valid supplementary document tasks includes: For each candidate replacement task in the candidate replacement task set, identify the associated historical replacement tasks in the historical replacement task set that are related to the candidate replacement task, and obtain the associated task identification result. Based on the associated task identification results, task comparison processing is performed from multiple task comparison dimensions to obtain the task comparison results corresponding to the candidate replacement task items; the multiple task comparison dimensions include: retention dimension, termination dimension, addition dimension, replacement dimension, merging dimension, and priority adjustment dimension. Based on the task comparison results corresponding to each of the candidate supplementary document task items, the historical supplementary document task set is dynamically reconstructed to obtain the effective supplementary document task set for the current approval stage.

6. The method of claim 4, wherein, Based on the valid supplementary document task set of the current approval stage, the supplementary document control result is output, including: Based on the valid supplementary document task set of the current approval stage, a first supplementary document control result, a second supplementary document control result, and a stage progress control result are generated; the first supplementary document control result indicates the supplementary document name, reason for supplementation, upload entry, document example, and deadline; the second supplementary document control result indicates the task source, rule basis, historical task reconstruction results, and current document completion status; the stage progress control result indicates whether to proceed to the next approval stage; The first supplementary document control result is sent to the application end of the target resource application via message notification; the second supplementary document control result is sent to the approval end via interface call; and the approval process of the target resource application is controlled based on the stage progress control result.

7. The method according to any one of claims 1 to 6, characterized in that, After outputting the component control results, the method further includes: In response to a component feedback event for the component control result, feedback processing is performed based on the component feedback event; the feedback processing includes: updating the submitted data set, data status re-identification processing, updating the valid component task set, and stage progress control.

8. A supplementary document control device for resource applications, characterized in that, The device includes: The context data acquisition module is used to acquire the application context data of the target resource application; The effective stage supplementary document rule determination module is used to determine the effective stage supplementary document rule set corresponding to the current approval stage based on a preset stage supplementary document rule library when an approval stage change event is determined based on the application context data. The valid supplementary document task generation module is used to perform document status identification processing on the submitted document set in the application context data based on the valid stage supplementary document rule set, and generate the valid supplementary document task set for the current approval stage based on the result of the document status identification processing. The supplementary document control module is used to output supplementary document control results based on the set of valid supplementary document tasks in the current approval stage.

9. An electronic device, comprising: It includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the supplementary control method for resource requests as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores at least one instruction or at least one program, which is loaded and executed by the processor to implement the method for controlling supplements for resource application according to any one of claims 1-7.

Images