Blockchain-based cross-border financial payment transaction data traceability system

Abstract

The present application relates to the technical field of cross-border financial payment, in particular to a cross-border financial payment transaction data tracing system based on a block chain. The present application decomposes payment transactions into a sequence of standardized payment events, condenses the whole payment path by using a homomorphic hash aggregation root, and only writes the aggregation root and sparse path aggregation tree root into the block chain, which ensures that the path cannot be tampered with and avoids detailed data on the chain. Through a double-layer chain anchoring mechanism, a privacy-oriented transaction tracing sub-chain is separated from a supervision-oriented audit anchoring sub-chain, and a regulatory node only obtains compliance metadata and anchoring identifiers, which can be sure that the data has not been tampered with by verifying anchoring association, without needing to contact transaction details. An abnormality detection state machine is embedded in a smart contract, which automatically checks the compliance of state transition, and abnormality proof is chained to form an auditable abnormal event record. The whole process of payment data is verified and traced, and the problems of easy tampering and privacy leakage of centralized solutions are solved.

Description

Technical Field

[0001] This invention relates to the field of cross-border financial payment technology, and more specifically, to a blockchain-based cross-border financial payment transaction data traceability system. Background Technology

[0002] Currently, Coralglobal's cross-border financial services face multiple pain points in the payment transaction tracing process, severely impacting business efficiency and compliance management. In traditional payment systems, transaction data is scattered across multiple nodes, including the bank's end, platform business systems, and partner institution systems. The data formats are inconsistent (e.g., bank statements are in MT940 format, while platform transaction records are in a custom JSON format), and there is a lack of real-time data synchronization mechanisms between these systems. When enterprises or regulatory agencies need to trace a cross-border payment transaction, they must manually retrieve data from multiple systems, then manually organize and compare it. This is not only time-consuming and labor-intensive (a complete trace of a single transaction takes an average of 2-3 business days), but also prone to inaccurate tracing results due to data omissions and format conversion errors. Furthermore, some transaction-related information (such as order contracts, logistics documents, and foreign exchange verification certificates) is not stored in conjunction with payment data. This makes it difficult to quickly verify the authenticity of the transaction background during tracing, which is insufficient to meet regulatory requirements such as anti-money laundering (AML) and foreign exchange management, and poses compliance risks. At the same time, when transaction anomalies occur (such as delayed fund arrival or discrepancies in amount), the inability to pinpoint the problem link in real time (whether it is an anomaly in the payment initiation, bank transfer, or clearing process) requires customer service personnel to repeatedly communicate with multiple parties to investigate, resulting in a long problem-solving cycle and affecting customer experience.

[0003] To address the aforementioned issues, there is an urgent need for a blockchain-based cross-border financial payment transaction data traceability system. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based cross-border financial payment transaction data traceability system, thereby solving the problems mentioned in the background art.

[0005] To achieve the above objectives, the blockchain-based cross-border financial payment transaction data traceability system includes a data access and standardization module, a blockchain networking module, an on-chain evidence storage module, a smart contract module, and a traceability engine module. The data access and standardization module obtains the original transaction data and related business documents of the entire cross-border payment chain from the banking system, payment business system and cooperative institution system through multi-protocol interfaces, and transforms the original transaction data into a standardized payment event sequence that conforms to a unified data model; The blockchain networking module is used to maintain a consortium blockchain network consisting of payment participating nodes and regulatory nodes, in which a transaction traceability sub-chain and an audit anchoring sub-chain are deployed. The on-chain evidence storage module is used to perform homomorphic hash aggregation on the standardized payment event sequence to generate a transaction path aggregation root, and to perform the following: Each standardized payment event in the standardized payment event sequence is symmetrically encrypted and written into the off-chain storage layer, and a corresponding storage index is generated. The storage index and the intermediate nodes formed by homomorphic hash aggregation are combined to construct a sparse path aggregation tree, and the transaction path aggregation root and the root hash of the sparse path aggregation tree are written into the transaction traceability sub-chain. The set of compliance metadata extracted based on the standardized payment events is written into the audit anchoring subchain, and an anchoring association is established between the transaction path aggregation root on the transaction traceability subchain and the set of compliance metadata on the audit anchoring subchain. The smart contract module is deployed on the consortium blockchain network and is used to perform state consistency verification on the standardized payment event sequence through the anomaly detection state machine. When the verification fails, an anomaly proof is generated and the anomaly proof is written into the transaction traceability subchain through the on-chain evidence storage module. The traceability engine module is used to respond to traceability requests containing the target payment event identifier, obtain the corresponding sparse path aggregation tree and transaction path aggregation root from the transaction traceability sub-chain, obtain the encrypted standardized payment event from the off-chain storage layer, perform decryption and reconstruct the payment end-to-end state transition sequence using the sparse path aggregation tree, and output traceability results containing payment path and compliance metadata by verifying the consistency between the aggregation root of the reconstructed path and the transaction path aggregation root recorded on the chain.

[0006] Compared with the prior art, the beneficial effects of the present invention are as follows: This blockchain-based cross-border financial payment transaction data traceability system decomposes payment transactions into standardized payment event sequences. It uses homomorphic hash aggregation roots to condense the entire payment path, writing only the aggregation root and the sparse path aggregation tree root to the blockchain. This ensures the immutability of the path while avoiding the uploading of detailed data to the chain. Through a two-layer chain anchoring mechanism, the privacy-oriented transaction traceability sub-chain is separated from the regulatory-oriented audit anchoring sub-chain. Regulatory nodes only obtain compliance metadata and anchoring identifiers, and can verify the anchoring association to confirm that the data has not been tampered with without accessing the transaction details. An anomaly detection state machine is embedded in the smart contract, automatically verifying the compliance of state transitions. Anomaly proofs are uploaded to the chain to form an auditable anomaly event record. The entire system achieves full-process verifiable traceability of payment data in a distributed trust environment, solving the problems of data tampering and privacy leakage in centralized solutions. Attached Figure Description

[0007] Figure 1 This is an overall system block diagram of the present invention; Figure 2This is a diagram of the interface of the original transaction data standardization processing system of the present invention; Figure 3 This is a diagram of the blockchain networking system interface of the present invention; Figure 4 This is a flowchart of the evidence storage process of the present invention. Figure 5 This is an interface diagram of the sparse path aggregation tree structure system of the present invention; Figure 6 This is an interface diagram of the anomaly detection system of the present invention; Figure 7 This is an interface diagram of the target payment event identification and tracing system of the present invention. Detailed Implementation

