Monitoring and auditing method based on blockchain finance payment and clearing

Abstract

A monitoring and auditing system based on blockchain finance payment and clearing. The system comprises a verification center for managing, verifying, and querying transactions, and the verification center is provided with a credentials authorization module; the verification center is provided as a centralized monitoring and auditing tool for blockchain finance payment and clearing to make up for regulatory vulnerabilities of a blockchain decentralized system; and the verification center is used as an international compliance data center and shares risk intelligence with global regulatory institutions.

Description

A monitoring and auditing method for blockchain-based financial payment and settlement

[0001] This invention relates to a monitoring and auditing method for blockchain-based financial payment and settlement.

[0002] Since 1973, the Society for Worldwide Interbank Financial Telecommunication (SWIFT) has been a mainstay of global cross-border transactions. It operates as a messaging network, enabling financial institutions to securely transmit payment instructions. However, SWIFT does not directly process fund transfers; instead, it relies on a network of correspondent banks for transaction settlement. This process introduces multiple intermediaries, leading to delays (typically 1-5 days), increased costs (including intermediary fees and foreign exchange), and a lack of transparency in transaction tracking. While SWIFT's standardized messaging (MT / MX format) ensures interoperability, its centralized architecture and legacy infrastructure are inefficient in today's demands for instant, low-cost transactions.

[0003] Blockchain technology is a decentralized ledger system that overcomes the limitations of SWIFT (Society for Worldwide Interbank Financial Telecommunication), bringing transformative potential to clearing and settlement, and possessing the following characteristics:

[0004] • Decentralization:

[0005] Transactions do not rely on traditional financial institutions (such as banks), but are verified by a decentralized network of nodes, thereby eliminating centralized regulation.

[0006] • The Paradox of Transparency and Anonymity:

[0007] Transaction records are publicly accessible (such as the Bitcoin blockchain), but addresses are not directly associated with real-world identities, thus creating "anonymity."

[0008] •Unalterable:

[0009] Data on a blockchain cannot be altered once recorded. However, this also makes it technically impossible to reverse illicit transactions, such as money laundering.

[0010] However, applying blockchain technology to the field of virtual currency will face the following challenges:

[0011] 1. Risks of Anonymous Abuse and Money Laundering

[0012] 2. Cross-border transactions and regulatory arbitrage

[0013] • Global instant settlement:

[0014] Virtual currencies can be transferred instantly across jurisdictions (e.g., via cross-chain bridges), thereby circumventing local regulations.

[0015] • Fragmented supervision:

[0016] Differences in the regulations governing different virtual currencies (e.g., U.S. assets versus EU financial instruments) have hindered international harmonization.

[0017] 3. DeFi (Decentralized Finance) faces compliance challenges.

[0018] • Lack of accountability:

[0019] Decentralized protocols lack a centralized entity to enforce anti-money laundering obligations, such as the "Travel Rule" regulatory requirements of the FATF Financial Action Task Force on Money Laundering.

[0020] • Flash loan vulnerability:

[0021] Attacks exploiting smart contract vulnerabilities (such as the $182 million Beanstalk hack in 2022) highlight the risks of automated systems.

[0022] Therefore, the core technological characteristics of cryptocurrencies—decentralization, cryptographic privacy, and smart contracts—are both the driving force behind innovation and the root of regulatory complexity. Effective regulatory measures are necessary to bridge the regulatory gaps in "decentralization," balance privacy and transparency, and mitigate the risks associated with smart contracts.

[0023] In traditional financial systems, the classification and identification of transaction risks are well-established. Common types of risk include credit risk, market risk, operational risk, liquidity risk, and legal compliance risk.

[0024] To address the aforementioned shortcomings of existing technologies, this invention proposes a monitoring and auditing method for blockchain-based financial payment and settlement, with the specific solution as follows.

[0025] This invention provides:

[0026] A monitoring and auditing method for blockchain-based financial payment clearing includes a monitoring and auditing system with a verification center, a financial payment clearing system deployed to the clearing parties, and a blockchain-based distributed ledger system.

[0027] The verification center includes a risk management module, a whitelist management module, and a credential authorization module.

[0028] The verification center assigns wallet addresses to each financial payment and clearing system;

[0029] The certificate authorization module issues, verifies, and queries trust certificates for signing financial payment and clearing transactions through the monitoring and auditing system of all parties involved in the settlement and clearing process.

[0030] During financial payment and settlement transactions, the initiator and the recipient collect and record customer information (KYC) and / or business information (KYB) transaction details and proof of transaction purpose through their respective financial payment and settlement systems, and generate archived record forms of KYC and / or KYB transaction details and proof of transaction purpose, and transmit the archived record forms to the verification center.

[0031] The initiator's financial payment and clearing system uses its trust credentials to sign and encrypt the transaction information, and publishes the encrypted transaction information to the distributed ledger system. The distributed ledger system sends the wallet addresses of the initiator and the recipient to the whitelist management module of the verification center for authentication. After authentication, the financial payment and clearing transaction initiated by the initiator is recorded on the blockchain to the distributed ledger system and a notification is sent to the recipient.

[0032] The recipient obtains financial payment and settlement transaction information from the distributed ledger system and uses its trust credentials to decrypt the transaction and complete the transaction;

[0033] The verification center's transaction monitoring module monitors all financial payment and settlement transactions and identifies suspicious transactions;

[0034] When a suspicious transaction report is received, the verification center sends KYC and / or KYB transaction details and proof of transaction purpose to the initiator and recipient. The risk management module then verifies the risk of the transaction and updates the trust credentials of both parties involved in the transaction and the information in the whitelist management module based on the verification results.

[0035] Furthermore, in addition to the credential authorization module, the trust credential can also be issued by a third-party credential issuing institution to the monitoring and auditing systems of all parties for signing financial payment and clearing transactions. This includes financial institutions that have obtained the trust of the verification center, web3 wallet providers, and other third-party trust credential issuing institutions.

[0036] Furthermore, the risk management module includes a risk data collection program that collects transaction data from financial institutions, suspicious transaction reports from financial institutions, on-chain transaction behavior data, address profile data, external compliance data, and public opinion data.

[0037] And transaction monitoring programs, which use data collected by risk data collection programs to detect suspicious transactions.

[0038] Furthermore, the transaction monitoring program includes a heterogeneous graph data modeling algorithm that utilizes financial institution transaction data to construct financial payment and settlement data.

[0039] Construct a heterogeneous graph containing nodes and relationship edges related to financial payment and settlement. The nodes in the heterogeneous graph include wallet address nodes, transaction nodes, smart contract nodes, and ownership entity nodes, while the relationship edges include transfer edges, usage edges, and deployment edges.

[0040] Furthermore, the transaction monitoring program includes a multi-wallet graph clustering algorithm for identifying the main entity:

[0041] S1-1. Using the node features and relation edge features in the heterogeneous graph, extract the structural similarity, common interaction addresses, and common counterparty features of wallet addresses;

[0042] S1-2. Use graph neural networks for feature embedding to map high-dimensional heterogeneous graph data to a low-dimensional vector space;

[0043] S1-3. Apply clustering algorithms to group low-dimensional vectors, identify multiple wallet address clusters controlled by the same entity, and generate a wallet entity clustering graph;

[0044] S1-4. Determine suspicious transactions based on the wallet entity clustering graph obtained from the analysis.

[0045] Furthermore, the transaction monitoring program includes a multi-hop path expansion and filtering algorithm:

[0046] S2-1. Using the established heterogeneous graph, starting from the target wallet address node, set the maximum search depth, and use the path search algorithm to perform forward or reverse multi-hop path traversal along the transfer edge in the heterogeneous graph to extract the associated transaction subgraph of the target node.

[0047] S2-2. Filter relation edges or path segments in real time during path expansion;

[0048] S2-3. Output the transaction path after being filtered by the constraint rules, whereby the transaction path represents the trajectory of fund flow from the starting address to the target address;

[0049] S2-4. Identify suspicious transactions based on fund flow patterns.

[0050] Furthermore, the transaction monitoring program includes a graph neural network-based algorithm for identifying hidden fund paths in the blockchain:

[0051] S3-1. Obtain known financial institution transaction data, financial institution suspicious transaction reports, on-chain transaction behavior data, address profile data, external compliance data, and public opinion data from the risk data collection program to construct a sample set of hidden fund paths and a sample set of normal transaction paths;

[0052] S3-2. Based on heterogeneous graphs, multi-dimensional features are assigned to nodes and edges of various types;

[0053] The node characteristics include at least one of the following or a combination thereof: transaction frequency of wallet address, average transaction amount, first active time, last active time, correlation with blacklisted addresses, and address type label;

[0054] The edge features include at least one of the following or a combination thereof: transaction amount, transaction timestamp, transaction frequency, transaction direction, gas consumption, and degree of matching with typical money laundering patterns;

[0055] S3-3. Implicit path feature extraction based on graph representation learning: Input heterogeneous graphs and labeled samples into the graph representation learning model for training, and automatically learn the implicit feature representations of nodes and paths in the graph;

[0056] The graph representation learning model iteratively aggregates the feature information of neighboring nodes to generate the embedding vector representation of each node in a low-dimensional space, and further extracts path-level feature representations based on the node embeddings.

[0057] The graph representation learning models include, but are not limited to, graph neural network models based on neighbor information aggregation, graph embedding models based on random walks, or graph representation learning methods based on matrix factorization.

[0058] S3-4. Hidden Path Classification and Recognition: The extracted path feature representations are input into the classification model to train the classifier to identify the pattern features of hidden fund paths;

[0059] The classification model outputs a probability value or risk score for each candidate path to belong to a hidden funding path;

[0060] When the risk score of the identified path exceeds the preset threshold, the path is marked as a "suspicious hidden funds path", and the key node addresses and transaction hashes on the path are extracted;

[0061] S3-5. Critical Path Segment Identification: By analyzing the degree of attention the model pays to each node and edge during the classification decision process, the critical path segments that contribute the most to the judgment result are identified.

[0062] The critical path segment includes at least key intermediate nodes of fund flow, abnormal transaction edges, or sub-path structures that conform to a specific concealment pattern;

[0063] S3-6. Risk Management: Identify suspicious hidden funding paths and report suspicious transactions.

[0064] Furthermore, the transaction monitoring program includes a cross-chain bridge behavior recognition algorithm:

[0065] S4-1. Cross-chain entity feature extraction: Identify the smart contract address of the cross-chain bridge protocol from the distributed ledger system and mark it as a cross-chain bridge contract node in the heterogeneous graph. Record the cross-chain transaction edge features flowing through the node. The features include: outgoing chain identifier, incoming chain identifier, token type, transaction amount and transaction timestamp.

