Transaction data verification method and device, storage medium and electronic equipment

Abstract

The invention discloses a transaction data verification method and device, a storage medium and electronic equipment. The method comprises the steps that target transaction data are acquired, and the target transaction data are used for executing cross-regional transaction operation; a plurality of verification threads are set according to the to-be-verified verification scenes, one verification thread corresponds to one verification scene, and different verification scenes need different target transaction data; a plurality of verification threads are used for executing scene verification operation on the target transaction data, and in the process of executing the multi-scene verification operation on the target transaction data, in response to the fact that at least one verification thread receives target abnormal data, an abnormal prompt message is generated, the target abnormal data is used for indicating that the transaction data required by any verification scene does not pass the verification, and the abnormal prompt message is used for indicating the termination of the cross-regional transaction operation. The technical problem that the verification accuracy of the transaction data is low is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the computer field, in particular, to a transaction data verification method and device, a storage medium and an electronic device. BACKGROUND

[0002] In the existing cross-regional transaction processing system, the verification mechanism of transaction data usually relies on a serial processing flow, that is, the system will sequentially pass through multiple verification scenarios to verify the compliance and security of the transaction data. This traditional verification method results in low verification accuracy and low efficiency, affecting the timeliness and accuracy of transaction data verification.

[0003] At present, no effective solution has been proposed for the above problems. SUMMARY

[0004] The embodiments of the present application provide a transaction data verification method and device, a storage medium and an electronic device to at least solve the technical problem of low verification accuracy of transaction data.

[0005] According to an aspect of the embodiments of the present application, a transaction data verification method is provided, comprising: obtaining target transaction data, wherein the target transaction data is used to perform a cross-regional transaction operation; setting multiple verification threads according to multiple verification scenarios to be verified, wherein one verification thread corresponds to one verification scenario, and different verification scenarios require different target transaction data; performing a scenario verification operation on the target transaction data using multiple verification threads, and in the process of performing a multi-scenario verification operation on the target transaction data, in response to at least one verification thread receiving target abnormal data, generating an abnormal prompt message, wherein the target abnormal data is used to indicate that the transaction data required by any verification scenario fails to pass the verification, and the abnormal prompt message is used to indicate termination of the cross-regional transaction operation.

[0006] According to another aspect of the embodiments of the present application, a transaction data verification device is also provided, comprising: an obtaining module configured to obtain target transaction data, wherein the target transaction data is used to perform a cross-regional transaction operation; a setting module configured to set multiple verification threads according to multiple verification scenarios to be verified, wherein one verification thread corresponds to one verification scenario, and different verification scenarios require different target transaction data; and an execution module configured to perform a scenario verification operation on the target transaction data using multiple verification threads, and in the process of performing a multi-scenario verification operation on the target transaction data, in response to at least one verification thread receiving target abnormal data, generating an abnormal prompt message, wherein the target abnormal data is used to indicate that the transaction data required by any verification scenario fails to pass the verification, and the abnormal prompt message is used to indicate termination of the cross-regional transaction operation.

[0007] In an example embodiment, the apparatus is configured to generate an exception prompt message in response to at least one of the check threads receiving target exception data, by: controlling a first check thread to generate the exception prompt message and send the exception prompt message to a master thread, in a case that the first check thread receives the target exception data, wherein the first check thread is one of the check threads; and sending an interrupt message to a second check thread to terminate the second check thread from performing the scenario check operation in response to the master thread receiving the exception prompt message, wherein the second check thread is one of the check threads other than the first check thread.

[0008] In an example embodiment, the apparatus is configured to generate the master thread before controlling the first check thread to generate the exception prompt message and send the exception prompt message to the master thread in a case that the first check thread receives the target exception data, by: controlling the master thread to generate a plurality of the check threads according to a plurality of the check scenarios.

[0009] In an example embodiment, the apparatus is further configured to: determine scenario transaction data from the target transaction data according to a target check scenario; set a target operation object according to the scenario transaction data; and perform the scenario check operation on the target operation object in a target method body, wherein the target method body belongs to the check thread corresponding to the target check scenario.

[0010] In an example embodiment, the target transaction data includes at least one of a resource type, object information, a resource quantity, and transaction information.

[0011] In an example embodiment, the check scenario includes at least one of a resource liquidity check scenario and a resource transaction mode check scenario.

[0012] According to another aspect of the embodiments of the present application, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program. The computer program is configured to perform the above-mentioned transaction data check method when running.

[0013] According to another aspect of the embodiments of the present application, a computer program product or a computer program is provided, and the computer program product or the computer program includes computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the above-mentioned transaction data check method.

[0014] According to a further aspect of the embodiments of the present application, an electronic device is also provided, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-mentioned transaction data verification method by using the computer program.

