Data verification method, electronic device, and storage medium for financial business

Abstract

The present application relates to the financial field and the field of data processing technology, and in particular to a data verification method, electronic device, and storage medium for financial business. According to the data verification method for financial business in the embodiment of the present application, it is applied to the financial business service end, and it is necessary to first obtain the front-end data request and financial business data; perform interface parsing on the front-end data request to determine the interface request identifier; query in a preset verification database based on the interface request identifier to obtain target interface information and target verification rules that match the target interface information; perform data verification on the financial business data based on the target verification rules to obtain verification result information. In this way, the efficiency of verification of financial business data can be improved.

Description

Technical Field

[0001] The present application relates to the fields of finance and data processing technology, and in particular to a data verification method, electronic device, and storage medium for financial services. Background Art

[0002] Data verification is particularly important in the financial and insurance sectors, as this involves the flow of vast amounts of financial resources and user information. Data verification is a critical step in the data flow process, ensuring data accuracy and security. Currently, data verification can be performed both on the front-end and on the financial service side. Front-end verification primarily enhances the user experience, while financial service side verification serves as the final line of defense for data security.

[0003] In related technologies, verification on the financial service server side may require writing separate verification logic for each interface. This makes verification rules difficult to reuse, increases code maintenance costs, and makes it difficult to adapt to changes in verification requirements. Under this data verification method, verification logic for different interfaces is written independently, resulting in code duplication and difficulty in unified management. The same verification rules need to be repeatedly developed for different interfaces, reducing development efficiency. Therefore, how to improve the efficiency of verification for financial service data has become a difficult problem that needs to be solved urgently in the industry. Summary of the Invention

[0004] The present application aims to solve at least one of the technical problems existing in the related art. To this end, the present application proposes a data verification method, electronic device, and storage medium for financial services, which can improve the efficiency of verifying financial service data.

[0005] According to the first aspect of the present application, a data verification method for financial services is applied to a financial service server, including:

[0006] Obtain front-end data requests and financial business data;

[0007] Performing interface analysis on the front-end data request to determine the interface request identifier;

[0008] Based on the interface request identifier, a query is performed in a preset verification database to obtain target interface information and a target verification rule matching the target interface information;

[0009] The financial business data is verified based on the target verification rule to obtain verification result information.

[0010] According to some embodiments of the present application, before querying a preset verification database based on the interface request identifier, the verification database is further preset, specifically including:

[0011] Identify multiple alternative interface types;

[0012] For each of the candidate interface types, at least one corresponding preparation scenario information is configured; wherein the mapping relationship type between the candidate interface type and the preparation scenario information is a first type mapping relationship;

[0013] For each type of the preliminary scenario information, a corresponding alternative verification rule is configured; wherein the mapping relationship type between the preliminary scenario information and the alternative verification rule is a second type mapping relationship;

[0014] Based on the first type of mapping relationship, each candidate interface type and the preliminary scenario information corresponding to the candidate interface type are integrated to obtain an interface scenario mapping table; wherein one candidate interface type corresponds to one interface scenario mapping table;

[0015] Based on the second type of mapping relationship, each of the preliminary scene information and the candidate verification rules corresponding to the preliminary scene information are integrated to obtain a verification rule table; wherein each type of preliminary scene information corresponds to one verification rule table;

[0016] Based on the preliminary scenario information, the interface scenario mapping table and the verification rule table are stored in the verification database to preset the verification database.

[0017] According to some embodiments of the present application, for each type of the preliminary scenario information, configuring a corresponding alternative verification rule includes:

[0018] For the preliminary scenario information, configure the corresponding verification rule identification field, applicable scenario description field, rule service class field and verification conclusion field;

[0019] The verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field are integrated to obtain the alternative verification rule corresponding to the preliminary scenario information.

[0020] According to some embodiments of the present application, performing data verification on the financial business data based on the target verification rule to obtain verification result information includes:

[0021] Invoking a target rule service class that matches the financial business data according to the rule service class field of the target verification rule;

[0022] The financial business data is verified through the target rule service class to obtain verification result information.

[0023] According to some embodiments of the present application, before integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the alternative verification rule corresponding to the preliminary scenario information, the method further includes:

[0024] For the preliminary scenario information, configure first response logic information corresponding to verification passing;

[0025] The step of integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the candidate verification rule corresponding to the preliminary scenario information includes:

[0026] The first response logic information, the verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field are integrated to obtain the alternative verification rule.

[0027] According to some embodiments of the present application, after performing data verification on the financial business data based on the target verification rule to obtain verification result information, the method further includes:

[0028] In response to the verification result information reflecting that the financial business data passes verification, determining the first response logic information of the target verification rule as target logic response information;

[0029] A verification response operation is performed according to the target logical response information.

[0030] According to some embodiments of the present application, before integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the alternative verification rule corresponding to the preliminary scenario information, the method further includes:

[0031] For the preparation scenario information, configure second response logic information corresponding to verification failure;

[0032] The step of integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the candidate verification rule corresponding to the preliminary scenario information includes:

[0033] The second response logic information, the verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field are integrated to obtain the alternative verification rule.

[0034] According to some embodiments of the present application, after performing data verification on the financial business data based on the target verification rule to obtain verification result information, the method further includes:

[0035] In response to the verification result information reflecting that the financial business data fails verification, determining the second response logic information of the target verification rule as target logic response information;

