Transaction data verification method, device, equipment, medium and product

Abstract

The invention discloses a transaction data verification method, device and equipment, a medium and a product, and the method comprises the steps: obtaining a transaction data set on that day; wherein the intraday transaction data set comprises at least one piece of transaction data; for each transaction data, verifying the current transaction data based on at least one verification mode to obtain a verification result of the current transaction data in each verification mode; if all the verification results are verification passing, marking the current transaction data as verification passing; and generating a to-be-sent message based on all the transaction data marked as passing the verification, and sending the to-be-sent message. The problems that in the prior art, the verification scene of a target department cannot be covered only through content verification and format verification, and after transaction data passing verification is submitted to the target department, receipt information of abnormal data of the target department still exists, so that submission fails are solved; the effect of improving the transaction data submission success probability is achieved.

Description

Technical Field

[0001] This invention relates to the field of data verification technology, and in particular to a method, apparatus, equipment, medium and product for verifying transaction data. Background Technology

[0002] To adapt to market development needs, industry regulators require financial institutions to submit daily transaction data in a specified format in order to continuously improve the financial transaction management mechanism.

[0003] Current financial regulations require institutions to submit formatted transaction data daily. Upon receiving the data, regulators perform checks on its completeness, format, and business logic. If the logic check fails, the data is returned for correction, resulting in a low overall pass rate.

[0004] To address the aforementioned issues, the method for verifying transaction data needs to be improved. Summary of the Invention

[0005] This invention provides a transaction data verification method, apparatus, device, medium, and product to solve the problem that existing technologies cannot cover the verification scenarios of the target department by only verifying content and format, and that after submitting the verified transaction data to the target department, there is still a problem that the target department will receive a receipt message for abnormal data, resulting in the submission failure.

[0006] In a first aspect, embodiments of the present invention provide a transaction data verification method, including:

[0007] Obtain the transaction dataset for the current day; wherein the transaction dataset for the current day includes at least one transaction record;

[0008] For each transaction data, the current transaction data is verified based on at least one verification method to obtain the verification result of the current transaction data under each verification method; wherein, at least one of the verification methods includes format verification, content verification and logical verification.

[0009] If all verification results are successful, then the current transaction data is marked as successful.

[0010] Generate a message to be sent based on all transaction data marked as verified, and then send it.

[0011] Secondly, embodiments of the present invention also provide a transaction data verification device, comprising:

[0012] A data acquisition module is used to acquire a daily transaction dataset; wherein the daily transaction dataset includes at least one transaction record.

[0013] The verification module is used to verify the current transaction data based on at least one verification method for each transaction data, and to obtain the verification result of the current transaction data under each verification method; wherein, at least one of the verification methods includes format verification, content verification and logical verification.

[0014] The marking module is used to mark the current transaction data as verified if all verification results are verified.

[0015] The message generation module is used to generate and send messages based on all transaction data marked as verified.

[0016] Thirdly, embodiments of the present invention also provide an electronic device, comprising:

[0017] At least one processor; and

[0018] A memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the transaction data verification method according to any embodiment of the present invention.

[0020] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute and implement the transaction data verification method described in any embodiment of the present invention.

[0021] Fifthly, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the transaction data verification method as described in any of the embodiments of the present invention.

[0022] The technical solution of this invention involves acquiring a daily transaction dataset, which includes at least one transaction record. For each transaction record, verification is performed using at least one verification method to obtain the verification result for each method. If all verification results are successful, the transaction record is marked as successful. A message to be sent is generated based on all transaction records marked as successful and then sent. In this technical solution, before sending the daily transaction dataset to the target department, content verification, format verification, and logical verification are performed on each transaction record in the dataset. A message is generated based on all transaction records that have passed these verifications and is then sent to the target department. This solves the problem in the prior art where content and format verification alone cannot cover the target department's verification scenarios, and where, even after submitting successful transaction records to the target department, there is still a possibility of receiving abnormal data receipts from the target department, leading to submission failure. This improves the probability of successful transaction data submission.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0025] Figure 1 This is a flowchart of a transaction data verification method provided in Embodiment 1 of the present invention;

[0026] Figure 2 This is a flowchart of a transaction data verification method provided in Embodiment 2 of the present invention;

