Data checking method and system in cross-border payment service and electronic equipment

Abstract

The invention relates to a data checking method and system in a cross-border payment service and electronic equipment. The method may comprise the steps of obtaining a target payment event in a target cross-border payment service; obtaining a target checking rule corresponding to the target payment event; based on the target checking rule, determining a data type which needs to be subjected to data checking; obtaining business data corresponding to the target payment event from a plurality of data sources associated with the target cross-border payment business according to the data type; based on the target checking rule, checking the business data to obtain a checking result; and under the condition that the checking result represents that the business data is abnormal, performing early warning processing of data checking. According to the technical scheme provided by the invention, by defining the target payment event and the checking rule and combining multi-source data acquisition and automatic checking processing, the real-time performance and accuracy of the payment process can be improved, and the risk of occurrence of abnormal conditions is reduced, so that the overall operation efficiency and safety of the system are improved.

Description

Technical Field

[0001] The present disclosure relates to the field of data processing technology, and in particular to a data verification method, system and electronic device in a cross-border payment business. Background Art

[0002] In the process of global economic integration, with the continuous expansion of cross-border e-commerce, cross-border payment and other business scales, especially in the transaction scenario of B2B (Business-to-Business) cross-border payment, the payment between enterprises involves a large amount of capital flow, account processing, and cross-system data interaction, including log data, MQ (Message Queue) data, database data, etc. However, currently various types of data are usually stored in different systems or modules, and cross-system and cross-module data synchronization has problems such as insufficient real-time performance and difficulty in aligning time sequences, which makes it difficult to detect abnormal situations in time, thus affecting the overall operation of the system.

[0003] Secondly, the existing data verification methods mainly rely on manual or semi-automatic operation processes, which is not only time-consuming and labor-intensive, but also prone to data omissions or errors. Especially in the case of large amounts of data and frequent transactions, the efficiency of manual verification cannot meet the real-time requirements of high-frequency transactions, which can easily lead to the failure to discover abnormal situations in time, thus affecting business continuity and data accuracy.

[0004] In addition, data synchronization delays and consistency issues often occur between multiple systems involved in cross-border payment business. For example, data transmitted by message queues may not be processed in time, and operation records in the database may not match log data, which will affect the accuracy and reliability of the business. Summary of the invention

[0005] The present disclosure provides a data verification method, system and electronic device in a cross-border payment service, so as to at least solve the problem of how to improve the verification efficiency and accuracy of multi-source data in the related art. The technical solution of the present disclosure is as follows:

[0006] According to a first aspect of an embodiment of the present disclosure, a method for verifying data in a cross-border payment service is provided, comprising:

[0007] Obtaining a target payment event in a target cross-border payment business; the target payment event represents a payment process status in the target cross-border payment business;

[0008] Obtaining a target verification rule corresponding to the target payment event;

[0009] Based on the target verification rule, determine the data type that needs to be verified;

[0010] According to the data type, obtaining business data corresponding to the target payment event from multiple data sources associated with the target cross-border payment business; the multiple data sources correspond to the data type;

[0011] Based on the target verification rule, the business data is verified and processed to obtain a verification result; the verification result indicates whether the business data is abnormal;

[0012] When the verification result indicates that the business data is abnormal, early warning processing of the data verification is performed.

[0013] According to a second aspect of an embodiment of the present disclosure, a data verification system in a cross-border payment service is provided, including:

[0014] An event acquisition module, used to acquire a target payment event in a target cross-border payment business; the target payment event represents a payment process status in the target cross-border payment business;

[0015] A rule acquisition module, used to acquire a target verification rule corresponding to the target payment event;

[0016] A type determination module, used to determine the type of data that needs to be checked based on the target checking rule;

[0017] A data acquisition module, configured to acquire business data corresponding to the target payment event from a plurality of data sources associated with the target cross-border payment business according to the data type; the plurality of data sources correspond to the data type;

[0018] A data verification module, used to verify the business data based on the target verification rule to obtain a verification result; the verification result indicates whether the business data is abnormal;

[0019] The verification and early warning module is used to perform early warning processing of the data verification when the verification result indicates that the business data is abnormal.

[0020] According to a third aspect of an embodiment of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement a method as described in any one of the above-mentioned first aspects.

[0021] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute any method described in the first aspect of the embodiment of the present disclosure.

[0022] According to a fifth aspect of an embodiment of the present disclosure, a computer program product is provided, comprising computer instructions, which, when executed by a processor, enable a computer to execute any one of the methods described in the first aspect of an embodiment of the present disclosure.

[0023] The technical solution provided by the embodiments of the present disclosure brings at least the following beneficial effects:

[0024] By obtaining the target payment event in the target cross-border payment business and the target verification rule corresponding to the event, an adaptive verification standard can be set for each payment process state, thereby improving the pertinence and accuracy of data verification; based on the verification rules, the data type that needs to be verified is further determined, and the corresponding business data is obtained from multiple data sources associated with the target payment business, which can make the data collection process more efficient and improve the integrity and consistency of the data; by verifying and processing the obtained business data, the verification results are obtained, and early warning processing is carried out in time when data anomalies are detected, so as to quickly locate and solve potential problems in the cross-border payment process, improve the security and stability of the payment business, and effectively prevent business risks caused by data anomalies.

[0025] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description are used to explain the principles of the present disclosure, and do not constitute improper limitations on the present disclosure.

[0027] Figure 1 It is a schematic diagram of an application environment according to an exemplary embodiment.

[0028] Figure 2 It is a flow chart of a data verification method in a cross-border payment business according to an exemplary embodiment.

[0029] Figure 3 The figure is a flow chart of data verification according to an exemplary embodiment.

[0030] Figure 4 It is a block diagram of a data verification system in a cross-border payment business according to an exemplary embodiment.

[0031] Figure 5 It is a block diagram of an electronic device used for data verification in cross-border payment business according to an exemplary embodiment. DETAILED DESCRIPTION

[0032] In order to enable ordinary persons in the art to better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings.

[0033] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0034] See also Figure 1 , Figure 1 is a schematic diagram of an application environment according to an exemplary embodiment. Figure 1 As shown, the application environment may include multiple business systems 10 , a data verification system 20 and a terminal 30 .

[0035] The multiple business systems 10 may be multiple external systems related to cross-border payments, such as bank payment systems, third-party payment platforms, foreign exchange trading platforms, etc., for obtaining data related to cross-border payments. The data verification system 20 may obtain payment flow records, payment status updates, and log data provided by external systems in real time through the multiple business systems 10. The multiple business systems 10 may pass multi-source data to the data verification system 20 through APIs (application programming interfaces), message queues (such as Kafka, RabbitMQ, etc.) or other data transmission methods.

[0036] The data verification system 20 may include a data processing module 21, a data storage module 22, a rule management module 23, and an early warning processing module 24. The data processing module 21 is used to receive and parse payment data from multiple business systems 10, extract key fields, and match them with the verification rules in the rule management module 23, and convert them into a data format that can be used for verification. The data storage module 22 may be a relational database or a NoSQL database that supports the storage and rapid retrieval of large-scale data, and is used to store business data related to the target payment event, including original payment records, verification results, and abnormal records.

[0037] The rule management module 23 is used to store and manage the rule set for payment data verification, determine the correctness and consistency of payment data, and generate verification results. The early warning processing module 24 is used to generate and record early warning information when the verification result shows that the payment data is abnormal, and send the verification result generated by the data verification system 20 to the terminal 30, such as a CRM (Customer Relationship Management) system or an internal management system of an enterprise.

[0038] In an optional embodiment, multiple business systems 10, data verification systems 20 and terminals 30 can transmit data via a LAN (Local Area Network), a WAN (Wide Area Network) or a mobile data network connection based on 5G or 4G.

[0039] In addition, it should be noted that Figure 1 What is shown is merely one application environment of the data verification method in the cross-border payment business provided by the present disclosure.

[0040] In the embodiments of this specification, the server 01 and the terminal 02 may be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitation thereto.

[0041] It should be noted that the following figure shows a possible order of steps, which is not actually limited to this order. Some steps can be executed in parallel without relying on each other. The user information (including but not limited to user device information, user personal information, user behavior information, etc.) and data (including but not limited to data for display, training data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0042] Figure 2 FIG. 1 is a flow chart showing a method for verifying data in a cross-border payment service according to an exemplary embodiment. Figure 2 As shown, the following steps may be included.

[0043] In step S201, a target payment event in a target cross-border payment business is obtained.

[0044] In the embodiments of this specification, the target cross-border payment business may be a cross-border payment transaction involving multiple countries and regions, such as cross-border e-commerce transactions, international remittances, foreign exchange transactions, overseas travel payments, etc.

[0045] The target payment event may represent the payment process status in the target cross-border payment business. For example, the target payment event may include but is not limited to the payment request initiation status, payment processing status, payment completion status, payment failure status, refund processing status, settlement completion status, etc.

[0046] In a possible implementation, a data interface can be established with multiple business systems to obtain target payment events from bank payment systems, third-party payment platforms, and foreign exchange trading platforms. For example, when a user initiates a cross-border payment in a bank payment system, the bank payment system can generate a target payment event representing the initiation status of the payment request and pass it to the data verification system through an API.