[0036] A verification response operation is performed according to the target logical response information.

[0037] In a second aspect, an embodiment of the present application provides an electronic device comprising: a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements a data verification method for financial services as described in any one of the embodiments of the first aspect of the present application.

[0038] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a program, and the program is executed by a processor to implement a data verification method for financial services as described in any one of the embodiments of the first aspect of the present application.

[0039] The data verification method, electronic device, and storage medium for financial services according to the embodiments of the present application have at least the following beneficial effects:

[0040] According to the data verification method for financial services in the embodiment of the present application, when applied to a financial service server, it is necessary to first obtain a front-end data request and financial service data; perform interface parsing on the front-end data request to determine an interface request identifier; perform a query in a preset verification database based on the interface request identifier to obtain target interface information and a target verification rule that matches the target interface information; perform data verification on the financial service data based on the target verification rule to obtain verification result information. In this way, the efficiency of verifying financial service data can be improved.

[0041] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become obvious from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0043] Figure 1 A flowchart of a data verification method for financial services provided in an embodiment of the present application;

[0044] Figure 2Another schematic diagram of a data verification method according to an embodiment of the present invention;

[0045] Figure 3 Another schematic diagram of a data verification method according to an embodiment of the present invention;

[0046] Figure 4 Another schematic diagram of a data verification method according to an embodiment of the present invention;

[0047] Figure 5 Another schematic diagram of a data verification method according to an embodiment of the present invention;

[0048] Figure 6 Another schematic diagram of a data verification method according to an embodiment of the present invention;

[0049] Figure 7 Another schematic diagram of a data verification method according to an embodiment of the present invention;

[0050] Figure 8 Another schematic diagram of a data verification method according to an embodiment of the present invention;

[0051] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] The following describes in detail embodiments of the present application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application and are not to be construed as limiting the present application.

[0053] In the description of this application, "several" means one or more, "many" means more than two, "greater than," "less than," and "exceed" are understood to exclude the number itself, while "above," "below," and "within" are understood to include the number itself. The terms "first" and "second" are used solely to distinguish technical features and are not to be construed as indicating or implying relative importance, or as implicitly specifying the number or order of the technical features indicated.

[0054] In the description of this application, it should be understood that descriptions involving orientations, such as up, down, left, right, front, and back, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, they cannot be understood as limitations on this application.

[0055] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0056] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "set," "install," and "connect" should be understood in a broad sense, and those skilled in the art can reasonably determine the specific meanings of the above terms in this application based on the specific content of the technical solution. In addition, the identification of specific steps below does not represent a limitation on the order of steps and execution logic. The execution order and execution logic between each step should be understood and inferred with reference to the content described in the embodiments.

[0057] Data verification is particularly important in the financial and insurance sectors, as this involves the flow of vast amounts of financial resources and user information. Data verification is a critical step in the data flow process, ensuring data accuracy and security. Currently, data verification can be performed both on the front-end and on the financial service side. Front-end verification primarily enhances the user experience, while financial service side verification serves as the final line of defense for data security.

[0058] In related technologies, verification on the financial service server side can require writing separate verification logic for each interface. This makes verification rules difficult to reuse, increases code maintenance costs, and makes it difficult to adapt to changes in verification requirements. Under this data verification method, verification logic for different interfaces is written independently, resulting in code duplication and difficulty in unified management. The same verification rules need to be repeatedly developed for different interfaces, reducing development efficiency. Furthermore, as verification requirements change, the decentralized verification logic needs to be frequently updated, increasing maintenance costs.

[0059] The defects and deficiencies of relevant technologies in data verification on the financial service side are manifested in the following aspects in the financial and insurance fields:

[0060] Multi-channel data validation: The financial and insurance sectors can encompass multiple business engagement channels, such as online platforms, mobile applications, and physical branches. Each channel may require different data validation rules, and related technologies may struggle to efficiently manage and apply these dispersed validation logic.

[0061] Complex business rules: The rules involved in financial and insurance businesses can be extremely complex, including but not limited to customer identity verification, resource flow verification, and policy information validation. In related technologies, each new business or rule may require code modifications, which not only increases development and maintenance workload but also increases the risk of errors.

[0062] Real-time and dynamic performance: Financial markets change rapidly, and insurance needs are constantly evolving, requiring the ability to quickly respond and adjust data validation rules. However, updating validation rules in existing technologies may require modifying and redeploying code, which fails to meet real-time and dynamic performance requirements.

[0063] Compliance and Auditing: The financial and insurance industries are subject to strict regulation, requiring them to ensure that all data verification processes meet compliance requirements and are auditable. However, relevant technologies may struggle to provide unified, transparent, and queryable verification rule management.

[0064] The present application aims to solve at least one of the technical problems existing in the related art. To this end, the present application proposes a data verification method, electronic device, and storage medium for financial services, which can improve the efficiency of verifying financial service data.

[0065] The following is a further explanation based on the accompanying drawings.

[0066] Reference Figure 1 According to the data verification method for financial services provided in the embodiments of the present application, when applied to a financial service server, the method may include, but is not limited to, the following steps:

[0067] Step S101, obtaining front-end data request and financial business data;

[0068] Step S102: performing interface analysis on the front-end data request to determine the interface request identifier;

[0069] Step S103: querying a preset verification database based on the interface request identifier to obtain target interface information and target verification rules matching the target interface information;