[0027] Figure 3 This is a flowchart of a specific embodiment of a transaction data verification method provided in Embodiment 2 of the present invention;

[0028] Figure 4 This is a schematic diagram of the structure of a transaction data verification device according to Embodiment 3 of the present invention;

[0029] Figure 5 This is a schematic diagram of the structure of an electronic device that implements the transaction data verification method of this invention. Detailed Implementation

[0030] 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. The acquisition, transmission, storage, use, and processing of data in the technical solutions of this application comply with the relevant provisions of national laws and regulations. It should be noted that in the embodiments of this application, certain software, components, or models and other existing solutions in the industry may be mentioned. These should be considered as exemplary, and their purpose is only to illustrate the feasibility of implementing the technical solutions of this application, but it does not mean that the applicant has or necessarily used such solutions.

[0031] 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 sequences other than those illustrated or described herein.

[0032] Before elaborating on this technical solution in detail, let's briefly introduce its application scenarios to help us understand it more clearly.

[0033] Example 1

[0034] Figure 1 The present invention provides a flowchart of a transaction data verification method according to Embodiment 1. This embodiment is applicable to situations where financial institutions verify transaction data from three dimensions—content verification, format verification, and logical verification—before uploading transaction data to the target department, thereby improving the success rate of transaction data submission. This method can be executed by a transaction data verification device, which can be implemented in hardware and / or software and can be configured in a computing device capable of executing the transaction data verification method.

[0035] like Figure 1 As shown, the method includes:

[0036] S110. Obtain the transaction dataset for the day.

[0037] The daily transaction dataset refers to a collection of transaction data that a financial institution processes, generates, or receives within a calendar day or business day, directly related to a user's financial transaction activities. Each daily transaction dataset includes at least one transaction record.

[0038] S120. For each transaction data, verify the current transaction data based on at least one verification method to obtain the verification result of the current transaction data under each verification method.

[0039] Among them, at least one verification method includes format verification, content verification, and logical verification.

[0040] In practical applications, the assessment of the accuracy of transaction data includes three dimensions: content accuracy, format accuracy, and business logic accuracy. Therefore, this application can perform format verification, content verification, and logic verification on the transaction data when verifying the transaction data, and determine the accuracy of the transaction data based on the verification results under each verification method, and determine whether the transaction data meets the standards based on the accuracy of the transaction data.

[0041] Understandably, format verification refers to whether the data format of transaction data meets the preset data format. For example, if the data format of transaction data is required to be a standardized message protocol format, and the data format of the transaction data included in the daily transaction dataset is a standardized message protocol format, then the format verification result of the transaction data is that the verification is passed; if the data format of transaction data is other data formats, such as structured text format, then the format verification result of the transaction data is that the verification is failed.

[0042] Similarly, content validation mainly targets pre-defined aspects of transaction data, such as field completeness, timeliness, account status, and data rationality. If the content in the transaction data meets the pre-defined content validation requirements, the validation result is "validation passed"; if the transaction data contains content that does not meet the pre-defined requirements, the validation result is "validation failed".

[0043] Building upon this foundation, in addition to format and content validation of transaction data, this application also includes logical validation. Specifically, if the validation method is logical validation, it is necessary to determine the transaction characteristics that need to be validated based on the transaction scenario corresponding to the transaction data, and then invoke the transaction rules corresponding to each transaction characteristic to perform the validation and obtain the validation result. Here, the transaction scenario refers to the combination of environmental characteristics, operational processes, and business attributes in which a user initiates a transaction through a financial institution under the drive of a specific business objective. For example, the transaction scenario could be a transfer scenario, a storage scenario, or a lending scenario, etc.

[0044] S130. If all verification results are successful, then mark the current transaction data as successful.

[0045] Specifically, after verifying the current transaction data based on at least one verification method, if the content verification, format verification, and logical verification of the current transaction data all pass, then the current transaction data is marked as verified.

[0046] S140. Generate a message to be sent based on all transaction data marked as verified, and send it.

[0047] Among them, the message to be sent refers to the message generated based on all verified transaction data.

[0048] Specifically, for all transaction data marked as verified in the daily transaction dataset, message processing is performed to obtain the message to be sent, and then the message to be sent is sent to the target department.

