Data checking method, device and electronic equipment

Abstract

The application discloses a data checking method and device and electronic equipment, and relates to the technical field of big data. The method comprises the following steps: obtaining to-be-checked data, wherein the to-be-checked data at least comprises metadata, business data and risk data; determining a checking rule corresponding to each data type according to the data types of the data contained in the to-be-checked data; and checking the data of the corresponding data type based on the checking rule to obtain a data checking result. The application solves the technical problem of low checking efficiency caused by the non-uniform checking rules corresponding to different interfaces in the prior art.

Description

Technical Field

[0001] This invention relates to the field of big data technology, and more specifically, to a data verification method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of the internet, big data is widely used across various industries, with hundreds of millions of data points interacting daily. In this data interaction, the primary task is data validation. Currently, data validation requires writing custom standards for different interfaces, and each field's validation rules must be written individually. This leads to a waste of time and manpower due to repetitive work. Furthermore, there is no unified validation standard for fields with the same meaning; different interfaces use different standards, resulting in inconsistent validation rules, leading to confusion and low validation efficiency.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a data verification method, apparatus, and electronic device to at least solve the technical problem of low verification efficiency caused by inconsistent verification rules for different interfaces in the prior art.

[0005] According to one aspect of the present invention, a data verification method is provided, comprising: acquiring data to be verified, wherein the data to be verified includes at least metadata, business data, and risk data; determining verification rules corresponding to each data type according to the data type contained in the data to be verified; and verifying the data of the corresponding data type based on the verification rules to obtain a data verification result.

[0006] Furthermore, the data verification method also includes: performing integrity verification on metadata based on metadata verification rules to obtain a first verification result; if the metadata passes the integrity verification, determining whether the business data meets the business verification rules to obtain a judgment result; if the business data meets the business verification rules, performing risk verification on risky data based on risk verification rules to obtain a data verification result.

[0007] Furthermore, the data verification method also includes: obtaining a target scenario identifier corresponding to the risk data; determining multiple verification rule identifiers corresponding to the risk data based on the target scenario identifier; determining a program identifier corresponding to each verification rule identifier, wherein the program identifier is used to identify the verification program script corresponding to the risk data; executing multiple verification program scripts to obtain multiple execution results, wherein the execution results characterize the execution status of the verification program scripts; and determining the data verification result based on the multiple execution results.

[0008] Furthermore, the data verification method also includes: determining that risky data passes risk verification when multiple execution results are all passed.

[0009] Furthermore, the data verification method also includes: receiving a request message for verifying metadata and a target interface name, wherein the target interface name is the name of the interface that issued the request message; obtaining the field name of the metadata verification field corresponding to the target interface name from the metadata configuration table, wherein the metadata configuration table is used to store the data information of the metadata to be verified by the target interface; obtaining the verification rule corresponding to the field name from the metadata definition table to obtain the metadata verification rule, wherein the metadata definition table is used to store the data information of the metadata; parsing the request message to obtain the field content of the metadata; and verifying the field content based on the metadata verification rule to obtain the first verification result.

[0010] Furthermore, the data verification method also includes: generating first information when the metadata passes the integrity verification, wherein the first information indicates that the metadata has passed the integrity verification; and generating second information when the metadata fails the integrity verification, wherein the second information indicates that the metadata has failed the integrity verification, and the second information includes at least information about the data in the metadata that failed the integrity verification.

[0011] Furthermore, the data verification method also includes: creating a metadata configuration table and configuring the data information of the metadata to be verified by the target interface; creating a metadata definition table and defining the data format of the metadata.

[0012] Furthermore, the data verification method also includes: acquiring multiple risk scenarios and identifying each risk scenario to obtain multiple scenario identifiers; identifying multiple verification rules under multiple risk scenarios to obtain multiple verification rule identifiers; and identifying the verification program script corresponding to each verification rule to obtain program identifiers.