[0070] Step S104: perform data verification on the financial business data based on the target verification rules to obtain verification result information.

[0071] According to the data verification method for financial business of the embodiment of the present application, through this implementation method, the financial business service end can realize efficient verification of financial business data. Its advantage is that it can reduce code duplication, reduce maintenance costs, and use the verification database to centrally manage verification rules, thereby improving the reusability and adaptability of the rules. In addition, this embodiment also allows for rapid response to changes in verification requirements, because the update and maintenance of verification rules no longer require the modification of a large amount of code, but is achieved by updating the rules in the database. This not only improves development efficiency, but also provides a more solid guarantee for the data security of financial business, and is more conducive to improving the efficiency of verification of financial business data.

[0072] In step S101 of some embodiments, a front-end data request and financial business data are obtained.

[0073] It should be noted that in financial services, the accuracy and security of financial service data are crucial because they directly affect the flow of financial resources and the protection of user information. To ensure that these financial service data are accurate and secure before entering the financial service server for processing, embodiments of the present application first need to obtain front-end data requests and financial service data. In some embodiments, financial service data can be received from a user interface or front-end application. This financial service data may include resource flow information, user authentication information, account details, etc.

[0074] In some embodiments, in order to ensure the integrity and consistency of data in the process of obtaining financial business data and avoid any form of damage or tampering during the transmission of financial business data, front-end verification can be performed in advance, such as format verification, required field verification, etc., to improve user experience and preliminarily filter out some obvious erroneous data.

[0075] However, the front-end verification of some embodiments is not sufficient to ensure the security of financial business data because they can be bypassed or used illegally. It is for this reason that the financial business service end of the embodiment of the present application needs to perform a deeper level of data verification. In step S101 of the embodiment of the present application, the financial business service end needs to receive a front-end data request from the front end. After the financial business service end receives the front-end data request and the financial business data, it can further analyze and verify the financial business data under the action of the front-end data request to ensure that the data format is correct, the fields are complete, and it complies with the business logic.

[0076] In some specific embodiments, the step of obtaining financial service data may further include a preliminary assessment of the security of the financial service data, such as checking whether the financial service data is encrypted, determining whether the financial service data comes from a trusted source, etc. These measures help prevent the financial service data from being intercepted or tampered with during transmission, thereby protecting the security of financial service data.

[0077] In some more specific embodiments, the front-end data request may include two types: storage request and extraction request, each type has its own specific application scenario and processing flow.

[0078] A storage request refers to a request from a front-end application to submit financial business data to a financial business server for storage. In financial services, this may include resource flow information, account details, and more. When a user enters information or performs an operation in the front-end application, the front-end packages this data into a storage request and sends it to the financial business server. Upon receiving the storage request, the financial business server verifies the financial business data using the target validation rules from the validation database to ensure its accuracy and security. If the financial business data passes validation, the financial business server performs the storage operation, such as saving the resource flow record to the database or updating the user's account information.

[0079] A pull request is a request from a front-end application to a financial service server for financial business data. In financial services, users may need to query information such as account balances, resource transfer history, and investment portfolios. Pull requests allow users to retrieve this financial business data for review or further operation. Upon receiving a pull request, the financial service server retrieves the corresponding financial business data from a database or other storage medium based on the request content and returns the results to the front-end application.

[0080] In step S102 of some embodiments, interface parsing is performed on the front-end data request to determine the interface request identifier.

[0081] In the data verification process for financial services, it is necessary to perform interface parsing on the front-end data request to determine the interface request identifier. The purpose of this step is to ensure that the financial service server can accurately identify and process the request from the front-end, so as to carry out subsequent data verification and business logic processing.

[0082] It should be noted that the interface parsing in the embodiment of the present application is intended to analyze the front-end data request sent by the front-end and extract key information therein, such as request type, target resource, operation intention, etc.

[0083] In some more specific embodiments, these front-end data requests may be sent in the form of HTTP requests, including request methods (such as GET, POST), request headers, request bodies, etc. After receiving these front-end data requests, the financial service server needs to parse the key information contained therein to clarify the specific content and purpose of the request.

[0084] It's important to note that the interface request identifier can be a unique identifier used to distinguish different front-end data requests. Specifically, this identifier can be a URL path, an operation code, or a specific request parameter. Using this interface request identifier, the financial service server can quickly locate the corresponding interface logic and determine how to handle the corresponding front-end data request.

[0085] In financial services, determining interface request identifiers is particularly important because financial services can involve multiple different services and operations, such as account management, resource flow processing, and risk assessment. Each service and operation has its own specific business rules and data validation requirements. Therefore, accurately determining interface request identifiers is crucial to ensuring that financial business data is validated according to the correct business rules.

[0086] Furthermore, interface parsing and request identification help improve processing efficiency on financial service servers. By quickly identifying the type and purpose of a request, financial service servers can avoid unnecessary processing delays and improve response speed. This is particularly important for financial services, where rapid response often translates to higher business efficiency and a better user experience.

[0087] Reference Figure 2 According to some embodiments of the present application, before querying the preset verification database based on the interface request identifier in step S103, the verification database may be preset, specifically including:

[0088] Step S201, determining multiple candidate interface types;

[0089] Step S202: for each candidate interface type, configure at least one corresponding preliminary scenario information; wherein the mapping relationship type between the candidate interface type and the preliminary scenario information is a first type mapping relationship;