[0008] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0009] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0010] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0011] Please see Figure 1 As shown, a blockchain-based cross-border financial payment transaction data traceability system is provided, including a data access and standardization module, a blockchain networking module, an on-chain evidence storage module, a smart contract module, and a traceability engine module. The data access and standardization module obtains the original transaction data and related business documents of the entire cross-border payment chain from the banking system, payment business system and partner institution system through multi-protocol interfaces, and transforms the original transaction data into a standardized payment event sequence that conforms to a unified data model; The blockchain networking module is used to maintain a consortium blockchain network consisting of payment participant nodes and regulatory nodes. This consortium blockchain network deploys a transaction traceability sub-chain and an audit anchoring sub-chain. The on-chain evidence storage module is used to perform homomorphic hash aggregation on standardized payment event sequences to generate transaction path aggregation roots, and performs the following: Each standardized payment event in the standardized payment event sequence is symmetrically encrypted, written into the off-chain storage layer, and a corresponding storage index is generated. The storage index and the intermediate nodes formed by homomorphic hash aggregation are combined to construct a sparse path aggregation tree, and the transaction path aggregation root and the root hash of the sparse path aggregation tree are written into the transaction traceability sub-chain. Write the set of compliance metadata extracted based on standardized payment events into the audit anchor subchain, and establish an anchoring association between the transaction path aggregation root on the transaction traceability subchain and the set of compliance metadata on the audit anchor subchain; The smart contract module is deployed on the consortium blockchain network and is used to perform state consistency verification on the standardized payment event sequence through the anomaly detection state machine. When the verification fails, an anomaly proof is generated and written to the transaction traceability sub-chain through the on-chain evidence storage module. The traceability engine module is used to respond to traceability requests containing the identifier of the target payment event, obtain the corresponding sparse path aggregation tree and transaction path aggregation root from the transaction traceability sub-chain, obtain the encrypted standardized payment event from the off-chain storage layer, perform decryption and reconstruct the payment end-to-end state transition sequence using the sparse path aggregation tree, and output the traceability result containing the payment path and compliance metadata by verifying the consistency between the aggregation root of the reconstructed path and the transaction path aggregation root recorded on the chain.

[0012] The specific implementation method is as follows: First, in order to ensure data consistency during the process of tracing cross-border financial payment transaction data, this solution uses a data access and standardization module to obtain the original transaction data and related business documents of the entire cross-border payment chain from the banking system, payment business system and partner institution system through multi-protocol interfaces, and transforms the original transaction data into a standardized payment event sequence that conforms to a unified data model.

[0013] Each standardized payment event in the standardized payment event sequence must include at least a payment event identifier, event type, event subject, event timestamp, and associated business summary. The specific conversion method is as follows: First, the data access and standardization module is composed of a protocol adaptation unit, a data cleaning and transformation unit, and an event synthesis unit connected in sequence.

[0014] The protocol adaptation unit is configured with multiple communication interfaces to interface with external systems of different technical forms. For banking systems, the protocol adaptation unit establishes a real-time API channel conforming to RESTful specifications, continuously receiving data such as payment records, settlement status, and transaction fee details in JSON format via HTTPS protocol. This API channel is configured with a 30-second heartbeat detection message; if no response is received after two consecutive heartbeats, a channel switching alarm is triggered. For partner institution systems that do not support real-time interfaces, such as some logistics service providers and customs brokerage platforms, the protocol adaptation unit enables a timed encrypted file transfer channel based on SFTP, acquiring the full amount of data from the previous day within a pre-agreed time window each day. The transmitted files are encrypted using the AES-256 symmetric encryption algorithm, and upon receipt, the MD5 digest of the file is calculated and compared with the digest value provided by the sender to verify integrity. All raw data obtained through the above interfaces is temporarily stored in binary form in the raw data buffer layer, accompanied by the source system identifier and the receiving timestamp.

[0015] After data acquisition, the data cleaning and transformation unit reads the raw data from the buffer layer and selects the corresponding parser based on the source system identifier. For bank MT940 format messages, the parser extracts fields such as transaction type, amount, value date, and account information, and maps the SWIFT bank identification code to a unified bank identifier within the system. For custom JSON records from the platform's business systems, the parser extracts fields such as order number, transaction amount, currency, buyer and seller accounts, and status change logs into key-value pairs. For related business documents in image or PDF format, such as scanned contracts and logistics vouchers, the data cleaning and transformation unit calls the OCR recognition subunit and uses a text detection and recognition model based on a deep convolutional recurrent neural network to extract key fields such as contract number, amount, signing date, and logistics tracking number, forming a structured summary text. All extracted fields then enter a mapping and normalization process: currency codes are uniformly converted to the ISO 4217 standard, the amount unit is uniformly converted to RMB Yuan with two decimal places, the timestamp is uniformly converted to Coordinated Universal Time (UTC) millisecond-level long integer, and the country code is standardized according to ISO 3166-1. Duplicate transaction records are deduplicated using a composite primary key, which is composed of the system source identifier and the original transaction number. Erroneous data, such as negative amounts or records with missing required fields, will be marked and transferred to a manual verification queue, and will not proceed to further processing.

[0016] Finally, the event synthesis unit receives the set of normalized fields output by the data cleaning and transformation unit, and according to the predefined cross-border payment state transition model, breaks down a complete cross-border payment transaction into an ordered sequence of standardized payment events.

[0017] The cross-border payment state transition model is stored in the form of a directed graph. The nodes of the graph represent the legal states in the payment lifecycle, including but not limited to: PAYMENT_INITIATED (payment initiated), FUNDS_DEBITED (funds deducted), INTERMEDIARY_FORWARDED (intermediate bank forwarding), CLEARING_COMPLETED (clearing completed), FUNDS_CREDITED (payee received funds), PAYMENT_FAILED (payment failed), REFUND_INITIATED (refund initiated), etc. The edges of the graph represent the allowed state transitions, and each edge is bound to an event type identifier.

[0018] Once the normalized field set arrives, the event synthesis unit first identifies the start and end states of the transaction. Taking a forward payment as an example, the default start state is PAYMENT_INITIATED. Based on the timestamps and status markers provided by each business system, the event synthesis unit extracts clues about state changes from the normalized fields. Clue sources include: order status logs from the payment business system, transaction codes and status codes in bank messages, confirmation notifications from the clearing network, and receipts from partner institutions' systems. If multiple state change clues exist for the same transaction, the state corresponding to the earliest reliable timestamp is used as the confirmation time for that state.