[0013] According to another aspect of the present invention, a data verification device is also provided, comprising: an acquisition module for acquiring data to be verified, wherein the data to be verified includes at least metadata, business data, and risk data; a determination module for determining verification rules corresponding to each data type based on the data type contained in the data to be verified; and a verification module for verifying the data of the corresponding data type based on the verification rules to obtain a data verification result.

[0014] According to another aspect of the present invention, an electronic device is also provided, the electronic device including one or more processors; a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are configured to run the programs, wherein the programs are configured to execute the above-described data verification method during runtime.

[0015] In this embodiment of the invention, a method of determining data verification rules based on data type is adopted. First, the data to be verified is obtained. Then, verification rules corresponding to each data type are determined according to the data types contained in the data to be verified. Finally, the data of the corresponding data type is verified based on the verification rules to obtain the data verification result. The data to be verified includes at least metadata, business data, and risk data.

[0016] In the above process, acquiring the data to be verified provides an accurate data foundation for subsequently determining data verification rules. Based on the data types contained in the data to be verified, verification rules corresponding to each data type can be determined. This enables the application of the same verification rules to data of the same type from different interfaces, thus avoiding the problem of low verification efficiency caused by inconsistent verification rules for different interfaces in existing technologies. Verifying the data of the corresponding data type based on the verification rules yields the data verification results. This process of verifying data of different data types contained in the data to be verified is realized. By unifying the data verification rules, time and manpower costs are saved, thereby improving verification efficiency.

[0017] Therefore, the technical solution of the present invention achieves the goal of unifying the verification rules corresponding to different interfaces, thereby improving the technical effect of verification efficiency and solving the technical problem of low verification efficiency caused by the inconsistency of verification rules corresponding to different interfaces in the prior art. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0019] Figure 1 This is a flowchart of an optional data verification method according to an embodiment of the present invention;

[0020] Figure 2 This is a flowchart of an optional transaction data verification method according to an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of an optional metadata verification according to an embodiment of the present invention;

[0022] Figure 4 This is a flowchart of an optional business data verification method according to an embodiment of the present invention;

[0023] Figure 5 This is a flowchart of an optional risk data verification method according to an embodiment of the present invention;

[0024] Figure 6 This is a schematic diagram of an optional data verification device according to an embodiment of the present invention;

[0025] Figure 7 This is a schematic diagram of an optional electronic device according to an embodiment of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

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

[0028] It should be noted that all relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this invention are information and data authorized by the user or fully authorized by all parties. For example, this system has an interface with the relevant user or organization. Before obtaining relevant information, it needs to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving consent from the aforementioned user or organization.

[0029] Example 1

[0030] According to an embodiment of the present invention, a method embodiment for data verification is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] Figure 1 This is a flowchart of an optional data verification method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0032] Step S101: Obtain the data to be verified, which includes at least metadata, business data, and risk data.

[0033] In the above steps, the data to be verified can be obtained through application systems, processors, electronic devices, and other devices. Optionally, this invention provides a general data standard verification model. In this invention, transaction data in the credit field is used as an example for detailed explanation. The model's applicability is not limited to the credit field; it can also be applied to data verification processes in other industries to achieve interface verification at various levels.

[0034] Optionally, the elements that need to be verified for a single transaction in the credit field can be divided into metadata verification, business layer verification, and risk control layer verification. Before performing data verification, it is necessary to first define the data types, that is, define what kind of data belongs to metadata, what kind of data belongs to business data, and what kind of data belongs to risk data.

[0035] Optionally, metadata standards can be defined first. For example, common fields with shared characteristics (such as amount and account number) can be defined as metadata, while fields related to technical implementation can be excluded. Specifically, as shown in Table 1, metadata standards can be defined based on the characteristics of the credit field, and then basic validations, such as format validation, can be performed on the transaction data.

[0036] Table 1 Examples of Metadata Standards in the Credit Sector

[0037]

