Qualification verification method, device and equipment

Abstract

The invention discloses a qualification verification method, device and equipment. The method comprises the following steps: determining a business scene condition and at least one to-be-checked business based on a received checking task; for each service, determining a target check rule set matched with the service scene condition and corresponding to each service; on the basis of the check rules in the target check rule set, check elements related to the check rules are determined, and the check elements are used for indicating element data needing to be obtained from a data source of the information of the storage object when the check rules are executed; obtaining element data corresponding to the object from a data source based on the identity label and the check element of the object; and executing the checking rule based on the element data corresponding to the object, and obtaining a verification result of the qualification of the object to use each service based on an execution result. According to the method, unified processing of qualification verification under multiple services and multiple scenes is realized through decoupling rule definition, element acquisition and rule execution, and the verification efficiency and maintainability of the system are improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a qualification verification method, apparatus and device. Background Technology

[0002] Currently, financial products are becoming increasingly diversified, leading to a growing need to verify whether customers are qualified to sign up for products or to screen products that customers can sign up for.

[0003] Each product type is influenced by multiple factors such as regulation, profit, and sales strategy, typically requiring complex verification rules. On the one hand, different verification rules may apply to products in different business scenarios. For example, for the same product, border branches may have stricter restrictions on signing qualifications compared to inland branches, leading to different verification rules. On the other hand, the verification rules for different products involve different combinations of verification elements. For instance, when the customer is a company, verification elements may include company size, company type, and company status. The verification rules for product A may require the company to be a micro or small enterprise, while the verification rules for product B may require both the company to be a micro or small enterprise and exclude customers whose company type is a micro-loan institution.

[0004] Existing solutions typically involve customized development for individual products, based on the business scenarios and verification elements involved in the product's verification process. On one hand, each product's verification rules are developed independently, leading to duplicate implementations of the same logic across different rules, and making it difficult to quickly respond to changes in rules or verification elements. On the other hand, the sheer number of products and the complexity of the rules result in an exponential increase in configuration items, leading to long development cycles and high maintenance costs. Therefore, a more efficient, flexible, and easily maintainable qualification verification solution is urgently needed. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a qualification verification method, apparatus, and device. By decoupling rule definition, element acquisition, and rule execution, it achieves unified processing of qualification verification across multiple services and scenarios, thereby improving the system's verification efficiency and maintainability.

[0006] In a first aspect, this application provides a qualification verification method, the method comprising:

[0007] Based on the received inspection task, the business scenario conditions and at least one business to be inspected are determined, wherein the inspection task is used to verify the object's eligibility to use each of the businesses.

[0008] For each of the aforementioned services, determine a set of target verification rules that match the conditions of the service scenario.

[0009] Based on the inspection rules in the target inspection rule set, the inspection elements involved in the inspection rules are determined. The inspection elements are used to indicate the element data that needs to be obtained from the data source storing the information of the object when executing the inspection rule.

[0010] Based on the object's identity and the verification elements, obtain the element data corresponding to the object from the data source;

[0011] The verification rules are executed based on the element data corresponding to the object, and the verification result of the object's eligibility to use each of the services is obtained based on the execution result.

[0012] In this embodiment, the business scenario conditions describe the specific business environment in which the current verification task takes place. This environment can be the specific organization where the object handles the business, or it can include the object's identity type. The same business may correspond to different sets of verification rules under different business scenario conditions. After extracting the current business scenario conditions and the business to be verified from the verification task, a target set of verification rules can be automatically matched for each specific business and current business scenario conditions. Each target set of verification rules includes one or more preset verification rules. Then, based on the verification elements and the object's identity identifier that the matched verification rules depend on, element data can be obtained and the verification rules can be executed. Finally, the object's eligibility to use each business is determined based on the execution results. This application decouples rule definition, element acquisition, and rule execution, eliminating the need to preset qualification verification procedures for each scenario and each business. It supports a unified verification entry point for multiple businesses and scenarios, reducing configuration costs.

[0013] In one possible implementation, the business scenario conditions include at least one business dimension and business dimension parameter values ​​corresponding to each business dimension, wherein each business dimension represents a type of business scenario feature that affects the configuration of the inspection rules;

[0014] The step of determining the set of target verification rules that match the business scenario conditions for each of the aforementioned businesses includes:

[0015] For each of the aforementioned services, based on the service identifier of the service and the service dimension parameter values ​​of each service dimension constituting the service scenario conditions, a matching is performed in a preset check rule base to obtain a target check rule set that matches the service identifier of the service and the service dimension parameter values ​​included in the service scenario conditions.

[0016] The inspection rule base supports configuration management through configuration operations, which include: configuring new inspection rules based on existing inspection elements; creating new inspection rule sets based on existing inspection rules; and configuring inspection rules in existing inspection rule sets and their associated business identifiers and business dimension parameter values.

[0017] In this embodiment, on the one hand, a method is proposed to determine the target set of inspection rules based on business scenario conditions and the business to be inspected. On the other hand, by supporting configuration operations on the inspection rule base, changes in business, scenarios, and inspection strategies can be responded to quickly. Business personnel can implement changes such as launching new regions or admitting new customer groups through configuration operations, without the need for developers to code. This can shorten the response time for rule changes and support for new business scenarios, and improve the flexibility and maintainability of the system.

[0018] In one possible implementation, obtaining the verification result of the object's eligibility to use each of the services based on the execution result includes:

[0019] According to the preset qualification verification feedback report template, the execution result is converted into a qualification verification feedback report, which includes: the verification result of the object's qualification for each of the services; and for services that fail qualification verification, operation suggestions generated based on the service scenario conditions and the object's identity to guide the object to pass the qualification verification.

[0020] In this embodiment, based on the verification results of the applicant's qualifications for each business, a pre-defined feedback report template is invoked to generate structured feedback information. Specifically, for businesses that fail the verification, operational suggestions are generated to guide the applicant in completing compliant procedures. The suggestions are related to the specific failure scenario. Users can directly learn the specific reasons for the qualification verification failure and the correction path (such as changing the signatory or supplementing materials), reducing the need for repeated submissions or inquiries due to unclear information and improving the user experience.

[0021] In one possible implementation, the method further includes:

[0022] Identify at least one candidate business that belongs to the same business type as the business that failed the qualification verification;

[0023] The verification result of the object's eligibility to use each of the candidate services is determined, and the candidate services with the qualified verification result are provided to the object as recommended services.