[0049] It should be noted that if the daily transaction dataset contains transaction data that fails verification, the transaction data that fails verification will be corrected again, and the corrected transaction data will be verified again. After the verification is passed, the data will be combined with all the transaction data marked as verified to generate a message to be sent, and the message to be sent will be sent to the target department.

[0050] Optionally, after generating and sending a message based on all transaction data marked as verified, the method further includes: receiving a data verification receipt from the target department; if the data verification receipt contains failed verification items, then correcting the failed verification items.

[0051] Among them, the items that fail the verification refer to transaction data that were submitted to the target department but failed to pass the target department's review.

[0052] In practical applications, if the target department's verification rules are updated, the financial business institution may not adjust the corresponding verification rules in a timely manner. Therefore, although the transaction data in the current transaction dataset has undergone content verification, format verification, and logic verification before being submitted to the target department, there may still be unqualified transaction data in the submitted transaction data. In this case, the target department needs to report the unqualified items to the relevant financial business institution and mark the corresponding information to be corrected, so that the financial business institution can re-examine and correct the unqualified items based on the information to be corrected.

[0053] The technical solution of this invention involves acquiring a daily transaction dataset, which includes at least one transaction record. For each transaction record, verification is performed using at least one verification method to obtain the verification result for each method. If all verification results are successful, the transaction record is marked as successful. A message to be sent is generated based on all transaction records marked as successful and then sent. In this technical solution, before sending the daily transaction dataset to the target department, content verification, format verification, and logical verification are performed on each transaction record in the dataset. A message is generated based on all transaction records that have passed these verifications and is then sent to the target department. This solves the problem in the prior art where content and format verification alone cannot cover the target department's verification scenarios, and where, even after submitting successful transaction records to the target department, there is still a possibility of receiving abnormal data receipts from the target department, leading to submission failure. This improves the probability of successful transaction data submission.

[0054] Example 2

[0055] Figure 2 The flowchart of a transaction data verification method provided in Embodiment 2 of the present invention is as follows: Optionally, if the verification method is logical verification, the current transaction data is verified based on at least one verification method, and the verification results of the current transaction data under each verification method are refined.

[0056] like Figure 2 As shown, the method includes:

[0057] S210. Obtain the transaction dataset for the day.

[0058] The daily transaction dataset includes at least one transaction record.

[0059] S220. For each transaction data, perform keyword matching on the current transaction data to determine the target transaction scenario corresponding to the current transaction data.

[0060] S230. If the transaction scenario is a newly added transaction scenario, then at least one transaction feature to be used is extracted from the target transaction scenario based on the pre-built transaction feature extraction model.

[0061] A transaction scenario refers to the combination of environmental characteristics, operational processes, and business attributes that a user encounters when initiating a transaction through a financial institution under the drive of a specific business objective. For example, a transaction scenario could be a transfer scenario, a storage scenario, or a lending scenario. A transaction feature extraction model is used to extract transaction features from current transaction data based on the corresponding transaction scenario. A new transaction scenario refers to a new transaction scenario initiated by a financial institution based on business processing needs. Transaction features to be used refer to transaction features extracted from current transaction data based on the target transaction scenario.

[0062] S240. Retrieve the verification rules corresponding to each transaction feature to be used and perform verification to obtain the verification results corresponding to each transaction feature to be used.

[0063] Among them, the verification rules to be used refer to the verification rules used when verifying the transaction rules to be used in the target transaction scenario.

[0064] For example, taking a real-world financial business scenario as the target transaction scenario, for the current transaction data, by performing keyword matching on the transaction elements of the current transaction data, the transaction elements contained in the current transaction data are obtained, such as transaction channels, transaction codes and transaction remarks, etc., and the business scenario corresponding to the current transaction data is determined to be a real-world financial business scenario based on the matched transaction elements.

[0065] Furthermore, the verification rules corresponding to the real financial business scenario are retrieved to verify at least one of the transaction features to be used, and the current transaction data is determined to meet the standards based on the verification results.

[0066] If the physical financial business scenario (i.e., the target transaction scenario) is determined to be a new transaction scenario, since financial institutions may not have updated the verification rules for verifying the transaction characteristics of the physical financial business scenario in a timely manner, it is necessary to extract transaction characteristics from the current transaction data to determine the verification rules for verifying the transaction characteristics of the physical financial business scenario, and then verify them.