[0090] Step S203: For each type of preliminary scenario information, a corresponding alternative verification rule is configured; wherein the mapping relationship type between the preliminary scenario information and the alternative verification rule is a second type mapping relationship;

[0091] Step S204: Based on the first type of mapping relationship, each candidate interface type and the corresponding preliminary scenario information are integrated to obtain an interface scenario mapping table; wherein one candidate interface type corresponds to one interface scenario mapping table;

[0092] Step S205: Based on the second type of mapping relationship, each piece of preliminary scene information and the candidate verification rules corresponding to the preliminary scene information are integrated to obtain a verification rule table; wherein one piece of preliminary scene information corresponds to one verification rule table;

[0093] Step S206: Based on the prepared scenario information, the interface scenario mapping table and the verification rule table are stored in the verification database to preset the verification database.

[0094] In some embodiments of the present application, pre-setting the verification database before step S103 is a key preparatory step that ensures the efficiency and accuracy of the data verification process. This pre-setting process involves multiple steps, including determining the candidate interface type, configuring scenario information and verification rules, and creating a mapping table and storing this information in the verification database.

[0095] In step S201 of some embodiments, embodiments of the present application determine multiple candidate interface types. These candidate interface types represent different types of front-end data requests that a financial service server may receive. Each type of front-end data request has corresponding business operations and data requirements. For example, financial services may include resource transfer interfaces, user management interfaces, risk assessment interfaces, and the like.

[0096] In step S202 of some embodiments, for each alternative interface type, the embodiments of the present application configure at least one corresponding preliminary scenario information. These preliminary scenario information describe the application environment and business requirements corresponding to the alternative interface type in different situations. For example, the resource flow interface may have different data requirements in normal resource flow scenarios and abnormal resource flow scenarios. In this step, the mapping relationship type established between the alternative interface type and the preliminary scenario information is a first-class mapping relationship.

[0097] In some embodiments, the data structure of the interface scenario mapping table may be as shown in Table 1 below:

[0098] property describe INTERFACE_NAME Alternative interface types SCENE Preparatory scene information

[0099] Table 1

[0100] In step S203 of some embodiments, for each type of preliminary scenario information, the embodiments of the present application configure corresponding alternative verification rules. These verification rules define the conditions that the data must meet to ensure the compliance and security of the data. For example, a normal resource flow scenario may require the number of resource flows to be within a certain range, while an abnormal resource flow scenario may require additional verification steps. What is established here is the second type of mapping relationship, that is, the association between the preliminary scenario information and the alternative verification rules.

[0101] Reference Figure 3 According to some embodiments of the present application, step S203 configures corresponding alternative verification rules for each type of preliminary scenario information, which may include, but is not limited to, the following steps:

[0102] Step S301: Configure the corresponding verification rule identification field, applicable scenario description field, rule service type field, and verification conclusion field for the preliminary scenario information;

[0103] Step S302: Integrate the verification rule identification field, the applicable scenario description field, the rule service type field, and the verification conclusion field to obtain an alternative verification rule corresponding to the preliminary scenario information.

[0104] In some embodiments of this application, configuring alternative validation rules for each pre-scenario information is a meticulous and critical process that ensures the accuracy and adaptability of data validation. This process involves not only defining the specific content of the validation rules, but also clearly describing the rule's identification, application scenario, service class, and conclusion.

[0105] In step S301 of some embodiments, for the preliminary scenario information, the present embodiment needs to configure several key fields to define the candidate verification rules. These fields may include, but are not limited to, the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field.

[0106] The validation rule identification field is a unique identifier used to distinguish between different validation rule candidates. This identifier facilitates quick retrieval and reference of specific validation rule candidates within the database. The validation rule identification field can include information such as the validation rule candidate number and name.

[0107] The Applicable Scenario Description field provides a detailed description of the specific scenarios in which the alternative validation rule applies. This helps you understand the rule's usage context and business logic, ensuring that the rule is applied in the correct scenario.

[0108] The Rule Service Class field specifies the service class or function required to execute the alternative validation rule. These service classes contain the code that implements the validation logic, which can be predefined algorithms, regular expression matching, or other business logic.

[0109] The Verification Conclusion field defines the possible conclusions after executing the alternative verification rules, such as "Pass" or "Fail," as well as the subsequent actions or prompts that may be required when the rules fail.

[0110] In step S302 of some embodiments, the embodiments of the present application integrate the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to form an alternative verification rule corresponding to the preliminary scenario information. This integration process combines the specific verification logic and business requirements to form a complete alternative verification rule entity. This alternative verification rule entity not only contains all the information required to perform the verification, but also associates it with the specific scenario information through the verification rule identification field to ensure that it can be correctly called and applied during the data verification process.

[0111] In the embodiment of the present application illustrated by steps S301 to S302, each type of preparatory scenario information has a corresponding set of alternative verification rules. These alternative verification rules define the specific conditions that the data must meet in that scenario. This configuration not only improves the manageability and maintainability of the alternative verification rules, but also enhances the pertinence and effectiveness of the verification by closely integrating the alternative verification rules with specific scenarios.