[0024] In this embodiment, when a business qualification verification fails, the system automatically identifies candidate businesses of the same type and re-executes the qualification verification process for the candidate businesses. The candidate businesses that pass the qualification verification are recommended to the customer as alternative solutions, which helps to reduce the risk of customer churn, uncover potential business opportunities, and improve business conversion rates.

[0025] In one possible implementation, obtaining the element data corresponding to the object from the data source based on the object's identity and the verification elements includes:

[0026] Based on the preset mapping relationship between inspection elements and data acquisition units, the target data acquisition unit corresponding to each inspection element is determined; wherein, the data acquisition units corresponding to inspection elements that need to acquire element data from the same data source are the same in the mapping relationship.

[0027] Each of the inspection elements is grouped according to its corresponding target data acquisition unit to obtain the inspection elements that each target data acquisition unit needs to acquire.

[0028] Each target data acquisition unit is invoked to access the corresponding data source based on the object's identity identifier to batch acquire the element data corresponding to the inspection elements it needs to acquire;

[0029] The acquired element data is summarized to obtain the element data corresponding to the object.

[0030] In this embodiment, by aggregating the verification elements according to the data source and achieving batch acquisition through a single call, repeated access and querying of the same data source can be avoided. In scenarios with concurrent verification of multiple rules, this helps to improve data acquisition efficiency and reduce network overhead.

[0031] In one possible implementation, before executing the check rules in the target check rule set based on the feature data corresponding to the object, the method further includes:

[0032] For each of the aforementioned services, identify the inspection rules that involve the same inspection elements but have different judgment criteria in the corresponding target inspection rule set, and form corresponding rule conflict groups based on the identified groups of inspection rules;

[0033] Based on the preset conflict rule selection strategy, the business identifier of the business corresponding to each rule conflict group, and the business scenario conditions, the check rule to be executed in each rule conflict group is determined.

[0034] The conflict rule selection strategy includes conflict decision logic configured for each business under different business scenario conditions. The conflict decision logic is used to select the inspection rule to be executed from the inspection rules involving the same inspection elements but different judgment criteria.

[0035] In this application embodiment, under the current business scenario, the same business may be matched with multiple sets of target verification rules, resulting in rules with different judgment standards for the same verification element (for example, a product requires "business turnover ≥ 100,000 yuan in the last 3 months" in location A, while requiring "business turnover ≥ 200,000 yuan in the last 3 months" in location B), thus causing rule conflicts. This application, by configuring conflict decision logic bound to business identifiers and business scenarios, can select the rule to be executed from each set of conflict rules, ensuring the consistency and accuracy of verification results while meeting the needs of differentiated strategies.

[0036] In one possible implementation, executing the check rule based on the feature data corresponding to the object includes:

[0037] Based on a preset rule importance determination strategy, the business identifier of each business, and the business scenario conditions, the importance of each inspection rule is determined; wherein, the rule importance determination strategy includes rule importance decision logic configured for each business under different business scenario conditions, and the rule importance decision logic is used to determine the importance of each inspection rule involved in each business under the business scenario conditions;

[0038] Based on the element data corresponding to the object, the inspection rules are executed sequentially from high to low importance.

[0039] If any verification rule whose importance exceeds the preset threshold fails the verification, the qualification verification status of the business involved in that verification rule will be updated to failure and the reason for failure will be displayed.

[0040] In this embodiment, the importance of each verification rule is determined according to the rule importance decision logic. When a high-importance risk rule fails, the failure result and reason of the qualification verification of the business associated with the high-importance rule are quickly fed back. This prioritizes the exposure of the substantive risks that cause the qualification verification to fail, avoids users from making futile modifications due to the failure of secondary rules, and can improve verification efficiency and optimize user experience.

[0041] Secondly, this application provides a qualification verification device, the device comprising:

[0042] The task receiving module is used to determine the business scenario conditions and at least one business to be inspected based on the received inspection task. The inspection task is used to verify the object's eligibility to use each of the business.

[0043] The rule determination module is used to determine, for each of the services, a set of target inspection rules that match the conditions of the service scenario for each service;

[0044] The element determination module is used to determine the inspection elements involved in the inspection rules based on the inspection rules in the target inspection rule set. The inspection elements are used to indicate the element data that needs to be obtained from the data source storing the information of the object when executing the inspection rule.

[0045] The element acquisition module is used to acquire element data corresponding to the object from the data source based on the object's identity identifier and the verification elements;

[0046] The rule execution module is used to execute the verification rules based on the element data corresponding to the object, and obtain the verification result of the object's eligibility to use each of the services based on the execution result.

[0047] Thirdly, embodiments of this application provide an apparatus including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a qualification verification method as described in any of the first aspects of this application.

[0048] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, enables a terminal device to perform the qualification verification method as described in any of the claims provided in the first aspect of this application.

[0049] The technical effects brought about by the second to fourth aspects and any one of their implementation methods can be referred to the technical effects brought about by the corresponding implementation methods in the first aspect, and will not be repeated here.

[0050] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0051] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the 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.

[0052] Figure 1 A flowchart of a qualification verification method provided in an embodiment of this application;

[0053] Figure 2 This application provides a schematic diagram of a qualification verification system architecture.

[0054] Figure 3 A schematic diagram of a qualification verification device provided in an embodiment of this application;

[0055] Figure 4 This is a schematic diagram of a qualification verification device provided in an embodiment of this application. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0057] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0058] The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the term encompasses the elements or objects listed following the term and their equivalents, without excluding other elements or objects. The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code capable of performing the functions associated with that element.

[0059] Currently, financial products are becoming increasingly diversified, leading to a growing need to verify whether customers are qualified to sign up for products or to screen products that customers can sign up for.

[0060] Each product type is influenced by multiple factors such as regulation, profit, and sales strategy, typically requiring complex verification rules. On the one hand, different verification rules may apply to products in different business scenarios. For example, for the same product, border branches may have stricter restrictions on signing qualifications compared to inland branches, leading to different verification rules. On the other hand, the verification rules for different products involve different combinations of verification elements. For instance, when the customer is a company, verification elements may include company size, company type, and company status. The verification rules for product A may require the company to be a micro or small enterprise, while the verification rules for product B may require both the company to be a micro or small enterprise and exclude customers whose company type is a micro-loan institution.