[0066] S4-2. Cross-chain data shadow mapping: For assets that flow out of the source chain and reappear on the target chain, a cross-chain shadow mapping table is constructed, and transactions before and after the cross-chain are associated through a preset time window pairing strategy;

[0067] S4-3. Heuristic Matching of Cross-Chain Behavior: Execute a multi-factor matching algorithm in the shadow mapping table to identify cross-chain transaction pairs that meet the following conditions:

[0068] Time correlation: The time interval between the source chain transfer-out time and the target chain transfer-in time is within a preset time window threshold;

[0069] Numerical consistency: After considering cross-chain transaction fees and slippage losses, the ratio of the difference between the amount transferred out of the source chain and the amount transferred in to the target chain is lower than a preset threshold.

[0070] Protocol consistency: Both parties to the transaction have interaction records with the same cross-chain bridge contract node;

[0071] S4-4. Cross-chain path completion: Logically connect the successfully matched cross-chain transaction pairs in the heterogeneous graph through cross-chain transaction edges to eliminate the trajectory breaks caused by cross-chain and complete the full-link capital flow graph.

[0072] S4-5. Cross-chain risk identification: Based on the completed end-to-end graph, analyze abnormal patterns of funds being laundered, split, or layered through cross-chain bridges, and generate suspicious transaction reports.

[0073] The beneficial effects of this invention are as follows: By establishing a verification center as a centralized monitoring and auditing center for blockchain-based financial payment and settlement, regulatory loopholes in decentralized blockchain systems are mitigated. Transaction information deployed to the blockchain ledger is similar to that of ordinary virtual currencies, such as transaction hashes, initiator addresses, recipient addresses, transaction amounts, and digital signatures. Transaction purpose information is additional transaction information added to the blockchain ledger to meet regulatory requirements. Therefore, KYC / KYB transaction details and proof of transaction purpose, among other private information, are not leaked in the blockchain ledger, thus maintaining the anonymity of the blockchain. All parties participating in the blockchain-based financial payment and settlement service system must authenticate their trust through trust credentials before processing transactions and deploy transaction information (such as initiator addresses, recipient addresses, and digital signatures) so that the verification center can track every transaction on the blockchain. Trustees must store KYC / KYB information and proof of transaction purpose internally for regulatory monitoring and auditing. Upon receiving a Suspicious Transaction Report (STR) or a request from a regulatory agency, the initiator address and recipient must transmit KYC / KYB information and proof of transaction purpose to the verification center to verify transaction risks and maintain risk records. As an international compliance information center, the verification center shares risk intelligence (such as suspicious transaction patterns) with regulatory agencies worldwide.

[0074] Figure 1

[0075] This is a system architecture diagram of the present invention. Figure 2

[0076] This is an architecture diagram of the verification center, clearing and settlement system, and distributed ledger system in this invention. Figure 3

[0077] This is a flowchart of the multi-wallet graph clustering algorithm for identifying the main body according to the present invention. Figure 4

[0078] This is a flowchart of the multi-hop path expansion and filtering algorithm of the present invention. Figure 5

[0079] This is a flowchart of the cross-chain bridge behavior recognition algorithm of the present invention.

[0080] To more clearly illustrate the technical solution of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the following embodiments are for illustrative purposes only and do not constitute a limitation thereof.

[0081] Financial payment and settlement monitoring and auditing system

[0082] This includes verification centers, financial payment clearing systems deployed by the clearing parties, and blockchain-based distributed ledger systems.

[0083] The verification center includes a risk management module, a whitelist management module, and a credential authorization module.

[0084] The verification center assigns wallet addresses to each financial payment and clearing system;

[0085] The credential authorization module issues, verifies, and queries trust credentials used by the monitoring and auditing systems of all parties involved in financial payment and settlement transactions. This module manages these trust credentials, issuing them to each financial payment and settlement system. It includes a root certificate management center and regional verification centers. The root certificate management center issues root certificates to the corresponding regional verification centers, which then issue leaf certificates to verification centers in various countries. Finally, the national verification centers issue trust credentials to their subordinate financial payment and settlement systems.

[0086] The transaction whitelist management module is used to manage the transaction whitelist.

[0087] The risk management module is used to monitor all financial payment and settlement transactions and identify suspicious transactions. It has a built-in risk management program, which includes a risk data collection program that collects transaction data from financial institutions, suspicious transaction reports from financial institutions, on-chain transaction behavior, address profiling data, external compliance data, and public opinion data.

[0088] Distributed ledger systems provide distributed ledger management for financial payment and settlement, such as blockchain networks like Ethereum and TRON.

[0089] Monitoring and auditing methods for financial payment and settlement

[0090] Transaction Initiation: When initiating a transaction, the initiator collects detailed KYC / KYB transaction information and proof of transaction purpose. In accordance with the requirements of the verification center, the initiator generates an archive record form based on the collected detailed KYC / KYB transaction information and proof of transaction purpose, and transmits it to the verification center. The items and contents of the archive record form will be provided in detail later.

[0091] Transaction signing and publication: The initiator's monitoring and auditing system uses its trust credentials to sign and encrypt the transaction information for financial payment and settlement, and publishes the encrypted transaction information to the distributed ledger system.

[0092] Whitelist authentication: The distributed ledger system sends the wallet addresses of the initiator and the receiver to the transaction whitelist management module of the verification center for authentication. After successful authentication, the clearing and settlement transaction initiated by the initiator is recorded on the distributed ledger system.

[0093] Transaction Receipt and Signature: The recipient obtains financial payment and settlement transaction information from the distributed ledger system and uses its trust credentials to decrypt the transaction and complete the transaction.

[0094] Transaction monitoring: The risk management module of the verification center monitors all financial payment and settlement transactions and identifies suspicious transactions.

[0095] Suspicious Transaction Reporting and Verification: When a Suspicious Transaction Report (STR) is generated, the verification center requires the initiator and recipient to provide detailed KYC / KYB transaction information and proof of transaction purpose, verify the risk of the transaction, and update the trust credentials of both parties involved in the transaction and the information in the whitelist management module.

[0096] The transaction whitelist management module is used to maintain and manage the transaction whitelist, and includes the following functions:

[0097] Whitelist creation: Allows users to create new whitelists and define the scope of application of the whitelists (such as specific accounts or specific transaction types).

[0098] Adding to the whitelist: Allows users to add accounts, addresses, or other transaction-related entities to the whitelist. Manual addition and batch import are supported.

[0099] Whitelist review: Review whitelist applications to ensure they meet compliance requirements.

[0100] Whitelist Update: Allows users to update whitelist information, such as changing account names, addresses, etc.

[0101] Whitelist deletion: Allows users to delete items from the whitelist that are no longer needed.

[0102] Whitelist query: Allows users to query whitelist information, such as viewing the list of accounts in the whitelist, the scope of application, etc.

[0103] Whitelist synchronization: Synchronize whitelist data to the transaction monitoring module to ensure that the transaction monitoring process can correctly identify whitelist transactions.

[0104] Risk Management Module

[0105] It includes the following core programs:

[0106] I. Risk Data Collection Procedure

[0107] The risk data collection program is responsible for collecting data from the following data sources:

[0108] Financial institution transaction data originates from various financial institutions (including banks, exchanges, payment institutions, etc.) and supports multiple data formats and protocols (such as CSV, JSON, XML, and API), including:

[0109] (1) Order depth: The distribution of buy and sell orders in the order book, reflecting market liquidity.

[0110] (2) Transaction data: Historical transaction records, including price, quantity, time, etc.

[0111] (3) Abnormal account markers: Suspicious accounts identified by financial institutions, such as those that frequently engage in large transactions or have unusual counterparties.

[0112] Its compliant use is to identify manipulation: by analyzing order book depth and transaction data, market manipulation behaviors can be detected, such as pump and dump, and fraudulent transactions. Wash trading: detects fraudulent transactions between related accounts, the purpose of which is to artificially inflate or depress prices.

[0113] Suspicious Transaction Reports (STRs) from financial institutions: These reports collect historical suspicious transaction data to train models and improve rules. The data originates from suspicious transactions identified within financial institutions, including account information, transaction details, and reasons for suspicion. Its compliance purpose is to identify illegal transactions or violations involving insiders, such as insider trading.

[0114] On-chain transaction data: This data originates from various blockchain networks (e.g., Bitcoin, Ethereum) and includes information on transfer transactions (including transaction hashes, sending addresses, receiving addresses, transaction amounts, timestamps, etc.), cross-chain transactions (asset transfer records between different blockchain networks), and address balances (the amount of assets held at each blockchain address). Its compliant use is for KYC-based money laundering checks on addresses without KYC verification, identifying suspicious transactions associated with addresses that may be used for money laundering. Data is obtained using blockchain explorer APIs or node connections.

[0115] Address profiling data: This data collects information such as tags, risk scores, and related transactions associated with addresses. The data comes from blockchain analytics companies and security agencies, and includes blacklisted addresses (addresses known to be associated with illegal activities, such as ransomware attacks and darknet markets), aggregated tags (categorization and labeling of addresses, such as exchange addresses, mining pool addresses, and mixer addresses), and frozen asset identifiers (addresses of assets frozen by law enforcement or exchanges). Its compliant use is to determine whether an entity is associated with sanctioned or high-risk entities (identifying whether a counterparty is associated with a sanctioned or high-risk entity).

