Method and system for identifying transaction risk

Abstract

The embodiment of the invention discloses a method and system for identifying transaction risks, and the method comprises the following steps: obtaining multi-source heterogeneous data, and initializing a dynamic transaction graph according to a multi-source heterogeneous data flow; the multi-source heterogeneous data comprises invoice data, fund flow data, an enterprise stock equity relationship and geographic data; receiving a multi-source event stream through a message queue, and updating the dynamic transaction graph in real time based on the multi-source event stream; for enterprise nodes affected by updating in the dynamic transaction graph, feature aggregation is executed, topological risk features are extracted, and risk scores of the enterprise nodes are output; verifying the consistency of the invoice hash and the fund flow hash through a relay chain protocol, and obtaining a cross-chain verification result; and according to the risk score and the cross-chain verification result, identifying a transaction risk. According to the embodiment of the invention, systematic risk identification is realized through data integration, graph construction, risk mining and cross-chain verification, and the accuracy of invoice risk identification can be improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and particularly relates to a method and system for identifying transaction risks. Background Art

[0002] With the development of digital technology, there are problems of isolated verification in traditional invoice risk identification, that is, it can only verify the authenticity of a single invoice (such as OCR + tax bureau verification), and cannot identify the associated risk network across enterprises, regions, and bills (such as the "separation of invoices and goods" and "funds return" closed-loop of false invoicing gangs).

[0003] In addition, the existing technology relies on manually preset thresholds (such as the daily invoicing amount > 1 million) and is easily circumvented, and cannot dynamically capture new and hidden risk patterns (such as high-frequency small-amount invoice splitting, centralized invoicing of cross-provincial associated enterprises, etc.).

[0004] Application Content

[0005] The purpose of the embodiments of this application is to provide a method and system for identifying transaction risks to solve the defect that the existing technology cannot accurately identify invoice risks.

[0006] To solve the above technical problems, this application is implemented as follows:

[0007] In a first aspect, a method for identifying transaction risks is provided, including the following steps:

[0008] Obtain multi-source heterogeneous data, and initialize a dynamic transaction graph according to the multi-source heterogeneous data stream; the multi-source heterogeneous data includes invoice data, fund flow data, enterprise equity relationship, and geographical data;

[0009] Receive a multi-source event stream through a message queue, and update the dynamic transaction graph in real time based on the multi-source event stream; the dynamic transaction graph includes a bill flow, a fund flow, an equity flow, and a logistics flow;

[0010] For the enterprise nodes in the dynamic transaction graph affected by the update, perform feature aggregation, extract topological risk features, and output the risk scores of the enterprise nodes; through a relay chain protocol, verify the consistency of the invoice hash and the fund flow hash, and obtain a cross-chain verification result;

[0011] Identify transaction risks according to the risk scores and the cross-chain verification results.

[0012] In a second aspect, a system for identifying transaction risks is provided, including:

[0013] A building module for obtaining multi-source heterogeneous data and initializing a dynamic transaction graph according to the multi-source heterogeneous data stream; the multi-source heterogeneous data includes invoice data, fund flow data, enterprise equity relationship, and geographical data;

[0014] An update module for receiving a multi-source event stream through a message queue and updating the dynamic transaction graph in real time based on the multi-source event stream; the dynamic transaction graph includes a bill flow, a fund flow, an equity flow, and a logistics flow;

[0015] An evaluation module for performing feature aggregation on enterprise nodes affected by the update in the dynamic transaction graph, extracting topological risk features, and outputting a risk score of the enterprise nodes; verifying the consistency of the invoice hash and the fund flow hash through a relay chain protocol to obtain a cross-chain verification result;

[0016] An identification module for identifying transaction risks according to the risk score and the cross-chain verification result.

[0017] Through data integration, graph construction, risk mining, and cross-chain verification, the embodiments of the present application realize systematic risk identification and can improve the accuracy of invoice risk identification. Description of the Drawings

[0018] Figure 1 is a flowchart of a method for identifying transaction risks provided by an embodiment of the present application;

[0019] Figure 2 is a schematic structural diagram of a system for identifying transaction risks provided by an embodiment of the present application. Detailed Embodiments