[0061] Existing solutions typically involve customized development for individual products, based on the business scenarios and verification elements involved in the product's verification process. On one hand, each product's verification rules are developed independently, leading to duplicate implementations of the same logic across different rules, and hindering rapid response to changes in rules or verification elements. On the other hand, the sheer number of products and the complexity of rules result in an exponential increase in configuration items, leading to low efficiency in qualification verification for scenarios requiring batch verification, as well as long development cycles and high maintenance costs. Therefore, a more efficient, flexible, and maintainable qualification verification solution is urgently needed.

[0062] In view of the above problems, this application provides a qualification verification method, apparatus and device, which achieves unified processing of qualification verification under multiple services and multiple scenarios by decoupling rule definition, element acquisition and rule execution, thereby improving the verification efficiency and maintainability of the system.

[0063] The specific embodiments of the present invention will now be described with reference to the accompanying drawings.

[0064] like Figure 1 The diagram shown is a flowchart of a qualification verification method provided in an embodiment of this application. The method includes the following steps S101-S105.

[0065] Step S101: Based on the received inspection task, determine the business scenario conditions and at least one business to be inspected.

[0066] The aforementioned verification task is used to verify the eligibility of the object to use at least one of the services to be verified.

[0067] In this embodiment of the application, the verification task is used to initiate the qualification verification process. The verification task is triggered by the need to determine whether a specific object has the conditions to use a certain business or service. Specifically, it can be triggered by a request initiated by an external system or a customer.

[0068] Optionally, the verification task can at least extract the identity identifier of the object to be verified, the business to be verified, and the business scenario conditions. Among them, the business scenario conditions describe the specific business environment in which the current verification task takes place, which can be the specific organization where the object handles the business, and can also include the object's identity type.

[0069] It should be noted that in the embodiments of this application, "object" and "customer" have the same meaning, and the object to be checked can be a corporate customer or an individual customer.

[0070] Optionally, the above-mentioned inspection task can be triggered by the customer filling out an application form. The application form must include at least the following two types of information:

[0071] The first type is information voluntarily filled in by the customer, such as the object's identity identifier (e.g., unified social credit code, ID number), the type of service to be activated, the expected signing date, contact information, etc.

[0072] The second type is context information automatically filled in by the system, such as the institution code where the customer conducts business (e.g., the institution number of a branch M in Tianjin), the channel of business (e.g., mobile banking, branch counter), the time of business, and the geographical location.

[0073] Based on the information filled in on the form, the system parses out the identity of the business and the object to be inspected, and combines the information filled in by the customer with the system context information to construct complete business scenario conditions (such as expected signing date, application region, etc.), generates inspection tasks, and initiates the qualification verification process.

[0074] Step S102: For each business, determine the set of target inspection rules that match the business scenario conditions.

[0075] In this embodiment, the same business may correspond to different sets of inspection rules under different business scenarios. The same set of inspection rules can also be associated with multiple businesses simultaneously. For example, a certain business may use the same set of general inspection rules in the North China region, or two businesses may use the same set of inspection rules. Therefore, after extracting the current business scenario conditions and the business to be inspected from the inspection task, for each specific business and the current business scenario conditions, a target set of inspection rules can be automatically matched from the set of inspection rules corresponding to that business. Each target set of inspection rules includes one or more preset inspection rules.

[0076] Step S103: Based on the inspection rules in the target inspection rule set, determine the inspection elements involved in the inspection rules.

[0077] Step S104: Based on the object's identity and verification elements, obtain the element data corresponding to the object from the data source.

[0078] In this embodiment of the application, the check element is used to indicate the element data that needs to be obtained from the data source of the stored object's information when executing the check rule.

[0079] Specifically, after parsing out the check elements upon which the check rules in the target check rule set depend, the corresponding data elements can be obtained by accessing the relevant data source using the object's identity identifier. For example, if the object's identity type is an enterprise, check elements such as "legal representative's age," "registered capital," and "historical number of defaults" may be involved, requiring the use of the object's identity identifier to obtain the corresponding data elements from the data source storing enterprise information.

[0080] Step S105: Execute the verification rules based on the element data corresponding to the object, and obtain the verification result of the object's eligibility to use each business based on the execution result.

[0081] For example, when a customer applies to activate the "cross-border payment" product, the system identifies the customer type as "startup" and the location as "Guangdong Free Trade Zone". Based on this, a set of target verification rules applicable to the business scenario is matched. The set may include a series of verification rules such as "no foreign exchange penalty record" and "non-sensitive list of actual controllers". Then, the corresponding element data is obtained and the qualification verification is completed.

[0082] Optionally, before executing the verification rules, deduplication can be performed on the verification rules to avoid the same verification rules being executed repeatedly, thereby improving verification efficiency.

[0083] Specifically, the deduplication process can involve the system comparing each verification rule based on its rule identifier (such as rule ID). If multiple target verification rule sets contain verification rules with the same rule identifier, only one is retained for subsequent execution, thus obtaining the deduplicated verification rules. Further, the system obtains the element data corresponding to the deduplicated verification rules (such as data from customer information databases, credit reporting systems, form filling systems, etc.) and executes the rule judgments one by one, generating an execution result (pass / fail) for each rule. After all deduplicated verification rules have been executed, the system combines the target verification rule set corresponding to each business with the rule execution results to determine the qualification verification result for each business.

[0084] In this embodiment, after extracting the current business scenario conditions and the business to be inspected from the inspection task, a target set of inspection rules can be automatically matched for each specific business and the current business scenario conditions. Then, based on the inspection elements and object identity identifiers upon which the matched inspection rules depend, element data can be obtained and the inspection rules executed. Finally, the object's eligibility to use each business is determined based on the execution results. This application decouples rule definition, element acquisition, and rule execution, eliminating the need to pre-set qualification verification procedures for each scenario and business, supporting a unified verification entry point for multiple businesses and scenarios, and reducing configuration costs.

[0085] In some embodiments, the business scenario conditions determined by step S101 include at least one business dimension and business dimension parameter values ​​corresponding to each business dimension, with each business dimension representing a type of business scenario feature that affects the configuration of the inspection rules.

[0086] For example, when the business dimension type can include the organization dimension (branch type / region), customer dimension (customer type), and agreement dimension (business effective date range), the business dimension parameter values ​​extracted from the inspection task can be: {Region = Guangdong; Customer type = Startup; Expected contract duration = 1 year}.