[0015] In the embodiments of the present application, target transaction data is acquired, wherein the target transaction data is used to perform a cross-region transaction operation; a plurality of verification threads are set according to a plurality of verification scenarios to be verified, wherein one verification thread corresponds to one verification scenario, and different verification scenarios require different target transaction data; and a scene verification operation is performed on the target transaction data by using the plurality of verification threads, and in the process of performing the multi-scene verification operation on the target transaction data, in response to the fact that at least one verification thread receives target abnormal data, an abnormal prompt message is generated, wherein the target abnormal data is used to indicate that the transaction data required by any verification scenario fails to pass the verification, and the abnormal prompt message is used to indicate that the cross-region transaction operation is terminated, thereby achieving the technical effect of improving the cross-region transaction security and efficiency, and further solving the technical problems of low verification accuracy of transaction data, long processing time, and influence on user experience and transaction fluency. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are included to provide a further understanding of the present application, form a part of the present application and illustrate the illustrative embodiments of the present application and the explanation of the present application, and do not constitute improper limitations on the present application. In the drawings:

[0017] Figure 1 is a schematic diagram of an application environment of an optional transaction data verification method according to an embodiment of the present application.

[0018] Figure 2 is a flowchart of an optional transaction data verification method according to an embodiment of the present application.

[0019] Figure 3 is a schematic diagram of the overall flow of an optional transaction data verification method according to an embodiment of the present application.

[0020] Figure 4 is a schematic diagram of the detailed flow of an optional transaction data verification method according to an embodiment of the present application.

[0021] Figure 5 is a schematic diagram of the structure of an optional transaction data verification device according to an embodiment of the present application.

[0022] Figure 6 is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to make the person skilled in the art better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by the person skilled in the art without creative labor should be within the scope of protection of the present application.

[0024] It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0025] It should be noted that in the technical scheme of the present application, the collection, storage, use, processing, transmission, provision and disclosure of financial data or user data and other information involved in the technical scheme of the present application comply with the relevant legal regulations and do not violate public order and good customs.

[0026] It should be noted that in the embodiments of the present application, some software, components, models and other existing solutions in the industry may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical scheme of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0027] The present application will be described below in conjunction with the embodiments:

[0028] According to an aspect of an embodiment of the present application, a transaction data verification method is provided.

[0029] Optionally, in the present embodiment, the above-mentioned transaction data verification method can be applied in a hardware environment composed of a server 101 and a terminal device 103 as shown in Figure 1

[0030] Further, in conjunction with Figure 1 The above-mentioned transaction data verification method can be realized by the terminal device 103 or the server 101 respectively, or realized by the terminal device 103 and the server 101 together, and the embodiments of the present application do not limit this. ​

[0031] It should be noted that the server 101 is connected with the terminal device 103 through the network, and can be used to provide services for the terminal device or the application program 107 installed on the terminal device to implement the above-mentioned transaction data verification method. The database 105 can also be set on the server 101 or independently of the server 101, and is used to provide data storage services for implementing the above-mentioned transaction data verification method, specifically:

[0032] The server 101 and the terminal device 103 can be any node in a distributed system, and the distributed system can be a blockchain system, etc. The blockchain system can be a distributed system formed by the multiple nodes communicating through the network. The nodes can form any form of network, and any computing device, such as any electronic device, can become a node in the distributed system by joining the network formed by the nodes.

[0033] The server 101 can be a single server, a server cluster composed of multiple servers, or a cloud server.

[0034] The network can include but is not limited to a wired network and a wireless network. The wired network includes a local area network, a metropolitan area network, and a wide area network. The wireless network includes Bluetooth, WIFI, and other wireless communication networks.

[0035] The terminal device 103 can be a terminal configured with an application program, and can include but is not limited to at least one of the following: a mobile phone (such as an Android mobile phone, an iOS mobile phone, etc.), a notebook computer, a tablet computer, a palm computer, a MID (Mobile Internet Device), a PAD, a desktop computer, a smart television, a smart voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal, and other computer devices.

[0036] Optionally, as an optional implementation manner, as shown in Figure 2 The transaction data verification method includes:

[0037] S202, obtaining target transaction data, wherein the target transaction data is used to perform a cross-region transaction operation;

[0038] Optionally, in the embodiments of the present application, the target transaction data refers to various key information involved in the transaction process, including but not limited to the identity of the transaction parties, the transaction amount, the transaction resource type, the transaction time and location, the description of the transaction goods or services, the credit level of the transaction parties, the payment method, etc. These information is the basis for cross-regional transaction operation, which is used to support subsequent compliance check, risk assessment and transaction execution.

[0039] It should be noted that due to the diversity of cross-regional transactions, the type and format of target transaction data may vary, for example, in some scenarios, the identity of the transaction parties may include personal identification number, enterprise registration number or social media account, etc. The description of the transaction goods or services may contain detailed specification parameters, quality standards, delivery terms, etc. The present application does not limit this, as long as the data can meet the needs of the verification scenario, it can be processed as target transaction data.

[0040] S204, a plurality of verification threads are set according to a plurality of verification scenarios to be verified, wherein one verification thread corresponds to one verification scenario, and different verification scenarios require different target transaction data;

[0041] Optionally, in the embodiments of the present application, the verification scenario refers to various specific conditions or rules that need to be verified in the transaction process, including but not limited to resource flow security audit, compliance and restriction check, important and complex transaction monitoring and reporting, cross-border resource exchange report, cross-border digital resource collection and payment declaration, etc. Each verification scenario aims to ensure the legality and security of the transaction from different angles, and by setting corresponding threads, these scenarios can be processed in parallel to improve the verification efficiency.