[0020] Next, the technical solutions in the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0021] Currently, enterprises upload invoice hash values to the blockchain, and the tax bureau node verifies the hash consistency. A smart contract is used to trigger an early warning for abnormal invoices (such as duplicate reimbursement). However, the current technical solutions also have limitations: only ensuring that a single invoice has not been tampered with, unable to identify the associated risks of cross-enterprise and cross-chain data; not accessing bank flow data, unable to verify the consistency of the invoice payment flow; invoice data (enterprise private chain), bank fund flow (financial institution alliance chain), and industrial and commercial data belong to different chain systems, lacking a cross-chain atomic verification protocol, resulting in the inability to match the invoice payment flow in real time.

[0022] Specifically, the existing technologies have the following defects:

[0023] 1. Defects at the data level

[0024] Serious data islands: Invoice data (enterprise private chain), fund flow (bank consortium chain), and enterprise industrial and commercial information belong to different systems, lacking a cross-chain data fusion mechanism and unable to construct a full-link view of transactions. This makes it difficult to identify complex risks such as "separation of invoices and goods" (inconsistent invoice and fund flow directions).

[0025] Single data dimension: Only basic invoice information (code, amount) is collected, without integrating spatio-temporal data (such as invoice issuing location) and equity relationships (such as the control chain of related enterprises). This results in the inability to detect cross-regional false invoicing gangs or behaviors of dispersing invoicing through holding companies.

[0026] 2. Defects in analysis methods

[0027] Reliance on static rules: Currently, it relies on manually preset thresholds (such as an invoice amount exceeding 1 million yuan per day triggering an alarm), with the rules being fixed and easily evaded (such as splitting into multiple small invoices). There are currently scenarios where new risk models (such as high-frequency small splits) cannot be captured in a timely manner.

[0028] Non-graph structure modeling: Traditional machine learning treats invoices as independent samples, ignoring the topological relationships among enterprises - invoices - funds. It is unable to detect hidden risk networks such as circular transactions (A→B→C→A) and cross-shareholdings.

[0029] 3. Defects in real-time performance

[0030] Batch processing delay: Existing systems use offline data analysis (such as daily batch processing), with a risk identification delay ranging from several hours to several days. Once the funds have been transferred, losses are difficult to recover.

[0031] 4. Defects in cross-chain collaboration

[0032] Protocol heterogeneity barrier: Existing cross-chain solutions only support homogeneous chains (such as Fabric-to-Fabric) and cannot adapt to the heterogeneous environment of enterprise private chains (Hyperledger) and tax consortium chains (FISCO BCOS). The cross-chain data verification failure rate is high, and it is impossible to ensure the consistency of the flow directions of invoices and funds.

[0033] The embodiments of this application aim to solve the above problems through technical means such as data integration, graph construction, GNN risk mining, and cross-chain verification, achieve systematic risk identification, and improve the accuracy of invoice risk identification.

[0034] Specifically, the embodiments of this application comprehensively improve the accuracy of invoice risk identification through the following technical means:

[0035] 1. Multi-source heterogeneous data fusion: Design a cross-chain data access protocol to break down the data barriers among enterprise chains (invoices), bank chains (funds), and APIs (industry and commerce / geography), and construct a full-dimensional transaction map covering bill flows, fund flows, equity flows, and logistics flows.

[0036] 2. Dynamic spatio-temporal feature integration: Embed spatio-temporal sensitive parameters (such as the GPS coordinates of the invoicing location and the transaction time interval) in the node attributes to capture cross-regional abnormal invoicing behaviors in real time.

[0037] 3. Dynamic graph neural network modeling: Develop a time-series aware GNN model (improved based on GraphSAGE) to extract topological risk features (such as circular transaction paths and abnormal equity control chains) through the neighbor aggregation mechanism.

[0038] 4. Adaptive risk rule generation: Replace manually preset rules and automatically learn dynamic risk thresholds (such as the reasonable invoicing frequency ranges for different industries / regions) through the GNN model.

[0039] 5. Streaming graph computing engine: Based on Apache Flink, implement real-time update of edge weights (such as refreshing the transaction frequency coefficient every 5 seconds) to support millisecond-level risk scoring.

[0040] 6. Heterogeneous cross-chain verification protocol: Design a relay-chain-driven atomic swap protocol that is compatible with heterogeneous algorithms such as SM3 (invoice hash) and Paillier (encrypted fund flow) to ensure that the cross-chain data matching success rate is ≥99.9%.