[0019] For each state change, the event synthesis unit generates a standardized payment event. The generation process includes the following steps: Step 1: Generate payment event identifier: Read the unique transaction identifier ID from the normalized field and combine it with the event counter maintained inside the event synthesis unit to form a composite identifier of "transaction ID-sequence number" to ensure that the event is unique throughout the entire system; The second step is to determine the event type: Based on the target state reached on the state transition diagram, select the corresponding event type from the enumeration set. For example, when transitioning from the initial state to the FUNDS_DEBITED state, the event type is "funds deducted"; Step 3: Extract the event subject: Identify the responsible subject from normalized fields based on the event type. In a fund deduction event, the subjects are the payer's account and the deducting bank; in an intermediary bank forwarding event, the subjects are the sending bank and the receiving bank; in a clearing completion event, the subject is the clearing network identifier. The subject is recorded in compound string format, with each part separated by vertical bars. Step 4: Record the event timestamp: Prioritize using the exact time of the status change in the original data; if no precise time is available, then take the bank's acceptance time, message writing time, or reception time in sequence, and add a time source marker. Step 5: Generate Related Business Summary: The event synthesis unit extracts non-payment information related to the event's timeline from the normalized fields and calls the summary generation algorithm. This algorithm scans logistics document fields, customs declaration fields, contract fields, etc. If there is non-payment data with a timestamp overlap of a preset window with the current event, it extracts keywords and numbers to form a short text of no more than 256 characters. For example, in the "Payment Initiation" event, the summary might be "Contract No. C20250918001, Logistics Tracking Number Pending Confirmation"; in the "Payee Receives Funds" event, the summary might be "Customs Declaration No. BG202509180056, Verification Status: Verified". Step 6: Attach context fields: Directly populate the event object with static or quasi-static fields such as transaction amount, currency, counterparty account, and transaction fee to ensure that each event is independently readable.

[0020] After constructing a single event, the event synthesis unit checks whether the final state of the transaction has been reached (such as FUNDS_CREDITED or PAYMENT_FAILED). If the final state has not been reached, it continues to wait for subsequent normalization fields or triggers the timeout supplementation mechanism; if no new state clues are received within the preset maximum waiting time, the event synthesis unit will insert a "state timeout" exception event to close the event sequence.

[0021] Finally, all generated events are sorted in ascending order of event timestamp in the output buffer of the event synthesis unit. If events with the same timestamp are present, they are stably sorted according to the topological order of the state transition model. The sorted event sequence is serialized into a unified JSON structure to generate a standardized payment event sequence for the transaction. This sequence is then pushed in batches to the on-chain evidence storage module via a message queue for use by homomorphic hash aggregation and on-chain anchoring.

[0022] like Figure 2 The diagram shows the interface of the raw transaction data standardization processing system. According to the data source (a total of 8234 transactions from the banking system, 3561 transactions from the payment business system, and 1052 transactions from the cooperation structure system), the corresponding channels are configured for data collection. The acquired raw data is uniformly converted into a standardized payment event sequence (e.g., EVT-20260729-0001 payment initiation, EVT-20260729-0002 message sending, and EVT-20260729-0003 settlement processing, etc.) through the cross-border payment status transition model.

[0023] Through the collaborative work of the three units mentioned above, the data access and standardization module completes the full transformation from multi-source heterogeneous data to a consistent internal representation, providing a data foundation with a clear structure, consistent semantics, and verifiability for the upper-layer tracing engine and smart contract module.

[0024] Furthermore, to ensure the security of the upper layer operation, this solution maintains a consortium blockchain network consisting of payment participating nodes and regulatory nodes through a blockchain networking module. This consortium blockchain network deploys a transaction traceability sub-chain and an audit anchoring sub-chain.

[0025] When deploying the blockchain networking module, the first step is to distribute network access credentials to entities involved in cross-border payment transactions. These credentials use the X.509 digital certificate format, issued by the root certificate authority of the consortium blockchain, and embed node type identifiers and permission attributes in the certificate's extended fields. Nodes are divided into two main categories based on their business roles: payment participant nodes and regulatory nodes. Payment participant nodes are operated by direct participants in the payment chain, such as commercial banks, payment institutions, clearing network operators, and large corporate clients. Regulatory nodes are operated by financial regulatory agencies, foreign exchange management agencies, and anti-money laundering compliance departments. Each type of node has different consensus participation weights and data access permissions within the consortium blockchain network.

[0026] Meanwhile, the module's network topology adopts a peer-to-peer network structure based on the gossip protocol, with each node establishing an encrypted communication channel through a transport layer security protocol. During initial network boot, a seed node list is written to the configuration file of each node. After a new node starts up, it discovers its neighbors through the seed nodes and gradually synchronizes the entire network topology. The module maintains a view of all nodes in the network through a node liveness detection mechanism, sending heartbeat messages to neighboring nodes every 10 seconds. If a node does not respond within three consecutive heartbeat cycles, the node is marked as unavailable and a view update is triggered.

[0027] Correspondingly, regarding the consensus mechanism, the blockchain networking module adopts an improved practical Byzantine fault-tolerant consensus protocol for permissioned blockchains. The consensus node set consists of core members from the payment participating nodes, including major settlement banks and payment platforms. Regulatory nodes do not directly participate in block consensus but receive block synchronization data in real time through a subscription mechanism. The consensus process employs a master node rotation strategy; after each block is generated, the node rotates to the next master node according to the lexicographical order of its identifier, ensuring that each participant takes turns assuming the responsibility of block proposal. The maximum block size is configured to 2000 transaction records, and the block timeout is set to 1000 milliseconds. If the master node fails to complete the block proposal within the timeout period, a view change protocol is triggered, and the next master node takes over. This consensus mechanism ensures data consistency among nodes while controlling the final confirmation time of a single notarized transaction to within 3 seconds.

[0028] It is worth noting that, to ensure logical layering, the blockchain networking module in this solution divides the consortium blockchain into a transaction traceability sub-chain and an audit anchoring sub-chain. Both share the same underlying peer-to-peer network and consensus layer, but are independent in terms of data organization structure and access control. Figure 3The diagram shows the interface of a blockchain networking system. The sub-chain on the left is the transaction traceability sub-chain, and the sub-chain on the right is the audit anchoring sub-chain.