[0042] It should be noted that different verification scenarios may have different requirements for target transaction data. For example, resource flow security audit requires the identity information and transaction history of the transaction parties, while cross-border resource exchange report may focus more on the resource type and transaction volume of the transaction.

[0043] In addition, the setting of verification scenarios and the demand for target transaction data can be adjusted according to the actual application environment and transaction type, for example, in some high-risk transactions, additional verification scenarios are added, or in some specific types of transactions, some verification scenarios do not need to use all types of target transaction data. The present application does not limit this, the configuration of verification scenarios and required target transaction data should be adjusted flexibly according to specific needs.

[0044] S206, performing a scenario verification operation on the target transaction data using multiple verification threads, in the process of performing the multi-scenario verification operation on the target transaction data, in response to at least one verification thread receiving target abnormal data, generating an abnormal prompt message, wherein the target abnormal data is used to indicate that the transaction data required by any verification scenario fails to pass the verification, and the abnormal prompt message is used to indicate the termination of the cross-region transaction operation.

[0045] Optionally, in the embodiments of the present application, the above-mentioned target abnormal data refers to the target transaction data that fails to pass the check of any verification scenario, including but not limited to the transaction amount exceeding the reasonable range, the transaction parties information not matching, the transaction time not conforming to the regular mode, the description of the transaction goods or services conflicting with the compliance requirements, etc. The abnormal prompt message is a signal generated by the transaction system to immediately notify and indicate the termination of the cross-region transaction operation, ensuring that the transaction will not continue when the data verification has a problem.

[0046] It should be noted that the basis for judging the target abnormal data can vary depending on different verification scenarios. For example, for resource flow security audit, the abnormal data can come from abnormal behaviors found in the transaction history; and for cross-border digital resource collection and payment declaration, the abnormal data can not conform to the compliance use standard of digital resources. In addition, the generation mechanism of the abnormal prompt message can be designed to be automatic or semi-automatic, according to the preset rules of the system, once the target abnormal data is detected, the abnormal prompt message is generated immediately. The present application does not make any limitation.

[0047] Exemplarily, the target transaction data is obtained, which contains the key information necessary for performing the cross-region transaction; then, according to the pre-defined multiple verification scenarios, the corresponding multiple verification threads are set, ensuring that each verification thread corresponds to an independent verification scenario, and the verification scenario corresponds to the required target transaction data one by one; at the thread level, the system starts multiple verification threads in parallel to perform multi-scenario verification on the target transaction data, once the target abnormal data is detected in any scenario, the system immediately generates an abnormal prompt message, and then indicates the termination of the cross-region transaction operation, preventing the risk caused by abnormal transaction data.

[0048] In an exemplary embodiment, in combination with Figure 3 the overall flowchart shown in FIG. 1, and Figure 4 the detailed flowchart shown in FIG. 2, taken as an example of a cross-region payment scenario:

[0049] S1, the system first captures a cross-region resource transaction request, extracts the required fields and additional information related to the resource transaction, such as the identification of the resource transaction parties, the quantity, the resource type, the description of the resource transaction purpose, etc., to form the target transaction data.

[0050] S2, based on the multi-scene verification principle, the system creates four verification threads, corresponding to resource flow security audit, compliance and restriction check, important and complex transaction detection and reporting, and cross-regional resource exchange reporting.

[0051] S3, then, each thread is started in parallel to verify different aspects of the target transaction data. Suppose in the resource flow security audit scenario, the thread detects potential irregular patterns in the payment party's historical transaction behavior, which is considered as target abnormal data.

[0052] S4, the system immediately generates an abnormal prompt message, which clearly indicates that the payment operation should be terminated immediately to avoid abnormal transaction data entering the subsequent processing flow, ensuring the safety and compliance of cross-regional resource transactions.

[0053] For example, based on the preliminary analysis of the target transaction data, such as the size of the transaction amount, the type of transaction resources, the credit records of both parties, etc., the potential risk level of the transaction is automatically identified. Then, according to the preset rules, the most suitable verification scene and thread are assigned to each transaction. For cross-regional operations involving sensitive resources or large transactions, both resource flow security audit and important and complex transaction monitoring and reporting verification threads can be started simultaneously to ensure the overall safety of the transaction; while for smaller or regular transactions, only one resource flow security audit verification thread may be needed.

[0054] In addition, based on the specific needs of the target transaction data, the allocation mechanism of the verification thread can also be dynamically adjusted, so that the system can adjust the verification process in real time according to new information or external environmental changes, such as increasing or decreasing verification scenes, adjusting verification priorities, ensuring that the transaction verification is both comprehensive and efficient.

[0055] In an exemplary embodiment, taking the application scenario of cross-border digital asset transactions as an example:

[0056] S1, the system receives a cross-border digital asset transaction request and automatically extracts key information from the request to form target transaction data.

[0057] S2, according to the type and amount of the transaction digital asset, the system predicts its risk level. Suppose the system determines that the transaction involves high-value resources and the transaction amount is large, and the risk level is high.

[0058] S3, the system immediately starts two verification threads, resource flow security audit and important and complex transaction monitoring and reporting, each focusing on checking different aspects of the target transaction data, such as the resource flow security audit thread focusing on the credit records and historical transaction behavior of both parties, while the important and complex transaction monitoring and reporting thread focusing on checking whether the amount and resource type of the transaction meet the regulatory requirements.