[0041] Through the above innovations, the embodiments of this application solve the pain points of traditional invoice risk identification in terms of data level, analysis methods, real-time performance, and cross-chain assistance, and improve the accuracy of invoice risk identification.

[0042] Next, in combination with the accompanying drawings, the method for identifying transaction risks provided by the embodiments of this application will be described in detail through specific embodiments and their application scenarios.

[0043] As Figure 1 shown, it is a flowchart of a method for identifying transaction risks provided by the embodiments of this application, and the method includes the following steps:

[0044] Step 101, obtain multi-source heterogeneous data, and initialize a dynamic transaction map according to the multi-source heterogeneous data stream; the multi-source heterogeneous data includes invoice data, fund flow data, enterprise equity relationships, and geographical data.

[0045] Specifically, taking enterprises, invoices, and bank accounts as nodes, taking transaction relationships as edges, initialize a dynamic transaction map, embed initial features in each node, and calculate edge weights.

[0046] In this embodiment, industry category, registered capital, and historical risk records can be embedded in the enterprise node, invoice code, amount, and commodity item can be embedded in the invoice node, and the opening bank, transaction frequency, and balance fluctuation can be embedded in the bank account node; the edge relationships of the enterprise node include invoice flow, fund flow, and holding relationship, the edge relationships of the invoice node include associated enterprises and associated bank accounts, and the edge relationships of the bank account node include fund payers and payees and associated invoices.

[0047] Among them, invoice data includes invoice code, amount, and invoicing time, and geographical data includes the GPS coordinates of the invoicing location.

[0048] Step 102, receive the multi-source event stream through the message queue, and update the dynamic transaction graph in real time based on the multi-source event stream; the dynamic transaction graph includes bill flow, fund flow, equity flow, and logistics flow.

[0049] Specifically, a sliding window mechanism can be used to process the multi-source data stream, the edge weights of the dynamic transaction graph can be updated in real time using a stream processing engine, and the edge weights can be synchronized to the graph database.

[0050] Step 103, for the enterprise nodes in the dynamic transaction graph affected by the update, perform feature aggregation, extract topological risk features, and output the risk scores of the enterprise nodes; through the relay chain protocol, verify the consistency between the invoice hash and the fund flow hash to obtain the cross-chain verification result.

[0051] Specifically, for the enterprise nodes in the dynamic transaction graph affected by the update, sample the invoice nodes directly associated with them, and calculate the aggregated features of the invoice nodes according to the features of the enterprise nodes and the edge weights between the enterprise nodes and the invoice nodes; sample the enterprise nodes second-order associated with the enterprise nodes affected by the update, calculate the aggregated features of the second-order associated enterprise nodes according to the aggregated features of the invoice nodes, and output the risk scores of the enterprise nodes based on the aggregated features.

[0052] In addition, an invoice hash can be generated according to the invoice code, number, amount, and invoicing time; the Paillier homomorphic encryption algorithm can be used to encrypt the fund flow data to obtain the fund flow hash; through the smart contract based on the relay chain, verify the time synchronization and amount consistency between the invoice hash and the fund flow hash to obtain the cross-chain verification result.

[0053] Step 104, identify transaction risks based on the risk scores and the cross-chain verification results.

[0054] Specifically, if the risk score is greater than the first preset value, the corresponding enterprise node is marked as a high-risk enterprise; if the cross-chain verification result is verification passed, the transaction is released; if the cross-chain verification result is verification failed, the transaction is marked as high-risk.

[0055] The embodiment of the present application realizes systematic risk identification through data integration, graph construction, risk mining, and cross-chain verification, and can improve the accuracy of invoice risk identification.

[0056] In the embodiment of the present application, the specific implementation process of identifying transaction risks includes the following steps:

[0057] 1. Data integration: Collect multi-source data through API / blockchain nodes;

[0058] 2. Graph construction: Initialize the graph structure with enterprises, invoices, and accounts as nodes and transaction relationships as edges, as shown in Table 1;

[0059] Table 1 Attribute table of the dynamic transaction graph

[0060] Node Type Attribute Example Edge Relationship Edge Weight Calculation Enterprise Node Industry Category, Registered Location, Equity Structure Invoice Flow, Capital Flow, Shareholding Relationship W = α * Transaction Frequency + β * Address Coincidence Degree + γ * Equity Weight Invoice Node Invoice Code, Amount, Commodity Item Associated Enterprises, Associated Bank Accounts W = δ * Amount Deviation Rate (compared with industry average) Bank Account Node Opening Bank, Transaction Frequency, Balance Fluctuation Fund Receiving and Paying Party, Associated Invoice W = 8 * Short-Term High-Frequency Transaction Coefficient