[0087] As a feasible implementation method, step S102 above is implemented in the following way:

[0088] For each business, based on the business identifier of the business and the business dimension parameter values ​​of each business dimension constituting the business scenario conditions, a set of target verification rules is obtained by matching the business identifier of the business and the business dimension parameter values ​​included in the business scenario conditions.

[0089] In this embodiment, by maintaining a verification rule base, the set of verification rules involved in all businesses and their mapping relationship with business scenario conditions can be stored and configured. The core object of configuration management is the set of verification rules, each set consisting of one or more verification rules, representing a type of reusable qualification verification logical unit.

[0090] In this embodiment of the application, the above-mentioned check rule base supports configuration management of the check rule base through configuration operations.

[0091] Optional configuration operations for the check rule base include, but are not limited to:

[0092] Configure new inspection rules based on existing inspection elements;

[0093] Create a new set of inspection rules based on existing inspection rules;

[0094] Configure the existing set of inspection rules and their associated business identifiers and business dimension parameter values.

[0095] Optionally, the check rule base can be configured and managed through a visual configuration interface.

[0096] For example, administrators can create new check rules, combine check rule sets, and bind business and business scenario conditions to check rule sets by dragging and dropping or clicking buttons.

[0097] Optionally, the configurable attributes of each set of inspection rules in the inspection rule base in this embodiment are shown in Table 1 below:

[0098] Table 1. Checklist Configuration Table

[0099]

[0100] It should be noted that the above business scenario conditions are matching conditions consisting of a specific combination of "business dimension type: parameter value", which are used to determine the applicable business scenario conditions for the set of verification rules, thereby determining which sets of verification rules should be activated and applied to the current qualification verification process under the determined business scenario conditions.

[0101] For example, the business scenario parameter values ​​corresponding to the business scenario conditions associated with a certain set of inspection rules can be {"Region": "Guangdong Free Trade Zone"; "Customer Type": "Startup"; "Processing Channel": "Mobile Banking"}, and the associated business identifier is the business identifier of product A. Only when the current business scenario conditions determined based on the inspection task include the above three business dimension parameter values ​​and the business to be inspected includes business A, will this set of inspection rules be used as the target set of inspection rules to be matched.

[0102] In some embodiments, the business dimension parameter values ​​can also be grouped and managed to obtain business scenario dimension groups. Each business scenario dimension group can be associated with a corresponding set of verification rules, specifically the business scenario dimension group identifier in Table 1. A business scenario dimension group can consist of multiple business dimension parameter values, representing the range of business dimensions covered by the group.

[0103] It is understandable that the aforementioned business scenario dimension group is a logical classification mechanism for the set of inspection rules, used to achieve hierarchical, categorized and batch management of the set of inspection rules. By configuring the associated business scenario dimension group for the set of inspection rules, it can be determined which rule level or strategy category a set of inspection rules belongs to.

[0104] For example, when defining a business scenario dimension group based on "regional characteristics", a business scenario dimension group can be defined for the North China region. Its business dimension parameter values ​​include the institution codes of all institutions in the North China region (such as the list of institution codes of branches in Beijing, Tianjin, Hebei and other places). Then, all general verification rule sets applicable to the North China region (such as the "North China region customer access basic rule set") can be marked as belonging to the "North China region" dimension group.

[0105] Furthermore, sub-dimension groups can be defined based on more granular business dimension parameter values, for example:

[0106] Under the "North China Region" dimension group, a separate "Tianjin" sub-dimension group is defined for Tianjin. The business scenario parameter value of this sub-dimension group is the list of institution codes of Tianjin branches. The set of verification rules applicable to special rules in Tianjin (such as the "Tianjin Branch High-Risk Customer Enhanced Verification Rule Set") belongs to this sub-dimension group.

[0107] Based on this, the set of inspection rules can be hierarchically categorized. For example: Level 1: North China rule group; Level 2: Tianjin rule group. This allows for a clear view of which strategy level a particular set of inspection rules belongs to, or for unified configuration of inspection rule sets at a specific strategy level, improving configuration efficiency.

[0108] Therefore, based on business scenario dimension groups, this application can provide a structured way to perform batch operations (such as copying, migrating, and access control) on the set of check rules in the check rule base, helping administrators understand the applicable scenarios of the rules and manage a large number of business dimension types, and simplifying the rule configuration and maintenance work.

[0109] For example, batch operations can be to quickly copy or migrate the verification rule configuration by "business scenario dimension group"; access control can mean that different departments can only modify the "business scenario dimension group" they are responsible for (such as the risk control department managing "customer attributes").

[0110] Optionally, the flexibility and reusability of rule configuration can be improved by grouping related business scenario dimension types into the same group. For example, business dimensions such as "region," "organization code," and "whether it is a free trade zone" can be uniformly grouped into a business scenario dimension group representing "regional characteristics," and multiple sub-dimension groups can be created under this "regional characteristics" business scenario dimension group, such as:

[0111] Business Scenario Dimension Group 1: General Rules for Free Trade Zones;

[0112] Business Scenario Dimension Group Two: Border Outlet Special Control Rules Group;

[0113] Group 3, Business Scenario Dimension: Incentive Rules for Key Marketing Areas.

[0114] In this way, when a new free trade zone outlet is added, its organization code only needs to be added to the "Free Trade Zone General Rules Group" to automatically inherit all the inspection rule sets under that group, without the need to configure each inspection rule set individually.

[0115] In this embodiment, on the one hand, a method is proposed to determine the target set of inspection rules based on business scenario conditions and the business to be inspected. On the other hand, by supporting configuration operations on the inspection rule base, changes in business, scenarios, and inspection strategies can be responded to quickly. Business personnel can implement changes such as launching new regions or admitting new customer groups through configuration operations, without the need for developers to code. This can shorten the response time for rule changes and support for new business scenarios, and improve the flexibility and maintainability of the system.

[0116] In some embodiments, before executing the "execute the check rules in the target check rule set based on the feature data corresponding to the object" in step S103, the above qualification verification method further includes steps S106-S107.

[0117] Step S106: For each business, identify the inspection rules involving the same inspection elements but different judgment criteria in the corresponding target inspection rule set, and form corresponding rule conflict groups based on the identified inspection rules.

[0118] Step S107: Based on the preset conflict rule selection strategy, the business identifier and business scenario conditions of the business corresponding to each rule conflict group, determine the check rules to be executed in each rule conflict group.