[0038] Optionally, business data can include payment date, customer name, account holder name, etc., while risk data can include customer status, customer risk indicators, etc.

[0039] It should be noted that in the above process, obtaining the data to be verified provides an accurate data foundation for subsequently determining the data verification rules.

[0040] Step S102: Determine the verification rules corresponding to each data type based on the data type contained in the data to be verified.

[0041] In the above steps, the verification rules can be divided into metadata verification rules, business verification rules, and risk verification rules. Optionally, based on the data type contained in the data to be verified, the verification rules corresponding to each data type can be determined. It should be noted that, unlike the prior art which determines verification rules based on interfaces, this invention determines verification rules based on data types. Therefore, for data of the same type from different interfaces, the same verification rules can be used, thereby avoiding the problem of low verification efficiency caused by inconsistent verification rules corresponding to different interfaces.

[0042] Step S103: Validate the data of the corresponding data type based on the validation rules to obtain the data validation result.

[0043] In the above steps, data verification is performed using corresponding verification rules, realizing the verification process of different data types contained in the data to be verified. By unifying data verification rules, time and manpower costs are saved, thereby improving verification efficiency.

[0044] Based on the scheme defined in steps S101 to S103 above, it can be understood that in this embodiment of the invention, the method of determining data verification rules according to data type is adopted. First, the data to be verified is obtained. Then, the verification rules corresponding to each data type are determined according to the data type contained in the data to be verified. Finally, the data of the corresponding data type is verified based on the verification rules to obtain the data verification result. Among them, the data to be verified includes at least metadata, business data, and risk data.

[0045] It is noteworthy that, in the above process, acquiring the data to be verified provides an accurate data foundation for subsequently determining the data verification rules. Based on the data types contained in the data to be verified, verification rules corresponding to each data type can be determined. This enables the application of the same verification rules to data of the same type from different interfaces, thus avoiding the low verification efficiency problem caused by inconsistent verification rules across different interfaces in existing technologies. Verifying the data of the corresponding data type based on the verification rules yields the data verification results, realizing the verification process for data of different data types contained in the data to be verified. By unifying the data verification rules, time and manpower costs are saved, thereby improving verification efficiency.

[0046] Therefore, the technical solution of the present invention achieves the goal of unifying the verification rules corresponding to different interfaces, thereby improving the technical effect of verification efficiency and solving the technical problem of low verification efficiency caused by the inconsistency of verification rules corresponding to different interfaces in the prior art.

[0047] In one optional embodiment, in the process of verifying data of the corresponding data type based on the verification rules and obtaining the data verification result, firstly, the metadata is verified for integrity based on the metadata verification rules to obtain the first verification result. Then, if the metadata passes the integrity verification, it is determined whether the business data meets the business verification rules to obtain the judgment result. If the business data meets the business verification rules, risk verification is performed on the risk data based on the risk verification rules to obtain the data verification result.

[0048] Optional, Figure 2 This is a flowchart of an optional transaction data verification method according to an embodiment of the present invention. Figure 4 This is a flowchart of an optional business data verification method according to an embodiment of the present invention, such as... Figure 2 As shown, after a transaction occurs, metadata verification is performed first, followed by business layer verification, and then risk control layer verification, resulting in a data verification result. Optionally, such as... Figure 4 As shown, business layer validation can be performed by writing a validation interface class (class name IBusinessCheckInterface) and a validation implementation class. The validation interface class defines methods and provides the methods to be implemented, while the validation implementation class implements the specific domain-specific validation methods. For example, in the credit field, common business layer validation implementations include: payment date validation, financing customer name validation, and off-bank account name validation.