[0116] External compliance data: This includes collecting sanctions lists, blacklists, and lists of high-risk countries. Data is obtained from authoritative institutions (such as OFAC and the United Nations) and updated regularly. The data originates from government agencies and international organizations (such as OFAC, FATF, and the UN), covering content such as OFAC sanctions lists (sanctions lists published by the US Treasury Department's Office of Foreign Assets Control, including individuals, companies, and countries), FATF blacklists (blacklists published by the Financial Action Task Force, including countries and regions that have failed to effectively combat money laundering and terrorist financing), and UN blacklists (sanctions lists published by the United Nations). Its compliance purpose is to prevent fund transfers between exchanges and sanctioned addresses, ensuring that exchanges do not transact with sanctioned entities and avoid violating sanctions regulations.

[0117] Public opinion data: This data is collected from news reports, social media posts, etc., to identify negative information related to money laundering, fraud, etc. Natural Language Processing (NLP) technology is used to analyze the text content. The data originates from news media, social platforms, forums, the dark web, etc., and includes information on black and gray market activities (discussions and transaction information related to illegal activities), topics on fraudulent fund flows (discussions about fraud cases and analysis of fund flows), and identification of ransomware-related wallets (identifying wallet addresses associated with ransomware attacks). Its compliant use is to proactively identify risks of illicit funds: by monitoring public opinion data, potential illicit fund flows can be detected in advance, and corresponding measures can be taken.

[0118] By leveraging a novel on-chain KYC mechanism, a connection is established between real users and on-chain addresses, linking KYC information and travel rule information from traditional financial institutions with on-chain transactions, forming a unified database that combines off-chain and on-chain data.

[0119]

[0120] II. Transaction Monitoring Program

[0121] It includes the following algorithms for calculating and detecting suspicious transactions.

[0122] Identifying hidden fund flows through graph computing: This involves tracing fund flows across multiple wallets, chains, and layers, combining transaction graphs from financial payment and settlement (heterogeneous graph data modeling) with graph neural networks (GNNs) and path search algorithms to achieve this complex fund flow tracking. Specifically, it is implemented through the following algorithms:

[0123] (1) Heterogeneous graph data modeling of transaction graphs in financial payment and settlement, as detailed below:

[0124] To comprehensively and accurately depict the complex financial activities on the blockchain and support subsequent multi-level and multi-dimensional risk analysis, the transaction monitoring program within the risk management module first executes an innovative heterogeneous graph data modeling algorithm. This algorithm unifies and abstracts multi-source, heterogeneous on-chain and off-chain data into a heterogeneous graph model containing multiple types of nodes and multiple types of relational edges, thereby constructing a computationally rich, panoramic financial transaction knowledge graph.

[0125] First, define the node type system for heterogeneous graphs.

[0126] To comprehensively cover all types of entities involved in financial payment and settlement, this algorithm defines the following five core node types, each of which is assigned a set of feature fields to describe its core attributes.

[0127] Node Type A: Wallet Address Node

[0128] An account address represents an account address on a blockchain network and is the basic unit of transaction activity.

[0129] Sub-type distinction: further subdivided into External Accounts (EOA), which are ordinary addresses directly controlled by the user's private key; and Contract Accounts, which are addresses controlled by deployed smart contract code.

[0130] Core attribute set:

[0131] - Address identifier: A unique address string on the blockchain (e.g., 0x1234...abcd).

[0132] - Chain: The blockchain network identifier of the address (such as Ethereum, TRON, BSC).

[0133] - First appearance time: The timestamp of when this address first appears on the chain (created or first transacted).

[0134] - Account type: an enumeration value, labeled "EOA" or "Contract".

[0135] - Address Tags: Tag information obtained from address profile data, such as "Exchange Hot Wallet", "Mining Pool Address", "Mixer Address", "Personal Wallet", etc.

[0136] - Risk score: A comprehensive risk score (0-100) derived from external data sources or historical analysis of this system.

[0137] Node type B: Transaction node

[0138] A record representing a specific transaction or smart contract interaction on the blockchain is a fundamental event for fund flows and state changes.

[0139] Core attribute set:

[0140] - Transaction hash: A hash value that uniquely identifies a transaction on the blockchain.

[0141] - Transaction Amount: The number of tokens transferred in this transaction.

[0142] - Token type: The type of digital asset involved in the transaction (such as ETH, USDT, WBTC).

[0143] - Timestamp: The precise time when a transaction was packaged into a block.

[0144] - Transaction parties' addresses: The sender's address and the receiver's address (for contract interactions, the receiver's address is the contract address).

[0145] -Gas consumption: The amount of Gas consumed in executing this transaction.

[0146] - Input data: Input data attached when calling the contract, which can be parsed to obtain specific function call information.

[0147] Node type C: Smart contract node (Contract)

[0148] It represents a smart contract program deployed on the blockchain that can be invoked, and is the core carrier of decentralized applications (DeFi, NFT, etc.).

[0149] Core attribute set:

[0150] - Contract address: The unique address identifier of the contract on the blockchain.

[0151] - Whether it is open source verification: Whether the contract source code has been made public and verified by a blockchain explorer.

[0152] - Contract type tags: Custom tags, such as "DEX" (Decentralized Exchange), "Lending" (Lending Protocol), "NFT Marketplace", and "Cross-chain Bridge".

[0153] - Creator address: The wallet address where the contract is deployed.

[0154] Node type D: Belonging entity node (Entity)

[0155] Representing real-world business organizations or individuals, it is used to aggregate multiple anonymous or pseudo-anonymous addresses on the blockchain under a single, real, and verifiable entity. This serves as a crucial bridge connecting on-chain behavior with off-chain KYC / KYB information.

[0156] Core attribute set:

[0157] - Entity ID: A unique identifier assigned to each entity within the system.

[0158] - Entity Name: The legal name of the entity (e.g., "a digital currency exchange", "a project foundation").

[0159] -KYC / KYB Score: The compliance level assessed based on KYC / KYB documents stored at the verification center.

[0160] - Entity type: such as "exchange", "market maker", "project party", "high-risk individual", etc.

[0161] - Cluster ID: A cluster identifier generated by the multi-wallet graph clustering identification algorithm (claim 5), used to quickly retrieve all addresses belonging to the entity.

[0162] Node type E: CrossChainBridge node

[0163] This represents a special type of smart contract protocol whose core function is to enable the transfer of assets between different blockchain networks.

[0164] Core attribute set:

[0165] - Bridge Name: The official name of the cross-chain bridge protocol (e.g., "Wormhole").

[0166] -Source Chain: The main outgoing chain supported by this bridge instance.

[0167] - Target Chain: The primary incoming chain supported by this bridge instance.

[0168] - Contract Addresses: A list of corresponding contract addresses deployed on different blockchains.

[0169]

[0170] Then, define the edge type system for heterogeneous graphs.

[0171] To accurately describe the interaction and control relationships between the different types of nodes, this algorithm defines the following five core edge types. Each edge type carries specific semantic information and is accompanied by corresponding relational attributes.

[0172] Edge type A: TRANSFER, which represents a direct transfer of an asset between two wallet addresses.

[0173] Starting node type: Wallet address node

[0174] Termination Node Type: Wallet Address Node

[0175] Relationship attribute set:

[0176] - Token type: The type of asset involved in the transfer.

[0177] - Transaction amount: The specific amount transferred.

[0178] - Timestamp: The time when the transaction occurred.

[0179] Typical scenarios: USDT transfers between individuals, users depositing funds into exchanges, and exchanges withdrawing funds from users.

[0180] Edge Type B: Use / Control Edges (USES) represent the ownership, control, or use relationship of a real-world entity over one or more wallet addresses. This edge serves as the link between off-chain KYC information and on-chain anonymous addresses.

[0181] Starting node type: Belonging entity node (Entity)

[0182] Termination Node Type: Wallet Address Node

[0183] Relationship attribute set:

[0184] - Confidence level: Indicates the degree of certainty regarding the control relationship (0-1). For example, a hot wallet on an exchange confirmed through official announcements has a confidence level of 1.0; a related address inferred through algorithmic clustering might have a confidence level of 0.7.

[0185] - Control type tags: such as "Official Operation Address", "Collection Address", "Distribution Address", "Test Address".

[0186] Typical scenario: A cryptocurrency exchange entity controls its hot wallet address used to receive user deposits.

[0187] Edge Type C: Cross-chain Transaction Edge (BRIDGE_TX), representing the transfer of an asset from one blockchain network to another via a cross-chain bridge protocol. This edge is a logical edge, generated by the cross-chain bridge behavior recognition algorithm (claim 8), used to connect the source chain transaction, the cross-chain bridge node, and the target chain transaction, completing the broken fund trajectory.

[0188] Starting node type: Wallet address node (sender address on the source chain)

[0189] Intermediate node type: CrossChainBridge node (serving as a medium for the path)

[0190] Termination Node Type: Wallet Address Node (Recipient Address on the Target Chain)

[0191] Relationship attribute set:

[0192] -Source Chain: The blockchain from which funds are transferred.

[0193] -Target Chain: The blockchain where funds are transferred.

[0194] - Source Chain Transaction Hash: Locked / Destroyed transactions on the source chain.

[0195] - Target chain transaction hash: Minting / releasing transactions on the target chain.

[0196] Typical scenario: Users convert ETH on Ethereum to BNB on BSC via a cross-chain bridge.

[0197] Edge type D: Deployed edge (DEPLOYED_BY), representing a relationship where a wallet address creates (deploys) a smart contract.

[0198] Starting node type: Wallet address node

[0199] Termination Node Type: Smart Contract Node

[0200] Relationship attributes: Usually no additional attributes are needed, as the relationship itself expresses the deployment facts.

[0201] Typical scenario: The project team deploys a new DeFi protocol contract; the developer deploys a test contract.

[0202] Edge type E: Call edges (CALLS), representing a wallet address (or a contract address) calling a function of another smart contract. This is the foundation for implementing complex DeFi interactions.

[0203] Starting node type: Wallet address node or smart contract node.

[0204] Termination Node Type: Smart Contract Node

[0205] Relationship attribute set:

[0206] - The name of the function being called: such as swap, deposit, borrow.

[0207] - Call parameters: Parsed function call parameters.

[0208] - Transaction hash: Records the transaction used in this call.

[0209] Typical scenario: Users exchange tokens on decentralized exchanges (DEXs) by calling their swap function.

[0210] Finally, the construction and storage of heterogeneous graphs.

[0211] Based on the node and edge type system defined above, the risk data collection program of the transaction monitoring program continuously extracts data from various data sources (financial institution transaction data, on-chain transaction data, address profiling data, external compliance data, etc.), and transforms the raw data into node and edge instances that conform to the graph model definition through data cleaning, alignment, parsing, and association mapping. Finally, these nodes and edges are stored in a graph database that supports attribute graph models (such as Neo4j), forming a continuously growing and dynamically updated heterogeneous graph for financial payment and settlement.

[0212]

[0213] (2) Multi-wallet graph clustering algorithm for identifying the main body, such as, specifically

[0214] To effectively identify the same controlling entity behind multiple anonymous wallet addresses and overcome the limitations of traditional analysis methods that can only analyze single addresses in isolation, the transaction monitoring program within the risk management module (as described in claim 3) executes an innovative multi-wallet graph clustering algorithm for identifying the controlling entity. This algorithm leverages the powerful feature extraction capabilities of graph neural networks (GNNs) and the excellent data partitioning capabilities of clustering algorithms to automatically identify and aggregate wallet address clusters belonging to the same entity or organization from massive and complex blockchain transaction data, generating a "wallet entity clustering graph," providing a crucial controlling entity perspective for judging suspicious transactions.