[0029] In terms of data organization, each notarized transaction in the consortium blockchain network carries a subchain attribution tag upon submission. This tag is set by the initiating node based on the data type. The transaction path aggregation root, the root hash of the sparse path aggregation tree, and the anomaly proof generated by the smart contract module all carry the transaction tracing subchain tag; the Merkle root and anchoring identifier of the compliance metadata set generated by the on-chain notarization module carry the audit anchoring subchain tag. When packaging blocks, consensus nodes mix transactions with both tags into the same physical block, regardless of their order. However, during block serialization and storage, consensus nodes split the block body into two logical partitions based on the tags: a transaction tracing partition and an audit anchoring partition. Each partition constructs a separate Merkle subtree, with the transaction order within the partition matching the order within the physical block. The leaf nodes of the partition's Merkle subtree are the hash values ​​of each transaction within that partition. The Merkle subtree roots of the two partitions serve as the transaction tracing Merkle root and the audit anchoring Merkle root, respectively, and are written into the same block header. When a node is synchronizing and querying, it can parse and index only the data of the corresponding partition according to its own permissions, thus logically presenting it as two independent sub-chains.

[0030] Regarding block header association, each physical block in the consortium blockchain has only one block header, which serves the logical verification of both the transaction tracing sub-chain and the audit anchoring sub-chain. The block header contains the following fields: previous block hash, block height, block timestamp, consensus node identifier, Merkle root of all transactions within the physical block, transaction tracing Merkle root, audit anchor Merkle root, and block hash. The previous block hash field stores the block hash value of the parent block, forming a unified chained hash pointer spanning the two logical sub-chains. The transaction tracing Merkle root is calculated solely from the hash values ​​of transactions within the transaction tracing partition, and the audit anchor Merkle root is calculated solely from the hash values ​​of transactions within the audit anchoring partition. The block hash is obtained by performing SHA-256 hash calculations on all fields in the block header except for the block hash itself. When payment participating nodes verify transaction tracing subchain data, they recalculate the hash path based on the transaction tracing Merkle root and the transaction list within that partition, and compare it with the transaction tracing Merkle root recorded in the block header. When regulatory nodes verify audit anchor subchain data, they perform the same independent verification based on the audit anchor Merkle root. The chained chaining mechanism of block hashes ensures that any tampering with data in any subchain partition will simultaneously destroy the corresponding partition's Merkle root and block hash, thus being detected by all nodes during block synchronization verification. Since the two subchains share the same chained hash pointer, the block containing the transaction path aggregation root written in the transaction tracing subchain and the block containing the anchor identifier written in the audit anchor subchain are the same physical block. The anchoring association between the two is naturally locked by the block hash, requiring no additional cross-chain communication protocol.

[0031] Through the design of the aforementioned network topology, consensus mechanism, logical layering, and access control, the blockchain networking module provides the entire system with a secure, efficient, and cross-border regulatory-compliant distributed ledger infrastructure, enabling the upper-layer on-chain evidence storage module and traceability engine module to operate reliably in a decentralized trust environment.

[0032] Furthermore, the on-chain evidence storage module is a core component connecting the data access layer and the blockchain networking layer. Its task is to transform standardized payment event sequences into verifiable on-chain evidence storage data and off-chain encrypted storage data, and to establish a cryptographic anchoring relationship between the transaction traceability sub-chain and the audit anchoring sub-chain. Internally, the on-chain evidence storage module is divided into a homomorphic hash operation unit, a symmetric encryption and off-chain storage unit, a sparse path aggregation tree construction unit, and a dual-chain anchoring unit. These four sub-units are sequentially connected and work together to complete the evidence storage process.

[0033] The homomorphic hashing unit receives standardized payment event sequences pushed by the data access and standardization modules. For a standardized payment event sequence of a payment transaction, the homomorphic hashing unit calculates the event hash for each event and performs ordered aggregation on all event hashes on the elliptic curve group to generate a compact transaction path aggregation root. The specific calculation formula is as follows: ; in, Indicates the event payload. Indicates event payload homomorphic hash value, Indicates event payload After normalized serialization, it is mapped to the scalar field using a cryptographic hash function. The numerical summary, and , The blinding factor is deterministically generated by the key derivation function using the transaction's unique identifier ID and the event sequence number as seeds. , Representing the elliptic curve group The first independent generator, Representing the elliptic curve group The second independent generator, and Represents scalar multiplication on the elliptic curve group. This represents point addition on the elliptic curve group; The corresponding transaction path aggregate root is calculated based on the event hash. The specific algorithm formula is as follows: ; in Represents the aggregate root of the transaction path, and represents the elliptic curve group. A point, Let represent the event hash of the i-th normalized payment event, and , This represents the total number of events in the standardized payment event sequence corresponding to this transaction.

[0034] The event hash is calculated using a homomorphic hash function. This homomorphism ensures that the path aggregation root can be incrementally updated and partially verified without recalculating all intermediate hashes. All intermediate aggregation values ​​generated during homomorphic aggregation are retained; these intermediate values ​​correspond to the sub-path aggregation roots from the first event to the k-th event and will be used as additional payloads for the sparse path aggregation tree, i.e.: ; in, This represents the homomorphic aggregation value of the hashes of the first k events, corresponding to the subpath aggregation root from the first event to the kth event, and... k represents the event sequence number, and . The corresponding symmetric encryption and off-chain storage unit receives the standardized payment event sequence processed by the homomorphic hashing unit. This unit independently encrypts each standardized payment event using a symmetric encryption algorithm. The encryption key is uniformly generated by the key management service and distributed to all authorized payment participating nodes through a secure channel. During encryption, each event is accompanied by a unique transaction identifier ID and event sequence number as additional authentication data to prevent replay or misalignment of the ciphertext. The encrypted ciphertext data packet is uploaded to the off-chain storage layer. The off-chain storage layer employs a distributed object storage system that operates based on a content addressing mechanism. After receiving the ciphertext data packet, it calculates its content hash and returns the hash value as a storage index. This storage index identifies the physical location of the ciphertext in the off-chain storage layer and also serves as a verification basis for the integrity of the ciphertext; any tampering with the ciphertext will result in a mismatch between the index and the content.