[0047] In another possible implementation, the target payment event can be obtained through a message queue (such as Kafka, RabbitMQ, etc.). For example, when the status of the payment process changes, the third-party payment platform can publish the target payment event through the Kafka message queue, and the data verification system can subscribe to the message queue, and after receiving the target payment event, parse and record the status represented by the target payment event.

[0048] In an optional implementation, multiple business systems can also communicate with the data verification system through encrypted transmission protocols (such as HTTPS, SSL / TLS, etc.), which can prevent data from being intercepted or tampered with during the transmission process, thereby improving the accuracy and security of data verification.

[0049] In practical applications, different interfaces or message queues can be selected for data acquisition to achieve rapid data transmission and processing and improve the utilization efficiency of system resources.

[0050] In step S203, the target verification rule corresponding to the target payment event is obtained.

[0051] In the embodiments of this specification, the target verification rules may be a set of verification rules defined for different types of target payment events, which are used to accurately verify the data in the payment process. The target verification rules may include, but are not limited to, verification rules for verification fields, data consistency rules, and cross-system data comparison rules. The target verification rules can be implemented through a self-developed script tool, which can automatically modify the parameters of the verification rules based on the data analysis results.

[0052] In a possible implementation, the target verification rule matching the target payment event can be queried and obtained through the rule management module according to the type of the target payment event. For example, when the target payment event represents the payment completion status, the corresponding verification rule can be obtained according to the payment completion status query, and the verification rule includes verification requirements for fields such as payment time, amount, receiving account and exchange rate.

[0053] In another possible implementation, the target verification rule can be adaptively selected and adjusted based on the historical records and data analysis results of the target payment event. For example, when the target payment event represents a payment failure state, the weight or parameter configuration of the verification rule can be automatically adjusted by analyzing common problems in historical payment failure events to optimize the verification effect.

[0054] In an optional implementation, the target verification rules can also allow business personnel to customize the logic and parameter configuration of the verification rules according to different business needs, so as to flexibly update and adjust the target verification rules. For example, business personnel can use self-developed script tools to quickly write or modify target verification rules and update them to the data verification system in real time.

[0055] In actual applications, the selection and application of target verification rules can be optimized based on the type and source of the target payment event and the specific requirements of the payment process to improve the accuracy and efficiency of data verification. This rule management and adjustment process relies on the flexibility of the self-developed scripting tool, which enables the verification process to quickly respond to business changes.

[0056] In step S205, based on the target verification rule, the data type that needs to be verified is determined.

[0057] In the embodiments of this specification, the data type may be a data category related to the target payment event, and is used to support the data verification system to verify and analyze the target payment event.

[0058] In a possible implementation, the data types that need to be checked can be identified and determined from the business system related to the target payment event according to the requirements of the target verification rules. For example, when the target payment event represents the payment request initiation status, the log data associated with the status can be checked first to verify whether the timestamp of the payment request initiation, the request source IP and other information are accurate.

[0059] In an optional implementation, the data verification system may communicate through an interface with the business system and automatically determine the data type to meet the verification requirements of the target verification rules.

[0060] In practical applications, the data type can be flexibly selected and determined based on the type of target payment event and its corresponding target verification rule to improve the accuracy and efficiency of data type determination.

[0061] In step S207, based on the data type, business data corresponding to the target payment event is obtained from multiple data sources associated with the target cross-border payment business.

[0062] In the embodiments of this specification, the data source can be used to store, process or transmit data associated with the target payment event, including but not limited to the database server, log server or message queue server of the business system, etc. Multiple data sources correspond to data types, and different data sources provide different types of business data for the data verification system.

[0063] Business data refers to data content extracted from a data source and associated with a target payment event, including but not limited to target log data, target database data, target message queue data, etc., which is used to support the verification and analysis of target payment events.

[0064] In one possible implementation, collection agents can be deployed on key nodes of the business system (such as bank payment systems, foreign exchange trading platforms, payment gateways, etc.). The collection agents can be horizontally expanded as needed to ensure that data collection is stable even when business traffic is high. The collection agent on each node is responsible for collecting the local log data, database data, and message queue data in the message queue data of the node, and transmits the data to the data center through encrypted transmission protocols (such as HTTPS, SSL / TLS, etc.).

[0065] In a possible implementation, the most suitable data source node can be automatically matched by a distributed collection agent according to the data type. For example, when the data type is log data, the collection agent will obtain log data of the initiation, processing, and completion of payment requests from the log system connected to the bank payment system; and for exchange rate change messages in the message queue, they will be collected from the message queue data connected to the foreign exchange trading platform.