[0059] S4, two threads start working in parallel, respectively checking the target transaction data.

[0060] S5, assuming that the resource flow security audit thread finds that the credit record of one party of the transaction is abnormal during the checking process, which is regarded as target abnormal data.

[0061] S6, the system immediately generates an abnormal prompt message, indicating that the transaction is risky and needs to be terminated or further manually audited.

[0062] S7, the system sends the abnormal prompt message to other running checking threads, instructing them to stop checking or adjust the checking strategy.

[0063] In the embodiments of the present application, target transaction data is obtained, wherein the target transaction data is used to perform a cross-regional transaction operation; a plurality of checking threads are set according to a plurality of verification scenarios to be verified, wherein one verification thread corresponds to one checking scenario, and different checking scenarios require different target transaction data; a plurality of checking threads are used to perform scene checking operations on the target transaction data, and in the process of performing the multi-scene checking operation on the target transaction data, in response to at least one checking thread receiving target abnormal data, an abnormal prompt message is generated, wherein the target abnormal data is used to indicate that the transaction data required by any checking scenario fails to pass the verification, and the abnormal prompt message is used to indicate that the cross-regional transaction operation is terminated, thereby achieving the purpose of quickly and accurately screening transaction data, and achieving the technical effect of improving the security and efficiency of cross-regional transactions, thereby solving the technical problems of low verification accuracy of transaction data, long processing time, and affecting user experience and transaction fluency.

[0064] As an optional solution, the above response to at least one of the above checking threads receiving target abnormal data generates an abnormal prompt message, including: in the case that the first checking thread receives the target abnormal data, the first checking thread is controlled to generate the abnormal prompt message, and the abnormal prompt message is sent to the master thread, wherein the first checking thread belongs to the checking thread; in response to the master thread receiving the abnormal prompt message, an interrupt message is sent to the second checking thread to terminate the second checking thread from performing the scene checking operation, wherein the second checking thread represents the checking thread in the plurality of checking threads except the first checking thread.

[0065] Optionally, in the embodiments of the present application, the first checking thread refers to a thread responsible for performing a specific checking scenario, including but not limited to a resource flow security audit thread, a compliance checking thread, a large transaction monitoring thread, etc. These threads independently check the transaction data to ensure that the data meets the preset checking rules.

[0066] For example, when the first verification thread detects the target abnormal data, it will generate an abnormal prompt message and send the message to the master thread, and the master thread will send instructions to other running verification threads according to the received message, instructing them to stop the verification operation. The system is allowed to react immediately when an exception is found in any verification scenario, without waiting for all verification threads to complete the verification, thereby effectively improving transaction security and efficiency. The present application is not limited in this regard.

[0067] Illustratively, the interaction between the master thread and the first verification thread enables immediate response and processing of abnormal transaction data, ensuring that an abnormal prompt message can be generated and sent to the master thread as soon as an exception is detected in any verification scenario, and the master thread uniformly controls the operation of other verification threads to achieve the purpose of terminating subsequent verification.

[0068] In an exemplary embodiment, taking a cross-border payment scenario as an example:

[0069] S1, when the system starts processing a cross-border payment request, the first verification thread, the resource flow security audit thread, starts to check whether there is any irregular behavior in the historical transaction records of the payment parties.

[0070] S2, if it is found that the payment party has abnormal transaction behavior (target abnormal data) in the checking process, the resource flow security audit thread will generate an abnormal prompt message.

[0071] S3, the abnormal prompt message is sent to the master thread, and the master thread receives the message and immediately sends instructions to the second verification thread, the financial sanctions compliance checking thread, which is being performed, to stop further verification of the payment, to prevent abnormal data from being misjudged as compliant.

[0072] S4, the financial sanctions compliance checking thread immediately terminates its verification operation and releases the occupied system resources after receiving the instructions from the master thread, to avoid unnecessary processing consumption and improve the overall response speed of the system.

[0073] Through the embodiments of the present application, the real-time monitoring and immediate response mechanism is adopted to enable the generation of an abnormal prompt message and the notification of the master thread to control the stop of all related verification threads as soon as abnormal transaction data is detected, thereby improving the accuracy of transaction data verification and transaction security, ensuring the effectiveness of transaction data in any verification scenario, and preventing abnormal data from entering the subsequent processing link.

[0074] It should be noted that the embodiments of the present application not only apply to the case of finding abnormality in a single verification scene, but also can deal with abnormal situations that may occur when multiple scenes are verified concurrently. That is, no matter which verification thread detects abnormal data first, the abnormality processing flow can be triggered quickly to ensure the safety and efficiency of transaction operations.

[0075] As an optional solution, before the first verification thread receives the target abnormal data, the method further includes: generating the master thread; and controlling the master thread to generate multiple verification threads according to multiple verification scenes.

[0076] Optionally, in the embodiments of the present application, the master thread refers to a process responsible for coordinating and managing multiple verification threads, including but not limited to initializing verification threads, allocating target transaction data, monitoring verification status, and summarizing verification results. Controlling the master thread to generate multiple verification threads means that the master thread starts and creates multiple independent threads, and each thread will focus on a specific verification scene to process the verification task of transaction data in parallel.