[0035] Standardized payment events The encryption uses the AES-256-GCM algorithm, and the encryption operation is represented as follows: ; in, This represents the ciphertext after the i-th event is encrypted. This indicates the message authentication tag generated in GCM mode, with a length of 128 bits. This represents the AES-256-GCM encryption function. This represents a 256-bit symmetric encryption key, generated by the key management service. This represents a 96-bit initialization vector, generated by a secure random number generator. Each event is generated independently to ensure global uniqueness. This represents the plaintext payload of the i-th standardized payment event after binary serialization. This indicates additional authentication data, which consists of a unique transaction identifier (ID) and an event sequence number. The corresponding storage index returned by the off-chain storage layer is generated by the content addressing mechanism, and its calculation method is as follows: ; in, This represents the storage index of the i-th encrypted event, a 32-byte hash value. This represents a secure hash algorithm with an output length of 256 bits. This indicates a byte string concatenation operation.

[0036] Subsequently, the sparse path aggregation tree construction unit utilizes the storage index generated by symmetric encryption and off-chain storage units, and the intermediate aggregation value generated by the homomorphic hashing unit, to construct a sparse path aggregation tree for each payment transaction. The leaf nodes of this tree consist of a storage index and the event hash of the corresponding event. Intermediate nodes, while aggregating lower-level nodes, embed the homomorphic hash intermediate aggregation value as an additional payload. Unlike traditional full binary Merkle trees, the sparse path aggregation tree expands only along the index paths of actual payment events; no nodes are generated at index positions where no events exist. This makes the tree's structural size linearly related to the number of payment events, rather than exponentially related to the possible index space size, significantly reducing storage and transmission overhead. The root node of the tree simultaneously stores the root hash and the complete transaction path aggregation root, binding the addressability of off-chain storage with the cryptographic commitment of on-chain notarization. After construction, this unit encapsulates the transaction path aggregation root and the root hash of the sparse path aggregation tree into transaction traceability notarization data and submits it to the transaction traceability sub-chain of the blockchain networking module.

[0037] The values ​​of the middle nodes in the corresponding sparse path aggregation tree are obtained by hashing the values ​​of their left and right child nodes. The specific calculation formula is as follows: ; in This represents the node value of the parent node, i.e., the intermediate aggregate value, a 32-byte hash digest. This represents the value of the left child node. If the left child node is a leaf node, then it is the event hash stored in that leaf node. Serialized bytes, This represents the value of the right child node, defined the same as the left child node. When the number of nodes at a certain level is odd, the last node is directly promoted, and this formula is not executed.

[0038] Finally, the dual-chain anchoring unit extracts a set of compliant metadata from the standardized payment event sequence. 'k' represents the total number of data items in the compliance metadata set. Compliance metadata is a subset of fields defined to meet regulatory review requirements. After extraction, the doubly-chained anchor unit calculates the Merkle root of the compliance metadata set to form a complete summary. The specific calculation method is as follows: First, calculate the leaf node hash for each compliant data item: ; in This represents the leaf node hash of the j-th compliant data item. This represents the j-th compliant data item, after being normalized and serialized into a byte string. Then, the parent node hash is calculated pairwise from bottom to top until the root is obtained. The formula for calculating the Merkle root of compliant metadata is as follows: ; in Represents a collection of compliance metadata Merkelgen, 32-byte hash value, This represents the standard Merkle tree root hash construction algorithm, which recursively performs pairwise hash concatenation on the leaf node hash sequences until a single root hash is produced.

[0039] Based on this, the dual-chain anchoring unit performs concatenated hashing on the compliance metadata Merkle root, the transaction path aggregation root of the same transaction, and the block hash of the transaction path aggregation root on the transaction traceability sub-chain to generate an anchoring identifier. The specific calculation formula is as follows: ; in Indicates anchoring identifier, This represents the block hash value (32 bytes) of the subchain block in the transaction path aggregation root. This indicates a byte string concatenation operation.

[0040] The anchor identifier, along with compliance metadata (Merkelgen), is encapsulated as compliance evidence data and submitted to the audit anchor subchain. The cryptographic significance of the anchor identifier lies in its inseparable binding of the compliance data in the audit anchor subchain to the specific payment path aggregation commitment and specific on-chain time point in the transaction tracing subchain. Any subsequent tampering with the compliance data or payment path data will prevent the anchor identifier from being recalculated and verified, thus being detected by regulatory nodes during independent audits.

[0041] Finally, as Figure 4 The diagram shows the interface for the evidence storage process. In the overall collaborative process, after the data access and standardization module outputs a standardized payment event sequence for a transaction, the homomorphic hashing unit first calculates the event hash and the path aggregation root. Subsequently, the symmetric encryption and off-chain storage unit encrypts the event and uploads it to the off-chain storage layer, retrieving the storage index. The sparse path aggregation tree construction unit receives the event hash, intermediate aggregation values, and storage index, completes the tree structure assembly, and produces the root hash, as shown below. Figure 5 The diagram shows the interface of the constructed sparse path aggregation tree system. The dual-chain anchoring unit synchronously extracts compliance metadata and calculates the Merkle root and anchoring identifier. Finally, the on-chain evidence storage module initiates evidence storage transactions to the transaction traceability sub-chain and the audit anchoring sub-chain respectively through the blockchain networking module. The two evidence storage transactions are logically related because they originate from the same batch of standardized payment events, and a non-repudiable temporal association is established through the block hash field in the anchoring identifier. This design allows payment participants to verify the integrity of the payment path from the transaction traceability sub-chain, and regulators to independently review compliance data from the audit anchoring sub-chain. The two achieve trusted linkage through the anchoring identifier without either party simultaneously holding full access rights to both types of data.

[0042] Furthermore, to identify anomaly proofs, this solution uses a smart contract module to perform state consistency verification on the standardized payment event sequence through an anomaly detection state machine. If the verification fails, an anomaly proof is generated and written to the transaction traceability subchain via the on-chain notarization module. The specific method is as follows: First, the smart contract module is a decentralized verification component deployed in the consortium blockchain network, and the smart contract module contains three sub-units: the expected state transition graph definition unit, the consistency verification unit, and the anomaly proof generation unit.

[0043] The expected state transition graph definition unit stores the legal state transition rules defined in cross-border payment transactions. These rules are organized in the form of a directed graph. The set of nodes in the graph represents all possible legal states in the payment lifecycle, including payment initiation, fund deduction, intermediary bank forwarding, settlement completion, recipient receipt, and payment failure. The set of edges in the graph represents the allowed transition relationships between states, with each edge corresponding to an event type. For example, the payment initiation state can only transition to the fund deduction state via the fund deduction event; the fund deduction state can transition to the intermediary bank forwarding state via the intermediary bank forwarding event; or it can directly transition to the payment failure state via the payment failure event. This state transition graph is written into the contract storage area as static data during smart contract deployment and can be upgraded later through the consortium blockchain governance mechanism.