[0049] Optionally, payment date verification compares the payment date in the transaction with the current date. The payment date cannot be earlier than the current date. Specifically, this is achieved by writing an implementation class (class name BusinessCheckDate) and implementing the verification of the payment date and the current date in the doCheck method. Optionally, a boolean data type parameter can be used in the method. For example, return true when the payment date is greater than or equal to the current date. Optionally, financing customer name verification checks the consistency between the financing customer name and the name in the business registration information. Specifically, this is achieved by writing an implementation class (class name BusinessCheckConsumer) and implementing the financing customer name verification in the doCheck method. For example, return true when the financing customer name equals the customer name set in the system. Optionally, off-bank account name verification verifies the customer's off-bank account name when the loan is disbursed. That is, it verifies whether the off-bank account name in the submitted message matches the name in the system. Specifically, by writing an implementation class (class name BusinessCheckAccount) and implementing the validation of the off-line account name in the doCheck method, for example, if the off-line account name is equal to the off-line account name set in the system, return true.

[0050] In some other alternative embodiments, the data standard verification model in this invention can provide an interface, the specific details of which can be implemented according to various scenarios. Figure 3 This is a schematic diagram of an optional metadata verification according to an embodiment of the present invention, such as... Figure 3 As shown, the caller can invoke the metadata verification interface to implement metadata verification for specific interfaces.

[0051] It should be noted that, combining the aforementioned three-layer verification, this invention establishes a universal data standard verification model. After application implementation, it can utilize metadata verification or implement unique metadata standard verification. Furthermore, application-specific controls can be implemented at the business layer and risk control layer.

[0052] In one optional embodiment, before obtaining the target scenario identifier corresponding to the risk data, multiple risk scenarios are obtained and each risk scenario is identified to obtain multiple scenario identifiers. Then, multiple verification rules under the multiple risk scenarios are identified to obtain multiple verification rule identifiers. Finally, the verification program script corresponding to each verification rule is identified to obtain a program identifier.

[0053] Optionally, before performing data verification, it is necessary to first define the scenarios that need to be verified at the risk control layer, i.e., risk scenarios, and assign scenario IDs, i.e. scenario identifiers, according to the scenarios, as shown in Table 2.

[0054] Table 2 Scene ID Allocation Table

[0055] Scene ID Scene Name Product Categories Processing stage 24 Digital credit credential financing application pre-verification Digital Credit Certificate EC-01 Pre-verification of Financing Applications

[0056] Furthermore, risk control rules are defined, that is, rules for a specific scenario are defined. The same scenario can contain multiple rules, as shown in Table 3. Further, risk control elements under a specific rule are defined, that is, the specific verification program scripts, as shown in Table 4.

[0057] Table 3 Risk Control Rule ID Allocation Table

[0058]

[0059] Table 4 Risk Control Element ID Allocation Table

[0060]

[0061] In one optional embodiment, during the process of performing risk verification on risk data based on risk verification rules to obtain data verification results, the process first involves obtaining a target scenario identifier corresponding to the risk data. Then, based on the target scenario identifier, multiple verification rule identifiers corresponding to the risk data are determined. Next, a program identifier corresponding to each verification rule identifier is determined. Then, multiple verification program scripts are executed, resulting in multiple execution results. Finally, the data verification result is determined based on these multiple execution results. The program identifier identifies the verification program script corresponding to the risk data, and the execution result characterizes the execution status of the verification program script.

[0062] In one optional embodiment, if multiple execution results are all passed, the risk data is determined to have passed the risk verification.

[0063] Optional, Figure 5 This is a flowchart of an optional risk data verification method according to an embodiment of the present invention, such as... Figure 5 As shown, when making a business call, the caller passes in the scenario ID, i.e., the target scenario identifier, that needs to be verified at the risk control layer entry point. For example, when the scenario name is "Digital Credit Certificate Financing Application Pre-verification," the passed scenario ID is 24.

[0064] Furthermore, the risk control layer queries the risk control rules based on the scenario ID to obtain the rule ID, which is the verification rule identifier. For example, if the scenario name is "Digital Credit Certificate Financing Application Pre-verification," and the scenario ID value is 24, the risk control rule ID allocation table in Table 3 is consulted to obtain the rule IDs: 80, 84, 87, and 92.