[0112] In addition, this configuration method also provides support for the flexibility and scalability of alternative verification rules. As the business develops and changes, new alternative verification rules can be added, and the original alternative verification rules can be updated or optimized, without requiring large-scale modifications to the entire embodiment of the present application. This flexibility is crucial for quickly adapting to business changes in the financial sector and meeting regulatory requirements. Especially in the financial business sector, this capability can significantly enhance the competitiveness and compliance of the embodiments of the present application.

[0113] In some embodiments, the data structure of the verification rule table may be as shown in Table 2 below:

[0114] property describe RULE_NO Alternative verification rule number RULE_NAME Alternative validation rule name RULE_SCENE Applicable scenario description field RULE_SERVICE Rule service class field, multiple RULE_RESULT Verification results, strong verification / weak verification RULE_TIPS Prompt message when verification fails RULE_DESC Business rule logic description

[0115] Table 2

[0116] Reference Figure 4 According to some embodiments of the present application, before integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field in step S302 to obtain the candidate verification rule corresponding to the preliminary scenario information, the following steps may also be included, but are not limited to:

[0117] Step S401: configuring first response logic information corresponding to verification passing for the preparatory scenario information;

[0118] In step S302, the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field are integrated to obtain an alternative verification rule corresponding to the preliminary scenario information, which may include, but is not limited to, the following steps:

[0119] Step S402: Integrate the first response logic information, the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain an alternative verification rule.

[0120] In some embodiments of the present application, before step S302, the present application embodiment can further enrich and improve the configuration of the alternative verification rules to ensure the comprehensiveness and effectiveness of the subsequent verification process. This includes configuring corresponding first response logic information for each preliminary scenario information. This first response logic information defines the action that the present application embodiment should take when the data verification passes.

[0121] In step S401 of some embodiments, for the preliminary scenario information, the embodiments of the present application will configure the first response logic information corresponding to the verification passed. The first response logic information is a set of instructions or operations that define how the embodiments of the present application should process the financial business data when the data verification is successful if the verification scenario meets the preliminary scenario information. For example, this may include storing the financial business data in a verification database, triggering a business process, sending a confirmation message to the user, etc. The configuration of the first response logic information makes the alternative verification rules focus not only on the compliance of the data, but also on the business logic processing after the verification is successful.

[0122] In step S402 of some embodiments, the embodiments of the present application integrate the first response logic information, the verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field. These fields may include the alternative verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field. Through this integration, the alternative verification rules obtained by the embodiments of the present application not only include the specific rules and conditions for data verification, but also include the business response logic after the verification is successful. It should be pointed out that this integration process ensures the integrity and consistency of the alternative verification rules. It allows the embodiments of the present application to seamlessly execute predetermined business operations after the financial business data verification is passed, thereby improving the degree of automation and efficiency of the entire financial business process. In addition, this also provides developers and business analysts with a clear perspective, enabling them to understand how the embodiments of the present application will respond after the data verification is passed in a specific scenario.

[0123] The embodiment of the present application shown in steps S401 to S402 enhances the flexibility and scalability of data verification. As financial services evolve and change, new response logic can be added and the existing logic can be adjusted as needed. This flexibility is crucial for quickly adapting to business changes and meeting regulatory requirements, especially in the financial business sector. This capability can significantly enhance the competitiveness and compliance of the embodiments of the present application.

[0124] Reference Figure 5According to some embodiments of the present application, before integrating the candidate verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field in step S302 to obtain the candidate verification rule corresponding to the preliminary scenario information, the following steps may also be included, but are not limited to:

[0125] Step S501: configuring second response logic information corresponding to verification failure for the preparation scenario information;

[0126] In step S302, the candidate verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field are integrated to obtain the candidate verification rule corresponding to the preliminary scenario information, which may include, but is not limited to, the following steps:

[0127] Step S502: Integrate the second response logic information, the alternative verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the alternative verification rule.

[0128] In some embodiments of the present application, to enhance the practicality of alternative data validation rules and to address various possible outcomes, additional configuration steps may be performed before integrating the alternative validation rule fields to form the alternative validation rules. This includes configuring secondary response logic information for the preliminary scenario information, i.e., the action that the present application embodiment should take when data validation fails.

[0129] In step S501 of some embodiments, the embodiments of the present application first configure the second response logic information for the preliminary scenario information. The second response logic information defines how the embodiments of the present application should respond when the financial business data verification fails. The second response logic may include generating an error report, sending a notification to the user or administrator, recording detailed information about the verification failure, executing a specific error handling process, etc. This configuration method allows the embodiments of the present application to take appropriate measures when faced with data that does not comply with the rules, ensuring that the problem can be discovered and properly handled in a timely manner.

[0130] In step S502 of some embodiments, the embodiments of the present application integrate the various key fields of the alternative verification rules to form alternative verification rules corresponding to the preliminary scenario information. These key fields include the alternative verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field, which together define the core content and application conditions of the alternative verification rules. In step S502, the embodiments of the present application further integrate the second response logic information with the above-mentioned alternative verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field. The alternative verification rules obtained in this way not only include the standards and conditions for data verification, but also include the countermeasures when the verification fails. This integration ensures the comprehensiveness of the alternative verification rules, so that the rules not only focus on the compliance of the data, but also on the processing flow after the verification fails.