[0066] In an optional implementation, when data collection is interrupted at a node due to network fluctuation or short-term failure, the collection agent will automatically retry and synchronize the untransmitted data after the collection is successful to ensure the integrity of the business data.

[0067] In an optional implementation, through a distributed collection mechanism, data collection nodes can be dynamically increased or decreased according to business needs to adapt to business data collection needs at different stages. For example, during the peak payment period, the system can dynamically increase the number of collection nodes to ensure the stability of real-time data collection and transmission; when the data flow is low, the collection nodes can be reduced to save resources.

[0068] In actual applications, especially in high-concurrency scenarios of cross-border payment services, by deploying lightweight data collection agents on different system nodes, data can be transmitted to the data center in real time and stably for further processing and verification, which can effectively improve the efficiency and stability of data collection.

[0069] In one possible implementation, the data types include log data, database data, and message queue data; the multiple data sources include a log server, a database server, and a message queue server; the business data includes target log data, target database data, and target message queue data; the target log data corresponding to the target payment event is obtained from the log server; the target database data corresponding to the target payment event is obtained from the database server; and the target message queue data corresponding to the target payment event is obtained from the message queue server.

[0070] In the embodiments of this specification, the log server may be a server for storing and managing log data related to the target payment event. For example, when the target payment event involves operations such as the initiation, processing, and completion of a payment request, the log server will record detailed information of these operations, including timestamps, request source IP addresses, payment status, etc.

[0071] The target log data may be log records extracted from a log server and directly associated with a target payment event.

[0072] The database server may be a server for storing core data of payment services, such as payment transaction records, user information, payment amounts, and payment accounts.

[0073] The target database data may be database data related to the target payment event obtained from the database server, including payment amount, payment account information, etc.

[0074] The message queue server can be a server used to transmit message queue data between different business systems, and is usually used to asynchronously transmit dynamic information such as payment status and exchange rate updates. For example, when the target payment event involves changes in cross-border payment exchange rates, the foreign exchange trading platform can transmit the corresponding exchange rate update information to the data verification system through the message queue server.

[0075] The target message queue data may be message queue data related to the target payment event obtained from the message queue server.

[0076] In a possible implementation, the data type related to the target payment event can be identified according to the target verification rule, and the business data of the target payment event can be obtained through the interface with the log server, database server and message queue server.

[0077] In one possible implementation, event time information is obtained based on a target payment event; and based on the event time information, business data matching the time represented by the event time information is acquired from multiple data sources associated with the target cross-border payment business.

[0078] In the embodiments of this specification, the event time information may be one or more time points associated with the target payment event, such as the initiation time of the payment request, the completion time of the payment processing, etc.

[0079] In a possible implementation, after receiving the target payment event, the event time information of the event is parsed, such as the time when the payment request is initiated or the time when the processing is completed. Based on this time information, the corresponding business data can be obtained from the log server, database server and message queue server.

[0080] In step S209, based on the target verification rule, the business data is verified to obtain a verification result;

[0081] In the embodiments of this specification, the verification result may indicate whether the business data is abnormal. For example, the verification result may include whether the data content is complete, whether the data format is correct, whether the payment amount is consistent with the record, whether the payment status matches the actual transaction situation, etc.

[0082] In one possible implementation, the target log data obtained from the log server is checked item by item according to the target verification rules, for example, checking whether the time of the payment request is in line with expectations and whether there are any missing status records of the payment process; checking the target database data obtained from the database server to verify the accuracy of data such as the payment amount and the receiving account information; analyzing the target message queue data obtained from the message queue server to confirm whether the messages related to the target payment event are sent at the correct time and whether the exchange rate change information is reasonable.

[0083] In actual applications, the target verification rules can be flexibly set according to the verification requirements of different target payment events. For high-risk target payment events, the verification of log data and message queue data can be strengthened to improve the accuracy and comprehensiveness of the verification.

[0084] In a possible implementation, the business data is parsed and converted into a target object in a target conversion format; based on a target verification rule, a target item that needs to be verified is obtained; and the target object is verified according to the target item.

[0085] In the embodiments of this specification, the target conversion format may be a data format after standardizing business data from different sources that is adapted to the target verification rules. For example, the payment time information in log data, database data, and message queue data is uniformly converted into the ISO time format, so that the time information from different data sources can be directly compared during the verification process.

[0086] The target object can be a data entity processed according to the target conversion format, such as a standardized data structure containing fields such as payment request time, payment amount, user information, etc. The target object can directly participate in the verification process and is an object for unified management and operation of payment data in different data sources.