[0065] Furthermore, based on the risk control rules, the risk control element, i.e., the program identifier, is obtained. For example, if the scenario name is "Digital Credit Certificate Financing Application Pre-verification" and the risk control rule ID is 80, querying Table 4 (Risk Control Element ID Allocation Table) will yield the corresponding risk control element ID as cust_010.

[0066] Furthermore, based on the risk control element ID, the corresponding "full name of data retrieval class" is obtained, and the corresponding "full name of data retrieval class" is executed. For example, if the scenario name is pre-verification of digital credit credential financing application, Table 4 shows that the "full name of data retrieval class" for risk control element ID cust_010 is "com.service.biz.QryStateBiz". Then, JAVA reflection is used to execute this class.

[0067] Furthermore, the execution result of "Retrieve Full Name of Data Category" is obtained, and the macro of the risk control rules in Table 3 is used to determine whether the risk control rule passes. For example, if the scenario name is "Digital Credit Certificate Financing Application Pre-verification", the risk control rule ID is 80, and the risk control element ID is cust_010, and the return result is "1-Watchlist" or "0-Banned", then the verification of the entire risk control rule ID 80 returns "0-Control Failed"; otherwise, it returns "1-Control Passed".

[0068] Furthermore, by combining the execution results of all risk control rules in a specific scenario (i.e., multiple execution results), the final execution result for that scenario is returned. For example, in the scenario name "Digital Credit Certificate Financing Application Pre-verification," if the execution results of risk control rules IDs 80, 84, 87, and 92 are all passed, the "Digital Credit Certificate Financing Application Pre-verification" returns "Verification Passed."

[0069] In one optional embodiment, before obtaining the data to be verified, a metadata configuration table is created and the data information of the metadata to be verified by the target interface is configured. A metadata definition table is also created and the data format of the metadata is defined.

[0070] Optionally, the metadata definition table is shown in Table 5, and the metadata configuration table is shown in Table 6.

[0071] Table 5 Metadata Definition Table

[0072]

[0073] Table 6 Interface Metadata Configuration Table

[0074] Interface Chinese Name Interface English name Metadata English name Verify Financing application interface loanApplyInterface Host area code yes Financing application interface loanApplyInterface Host Network Address yes Financing application interface loanApplyInterface Organization Number yes

[0075] In one optional embodiment, during the process of performing integrity verification on metadata based on metadata verification rules to obtain a first verification result, the process first involves receiving a request message for metadata verification and the target interface name. Then, the field name of the metadata verification field corresponding to the target interface name is obtained from the metadata configuration table. Next, the verification rule corresponding to the field name is obtained from the metadata definition table to obtain the metadata verification rules. Finally, the request message is parsed to obtain the field content of the metadata. Based on the metadata verification rules, the field content is then verified to obtain the first verification result. Here, the target interface name is the name of the interface that issued the request message, the metadata configuration table stores the data information of the metadata to be verified by the target interface, and the metadata definition table stores the data information of the metadata.

[0076] In one optional embodiment, during the process of validating the field content based on metadata validation rules to obtain a first validation result, if the metadata passes the integrity validation, first information is generated; if the metadata fails the integrity validation, second information is generated. The second information indicates that the metadata has failed the integrity validation, and the second information includes at least information about the data in the metadata that failed the integrity validation. The first information indicates that the metadata has passed the integrity validation.

[0077] Optionally, in this embodiment, metadata verification provides a verification interface that can be called by interfaces in various scenarios. Optionally, metadata verification is implemented by writing an interface class (class name: loanConmonCheck). Optionally, when performing metadata verification, the interface name (target interface name) and the application verification message (request message) are passed to the interface. Then, based on the passed English name of the interface, the metadata configuration table and metadata definition table are queried. For example, the English name of the interface is "loanApplyInterface", and the application message is:

[0078] {

[0079] "areaCode":"00101",

[0080] "netCode": "00001",

[0081] "branch": "0010100001"

[0082] }