[0077] It should be noted that the interaction mechanism between the master thread and the verification thread can be flexibly designed. For example, the master thread can set the starting conditions of the verification thread in advance or dynamically generate the verification thread according to the type of the target transaction data. In addition, the allocation of the target transaction data can also be intelligently managed by the master thread to ensure that each verification thread receives valid information related to its verification scene. The present application does not limit this, and the key is to coordinate the generation and running of the verification thread through the master thread to achieve an efficient and parallel verification process.

[0078] Illustratively, the master thread is generated before the verification thread, and then the master thread generates and starts multiple verification threads according to the preset verification scenes, and each verification thread focuses on processing transaction data related to its own scene. When any verification thread detects abnormal data, it transmits abnormal information to the master thread, which uniformly manages the abnormality processing flow and terminates the verification operation of the remaining verification threads.

[0079] In an exemplary embodiment, the application scenario is the cross-border payment:

[0080] S1, the system generates a master thread responsible for overall verification process coordination.

[0081] S2, the master thread generates corresponding verification threads according to defined verification scenes such as resource flow safety audit, compliance check, large and suspicious transaction monitoring, international balance of payments declaration, cross-border digital resource payment declaration, etc.

[0082] S3, each verification thread receives target transaction data from the master thread, and starts to perform the verification operation in the respective scenario.

[0083] S4, during the verification process, once the first verification thread (for example, the thread performing resource flow security audit) detects target abnormal data, an abnormal prompt message is generated and sent to the master thread.

[0084] S5, after receiving the abnormal prompt message, the master thread sends a stop instruction to the second verification thread (i.e., all the remaining verification threads), instructing them to stop performing the verification operation.

[0085] Through the embodiments of the present application, the way of using the master thread to coordinate the parallel work of multiple verification threads is adopted, the technical effect of quickly generating and sending an abnormal prompt message when abnormal data is detected is achieved, and the purpose of timely terminating the cross-region transaction operation and improving the transaction security is achieved.

[0086] It should be noted that the interaction between the master thread and the verification thread can be real-time, that is, once the abnormality is detected, the response is immediate, avoiding abnormal data from entering the subsequent verification link. At the same time, the generation mechanism of the abnormal prompt message ensures the accuracy of the verification of the transaction data, avoiding the influence of the delay or failure of a single verification thread on the efficiency and safety of the entire transaction process.

[0087] The embodiments of the present application introduce the master thread to manage and control the verification thread, realize efficient parallel verification of transaction data and immediate response to abnormal conditions, and effectively improve the security and accuracy of cross-region transactions.

[0088] As an optional solution, the above method further comprises: determining scenario transaction data from the target transaction data according to a target verification scenario; setting a target operation object according to the scenario transaction data; and performing the scenario verification operation on the target operation object in a target method body, wherein the target method body belongs to the verification thread corresponding to the target verification scenario.

[0089] Optionally, in the embodiments of the present application, the target verification scenario refers to the check rules or conditions set for verifying the legality of a specific transaction, including but not limited to financial anomaly detection, large and suspicious transaction monitoring and reporting, international balance of payments declaration, cross-border digital resource collection and payment declaration, etc. The scenario transaction data refers to the information extracted from the target transaction data for verification related to a specific verification scenario.

[0090] For example, in the financial anomaly detection scenario, the scene transaction data can include the names, addresses, transaction resources, and transaction purposes of the two parties involved in the transaction. The target operation object is a data object or container constructed according to the scene transaction data, which is used for further processing and verification in the method body of the verification thread. Performing scene verification operations on the operation object in the target method body means that each verification thread contains a specific method body for verifying the operation object, thereby achieving multi-scene verification of the target transaction data.

[0091] It should be noted that the determination of the scene transaction data and the setting of the target operation object can be flexibly adjusted according to different verification scenes. For example, in the financial anomaly detection scenario, the scene transaction data can need to include detailed information of the two parties involved in the transaction; while in the large amount and suspicious transaction monitoring scenario, more attention can be paid to transaction amount and time data. At the same time, the construction of the target operation object can be the encapsulation of the scene transaction data, or further processing of the data for efficient verification in the method body of the thread. The present application does not limit this.

[0092] Illustratively, the master thread filters the scene transaction data from the target transaction data according to the preset target verification scene, and then sets the target operation object according to the characteristics of the scene transaction data. Then, in the verification thread corresponding to the target verification scene, each thread has its specific target method body, which realizes multi-scene and parallel verification of the transaction data by performing corresponding scene verification operations on the operation object in the method body.

[0093] In an exemplary embodiment, the application scenario of cross-border payment is taken as an example:

[0094] S1, the system generates a master thread, and defines multiple target verification scenes according to the characteristics of cross-border payment, such as resource flow security audit, compliance and restriction check, important and complex transaction monitoring and reporting, and cross-border resource exchange reporting.

[0095] S2, the master thread determines the scene transaction data from the target transaction data according to the target verification scene of resource flow security audit, including the identity of the two parties involved in the transaction, the transaction amount, the transaction location, and other information.

[0096] S3, the system sets a target operation object according to the scene transaction data, which contains all the necessary information for security audit.