[0044] Subsequently, the consistency verification unit receives the standardized payment event sequence output by the data access and standardization module, and drives the anomaly detection state machine to evolve state by event in ascending order of event timestamp. The initial state of the state machine is set to payment initiation. For each event in the sequence, the consistency verification unit extracts the event type of the event and queries the state transition graph to see if there is a valid transition edge matching the event type from the current state. If a matching transition edge exists, the state machine transitions to the target state along that edge, and the verification continues; If no matching transition edge exists, a state anomaly is determined to have occurred.

[0045] In addition to verifying the legality of state transitions, the consistency verification unit also performs a monetary consistency verification. The determination method for monetary consistency verification is as follows: When the event type involves fund changes, this unit extracts the actual transaction amount of the current event from the event context field and reads the expected amount from the cumulative state of the state machine, calculating the deviation between the actual amount and the expected amount. If the deviation exceeds a preset deviation threshold, an abnormal amount deviation is determined. The expected amount in the cumulative state is calculated one by one from the actual amount of the preceding events and the transaction fee expenditures. The initial expected amount comes from the application amount of the payment initiation event.

[0046] Finally, the anomaly proof generation unit is triggered when the consistency verification unit determines that the state or amount deviation is abnormal. The anomaly proof generation unit collects context data at the time of anomaly determination, including the event identifier that triggered the anomaly, the expected state at the time of the anomaly, the actual state or actual amount, deviation parameters, and the path segment from the initial event to the anomaly event. The path segment consists of the event identifiers and event types of all verified preceding events in sequence, used to completely describe the payment chain before the anomaly occurred. The anomaly proof generation unit serializes the above context data into structured binary data, digitally signs the data using the private key of the node where the smart contract resides, and generates an anomaly proof. The addition of the digital signature makes the source of the anomaly proof traceable and its content non-repudiable. After the anomaly proof is generated, it is submitted through the on-chain notarization interface of the smart contract, and the on-chain notarization module encapsulates it into a notarized transaction and writes it into the transaction traceability sub-chain, recording it in the same logical partition as the corresponding transaction path aggregation root record. Figure 6 The diagram shows the interface of the anomaly detection system. The left side of the diagram represents the detection workflow of the anomaly detection state machine, which sequentially goes through the following steps: initial normal state consistency, execution of legality verification and amount consistency verification, anomaly determination (state inconsistency), and transaction freezing. For example, if an event TX-2026729-0089 is detected as having an inconsistent event sequence, a corresponding anomaly proof is generated and stored on the blockchain. The right side of the diagram shows the specific functions of the smart contract in generating anomaly proofs, including the state verification type (legality verification and amount consistency verification), the anomaly detection mechanism, and the anomaly proof generation process. It also records the corresponding event pass rate (e.g., 156 events passed verification today) and the number of anomaly proofs (e.g., 3 anomaly detections today).

[0047] After being written into the transaction traceability subchain, the anomaly proof becomes an immutable record of the anomaly event for that payment transaction. When subsequent traceability operations are initiated, the traceability engine module can synchronously extract the anomaly proof from the transaction traceability subchain during the process of reconstructing the entire payment chain, and identify the node location and anomaly type where the anomaly occurred in the traceability results.

[0048] After completing the anomaly verification, the tracing engine module responds to the tracing request containing the target payment event identifier. It retrieves the corresponding sparse path aggregation tree and transaction path aggregation root from the transaction tracing sub-chain, obtains the encrypted standardized payment event from the off-chain storage layer, performs decryption, and reconstructs the payment end-to-end state transition sequence using the sparse path aggregation tree. By verifying the consistency between the reconstructed path aggregation root and the transaction path aggregation root recorded on-chain, it outputs the tracing result containing the payment path and compliance metadata. The specific method is as follows: The traceability engine module is a core component that provides users and regulatory agencies with trusted verification and visual query services for the entire payment chain. Deployed at the application layer, the traceability engine module is connected to the blockchain networking module and the off-chain storage layer through a network interface. It is responsible for responding to traceability requests initiated by external systems or users that include the identifier of the target payment event, and completing the five-stage processing flow of on-chain data acquisition, off-chain data decryption, payment path reconstruction, integrity verification, and result output.

[0049] During the on-chain data acquisition phase, the traceability engine module parses the received traceability request and extracts the target payment event identifier. The target payment event identifier can be a unique transaction identifier (ID) or a single payment event identifier. When the input is a single payment event identifier, the module first locates the unique transaction identifier (ID) of the corresponding transaction through the mapping relationship between the unique transaction identifier (ID) and the event sequence number. Using the unique transaction identifier (ID) as an index, the module initiates a query request to the transaction traceability sub-chain of the blockchain networking module to obtain the sparse path aggregation tree structure data and the transaction path aggregation root corresponding to the transaction. The sparse path aggregation tree structure data is returned in serialized form, containing the hierarchical relationship of all nodes in the tree, the storage index of each node, and intermediate aggregation values. Simultaneously, the module initiates a query to the audit anchoring sub-chain to obtain the compliance metadata Merkle root and anchor identifier corresponding to the transaction, used for subsequent integrity verification of compliance data.

[0050] During the off-chain data decryption phase, the tracing engine module traverses all leaf nodes of the sparse path aggregation tree, extracting the storage index stored in each leaf node to form a storage index list. The module uses this storage index list as a parameter to initiate batch data extraction requests to the off-chain storage layer. The off-chain storage layer returns the corresponding encrypted data packets based on the storage indexes. Each encrypted data packet contains ciphertext, an initialization vector, and a message authentication tag. The module calls the key management service to obtain the symmetric decryption key corresponding to the transaction and sequentially performs AES-256-GCM decryption on each encrypted data packet. During decryption, the initialization vector and message authentication tag in the encrypted data packet are used for integrity verification. The additional authentication data still uses the concatenation of the transaction's unique identifier ID and the event sequence number. The plaintext payload that passes the decryption verification is deserialized to recover the original standardized payment event object. After decryption, the module obtains all standardized payment events for the transaction.

[0051] During the payment path reconstruction phase, the traceability engine module sorts all decrypted standardized payment events in ascending order of event timestamps, forming a complete standardized payment event sequence. For events with the same timestamp, the module determines a stable sort by referring to the arrangement order of leaf nodes in the sparse path aggregation tree. The sorted event sequence is the full-link event record of the payment transaction. The module further transforms the event sequence into a full-link payment state transition sequence, extracting the event type, event subject, and event timestamp of each event, and arranging them on a timeline to form a state transition view. Simultaneously, the module extracts the payer account, payee account, intermediary bank account, transaction amount, and handling fee fields from each event, constructing a fund flow path graph with accounts as nodes and fund transfers as edges, and labeling the transfer amount and handling fee amount with the edge weights.