[0083] Specifically, by querying Table 6 (interface metadata configuration table), we can obtain the three fields that need to be validated corresponding to the English name of the input interface (loanApplyInterface): areaCode, netCode, and branch.

[0084] Furthermore, based on the English field name, the required length for this field to be validated is obtained from Table 5 (Metadata Definition Table), which are 5, 5, and 10 respectively. Further, the value of this English field name in the application message, i.e., the field content, is obtained and validated according to the rules. If the validation passes, the result (first information) is returned as 0; if the validation fails, the result is returned as 1, and the specific information indicating the validation failure (second information) is also returned. For example, if the content of the host area code (areaCode) field in the application message is "00101" with a length of 5, which matches the length in the metadata definition table, the result returned is 0.

[0085] Therefore, the technical solution of the present invention achieves the goal of unifying the verification rules corresponding to different interfaces, thereby improving the technical effect of verification efficiency and solving the technical problem of low verification efficiency caused by the inconsistency of verification rules corresponding to different interfaces in the prior art.

[0086] Example 2

[0087] According to an embodiment of the present invention, a data verification device is provided, wherein, Figure 6 This is a schematic diagram of an optional data verification device according to an embodiment of the present invention, such as... Figure 6 As shown, the device includes: an acquisition module 601 for acquiring data to be verified, wherein the data to be verified includes at least metadata, business data, and risk data; a determination module 602 for determining the verification rules corresponding to each data type based on the data type contained in the data to be verified; and a verification module 603 for verifying the data of the corresponding data type based on the verification rules to obtain the data verification result.

[0088] It should be noted that the above-mentioned acquisition module 601, determination module 602 and verification module 603 correspond to steps S101 to S103 in the above embodiments. The three modules and the corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed in the above embodiment 1.

[0089] Optionally, the verification module includes: a first verification module, used to perform integrity verification on metadata based on metadata verification rules to obtain a first verification result; a judgment module, used to determine whether business data meets business verification rules if the metadata passes integrity verification, and obtain a judgment result; and a second verification module, used to perform risk verification on risky data based on risk verification rules if the business data meets business verification rules, and obtain a data verification result.

[0090] Optionally, the data verification device further includes: a first acquisition module for acquiring a target scenario identifier corresponding to the risk data; a first determination module for determining multiple verification rule identifiers corresponding to the risk data based on the target scenario identifier; a second determination module for determining a program identifier corresponding to each verification rule identifier, wherein the program identifier is used to identify a verification program script corresponding to the risk data; an execution module for executing multiple verification program scripts to obtain multiple execution results, wherein the execution results characterize the execution status of the verification program scripts; and a third determination module for determining a data verification result based on the multiple execution results.

[0091] Optionally, the third determining module includes: a fourth determining module, used to determine that the risk data passes the risk verification when multiple execution results are all passed.

[0092] Optionally, the first verification module includes: a receiving module, used to receive a request message for verifying metadata and a target interface name, wherein the target interface name is the name of the interface that issued the request message; a first obtaining module, used to obtain the field name of the metadata verification field corresponding to the target interface name from the metadata configuration table, wherein the metadata configuration table is used to store the data information of the metadata to be verified by the target interface; a second obtaining module, used to obtain the verification rule corresponding to the field name from the metadata definition table to obtain the metadata verification rule, wherein the metadata definition table is used to store the data information of the metadata; a parsing module, used to parse the request message to obtain the field content of the metadata; and a field verification module, used to verify the field content based on the metadata verification rule to obtain a first verification result.

[0093] Optionally, the field validation module includes: a first generation module, used to generate first information when the metadata passes the integrity validation, wherein the first information indicates that the metadata passes the integrity validation; and a second generation module, used to generate second information when the metadata fails the integrity validation, wherein the second information indicates that the metadata fails the integrity validation, and the second information includes at least information about the data in the metadata that failed the integrity validation.