[0067] Optionally, before extracting at least one transaction feature to be used from the target transaction scenario based on the pre-built transaction feature extraction model, the method further includes: acquiring at least one historical transaction data; and training the transaction feature extraction model according to the mapping relationship between the transaction scenario and the transaction feature in the at least one historical transaction data.

[0068] Historical transaction data refers to transaction data generated by financial institutions before the current day.

[0069] For example, in practical applications, financial institutions can set up different business scenarios according to their business needs. Different business scenarios contain different transaction characteristics. When adding a new transaction scenario, the associated transaction characteristics of each scenario can be trained to determine the corresponding transaction characteristics for the new scenario. For instance, a financial institution can pre-set a transaction scenario configuration table, which includes at least one transaction scenario and at least one transaction characteristic associated with each scenario. Further, the transaction scenario configuration table is input into an initial transaction characteristic training module for training to obtain a transaction characteristic extraction model. This model is then used to extract features from the transaction data under the new transaction scenario, yielding at least one transaction characteristic.

[0070] Optionally, the verification rules corresponding to each transaction feature to be used are retrieved for verification to obtain the verification results corresponding to each transaction feature to be used. This includes: determining the verification rules corresponding to each transaction feature to be used based on a pre-built rule-feature mapping table; and verifying the corresponding transaction features to be used based on the verification rules corresponding to each transaction feature to be used to obtain the verification results.

[0071] The rule-feature mapping table contains at least one verification rule and the transaction features corresponding to each verification rule.

[0072] Optionally, this application further includes: if the transaction feature to be used is an unmapped transaction feature not included in the rule-feature mapping table, then obtaining at least one historical transaction data; training a verification rule determination model based on the mapping relationship between the transaction feature and the verification rule in the at least one historical transaction data; and determining the target verification rule corresponding to the unmapped transaction feature based on the verification rule determination model.

[0073] Unmapped transaction features refer to transaction features that cannot be found in the rule feature mapping table. The validation rule determination model is a model obtained by learning the mapping relationship between transaction features and validation rules in historical transaction data. After the validation rule determination model is trained, it can be used to determine the target validation rule corresponding to the unmapped transaction features.

[0074] For example, if unmapped transaction features exist, the corresponding verification rules cannot be directly determined. Therefore, this application learns the mapping relationship between transaction features and verification rules in historical verification data to obtain a verification rule determination model. This model then outputs the target verification rule corresponding to the unmapped transaction features. For instance, in a money transfer transaction scenario, the counterparty account cannot be empty, and the number of counterparty accounts cannot exceed n.

[0075] S250. If all verification results are successful, then mark the current transaction data as successful.

[0076] S260. Generate a message to be sent based on all transaction data marked as verified, and send it.

[0077] In a specific example, such as Figure 3 As shown, a transaction feature model is pre-trained based on historical transaction data to obtain a transaction feature extraction model, and a logical rule model is trained based on historical transaction data to obtain a verification rule determination model. Based on this, a daily transaction dataset is obtained, which contains at least one transaction. For each transaction, content verification, format verification, and logical verification are performed. After the transaction data passes all verifications, a message to be sent is generated and submitted to the designated financial department (i.e., the target department). Further, upon receiving the message to be sent, the designated financial department verifies the transaction data in the message. If any transaction data fails verification, it is sent back to the corresponding financial institution for manual correction and re-verification, until the failed transaction data passes all verification rules and the verification by the designated financial department.

[0078] During this process, when performing logical verification on transaction data, the transaction scenario corresponding to the transaction data is determined based on the transaction elements in the transaction data. If the transaction scenario is a newly added transaction scenario, at least one transaction feature to be used is extracted from the target transaction scenario based on a pre-built transaction feature extraction model, and this transaction feature is written into the transaction feature library. Further, it is determined whether a verification rule corresponding to the transaction feature to be used exists. If it exists, the transaction feature to be used is verified based on the corresponding verification rule to obtain a verification result. If it does not exist, the pre-built verification rule determination model is used to determine the verification rule corresponding to the transaction feature to be used, and the transaction feature to be used is verified based on the corresponding verification rule to obtain a verification result. The verification rule to be used is then written into the verification rule library so that transaction features of transaction data under the same transaction scenario can be verified in subsequent data verification processes.