[0087] The target item can be a data field or attribute that needs to be verified, such as payment amount, transaction status, timestamp, etc. The target item belongs to the target object and is compared and verified according to the target verification rules during the verification process.

[0088] In one possible implementation, after receiving the target payment event, the business data is parsed and the log data, database data and message queue data are converted into standardized objects in the target conversion format. Based on the target verification rules, the items that need to be verified are identified, such as "payment amount consistency" or "payment status integrity". According to the target items, the standardized target objects are checked item by item to ensure that the time, amount and status of the payment request are consistent between different data sources.

[0089] For example, when checking the "payment amount consistency" item, the payment amount field is extracted from the target object, and the amount values ​​in the log data, database data, and message queue data are compared to see if they are consistent. If there is an inconsistency in the amount field, the verification result will indicate that the data of the target payment event is abnormal.

[0090] In actual applications, the structure of the target conversion format and the content of the verification items can be adjusted according to the target payment events and the needs of cross-border payment business to improve the accuracy and efficiency of the verification process.

[0091] In one possible implementation, the target items include a first item, a second item, and a third item; the target log data, the target database data, and the target message queue data are paired in pairs to obtain a first data group, a second data group, and a third data group; based on the target verification rules, a first item that requires data verification on the first data group, a second item that requires data verification on the second data group, and a third item that requires data verification on the third data group are obtained.

[0092] In the embodiment of this specification, the first item, the second item and the third item may be items to be checked for different data groups respectively.

[0093] The first data group may include target log data and target database data; the second data group may include target log data and target message queue data; and the third data group may include target database data and target message queue data.

[0094] In one possible implementation, after receiving the target payment event, the system will obtain business data from different data sources (such as log server, database server, message queue server), and pair these data based on the target verification rules to form three data groups.

[0095] In one possible implementation, the first item is to check whether the payment timestamp in the log is consistent with the record in the database; compare whether the payment amount in the log is consistent with the amount stored in the database; and verify whether the user information in the log record matches the corresponding field in the database data.

[0096] For example, when a payment request is recorded in the log at 12:01, but the database data is at 12:05, and the amount is different, the system will mark it as abnormal. This kind of verification can quickly find the time or amount inconsistency between the log record and the database data, and trigger subsequent processing in time.

[0097] In another possible implementation, the second project is to verify the synchronization of payment status updates in the log and the message queue; compare whether the status changes in the payment process are consistent in the log and message queue data, such as the status updates of "payment successful" or "payment failed"; and check whether the operation records in the log can find the corresponding messages in the message queue.

[0098] For example, when the log records the status of "payment successful", but the corresponding status change message is not found in the message queue, the system will mark this as an exception.

[0099] In another possible implementation, the third item is to verify whether the transaction information recorded in the database is consistent with the payment message in the message queue; compare whether the payment time of the database data is consistent with the timestamp transmitted by the message queue; and verify whether the payment status in the database is consistent with the message status in the message queue.

[0100] Exemplarily, when the exchange rate information transmitted in the message queue is different from the exchange rate value stored in the database, the system will mark it as abnormal.

[0101] In actual applications, by pairing the target log data, target database data, and target message queue data, the correctness of the target payment event can be verified from multiple angles (timestamp, payment amount, or status update). By performing verification processing between different data sources, problems such as data inconsistency or information loss can be more accurately identified, effectively responding to data interactions involving multiple business systems, and ensuring data consistency between various systems.

[0102] In a possible implementation, a first verification process and a second verification process are performed on the business data based on the target verification rule to obtain a verification result; the verification result includes an abnormal result; the abnormal result includes a first abnormal result or a second abnormal result.

[0103] In the embodiments of this specification, the first verification process may refer to checking whether the business data matches the target payment event, for example, checking whether the timestamp of the payment request is consistent with the received time, and whether the transaction amount is as expected.

[0104] The second verification process may refer to checking whether the information in the business data is erroneous or missing, such as verifying the completeness of payment status updates or the accuracy of exchange rate change information.

[0105] The first abnormal result may indicate that the business data does not match the target payment event, such as the payment amount does not match the actual transaction amount, or the payment time information has a large deviation; the second abnormal result may indicate that there are errors or data loss in the business data, such as missing payment status update records, or related exchange rate data cannot be successfully stored.

[0106] In a possible implementation, after receiving the target payment event, relevant business data is obtained from different data sources, and the first verification process and the second verification process are automatically performed according to the preset target verification rules. After the verification is completed, according to the type of the verification result (i.e., the first abnormal result or the second abnormal result), corresponding abnormal information is generated and the corresponding abnormal processing flow is triggered.