[0215] The specific implementation of this algorithm is explained in the following detailed steps:

[0216] Step S1-1: Feature extraction based on heterogeneous graphs

[0217] First, based on the on-chain transaction data, address profile data, and financial institution transaction data collected by the risk data collection program, a heterogeneous graph data modeling algorithm is invoked to construct a heterogeneous graph that comprehensively reflects the financial payment and settlement relationship.

[0218] This heterogeneous graph defines multiple entity node types, including at least:

[0219] Wallet address node: Represents the blockchain address involved in the transaction.

[0220] Transaction node: Represents a specific on-chain transaction.

[0221] Smart contract node: Represents the decentralized protocol or program that is invoked.

[0222] Attribution Entity Node: Represents a real-world entity (such as an exchange or a company) known through KYC / KYB information.

[0223] At the same time, several types of relation edges are defined to connect the above nodes:

[0224] Transfer edge: Connects the "wallet address node" and the "transaction node", indicating the inflow or outflow of funds.

[0225] Using edges: Connecting "wallet address nodes" and "smart contract nodes" represents the interaction between addresses and contracts.

[0226] Deployment edge: Connects the "wallet address node" and the "smart contract node", indicating that the address created the contract.

[0227] Based on this heterogeneous graph, the algorithm focuses on extracting high-order features that reveal potential principal relationships between wallet addresses, including:

[0228] Structural similarity features: Calculate the similarity of two wallet address nodes in the local graph topology, such as whether they have similar "number of counterparties", "active time periods", "transaction frequency distribution", or "in-out degree ratio". Highly similar structural features usually suggest that they may be controlled by the same set of automated trading strategies or scripts.

[0229] Shared interaction address characteristics: Identify whether two wallet addresses frequently interact with the same or a group of highly related intermediate addresses (such as aggregation addresses or distribution addresses). For example, if funds from addresses A and B ultimately flow to the same aggregation wallet C, then A and B have a strong correlation.

[0230] Common counterparty characteristics: Extending the connection from direct interaction to indirect interaction. For example, if two addresses interact with the same known exchange deposit address, the same mixer smart contract, or the same high-risk DApp within a similar time window, this also constitutes evidence of a connection between the entities.

[0231] Step S1-2: Feature embedding based on graph neural network (GNN)

[0232] Because the extracted features have high dimensionality and complex structure, they are difficult to use directly for cluster analysis. Therefore, this step uses a graph neural network model to map each wallet address node into a low-dimensional dense vector space.

[0233] Model Selection and Input: This embodiment preferably uses a Graph Attention Network (GAT) model. The input to the model is the complete heterogeneous graph constructed in step S1-1. The initial feature vector of each wallet address node is composed of two concatenated parts:

[0234] 1. Basic on-chain characteristics: such as total transaction volume, first / last active time, average transaction amount, gas consumption pattern, etc.

[0235] 2. External tag features: Risk score, address type tags (such as "exchange address", "mining pool address", "mixer address"), and whether it is on a blacklist, etc., obtained from address profile data.

[0236] Feature Aggregation and Embedding Generation: The GAT model iteratively aggregates features from each central node's "neighbor" nodes through a multi-head attention mechanism. For example, for a target wallet address, the model not only aggregates information from its direct counterparties (first-order neighbors), but also aggregates information from the counterparties' counterparties (second-order neighbors) by stacking multiple layers of the network. More importantly, the attention mechanism can automatically learn and assign different weights to different neighbors, meaning that "key neighbors" with stronger relevance to the subject (such as common counterparties) will receive higher attention during feature aggregation. After propagation and transformation through multiple layers of the network, each wallet address node is ultimately generated as a 128-dimensional embedding vector containing its own and surrounding complex structural information.

[0237] Step S1-3: Apply clustering algorithms to identify address clusters

[0238] After obtaining the low-dimensional embedding vectors of all wallet addresses, the geometric distance (such as Euclidean distance) or angular distance (such as cosine similarity) of these vectors in space reflects the behavioral and association similarity between the addresses. This step applies a clustering algorithm to automatically group these vectors.

[0239] Algorithm selection: Considering that it does not require pre-specifying the number of clusters and can effectively identify isolated points (i.e. addresses that are not strongly associated with other addresses), this embodiment preferably adopts the density-based clustering algorithm DBSCAN.

[0240] Clustering process: The 128-dimensional embedding vectors of all wallet addresses generated in steps S1-2 are input into the DBSCAN algorithm. The algorithm automatically identifies high-density regions in the vector space using preset neighborhood radius (Eps) and minimum sample size (MinPts) parameters. Ultimately, each set of vectors identified as a high-density region is grouped into a cluster. Each cluster represents a "wallet entity cluster" formed by multiple wallet addresses that are suspected to be controlled by the same entity or are highly correlated.

[0241] Cross-chain entity clustering: Since the heterogeneous graph itself integrates data from different blockchains (such as Ethereum and TRON), the cross-chain transaction edges completed by the cross-chain bridge behavior recognition algorithm (as described in claim 8) have also been incorporated into the graph. Therefore, the embedding vectors generated by the GNN model naturally contain the cross-chain behavior patterns of addresses. This enables the subsequent DBSCAN clustering to group addresses on different chains but with closely related behaviors (e.g., source chain addresses and target chain addresses transferring assets through cross-chain bridges) into the same cluster, thus forming a true "cross-chain wallet entity clustering graph".

[0242] Steps S1-4: Suspicious Transaction Judgment Based on Wallet Entity Clustering Graph

[0243] Through the steps described above, the transaction monitoring program obtains a dynamically updated "wallet entity clustering map." This map provides a revolutionary perspective for identifying and judging suspicious transactions.

[0244] When monitoring transactions, the system no longer treats them as simple fund flows between two isolated addresses (A and B), but rather as interactions between two entity clusters (Cluster_X and Cluster_Y). For example:

[0245] Scenario 1, Risk Penetration: Suppose that the historical transactions of address A appear normal, but cluster analysis shows that address A belongs to an entity cluster (Cluster_HighRisk) containing multiple known high-risk addresses (such as those marked as being associated with fraudulent activities). Then, any transaction initiated or received by address A will be automatically marked as high-risk by the system due to the overall risk profile of its respective entity, thus triggering more stringent scrutiny.

[0246] Scenario 2: Pattern Recognition: When monitoring detects a series of complex, rapid, and patterned fund transfers between multiple addresses belonging to different entity clusters (e.g., funds flow from Cluster_A to Cluster_B, and then flow into Cluster_C after a series of "layered" operations), the system can determine earlier and more accurately whether this is an organized money laundering network operating across groups, rather than random transactions by multiple independent individuals, based on the relationship graph between clusters and the hidden fund path identification algorithm (as described in claim 7).

[0247] Once a suspicious transaction is identified based on the clustering graph, the system proceeds to the subsequent process described in claim 1: the verification center will issue an instruction to the relevant party to provide detailed KYC / KYB information, the risk management module will conduct the final risk verification, and the trust credentials and whitelist information will be dynamically updated based on the verification results.

[0248]

[0249] (3) Multi-hop path expansion and filtering algorithm, refer to, specifically:

[0250] To effectively track the flow of funds in complex blockchain networks and identify hidden, multi-layered, suspicious transaction patterns, the transaction monitoring program within the risk management module (as described in claim 3) executes an innovative multi-hop path expansion and filtering algorithm. Starting from the target wallet address, this algorithm performs a multi-level, penetrating traversal along the direction of fund flow in the heterogeneous graph, and combines preset constraint rules to prune and filter massive paths in real time, ultimately generating a fund flow trajectory focused on suspicious patterns, providing direct link evidence for risk assessment of transaction behavior.

[0251] The specific implementation of this algorithm is explained in the following detailed steps:

[0252] Step S2-1: Extraction of Related Transaction Subgraphs Based on Heterogeneous Graphs

[0253] First, based on the heterogeneous graph of financial payment and settlement constructed in claim 4, the algorithm starts the path search process from the target wallet address node that needs to be monitored. The core of this process is the path traversal algorithm in graph theory.

[0254] Search direction and depth settings: Depending on the analysis objective, forward traversal (tracking the flow of funds) or reverse traversal (tracing the source of funds) can be selected. At the same time, to prevent the traversal range from expanding indefinitely and causing computational explosion, the algorithm sets a maximum search depth (i.e., "number of hops"), such as 6 hops or 10 hops, which is usually sufficient to cover most typical money laundering layered operations.

[0255] Path search algorithm implementation:

[0256] Depth-First Search (DFS): Suitable for scenarios that require exhaustively searching specific paths to explore whether funds have reached certain deep, high-risk addresses. The algorithm digs deep along a transaction chain until it reaches the maximum depth or there are no new addresses to explore, and then backtracks.

[0257] Breadth-First Search (BFS): Suitable for assessing the spread of risk, such as in scenarios where, after identifying fraudulent funds, it's necessary to quickly understand how many addresses the funds have spread to within a certain number of layers. The algorithm expands outward layer by layer according to the number of hops.

[0258] Implementation Platform: In practical engineering implementation, this algorithm can rely on various graph computing engines. For example, the `apoc.path.expandConfig()` procedure provided by the graph database Neo4j can be used to efficiently expand multi-hop paths from the target node by configuring parameters such as `maxLevel` (maximum depth) and `relationshipFilter` (relationship type filtering). For ultra-large-scale network analysis scenarios, it can be deployed on distributed computing platforms such as Spark GraphX, leveraging its powerful parallel graph traversal capabilities to process massive amounts of transaction data.

[0259] Through the above steps, a manageable-sized "association transaction subgraph" containing multi-hop transaction associations is extracted from the full heterogeneous graph containing billions of nodes and edges for each target address.

[0260] Step S2-2: Real-time filtering during path expansion

[0261] While the path unfolds, the algorithm introduces a dynamic constraint rule engine to evaluate and filter the traversal process and generated path fragments in real time. This aims to eliminate irrelevant or low-value transaction paths, focusing computational resources on truly suspicious patterns.

[0262] Node hierarchy constraints:

[0263] Whitelist filtering: Automatically removes path branches from verified low-risk entity nodes (such as aggregation wallets of mainstream exchanges and addresses of compliant institutions that have passed KYC verification), because these nodes usually mean that funds have flowed into the compliant regulatory field, and the risk chain may be broken.