[0119] In this embodiment of the application, the conflict rule selection strategy includes conflict decision logic configured for each business under different business scenario conditions. The conflict decision logic is used to select the inspection rule to be executed from inspection rules involving the same inspection elements but different judgment criteria.

[0120] For example, the conflict decision-making logic described above can be shown in Table 2 below:

[0121] Table 2 Examples of Conflict Decision-Making Logic

[0122]

[0123]

[0124] For example, if the "P2" business requires "corporate turnover ≥ 100,000 RMB in the last 3 months" nationwide, and also requires "corporate turnover ≥ 200,000 RMB in the last 3 months" separately in location B, and a customer in location B needs to sign up for the "P2" business, then under the current business scenario, both the "corporate turnover ≥ 100,000 RMB in the last 3 months" and "corporate turnover ≥ 200,000 RMB in the last 3 months" verification rules are met simultaneously. The system detects that both involve the verification element "corporate turnover", forming a conflict group. At this time, according to the decision logic of "the larger value takes precedence" for the P2 business and the business scenario condition in location B in Table 2, "corporate turnover ≥ 200,000 RMB in the last 3 months" is finally selected as the execution standard.

[0125] In this embodiment, under the current business scenario, the same business may be matched with multiple sets of target verification rules, resulting in rules with different judgment standards for the same verification element, thus causing rule conflicts. This application, by configuring conflict decision logic bound to business identifiers and business scenarios, can select the rule to be executed from each set of conflicting rules, ensuring the consistency and accuracy of verification results while meeting the needs of differentiated strategies.

[0126] As a feasible implementation method, the above step S104 is implemented by the following steps S104a-S104d.

[0127] Step S104a: Based on the preset mapping relationship between inspection elements and data acquisition units, determine the target data acquisition unit corresponding to each inspection element.

[0128] In the above mapping relationship, the data acquisition units corresponding to the verification elements that need to obtain element data from the same data source are the same. For example, if "Enterprise Operating Status" and "Registered Capital" are both obtained from the business registration information interface, then they correspond to the same data acquisition unit.

[0129] In this embodiment, the data acquisition unit acquires data in ways including but not limited to: directly extracting basic information fields of an object; querying an internal database based on the object's identity; calling external components or third-party interfaces (such as credit reporting platforms or government information disclosure interfaces); and generating results by performing composite calculations on multiple fields using scripts or rule engines. Simultaneously, the system provides open extension interfaces, supporting the customized development of new data acquisition units through a plug-in approach to adapt to ever-changing business needs.

[0130] Step S104b: Group each inspection element according to the corresponding target data acquisition unit to obtain the inspection elements that each target data acquisition unit needs to acquire.

[0131] Step S104c: Each target data acquisition unit is invoked to access the corresponding data source based on the object's identity identifier to batch acquire the element data corresponding to the inspection elements it needs to acquire.

[0132] Step S104d: Summarize the acquired feature data to obtain the feature data corresponding to the object.

[0133] Optionally, since multiple businesses or multiple sets of verification rules may share the same verification elements (such as "whether the enterprise is listed in the list of abnormal business operations" being used by multiple businesses), in order to avoid repeated access to the data source and improve data acquisition efficiency, this application performs deduplication processing on the verification elements before executing step S104a.

[0134] Specifically, the system compares each check element based on its element identity identifier (such as element ID). When multiple check rules depend on the same check element, only one is retained, resulting in the deduplicated check element.

[0135] For example, if a corporate client applies to activate both "Cross-border Payment P2" and "Inclusive Loan L3" services simultaneously, the system will match each with its respective set of target verification rules:

[0136] The target check rule set 1 corresponding to P2 contains the check rules:

[0137] Check Rule R1: Enterprise Status ≠ "Abnormal Operation" → Dependent Element: Enterprise Operation Status;

[0138] Inspection Rule R2: Legal representative's age ≥ 18 → Dependent factor: Legal representative's age;

[0139] Inspection Rule R3: No foreign exchange penalty record → Dependent element: Foreign exchange penalty record.

[0140] L3 corresponds to the target check rule set 2, which contains the check rules:

[0141] Check Rule R2: Legal representative's age ≥ 18 → Dependent element: Legal representative's age (repeated);

[0142] Verification Rule R4: Registered capital ≥ 500,000 RMB → Dependent factor: Registered capital;

[0143] Verification Rule R5: Corporate bank statements for the past 3 months ≥ RMB 100,000 → Dependent factor: Corporate bank statements.

[0144] The inspection elements upon which the inspection rules in Target Inspection Rule Set 1 and Target Inspection Rule Set 2 depend include:

[0145] {Business operation status, legal representative's age, foreign exchange penalty records, registered capital, corporate bank account transaction history, legal representative's age}.

[0146] After deduplication based on the element identity, the final set of verification elements to be obtained is obtained:

[0147] {Business operation status, legal representative's age, foreign exchange penalty records, registered capital, and bank account transaction history}.

[0148] Subsequently, based on steps S104a-S104d above, the system uses the enterprise's unified social credit code as its identity identifier to initiate a batch query to the following data sources, providing input for the subsequent execution of verification rules:

[0149] Obtain information from the business registration information interface: business status and registered capital;

[0150] Obtain the following from the customer master data system: legal representative's age;

[0151] Obtain foreign exchange penalty records from the State Administration of Foreign Exchange interface;

[0152] Obtain from the core banking system: Corporate account transaction records.

[0153] In this embodiment, by aggregating the verification elements according to the data source and achieving batch acquisition through a single call, repeated access and querying of the same data source can be avoided. In scenarios with concurrent verification of multiple rules, this helps to improve data acquisition efficiency and reduce network overhead.

[0154] In some embodiments, before invoking the target data acquisition unit to perform data acquisition, this application determines whether the preconditions for performing the data acquisition action are met.

[0155] Prerequisites include, but are not limited to, the following two categories:

[0156] 1. Data acquisition unit's own status

[0157] If the status of the data acquisition unit is "failed", then no data acquisition request will be initiated, and the associated check element will be directly marked as "not meeting the check conditions".

[0158] 2. Current stage of business

[0159] Each data acquisition unit can be configured with its applicable business stage identifier (such as "account opening stage", "contract signing stage", "usage stage"). The system determines whether the data acquisition unit has entered the executable stage based on the business process stage in which the current inspection task is located.

[0160] For example, suppose a customer applies to open an online banking account for a new account. The process is divided into two stages: Stage 1: Account opening stage; Stage 2: Online banking activation stage.

[0161] The data acquisition units involved in this process can be shown in Table 3 below:

[0162] Table 3. Data Acquisition Unit Configuration Diagram

[0163]

[0164]

[0165] The execution process is as follows:

[0166] Initiate the verification in Phase 1 (Account Opening Phase):

[0167] A1: Status is "Valid" and applicable to the current stage → Execute data collection to obtain E1 and E2;

[0168] A2: Although the status is "valid", its applicable stage is "signing stage and beyond". Currently, it is "account opening stage". Data collection is not performed. E3 and E4 are marked as "temporarily unverifiable" or "do not meet the conditions". Only the first round of pre-qualification is completed based on customer information.

[0169] A second check will be initiated during Phase 2 (the phase of activating online banking):

[0170] A1: It can still be executed, reused, or re-acquired;

[0171] A2: The current business stage meets the applicable conditions. Perform account information query and obtain E3 and E4.

[0172] Through the aforementioned precondition control mechanism, the embodiments of this application can dynamically determine the feasibility of data acquisition based on the customer's business process stage, effectively supporting phased verification at different stages such as account opening, contract signing, and usage, adapting to the differences in the availability of customer data at each stage, avoiding the initiation of invalid data collection requests, preventing misjudgments due to interface call failures or data loss, making the verification strategy more flexible and accurate, and fully adapting to complex and ever-changing actual business scenarios.

[0173] As a feasible implementation method, step S105 above is implemented in the following way:

[0174] According to the preset qualification verification feedback report template, the execution results are converted into a qualification verification feedback report, which includes:

[0175] The object uses the qualification verification results for each business;

[0176] For businesses that fail qualification verification, operational suggestions are generated based on business scenario conditions and the identity of the object to guide the object to pass the qualification verification.

[0177] In this embodiment, based on the verification results of the object's eligibility for each business, a preset feedback report template is invoked to generate structured feedback information. Specifically, for businesses that fail the verification, operational suggestions are generated to guide the object in completing compliant operations. The suggestions are related to the specific failure scenario. Users can directly learn the specific reasons for the eligibility verification failure and the correction path (such as changing the signatory or supplementing materials), reducing the need for repeated submissions or inquiries due to unclear information and improving the user experience.

[0178] In some embodiments, the above qualification verification method further includes the following steps S108-S109:

[0179] Step S108: Identify at least one candidate business that belongs to the same business type as the business that failed the qualification verification;

[0180] Step S109: Determine the verification result of the object's eligibility for each candidate service, and provide the candidate services with the qualified verification result as recommended services to the object.

[0181] The method for determining the qualification verification results of each candidate service for the target is the same as steps S101-S105, and will not be repeated here.

[0182] In this embodiment, when a business qualification verification fails, the system automatically identifies candidate businesses of the same type and re-executes the qualification verification process for the candidate businesses. The candidate businesses that pass the qualification verification are recommended to the customer as alternative solutions, which helps to reduce the risk of customer churn, uncover potential business opportunities, and improve business conversion rates.

[0183] In some embodiments, the step S105 above, “execute check rules based on the feature data corresponding to the object”, includes the following steps S105a-S105c.

[0184] Step S105a: Determine the strategy, business identifier and business scenario conditions of each business based on the preset rule importance level, and determine the importance level of each inspection rule.

[0185] The rule importance determination strategy includes rule importance decision logic configured for each business under different business scenario conditions. The rule importance decision logic is used to determine the importance of each check rule involved in each business under the business scenario conditions.

[0186] For example, the decision logic for the importance of the above rules can be shown in Table 4 below:

[0187] Table 4. Schematic diagram of the decision-making logic for the importance of rules.

[0188]

[0189]

[0190] Step S105b: Based on the element data corresponding to the object, execute the check rules in descending order of importance;

[0191] In step S105c, if any verification rule with an importance level higher than the preset threshold fails the verification, the qualification verification status of the business involved in the verification rule is updated to failure and the reason for failure is displayed.

[0192] In this embodiment, the importance of each verification rule is determined according to the rule importance decision logic. When a high-importance risk rule fails, the failure result and reason of the qualification verification of the business associated with the high-importance rule are quickly fed back. This prioritizes the exposure of the substantive risks that cause the qualification verification to fail, avoids users from making futile modifications due to the failure of secondary rules, and can improve verification efficiency and optimize user experience.

[0193] For example, when a company applies for the "Cross-border Payment P2" service, the system determines, based on the decision logic in Table 4, that the rule "Whether the company is on the foreign exchange blacklist" is of "high" importance in all business scenarios. During the verification process, the system prioritizes this verification rule. If it finds that the company is on the foreign exchange control list, it directly returns a qualification verification failure, indicating the reason for the failure as "the company is involved in foreign exchange compliance risks." Alternatively, the system can choose to immediately terminate the execution of subsequent rules, or continue executing subsequent rules and return a qualification verification feedback report containing the results of all rule executions after all executions are completed.

[0194] For example, when a startup applies for an "Inclusive Finance Loan L3," the system identifies its customer type as a "startup." According to Table 4, the material completeness rule is marked as "low" importance. Even if the customer has not yet uploaded all non-core materials (such as a business plan), the system can still first execute medium-to-high importance rules such as "actual controller's credit score" and "bank statements for the past 3 months." If the high importance rule is passed, the system can prompt the user that "basic qualifications are met, and supplementary materials can be submitted," rather than directly rejecting the application.

[0195] Based on the decision-making logic of the importance of the above rules, high-risk issues can be quickly exposed and blocked, improving verification efficiency. At the same time, it can be flexibly adapted to business scenarios, optimize user experience, and reduce false rejections caused by the absence of non-critical items.

[0196] like Figure 2 The diagram shown is a schematic representation of the qualification verification system architecture provided in an embodiment of this application. The architecture components shown in the diagram are described below.

[0197] 1. Initiator of the inspection task

[0198] The task initiator refers to the business system or operator that needs to verify the qualifications of a specific object. It can be a bank, an internal management system, or any other entity that needs to verify the qualifications of a customer or business object. Its main function is to submit verification requests to the qualification verification system and, when necessary, query the verification results. The task initiator interacts with the qualification verification system through the external service layer, submitting verification tasks containing information such as the object to be verified, business identifiers, and scenario conditions, as well as querying the verification results.

[0199] 2. External Service Layer

[0200] The external service layer serves as the entry point for the qualification verification system, including the functions of receiving verification tasks and querying verification results. It can receive verification requests initiated from outside and provide a service for querying verification results.

[0201] The inspection task receiving function receives inspection requests from the inspection task initiator, including key parameters such as customer information, business identifiers, and business scenario conditions, and then passes this information to the application service layer for processing.

[0202] The query function for inspection results allows the initiator of an inspection task to query the results of executed inspection tasks, and supports querying by task ID or object.

[0203] 3. Application Service Layer

[0204] The application service layer, as the core processing layer of the qualification verification system, includes the verification engine module and the rule configuration module, and is responsible for the execution of verification logic and the management of rule configuration.

[0205] The verification engine module includes the processing logic of the qualification verification method in the aforementioned embodiments. It can match the target verification rule set according to the received verification task, call the data acquisition unit to collect the required element data, and execute the verification rules. At the same time, it dynamically adjusts the rule execution order and priority based on the conflict rule selection strategy package and the importance of the rules to ensure that the qualification verification is completed efficiently and accurately.

[0206] The rule configuration module is responsible for maintaining various check rules and their applicable conditions (such as configuring business identifiers and business scenario conditions) in the check rule base of the aforementioned embodiments. It supports flexible configuration of conflict rule selection strategy packages and rule importance determination strategies to adapt to differentiated needs under different business scenario conditions.

[0207] 4. Public Service Layer

[0208] The public service layer provides general data collection capabilities through the data acquisition unit, serving as the data source for the inspection engine module.

[0209] Among them, the data acquisition unit encapsulates specific data collection logic for different inspection elements, and can obtain the required customer information, account status and other information from the data source storing object information; each data acquisition unit can dynamically decide whether to execute according to its applicable stage and status conditions.

[0210] Data source for storing object information: This stores relevant information for all objects to be inspected and is the direct data source for the data acquisition unit. It includes, but is not limited to, multi-dimensional data such as basic customer information, account transaction records, and business operation status, and supports both structured and unstructured data storage.

[0211] Based on the same inventive concept, embodiments of this application also provide a qualification verification device, such as... Figure 3 As shown, the device includes:

[0212] The task receiving module 301 is used to determine the business scenario conditions and at least one business to be inspected based on the received inspection task, wherein the inspection task is used to verify the eligibility of the object to use each of the businesses.

[0213] The rule determination module 302 is used to determine, for each of the services, a set of target inspection rules that match the service scenario conditions for each service;

[0214] The element determination module 303 is used to determine the inspection elements involved in the inspection rules based on the inspection rules in the target inspection rule set. The inspection elements are used to indicate the element data that needs to be obtained from the data source storing the information of the object when executing the inspection rule.

[0215] The element acquisition module 304 is used to acquire element data corresponding to the object from the data source based on the object's identity identifier and the verification element;

[0216] The rule execution module 305 is used to execute the verification rules based on the element data corresponding to the object, and obtain the verification result of the object's eligibility to use each of the services based on the execution result.

[0217] As a feasible implementation, the business scenario conditions include at least one business dimension and business dimension parameter values ​​corresponding to each business dimension, and each business dimension represents a type of business scenario feature that affects the configuration of the inspection rules;

[0218] The rule determination module 302 is specifically used for:

[0219] For each of the aforementioned services, based on the service identifier of the service and the service dimension parameter values ​​of each service dimension constituting the service scenario conditions, a matching is performed in a preset check rule base to obtain a target check rule set that matches the service identifier of the service and the service dimension parameter values ​​included in the service scenario conditions.

[0220] The inspection rule base supports configuration management through configuration operations, which include: configuring new inspection rules based on existing inspection elements; creating new inspection rule sets based on existing inspection rules; and configuring inspection rules in existing inspection rule sets and their associated business identifiers and business dimension parameter values.

[0221] As one possible implementation method, the rule execution module 305 is specifically used for:

[0222] According to the preset qualification verification feedback report template, the execution result is converted into a qualification verification feedback report, which includes: the verification result of the object's qualification for each of the services; and for services that fail qualification verification, operation suggestions generated based on the service scenario conditions and the object's identity to guide the object to pass the qualification verification.

[0223] As a possible implementation, the apparatus further includes a candidate recommendation module, configured to determine at least one candidate service belonging to the same service type as the service that failed the qualification verification; determine the qualification verification result of the object using each of the candidate services; and provide the candidate services with the qualification verification result of passing as recommended services to the object.

[0224] As one feasible implementation, the element acquisition module 304 is specifically used for:

[0225] Based on the preset mapping relationship between inspection elements and data acquisition units, the target data acquisition unit corresponding to each inspection element is determined; wherein, the data acquisition units corresponding to inspection elements that need to acquire element data from the same data source are the same in the mapping relationship.

[0226] Each of the inspection elements is grouped according to its corresponding target data acquisition unit to obtain the inspection elements that each target data acquisition unit needs to acquire.

[0227] Each target data acquisition unit is invoked to access the corresponding data source based on the object's identity identifier to batch acquire the element data corresponding to the inspection elements it needs to acquire;

[0228] The acquired element data is summarized to obtain the element data corresponding to the object.

[0229] As a feasible implementation, the device further includes a conflict rule processing module, which is used to identify, for each business, the inspection rules involving the same inspection elements but with different judgment criteria in the corresponding target inspection rule set before executing the inspection rules in the target inspection rule set based on the element data corresponding to the object, and form a corresponding rule conflict group based on the identified inspection rules.

[0230] Based on the preset conflict rule selection strategy, the business identifier of the business corresponding to each rule conflict group, and the business scenario conditions, the check rule to be executed in each rule conflict group is determined.

[0231] The conflict rule selection strategy includes conflict decision logic configured for each business under different business scenario conditions. The conflict decision logic is used to select the inspection rule to be executed from the inspection rules involving the same inspection elements but different judgment criteria.

[0232] As one possible implementation method, the rule execution module 305 is specifically used for:

[0233] Based on a preset rule importance determination strategy, the business identifier of each business, and the business scenario conditions, the importance of each inspection rule is determined; wherein, the rule importance determination strategy includes rule importance decision logic configured for each business under different business scenario conditions, and the rule importance decision logic is used to determine the importance of each inspection rule involved in each business under the business scenario conditions;

[0234] Based on the element data corresponding to the object, the inspection rules are executed sequentially from high to low importance.

[0235] If any verification rule whose importance exceeds the preset threshold fails the verification, the qualification verification status of the business involved in that verification rule will be updated to failure and the reason for failure will be displayed.

[0236] Based on the same inventive concept, this application also provides a qualification verification device 400, such as... Figure 4 As shown, it includes at least one processor 402; and a memory 401 communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described qualification verification method.

[0237] Memory 401 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions. Memory 401 may be volatile memory, such as random-access memory (RAM); it may also be non-volatile memory, such as flash memory, hard disk drive (HDD), or solid-state drive (SSD); or it may be any one or a combination of the above-mentioned volatile and non-volatile memory types.

[0238] Processor 402 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. It can also be a hardware chip. The aforementioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0239] This invention also provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the qualification verification method provided in the above embodiments.

