Transaction data processing method, apparatus, device, storage medium, and program product

CN119941402BActive Publication Date: 2026-09-25DAWNING INFORMATION IND (BEIJING) CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411854419.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-16
Publication Date
2026-09-25
Estimated Expiration
2044-12-16

AI Technical Summary

Technical Problem

[0003]然而,由于现有的对账系统仅能处理对平状态下的交易数据,即,仅能处理各交易端中交易结果均一致的交易数据(例如,各交易端内交易结果均成功/失败),会降低数据对账的效率

Benefits of technology

[0040]若否,则根据各系统交易结果,对各交易数据进行数据对账。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119941402B_ABST
    Figure CN119941402B_ABST
Patent Text Reader

Abstract

The application relates to a transaction data processing method, device, equipment, storage medium and program product. The method comprises the following steps: in response to a data reconciliation request of a target transaction, acquiring transaction data of the target transaction on each transaction system in a current collection period; when the system transaction results contained in the transaction data are not completely same, determining whether an abnormality exists in the execution process of the target transaction according to the system transaction results contained in the transaction data and a standard transaction result group corresponding to the target transaction, wherein each standard transaction result group comprises a standard transaction result of the target transaction under the condition that each transaction system is normally operated; and if not, performing data reconciliation on the transaction data according to the system transaction results. The method can improve the efficiency of data reconciliation.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a transaction data processing method, apparatus, device, storage medium, and program product. Background Technology

[0002] With the continuous development of online trading platforms, in order to ensure the reliability of transaction data on these platforms, reconciliation systems from the financial sector can be used to process the transaction data. Existing reconciliation systems, for each transaction, first need to collect transaction data from various transaction endpoints (e.g., the payment endpoint and the transaction endpoint), and then perform reconciliation processing based on this data.

[0003] However, existing reconciliation systems can only process transaction data in a balanced state, that is, they can only process transaction data in which the transaction results are consistent across all transaction terminals (e.g., all transaction results are successful / failed within each transaction terminal), which reduces the efficiency of data reconciliation. Summary of the Invention

[0004] Therefore, it is necessary to provide a transaction data processing method, apparatus, equipment, storage medium, and program product that can improve the efficiency of data reconciliation in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a transaction data processing method, including:

[0006] In response to a data reconciliation request for a target transaction, obtain the transaction data of the target transaction on each transaction system during the current collection period;

[0007] If the system transaction results contained in each transaction data are not completely identical, determine whether there are any abnormalities in the execution process of the target transaction based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction; wherein, each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are operating normally;

[0008] If not, then data reconciliation will be performed on each transaction based on the transaction results of each system.

[0009] In this embodiment of the application, a standard transaction result group is introduced to determine whether each transaction system is running normally during the execution of the target transaction, thereby reconciling the transaction data generated under normal operating conditions and improving the efficiency of data reconciliation.

[0010] In one embodiment, based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction, it is determined whether there is an anomaly in the execution process of the target transaction, including:

[0011] If the system transaction results contained in each transaction data match any standard transaction result group corresponding to the target transaction, it is determined that there are no abnormalities in the execution process of the target transaction.

[0012] In this embodiment of the application, by determining whether there are any abnormalities in the execution process of the target transaction based on the matching between the transaction results of each system and the standard transaction result group, the reliability of the identification of abnormal situations during the transaction execution process can be guaranteed.

[0013] In one embodiment, the method further includes:

[0014] Obtain the standard acceptance path for the target transaction; wherein, the standard acceptance path is determined based on the system acceptance order among the various transaction systems involved in the target transaction, as well as the internal transaction code of each transaction system; determine the standard transaction result group corresponding to the target transaction based on the system acceptance order in the standard acceptance path and the benchmark acceptance system in each transaction system; wherein, the benchmark acceptance system is the transaction system in which the transaction results in each transaction system can characterize the overall transaction result of the target transaction.

[0015] In this embodiment of the application, by determining the standard transaction result group corresponding to the target transaction based on the system acceptance order and the benchmark acceptance system, the rationality of the standard transaction result group can be guaranteed.

[0016] In one embodiment, data reconciliation is performed on the transaction data based on the transaction results of each system, including:

[0017] Obtain the data processing strategy associated with the standard transaction result group that matches the transaction results of each system; adopt the data processing strategy to perform consistency processing or transaction reversal processing on each transaction data; and perform data reconciliation on each processed transaction data.

[0018] In this embodiment of the application, by adopting a data processing strategy to perform consistency processing or transaction reversal processing on each transaction data, the rationality of data processing can be guaranteed, thereby ensuring the reliability of data reconciliation.

[0019] In one embodiment, if it is determined that the system transaction results contained in each transaction data are not completely identical, the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction are used to determine whether there is an anomaly in the execution process of the target transaction, including:

[0020] Based on the consistency between the transaction systems included in the standard transaction flow path corresponding to the target transaction and the transaction systems of the acquired transaction data, the data integrity of the target transaction is determined. If the data integrity is complete and it is determined that the system transaction results contained in each transaction data are not completely the same, based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction, it is determined whether there are any abnormalities in the execution process of the target transaction.