[0107] In practical applications, through the two-step verification of the first verification process and the second verification process, abnormal data in the payment process can be effectively identified, and problems such as data inconsistency or information loss that may exist in the system can be discovered in a timely manner, thereby generating abnormal results. According to the type of abnormal result, corresponding corrective measures can be taken to improve data verification accuracy and payment security in cross-border payment scenarios.

[0108] In step S211, when the verification result indicates that the business data is abnormal, early warning processing of data verification is performed.

[0109] In the embodiments of this specification, the warning processing may include a variety of measures, such as sending an exception notification, generating an early warning log, automatically marking abnormal data, and recording the specific time when the exception occurred and related business information.

[0110] In one possible implementation, the exception information can be sent to the system terminal or email of the relevant operation and maintenance personnel in real time according to the configuration of different types of exceptions and verification rules, so as to ensure that the operation and maintenance personnel can understand and handle the data anomalies in a timely manner. For example, when an anomaly occurs, the appropriate notification method (such as SMS, email, Feishu, WeChat, etc.) can be automatically selected, and the preset notification strategy can be used to determine whether multiple notification methods are needed at the same time to improve the timeliness and coverage of the warning information.

[0111] In another possible implementation, the selection criteria of the notification method can be flexibly adjusted according to different business needs. For serious anomalies in the verification results (such as inconsistent payment amounts, abnormal payment status, or logical errors in the transaction process, etc.), high-risk information can be sent to relevant persons in charge according to the early warning configuration, and the speed of information transmission can be ensured through expedited notification methods (such as a combination of SMS + email). At the same time, an early warning log is automatically generated to record the specific type and data source of the anomaly, and the log is stored in the designated early warning log database for subsequent analysis and tracking.

[0112] In an optional implementation, an automated early warning response mechanism may be further implemented for high-risk anomalies in the verification results, such as those involving high-amount payment anomalies or payment anomalies involving high-risk accounts. For example, when such high-risk anomalies are detected, the relevant payment operations may be automatically suspended, the abnormal accounts may be locked, and the system's built-in security policies may be triggered to restrict the conduct of relevant transactions, thereby preventing the spread of potential risks at the first opportunity.

[0113] In actual applications, the scalability of notifications enables the system to automatically select the most appropriate notification method based on different types of exceptions and business needs. Combined with the multi-level mechanism of early warning processing, it can effectively improve the system's ability to respond to abnormal data and ensure that early warning information can be conveyed to relevant personnel in a timely manner, thereby reducing the risks and impacts that data anomalies may have on the payment process.

[0114] In a possible implementation, there are multiple data types; when the business data does not include at least one data type, early warning processing of data verification is performed.

[0115] In one possible implementation, when a data type is detected missing in business data, such as log data or message queue data, an early warning log can be automatically generated and stored in a designated early warning log database, recording the type, source and timestamp information of the missing data in the early warning log.

[0116] In another possible implementation, when the type of data missing in the business data may have a significant impact on the subsequent verification results, the current payment operation process can be suspended and the relevant payment account can be locked to avoid the spread of potential risks caused by missing data. At the same time, an early warning report of missing data can be generated and pushed to the exception management module for further analysis and processing by relevant personnel.

[0117] In practical applications, early warning processing of the integrity of business data types can effectively improve the system's ability to respond to data anomalies. Especially for business scenarios involving multiple data types, this early warning mechanism can take timely measures at the early stage of data loss to prevent data loss from having a greater impact on business processes, thereby improving the overall verification processing accuracy and data management reliability.