[0264] Blacklist / Graylist Highlighting: When a path touches a blacklisted address or a high-risk profile address (such as a mixer or a known fraudulent address), instead of pruning, it is marked and highlighted, and may trigger a deeper expansion to track its full range of influence.

[0265] Relationship edge feature constraints:

[0266] Transaction amount threshold: Ignore "dust transactions" with extremely small amounts, as these transactions are often used for address pollution or irrelevant small-amount tests and are not related to the main cash flow.

[0267] Transaction time window: Only transactions that occur within a specific time window are retained. For example, when tracing the whereabouts of specific fraudulent funds, only transactions after the time of the incident are considered to eliminate normal transaction noise carried over from the past.

[0268] Transaction frequency and pattern: Edges that have a large number of high-frequency, equal-amount transactions with the same address in a short period of time are highlighted. This may be a characteristic of "layered" money laundering or wash trading.

[0269] Path shape constraints:

[0270] Circular path elimination: Identify and filter out self-circulating transaction paths that are formed due to technical reasons (such as change address mechanism) and have no actual risk implications.

[0271] Convergence / Divergence Pattern Recognition: When a "star" structure appears in the path, where multiple addresses converge to a single address (funds collection) or a single address disperses to multiple addresses (funds distribution), the algorithm retains such path segments and extracts their structural features for subsequent analysis.

[0272] Step S2-3: Generate filtered compliant transaction paths

[0273] After real-time filtering and pruning in step S2-2, all path branches that do not conform to the constraint rules are eliminated. Finally, the algorithm outputs a series of transaction paths starting from the starting address, passing through multiple intermediate nodes, and finally reaching the target address (or the maximum search depth boundary). Each path clearly represents the complete flow trajectory of funds from the starting point to the destination, and all nodes and edges on the path have passed preliminary compliance screening, focusing on truly noteworthy risk transmission links.

[0274] Step S2-4: Identify suspicious transactions based on fund flow patterns

[0275] Finally, the transaction monitoring program uses the generated transaction path as the core basis to assess the risk of the target transaction or address.

[0276] Simple rule judgment: For example, if tracing back N hops from the source address of a cross-border payment reveals that its upstream funds originated from a known dark web marketplace address, then the payment can be directly judged as highly suspicious.

[0277] Complex pattern matching: The generated path pattern is matched against a known money laundering pattern library. For example, if the path exhibits typical covert patterns such as "rapid in and out" (funds flow quickly between multiple addresses), "split and consolidate" (large sums of money are split into multiple smaller sums and then re-integrated), or "cross-chain jump" (the path includes asset transfers via cross-chain bridges), the system will automatically generate a suspicious transaction report.

[0278] Based on the multi-wallet clustering results: each address on the path is mapped to the wallet entity clustering graph generated in step S1. If a fund path flows through multiple different addresses belonging to the same entity cluster at different hop counts, it is highly likely that the entity is engaging in "self-money laundering" or internal fund aggregation to circumvent the large-amount reporting threshold, thereby triggering a high-risk alert.

[0279] Once a suspicious transaction is identified based on the path analysis, the system proceeds to the subsequent process described in claim 1: the verification center will issue instructions to all parties involved in the path to provide detailed KYC / KYB information, the risk management module will conduct the final risk verification, and the trust credentials and whitelist information will be dynamically updated based on the verification results.

[0280]

[0281] (4) A graph neural network algorithm for identifying hidden funds paths in blockchain, as detailed below:

[0282] To address the most complex "layering" stage of money laundering—where criminals use multiple, complex, and cross-border financial transactions to obscure the source of funds and conceal their tracks—the transaction monitoring program within the risk management module (as described in claim 3) executes an innovative blockchain-based algorithm for identifying concealed fund flows using graph neural networks. This algorithm utilizes heterogeneous graph representation learning technology to automatically learn and identify suspicious fund flow patterns that deliberately conceal their true purpose from massive amounts of transaction data, achieving accurate identification of concealed paths that are difficult to capture using traditional rule-based and human experience-based methods.

[0283] The specific implementation of this algorithm is explained in the following detailed steps:

[0284] Step S3-1: Construct a supervised learning sample set

[0285] The primary task of the algorithm is to construct high-quality training data to guide the model in learning the essential differences between "hidden" and "normal" paths.

[0286] Construction of positive samples (hidden funding paths):

[0287] Source 1: Known Risk Address Association Paths: External compliance data (such as blacklists provided by blockchain analytics companies like TRM Labs and Chainalysis) and sanctions lists (such as OFAC sanctioned addresses) obtained from risk data collection programs (see the "Risk Data Collection Programs" section) are used to extract fund paths that have multiple hops with these high-risk addresses. For example, starting with a known ransomware payment address, the fund collection path can be traced backwards, or the money laundering outflow path can be traced backwards.

[0288] Source 2: Historical STR Association Paths: Extracting on-chain transaction paths that have been proven to be core elements of money laundering cases from the Suspicious Transaction Reports (STR) database of financial institutions. Associating and mapping the off-chain transactions described in these reports with on-chain addresses to form samples of concealed fund paths with clear labels.

[0289] Source 3: Typical Money Laundering Pattern Simulation: Based on the knowledge of anti-money laundering experts, synthetic path data simulating typical money laundering patterns (such as "split-layer-integration", "cross-chain jump", "coin mixer interaction") is constructed to enhance the model's ability to identify such specific patterns.

[0290] Construction of negative samples (normal transaction path):

[0291] From a massive volume of on-chain transactions, random sampling is performed, ensuring the samples are unrelated to any known risky addresses or historical STRs, and that the transaction behavior follows normal business logic or personal consumption habits. For example, the common path of withdrawing user deposits from mainstream exchanges to personal wallets and then interacting with DEXs. The number of negative samples should be significantly greater than the number of positive samples to simulate the normal behavior of the vast majority of transactions in the real world.

[0292] Using the methods described above, a large-scale training sample set with clear labels and covering various cloaking patterns was constructed.

[0293] Step S3-2: Multidimensional Feature Engineering of Nodes and Edges Based on Heterogeneous Graphs

[0294] Before inputting the sample path into the model, it is necessary to assign rich, multi-dimensional features to each node and each edge on the path based on the heterogeneous graph constructed in claim 4, so as to fully characterize its role and behavior in the transaction network.

[0295] Node characteristics (including at least one or a combination of the following):

[0296] Transaction behavior characteristics: transaction frequency (daily / weekly / monthly), average transaction amount, first active time, last active time, inbound / outbound ratio (reflecting whether it is a fund aggregation address or a distribution address).

[0297] Risk association characteristics: correlation with blacklisted addresses (such as shortest path distance), address type labels (obtained from address profile data, such as "exchange", "mining pool", "mixer", "DeFi protocol", "personal wallet").

[0298] Fund characteristics: current balance, historical maximum balance, and capital turnover rate.

[0299] Edge features (including at least one or a combination of the following):

[0300] Basic characteristics of a transaction: transaction amount, transaction timestamp, and transaction direction (transfer in / transfer out).

[0301] On-chain technical characteristics: Gas consumption (abnormally high Gas consumption may indicate an emergency operation), call to contract methods (such as swap, transfer), and input data (which may contain hidden information).

[0302] Pattern matching characteristics: the degree of matching with typical money laundering patterns, such as whether the transaction belongs to the pattern defined by heuristic rules such as "the amount is just below the threshold for large-amount reporting" or "multiple reverse transactions with the same address in a short period of time".

[0303] Step S3-3: Hidden path feature extraction based on heterogeneous graph representation learning

[0304] This step is the core of the algorithm, which uses a heterogeneous graph neural network (GNN) to automatically learn the high-order implicit feature representation of the path.

[0305] Model Selection: This embodiment preferably uses a Heterogeneous Graph Attention Network (HetGAT). Compared to homogeneous GNNs, HetGAT can natively handle different types of nodes (wallets, contracts, entities) and edges (transfers, usage, deployments) in heterogeneous graphs, and assign independent attention weights to different types of relationships, thereby capturing semantic information in complex financial activities more accurately.

[0306] Model training:

[0307] Input: Input the heterogeneous graph with rich features constructed in step S3-2, and the path samples labeled in step S3-1 (each sample corresponds to a specific path in the graph with a start and an end point) into the HetGAT model.

[0308] Node-level feature learning: The HetGAT model updates the embedding vector of each node by iteratively aggregating information from different types of neighbor nodes. For example, the final representation of a wallet address node will be determined by the features of the transaction nodes it directly interacts with, the smart contract nodes it has used, and the entity nodes to which it may belong. The attention mechanism ensures that the model can focus on the neighbor types and specific neighbors that are most important for judging path risk.

[0309] Path-level feature learning: After obtaining the embedding vectors of all nodes on the path, the model further aggregates these node vectors through a path pooling layer (such as attention-based pooling or simple averaging / summing) to form a single feature vector representation of the entire path. This vector encapsulates the structural information, node behavior information, and risk propagation process of the entire path.

[0310] Training objective: The training objective of the model is to minimize the loss function of path classification (such as cross-entropy loss) so that positive sample paths (hidden paths) and negative sample paths (normal paths) can be clearly distinguished in the path feature space generated by the model.

[0311] Step S3-4: Hidden Path Classification and Risk Scoring

[0312] The trained HetGAT model is connected to a classifier (such as an MLP multilayer perceptron) to form a complete recognition pipeline.

[0313] Recognition process: For a funding path to be detected (e.g., a candidate path generated by the multi-hop path expansion algorithm in step S2), it is input into the trained model. The model first generates a path-level feature vector for it, and then the classifier outputs a probability value between 0 and 1 based on this vector.

[0314] Output: This probability value is the risk score of the path. The higher the score, the greater the likelihood that the path is a "hidden funds path". The system presets a risk threshold (e.g., 0.85). When the score exceeds the threshold, the path is automatically marked as a "suspicious hidden funds path". Simultaneously, the algorithm outputs key information about the path, including all wallet addresses, transaction hashes, timestamps, and the final aggregated risk score, providing a complete chain of evidence for subsequent manual review and report writing.

[0315] Step S3-5: Interpretability Analysis – Critical Path Segment Identification

[0316] To meet the regulatory audit requirements for decision interpretability, this algorithm integrates a model interpretability analysis module.

[0317] Technical approach: By analyzing the attention weight distribution within the HetGAT model, or by using ex post-hoc interpretation tools such as GNNExplainer and PGExplainer, the "degree of attention" the model pays to each node and edge on the path when making classification decisions can be calculated.

[0318] Output key fragments: The algorithm automatically identifies the key elements that contribute most to the judgment result, such as:

[0319] Key intermediate nodes: Addresses assigned the highest attention weight, which are usually "stepping stones" or "recapitulation points" in the money laundering path.

[0320] Abnormal transaction edge: The core transaction record that causes the model to make a high-risk judgment, which may have significant anomalies in amount, time or interaction object.

[0321] Key sub-path structure: Subgraph structure that conforms to a specific hiding pattern, such as a typical "star distribution" or "chain stacking" structure.

[0322] These interpretable outputs enable risk control personnel not only to know that a transaction is "suspicious," but also to quickly understand "why it is suspicious," greatly improving audit efficiency.

[0323] Step S3-6: Risk Management and Suspicious Transaction Report Generation

[0324] Once a suspicious concealed fund path is identified through the above steps, the system will automatically trigger the risk handling process.

[0325] STR Report Generation: Based on the extracted key path information (node ​​addresses, transaction hashes, risk scores, key segments), a formatted Suspicious Transaction Report (STR) is automatically generated. The report clearly describes the complete concealed path of funds from source to destination, the amount and time involved, and the high-risk characteristics identified by the model.

[0326] Process Trigger: The generated STR report will be submitted to the risk management module of the verification center. According to the process described in claim 1, the verification center will issue instructions to the relevant parties involved in the path to provide detailed KYC / KYB information, conduct the final manual or assisted risk verification, and dynamically update the trust credentials and whitelist status of the relevant addresses based on the verification results.

[0327] (5) Cross-bridge behavior recognition method:

[0328] To address the prominent issue of using cross-chain bridge technology to transfer assets between different blockchain networks, thereby severing the flow of funds and evading regulation, the transaction monitoring program within the risk management module (as described in claim 3) executes an innovative cross-chain bridge behavior recognition algorithm. This algorithm, through the construction of cross-chain shadow mapping and multi-factor heuristic matching, can penetrate data silos between different blockchains, accurately linking seemingly independent outgoing transactions on the source chain with incoming transactions on the target chain. This completes the fund flow graph severed by cross-chain behavior, thereby achieving comprehensive monitoring of complex risks such as cross-chain money laundering and cross-chain arbitrage.

[0329] The specific implementation of this algorithm is explained in the following detailed steps:

[0330] Step S4-1: Cross-chain entity feature extraction and node tagging

[0331] The algorithm’s primary task is to identify and label all key entities involved in cross-chain activities in the heterogeneous graph.

[0332] Cross-chain bridge contract identification: From the on-chain transaction data collected by the risk data collection program, the system identifies the smart contract address of the cross-chain bridge protocol in the following ways:

[0333] Known protocol library matching: Built-in and regularly updated official smart contract address libraries of mainstream cross-chain bridge protocols (such as Multichain, Wormhole, Across, Hop Protocol, etc.).

[0334] Behavioral pattern heuristic identification: For unknown or emerging cross-chain bridges, identification is achieved by analyzing the behavioral patterns of smart contracts. For example: contract interactions involve standardized cross-chain operations such as locking / unlocking and minting / destroying; transaction logs contain cross-chain-specific event fields such as ChainId, token, and receiver; and there are interaction records with assets on multiple blockchain networks.

[0335] Node Marking and Feature Recording: The identified cross-chain bridge smart contract addresses are marked as special "cross-chain bridge contract nodes" in the heterogeneous graph described in claim 4. Simultaneously, key features are recorded for all transaction edges (i.e., "cross-chain transaction edges") that interact with these nodes, including at least:

[0336] Source chain identifier: The blockchain network (such as Ethereum) from which the transaction was initiated.

[0337] Target chain identifier: The blockchain network to which the transaction is intended to flow (such as Polygon).

[0338] Token type: The type of asset that can be transferred across chains (such as USDC, ETH).

[0339] Transaction amount: The amount transferred out on the source chain.

[0340] Transaction timestamp: The exact time when the source chain transaction was packaged.

[0341] Recipient address: The user address that receives the assets on the target chain (usually parsed from the event log of the cross-chain bridge contract).

[0342] Step S4-2: Construction of Cross-Chain Data Shadow Map

[0343] To address the issue of the same cross-chain transaction having different transaction hashes on the source and target chains, this algorithm constructs a logical "cross-chain shadow mapping table" between different blockchain networks.

[0344] Data aggregation: The monitoring program continuously listens for and aggregates all marked cross-chain bridge contract nodes' "lock / burn" transactions (denoted as Tx_Source) on the source chain and "mint / release" transactions (denoted as Tx_Target) on the target chain. Although these two types of transactions appear as independent and unconnected events on the chain, they belong to the same cross-chain operation in terms of business logic.

[0345] Shadow Mapping Table Structure: A temporary data table is created to temporarily store cross-chain transaction events that have not yet been matched. Each record in this table corresponds to a cross-chain event to be matched, including its chain, transaction hash, timestamp, amount, token type, user address, and associated cross-chain bridge contract address.

[0346] Preset Time Window: The algorithm presets a configurable "cross-chain pairing time window," for example, the default setting is ±2 minutes or ±5 minutes. This window is derived from statistical analysis of the average processing time of mainstream cross-chain bridge protocols and is used to limit the scope of subsequent matching searches, balancing matching accuracy and computational efficiency.

[0347] Step S4-3: Cross-chain behavior heuristic multi-factor matching

[0348] This step is the core of the algorithm. By performing refined multi-factor matching in the shadow mapping table, the source chain events and target chain events belonging to the same cross-chain operation are accurately "reconciled".

[0349] Within a preset time window, the algorithm performs the following multi-factor matching logic on all Tx_Source and Tx_Target events to be matched, and only determines that the two constitute a valid "cross-chain transaction pair" when all conditions are met:

[0350] Condition 1: Time-related matching

[0351] The transfer-out time T_source on the source chain and the transfer-in time T_target on the target chain must satisfy the following:

[0352] |T_source - T_target| ≤ TimeWindow

[0353] In other words, the absolute value of the time difference between the two events does not exceed a preset time window threshold. This ensures that cross-chain events are closely related in time.

[0354] Condition 2: Numerical consistency matching

[0355] Considering the inevitable bridge fees and potential slippage during cross-chain transactions, the amount transferred out from the source chain (Amt_source) and the amount transferred into the target chain (Amt_target) must satisfy the following:

[0356] |Amt_source - Amt_target - Fee_estimated| / Amt_source ≤ SlippageTolerance