[0061] 3. Dynamic weight update: Adjust the edge weights according to time-series data (formula: W_ij = α * transaction frequency + β * geographical deviation);

[0062] 3.1 Time window configuration: Sliding window (window size = 1 hour, sliding step = 5 minutes)

[0063] 3.2 Data stream event processing:

[0064] Event 1: Enterprise A issues an invoice at time t1 → Update the invoice edge weight

[0065] Event 2: Enterprise B receives funds at time t2 → Update the funds edge weight

[0066] Event 3: The equity of enterprise C changes at time t3 → Update the holding edge weight

[0067] Event ingestion: Receive the event stream through the Kafka message queue (TPS ≥ 10,000)

[0068] Event format: {event type, subject ID, associated ID, timestamp, metadata}

[0069] Real-time weight update: Use the Apache Flink state backend (RocksDB) to maintain the edge weights, and recalculate the weights of the corresponding edges each time an event is triggered (update period ≤ 100ms)

[0070] Graph status synchronization: The updated edge weights are immediately synchronized to the graph database (Neo4j)

[0071] 3.3 Real-time response logic: Window trigger condition: Cumulative events ≥ 100 or timeout of 5 minutes;

[0072] 4. GNN risk mining: Aggregate neighbor node features through GraphSAGE and output risk scores;

[0073] Input: Dynamic graph G = (V, E, W)

[0074]

[0075] Among them, σ is the ReLU activation function; W_agg is the trainable aggregation weight matrix; CONCAT is the concatenation of feature vectors.

[0076] Local subgraph extraction: Based on the changed edges, extract the affected enterprise nodes and their 2-hop neighbors.

[0077] Incremental inference: Only perform GNN feature aggregation on the changed nodes (not full-graph calculation); Computation time: Average 8 ms / node (accelerated by NVIDIA A100 GPU).

[0078] Result output: Output the latest risk score and write it into the Redis cache (response latency ≤ 50 ms); High-risk enterprises (score ≥ 80) trigger real-time interception of bank API transactions.

[0079] 5. Cross-chain verification: Trigger the relay chain protocol to compare the consistency of the invoice hash and the fund flow hash;

[0080] Invoice hash: Algorithm: SM3 national cryptographic algorithm; Input: Invoice code + number + amount + invoicing time (accurate to seconds).

[0081] Fund flow encryption: Algorithm: Paillier homomorphic encryption; Feature: Supports ciphertext addition and subtraction operations to ensure the privacy of amount verification.

[0082] The relay chain calls the smart contract to verify the time synchronization (allowing a deviation of ±5 minutes) and amount consistency (error ≤ 1%) of the invoice hash and the fund flow hash. If the verification passes, the transaction is released; otherwise, an alarm is triggered and the transaction is rolled back.

[0083] After three retry verifications fail, mark the transaction as "high risk" and freeze the fund flow.

[0084] 6. Alarm handling: Automatically intercept or manually review high-risk nodes.

[0085] The hardware deployment in the embodiments of this application includes:

[0086] Data Node: Deploy Hyperledger Fabric enterprise chain and FISCO BCOS consortium chain nodes;

[0087] Computing Server: Configure NVIDIA A100 GPUs to run the GNN model;

[0088] Relay Chain: Developed based on the Polkadot Substrate framework.

[0089] Computing Cluster: Real-time Computing Server: NVIDIA DGX A100 (8×A100 GPUs), running the Apache Flink stream processing engine;

[0090] Storage Node: Ceph distributed storage cluster (total capacity 1PB), storing historical graph data.

[0091] The software deployment in the embodiments of this application includes:

[0092] Dynamic Graph Module: Implement the GraphSAGE algorithm using PyTorch Geometric;

[0093] Cross-chain Protocol: Adopt HTLC (Hash Time Lock Contract) to ensure atomic swap;

[0094] Encryption Algorithm: Use SM3 for invoice hash generation and Paillier homomorphic encryption for fund flow.

[0095] The data stream processing in the embodiments of this application includes:

[0096] Real-time Processing Flow: Kafka Topic (Raw Data) → Flink ETL → Neo4j Graph Update → GNN Inference → Redis Cache Results → API Response

[0097] Performance Metrics: End-to-end Latency: ≤500ms (from data ingestion to risk score output); Throughput: ≥10,000 events / second.

[0098] The model training and optimization in the embodiments of this application includes:

[0099] Training Data: Positive Samples: 1,200 enterprises involved in historical invoice fraud cases and their associated invoice / fund data; Negative Samples: Data of 50,000 randomly selected normal enterprises.

[0100] Hyperparameters: Learning Rate: 0.001 (Adam optimizer); Number of Training Epochs: 50 epochs; Regularization: L2 coefficient = 0.005, Dropout rate = 0.3.

[0101] Performance verification: Accuracy: 93.2% (F1 Score); Inference speed: 15ms / enterprise node (A100 GPU).

[0102] In the embodiments of the present application, through multi-source data fusion, dynamic GNN modeling, and real-time cross-chain verification, full-dimensional risk penetration is achieved, breaking through the limitations of single-vote authenticity verification. For the first time, four-dimensional correlation analysis of "fund - bill - equity - geography" is realized, and the identification rate of false invoicing gangs is increased to 93%. The embodiments of the present application can also dynamically adapt rules, learn new risk patterns (such as NFT invoice money laundering) in real time through GNN, replace manual rules, and reduce the false alarm rate to 2.1% (traditional solution ≥ 18%). The embodiments of the present application can also achieve second-level risk interception, with the entire process from invoicing to fund freezing ≤ 8 seconds, which is 10,800 times more efficient than traditional manual auditing (3 - 7 days). The embodiments of the present application can also achieve seamless collaboration of heterogeneous chains, support atomic verification of data on enterprise chains (private), bank chains (consortium), and industrial and commercial chains (public), and break data islands. The embodiments of the present application can also achieve compliance, cost reduction, and efficiency improvement. Pilot enterprises reduce 70% of their auditing manpower, intercept more than 500 million yuan of risk funds annually, meeting the regulatory requirements of "governing taxes by data" in the fourth phase of the Golden Tax Project.

[0103] As Figure 2 shown, it is a schematic structural diagram of a system for identifying transaction risks provided by the embodiments of the present application, including:

[0104] A construction module 210, configured to obtain multi-source heterogeneous data and initialize a dynamic transaction graph according to the multi-source heterogeneous data stream; the multi-source heterogeneous data includes invoice data, fund flow data, enterprise equity relationships, and geographical data.

[0105] Specifically, the construction module 210 is specifically configured to initialize a dynamic transaction graph with enterprises, invoices, and bank accounts as nodes and transaction relationships as edges, embed initial features in each node, and calculate edge weights.

[0106] Among them, the invoice data includes invoice codes, amounts, and invoicing times, and the geographical data includes GPS coordinates of the invoicing locations;

[0107] In this embodiment, the construction module 210 is specifically configured to embed industry categories, registered capital, and historical risk records for enterprise nodes, embed invoice codes, amounts, and commodity items for invoice nodes, and embed bank opening branches, transaction frequencies, and balance fluctuations for bank account nodes; the edge relationships of the enterprise nodes include invoice flow, fund flow, and holding relationships, the edge relationships of the invoice nodes include associated enterprises and associated bank accounts, and the edge relationships of the bank account nodes include fund payers and payees and associated invoices.

[0108] An update module 220 for receiving multi-source event streams through a message queue and updating the dynamic transaction graph in real time based on the multi-source event streams; the dynamic transaction graph includes a bill flow, a fund flow, an equity flow, and a logistics flow.

[0109] Specifically, the update module 220 is specifically configured to process the multi-source data stream by using a sliding window mechanism, use a stream processing engine to update the edge weights of the dynamic transaction graph in real time, and synchronize the edge weights to a graph database.

[0110] An evaluation module 230 for performing feature aggregation on enterprise nodes affected by the update in the dynamic transaction graph, extracting topological risk features, and outputting risk scores of the enterprise nodes; verifying the consistency of the invoice hash and the fund flow hash through a relay chain protocol to obtain a cross-chain verification result.