[0021] In this embodiment of the application, by determining the data integrity of the target transaction according to the standard transaction flow path, and if the transaction data is complete, determining whether there are any abnormalities in the execution process of the target transaction, the reasonableness of the determination of abnormalities in the execution process can be guaranteed.

[0022] In one embodiment, the method further includes:

[0023] If the data integrity is incomplete, the data acquisition time is determined based on the data upload cycle of the target trading system. The target trading system is the trading system other than the trading system in the standard trading flow path that acquires the transaction data. When the data acquisition time is reached, the transaction data of the target transaction is acquired from the target trading system and returned for execution. If the system transaction results contained in each transaction data are not completely the same, the execution process of the target transaction is determined to have any abnormal operations based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction.

[0024] In this embodiment of the application, by re-acquiring the transaction data of the target transaction from the target transaction system when the data acquisition time is reached, the transaction data of the target transaction in each transaction system is completed, thereby ensuring the rationality of data reconciliation.

[0025] Secondly, this application also provides a transaction data processing apparatus, comprising:

[0026] The data acquisition module is used to respond to data reconciliation requests for the target transaction and acquire the transaction data of the target transaction on various trading systems during the current collection period;

[0027] The anomaly detection module is used to determine whether there are any anomalies in the execution process of the target transaction when the system transaction results contained in each transaction data are not completely the same, based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction; wherein, each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are running normally;

[0028] The data reconciliation module is used to reconcile the transaction data of each system based on the transaction results if the transaction is not found to be true.

[0029] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0030] In response to a data reconciliation request for a target transaction, obtain the transaction data of the target transaction on each transaction system during the current collection period;

[0031] If the system transaction results contained in each transaction data are not completely identical, determine whether there are any abnormalities in the execution process of the target transaction based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction; wherein, each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are operating normally;

[0032] If not, then data reconciliation will be performed on each transaction based on the transaction results of each system.

[0033] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0034] In response to a data reconciliation request for a target transaction, obtain the transaction data of the target transaction on each transaction system during the current collection period;

[0035] If the system transaction results contained in each transaction data are not completely identical, determine whether there are any abnormalities in the execution process of the target transaction based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction; wherein, each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are operating normally;

[0036] If not, then data reconciliation will be performed on each transaction based on the transaction results of each system.

[0037] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0038] In response to a data reconciliation request for a target transaction, obtain the transaction data of the target transaction on each transaction system during the current collection period;

[0039] If the system transaction results contained in each transaction data are not completely identical, determine whether there are any abnormalities in the execution process of the target transaction based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction; wherein, each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are operating normally;

[0040] If not, then data reconciliation will be performed on each transaction based on the transaction results of each system.

[0041] The aforementioned transaction data processing method, apparatus, equipment, storage medium, and program product, in response to a data reconciliation request for a target transaction, acquires the transaction data of the target transaction on various transaction systems within the current collection period. If it is determined that the system transaction results contained in each transaction data are not entirely identical, it determines whether there are any anomalies in the execution process of the target transaction based on the system transaction results contained in each transaction data and the standard transaction result set corresponding to the target transaction. Subsequently, if there are no anomalies in the execution process, it performs data reconciliation on each transaction data based on the transaction results of each system. Compared to related technologies that can only perform data reconciliation on single reconciliation transaction data, the above method, by introducing a standard transaction result set to determine whether all transaction systems are operating normally during the execution of the target transaction, improves the efficiency of data reconciliation by performing data reconciliation on transaction data generated under normal operating conditions. Attached Figure Description

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

[0043] Figure 1 This is a flowchart illustrating a transaction data processing method in one embodiment;

[0044] Figure 2 This is a schematic diagram of the transaction flow in one embodiment;

[0045] Figure 3 This is a flowchart illustrating the process of determining a standard transaction result group in one embodiment;

[0046] Figure 4 This is a schematic diagram of the data reconciliation process in one embodiment;

[0047] Figure 5 This is a flowchart illustrating a transaction data processing method in another embodiment;

[0048] Figure 6 This is a structural block diagram of a transaction data processing device in one embodiment;

[0049] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] With the continuous development of online trading platforms, in order to ensure the reliability of transaction data on these platforms, reconciliation systems from the financial sector can be used to process the transaction data. Existing reconciliation systems, for each transaction, first need to collect transaction data from various transaction endpoints (e.g., the payment endpoint and the transaction endpoint), and then perform reconciliation processing based on this data.

[0052] However, existing reconciliation systems can only process transaction data in a balanced state, that is, they can only process transaction data in which the transaction results are consistent across all transaction terminals (e.g., all transaction results are successful / failed within each transaction terminal), which reduces the efficiency of data reconciliation.

[0053] Based on this, in an exemplary embodiment, such as Figure 1 As shown, a transaction data processing method is provided. Taking the application of this method to a data reconciliation device as an example, the method includes the following steps:

[0054] S101, in response to a data reconciliation request for the target transaction, obtains the transaction data of the target transaction on each transaction system during the current collection period.

[0055] Among them, the data reconciliation request is a request to reconcile the target transaction; the target transaction is any transaction with reconciliation requirements; the collection period is the period of time used to collect transaction data on each transaction system, which is divided based on a preset collection cycle; the current collection period is the sampling period that includes the current collection time.

[0056] Each trading system refers to the trading platform involved in the flow of the target transaction; transaction data refers to the data generated when the target transaction is executed on the trading system. For example, refer to... Figure 2 The diagram illustrates the transaction flow. In this diagram, sysA is the initiating system of transaction S (e.g., the user's terminal), sysB is the forwarding system of transaction S, sysC is the payment deduction core of transaction S (e.g., a bank), and sysD is the payment receiving core of transaction S (e.g., a merchant). Transaction S is sent from system sysA to system sysB, and sysB then requests sysC and sysD respectively, thus completing the execution of transaction S.

[0057] To ensure the timeliness of data reconciliation requests, a data reconciliation request for the target transaction can be automatically initiated after a preset interval following the occurrence of the target transaction; alternatively, a preset request initiation interval can be used to simultaneously initiate data reconciliation requests for all transactions within the transaction scenario in which the target transaction exists; or, the user can proactively initiate a data reconciliation request for the target transaction. This application does not impose specific restrictions on the method of initiating data reconciliation requests.

[0058] Upon detecting a data reconciliation request for a target transaction, in one possible implementation, the transaction systems associated with the target transaction can be identified based on the standard transaction flow path contained in the data reconciliation request. Subsequently, transaction data generated by the target transaction during the current collection period can be obtained from each transaction system based on the transaction identification information of the target transaction.

[0059] In another possible implementation, to improve the efficiency of data acquisition, for each transaction system, based on its internal data upload cycle, all transaction data generated within that system will be uniformly uploaded to the reconciliation device.

[0060] Furthermore, the reconciliation device can divide all transaction data based on the transaction identifier information of each transaction to obtain the transaction data under each transaction; then, it can use the transaction identifier information of the target transaction data in the data reconciliation request as an index to query the transaction data of each transaction to obtain the transaction data of the target transaction.

[0061] Understandably, to ensure transaction reliability, preprocessing can be performed on the transaction data after it is acquired. This could include, but is not limited to, checking transaction size, data security, the number of transaction records, and supplementing transaction headers. Furthermore, since transaction definitions may differ between components of the system, and unique transaction numbers may not be available, it is necessary to supplement the transaction data across systems.

[0062] S102, if it is determined that the system transaction results contained in each transaction data are not completely the same, determine whether there is any abnormality in the execution process of the target transaction based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction.

[0063] The so-called system trading result refers to the trading outcome within the trading system, which can be either successful or unsuccessful. The so-called standard trading result set is the combination of possible trading outcomes for the target trade across various trading systems when all systems are operating normally. In other words, each standard trading result set includes the standard trading results for the target trade under the condition that all trading systems are operating normally. It is understandable that the trading outcome under normal operating conditions can be either successful or unsuccessful.

[0064] After obtaining the transaction data from each trading system involved in the target exchange, for each transaction data, the system transaction result of the target transaction executed by the trading system where the transaction data is located can be obtained from that transaction data.

[0065] If it is determined that all transaction data contain identical system transaction results, it can be proven that the transaction data generated by the target transaction is reconciliation data. In this case, all transaction data of the target transaction can be written into the reconciliation file associated with the reconciliation data. Subsequently, for each transaction in the reconciliation file, data reconciliation can be performed based on the transaction log information in each transaction data of that transaction.

[0066] For example, if the target transaction is successful or unsuccessful in all trading systems, the transaction data of the target transaction can be written into the reconciliation file; then, a reconciliation device can be used to reconcile the transaction data of each transaction in the reconciliation file.

[0067] If it is determined that the system transaction results contained in each transaction data are not completely the same, there may be differences in system transaction results caused by anomalies in the transaction system, or differences in system transaction results caused by anomalies in the transaction itself.

[0068] Therefore, in order to determine the reason why the system transaction results are not completely the same, in one optional implementation, the system transaction results contained in each transaction data can be compared with the standard transaction result group generated by the target transaction under the condition that each transaction system is operating normally, so as to determine whether there is an anomaly in the execution process of the target transaction.

[0069] In another alternative implementation, for the transaction scenario in which the target transaction is located, an anomaly detection model can be pre-trained based on the standard transaction result group of the target transaction; accordingly, the system transaction results contained in each transaction data can be input into the anomaly detection model, and the anomaly detection model can output whether there is an anomaly in the execution process of the target transaction based on the system transaction results contained in each transaction data and the model parameters.

[0070] S103. If not, then reconcile the transaction data for each system based on the transaction results of each system.

[0071] In one possible implementation, if it is determined that all trading systems are operating normally when the target transaction is executed, the reasons for the inconsistency in the transaction results can be determined based on the transaction results of each system, thereby reconciling the transaction data.

[0072] For example, the cause of the anomaly can be used as an index to query from each candidate cause of the anomaly and the corresponding solution strategy to determine the target solution strategy; then, the target solution strategy can be used to process each transaction data, and the processed transaction data can be reconciled to obtain the data reconciliation result.

[0073] Understandably, in order to improve the efficiency of reconciliation, transaction data whose system transaction results are not completely the same, assuming that there are no abnormalities in the execution process of the target transaction, can be uniformly written into the normal inconsistency file; then, reconciliation equipment can be used to uniformly reconcile the transaction data in the normal inconsistency file.

[0074] After obtaining the data reconciliation results for each transaction, abnormal transactions with abnormal data reconciliation results can be reported to the auditing end to prompt the auditing end to handle the abnormal transactions, thereby ensuring the security and reliability of each transaction.

[0075] In the aforementioned transaction data processing method, in response to a data reconciliation request for the target transaction, the transaction data of the target transaction on each transaction system within the current collection period is obtained. If it is determined that the system transaction results contained in each transaction data are not entirely identical, the system transaction results contained in each transaction data and the standard transaction result set corresponding to the target transaction are used to determine whether there are any anomalies in the execution process of the target transaction. Subsequently, if there are no anomalies in the execution process, data reconciliation is performed on each transaction data based on the transaction results of each system. Compared to related technologies that can only perform data reconciliation on single reconciliation transaction data, the above method, by introducing a standard transaction result set to determine whether all transaction systems are operating normally during the execution of the target transaction, improves the efficiency of data reconciliation by performing data reconciliation on transaction data generated under normal operating conditions.

[0076] To ensure the accuracy of determining abnormal situations during the execution process, based on the above embodiments, this application provides an optional method for determining whether there are abnormalities in the execution process of a target transaction. Specifically, if the system transaction results contained in each transaction data match any standard transaction result group corresponding to the target transaction, it is determined that there are no abnormalities in the execution process of the target transaction.

[0077] Understandably, in order to ensure the standardization of standard transaction result groups, standard transaction result groups are generally generated based on the acceptance order of transactions across various transaction systems.

[0078] Based on this, in one optional implementation, the system transaction results of the target transaction on each transaction system can be combined first based on the acceptance order of the target transaction to obtain a group of transaction results to be verified; then, the group of transaction results to be verified can be compared with each standard group of transaction results for consistency.

[0079] If any standard transaction result set matches the transaction result set to be verified, it proves that the problem of inconsistent system transaction results in the target transaction is caused by the transaction itself, that is, there is no abnormality in the execution process of the target transaction; if none of the standard transaction result sets match the transaction result set to be verified, it proves that the problem of inconsistent system transaction results in the target transaction is caused by a system abnormality, that is, there is an abnormality in the execution process of the target transaction.

[0080] In this embodiment of the application, by determining whether there are any abnormalities in the execution process of the target transaction based on the matching between the transaction results of each system and the standard transaction result group, the reliability of the identification of abnormal situations during the transaction execution process can be guaranteed.

[0081] To ensure the rationality of the standard transaction result group, based on the above embodiments, this application provides an optional method for determining the standard transaction result group, such as... Figure 3 As shown, the specific steps include:

[0082] S301, the standard acceptance path for obtaining the target transaction.

[0083] The standard acceptance path is determined based on the system acceptance order among the various transaction systems involved in the target transaction, as well as the internal transaction codes of each transaction system. The internal transaction code is the unique identification information of each transaction system; the system acceptance order is the flow order of resources within the transaction system. For example, the order of deductions from accounts receivable.

[0084] Understandably, forked transactions (i.e., multiple systems processing different parts of the same transaction simultaneously) are common in existing reconciliation systems. However, the processing paths of forked transactions are difficult to track and reconcile using unified rules, which may lead to the loss of some transaction states or their inability to be updated correctly. For example, refer to... Figure 2 The diagram shows a transaction flow where transaction S is sent from sysB to both sysC and sysD simultaneously. However, existing systems often fail to accurately reflect this complex flow path.

[0085] Therefore, to more accurately reflect the transaction flow path, internal transaction codes can be added to each system. For example, a unified format can be used to add the internal transaction codes of the transaction system to the transaction data. For instance, [Source System ID: Internal Transaction Code] -> [Destination System ID: Internal Transaction Code].

[0086] For example, refer to Figure 2 The transaction flow diagram shown shows that the standard transaction flow path for transaction S is [sysA:Txn1]->[sysB:Txn2], [sysB:Txn2]->[sysC:Txn3], [sysB:Txn2]->[sysD:Txn4].

[0087] Correspondingly, the acceptance order of transaction S is sysC->sysD->sysB->sysA; further, based on the acceptance order, the internal transaction codes of each transaction system are added to generate the standard acceptance path of transaction S: [sysC:Txn3]->[sysD:Txn4]->[sysB:Txn2]->[sysA:Txn1].

[0088] In one alternative implementation, a standard acceptance path for the target transaction can be directly generated based on the acceptance order among the various trading systems of the target transaction and the internal transaction codes of each trading system.

[0089] In another alternative implementation, standard acceptance paths associated with each transaction scenario can be pre-configured based on the acceptance order of each transaction scenario and the internal transaction codes of the transaction systems involved in each transaction scenario.

[0090] After obtaining the scenario identifier of the target transaction corresponding to the transaction scenario from the data reconciliation request, the scenario identifier can be used as an index to query from the standard acceptance path associated with each transaction scenario to obtain the standard acceptance path of the target transaction.

[0091] S302, Based on the system acceptance sequence in the standard acceptance path and the benchmark acceptance system in each transaction system, determine the standard transaction result group corresponding to the target transaction.

[0092] The benchmark acceptance system is the transaction system within each transaction system whose transaction results can represent the overall transaction result of the target transaction. For example, the deduction transaction system within the target transaction can be used as the benchmark acceptance system for the target transaction. That is, if the deduction is successful, the target transaction can be considered as a whole successful.

[0093] Understandably, since the system acceptance sequence in the standard acceptance path can reflect the deduction progress to a certain extent, the standard transaction result group corresponding to the target transaction can be determined based on the system acceptance sequence and the benchmark acceptance system.

[0094] For example, given the system acceptance sequence sysC->sysD->sysB->sysA, if the system transaction result in sysB is successful, then under normal system operation, the system transaction results in sysC and sysD should also be successful.

[0095] In one alternative implementation, starting with setting the system transaction result of the benchmark acceptance system to success and setting the system transaction results of other transaction systems to failure, the system transaction results of other transaction systems can be set to success in sequence according to the system acceptance order to obtain the standard transaction result group corresponding to the target transaction.

[0096] For example, refer to Figure 2 The transaction flow diagram shown depicts the system acceptance sequence for transaction S as sysC->sysD->sysB->sysA, with sysC as the benchmark acceptance system. The standard transaction result group for transaction S can be presented using the following transaction result table. The transaction result table is referenced in Table 1 below.

[0097] Table 1 Transaction Results Table

[0098]

[0099] Each row in the transaction results table represents a standard transaction result group. The first standard transaction result group is {[sysC: Success]; [sysD: Failure]; [sysB: Failure]; [sysA: Failure]}; the second standard transaction result group is {[sysC: Success]; [sysD: Success]; [sysB: Failure]; [sysA: Failure]}; and the third standard transaction result group is {[sysC: Success]; [sysD: Success]; [sysB: Success]; [sysA: Failure]}.

[0100] In this embodiment of the application, by determining the standard transaction result group corresponding to the target transaction based on the system acceptance order and the benchmark acceptance system, the rationality of the standard transaction result group can be guaranteed.

[0101] To ensure the reliability of data reconciliation, based on the above embodiments, this application provides an optional data reconciliation method, such as... Figure 4 As shown, the specific steps include:

[0102] S401, Obtain the data processing strategy associated with the standard transaction result group that matches the transaction results of each system.

[0103] Among them, the data processing strategy refers to the method of processing transaction data.

[0104] Understandably, to improve data processing efficiency, in one optional implementation, data processing strategies corresponding to each standard transaction result group can be pre-configured. Then, using the system transaction results of the target transaction as an index, a search is performed within the data processing strategies corresponding to each standard transaction result group to obtain the data processing strategies associated with the standard transaction result groups that match each system transaction result.

[0105] For example, refer to Figure 2 The transaction flow diagram shown illustrates that the data processing strategies associated with each standard transaction result group of transaction S can be presented in the form of a processing strategy table. The processing strategy table is shown in Table 2 below.

[0106] Table 2 Processing Strategy Parameters

[0107]

[0108] S402 employs a data processing strategy to perform consistency processing or transaction reversal processing on each transaction data.

[0109] Among them, consistency processing means modifying the transaction results of each system to be consistent; transaction reversal processing means that, in the case of uncertainty about whether a transaction has been completed, in order to ensure the interests of users, the transaction record needs to be cancelled. If the benchmark acceptance system has successfully completed the transaction, the transaction is rolled back; if the benchmark acceptance system has failed the transaction, no processing is performed.

[0110] In one alternative implementation, after determining the data processing strategy corresponding to the target transaction, the data processing strategy can be adopted to perform consistency processing on the system transaction results of transaction data in each transaction data where the system transaction result is failed; or, transaction reversal processing can be performed on the benchmark transaction system.

[0111] For example, referring to Table 2 above, if the system transaction results of the target transaction are {[sysC: Success]; [sysD: Failure]; [sysB: Failure]; [sysA: Failure]}, there are too many failed transaction nodes. Therefore, in order to ensure the interests of users, sysC can be reversed, that is, the transaction flow of the target transaction on sysC can be canceled and the target transaction can be re-initiated.

[0112] If the system transaction results for the target transaction are {[sysC: Success]; [sysD: Success]; [sysB: Failure]; [sysA: Failure]}, since the target transaction has already been successful on the next transaction system of the benchmark acceptance system, the system transaction results of sysA and sysB can be directly set to success.

[0113] Similarly, if the system transaction results for the target transaction are {[sysC: Success]; [sysD: Success]; [sysB: Success]; [sysA: Failure]}, the system transaction result of sysA can be directly set to success.

[0114] S403 performs data reconciliation on the processed transaction data.

[0115] After processing the transaction data, in one optional implementation, a preset data reconciliation device can be used to reconcile the processed transaction data according to the transaction flow information in each transaction data to obtain the data reconciliation result.

[0116] In this embodiment of the application, by adopting a data processing strategy to perform consistency processing or transaction reversal processing on each transaction data, the rationality of data processing can be guaranteed, thereby ensuring the reliability of data reconciliation.

[0117] To ensure the reasonableness of determining abnormal situations during the execution process, based on the above embodiments, this application provides another optional method for determining whether there are abnormalities in the execution process of the target transaction. Specifically, the data integrity of the target transaction is determined based on the consistency between the transaction system included in the standard transaction flow path corresponding to the target transaction and the transaction system of each acquired transaction data. If the data integrity is complete and it is determined that the system transaction results contained in each transaction data are not completely the same, the execution process of the target transaction is determined based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction.

[0118] Understandably, due to the inconsistent data upload cycles of different trading systems, incomplete transaction data for a particular transaction may occur. In such cases, it is impossible to perform subsequent operations to determine whether there are any anomalies in the execution process of the target transaction. Therefore, after obtaining the transaction data of the target transaction on each trading system within the current collection period, it is necessary to verify the integrity of each transaction data.

[0119] In one possible implementation, the standard transaction flow path corresponding to the target transaction can be extracted from the data reconciliation request, and the transaction systems involved in the target transaction can be determined based on the standard transaction flow path. Subsequently, the transaction systems involved in the target transaction can be compared one by one with the transaction systems corresponding to the obtained transaction data.

[0120] If the trading systems involved in the target transaction are consistent with the trading systems corresponding to the obtained trading data, it proves that the obtained trading data of the target transaction is complete. At this time, you can refer to step S102 above. If it is determined that the system trading results contained in each trading data are not completely the same, you can determine whether there is any abnormality in the execution process of the target transaction based on the system trading results contained in each trading data and the standard trading result group corresponding to the target transaction.

[0121] If the trading systems involved in the target exchange are inconsistent with the trading systems corresponding to the obtained trading data, it proves that the obtained trading data of the target exchange is incomplete. In this case, the trading data of the target exchange can be written into a data missing file. After obtaining the missing trading data, the subsequent operation to determine whether there are any abnormalities in the execution process of the target exchange can be performed.

[0122] In this embodiment of the application, by determining the data integrity of the target transaction according to the standard transaction flow path, and if the transaction data is complete, determining whether there are any abnormalities in the execution process of the target transaction, the reasonableness of the determination of abnormalities in the execution process can be guaranteed.

[0123] To further ensure the rationality of data reconciliation, based on the above embodiments, this application embodiment provides an optional method for processing incomplete transaction data. Specifically, when the data integrity is incomplete, the data acquisition time is determined according to the data upload cycle of the target transaction system; when the data acquisition time is reached, the transaction data of the target transaction is acquired from the target transaction system, and the execution is returned. If the system transaction results contained in each transaction data are not completely the same, the execution process of the target transaction is determined to have any abnormal operations based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction.

[0124] The target trading system refers to the trading system other than the trading system that acquires the trading data in the standard trading flow path; the so-called data upload cycle is the preset cycle for the target trading system to upload trading data in batches.

[0125] It is understandable that missing transaction data could be due to the data upload time being later than the data retrieval time, or it could be due to data loss. If it is due to the data upload time being later than the data retrieval time, the missing transaction data can be retrieved again at the next data retrieval time; if it is due to lost transaction data, then data reconciliation cannot be performed.

[0126] Based on this, in one optional implementation, if the data integrity of the transaction data is determined to be incomplete, the target transaction system that has not acquired the transaction data can be identified from the various transaction systems involved in the standard transaction flow path; subsequently, the data acquisition time of the missing transaction data of the target exchange can be determined according to the data upload cycle configured by the target transaction system.

[0127] For example, the current acquisition time of transaction data within the current collection period can be added to the data upload cycle configured in the target transaction system to obtain the data acquisition time for reacquiring the missing transaction data.

[0128] When the data acquisition time arrives, the transaction data of the target transaction can be retrieved by querying the transaction data uploaded to the target transaction system based on the transaction identifier of the target transaction.

[0129] If the transaction data of the target transaction can be obtained from the target transaction system, the transaction data of the target transaction can be obtained from the target transaction system and aggregated with the other transaction data of the target transaction written to the missing data file; then, for the aggregated transaction data, referring to the above step S102, if it is determined that the system transaction results contained in each aggregated transaction data are not completely the same, it can be determined whether there is an anomaly in the execution process of the target transaction based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction.

[0130] If the transaction data for the target transaction cannot be obtained from the target transaction system, it proves that the missing transaction data is due to data loss. In this case, the transaction data for the target transaction can be written to a legacy file. The auditing department will then process the transaction data for each transaction in the legacy file uniformly.

[0131] In this embodiment of the application, by re-acquiring the transaction data of the target transaction from the target transaction system when the data acquisition time is reached, the transaction data of the target transaction in each transaction system is completed, thereby ensuring the rationality of data reconciliation.

[0132] Figure 5 This is a flowchart illustrating a transaction data processing method in another embodiment. Based on the above embodiments, this embodiment provides an optional example of a transaction data processing method. (In conjunction with...) Figure 5 The specific implementation process is as follows:

[0133] S501, the standard acceptance path for obtaining the target transaction.

[0134] The standard acceptance path is determined based on the system acceptance order among the various trading systems involved in the target transaction, as well as the internal transaction codes of each trading system.

[0135] S502, based on the system acceptance sequence in the standard acceptance path and the benchmark acceptance system in each transaction system, determine the standard transaction result group corresponding to the target transaction.

[0136] Among them, the benchmark acceptance system is a trading system in which the trading results of each trading system can characterize the overall trading results of the target transaction; each standard trading result group includes the standard trading results of the target transaction under the condition that each trading system is operating normally.

[0137] S503, in response to a data reconciliation request for the target transaction, retrieves the transaction data of the target transaction on each transaction system during the current collection period.

[0138] S504. Based on the consistency between the transaction system included in the standard transaction flow path corresponding to the target transaction and the transaction system of each acquired transaction data, determine whether the transaction data of the target transaction is complete. If yes, execute S507; otherwise, execute S505.

[0139] S505 determines the data acquisition time based on the data upload cycle of the target trading system.

[0140] The target trading system refers to the trading system other than the trading system that acquires the trading data in the standard trading flow path.

[0141] S506, when the data acquisition time is reached, retrieve the transaction data of the target transaction from the target transaction system and return to execute S504.

[0142] S507, determine whether the system transaction results contained in each transaction data are completely identical. If yes, execute S511; otherwise, execute S508.

[0143] S508: Based on the system transaction results and the standard transaction result group corresponding to the target transaction contained in each transaction data, determine whether there is any abnormality in the execution process of the target transaction. If yes, execute S509; otherwise, execute S510.

[0144] Optionally, if the system transaction results contained in each transaction data match any standard transaction result group corresponding to the target transaction, it can be determined that there are no abnormalities in the execution process of the target transaction.

[0145] S509, write the transaction data of the target transaction to the abnormal inconsistency file.

[0146] S510: Obtain the data processing strategy associated with the standard transaction result group that matches the transaction results of each system, and use the data processing strategy to perform consistency processing or transaction reversal processing on each transaction data.

[0147] S511 performs data reconciliation for each transaction.

[0148] The specific processes of S501-S511 described above can be found in the description of the above method embodiments. Their implementation principles and technical effects are similar, and will not be repeated here.

[0149] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0150] Based on the same inventive concept, this application also provides a transaction data processing apparatus for implementing the transaction data processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more transaction data processing apparatus embodiments provided below can be found in the limitations of the transaction data processing method described above, and will not be repeated here.