[0052] During the integrity verification phase, the tracing engine module uses the same homomorphic hash function as the on-chain evidence storage module to recalculate the transaction path aggregation root for the reconstructed standardized payment event sequence. The module calls the homomorphic hash operation unit to calculate the event hash for each event in the sequence, and then performs point addition aggregation on the elliptic curve group on all event hashes to obtain the reconstructed path aggregation root. The specific calculation formula is as follows: ; in This represents the event hash of the i-th event in the reconstructed sequence. This represents the i-th standardized payment event after being decrypted and sorted from the off-chain storage layer. Indicates event payload Numerical summary, The blinding factor is generated deterministically by a derivation function of the same key using the unique identifier ID of the transaction and the event sequence number, consistent with the one recorded on the chain. Corresponding reconstructed path aggregate root for: .

[0053] The module compares and verifies the reconstructed path aggregate root with the on-chain transaction path aggregate root obtained from the transaction tracing subchain. The verification equation is that the reconstructed path aggregate root and the on-chain transaction path aggregate root are equal on the elliptic curve group. ,in This represents the aggregate root of the on-chain transaction path obtained from the transaction tracing subchain. If the verification passes, then... This indicates that the event sequence stored off-chain has not been tampered with since the evidence was uploaded to the chain, and the payment path is complete and reliable. The module will then append a verification pass flag to the tracing results. If the verification fails, i.e. In the traceability results, the module marks the data integrity verification failure and locates the deviation information that is inconsistent between the reconstructed path aggregation root and the record on the chain. At this time, the module uses the structural characteristics of the sparse path aggregation tree to compare the intermediate aggregation values ​​layer by layer. Starting from the root node, it recursively compares the homomorphic hash payload of each intermediate node with the aggregation value of the corresponding subset of the reconstruction calculation to locate the node where the inconsistency first occurs. The event subset covered by this node is the link where the data deviation exists. The deviation location information is output to the traceability results along with the verification failure mark.

[0054] During the results output phase, the traceability engine module integrates the payment end-to-end state transition sequence, fund flow path diagram, compliance metadata, and integrity verification results into a traceability result object. For the compliance metadata part, the module obtains the compliance metadata Merkle root from the audit anchor sub-chain and uses on-chain anchor identifiers to verify whether the anchor association between the compliance metadata and the transaction path aggregation root is consistent.

[0055] The traceability result object consists of four parts: The basic information section lists the transaction's unique identifier ID, transaction amount, currency, and payment status; the payment path section displays the entire status transition nodes from payment initiation to final receipt or failure in a timeline format, with each node labeled with an event timestamp, event type, event subject, and event summary; the fund flow section displays the flow routes of funds between accounts in a directed graph format, labeling the amount and transaction fees for each segment; and the compliance information section displays compliance metadata, anchor verification results, and a list of anomaly proofs associated with the transaction. The traceability result object is serialized into a structured data format and returned to the traceability requester, completing the entire traceability query process. Figure 7 The figure shows the interface of the target payment event identification and tracing system. As shown, during the specific event tracing process, the corresponding target payment event sequence (e.g., EVT-20260729-003) is first entered in the tracing window. Then, the tracing engine module performs a five-stage processing flow for the target payment event, which includes on-chain data acquisition, off-chain data decryption, payment path reconstruction, integrity verification, and result output. The specific tracing results, such as the aggregate root consistency verification result, are displayed in real time through the tracing verification details on the right.

[0056] This invention decomposes payment transactions into standardized payment event sequences and uses homomorphic hash aggregation roots to condense the entire payment path. Only the aggregation root and the sparse path aggregation tree root are written to the blockchain, ensuring the immutability of the path while avoiding the uploading of detailed data to the chain. Through a two-layer chain anchoring mechanism, a privacy-oriented transaction traceability sub-chain and a regulatory audit anchoring sub-chain are separated. Regulatory nodes only obtain compliance metadata and anchoring identifiers and can verify the anchoring association to confirm that the data has not been tampered with without accessing the transaction details. An anomaly detection state machine is embedded in the smart contract, automatically verifying the compliance of state transitions. Anomaly proofs are uploaded to the chain to form an auditable anomaly event record. The entire system achieves full-process verifiable traceability of payment data in a distributed trust environment, solving the problems of data tampering and privacy leakage in centralized solutions.

[0057] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based cross-border financial payment transaction data traceability system, characterized in that: It includes a data access and standardization module, a blockchain networking module, an on-chain evidence storage module, a smart contract module, and a traceability engine module; The data access and standardization module obtains the original transaction data and related business documents of the entire cross-border payment chain from the banking system, payment business system and cooperative institution system through multi-protocol interfaces, and transforms the original transaction data into a standardized payment event sequence that conforms to a unified data model; The blockchain networking module is used to maintain a consortium blockchain network consisting of payment participating nodes and regulatory nodes, in which a transaction traceability sub-chain and an audit anchoring sub-chain are deployed. The on-chain evidence storage module is used to perform homomorphic hash aggregation on the standardized payment event sequence to generate a transaction path aggregation root, and to perform the following: Each standardized payment event in the standardized payment event sequence is symmetrically encrypted and written into the off-chain storage layer, and a corresponding storage index is generated. The storage index and the intermediate nodes formed by homomorphic hash aggregation are combined to construct a sparse path aggregation tree, and the transaction path aggregation root and the root hash of the sparse path aggregation tree are written into the transaction traceability sub-chain. The set of compliance metadata extracted based on the standardized payment events is written into the audit anchoring subchain, and an anchoring association is established between the transaction path aggregation root on the transaction traceability subchain and the set of compliance metadata on the audit anchoring subchain. The smart contract module is deployed on the consortium blockchain network and is used to perform state consistency verification on the standardized payment event sequence through the anomaly detection state machine. When the verification fails, an anomaly proof is generated and the anomaly proof is written into the transaction traceability subchain through the on-chain evidence storage module. The traceability engine module is used to respond to traceability requests containing the target payment event identifier, obtain the corresponding sparse path aggregation tree and transaction path aggregation root from the transaction traceability sub-chain, obtain the encrypted standardized payment event from the off-chain storage layer, perform decryption and reconstruct the payment end-to-end state transition sequence using the sparse path aggregation tree, and output traceability results containing payment path and compliance metadata by verifying the consistency between the aggregation root of the reconstructed path and the transaction path aggregation root recorded on the chain.