[0097] S4, the above operation object is passed to the verification thread corresponding to the resource flow security audit scene, which contains a target method body for performing scene verification operations on the operation object.

[0098] S5, the target method body runs within the thread and performs deep verification on the operation object to ensure that the transaction data meets the requirements of the security audit.

[0099] S6, if abnormal data is detected (such as the transaction amount does not match the historical transaction), the target method body generates an exception prompt message and passes it to other verification threads through the main control thread, instructing them to stop the verification operation.

[0100] Through the embodiments of the present application, the scene transaction data is determined from the target transaction data, the target operation object is constructed, and the scene verification operation is performed in the target method body. The function of realizing comprehensive, accurate and fast compliance check of cross-border payment transaction data under multi-thread parallel processing is realized. The technical effect is to improve the verification accuracy of transaction data and transaction security. The purpose of ensuring the effectiveness of transaction data in any verification scene and preventing abnormal data from entering the subsequent processing link is achieved.

[0101] As an optional solution, the target transaction data includes at least one of resource type, object information, resource quantity and transaction information.

[0102] As an optional solution, the verification scene includes at least one of resource liquidity verification scene and resource transaction mode verification scene.

[0103] Optionally, in the embodiments of the present application, the resource type refers to the category of assets or services involved in the transaction, including but not limited to currency, digital assets, physical goods, service items, etc. The object information involves the detailed information of the transaction parties or multiple parties, including but not limited to the name, address, contact information, identity verification information, etc. of the transaction subject. The resource quantity refers to the specific amount of resources involved in the transaction, which can be the amount, quantity, capacity, etc. The transaction information covers the detailed description of the transaction, such as transaction time, place, purpose, mode, etc.

[0104] It should be noted that for different transaction scenarios, the composition of the target transaction data may be different. For example, in cross-border financial transactions, the resource type mainly focuses on currency type and exchange rate; in digital asset transactions, the object information may focus on the owner information and transaction records of the digital wallet; in physical commodity transactions, the resource quantity and transaction information may be more detailed, including the specific specifications of the goods and the logistics information of the transaction. The present application does not limit this, and the specific content of the target transaction data should be flexibly configured according to the actual transaction type and demand.

[0105] Exemplarily, target transaction data is acquired, which can include resource type, object information, resource quantity, and transaction information of the transaction parties. Subsequently, according to preset verification scenarios such as resource liquidity verification scenarios and resource transaction mode verification scenarios, parallel verification threads are set respectively to verify different aspects of the target transaction data. Once any thread detects abnormal data, the system immediately generates an abnormal prompt message to indicate termination of the transaction to prevent potential risks.

[0106] In an exemplary embodiment, the application scenario of cross-border digital asset transactions is taken as an example:

[0107] S1. The system captures a cross-border digital asset transaction request and extracts target transaction data including resource type, object information, resource quantity, and transaction information (transaction time, location, and purpose) from the request.

[0108] S2. According to the resource liquidity verification scenario and the resource transaction mode verification scenario, the system creates and starts two verification threads to verify the target transaction data.

[0109] S3. The resource liquidity verification thread checks whether the resource type and quantity meet the liquidity requirements, and the resource transaction mode verification thread verifies whether the transaction meets the preset transaction mode.

[0110] S4. If any thread (for example, the resource liquidity verification thread) detects an abnormality, such as resource quantity exceeding a reasonable range or resource type not being in the allowed transaction category, the thread immediately generates an abnormal prompt message.

[0111] S5. The abnormal prompt message is sent to the master thread, which sends a stop command to the remaining verification threads to ensure that all verification operations are immediately stopped.

[0112] S6. The transaction is terminated immediately to prevent further processing of abnormal data and protect transaction security.

[0113] Through the embodiments of the present application, the resource type, object information, resource quantity, and transaction information are extracted from the target transaction data, and parallel verification is performed according to the resource liquidity verification scenario and the resource transaction mode verification scenario. This realizes comprehensive and accurate verification of transaction data under multi-thread parallel processing, improves the verification efficiency and transaction security of transaction data, and achieves the purpose of discovering and stopping abnormal transaction data in a timely manner to ensure transaction compliance.

[0114] In an exemplary embodiment, before processing the target transaction data, the cross-border payment submission data (the above target transaction data) is judged. If the submission data is incorrect, it will cause subsequent processing of the submission data to be incorrect or missing, causing certain memory pressure and resource waste of the system. If there is no problem, then subsequent financial screening and declaration processing will be continued.

[0115] When starting processing, a Thread object is allocated for each financial screening and declaration scenario (for different payee bank countries and regions, payee countries and regions, different financial transaction models configured by business, the model supports dynamic configuration of different verification fields and verification rules, and supports dynamic promotion verification of related fields for similar transactions occurring in the same day or month). The run() method is rewritten, the start method is called to start the thread, and a for loop is used to start processing the payment information. A financial screening and declaration object tab_aml_incomelog is declared, and the system processed information including the system generated reference number, currency, amount, payer number, payer name, payee number, payee name, payee address, agency account information, commission fee bearing method, agency information, payee bank information, intermediary agency information, payment information, transaction notes are assigned to this object. Then a switch statement is used to verify the processed fields, and the verification includes the length of the data, whether the data is within the enumeration range, and other legality verification. The purpose of using switch is that the verification method and the logic of the result of each element can be recorded in the method body, and Invalid is used as an identifier. When more than one scene fails, the transaction fails directly, which improves the customer experience. Specifically, when a certain scene fails, an error will be thrown in the thread method according to the verification result, and the error is returned to the main process. After the main process captures an exception, it will enter the exception handling process and return a transaction failure, reducing customer waiting time.