[0151] In one exemplary embodiment, such as Figure 6 As shown, a transaction data processing device 1 is provided, including: a data acquisition module 10, an anomaly detection module 20, and a data reconciliation module 30, wherein:

[0152] Data acquisition module 10 is used to respond to data reconciliation requests for the target transaction and acquire transaction data of the target transaction on various trading systems during the current collection period;

[0153] The anomaly detection module 20 is used to determine whether there is an anomaly in the execution process of the target transaction when the system transaction results contained in each transaction data are not completely the same, based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction; wherein, each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are running normally;

[0154] The data reconciliation module 30 is used to reconcile the transaction data of each system based on the transaction results if the transaction is not found to be true.

[0155] In an exemplary embodiment, the anomaly detection module 20 is specifically used for:

[0156] If the system transaction results contained in each transaction data match any standard transaction result group corresponding to the target transaction, it is determined that there are no abnormalities in the execution process of the target transaction.

[0157] In an exemplary embodiment, the transaction data processing apparatus 1 further includes a result group generation module, wherein the result group generation module is specifically used for:

[0158] Obtain the standard acceptance path for the target transaction; wherein, the standard acceptance path is determined based on the system acceptance order among the various transaction systems involved in the target transaction, as well as the internal transaction code of each transaction system; determine the standard transaction result group corresponding to the target transaction based on the system acceptance order in the standard acceptance path and the benchmark acceptance system in each transaction system; wherein, the benchmark acceptance system is the transaction system in which the transaction results in each transaction system can characterize the overall transaction result of the target transaction.