[0357] This means that after deducting the estimated fee (Fee_estimated, which can be obtained from the cross-chain bridge contract's fee model or calculated based on historical data), the difference between the two is lower than a preset slippage tolerance threshold (such as 1% or 2%). This condition excludes accidental numerical coincidences caused by exchange rate fluctuations or high fees.

[0358] Condition 3: Protocol and user consistency match

[0359] Protocol Consistency: The cross-chain bridge contract address invoked by Tx_Source must belong to the same protocol as the cross-chain bridge contract address invoked by Tx_Target (i.e., both are deployment contracts of the same cross-chain bridge project on different chains). This condition ensures that funds are transferred through the same bridge.

[0360] User consistency: The "target link recipient address" parsed from the Tx_Source event log must be completely consistent with the "recipient address" in the Tx_Target event. This is the most critical strong matching factor, fundamentally ensuring that the entity to which the funds flow belongs remains unchanged.

[0361] Through the rigorous screening of the above three conditions, the algorithm can link two seemingly unrelated on-chain transactions with a very high degree of confidence, forming a one-to-one cross-chain transaction mapping.

[0362] Step S4-4: Cross-chain path completion

[0363] After a successful match, the algorithm materializes this logical association into the heterogeneous graph.

[0364] Logical edge creation: A new, special type of logical relationship edge—a "cross-chain transaction edge"—is created between the sending address (or intermediate proxy address) of the source chain and the receiving address of the target chain. This edge does not directly correspond to a specific on-chain transaction record, but rather serves as a "virtual edge" or "derived edge" to bridge transaction nodes on two different blockchain networks.

[0365] Graph Fusion: In this way, the broken fund flow path that was originally interrupted by cross-chain communication is successfully completed. For example, the original broken chain of "Address A → [Ethereum transaction] → Cross-chain bridge contract → ??? → [Polygon transaction] → Address B" is now represented in the heterogeneous graph as a continuous and complete end-to-end fund flow graph of "Address A → Ethereum transaction node → Cross-chain bridge contract node → Cross-chain transaction edge → Polygon transaction node → Address B".

[0366] Step S4-5: Cross-chain risk identification based on completion gateway

[0367] After obtaining the complete end-to-end graph, the transaction monitoring program can conduct risk analysis from a more macro and comprehensive perspective.

[0368] Typical risk pattern identification:

[0369] Cross-chain money laundering identification: Monitor whether funds repeatedly "jump" between different chains through multiple cross-chain bridges (e.g., Ethereum → BSC → Polygon → Avalanche). Each jump may be accompanied by a split of the amount or interaction with a coin mixer, which is consistent with the typical cross-chain layered money laundering pattern.

[0370] Cross-chain splitting and integration: Identify the hidden behavior of "funds being split into multiple small transactions on the source chain, crossing chains through different paths or time windows, and finally being reintegrated into a single address on the target chain".

[0371] Cross-chain arbitrage and abnormal flows: Identify large, abnormal fund flows through cross-chain bridges in a short period of time, which may be related to the transfer of stolen funds after a DeFi protocol attack.

[0372] Risk Scoring and Report Generation: When the algorithm identifies the above high-risk patterns, it combines the address profiles and transaction behavior characteristics of all nodes along the path, as well as the anomalousness of the cross-chain operation itself (such as first-time use of the bridge, cross-chain amount far exceeding the user's regular transaction amount, etc.), to calculate a comprehensive risk score. When the score exceeds a preset threshold, the system automatically generates a Suspicious Transaction Report (STR) containing a complete cross-chain fund flow graph and submits it to the verification center.

[0373] The early warning response layer outputs relevant information about suspicious transactions as a Suspicious Transaction Report (STR) and issues a risk warning.

[0374]

[0375] III. Feature Engineering

[0376] (1) Amount Normalization (log(amount+1)): This involves logarithmically transforming transaction amounts to reduce the magnitude difference in amounts and make the data closer to a normal distribution. This is because transaction amounts on the blockchain typically exhibit a long-tail distribution, meaning a few transactions are very large while the majority are small. Directly using the original amounts would bias the model towards large transactions and ignore small ones. Logarithmic transformation can alleviate this problem. Another approach is to convert the unit to a unified currency unit, commonly the US dollar. For example, converting transaction amounts from different cryptocurrencies to US dollars eliminates exchange rate differences between currencies.

[0377] (2) Node / edge time aggregation window: Aggregate the behavior of nodes (addresses) or edges (transactions) within different time windows to capture features at different time scales, such as 1 hour / 6 hours / 24 hours / 7 days, etc. (multi-scale). The reason is that the behavior patterns of addresses or transactions may change over time. For example, an address may engage in high-frequency transactions in a short period of time, but may engage in very few transactions over a long period of time. Using different time windows can capture these features at different time scales.

[0378] (3) Normalize by token and network global scale. Scale the feature values ​​of different tokens or different networks to the same range to eliminate the influence of units and numerical ranges. Different tokens may have different transaction volumes, and different networks may have different transaction activity levels. If normalization is not performed, the model may be biased towards tokens with larger transaction volumes or networks with higher transaction activity.

[0379] (4) Graph statistical characteristics: PageRank, in / out degree, betweenness, clustering coeff. Calculate various statistical characteristics of nodes in the graph to reflect the importance, connectivity, and clustering degree of the nodes.

[0380] PageRank: Measures the importance of a node in a network. The higher the PageRank value, the more important the node is.

[0381] in / out degree: These represent the in-degree and out-degree of a node, respectively. The in-degree indicates how many edges point to that node, and the out-degree indicates how many edges point to other nodes from that node.

[0382] Betweenness: Measures the importance of a node as a "bridge" in the network. The higher the betweenness value, the more pairs of nodes the node connects in the network.

[0383] Clustering coeff: Measures the degree of clustering around a node. The higher the clustering coeff value, the stronger the connections between the nodes around that node.

[0384] (5) Path / flow characteristics: flow entropy, amount diffusion coefficient (Gini), number of fund "forks", etc., to capture the patterns and characteristics of fund flow.

[0385] Entropy measures the diversity of fund flows. Low entropy indicates funds flowing to only a few addresses, while high entropy indicates funds flowing to many different addresses. Higher entropy may indicate that the address is involved in coin mixing or fund dispersal activities.

[0386] The Gini coefficient measures the degree of concentration of funds. A high Gini coefficient indicates that funds are concentrated in a few addresses, while a low Gini coefficient indicates that funds are dispersed across many addresses.

[0387] Fund fork frequency: measures the complexity of fund flows. Fund forks refer to the movement of funds from one address to multiple addresses. The more forks, the more likely that the address is involved in splitting funds.

[0388] (6) Behavioral patterns: Does the address engage in "hand-swapping" behavior (A->B->A)? Does it frequently interact with the mixer / bridge? Capture specific interaction patterns between addresses, which may be related to suspicious activity.

[0389] "Funds changing hands" (A->B->A) refers to the flow of funds from address A to address B, and then back from address B to address A. This behavior may indicate a connection between the addresses or participation in circular transactions.

[0390] Frequent interactions with mixers / bridges: A mixer is a service used to obfuscate the origin of funds, and a bridge is a service used to transfer assets between different blockchains. Frequent interactions with mixers or bridges may indicate that the address is attempting to conceal the origin or destination of funds.

[0391] (7) Abnormal label features: distance to blacklisted addresses, and presence in the sanctions list. External information is used to enhance the model's recognition capabilities. Distance to blacklisted addresses measures the distance between an address and known blacklisted addresses. The closer the distance, the more likely the address is associated with a blacklisted address or has participated in activities related to it. Presence in the sanctions list determines whether the address appears on the sanctions list. If the address appears on the sanctions list, it is highly likely to have participated in illegal activities.

[0392]

[0393] It collects transaction data from financial institutions, suspicious transaction reports from financial institutions, on-chain transaction behavior, address profiling data, external compliance data, and public opinion data. The transaction monitoring module is used to monitor all stablecoin transactions and identify suspicious transactions.

[0394]

[0395] During financial payment and settlement transactions, the initiator and the recipient collect and record their customers' Know Your Customer (KYC) and / or Know Your Business (KYB) transaction details and proof of transaction purpose through their respective financial payment and settlement systems, and generate archived record forms of KYC and / or KYB transaction details and proof of transaction purpose, and transmit the archived record forms to the verification center.

[0396] The initiator's financial payment and clearing system uses its trust credentials to sign and encrypt the transaction information, and publishes the encrypted transaction information to the distributed ledger system. The distributed ledger system sends the wallet addresses of the initiator and the recipient to the whitelist management module of the verification center for authentication. After authentication, the financial payment and clearing transaction initiated by the initiator is recorded on the blockchain to the distributed ledger system and a notification is sent to the recipient.

[0397] The recipient obtains financial payment and settlement transaction information from the distributed ledger system and uses its trust credentials to decrypt the transaction and complete the transaction;

[0398] The verification center's transaction monitoring module monitors all financial payment and settlement transactions and identifies suspicious transactions;

[0399] When a suspicious transaction report is received, the verification center sends KYC and / or KYB transaction details and proof of transaction purpose to the initiator and recipient. The risk management module then verifies the risk of the transaction and updates the trust credentials of both parties involved in the transaction and the information in the whitelist management module based on the verification results.

[0400] See also, for monitoring and auditing tools for blockchain-based financial payment and settlement, including:

[0401] The verification center is responsible for managing, verifying, and querying transactions processed by the blockchain-based financial payment and clearing service system.

[0402] The credential authorization module is responsible for issuing and verifying trust credentials for all parties using or deploying the blockchain clearing and settlement service system;

[0403] Transaction information, at least for trading purposes, is embedded into a designated stablecoin to facilitate the transfer of fiat currency value and control of risk information.

[0404] KYC / KYB transaction information and transaction purpose verification are collected and stored by the initiator and the recipient, and are authenticated by the credential authorization module;

[0405] The verification center monitors all transactions conducted through blockchain-based financial payment and clearing service systems. When an STR is initiated, the verification center requires the initiator and recipient to provide KYC / KYB and proof of transaction purpose, verifies the risk of the transaction, and maintains a risk record.

[0406] The verification center, established and acting as a centralized hub, monitors and audits blockchain-based financial payment clearing to address regulatory loopholes in decentralized blockchain systems. Transaction information is deployed to the blockchain ledger similarly to that of ordinary cryptocurrencies, including transaction hashes, initiator addresses, recipient addresses, transaction amounts, and digital signatures. Purpose information within the transaction is additional transaction information added to the blockchain ledger to meet regulatory requirements. Therefore, privacy information such as KYC / KYB and proof of transaction purpose is not disclosed in the blockchain ledger to maintain anonymity. Parties participating in the blockchain-based financial payment clearing service must verify trust through trust credentials to process transactions and deploy transaction information (such as initiator addresses, recipient addresses, and digital signatures) so that the verification center can track every transaction on the blockchain. Trusting parties must store KYC / KYB and proof of transaction purpose internally for regulatory monitoring and auditing. Upon receiving a Suspicious Transaction Report (STR) or regulatory request, the initiator address and recipient must transmit KYC / KYB information and proof of transaction purpose to the verification center to verify transaction risks and maintain risk records. As an international compliance information center, the verification center shares risk intelligence (such as suspicious transaction patterns) with regulatory agencies worldwide.

[0407] To monitor and audit every transaction in a blockchain-based financial payment and clearing service system, transactions can only be initiated and received by trusted parties to control risk. To verify the identity of trusted parties, the credential authorization module manages all credentials used by all trusted parties. It can issue credentials to trusted parties and manage the credentials issued by them. These trusted parties must be trusted institutions, such as financial institutions (banks, securities companies, insurance companies, investment companies, trust companies, etc.), Web3 wallet providers (cryptocurrency exchanges), financial regulatory agencies, etc.

[0408] A risk center is set up to monitor and audit all transactions on the blockchain, communicate with the verification center, take over the STR processing flow, and report risk records to the verification center in order to control risky transactions.

[0409] In some countries, the trading and transfer of digital assets are subject to anti-money laundering laws. The relevant regulations are as follows:

[0410] • KYC requirements for both parties in an on-chain transaction

[0411] • Requirements for recording specific fields in on-chain transactions

[0412] • Requirements for reporting suspicious on-chain transactions

[0413] Therefore, the fields and information that need to be collected are as follows:

[0414] Is reporting to the verification center mandatory in the KYC form's serial number field? 1. Name (if any) Yes or No 2. Middle Name (if any) Yes or No 3. Last Name (if any) Yes or No 4. Date of Birth (if any) Yes or No 5. Gender (if any) Yes or No 6. Nationality (if any) Yes or No 7. Document Type: ID card, driver's license, voter registration card, passport, other Yes 8. Document Number (if any) Yes or No 9. Document Document Yes or No 10. Address (if any) Yes or No 11. Contact Number (if any) Yes or No 12. Email (if any) Yes or No 13. Facial Recognition (if approved) Yes or No 14. Official Authentication Yes or No 15. Authentication Date: Date or Not Applicable Yes 16. Power of Attorney (if any) Yes or No

[0415] Is it mandatory to report the following KYB form fields to the verification center? 1. Company legal name (if any) Yes or No Yes 2. Company certificate number (if any) Yes or No Yes 3. Business type (if any) Non-financial enterprise Bank Cryptocurrency exchange Other financial institutions Type or Not applicable Yes 4. Contact number (if any) Yes or No Yes 5. Email (if any) Yes or No Yes 6. Date of incorporation and expiry date of registration (if any) Yes or No Yes 7. Registered office address (if any) Yes or No Yes 8. Business license / Business registration certificate (if any) Yes or No Yes 9. Lease agreement (if any) Yes or No Yes 10. Tax registration certificate (if any) Yes or No Yes 11. Latest annual return (if any) Yes or No Yes Is it mandatory to report the following director information fields to the verification center? 1. List of directors (if any) Yes or No Yes 2. Director identification documents (if any) Yes or No Yes 3. Director's address proof (if any) Yes or No Yes Is it mandatory to report the following ultimate beneficial owner information fields to the verification center? 1. UBO List (Shareholders / Beneficiaries holding more than 25% of shares) (if any) Yes or No 2. UBO Identity Documents (if any) Yes or No No 3. UBO Address Proof (if any) Yes or No No 4. UBO Control Statement (if any) Yes or No No Is reporting the shareholder and shareholding structure fields to the verification center mandatory? 1. Shareholder List (if any) Yes or No Yes 2. Shareholding Structure Diagram (if any) Yes or No No 3. Share Certificate (if any) Yes or No No Is reporting the bank account information fields to the verification center mandatory? 1. Company Bank Account Details (if any) Bank Name, Account Number, SWIFT / BIC Code Yes or No No 2. Bank Statements for the Last 3-6 Months (if any) Proving the Company Account's Transaction Status and Fund Flow Yes or No No Is reporting the business certification documents fields to the verification center mandatory? 1. Commercial Contracts / Invoices (if any): Recent commercial contracts or invoices to prove the company has genuine business operations. Yes / No / No 2. List of Major Suppliers / Customers (if any): Proof of the authenticity of the company's business operations (if applicable). Yes / No / No 3. Company Website / Online Business Proof (if any): Company website address, or other online business proof. Yes / No / No Other Supporting Documents Serial Number Field Compliance Assessment Reporting to the Verification Center Mandatory? 1. Licenses / Permits (if applicable): If certain industries require relevant business licenses. Yes / No / Yes 2. Anti-Money Laundering and Compliance Policies (if collected): If certain industries require relevant business licenses. Yes / No / No 3. Latest Financial Statements (if any): Recent balance sheet and profit and loss statement (if applicable). Yes / No / No Serial Number Field Compliance Assessment Reporting to the Verification Center Mandatory? Transaction Initiator Information: Initiator Name (or Not Applicable) Initiator Address (or Not Applicable) Initiator ID Number (or Not Applicable) Initiator Date of Birth (or Not Applicable) Transaction Recipient Information: Recipient Name (or Not Applicable) Transaction Details: Transaction Type: • Personal to Personal • Transfer of Funds between Banks and Financial Institutions • Foreign Exchange Settlement • Payment for Commercial Purposes • Cryptocurrency Exchange Investment • Other (Is Evidence?)

[0416] Are the STR table directory fields mandatory? Reporting Basic Information: Institution Yes (Organization Code) No Reporting Date Yes Customer Basic Information: Name Yes (Type Yes) Certificate Type Yes (Certificate Number Yes) Date of Birth Yes (Nationality Yes) Contact Number Yes (Email Yes) Address Yes (Address) Registration Time Yes Relevant Transaction Details: Transaction Time Yes Transaction Type Yes Amount Yes Currency Type Yes Account Number / Wallet Address Yes Trader Account / Wallet Address Yes Trader Name Yes Trader Institution Yes Suspicious Activity Description: Suspicious Type Yes Crime Type Yes Risk Level Yes Control Measures Yes

Claims

A monitoring and auditing method for financial payment and settlement based on blockchain, characterized in that: The system includes a monitoring and auditing system with a verification center, deployed across the financial payment clearing systems of all parties involved in the clearing process, and a blockchain-based distributed ledger system. The verification center comprises a risk management module, a whitelist management module, and a credential authorization module. The verification center assigns wallet addresses to each financial payment clearing system. The credential authorization module issues, verifies, and queries trust credentials used by the monitoring and auditing systems of all parties involved in the clearing and settlement process to sign financial payment clearing transactions. During a financial payment clearing transaction, the initiator and recipient collect and record their customers' Know Your Customer (KYC) and / or Know Your Business (KYB) transaction details and proof of transaction purpose through their respective financial payment clearing systems. They generate archived records of KYC and / or KYB transaction details and proof of transaction purpose, which are then transmitted to the verification center. The initiator's financial payment clearing system uses its trust credentials to sign and encrypt the transaction information and publishes the encrypted transaction information to the distributed ledger system. The distributed ledger system then sends the wallet addresses of the initiator and recipient to the whitelist management module of the verification center for authentication. After authentication, the financial payment and settlement transaction initiated by the initiator is uploaded to the distributed ledger system and a notification is sent to the recipient. The recipient obtains the financial payment and settlement transaction information from the distributed ledger system and uses its trust credentials to decrypt the transaction and complete it. The transaction monitoring module of the verification center monitors all financial payment and settlement transactions and identifies suspicious transactions. When a suspicious transaction report is received, the verification center sends KYC and / or KYB transaction details and proof of transaction purpose to the initiator and recipient. The risk management module verifies the risk of the transaction and updates the trust credentials of both parties involved in the transaction and the information in the whitelist management module based on the verification results. A monitoring and auditing tool for blockchain-based financial payment and settlement according to claim 1, characterized in that: In addition to the credential authorization module, the trust credential can also be issued by a third-party credential issuing institution to the monitoring and auditing systems of all parties for signing financial payment and clearing transactions. This includes financial institutions that have obtained the trust of the verification center, web3 wallet providers, and other third-party trust credential issuing institutions. A monitoring and auditing method for blockchain-based financial payment and settlement according to claim 1, characterized in that: The risk management module includes a risk data collection program that collects transaction data from financial institutions, suspicious transaction reports from financial institutions, on-chain transaction behavior data, address profile data, external compliance data, and public opinion data; as well as a transaction monitoring program that calculates and discovers suspicious transactions based on the data collected by the risk data collection program. A monitoring and auditing method for blockchain-based financial payment and settlement according to claim 3, characterized in that: The transaction monitoring program includes a heterogeneous graph data modeling algorithm that uses financial institution transaction data to construct financial payment and settlement: constructing a heterogeneous graph containing nodes and relationship edges related to financial payment and settlement, wherein the nodes of the heterogeneous graph include wallet address nodes, transaction nodes, smart contract nodes, and ownership entity nodes, and the relationship edges include transfer edges, usage edges, and deployment edges. A monitoring and auditing method for blockchain-based financial payment and settlement according to claim 4, characterized in that: The transaction monitoring program includes a multi-wallet graph clustering algorithm for identifying the main entity: S1-1. Using the node features and relation edge features in the heterogeneous graph, extract the structural similarity of wallet addresses, common interaction addresses, and common counterparty features; S1-2. Use graph neural networks for feature embedding to map high-dimensional heterogeneous graph data to a low-dimensional vector space; S1-3. Apply clustering algorithms to group the low-dimensional vectors, identify multiple wallet address clusters controlled by the same entity, and generate a wallet entity clustering graph; S1-4. Judge suspicious transactions based on the wallet entity clustering graph obtained from the analysis. A risk monitoring method based on stablecoin transactions according to claim 4, characterized in that: The transaction monitoring program includes a multi-hop path expansion and filtering algorithm: S2-1. Using the established heterogeneous graph, starting from the target wallet address node, setting a maximum search depth, and using a path search algorithm to traverse forward or reverse multi-hop paths along the transfer edges in the heterogeneous graph, extracting the associated transaction subgraph of the target node; S2-2. Filtering relational edges or path segments in real time during the path expansion process; S2-3. Outputting the transaction path after filtering by constraint rules, whereby the transaction path represents the fund flow trajectory from the starting address to the target address; S2-4. Judging suspicious transactions based on the fund flow trajectory. A monitoring and auditing method for blockchain-based financial payment and settlement according to claim 4, characterized in that: The transaction monitoring program includes a graph neural network-based algorithm for identifying hidden fund paths in the blockchain: S3-1. Obtain known financial institution transaction data, suspicious transaction reports from financial institutions, on-chain transaction behavior data, address profile data, external compliance data, and public opinion data from the risk data collection program to construct a sample set of hidden fund paths and a sample set of normal transaction paths; S3-2. Based on heterogeneous graphs, assign multi-dimensional features to nodes and edges of various types; the node features include at least one or a combination of the following: transaction frequency of wallet addresses, average transaction amount, first active time, last active time, correlation with blacklisted addresses, and address type label; the edge features include at least one or a combination of the following: transaction amount, transaction timestamp, transaction frequency, transaction direction, gas consumption, and matching degree with typical money laundering patterns; S3-3. Hidden path feature extraction based on graph representation learning: input the heterogeneous graph and labeled samples into the graph representation learning model for training, and automatically learn the implicit feature representations of nodes and paths in the graph; The graph representation learning model iteratively aggregates the feature information of neighboring nodes to generate embedding vector representations of each node in a low-dimensional space, and further extracts path-level feature representations based on node embeddings; the graph representation learning model includes, but is not limited to, graph neural network models based on neighbor information aggregation, graph embedding models based on random walks, or graph representation learning methods based on matrix factorization; S3-4. Hidden path classification and recognition: The extracted path feature representations are input into the classification model to train the classifier to identify the pattern features of hidden funding paths; The classification model outputs the probability value or risk score of each candidate path belonging to a hidden funds path; when the risk score of the identified path exceeds a preset threshold, the path is marked as a "suspicious hidden funds path", and the key node addresses and transaction hashes on the path are extracted; S3-5. Key path segment identification: by analyzing the degree of attention the model pays to each node and edge in the classification decision process, the key path segments that contribute the most to the judgment result are identified; the key path segments include at least key intermediate nodes of fund flow, abnormal transaction edges, or sub-path structures that conform to a specific concealment pattern; S3-6. Risk handling: the identified suspicious hidden funds paths are reported as suspicious transaction reports. A monitoring and auditing method for blockchain-based financial payment and settlement according to claim 4, characterized in that: The transaction monitoring program includes a cross-chain bridge behavior recognition algorithm: S4-1. Cross-chain entity feature extraction: Identify the smart contract address of the cross-chain bridge protocol from the distributed ledger system and mark it as a cross-chain bridge contract node in the heterogeneous graph. Record the characteristics of cross-chain transaction edges flowing through this node. The characteristics include: outgoing chain identifier, incoming chain identifier, token type, transaction amount, and transaction timestamp; S4-2. Cross-chain data shadow mapping: For assets that flow out of the source chain and reappear on the target chain, construct a cross-chain shadow mapping table and associate transactions before and after the cross-chain transaction using a preset time window pairing strategy; S4-3. Cross-chain behavior heuristic matching: Execute a multi-factor matching algorithm in the shadow mapping table to identify those that meet the following conditions. Cross-chain transaction pairs: Time correlation: The time interval between the source chain transfer out and the target chain transfer in is within a preset time window threshold; Numerical consistency: After considering cross-chain fees and slippage losses, the ratio of the difference between the source chain transfer out amount and the target chain transfer in amount is lower than a preset threshold; Protocol consistency: Both parties to the transaction have interaction records with the same cross-chain bridge contract node; S4-4. Cross-chain path completion: The successfully matched cross-chain transaction pairs are logically connected in the heterogeneous graph through cross-chain transaction edges to eliminate the trajectory breaks caused by cross-chain and complete the full-link fund flow graph; S4-5. Cross-chain risk identification: Based on the completed full-link graph, analyze abnormal patterns of funds being laundered, split, or layered through the cross-chain bridge, and generate suspicious transaction reports.

Images