[0079] Based on this, after verifying the current transaction data using at least one verification method, if the content verification, format verification, and logic verification of the current transaction data pass, then the current transaction data is marked as verified. Based on all transaction data marked as verified, a message to be sent is generated and sent to the designated financial department.

[0080] The technical solution of this invention involves acquiring a daily transaction dataset, which includes at least one transaction record. For each transaction record, verification is performed using at least one verification method to obtain the verification result for each method. If all verification results are successful, the transaction record is marked as successful. A message to be sent is generated based on all transaction records marked as successful and then sent. In this technical solution, before sending the daily transaction dataset to the target department, content verification, format verification, and logical verification are performed on each transaction record in the dataset. A message is generated based on all transaction records that have passed these verifications and is then sent to the target department. This solves the problem in the prior art where content and format verification alone cannot cover the target department's verification scenarios, and where, even after submitting successful transaction records to the target department, there is still a possibility of receiving abnormal data receipts from the target department, leading to submission failure. This improves the probability of successful transaction data submission.

[0081] Example 3

[0082] Figure 4 This is a schematic diagram of a transaction data verification device provided in Embodiment 3 of the present invention. Figure 4 As shown, the device includes: a data acquisition module 310, a verification module 320, a marking module 330, and a message generation module 340.

[0083] The data acquisition module 310 is used to acquire the daily transaction dataset; the daily transaction dataset includes at least one transaction record.

[0084] The verification module 320 is used to verify the current transaction data based on at least one verification method for each transaction data, and obtain the verification result of the current transaction data under each verification method; wherein, at least one verification method includes format verification, content verification and logical verification.

[0085] The marking module 330 is used to mark the current transaction data as having passed verification if all verification results are successful.

[0086] The message generation module 340 is used to generate and send messages based on all transaction data marked as verified.

[0087] The technical solution of this invention involves acquiring a daily transaction dataset, which includes at least one transaction record. For each transaction record, verification is performed using at least one verification method to obtain the verification result for each method. If all verification results are successful, the transaction record is marked as successful. A message to be sent is generated based on all transaction records marked as successful and then sent. In this technical solution, before sending the daily transaction dataset to the target department, content verification, format verification, and logical verification are performed on each transaction record in the dataset. A message is generated based on all transaction records that have passed these verifications and is then sent to the target department. This solves the problem in the prior art where content and format verification alone cannot cover the target department's verification scenarios, and where, even after submitting successful transaction records to the target department, there is still a possibility of receiving abnormal data receipts from the target department, leading to submission failure. This improves the probability of successful transaction data submission.

[0088] Optionally, the verification module includes: a scenario matching submodule, used to perform keyword matching on the current transaction data to determine the target transaction scenario corresponding to the current transaction data;

[0089] The feature extraction submodule is used to extract at least one transaction feature to be used from the target transaction scenario based on a pre-built transaction feature extraction model if the transaction scenario is a new transaction scenario.

[0090] The first verification submodule is used to retrieve the verification rules corresponding to each transaction feature to be used for verification, and obtain the verification results corresponding to each transaction feature to be used.

[0091] Optionally, the transaction data verification device further includes: a historical data acquisition module, used to acquire at least one historical transaction data before extracting at least one transaction feature to be used from the target transaction scenario based on a pre-built transaction feature extraction model;

[0092] The transaction feature extraction model training module is used to train a transaction feature extraction model based on the mapping relationship between transaction scenarios and transaction features in at least one historical transaction data.

[0093] Optionally, the verification module includes: a verification rule determination submodule, used to determine the verification rule to be used corresponding to each transaction feature to be used based on a pre-built rule-feature mapping table; wherein the rule-feature mapping table contains at least one verification rule and the transaction feature corresponding to each verification rule;

[0094] The second verification submodule is used to verify the corresponding transaction features based on the verification rules corresponding to each transaction feature to be used, and obtain the verification results.

[0095] Optionally, the verification module may also include: an unmapped transaction feature determination submodule, used to obtain at least one historical transaction data if the transaction feature to be used is an unmapped transaction feature not included in the rule-feature mapping table;