[0159] In one exemplary embodiment, the data reconciliation module 30 is specifically used for:

[0160] Obtain the data processing strategy associated with the standard transaction result group that matches the transaction results of each system; adopt the data processing strategy to perform consistency processing or transaction reversal processing on each transaction data; and perform data reconciliation on each processed transaction data.

[0161] In an exemplary embodiment, the anomaly detection module 20 is further configured to:

[0162] Based on the consistency between the transaction systems included in the standard transaction flow path corresponding to the target transaction and the transaction systems of the acquired transaction data, the data integrity of the target transaction is determined. If the data integrity is complete and it is determined that the system transaction results contained in each transaction data are not completely the same, based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction, it is determined whether there are any abnormalities in the execution process of the target transaction.

[0163] In an exemplary embodiment, the anomaly detection module 20 is further configured to:

[0164] If the data integrity is incomplete, the data acquisition time is determined based on the data upload cycle of the target trading system. The target trading system is the trading system other than the trading system in the standard trading flow path that acquires the transaction data. When the data acquisition time is reached, the transaction data of the target transaction is acquired from the target trading system and returned for execution. If the system transaction results contained in each transaction data are not completely the same, the execution process of the target transaction is determined to have any abnormal operations based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction.

[0165] Each module in the aforementioned transaction data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0166] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores transaction data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a transaction data processing method.