[0131] The embodiment of the present application shown through steps S501 to S502 can handle various verification results more flexibly and efficiently. When the data verification passes, the corresponding business operation can be performed according to the first response logic information; and when the data verification fails, the corresponding error handling measures can be taken according to the second response logic information. This design improves the robustness of the embodiment of the present application and the user experience, and also provides clear guidance for developers and business analysts, enabling them to better understand and maintain alternative verification rules.

[0132] In step S204 of some embodiments, based on the first type of mapping relationship, the embodiments of the present application integrate each candidate interface type and its corresponding preliminary scenario information to form an interface scenario mapping table. This interface scenario mapping table clarifies the applicability of each interface type in different scenarios and provides a basis for subsequent data verification.

[0133] In step S205 of some embodiments, based on the second type of mapping relationship, the embodiments of the present application integrate each type of preliminary scenario information and its corresponding candidate verification rule to form a candidate verification rule table. This table lists all the candidate verification rules that the data needs to meet in a specific scenario.

[0134] In step S206 of some embodiments, the present invention stores the interface scenario mapping table and the alternative validation rule table in the validation database, completing the presetting of the validation database. In this way, when the financial service server receives a front-end data request, it can quickly query the corresponding target interface type, target scenario information, and target alternative validation rules, thereby performing effective data validation.

[0135] By presetting a series of steps for verifying the database, the embodiments of the present application can provide customized data verification processes for different financial business scenarios, improving the pertinence and efficiency of verification. At the same time, this presetting mechanism also enhances the flexibility and scalability of the embodiments of the present application, allowing for rapid adjustment and updating of alternative verification rules when business needs change without requiring large-scale code modifications. This is of great significance for the rapid response and continuous compliance of financial businesses.

[0136] In step S103 of some embodiments, a query is performed in a preset verification database based on the interface request identifier to obtain target interface information and a target verification rule matching the target interface information.

[0137] It should be noted that the interface request identifier serves as an index for queries in the verification database, helping the financial service server quickly locate specific interface information and obtain the target interface information. The target interface information may include the interface name, function description, and related business logic that matches the interface request identifier. It should be understood that obtaining target interface information is a prerequisite for data verification of financial service data, as different target interface information may correspond to different business scenarios and data requirements.

[0138] Furthermore, the financial service server uses the target interface information to further query a pre-set validation database to obtain target validation rules that match the target interface information. The validation database centrally stores and manages all validation rules, allowing the financial service server to retrieve the corresponding validation rules based on different interface request identifiers. These validation rules define the conditions that financial service data must meet, such as data type, format, range, and logical relationships, to ensure the compliance and consistency of financial service data.

[0139] Through this query mechanism, the financial service server of the embodiment of the present application can achieve dynamic management and application of data validation rules. Compared with traditional hard-coding methods, this embodiment has higher flexibility and maintainability. When business requirements change or new validation rules need to be introduced, only the rules in the validation database need to be updated, without having to modify a large amount of code. This greatly reduces maintenance workload and speeds up response time.

[0140] Furthermore, centrally managed validation rules make it easier for developers and business analysts to understand and maintain them. They can clearly see the validation rules corresponding to each interface and how these validation rules are applied in actual business scenarios, which improves convenience.

[0141] In step S104 of some embodiments, data verification is performed on the financial business data based on the target verification rules to obtain verification result information.

[0142] It should be noted that the financial service server first verifies each received financial service data according to the target verification rules obtained in the previous step. Target verification rules may include data type checking, format verification, range restrictions, logical consistency checks, etc. These target verification rules are pre-set based on the specific needs of the financial service. For example, the verification of the number of resource transfers may require ensuring that the number is positive and conforms to a specific resource format; the verification of user identification information may require verifying the existence and validity of the user ID.

[0143] It's important to note that during the data verification process for financial business data based on target verification rules, the financial business server can compare each piece of financial business data against the target verification rules to ensure that each piece of financial business data meets the established criteria. If the financial business data passes all target verification rules, it is considered compliant and can proceed with subsequent business processing. Conversely, if the financial business data fails one or more target verification rules, the financial business server will record these violations and generate corresponding verification result information, such as which rules failed and the specific error message. This generated verification result information is of great significance to both front-end users and the financial business server. For front-end users, this verification result information can help them understand the reasons for data submission failures and make appropriate modifications and resubmissions. For the financial business server, this verification result information helps monitor data quality, promptly identify and correct data issues, and prevent the impact of data errors on business processes.

[0144] Furthermore, step S104 demonstrates the flexibility and scalability of the data verification process in the embodiments of the present application. As financial services evolve and change, new verification rules may need to be introduced, or existing rules may need to be updated. In this dynamically changing environment, the ability to quickly adapt and execute data verification based on target verification rules is crucial to maintaining the competitiveness and compliance of financial services.

[0145] To sum up, step S104 of the embodiment within this community verifies the financial business data based on the target verification rules and generates verification result information, which not only ensures the accuracy and security of the financial business data, but also improves the efficiency and quality of financial business processing.

[0146] Reference Figure 6 According to some embodiments of the present application, step S104 performs data verification on the financial business data based on the target verification rule to obtain verification result information, which may include, but is not limited to, the following steps:

[0147] Step S601: Call the target rule service class that matches the financial business data according to the rule service class field of the target verification rule;

[0148] Step S602: Perform data verification on the financial business data through the target rule service class to obtain verification result information.