[0118] For example, Figure 3 For example, Figure 3 is a flowchart of a data verification according to an exemplary embodiment. Obtain the target payment event (i.e. Figure 3 Get the target payment event in the target payment event), get the target verification rule corresponding to the target payment event (i.e. Figure 3 Based on the target verification rules, determine the data type that needs to be verified (i.e. Figure 3 The data types are various and may include log data, database data, and message queue data. Based on the target verification rules, the target items that need to be verified are obtained (i.e. Figure 3The data type corresponds to multiple data sources, which may include a log server, a database server, and a message queue server. Business data matching the time represented by the event time information is obtained from multiple data sources associated with the target cross-border payment business (i.e. Figure 3 In the process of obtaining business data that matches event time information from multiple data sources). If the business data does not include at least one data type, perform early warning processing for data verification; if not, parse the business data and convert the business data into a target object in the target format (i.e. Figure 3 The target object is converted into the target conversion format), and the target object is verified according to the target project to check whether the business data matches the target payment event and whether the information in the business data is wrong or missing, and obtain the verification result. If the verification result indicates that the business data is abnormal, an early warning is carried out. If not, it means that the business data is normal.

[0119] Figure 4 This is a block diagram of a data verification system in a cross-border payment service according to an exemplary embodiment. Figure 4 , the system may include:

[0120] An event acquisition module 401 is used to acquire a target payment event in a target cross-border payment business; the target payment event represents a payment process status in the target cross-border payment business;

[0121] A rule acquisition module 403 is used to acquire a target verification rule corresponding to the target payment event;

[0122] A type determination module 405 is used to determine the type of data that needs to be checked based on the target checking rule;

[0123] A data acquisition module 407 is used to acquire business data corresponding to the target payment event from multiple data sources associated with the target cross-border payment business according to the data type; the multiple data sources correspond to the data type;

[0124] The data verification module 409 is used to verify the business data based on the target verification rule to obtain a verification result; the verification result indicates whether the business data is abnormal;

[0125] The verification and early warning module 411 is used to perform early warning processing of the data verification when the verification result indicates that the business data is abnormal.

[0126] In a possible implementation, the data verification module 409 includes:

[0127] A data parsing unit, used for parsing the business data and converting the business data into a target object in a target conversion format; the target conversion format is adapted to the target verification rule;

[0128] A project determination unit, configured to obtain a target project that needs to undergo data verification based on the target verification rule; the target project belongs to the target object;

[0129] A project verification unit is used to verify the target object according to the target project.

[0130] In a possible implementation, the target project includes a first project, a second project, and a third project; the business data includes target log data, target database data, and target message queue data; and may also include:

[0131] a data pairing unit, configured to pair the target log data, the target database data, and the target message queue data in pairs to obtain a first data group, a second data group, and a third data group; the first data group includes the target log data and the target database data; the second data group includes the target log data and the target message queue data; the third data group includes the target database data and the target message queue data;

[0132] Project identification unit, including:

[0133] The project determination subunit is used to obtain the first project that needs to perform the data verification on the first data group, the second project that needs to perform the data verification on the second data group, and the third project that needs to perform the data verification on the third data group based on the target verification rule.

[0134] In a possible implementation, the data verification module 409 includes:

[0135] A verification processing unit is used to perform a first verification process and a second verification process on the business data based on the target verification rule to obtain a verification result; the first verification process refers to checking whether the business data matches the target payment event; the second verification process refers to checking whether the information in the business data is erroneous or missing; the verification result includes an abnormal result; the abnormal result includes a first abnormal result or a second abnormal result.

[0136] In a possible implementation, the data type is multiple and may also include:

[0137] An early warning unit is used to perform early warning processing of the data verification when the business data does not include at least one of the data types.

[0138] In a possible implementation, the data acquisition module 407 includes:

[0139] A time information acquisition unit, used to obtain event time information based on the target payment event;

[0140] A business data acquisition unit is used to acquire, based on the event time information, the business data that matches the time represented by the event time information from multiple data sources associated with the target cross-border payment business.

[0141] In a possible implementation, the multiple data sources include a log server, a database server, and a message queue server; the business data includes target log data, target database data, and target message queue data;

[0142] The business data acquisition unit includes:

[0143] A log data acquisition subunit, used to acquire target log data corresponding to the target payment event from the log server;

[0144] A database data acquisition subunit, used for acquiring target database data corresponding to the target payment event from the database server;

[0145] The message queue data acquisition subunit is used to acquire the target message queue data corresponding to the target payment event from the message queue server.

[0146] Regarding the system in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0147] Figure 5 is a block diagram of an electronic device for data verification in a cross-border payment business according to an exemplary embodiment. The electronic device may be a server terminal, and its internal structure diagram may be as shown in FIG. Figure 5As shown. The electronic device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the electronic device is used to provide computing and control capabilities. When the processor executes the computer program stored in the memory, it can realize the acquisition, processing and verification of log data, database data and message queue data. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The non-volatile storage medium stores an operating system and a computer program for data verification in a cross-border payment business. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium to support the verification task. The network interface of the electronic device is used to communicate with an external terminal (such as a log server, a database server, a message queue server, etc.) through a network connection, so as to obtain relevant data in the cross-border payment business in real time and perform data verification tasks. When the computer program is executed by the processor, a method for data verification in a cross-border payment business is implemented. The display screen of the electronic device can be a liquid crystal display screen or an electronic ink display screen, which is used to display the verification results and abnormal prompt information. The input device of the electronic device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the electronic device housing, or an external keyboard, touchpad or mouse.

[0148] Those skilled in the art will understand that Figure 5 The structure shown in the figure is merely a block diagram of a partial structure related to the scheme of the present disclosure, and does not constitute a limitation on the electronic device to which the scheme of the present disclosure is applied. The specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0149] In an exemplary embodiment, an electronic device is also provided, comprising: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement a data verification method in a cross-border payment business as in an embodiment of the present disclosure.

[0150] In an exemplary embodiment, a computer-readable storage medium is also provided, and when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the data verification method in the cross-border payment business in the embodiment of the present disclosure. The computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0151] In an exemplary embodiment, a computer program product containing instructions is also provided, which, when executed on a computer, enables the computer to execute the method for data verification in a cross-border payment business in the embodiment of the present disclosure.