[0096] The verification rule determination model determination submodule is used to train the verification rule determination model based on the mapping relationship between transaction features and verification rules in at least one historical transaction data.

[0097] The target verification rule determination submodule is used to determine the target verification rule corresponding to the unmapped transaction features based on the verification rule determination model.

[0098] Optionally, the transaction data verification device is also used to receive data verification receipts from the target department, and if the transmitted data verification receipts contain failed verification items, the failed verification items will be corrected.

[0099] The transaction data verification device provided in this embodiment of the invention can execute the transaction data verification method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0100] Example 4

[0101] Figure 5 A schematic diagram of the structure of an electronic device 10 according to an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0102] like Figure 5As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0103] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0104] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as transaction data verification methods.

[0105] In some embodiments, the transaction data verification method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the transaction data verification method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the transaction data verification method by any other suitable means (e.g., by means of firmware).

[0106] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0107] Computer programs used to implement the transaction data verification method of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0108] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0109] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0110] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0111] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0112] Example 5

[0113] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the transaction data verification method provided in any embodiment of this application.

[0114] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0115] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0116] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for verifying transaction data, characterized in that, include: Obtain the transaction dataset for the current day; wherein the transaction dataset for the current day includes at least one transaction record; For each transaction data, the current transaction data is verified based on at least one verification method to obtain the verification result of the current transaction data under each verification method; wherein, at least one of the verification methods includes format verification, content verification and logical verification. If all verification results are successful, then the current transaction data is marked as successful. Generate a message to be sent based on all transaction data marked as verified, and then send it.

2. The method according to claim 1, characterized in that, If the verification method is the logical verification, then the step of verifying the current transaction data based on at least one verification method to obtain the verification results of the current transaction data under each verification method includes: Perform keyword matching on the current transaction data to determine the target transaction scenario corresponding to the current transaction data; If the transaction scenario is a new transaction scenario, then at least one transaction feature to be used is extracted from the target transaction scenario based on the pre-built transaction feature extraction model; The verification rules corresponding to each transaction feature to be used are retrieved and verified to obtain the verification results corresponding to each transaction feature to be used.

3. The method according to claim 2, characterized in that, Before extracting at least one usable transaction feature from the target transaction scenario based on the pre-built transaction feature extraction model, the method further includes: Obtain at least one historical transaction record; A transaction feature extraction model is trained based on the mapping relationship between transaction scenarios and transaction features in at least one of the historical transaction data.

4. The method according to claim 2, characterized in that, The step of retrieving the verification rules corresponding to each transaction feature to be used and performing verification to obtain the verification results corresponding to each transaction feature to be used includes: Based on a pre-built rule-feature mapping table, the verification rules to be used corresponding to each transaction feature to be used are determined; wherein, the rule-feature mapping table contains at least one verification rule and the transaction feature corresponding to each verification rule; The corresponding transaction features are verified according to the verification rules for each transaction feature to be used, and the verification results are obtained.

5. The method according to claim 4, characterized in that, Also includes: If the transaction feature to be used is an unmapped transaction feature not included in the rule-feature mapping table, then at least one historical transaction data is obtained; Based on the mapping relationship between transaction features and verification rules in at least one of the historical transaction data, a verification rule determination model is trained. Based on the verification rules, a model is determined, and the target verification rule corresponding to the unmapped transaction feature is determined.

6. The method according to claim 1, characterized in that, After generating and sending the message based on all transaction data marked as verified, the process further includes: Receive data verification feedback from the target department. If the data verification feedback contains items that failed verification, correct the items that failed verification.

7. A transaction data verification device, characterized in that, include: A data acquisition module is used to acquire a daily transaction dataset; wherein the daily transaction dataset includes at least one transaction record. The verification module is used to verify the current transaction data based on at least one verification method for each transaction data, and to obtain the verification result of the current transaction data under each verification method; wherein, at least one of the verification methods includes format verification, content verification and logical verification. The marking module is used to mark the current transaction data as verified if all verification results are verified. The message generation module is used to generate and send messages based on all transaction data marked as verified.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the transaction data verification method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the transaction data verification method according to any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the transaction data verification method as described in any one of claims 1-6.

Images