[0149] In some embodiments of the present application, step S104 is the execution phase of the data verification process, which verifies the financial business data based on the target verification rules and generates verification result information. This process is a key step in ensuring data accuracy and security, and involves calling specific service classes to execute verification logic and evaluate the data.

[0150] In step S601 of some embodiments, the embodiments of the present application determine the specific service class that needs to be called based on the rule service class field in the target verification rule. The rule service class field is previously configured when the verification rule is preset, and it specifies the service class or function required to perform the verification. These service classes contain code that implements the verification logic and can be written based on specific algorithms, regular expression matching, or other business logic. Through the rule service class field, the embodiments of the present application can locate and call the target rule service class that matches the financial business data.

[0151] In step S602 of some embodiments, embodiments of the present application perform actual data verification on financial business data by invoking the target rule service class. This step is the core of the data verification process and involves comparing the data with the verification rules to verify whether the data meets the predetermined conditions. The verification process may include data type checking, format verification, range restriction, logical consistency verification, etc. Depending on the verification rules, the service class will perform the corresponding verification operations and generate verification results.

[0152] It's important to note that validation result information is the output of the validation process, detailing the results of data validation. If the data meets all validation rules, the validation result can indicate that the data has passed validation, and subsequent business processing can proceed. If the data fails one or more validation rules, the validation result can also record these violations and provide specific error details, such as which rules failed and a detailed description of the error. These error details are crucial for both front-end users and financial service servers, helping them understand the reasons for data submission failures and guiding them in making appropriate corrections.

[0153] Through step S601 to step S602 of the embodiment of the present application, the design of this verification process embodies a high degree of flexibility and scalability. As business needs change, new verification rules can be added to the embodiment of the present application, and the original rules can also be updated or optimized as needed. This design allows the embodiment of the present application to quickly adapt to new business scenarios and regulatory requirements without the need for large-scale code rewriting.

[0154] Reference Figure 7 According to some embodiments of the present application, after performing data verification on the financial business data based on the target verification rule and obtaining verification result information in step S104, the following steps may also be included, but are not limited to:

[0155] Step S701: In response to the verification result information reflecting that the financial business data passes the verification, the first response logic information of the target verification rule is determined as the target logic response information;

[0156] Step S702: Perform a verification response operation according to the target logic response information.

[0157] In some embodiments of the present application, once the data verification of financial business data is completed based on the target verification rules and verification result information is obtained, the embodiments of the present application will further perform corresponding verification response operations based on the verification results. This process ensures that the verification rules are not only used to identify data compliance, but also to guide subsequent business logic processing.

[0158] In step S701 of some embodiments, the embodiments of the present application first respond to the verification result information. If the verification result indicates that the financial business data has passed all relevant target verification rules, the embodiments of the present application can determine the first response logic information configured in the target verification rules as the target logic response information. The first response logic information is previously defined in the rule configuration stage and is used to guide how the embodiments of the present application should respond when the data verification is successful. At this time, the target logic response information may include operations such as storing the data in a database, triggering subsequent business processes, updating the user interface, and sending confirmation information.

[0159] In step S702 of some embodiments, the embodiments of the present application perform a verification response operation based on the determined target logic response information. This step converts the first response logic information into an actual business action to ensure that the data can flow smoothly into the subsequent processing flow. For example, if the verification rule is for resource flow data, then after the verification is passed, the embodiments of the present application may perform operations such as resource flow data confirmation, fund transfer, and recording resource flow data logs. These operations are an indispensable part of the financial business process, and they ensure the validity and integrity of resource flow data.

[0160] Furthermore, executing the verification response operation also helps improve the automation and efficiency of the embodiments of the present application. Through automated response logic, the embodiments of the present application can reduce manual intervention, lower error rates, and speed up processing. This is particularly important for financial services, as fast and accurate processing capabilities are key to improving user experience and maintaining competitiveness in the financial market.

[0161] Reference Figure 8 According to some embodiments of the present application, after performing data verification on the financial business data based on the target verification rule and obtaining verification result information in step S104, the following steps may also be included, but are not limited to:

[0162] Step S801: In response to the verification result information indicating that the financial business data fails verification, second response logic information of the target verification rule is determined as target logic response information;

[0163] Step S802: Perform a verification response operation according to the target logic response information.

[0164] In some embodiments of the present application, after step S104 completes verification of the financial service data based on the target verification rule and obtains verification result information, the embodiments of the present application may determine subsequent actions based on the verification result information. If the verification result information indicates that the financial service data has failed verification, the embodiments of the present application will take specific response measures to handle this situation.

[0165] In step S801 of some embodiments, embodiments of the present application first respond to verification result information. When the financial business data fails verification, embodiments of the present application may determine the second response logic information configured in the target verification rule as the target logic response information. The second response logic information is pre-defined during the rule configuration phase and is used to guide the embodiment of the present application on how to respond when data verification fails. In this case, the target logic response information may include recording error details, generating an error report, sending a notification to the user or administrator, executing a specific error handling process, etc.

[0166] In step S802 of some embodiments, embodiments of the present application perform a verification response operation based on the determined target logic response information. This step converts the second response logic information into an actual business action to properly handle the situation where the verification fails. For example, embodiments of the present application may prevent further execution of resource transfers, prompt users to correct data, trigger risk management processes, or perform other necessary error handling measures. These operations help ensure the accuracy and compliance of data while maintaining the stability and security of financial services.