2. The blockchain-based cross-border financial payment transaction data traceability system according to claim 1, characterized in that, Each standardized payment event in the standardized payment event sequence of the data access and standardization module includes at least a payment event identifier, event type, event subject, event timestamp, and associated business summary.

3. The blockchain-based cross-border financial payment transaction data traceability system according to claim 2, characterized in that, The data access and standardization module is composed of a protocol adaptation unit, a data cleaning and conversion unit, and an event synthesis unit connected in sequence. The protocol adaptation unit is configured with multiple communication interfaces to interface with external systems of different technical forms; The data cleaning and conversion unit reads the raw data from the buffer layer and selects the corresponding parser according to the source system identifier; The event synthesis unit receives the set of normalized fields output by the data cleaning and transformation unit, and breaks down cross-border payment transactions into an ordered sequence of standardized payment events according to a predefined cross-border payment state transition model.

4. The blockchain-based cross-border financial payment transaction data traceability system according to claim 3, characterized in that, The predefined cross-border payment state transition model in the event synthesis unit is stored in the form of a directed graph, where nodes represent legitimate states in the payment lifecycle, including but not limited to: Payment initiation, fund deduction, intermediary bank forwarding, clearing completion, recipient receiving funds, payment failure, refund initiation; The edges of the graph represent allowed state transitions, and each edge is bound to an event type identifier.

5. The blockchain-based cross-border financial payment transaction data traceability system according to claim 3, characterized in that, The method for transforming standardized payment event sequences in the event synthesis unit includes the following steps: S1. Read the transaction unique identifier ID from the normalized field and combine it with the event counter maintained inside the event synthesis unit to generate a payment event identifier; S2. Based on the target state reached on the state transition diagram, select the corresponding event type from the enumeration set; S3. Identify the responsible party from the normalized fields based on the event type; S4. Use the exact time when the status change occurred in the original data; If no precise time is available, then take the bank's acceptance time, message writing time, or reception time in sequence, and add a time source mark; S5. Extract non-payment information related to the event timeline from the normalized fields, and call the summary generation algorithm to generate a related business summary; S6. Directly populate the event object with static or quasi-static fields such as transaction amount, currency, counterparty account, and transaction fee, and attach context fields.

6. The blockchain-based cross-border financial payment transaction data traceability system according to claim 1, characterized in that, The transaction traceability sub-chain and audit anchoring sub-chain in the blockchain networking module share the same underlying peer-to-peer network and consensus layer, and are independent of each other in terms of data organization structure and access control.

7. The blockchain-based cross-border financial payment transaction data traceability system according to claim 3, characterized in that, The on-chain evidence storage module includes a homomorphic hash operation unit, a symmetric encryption and off-chain storage unit, a sparse path aggregation tree construction unit, and a dual-chain anchoring unit. The homomorphic hashing unit is used to receive the standardized payment event sequence pushed by the data access and standardization module, and to calculate the event hash for each event using the homomorphic hashing unit, and to perform ordered aggregation on all event hashes on the elliptic curve group to generate a compact transaction path aggregation root. The symmetric encryption and off-chain storage unit receives the standardized payment event sequence processed by the homomorphic hash operation unit, and independently encrypts each standardized payment event using a symmetric encryption algorithm; The sparse path aggregation tree construction unit uses the storage index generated by the symmetric encryption and off-chain storage unit and the intermediate aggregation value generated by the homomorphic hash operation unit to construct a sparse path aggregation tree for each payment transaction. The dual-chain anchoring unit extracts a set of compliant metadata from a standardized payment event sequence, calculates a Merkle root for the compliant metadata set to form a complete summary, and performs concatenated hashing on the compliant metadata Merkle root, the transaction path aggregation root of the same transaction, and the block hash of the transaction path aggregation root on the transaction traceability subchain to generate an anchoring identifier.

8. The blockchain-based cross-border financial payment transaction data traceability system according to claim 1, characterized in that, The smart contract module includes an expected state transition graph definition unit, a consistency verification unit, and an anomaly proof generation unit. The expected state transition graph definition unit is used to store the legal state transition rules defined in cross-border payment business, and the legal state transition rules are organized in the form of a directed graph; The set of nodes in the graph represents all possible legal states in the payment lifecycle; The set of edges in a graph represents the allowed transitions between states, and each edge corresponds to an event type; The consistency verification unit receives the standardized payment event sequence output by the data access and standardization module, and drives the anomaly detection state machine to perform state evolution in ascending order of event timestamps. For each event in the sequence, the consistency verification unit extracts the event type of the event and queries the state transition graph to see if there is a valid transition edge matching the event type starting from the current state. If a matching transition edge exists, the state machine transitions to the target state along that edge, and the verification continues; If no matching transition edge exists, a state anomaly is determined to have occurred; Simultaneously, the consistency verification unit also performs an amount consistency verification: When the event type involves fund changes, the unit extracts the actual transaction amount of the current event from the event context field, reads the expected amount from the cumulative state of the state machine, and calculates the deviation between the actual amount and the expected amount. If the deviation value exceeds the preset deviation threshold, an abnormal amount deviation is determined to have occurred. The anomaly proof generation unit is triggered when the consistency verification unit determines that the state is abnormal or the amount deviates abnormally. It collects the context data at the time of the anomaly determination, serializes the context data into structured binary data, and digitally signs the data using the private key of the node where the smart contract is located to generate an anomaly proof.

9. The blockchain-based cross-border financial payment transaction data traceability system according to claim 1, characterized in that, The method for outputting traceability results containing payment path and compliance metadata in the traceability engine module includes the following steps: S1. Parse the received tracing request, extract the target payment event identifier, and perform on-chain data acquisition; S2. Traverse all leaf nodes of the sparse path aggregation tree, extract the storage index stored in each leaf node, and perform off-chain data decryption. S3. Arrange all the decrypted standardized payment events in ascending order of event timestamps to form a complete standardized payment event sequence, and then perform payment path reconstruction. S4. Using the same homomorphic hash function as the on-chain evidence storage module, recalculate the transaction path aggregation root for the reconstructed standardized payment event sequence and perform integrity verification; S5. Integrate the payment end-to-end state transition sequence, fund flow path diagram, compliance metadata, and integrity verification results into a traceability result object and output the execution result.

Images