[0094] Optionally, the data verification device further includes: a first creation module for creating a metadata configuration table and configuring the data information of the metadata to be verified by the target interface; and a second creation module for creating a metadata definition table and defining the data format of the metadata.

[0095] Optionally, the data verification device further includes: a first identification module, used to acquire multiple risk scenarios and identify each risk scenario to obtain multiple scenario identifications; a second identification module, used to identify multiple verification rules under multiple risk scenarios to obtain multiple verification rule identifications; and a third identification module, used to identify the verification program script corresponding to each verification rule to obtain a program identification.

[0096] Example 3

[0097] According to another aspect of the present invention, an electronic device is also provided, wherein, Figure 7 This is a schematic diagram of an optional electronic device according to an embodiment of the present invention, such as... Figure 7 As shown, the electronic device includes one or more processors; and a memory for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors are configured to run the programs, wherein the programs are set to execute the aforementioned data verification method during runtime. When the processor executes the program, it performs the following steps: acquiring data to be verified, wherein the data to be verified includes at least metadata, business data, and risk data; determining verification rules corresponding to each data type based on the data type contained in the data to be verified; and verifying the data of the corresponding data type based on the verification rules to obtain the data verification result.

[0098] Optionally, the processor may also perform the following steps when executing the program: perform integrity verification on the metadata based on the metadata verification rules to obtain a first verification result; if the metadata passes the integrity verification, determine whether the business data meets the business verification rules to obtain a judgment result; if the business data meets the business verification rules, perform risk verification on the risk data based on the risk verification rules to obtain a data verification result.

[0099] Optionally, the processor also performs the following steps when executing the program: obtaining a target scenario identifier corresponding to the risk data; determining multiple verification rule identifiers corresponding to the risk data based on the target scenario identifier; determining a program identifier corresponding to each verification rule identifier, wherein the program identifier is used to identify the verification program script corresponding to the risk data; executing multiple verification program scripts to obtain multiple execution results, wherein the execution results characterize the execution status of the verification program scripts; and determining the data verification result based on the multiple execution results.

[0100] Optionally, the processor may also perform the following steps when executing the program: if multiple execution results are all passed, determine that the risky data passes the risk verification.

[0101] Optionally, the processor, when executing the program, also implements the following steps: receiving a request message for verifying metadata and the target interface name, wherein the target interface name is the name of the interface that issued the request message; obtaining the field name of the metadata verification field corresponding to the target interface name from the metadata configuration table, wherein the metadata configuration table is used to store the data information of the metadata to be verified by the target interface; obtaining the verification rule corresponding to the field name from the metadata definition table to obtain the metadata verification rule, wherein the metadata definition table is used to store the data information of the metadata; parsing the request message to obtain the field content of the metadata; and verifying the field content based on the metadata verification rule to obtain the first verification result.

[0102] Optionally, when the processor executes the program, it further implements the following steps: if the metadata passes the integrity check, it generates first information, wherein the first information indicates that the metadata passes the integrity check; if the metadata fails the integrity check, it generates second information, wherein the second information indicates that the metadata fails the integrity check, and the second information includes at least information about the data in the metadata that failed the integrity check.

[0103] Optionally, the processor may also perform the following steps when executing the program: create a metadata configuration table and configure the data information of the metadata to be verified by the target interface; create a metadata definition table and define the data format of the metadata.

[0104] Optionally, the processor may also perform the following steps when executing the program: acquire multiple risk scenarios and identify each risk scenario to obtain multiple scenario identifiers; identify multiple verification rules under multiple risk scenarios to obtain multiple verification rule identifiers; and identify the verification program script corresponding to each verification rule to obtain a program identifier.

[0105] The devices mentioned in this article can be servers, PCs, tablets, mobile phones, etc.

[0106] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0107] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