[0111] Specifically, the evaluation module 230 is specifically configured to sample invoice nodes directly associated with the enterprise nodes affected by the update in the dynamic transaction graph, and calculate the aggregated features of the invoice nodes according to the features of the enterprise nodes and the edge weights between the enterprise nodes and the invoice nodes; sample enterprise nodes second-order associated with the enterprise nodes affected by the update, calculate the aggregated features of the second-order associated enterprise nodes according to the aggregated features of the invoice nodes, and output the risk scores of the enterprise nodes based on the aggregated features.

[0112] The evaluation module 230 is also specifically configured to generate an invoice hash according to the invoice code, number, amount, and invoicing time; encrypt the fund flow data by using the Paillier homomorphic encryption algorithm to obtain a fund flow hash; verify the time synchronization and amount consistency of the invoice hash and the fund flow hash through a smart contract based on a relay chain to obtain a cross-chain verification result.

[0113] An identification module 240 for identifying transaction risks according to the risk scores and the cross-chain verification results.

[0114] Specifically, the identification module 240 is specifically configured to label the corresponding enterprise nodes as high-risk enterprises if the risk scores are greater than a first preset value; release the transaction if the cross-chain verification result is verification passed; and mark the transaction as high-risk if the cross-chain verification result is verification failed.

[0115] The embodiments of the present application realize systematic risk identification through data integration, graph construction, risk mining, and cross-chain verification, and can improve the accuracy of invoice risk identification.

[0116] The embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements each process of the above method embodiment for identifying transaction risks and can achieve the same technical effects. To avoid repetition, it will not be elaborated here. Among them, the computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc, etc.

[0117] It should be noted that in this article, the term "including", "comprising", or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device including a series of elements not only includes those elements but also includes other elements not explicitly listed, or further includes elements inherent to such a process, method, article, or device. Without more limitations, an element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, article, or device including that element.

[0118] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment method can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc) and includes several instructions to enable a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in the various embodiments of the present application.

[0119] The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above specific implementation manners. The above specific implementation manners are merely illustrative and not restrictive. Under the inspiration of the present application, those of ordinary skill in the art can also make many forms without departing from the purpose of the present application and the scope protected by the claims, and all of them belong to the protection scope of the present application.

Claims

1. A method for identifying transaction risks, characterized in that, Including the following steps: Obtain multi-source heterogeneous data, and initialize a dynamic transaction graph according to the multi-source heterogeneous data stream; the multi-source heterogeneous data includes invoice data, fund flow data, enterprise equity relations, and geographical data; Receive a multi-source event stream through a message queue, and update the dynamic transaction graph in real time based on the multi-source event stream; the dynamic transaction graph includes a bill flow, a fund flow, an equity flow, and a logistics flow; For the enterprise nodes in the dynamic transaction graph affected by the update, perform feature aggregation, extract topological risk features, and output the risk scores of the enterprise nodes; Through the relay chain protocol, verify the consistency of the invoice hash and the fund flow hash, and obtain the cross-chain verification result; Identify transaction risks according to the risk scores and the cross-chain verification results.

2. The method according to claim 1, characterized in that The initialization of the dynamic transaction graph according to the multi-source heterogeneous data stream specifically includes: Initialize a dynamic transaction graph with enterprises, invoices, and bank accounts as nodes and transaction relationships as edges, embed initial features in each node, and calculate edge weights; The real-time update of the dynamic transaction graph based on the multi-source data stream specifically includes: Adopt a sliding window mechanism to process the multi-source data stream, use a stream processing engine to update the edge weights of the dynamic transaction graph in real time, and synchronize the edge weights to the graph database.

3. The method according to claim 2, characterized in that The invoice data includes invoice codes, amounts, and invoicing times, and the geographical data includes the GPS coordinates of the invoicing locations; The embedding of initial features in each node includes: Embed industry categories, registered capital, and historical risk records for enterprise nodes, invoice codes, amounts, and commodity items for invoice nodes, and bank branch names, transaction frequencies, and balance fluctuations for bank account nodes; the edge relationships of the enterprise nodes include invoice flow directions, fund flow directions, and holding relationships, the edge relationships of the invoice nodes include associated enterprises and associated bank accounts, and the edge relationships of the bank account nodes include fund payers and payees and associated invoices.

