Reconciliation method and device based on block chain, storage medium and electronic equipment
By using a blockchain-based reconciliation method, which utilizes spatiotemporal attribute sharding and smart contract detection, the problems of reconciliation timeliness and operational risk in the bank payment and clearing system have been solved, achieving efficient and accurate reconciliation processing.
Patent Information
- Application Number
- CN202511056577.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-30
- Publication Date
- 2025-10-31
AI Technical Summary
In the payment and settlement systems of banks and financial institutions, existing technologies require daily reconciliation mechanisms to compare each transaction, which is not timely and has problems with operational risks and low processing efficiency.
A blockchain-based reconciliation method is adopted, which receives transaction flow data, performs sharding based on spatiotemporal attributes, and uses smart contracts to detect reconciliation anomalies and handle adjustments, including the generation of sharded datasets, reconciliation operations, and adjustment operations.
It improved the timeliness and accuracy of reconciliation, reduced the risk of human intervention, and achieved efficient reconciliation processing.
Smart Images
Figure CN120873084A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a blockchain-based reconciliation method, apparatus, storage medium, and electronic device. Background Technology
[0002] In the payment and settlement systems of financial institutions such as banks and UnionPay, transaction flows generated through channels such as ATMs, POS machines, and online payments need to be secured through end-of-day reconciliation mechanisms to ensure fund security.
[0003] Typically, all transaction data for the day needs to be summarized, and then the reconciliation party needs to compare each transaction one by one the next day, which is not very timely. When there are anomalies such as overages or underages in the transaction data, manual intervention is required to verify the reasons for the discrepancies and perform adjustment operations, which poses operational risks and has low processing efficiency. Summary of the Invention
[0004] The technical problem this application aims to solve is to provide a blockchain-based reconciliation method, apparatus, storage medium, and electronic device that can efficiently achieve reconciliation. The specific solution is as follows:
[0005] A blockchain-based reconciliation method, applied to data processing nodes in a blockchain, the method comprising:
[0006] Receive transaction log data sent by transaction nodes at all levels of the bank;
[0007] Based on the spatiotemporal attributes of the transaction data, the transaction data is segmented to generate a segmented dataset.
[0008] Perform reconciliation processing on the transaction data within the aforementioned sharded dataset;
[0009] In response to the detection of target transaction data with reconciliation anomalies in the sharded dataset, the smart contract is triggered to match the target transaction data with preset rules. If the match with the preset rules is successful, the target transaction data is adjusted.
[0010] Optionally, the above method, based on the spatiotemporal attributes of the transaction flow data, performs sharding processing on the transaction flow data to generate a sharded dataset, including:
[0011] The transaction log data is preprocessed to obtain multiple standard transaction data.
[0012] Extract the spatiotemporal attributes from each of the standard transaction data;
[0013] Feature encoding is performed on each standard transaction data according to its spatiotemporal attributes and proportion parameters to generate a composite sharding factor for each standard transaction data. The proportion parameters are determined based on the real-time system load monitoring results of the data processing node.
[0014] Based on the composite sharding factor of each standard transaction data, the data shard to which each standard transaction data belongs is determined to generate a sharded dataset.
[0015] Optionally, in the above method, the reconciliation processing of transaction data within the sharded dataset includes:
[0016] For each shard in the transaction dataset, a reconciliation operation is performed on each transaction data in the shard to detect whether there is first one-sided account data in the shard. If the first one-sided account data exists in the shard, the shard is determined as the first target shard.
[0017] Identify a second target segment that is within the same target range as each of the first target segments; the target range is at least one of a time range and a spatial range; merge the first target segments and the second target segments to obtain a merged segment; perform a reconciliation operation on the first unilateral ledger data in the merged segment to determine whether there is second unilateral ledger data in each of the first unilateral ledger data in the merged segment;
[0018] If multiple merged shards contain second unilateral ledger data, then the unilateral ledger data in each merged shard will be reconciled to determine whether there is third unilateral ledger data in each of the second unilateral ledger data.
[0019] If at least one of the aforementioned third-party ledger data exists, then the third-party ledger data is identified as the target transaction data with reconciliation anomalies.
[0020] The above methods may also include:
[0021] If the target transaction data fails to match the preset rules, a verification prompt message is output so that the user can verify the target transaction data.
[0022] Optionally, after adjusting the target transaction data, the above method further includes:
[0023] The transaction data of each shard in the sharded dataset is stored in a predefined sharded ledger;
[0024] Generate the call record of the smart contract, and store the call record and the adjustment operation log corresponding to the target transaction data in a preset global ledger.
[0025] A blockchain-based reconciliation device, applied to a data processing node in a blockchain, the device comprising:
[0026] The receiving unit is used to receive transaction flow data sent by transaction nodes at all levels of the bank;
[0027] The sharding unit is used to shard the transaction flow data based on the spatiotemporal attributes of the transaction flow data to generate a sharded dataset.
[0028] The reconciliation unit is used to reconcile transaction data within the sharded dataset;
[0029] The execution unit is used to respond to the detection of target transaction data with reconciliation anomalies in the sharded dataset, trigger the smart contract to match the target transaction data with preset rules, and perform reconciliation processing on the target transaction data if the match with the preset rules is successful.
[0030] Optionally, in the aforementioned apparatus, the slicing unit includes:
[0031] The preprocessing subunit is used to preprocess the transaction flow data to obtain multiple standard transaction data.
[0032] An extraction subunit is used to extract the spatiotemporal attributes from each of the standard transaction data.
[0033] A generation subunit is used to perform feature encoding based on the spatiotemporal attributes and proportion parameters of each standard transaction data to generate a composite sharding factor for each standard transaction data. The proportion parameters are determined based on the real-time system load monitoring results of the data processing node.
[0034] The first determining subunit is used to determine the data shard to which each standard transaction data belongs based on the composite sharding factor of each standard transaction data, so as to generate a sharded dataset.
[0035] Optionally, the reconciliation unit in the aforementioned apparatus includes:
[0036] The first reconciliation subunit is used to perform reconciliation operations on each transaction data in each segment of the transaction dataset to detect whether there is first one-sided account data in the segment. If the first one-sided account data exists in the segment, the segment is determined as the first target segment.
[0037] The second reconciliation subunit is used to identify a second target segment that is in the same target range as each of the first target segments; the target range is at least one of time range and spatial range; merge the first target segments and the second target segments to obtain merged segments; perform reconciliation operations on the first unilateral account data in the merged segments to determine whether there is second unilateral account data in each of the first unilateral account data in the merged segments;
[0038] The third reconciliation subunit is used to reconcile the single-sided account data in each of the merged segments if there are multiple merged segments with second single-sided account data, in order to determine whether there is third single-sided account data in each of the second single-sided account data.
[0039] The second determining subunit is used to determine the third unilateral account data as target transaction data with reconciliation anomalies if at least one of the third unilateral account data exists.
[0040] A storage medium comprising stored instructions, wherein, when the instructions are executed, the device in which the storage medium resides executes the blockchain-based reconciliation method described above.
[0041] An electronic device includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the blockchain-based reconciliation method described above.
[0042] This application provides a blockchain-based reconciliation method, apparatus, storage medium, and electronic device. The method includes: receiving transaction flow data sent by transaction nodes at various levels of a bank; segmenting the transaction flow data based on its spatiotemporal attributes to generate a segmented dataset; performing reconciliation processing on the transaction data within the segmented dataset; and, in response to detecting a target transaction data with reconciliation anomalies within the segmented dataset, triggering a smart contract to match the target transaction data against preset rules, and, if a successful match is found, performing adjustment processing on the target transaction data. Applying the method provided in this application can improve the timeliness of reconciliation and achieve efficient reconciliation. Attached Figure Description
[0043] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0044] Figure 1A flowchart illustrating a blockchain-based reconciliation method provided for this application;
[0045] Figure 2 A schematic diagram of a reconciliation and adjustment system architecture based on blockchain and smart contracts is provided for this application;
[0046] Figure 3 An example diagram of a block structure provided in this application;
[0047] Figure 4 A flowchart of a contract execution process is provided for this application;
[0048] Figure 5 This application provides a flowchart of the reconciliation and adjustment process;
[0049] Figure 6 A schematic diagram of the structure of a blockchain-based reconciliation device provided for this application;
[0050] Figure 7 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation
[0051] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0052] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0053] This application provides a blockchain-based reconciliation method. This method can be applied to data processing nodes in the blockchain, which can be personal computers, servers, smartphones, tablets, smart wearable devices, etc. The method flowchart is shown below. Figure 1 As shown, it specifically includes:
[0054] S101: Receives transaction flow data sent by transaction nodes at all levels of the bank.
[0055] In this embodiment, transaction flow data transmitted from multiple transaction nodes of the bank is collected in real time; the transaction flow data includes at least timestamps, geographic coordinates and transaction element fields (including transaction number, transaction amount, card number, merchant code and transaction type code).
[0056] Optionally, transaction nodes include branch core systems, etc.
[0057] S102: Based on the spatiotemporal attributes of the transaction flow data, the transaction flow data is segmented to generate a segmented dataset.
[0058] In this embodiment, the spatiotemporal attributes may include timestamps and geographic coordinates. A spatiotemporal composite sharding factor can be constructed based on the timestamps and geographic coordinates in the transaction flow data. The weights of the time and space dimensions are dynamically adjusted through an adaptive weighting algorithm to generate a sharded dataset, which includes multiple shards.
[0059] S103: Perform reconciliation processing on the transaction data within the sharded dataset.
[0060] In this embodiment, the sharded dataset refers to a collection of transaction data generated by dynamic sharding based on spatiotemporal attributes. Each shard contains standardized transaction messages within the same time window (e.g., 1 hour) and geographical area, and data integrity is ensured through a Merkle tree structure. The transaction data covers key fields such as serial number, transaction amount, card number, and merchant code.
[0061] Optionally, the reconciliation process may include: First, comparing transaction data within each shard, using transaction number, transaction time, and amount as matching conditions, verifying the consistency of data within each shard, and generating reconciliation results through the lightweight and practical Byzantine Fault-Tolerant (PBFT) consensus algorithm; Second, expanding the spatiotemporal range of unmatched one-sided ledger data to form secondary shards, performing cross-shard consistency verification to eliminate differences caused by local deviations; Finally, aggregating unmatched one-sided ledger data from all secondary shards to generate a global shard, completing final state consistency auditing through the dynamic consensus mechanism DPoS, with nodes triggering a full review and generating a global Merkle proof daily. Furthermore, for detected abnormal transaction data, automatic reconciliation matching is performed using smart contract preset rules (such as amount thresholds and merchant code matching). Successful matching triggers a reconciliation operation and records it in the global ledger; unsuccessful matching outputs verification prompts for manual review. By using a progressive reconciliation process across time and space, layered verification through consensus algorithms, and automated processing via smart contracts, this approach solves the problems of low efficiency due to serial processing, high risk of human intervention, and potential data tampering in traditional reconciliation, significantly improving the timeliness, accuracy, and traceability of reconciliation.
[0062] S104: In response to detecting that there is a target transaction data with reconciliation anomaly in the sharded dataset, the smart contract is triggered to match the target transaction data with preset rules. If the target transaction data is successfully matched with the preset rules, the reconciliation process is performed on the target transaction data.
[0063] In this embodiment, the sharded dataset refers to the set of transaction data formed after being sharded by spatiotemporal attributes. The target transaction data with reconciliation anomalies are the transaction records that failed to reconcile. The abnormal characteristics include, but are not limited to, serial number conflicts, amount differences, merchant code mismatches, or timestamp deviations.
[0064] Optionally, the smart contract is deployed on a blockchain node and performs real-time matching of target transaction data through a preset rule base and time window verification strategy. The rule base supports dynamic updates (such as adjusting the threshold range or adding rule items through the supernode consensus mechanism). The preset rule base includes at least one of the following: amount threshold, merchant code whitelist, transaction type matching rules, etc.
[0065] Optionally, when the field combination of the target transaction data meets the preset rules (e.g., abnormal amount ≤ amount threshold and merchant code matching degree ≥ 95%), the smart contract is triggered to perform accounting correction on the target transaction data, including but not limited to reverse reversal transactions, supplementing missing fields or synchronizing the status of ledgers in multiple systems, and writing the adjustment result into the distributed ledger (blockchain) to form an immutable adjustment voucher; if the matching fails, the abnormal data is marked as requiring manual review.
[0066] The method provided in this application involves receiving transaction log data sent by transaction nodes at various levels of a bank; segmenting the transaction log data based on its spatiotemporal attributes to generate segmented datasets; reconciling the transaction data within the segmented datasets; and, in response to the detection of target transaction data with reconciliation anomalies within the segmented datasets, triggering a smart contract to match the target transaction data against preset rules. If a match is successful, the target transaction data is adjusted. This method improves the timeliness of reconciliation and enables efficient reconciliation.
[0067] In some embodiments provided in this application, optionally, the process of segmenting the transaction flow data based on the spatiotemporal attributes of the transaction flow data in S102 to generate a segmented dataset includes:
[0068] The transaction log data is preprocessed to obtain multiple standard transaction data.
[0069] Extract the spatiotemporal attributes from each of the standard transaction data;
[0070] Feature encoding is performed on each standard transaction data according to its spatiotemporal attributes and proportion parameters to generate a composite sharding factor for each standard transaction data. The proportion parameters are determined based on the real-time system load monitoring results of the data processing node.
[0071] Based on the composite sharding factor of each standard transaction data, the data shard to which each standard transaction data belongs is determined to generate a sharded dataset.
[0072] Optionally, transaction log data refers to the original transaction records that include fields such as timestamp, geographic coordinates, transaction amount, and merchant code.
[0073] In this embodiment, the "spatiotemporal attribute" is a composite feature extracted from the transaction flow data, combining the time and spatial dimensions.
[0074] Optionally, standard transaction data refers to transaction records that have been preprocessed (including data cleaning, field completion, and outlier removal) and conform to a unified format specification.
[0075] Optionally, the scaling parameter is a weighting coefficient dynamically calculated based on the real-time system load monitoring results of the data processing nodes, used to balance the uniformity of shard distribution and the load balance of nodes. The real-time system load monitoring results include CPU utilization, memory usage, and network throughput, etc.
[0076] In this embodiment, the original transaction log data is first standardized to generate standard transaction data with complete structured fields that conform to the preset data model. Then, the spatiotemporal attributes of each standard transaction data are extracted. Furthermore, the spatiotemporal attributes are weighted and fused with a proportional parameter to generate a composite sharding factor. This composite sharding factor is composed of the normalized value of the time code and the normalized value of the spatial code, which are weighted and summed according to the proportional parameter. Each standard transaction data is then allocated to the corresponding data shard to generate a sharded dataset.
[0077] In some embodiments provided in this application, optionally, the reconciliation processing of transaction data within the sharded dataset includes:
[0078] For each shard in the transaction dataset, a reconciliation operation is performed on each transaction data in the shard to detect whether there is first one-sided account data in the shard. If the first one-sided account data exists in the shard, the shard is determined as the first target shard.
[0079] Identify a second target segment that is within the same target range as each of the first target segments; the target range is at least one of a time range and a spatial range; merge the first target segments and the second target segments to obtain a merged segment; perform a reconciliation operation on the first unilateral ledger data in the merged segment to determine whether there is second unilateral ledger data in each of the first unilateral ledger data in the merged segment;
[0080] If multiple merged shards contain second unilateral ledger data, then the unilateral ledger data in each merged shard will be reconciled to determine whether there is third unilateral ledger data in each of the second unilateral ledger data.
[0081] If at least one of the aforementioned third-party ledger data exists, then the third-party ledger data is identified as the target transaction data with reconciliation anomalies.
[0082] In this embodiment, one-sided account data refers to transaction data where at least one party has not completed fund clearing or accounting records. The detection criteria include, but are not limited to, serial number conflicts, amount differences, merchant code mismatches, or timestamp deviations. The first one-sided account data is the abnormal transaction record initially detected within a single shard. The first target shard is a shard unit containing the first one-sided account data, and it is determined based on the density of one-sided account data within the shard (e.g., the proportion of abnormal transactions exceeds a preset ratio) or the amount of a single abnormal transaction exceeds a threshold.
[0083] Optionally, the target range is a composite dimension of time range and spatial range, used to filter second target segments that are related to the first target segment. For example, the second target segment is continuous with the first target segment in time or in space.
[0084] In this embodiment, the merged shard is the data set obtained by merging the first target shard and the second target shard according to the rules of temporal or spatial continuity. The merging strategy includes temporal alignment and spatial aggregation. The second unilateral ledger data is the abnormal transaction records further detected in the merged shard. The judgment logic is that there are still unmatched items in the comparison of upstream and downstream accounts after merging. The third unilateral ledger data is the abnormal transaction data that still fails to reach consistency when reconciling accounts across multiple merged shards.
[0085] In some embodiments provided in this application, optionally, the following additional features may be included:
[0086] If the target transaction data fails to match the preset rules, a verification prompt message is output so that the user can verify the target transaction data.
[0087] Optionally, the prompt message can be used to instruct the user to review the target transaction data. The prompt message can be displayed on a preset display interface or sent to a preset terminal.
[0088] In some embodiments provided in this application, optionally, after adjusting the target transaction data, the process further includes:
[0089] The transaction data of each shard in the sharded dataset is stored in a predefined sharded ledger;
[0090] Generate the call record of the smart contract, and store the call record and the adjustment operation log corresponding to the target transaction data in a preset global ledger.
[0091] In this embodiment, the sharded ledger can be a localized ledger unit deployed on a blockchain node. Its data structure is key-value pair storage, where the key is the shard identifier and the value is a set of encrypted sharded transaction data. The transaction data includes the original transaction log, adjustment records, and smart contract execution status.
[0092] Optionally, the global ledger can be a distributed ledger synchronized across nodes, with a chain-like block structure. Each block contains smart contract call records, adjustment operation logs of the target transaction data, and verification signatures.
[0093] Optionally, transaction data from each shard of the sharded dataset is written to the local shard ledger. Subsequently, after the smart contract performs the reconciliation process, it automatically generates call records and reconciliation operation logs. The call records contain the call time and parameters of the contract method calls, while the reconciliation operation logs capture key operation records of the reconciliation process through an event listening mechanism. These records are then written to the global ledger in an atomic operation form through a preset global ledger interface. The writing process uses a two-phase commit protocol to ensure cross-ledger consistency. Finally, the call records and reconciliation operation logs are broadcast to all network nodes through the PBFT consensus algorithm of the global ledger.
[0094] See Figure 2 This document presents a schematic diagram of a blockchain-based smart contract-based reconciliation system architecture, as provided in an embodiment of this application. During the data processing phase, bank branches at various levels push transaction flow data. To meet the demands of high-frequency transactions and large-scale data processing, spatiotemporal coding is used as a sharding factor for dynamic data sharding, improving system throughput. Subsequently, a layered reconciliation mechanism is used to perform transaction data reconciliation operations, significantly improving real-time performance and efficiency while ensuring accuracy. For transaction data with reconciliation anomalies, smart contracts perform risk decisions, reconciliation operations, and audit tracking. After processing, abnormal and normal transaction flows, along with audit logs, are uploaded to the blockchain via a consensus network to ensure the credibility and global consistency of the reconciliation results. Finally, the original transaction data is stored in the sharded ledger according to the sharding strategy, while the reconciliation results and audit logs are stored in the global ledger, achieving persistent data storage to support subsequent queries, analysis, and auditing.
[0095] Dynamic Data Sharding Processing Layer: This layer involves banks and UnionPay preprocessing transaction data to generate data shards and constructing Merkle tree blocks. The process is as follows:
[0096] First, the spatiotemporal attributes (timestamp, geographic coordinates) of the transaction data are encoded to generate a composite sharding factor, calculated using the following formula:
[0097]
[0098] in, The sharding factor is a composite sharding factor, where α and β represent the time and spatial weights, respectively, and α + β = 1. Based on real-time load monitoring data (node processing capacity, network latency, and storage capacity), an adaptive algorithm dynamically adjusts the weight ratio of each attribute in the sharding factor to avoid the formation of hotspot shards. Tshard represents the time shard code ID, Gshard represents the spatial shard code ID, and N represents the upper limit of the number of shards. This method ensures that transaction data from the same time period and region are grouped into a single shard as much as possible.
[0099] Then, non-reconciliation data is filtered out, heterogeneous sources are unified into standardized transaction messages, and a two-level verification structure is constructed, specifically including a transaction detail tree and a summary statistics tree.
[0100] Optionally, the transaction details tree includes a hash value generated for each transaction within a shard, forming a hash chain from the leaf node to the root node.
[0101] In this embodiment, the summary statistical tree is used to calculate the statistical hash value of the sharded transaction features.
[0102] like Figure 3 The diagram shown is an example of a block structure provided in an embodiment of this application, which can package and shard transactions into blocks for submission according to a 1-hour time window.
[0103] Layered Reconciliation Execution Layer: This layer adopts a three-tier sharding architecture to improve reconciliation timeliness, as detailed below:
[0104] The bank transaction data and UnionPay transaction data within each slice are automatically compared one by one based on factors such as transaction serial number, transaction time, and transaction amount. The reconciliation results are verified using lightweight PBFT consensus within the initial slice.
[0105] After the initial intra-shard reconciliation is completed, for unmatched one-sided transaction data, real-time synchronization of transaction data between shards is achieved through a cross-chain relay gateway. Spatiotemporal shards are merged, for example, by extending the time span and increasing the spatial range, to reorganize cross-shards into secondary shards. In the secondary shards, matching is also performed automatically, transaction by transaction, using elements such as transaction serial number, transaction time, and transaction amount as matching criteria. Within the secondary shards, the reconciliation results are verified using a lightweight PBFT consensus mechanism.
[0106] After reconciliation within the secondary shards is completed, all unmatched one-sided ledger data in all secondary shards are aggregated to form a global shard. Within the global shard, transaction serial numbers, transaction times, and transaction amounts are used as matching criteria to automatically compare each transaction, thus obtaining the final one-sided or erroneous ledger data. Simultaneously, the global layer integrates core audit nodes and a dynamic DPoS consensus mechanism to perform full-chain auditing and final state consistency verification. Supernodes trigger a global reconciliation task daily, generating a global Merkle proof by aggregating the root hash value of the aggregated tree of all shard states, and then performing a full review.
[0107] Smart Contract Processing Layer: This layer is primarily used to automate reconciliation and adjustment processes using smart contracts, and to retain all process data and operation logs for auditing and tracing. The execution flowchart of each contract in this layer is shown below. Figure 4 As shown.
[0108] Automatic reconciliation contract: Enables real-time consistency verification and discrepancy identification of transaction data, ensuring the accuracy of accounting records. It automatically compares each transaction based on elements such as transaction serial number, transaction time, and transaction amount. Transaction data with mismatched reconciliation elements is designated as a one-sided transaction for subsequent cross-segment or global reconciliation. Transaction data that remains a one-sided transaction after global reconciliation will be adjusted through an adjustment execution contract.
[0109] Reconciliation Execution Contract: Reconciliation is automatically executed based on reconciliation results and preset rules, minimizing manual intervention. Due to the transparency of the reconciliation execution contract and the immutability of blockchain, the contract execution process is traceable. If, during execution, there are transactions that cannot match the preset rules, a manual review channel will be used to intervene and conduct subsequent reconciliation work.
[0110] Audit trail contract: Records the entire lifecycle of transactions, providing a traceable chain of audit evidence. It writes reconciliation and adjustment results from each shard to a timestamp hash chain, ensuring immutability. A lightweight consensus algorithm is integrated to verify the authenticity of the audit logs.
[0111] Distributed ledger storage layer: This layer is mainly used to store raw transaction data, adjustment logs, and other data.
[0112] Sharded Ledger: Stores raw transaction data within different time windows and spatial regions according to a data sharding strategy, supporting fast read and write operations in high-concurrency scenarios. Simultaneously, it achieves efficient verification of single and batch transactions through a two-level Merkle tree structure, solving the fragmentation problem of traditional distributed storage.
[0113] Global Ledger: Records the entire process of handling one-sided or erroneous accounts (including smart contract call records and reconciliation operation logs), meeting financial compliance requirements and achieving full traceability and auditability. Furthermore, it serves as a public database, maintaining metadata such as the network's node topology, sharding mapping rules, and reconciliation preset rules.
[0114] Based on the above four levels, the reconciliation and adjustment process will be carried out through a blockchain-based smart contract-based reconciliation and adjustment system as follows: Figure 5 As shown, the specific process is as follows:
[0115] The first step, branch data preprocessing and submission, involves each branch of the bank first cleaning and standardizing the transaction data. During this process, data not required for reconciliation is filtered out, and heterogeneous data sources are converted into standardized transaction messages for subsequent reconciliation operations. After standardization, the data is fragmented according to a spatiotemporal strategy, a Merkle tree of the transaction data is constructed, and the processed data is packaged into blocks and submitted.
[0116] The second step involves automatic reconciliation and global auditing at the reconciliation layer. In this embodiment, after receiving a block, the reconciliation layer nodes employ a three-tier sharding reconciliation architecture, utilizing an automatic reconciliation contract to achieve automatic reconciliation of transaction data. The specific steps are as follows: First, the initial shard data in the block is reconciled based on reconciliation elements such as transaction number, card number, and transaction amount. For unmatched transactions, the spatiotemporal scope is expanded to form secondary shards, and reconciliation is performed again. Finally, all unmatched transactions from the secondary shards are combined into a global shard for a final reconciliation. Furthermore, the global layer integrates core audit nodes and a dynamic DPoS consensus mechanism to perform full-chain auditing and final state consistency verification. Supernodes trigger global reconciliation tasks daily, generating a global Merkle proof by aggregating the root hash value of the aggregated tree of all shard states, and performing a full review. Throughout the reconciliation process, all reconciliation records and operation records are logged through the audit trail contract.
[0117] The third step is the processing of unilateral or erroneous accounts. In this embodiment, after obtaining the unilateral or erroneous account data, the adjustment execution contract matches the data with preset rules. If the match is successful, the adjustment is performed automatically; if the match fails, it enters the manual review stage, where manual intervention completes the adjustment operation. During the processing of unilateral or erroneous accounts, all adjustment records, review records, and operation records are logged through the audit trail contract.
[0118] The fourth step is data storage. In this embodiment, the original transaction data is stored in the sharded ledger according to the sharding strategy, while the smart contract call records, adjustment operation logs, etc. generated throughout the entire process are stored in the global ledger.
[0119] In this embodiment, a spatiotemporal coding factor can be used to dynamically shard the transaction flow. Dynamic sharding breaks down massive transaction data into parallel processing units according to spatiotemporal characteristics, transforming the reconciliation task from serial to concurrent.
[0120] Optionally, pre-defined reconciliation rules significantly reduce anomaly response time and the risks associated with manual intervention. Furthermore, the transparency of the contract and the immutability of the blockchain ensure the traceability of reconciliations. In addition, audit logs are uploaded to the blockchain in real time for evidence storage, meeting the requirements for transaction traceability and auditability.
[0121] In this embodiment, the reconciliation results can be solidified through a consensus network to prevent financial disputes caused by subsequent tampering, and the audit requirements can also be met.
[0122] and Figure 1 Corresponding to the method described above, this application also provides a blockchain-based reconciliation device, applied to a data processing node in the blockchain, specifically for reconciliation... Figure 1 The specific implementation of the method is shown in the following structural diagram. Figure 6 As shown, it includes:
[0123] The receiving unit 601 is used to receive transaction flow data sent by transaction nodes at all levels of the bank;
[0124] Sharding unit 602 is used to shard the transaction flow data based on the spatiotemporal attributes of the transaction flow data to generate a sharded dataset.
[0125] The reconciliation unit 603 is used to reconcile transaction data within the sharded dataset;
[0126] The execution unit 604 is used to respond to the detection of target transaction data with reconciliation anomalies in the sharded dataset, trigger the smart contract to match the target transaction data with preset rules, and perform reconciliation processing on the target transaction data if the match with the preset rules is successful.
[0127] In some embodiments provided in this application, optionally, the fragmentation unit 602 includes:
[0128] The preprocessing subunit is used to preprocess the transaction flow data to obtain multiple standard transaction data.
[0129] An extraction subunit is used to extract the spatiotemporal attributes from each of the standard transaction data.
[0130] A generation subunit is used to perform feature encoding based on the spatiotemporal attributes and proportion parameters of each standard transaction data to generate a composite sharding factor for each standard transaction data. The proportion parameters are determined based on the real-time system load monitoring results of the data processing node.
[0131] The first determining subunit is used to determine the data shard to which each standard transaction data belongs based on the composite sharding factor of each standard transaction data, so as to generate a sharded dataset.
[0132] In some embodiments provided in this application, optionally, the reconciliation unit 603 includes:
[0133] The first reconciliation subunit is used to perform reconciliation operations on each transaction data in each segment of the transaction dataset to detect whether there is first one-sided account data in the segment. If the first one-sided account data exists in the segment, the segment is determined as the first target segment.
[0134] The second reconciliation subunit is used to identify a second target segment that is in the same target range as each of the first target segments; the target range is at least one of time range and spatial range; merge the first target segments and the second target segments to obtain merged segments; perform reconciliation operations on the first unilateral account data in the merged segments to determine whether there is second unilateral account data in each of the first unilateral account data in the merged segments;
[0135] The third reconciliation subunit is used to reconcile the single-sided account data in each of the merged segments if there are multiple merged segments with second single-sided account data, in order to determine whether there is third single-sided account data in each of the second single-sided account data.
[0136] The second determining subunit is used to determine the third unilateral account data as target transaction data with reconciliation anomalies if at least one of the third unilateral account data exists.
[0137] The specific principles and execution processes of each unit and module in the blockchain-based reconciliation device disclosed in the above embodiments of this application are the same as those of the blockchain-based reconciliation method disclosed in the above embodiments of this application. Please refer to the corresponding parts of the blockchain-based reconciliation method provided in the above embodiments of this application, and they will not be repeated here.
[0138] This application embodiment also provides a storage medium, which includes stored instructions, wherein, when the instructions are executed, the device where the storage medium is located executes the above-described blockchain-based reconciliation method.
[0139] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 7 As shown, it specifically includes a memory 701 and one or more instructions 702, wherein one or more instructions 702 are stored in the memory 701 and configured to be executed by one or more processors 703 to perform the above-mentioned blockchain-based reconciliation method.
[0140] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.
[0141] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application program, server, or storage medium executing the operation of this invention, based on the prompt message.
[0142] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.
[0143] It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation of the present invention. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present invention.
[0144] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.
[0145] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.
[0146] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.
[0147] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.
[0148] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.
[0149] The above provides a detailed description of a blockchain-based reconciliation method. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A blockchain-based reconciliation method, characterized in that, The method, applied to data processing nodes in a blockchain, includes: Receive transaction log data sent by transaction nodes at all levels of the bank; Based on the spatiotemporal attributes of the transaction data, the transaction data is segmented to generate a segmented dataset. Perform reconciliation processing on the transaction data within the aforementioned sharded dataset; In response to the detection of target transaction data with reconciliation anomalies in the sharded dataset, the smart contract is triggered to match the target transaction data with preset rules. If the match with the preset rules is successful, the target transaction data is adjusted.
2. The method according to claim 1, characterized in that, The step of segmenting the transaction flow data based on its spatiotemporal attributes to generate a segmented dataset includes: The transaction log data is preprocessed to obtain multiple standard transaction data. Extract the spatiotemporal attributes from each of the standard transaction data; Feature encoding is performed on each standard transaction data according to its spatiotemporal attributes and proportion parameters to generate a composite sharding factor for each standard transaction data. The proportion parameters are determined based on the real-time system load monitoring results of the data processing node. Based on the composite sharding factor of each standard transaction data, the data shard to which each standard transaction data belongs is determined to generate a sharded dataset.
3. The method according to claim 1, characterized in that, The reconciliation process for transaction data within the sharded dataset includes: For each shard in the transaction dataset, a reconciliation operation is performed on each transaction data in the shard to detect whether there is first one-sided account data in the shard. If the first one-sided account data exists in the shard, the shard is determined as the first target shard. Identify a second target segment that is within the same target range as each of the first target segments; the target range is at least one of a time range and a spatial range; merge the first target segments and the second target segments to obtain a merged segment; perform a reconciliation operation on the first unilateral ledger data in the merged segment to determine whether there is second unilateral ledger data in each of the first unilateral ledger data in the merged segment; If multiple merged shards contain second unilateral ledger data, then the unilateral ledger data in each merged shard will be reconciled to determine whether there is third unilateral ledger data in each of the second unilateral ledger data. If at least one of the aforementioned third-party ledger data exists, then the third-party ledger data is identified as the target transaction data with reconciliation anomalies.
4. The method according to claim 1, characterized in that, Also includes: If the target transaction data fails to match the preset rules, a verification prompt message is output so that the user can verify the target transaction data.
5. The method according to claim 1, characterized in that, After adjusting the target transaction data, the process further includes: The transaction data of each shard in the sharded dataset is stored in a predefined sharded ledger; Generate the call record of the smart contract, and store the call record and the adjustment operation log corresponding to the target transaction data in a preset global ledger.
6. A blockchain-based reconciliation device, characterized in that, The device, used as a data processing node in a blockchain, includes: The receiving unit is used to receive transaction flow data sent by transaction nodes at all levels of the bank; The sharding unit is used to shard the transaction flow data based on the spatiotemporal attributes of the transaction flow data to generate a sharded dataset. The reconciliation unit is used to reconcile transaction data within the sharded dataset; The execution unit is used to respond to the detection of target transaction data with reconciliation anomalies in the sharded dataset, trigger the smart contract to match the target transaction data with preset rules, and perform reconciliation processing on the target transaction data if the match with the preset rules is successful.
7. The apparatus according to claim 6, characterized in that, The fragmentation unit includes: The preprocessing subunit is used to preprocess the transaction flow data to obtain multiple standard transaction data. An extraction subunit is used to extract the spatiotemporal attributes from each of the standard transaction data. A generation subunit is used to perform feature encoding based on the spatiotemporal attributes and proportion parameters of each standard transaction data to generate a composite sharding factor for each standard transaction data. The proportion parameters are determined based on the real-time system load monitoring results of the data processing node. The first determining subunit is used to determine the data shard to which each standard transaction data belongs based on the composite sharding factor of each standard transaction data, so as to generate a sharded dataset.
8. The apparatus according to claim 6, characterized in that, The reconciliation unit includes: The first reconciliation subunit is used to perform reconciliation operations on each transaction data in each segment of the transaction dataset to detect whether there is first one-sided account data in the segment. If the first one-sided account data exists in the segment, the segment is determined as the first target segment. The second reconciliation subunit is used to identify a second target segment that is in the same target range as each of the first target segments; the target range is at least one of time range and spatial range; merge the first target segments and the second target segments to obtain merged segments; perform reconciliation operations on the first unilateral account data in the merged segments to determine whether there is second unilateral account data in each of the first unilateral account data in the merged segments; The third reconciliation subunit is used to reconcile the single-sided account data in each of the merged segments if there are multiple merged segments with second single-sided account data, in order to determine whether there is third single-sided account data in each of the second single-sided account data. The second determining subunit is used to determine the third unilateral account data as target transaction data with reconciliation anomalies if at least one of the third unilateral account data exists.
9. A storage medium, characterized in that, The storage medium includes storage instructions, wherein, when the instructions are executed, the device containing the storage medium is controlled to perform the blockchain-based reconciliation method as described in any one of claims 1 to 5.
10. An electronic device, characterized in that, It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the blockchain-based reconciliation method as described in any one of claims 1 to 5.