[0110] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0111] If the integrated unit is implemented as 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, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0112] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A data verification method, characterized in that, include: Obtain the data to be verified, wherein the data to be verified includes at least metadata, business data, and risk data; The verification rules for each data type are determined based on the data type contained in the data to be verified, wherein the same verification rules are used for data of the same data type from different interfaces. The data of the corresponding data type is validated based on the validation rules to obtain a data validation result. Specifically, the metadata is validated for integrity based on the metadata validation rules to obtain a first validation result. If the metadata passes the integrity validation, it is determined whether the business data meets the business validation rules to obtain a determination result. If the business data meets the business validation rules, the risk data is validated for risk based on the risk validation rules to obtain the data validation result.

2. The method according to claim 1, characterized in that, The risk data is validated based on risk validation rules to obtain the data validation results, including: Obtain the target scene identifier corresponding to the risk data; Based on the target scenario identifier, determine multiple verification rule identifiers corresponding to the risk data; Determine a program identifier corresponding to each of the verification rule identifiers, wherein the program identifier is used to identify the verification program script corresponding to the risk data; Execute multiple verification program scripts to obtain multiple execution results, wherein the execution results characterize the execution status of the verification program scripts; The data verification result is determined based on the multiple execution results.

3. The method according to claim 2, characterized in that, The data verification result is determined based on the multiple execution results, including: If all the execution results are passed, the risk data is determined to have passed the risk verification.

4. The method according to claim 1, characterized in that, The metadata is subjected to integrity verification based on the metadata verification rules to obtain a first verification result, including: Receive a request message for verifying the metadata and a target interface name, wherein the target interface name is the name of the interface that sent the request message; Obtain the field name of the metadata verification field corresponding to the target interface name from the metadata configuration table, wherein the metadata configuration table is used to store the data information of the metadata to be verified by the target interface; Obtain the validation rules corresponding to the field names from the metadata definition table to obtain the metadata validation rules, wherein the metadata definition table is used to store the data information of the metadata; Parse the request message to obtain the field content of the metadata; Based on the metadata verification rules, the content of the field is verified to obtain the first verification result.

5. The method according to claim 4, characterized in that, Based on the metadata verification rules, the field content is verified to obtain the first verification result, including: If the metadata passes the integrity check, first information is generated, wherein the first information indicates that the metadata has passed the integrity check; If the metadata fails the integrity check, second information is generated, wherein the second information indicates that the metadata failed the integrity check, and the second information includes at least information about the data in the metadata that failed the integrity check.

6. The method according to claim 4, characterized in that, Before obtaining the data to be verified, the method further includes: Create the metadata configuration table and configure the data information of the metadata to be verified by the target interface; Create the metadata definition table and define the data format of the metadata.

7. The method according to claim 2, characterized in that, Before obtaining the target scene identifier corresponding to the risk data, the method further includes: Multiple risk scenarios are obtained, and each risk scenario is identified to obtain multiple scenario identifiers; Multiple verification rules under the multiple risk scenarios are identified to obtain the multiple verification rule identifiers; The verification program script corresponding to each verification rule is identified to obtain the program identifier.

8. A data verification device, characterized in that, include: The acquisition module is used to acquire the data to be verified, wherein the data to be verified includes at least metadata, business data, and risk data; The determination module is used to determine the verification rule corresponding to each data type based on the data type contained in the data to be verified, wherein data of the same data type from different interfaces adopt the same verification rule. The verification module is used to verify data of the corresponding data type based on the verification rules to obtain a data verification result. Specifically, it performs integrity verification on the metadata based on the metadata verification rules to obtain a first verification result; if the metadata passes the integrity verification, it determines whether the business data meets the business verification rules to obtain a judgment result; if the business data meets the business verification rules, it performs risk verification on the risk data based on the risk verification rules to obtain the data verification result.

9. An electronic device, characterized in that, The electronic device includes one or more processors; A memory for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to be configured to run the programs, wherein the programs are configured to execute the data verification method as described in any one of claims 1 to 7 at runtime.

Images