[0167] The embodiment of the present application, illustrated through steps S801 to S802, constitutes a complete post-verification failure response process, which ensures that financial business data is properly handled when it fails verification. This process not only improves the accuracy and security of data processing, but also provides a solid foundation for the smooth operation and risk management of financial services.

[0168] Reference Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is shown. The electronic device includes:

[0169] The processor 901 may be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is configured to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0170] The memory 902 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called by the processor 901 to execute the data verification method for financial services in the embodiments of this application.

[0171] Input / output interface 903, used to implement information input and output;

[0172] Communication interface 904, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.);

[0173] Bus 905 , which transmits information between various components of the device (e.g., processor 901 , memory 902 , input / output interface 903 , and communication interface 904 );

[0174] The processor 901 , the memory 902 , the input / output interface 903 and the communication interface 904 are connected to each other in communication within the device via a bus 905 .

[0175] The present application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, so that the computer device implements the above-mentioned data verification method for financial services.

[0176] The terms "first," "second," "third," "fourth," and the like (if any) in the specification of the present disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein, for example, can be implemented in orders other than those illustrated or described herein. In addition, the terms "comprises" and "comprising," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising 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 process, method, product, or apparatus.

[0177] It should be understood that in the present disclosure, "at least one (item)" refers to one or more, and "plurality" refers to two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can represent: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, and may include, but is not limited to, any combination of single or plural items in the following steps. For example, at least one of a, b or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0178] It should be understood that in the description of the embodiments of the present application, multiple (or multiple items) means more than two, greater than, less than, exceed, etc. are understood to exclude the number itself, and above, below, within, etc. are understood to include the number itself.

[0179] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0180] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0181] In addition, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0182] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the relevant technology or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and may include, but is not limited to, the following steps and several instructions for enabling a computer device (which can be a personal computer, a financial service service terminal, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-On l yMemory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), magnetic disk or optical disk and other media that can store program code.

[0183] It should also be understood that the various implementation methods provided in the embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0184] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A data verification method for financial services, characterized in that: Applied to financial business service end, including: Identify multiple alternative interface types; For each of the candidate interface types, at least one corresponding preparation scenario information is configured; wherein the mapping relationship type between the candidate interface type and the preparation scenario information is a first type mapping relationship; For each type of the preliminary scenario information, configure the corresponding verification rule identification field, applicable scenario description field, rule service type field and verification conclusion field; Integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain an alternative verification rule corresponding to the preliminary scenario information; wherein the mapping relationship type between the preliminary scenario information and the alternative verification rule is a second-type mapping relationship; Based on the first type of mapping relationship, each candidate interface type and the preliminary scenario information corresponding to the candidate interface type are integrated to obtain an interface scenario mapping table; wherein one candidate interface type corresponds to one interface scenario mapping table; Based on the second type of mapping relationship, each of the preliminary scene information and the candidate verification rules corresponding to the preliminary scene information are integrated to obtain a verification rule table; wherein each type of preliminary scene information corresponds to one verification rule table; Based on the preliminary scenario information, the interface scenario mapping table and the verification rule table are stored in a verification database to preset the verification database; Obtain front-end data requests and financial business data; Performing interface analysis on the front-end data request to determine the interface request identifier; Based on the interface request identifier, query the preset verification database to obtain target interface information and a target verification rule matching the target interface information; The financial business data is verified based on the target verification rule to obtain verification result information.

2. The method according to claim 1, characterized in that The performing data verification on the financial business data based on the target verification rule to obtain verification result information includes: Invoking a target rule service class that matches the financial business data according to the rule service class field of the target verification rule; The financial business data is verified through the target rule service class to obtain verification result information.

3. The method according to claim 1, characterized in that Before integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the candidate verification rule corresponding to the preliminary scenario information, the method further includes: For the preliminary scenario information, configure first response logic information corresponding to verification passing; The step of integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the candidate verification rule corresponding to the preliminary scenario information includes: The first response logic information, the verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field are integrated to obtain the alternative verification rule.

4. The method according to claim 3, characterized in that After performing data verification on the financial business data based on the target verification rule to obtain verification result information, the method further includes: In response to the verification result information reflecting that the financial business data passes verification, determining the first response logic information of the target verification rule as target logic response information; A verification response operation is performed according to the target logical response information.

5. The method according to claim 1, characterized in that Before integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the candidate verification rule corresponding to the preliminary scenario information, the method further includes: For the preparation scenario information, configure second response logic information corresponding to verification failure; The step of integrating the verification rule identification field, the applicable scenario description field, the rule service class field, and the verification conclusion field to obtain the candidate verification rule corresponding to the preliminary scenario information includes: The second response logic information, the verification rule identification field, the applicable scenario description field, the rule service class field and the verification conclusion field are integrated to obtain the alternative verification rule.

6. The method according to claim 5, characterized in that After performing data verification on the financial business data based on the target verification rule to obtain verification result information, the method further includes: In response to the verification result information reflecting that the financial business data fails verification, determining the second response logic information of the target verification rule as target logic response information; A verification response operation is performed according to the target logical response information.

7. An electronic device, characterized in that: include: A memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the data verification method for financial services according to any one of claims 1 to 6 is implemented.

8. A computer-readable storage medium, characterized in that The storage medium stores a program, and the program is executed by a processor to implement the data verification method for financial services according to any one of claims 1 to 6.

Images