[0240] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0241] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, apparatuses, or modules, and may be electrical, mechanical, or other forms.

[0242] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0243] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0244] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0245] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0246] The technical solutions provided in this application have been described in detail above. Specific examples have been used in this application to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0247] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0248] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0249] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0250] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0251] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A qualification verification method, characterized in that, include: Based on the received inspection task, the business scenario conditions and at least one business to be inspected are determined, wherein the inspection task is used to verify the object's eligibility to use each of the businesses. For each of the aforementioned services, determine a set of target verification rules that match the conditions of the service scenario. Based on the inspection rules in the target inspection rule set, the inspection elements involved in the inspection rules are determined. The inspection elements are used to indicate the element data that needs to be obtained from the data source storing the information of the object when executing the inspection rule. Based on the object's identity and the verification elements, obtain the element data corresponding to the object from the data source; The verification rules are executed based on the element data corresponding to the object, and the verification result of the object's eligibility to use each of the services is obtained based on the execution result.

2. The method according to claim 1, characterized in that, The business scenario conditions include at least one business dimension and a business dimension parameter value corresponding to each business dimension. Each business dimension represents a type of business scenario feature that affects the configuration of the inspection rules. The step of determining the set of target verification rules that match the business scenario conditions for each of the aforementioned businesses includes: For each of the aforementioned services, based on the service identifier of the service and the service dimension parameter values ​​of each service dimension constituting the service scenario conditions, a matching is performed in a preset check rule base to obtain a target check rule set that matches the service identifier of the service and the service dimension parameter values ​​included in the service scenario conditions. The inspection rule base supports configuration management through configuration operations, which include: configuring new inspection rules based on existing inspection elements; creating new inspection rule sets based on existing inspection rules; and configuring inspection rules in existing inspection rule sets and their associated business identifiers and business dimension parameter values.