[0116] When the parallel financial screening and declaration are passed, the subsequent cross-border payment process is continued, reducing customer waiting time and realizing cross-border payment.

[0117] Through the embodiments of the present application, multiple threads are started for background synchronous processing, reducing waiting time, improving customer cross-border payment scene use experience, and avoiding most invalid submissions.

[0118] It can be understood that in the specific embodiments of the present application, user information and other related data are involved. When the above embodiments of the present application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0119] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all described as a combination of a series of actions, but those skilled in the art should know that the present application is not limited to the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0120] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and a necessary general hardware platform, and of course, it can also be realized by hardware, but in many cases, the former is a better embodiment.

[0121] Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product in essence or the part that contributes to the prior art, and the computer software product is stored in a storage medium (such as a Read-Only Memory (ROM) / Random Access Memory (RAM), a magnetic disk, an optical disk), and includes a plurality of instructions for causing an end device (which can be a mobile phone, a computer, a server, or a network device) to execute the method described in each embodiment of the present application.

[0122] According to another aspect of the embodiments of the present application, a transaction data verification device for implementing the transaction data verification method described above is also provided. The transaction data verification device can be used to implement the transaction data verification method provided in the above embodiments, which has been described and will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware or a combination of software and hardware is also possible and is contemplated.

[0123] Figure 5 is a structural block diagram of an optional transaction data verification device according to the embodiments of the present application, as shown in Figure 5 The transaction data verification device includes:

[0124] The acquisition module 502 is configured to acquire target transaction data, wherein the target transaction data is used to perform a cross-region transaction operation.

[0125] The setting module 504 is configured to set a plurality of verification threads according to a plurality of verification scenarios to be verified, wherein one verification thread corresponds to one verification scenario, and different verification scenarios require different target transaction data.

[0126] The execution module 506 is configured to perform a scenario verification operation on the target transaction data using a plurality of verification threads, and in the process of performing the multi-scenario verification operation on the target transaction data, in response to the at least one verification thread receiving target abnormal data, an abnormal prompt message is generated, wherein the target abnormal data is used to indicate that the transaction data required by any verification scenario fails to pass the verification, and the abnormal prompt message is used to indicate that the cross-regional transaction operation is terminated.

[0127] In an example embodiment, the device is configured to generate the abnormal prompt message in response to the at least one verification thread receiving the target abnormal data by: in the case that the first verification thread receives the target abnormal data, controlling the first verification thread to generate the abnormal prompt message and send the abnormal prompt message to the master thread, wherein the first verification thread belongs to the verification threads; in response to the master thread receiving the abnormal prompt message, sending an interrupt message to the second verification thread to terminate the second verification thread from performing the scenario verification operation, wherein the second verification thread represents the verification threads other than the first verification thread among the plurality of verification threads.

[0128] In an example embodiment, the device is configured to generate the master thread before controlling the first verification thread to generate the abnormal prompt message and send the abnormal prompt message to the master thread in the case that the first verification thread receives the target abnormal data by: controlling the master thread to generate the plurality of verification threads according to the plurality of verification scenarios.

[0129] In an example embodiment, the device is further configured to: determine scenario transaction data from the target transaction data according to a target verification scenario; set a target operation object according to the scenario transaction data; and perform a scenario verification operation on the target operation object in a target method body, wherein the target method body belongs to a verification thread corresponding to the target verification scenario.

[0130] In an example embodiment, the target transaction data includes at least one of a resource type, object information, a resource quantity, and transaction information.

[0131] In an example embodiment, the verification scenario includes at least one of a resource liquidity verification scenario and a resource transaction mode verification scenario.

[0132] With regard to the apparatus in the above-described embodiments, the term "module" or "unit" refers to a computer program or a part of a computer program having a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented in whole or in part by using software, hardware such as a processing circuit or a memory, or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit. The specific manner in which the various modules perform operations has been described in detail in the embodiments related to the method, and will not be described in detail here.

[0133] According to yet another aspect of the embodiments of the present application, an electronic device is provided.

[0134] The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor is configured to perform the steps of any of the above method embodiments by the computer program. In an exemplary embodiment, the above electronic device can further include a transmission device connected to the processor and an input / output device connected to the processor. Specific examples in this embodiment can refer to the examples described in the above embodiments and exemplary implementation manners, which will not be described here again.

[0135] According to an aspect of the present application, a computer program product is also provided, which includes a computer program.

[0136] Figure 6 A computer system structure block diagram of an electronic device for implementing the embodiments of the present application is schematically shown. As shown in the figure, Figure 6 The computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to programs stored in a ROM 602 or programs loaded from a storage portion 608 to a RAM 603. In the random access memory 603, various programs and data required for system operation are also stored. The central processing unit 601, the read-only memory 602, and the random access memory 603 are connected to each other through a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0137] The computer program product includes computer programs / instructions containing program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit 601, various functions provided by the embodiments of the present application are performed. The above-mentioned sequence numbers of the embodiments of the present application are merely for description, and do not represent the advantages or disadvantages of the embodiments.