4. The method according to claim 1, wherein The execution of feature aggregation for the enterprise nodes in the dynamic transaction graph affected by the update, extraction of topological risk features, and output of the risk scores of the enterprise nodes specifically include: For the enterprise nodes in the dynamic transaction graph affected by the update, sample the directly associated invoice nodes, and calculate the aggregated features of the invoice nodes according to the features of the enterprise nodes and the edge weights between the enterprise nodes and the invoice nodes; Sample the enterprise nodes second-order associated with the enterprise nodes affected by the update, calculate the aggregated features of the second-order associated enterprise nodes according to the aggregated features of the invoice nodes, and output the risk scores of the enterprise nodes based on the aggregated features.

5. The method according to claim 4, wherein The verification of the consistency of the invoice hash and the fund flow hash through the relay chain protocol and obtaining the cross-chain verification result specifically includes: Generate an invoice hash according to the invoice code, number, amount, and invoicing time; Use the Paillier homomorphic encryption algorithm to encrypt the fund flow data to obtain a fund flow hash; Through an intelligent contract based on the relay chain, verify the time synchronization and amount consistency of the invoice hash and the fund flow hash, and obtain the cross-chain verification result; Identifying transaction risks based on the risk score and the cross-chain verification result specifically includes: If the risk score is greater than the first preset value, mark the corresponding enterprise node as a high-risk enterprise; If the cross-chain verification result is verification passed, release the transaction; If the cross-chain verification result is verification failed, mark the transaction as high risk.

6. A system for identifying transaction risks, characterized in that, Including: A construction module for obtaining multi-source heterogeneous data and initializing a dynamic transaction graph according to the multi-source heterogeneous data stream; the multi-source heterogeneous data includes invoice data, fund flow data, enterprise equity relations, and geographical data; An update module for receiving a multi-source event stream through a message queue and updating the dynamic transaction graph in real time based on the multi-source event stream; the dynamic transaction graph includes a bill flow, a fund flow, an equity flow, and a logistics flow; An evaluation module for performing feature aggregation on enterprise nodes affected by the update in the dynamic transaction graph, extracting topological risk features, and outputting the risk score of the enterprise nodes; Verify the consistency of the invoice hash and the fund flow hash through the relay chain protocol to obtain the cross-chain verification result; An identification module for identifying transaction risks based on the risk score and the cross-chain verification result.

7. The system according to claim 6, wherein The construction module is specifically configured to initialize a dynamic transaction graph with enterprises, invoices, and bank accounts as nodes, transaction relationships as edges, embed initial features in each node, and calculate edge weights; The update module is specifically configured to process the multi-source data stream by using a sliding window mechanism, use a stream processing engine to update the edge weights of the dynamic transaction graph in real time, and synchronize the edge weights to the graph database.

8. The system according to claim 7, wherein The invoice data includes an invoice code, an amount, and an invoicing time, and the geographical data includes the GPS coordinates of the invoicing location; The construction module is specifically configured to embed an industry category, a registered capital, and a historical risk record for an enterprise node, an invoice code, an amount, and a commodity item for an invoice node, and a bank opening, a transaction frequency, and a balance fluctuation for a bank account node; the edge relationships of the enterprise nodes include an invoice flow direction, a fund flow direction, and a holding relationship, the edge relationships of the invoice nodes include associated enterprises and associated bank accounts, and the edge relationships of the bank account nodes include fund payers and payees and associated invoices.

9. The system according to claim 6, wherein The evaluation module is specifically configured to sample invoice nodes directly associated with an enterprise node affected by the update in the dynamic transaction graph, and calculate the aggregated features of the invoice nodes according to the features of the enterprise node and the edge weights between the enterprise node and the invoice nodes; Sample enterprise nodes second-order associated with the enterprise node affected by the update, calculate the aggregated features of the second-order associated enterprise nodes according to the aggregated features of the invoice nodes, and output the risk score of the enterprise node based on the aggregated features.

10. The system according to claim 9, wherein The evaluation module is specifically configured to generate an invoice hash based on the invoice code, number, amount, and invoicing time; encrypt the fund flow data using the Paillier homomorphic encryption algorithm to obtain a fund flow hash; verify the time synchronization and amount consistency between the invoice hash and the fund flow hash through a smart contract based on the relay chain, and obtain a cross-chain verification result; The identification module is specifically configured to label the corresponding enterprise node as a high-risk enterprise if the risk score is greater than a first preset value; If the cross-chain verification result is verification passed, release the transaction; if the cross-chain verification result is verification failed, mark the transaction as high risk.

Images