3. The method according to claim 2, characterized in that, The verification result for the object's eligibility to use each of the services, obtained based on the execution result, includes: According to the preset qualification verification feedback report template, the execution result is converted into a qualification verification feedback report, which includes: the verification result of the object's qualification for each of the services; and for services that fail qualification verification, operation suggestions generated based on the service scenario conditions and the object's identity to guide the object to pass the qualification verification.

4. The method according to claim 3, characterized in that, The method further includes: Identify at least one candidate business that belongs to the same business type as the business that failed the qualification verification; The verification result of the object's eligibility to use each of the candidate services is determined, and the candidate services with the qualified verification result are provided to the object as recommended services.

5. The method according to claim 1, characterized in that, The step of obtaining the element data corresponding to the object from the data source based on the object's identity and the verification elements includes: Based on the preset mapping relationship between inspection elements and data acquisition units, the target data acquisition unit corresponding to each inspection element is determined; wherein, the data acquisition units corresponding to inspection elements that need to acquire element data from the same data source are the same in the mapping relationship. Each of the inspection elements is grouped according to its corresponding target data acquisition unit to obtain the inspection elements that each target data acquisition unit needs to acquire. Each target data acquisition unit is invoked to access the corresponding data source based on the object's identity identifier to batch acquire the element data corresponding to the inspection elements it needs to acquire; The acquired element data is summarized to obtain the element data corresponding to the object.

6. The method according to claim 1, characterized in that, Before executing the check rules in the target check rule set based on the feature data corresponding to the object, the method further includes: For each of the aforementioned services, identify the inspection rules that involve the same inspection elements but have different judgment criteria in the corresponding target inspection rule set, and form corresponding rule conflict groups based on the identified groups of inspection rules; Based on the preset conflict rule selection strategy, the business identifier of the business corresponding to each rule conflict group, and the business scenario conditions, the check rule to be executed in each rule conflict group is determined. The conflict rule selection strategy includes conflict decision logic configured for each business under different business scenario conditions. The conflict decision logic is used to select the inspection rule to be executed from the inspection rules involving the same inspection elements but different judgment criteria.

7. The method according to claim 1, characterized in that, The execution of the inspection rule based on the feature data corresponding to the object includes: Based on a preset rule importance determination strategy, the business identifier of each business, and the business scenario conditions, the importance of each inspection rule is determined; wherein, the rule importance determination strategy includes rule importance decision logic configured for each business under different business scenario conditions, and the rule importance decision logic is used to determine the importance of each inspection rule involved in each business under the business scenario conditions; Based on the element data corresponding to the object, the inspection rules are executed sequentially from high to low importance. If any verification rule whose importance exceeds the preset threshold fails the verification, the qualification verification status of the business involved in that verification rule will be updated to failure and the reason for failure will be displayed.

8. A qualification verification device, characterized in that, include: The task receiving module is used to determine the business scenario conditions and at least one business to be inspected based on the received inspection task. The inspection task is used to verify the object's eligibility to use each of the business. The rule determination module is used to determine, for each of the services, a set of target inspection rules that match the conditions of the service scenario for each service; The element determination module is used to determine the inspection elements involved in the inspection rules based on the inspection rules in the target inspection rule set. The inspection elements are used to indicate the element data that needs to be obtained from the data source storing the information of the object when executing the inspection rule. The element acquisition module is used to acquire element data corresponding to the object from the data source based on the object's identity identifier and the verification elements; The rule execution module is used to execute the verification rules based on the element data corresponding to the object, and obtain the verification result of the object's eligibility to use each of the services based on the execution result.

9. A qualification verification device, characterized in that, The method includes at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the qualification verification method as described in any one of claims 1-7.

Images