[0138] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a local area network card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as necessary. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 610 as necessary, so that a computer program read therefrom is installed in the storage section 608 as necessary.

[0139] The above-mentioned sequence numbers of the embodiments of the present application are merely for description, and do not represent the advantages or disadvantages of the embodiments.

[0140] In particular, according to the embodiments of the present application, the processes described in each of the method flowcharts can be implemented as computer programs / instructions. For example, the embodiments of the present application include a computer program / instruction including a computer program carried on a computer readable medium, which contains program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication section, and / or installed from the removable medium. When the computer program is executed by the central processing unit, various functions defined in the system of the present application are performed. In such embodiments, the computer program / instruction can be downloaded and installed from a network through the communication section, and / or installed from the removable medium. When the computer program / instruction is executed by the central processing unit, the above-mentioned verification method of transaction data is performed.

[0141] According to one aspect of the present application, a computer readable storage medium is also provided.

[0142] The processor of the electronic device can read the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the electronic device to perform the transaction data verification method provided in the various optional implementations of the transaction data verification aspect.

[0143] Optionally, in the embodiment, the computer readable storage medium can be configured to store the program for executing the method in the embodiments of the present application.

[0144] Optionally, in the embodiment, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiments can be completed by programs instructing the hardware of the terminal device, and the programs can be stored in a computer readable storage medium, which can include a flash disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0145] The serial numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0146] The integrated units in the above-mentioned embodiments, if realized in the form of software function units and sold or used as independent products, can be stored in the above-mentioned computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or the whole or part of the technical solutions can be embodied in the form of software products, and the computer software products are stored in the storage medium, including a plurality of instructions for enabling one or more electronic devices to execute all or part of the steps of the methods described in the embodiments of the present application.

[0147] In the several embodiments of the present application, it should be understood that the disclosed application programs can be implemented in other ways. Among them, the above-mentioned device embodiments are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutual units can be indirect coupling or communication connection through some interfaces, units or modules, and can be electrical or other forms.

[0148] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0149] In addition, each of the functional units in the various embodiments of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0150] The above is only the preferred embodiment of the present application, and it should be pointed out that, for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, which should be considered as the protection scope of the present application.

Claims

1. A method for verifying transaction data, characterized in that, include: Acquire target transaction data, wherein the target transaction data is used to execute cross-regional transaction operations; Multiple verification threads are set up according to multiple verification scenarios to be verified, wherein one verification thread corresponds to one verification scenario, and different verification scenarios require different target transaction data; Multiple verification threads are used to perform scenario verification operations on the target transaction data. During the multi-scenario verification operation on the target transaction data, in response to at least one verification thread receiving target abnormal data, an abnormal prompt message is generated. The target abnormal data is used to indicate that the transaction data required for any of the verification scenarios has failed the verification, and the abnormal prompt message is used to indicate the termination of the cross-regional transaction operation.

2. The method according to claim 1, characterized in that, The response to at least one of the verification threads receiving target abnormal data, generating an abnormal prompt message, includes: When the first verification thread receives the target abnormal data, it controls the first verification thread to generate the abnormal prompt message and sends the abnormal prompt message to the main control thread, wherein the first verification thread belongs to the verification thread; In response to the main control thread receiving the exception prompt message, an interrupt message is sent to the second verification thread to terminate the second verification thread from performing the scene verification operation. The second verification thread refers to the verification thread other than the first verification thread among the plurality of verification threads.

3. The method according to claim 2, characterized in that, Before the first verification thread generates the exception message and sends the exception message to the main control thread after receiving the target exception data, the method further includes: Generate the main control thread; The main control thread is controlled to generate multiple verification threads according to multiple verification scenarios.

4. The method according to claim 1, characterized in that, The method further includes: Scenario transaction data is determined from the target transaction data based on the target verification scenario; Set the target operation object according to the transaction data of the described scenario; Within the target method body, the scenario verification operation is performed on the target operation object, wherein the target method body belongs to the verification thread corresponding to the target verification scenario.

5. The method according to claim 1, characterized in that, The target transaction data includes at least one of the following: resource type, object information, resource quantity, and transaction information.

6. The method according to claim 1, characterized in that, The verification scenarios include at least one of the following: resource liquidity verification scenario and resource transaction mode verification scenario.

7. A device for verifying transaction data, characterized in that, include: An acquisition module is used to acquire target transaction data, wherein the target transaction data is used to execute cross-regional transaction operations; The setting module is used to set up multiple verification threads according to multiple verification scenarios to be verified, wherein one verification thread corresponds to one verification scenario, and different verification scenarios require different target transaction data; The execution module is used to perform scenario verification operations on the target transaction data using multiple verification threads. During the multi-scenario verification operation on the target transaction data, in response to at least one of the verification threads receiving target abnormal data, an abnormal prompt message is generated. The target abnormal data is used to indicate that the transaction data required for any of the verification scenarios has failed the verification, and the abnormal prompt message is used to indicate the termination of the cross-regional transaction operation.

8. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

Images