[0167] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0168] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0169] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0170] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0171] It should be noted that the data involved in this application (including but not limited to transaction data) is all data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0172] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0173] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0174] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for processing transaction data, characterized in that, The method includes: Obtain the standard acceptance path for the target transaction; wherein the standard acceptance path is determined based on the system acceptance order among the various transaction systems involved in the target transaction, and the internal transaction code of each transaction system; Based on the system acceptance sequence in the standard acceptance path and the benchmark acceptance system in each transaction system, a standard transaction result group corresponding to the target transaction is determined; wherein, the benchmark acceptance system is a transaction system in which the transaction results in each transaction system can characterize the overall transaction result of the target transaction; each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are operating normally; In response to a data reconciliation request for the target transaction, obtain the transaction data of the target transaction on each transaction system during the current data collection period; If the system transaction results contained in each transaction data are not completely identical, and if the system transaction results contained in each transaction data match any standard transaction result group corresponding to the target transaction, then it is determined that there is no abnormality in the execution process of the target transaction. Based on the transaction results of each system, data reconciliation is performed on each transaction.

2. The method according to claim 1, characterized in that, The process of reconciling transaction data based on the transaction results of each system includes: Obtain data processing strategies associated with standard transaction result groups that match the transaction results of each system; Using the aforementioned data processing strategy, consistency processing or transaction reversal processing is performed on each transaction data. Perform data reconciliation on the processed transaction data.