[0152] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0153] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.

[0154] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A data verification method in a cross-border payment service, characterized in that: The method comprises: Obtaining a target payment event in a target cross-border payment business; the target payment event represents a payment process status in the target cross-border payment business; Obtaining a target verification rule corresponding to the target payment event; Based on the target verification rule, determine the data type that needs to be verified; According to the data type, obtaining business data corresponding to the target payment event from multiple data sources associated with the target cross-border payment business; the multiple data sources correspond to the data type; Based on the target verification rule, the business data is verified and processed to obtain a verification result; the verification result indicates whether the business data is abnormal; When the verification result indicates that the business data is abnormal, early warning processing of the data verification is performed.

2. The method according to claim 1, characterized in that The checking and processing of the business data based on the target checking rule includes: Parsing the business data, converting the business data into a target object in a target conversion format; the target conversion format is adapted to the target verification rule; Based on the target verification rule, a target item that needs to be subjected to the data verification is obtained; the target item belongs to the target object; The target object is checked and processed according to the target item.

3. The method according to claim 2, characterized in that The target project includes a first project, a second project and a third project; the business data includes target log data, target database data and target message queue data; the method further includes: The target log data, the target database data and the target message queue data are paired in pairs to obtain a first data group, a second data group and a third data group; the first data group includes the target log data and the target database data; the second data group includes the target log data and the target message queue data; the third data group includes the target database data and the target message queue data; The target items that need to be checked for the data are obtained based on the target checking rules, including: Based on the target verification rule, the first item requiring data verification on the first data group, the second item requiring data verification on the second data group, and the third item requiring data verification on the third data group are obtained.

4. The method according to claim 1, characterized in that: The business data is checked based on the target checking rule to obtain the checking result, including: Based on the target verification rules, the business data is subjected to a first verification process and a second verification process to obtain a verification result; the first verification process refers to checking whether the business data matches the target payment event; the second verification process refers to checking whether the information in the business data is erroneous or missing; the verification result includes an abnormal result; the abnormal result includes a first abnormal result or a second abnormal result.

5. The method according to claim 1, characterized in that: The data types are multiple; before the step of checking the business data based on the target checking rule to obtain the checking result, the method further includes: In the case that the business data does not include at least one of the data types, early warning processing of the data verification is performed.

6. The method according to claim 1, characterized in that The acquiring the business data corresponding to the target payment event from a plurality of data sources associated with the target cross-border payment business includes: Based on the target payment event, obtaining event time information; According to the event time information, the business data that matches the time represented by the event time information is obtained from multiple data sources associated with the target cross-border payment business.

7. The method according to claim 1, characterized in that The data types include log data, database data and message queue data; the multiple data sources include log servers, database servers and message queue servers; The acquiring business data corresponding to the target payment event from multiple data sources associated with the target cross-border payment business includes: Obtaining target log data corresponding to the target payment event from the log server; Acquire target database data corresponding to the target payment event from the database server; Obtain target message queue data corresponding to the target payment event from the message queue server.

8. A data verification system in cross-border payment business, characterized in that: include: An event acquisition module is used to acquire target payment events in target cross-border payment services; The target payment event represents the payment process status in the target cross-border payment business; A rule acquisition module, used to acquire a target verification rule corresponding to the target payment event; A type determination module, used to determine the type of data that needs to be checked based on the target checking rule; A data acquisition module, configured to acquire business data corresponding to the target payment event from a plurality of data sources associated with the target cross-border payment business according to the data type; the plurality of data sources correspond to the data type; A data verification module, used to verify the business data based on the target verification rule to obtain a verification result; The verification result indicates whether the business data is abnormal; The verification and early warning module is used to perform early warning processing of the data verification when the verification result indicates that the business data is abnormal.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; Wherein, the processor is configured to execute the instructions to implement the data verification method in the cross-border payment business as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the data verification method in a cross-border payment business as described in any one of claims 1 to 7.

11. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by the processor, the data verification method in the cross-border payment business described in any one of claims 1 to 7 is implemented.

Images