3. The method according to claim 1, characterized in that, When the system transaction results contained in each transaction data are not completely identical, the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction are used to determine whether there is an anomaly in the execution process of the target transaction, including: The data integrity of the target transaction is determined based on the consistency between the transaction system included in the standard transaction flow path corresponding to the target transaction and the transaction system of each acquired transaction data. If the data integrity is deemed complete and it is determined that the system transaction results contained in each transaction data are not entirely identical, then based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction, it is determined whether there is an anomaly in the execution process of the target transaction.

4. The method according to claim 3, characterized in that, The method further includes: In the case where the data integrity is incomplete, the data acquisition time is determined according to the data upload cycle of the target trading system; wherein, the target trading system is the trading system other than the trading system in the standard trading flow path that acquires each transaction data; When the data acquisition time is reached, the transaction data of the target transaction is obtained from the target transaction system. If the system transaction results contained in each transaction data are not completely the same, the execution process of the target transaction is determined to have any abnormal operations based on the system transaction results contained in each transaction data and the standard transaction result group corresponding to the target transaction.

5. A transaction data processing device, characterized in that, The device includes: The result group generation module is used to obtain the standard acceptance path of the target transaction; and determine the standard transaction result group corresponding to the target transaction based on the system acceptance order in the standard acceptance path and the benchmark acceptance system in each transaction system; wherein, the standard acceptance path is determined based on the system acceptance order among the transaction systems involved in the target transaction and the internal transaction code of each transaction system; the benchmark acceptance system is the transaction system whose transaction results in each transaction system can characterize the overall transaction result of the target transaction; each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are operating normally; The data acquisition module is used to respond to a data reconciliation request for the target transaction and acquire the transaction data of the target transaction on various transaction systems during the current collection period; The anomaly detection module is used to determine that, if the system transaction results contained in each transaction data are not completely identical, and if the system transaction results contained in each transaction data match any standard transaction result group corresponding to the target transaction, then it is determined that the execution process of the target transaction is not abnormal; wherein, the standard transaction result group is a combination of the possible transaction results of the target transaction on each transaction system when all transaction systems are in normal operating condition; each standard transaction result group includes the standard transaction results of the target transaction under the condition that all transaction systems are in normal operating condition; The data reconciliation module is used to reconcile the transaction data of each system based on the transaction results of each system.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, 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 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Citation Information

Patent Citations

  • Transaction flow account checking method, system and device and storage medium

    CN119107181A

  • Detection of Potential Abusive Trading Behavior in Electronic Markets

    US20150081505A1