Block chain-based cross-border payment transaction risk control method

Abstract

The invention relates to the technical field of cross-border payment, and discloses a cross-border payment transaction risk control method based on a block chain, and the method comprises the following steps: constructing a federated learning model, deploying a local training node by a participation mechanism, transmitting gradient parameters through 256-bit homomorphic encryption, and avoiding the cross-border transmission of original data; constructing a customized circuit based on Li bsnk, and verifying the validity of gradient parameters and the legality of identities of participants; constructing an account-transaction-IP three-dimensional map, updating node association weights in real time, identifying a fund loop by adopting a GraphSAGE algorithm, and detecting space-time anomalies in combination with an LOF algorithm; the federal learning model outputs a real-time risk score, and the real-time risk score is fused with an atlas analysis result to realize millisecond risk interception; and block chain evidence storage. According to the method, through a federated learning model (FedProx algorithm) and 256-bit homomorphic encryption, safe aggregation of gradient parameters is realized, the problem of data islands is solved, compliance risks of original data cross-border transmission are avoided, and a cross-machine data system is realized.

Description

Technical Field

[0001] This invention relates to the field of cross-border payment technology, specifically to a blockchain-based method for risk control in cross-border payment transactions. Background Technology

[0002] Cross-border payment refers to the act of transferring funds across borders or regions through payment or settlement processes that occur between two or more countries or regions. Its core characteristics include: (1) cross-border fund flows, involving international debt settlement in scenarios such as international trade and investment, which requires the use of specific payment systems (such as SWIFT and CIPS) to complete fund transfers.

[0003] (2) Currency exchange needs: the two parties to the transaction usually use different currencies and need to convert the exchange rate in real time through a bank or payment platform (such as the exchange of RMB and USD).

[0004] (3) Multilateral regulatory compliance requires compliance with the foreign exchange management policies of various countries (such as China's foreign exchange control) and anti-money laundering regulations (such as the EU's AMLD).

[0005] Traditional cross-border payments rely on centralized systems such as SWIFT, which prevents data sharing among participating institutions, resulting in insufficient training samples for risk control models. Furthermore, the cross-border transmission of raw data violates privacy regulations such as GDPR. Risk control relies on post-transaction audits, which cannot effectively intercept abnormal transactions and are prone to fund losses. Key operation records are stored in a scattered manner and lack a blockchain for evidence preservation, resulting in low audit efficiency and an inability to meet the audit requirements of different countries. Therefore, a blockchain-based risk control method for cross-border payment transactions is proposed to address the aforementioned problems. Summary of the Invention

[0006] (a) Technical problems to be solved

[0007] To address the shortcomings of existing technologies, this invention provides a blockchain-based risk control method for cross-border payment transactions. This method offers advantages such as rapid risk interception and efficient auditing. It solves the problems of traditional cross-border payments relying on centralized systems like SWIFT, where data sharing among participating institutions is impossible, leading to insufficient training samples for risk control models. Furthermore, the cross-border transmission of raw data violates privacy regulations such as GDPR. Risk control relies on post-transaction auditing, which fails to effectively intercept abnormal transactions, easily resulting in fund losses. Additionally, the scattered storage of key operation records and the lack of a blockchain for evidence preservation lead to low audit efficiency and an inability to meet the auditing requirements of different countries.

[0008] (II) Technical Solution

[0009] This invention provides the following technical solution: a blockchain-based risk control method for cross-border payment transactions, characterized by comprising the following steps:

[0010] Step 1: Construct a federated learning model, with participating institutions deploying local training nodes, using 256-bit homomorphic encryption to transmit gradient parameters, and implementing cross-institutional model updates through the Secure Aggregation protocol to avoid cross-border transmission of raw data;

[0011] Step 2: Overlay differential privacy to prevent gradient backpropagation, and start joint training every day at midnight;

[0012] Step 3: Build a custom circuit based on Libsnark to verify the validity of the gradient parameters and the legitimacy of the participants' identities;

[0013] Step 4: Construct a three-dimensional graph of "account-transaction-IP", update the node association weights in real time, use the GraphSAGE algorithm to identify fund loops, and combine the LOF algorithm to detect spatiotemporal anomalies;

[0014] Step 5: The federated learning model outputs a real-time risk score, which is then fused with the graph analysis results to achieve millisecond-level risk interception. Unfreezing requires the signatures of 2 / 3 of the regulatory authorities.

[0015] Step 6: Blockchain evidence storage. Key risk control operations are stored on the blockchain to support regulatory audit traceability.

[0016] Preferably, the specific steps for constructing the federated learning model in step 1 are as follows:

[0017] Step 101: Local Data Standardization

[0018] Each participating party independently completes data cleaning and feature alignment to ensure data format compatibility, unifies timestamp and ID mapping rules, adopts encrypted sample alignment technology, identifies users shared across institutions, and avoids the exchange of raw data.

[0019] Step 102: The central server generates initial model parameters and distributes them to each client using the homomorphic Paillier algorithm;

[0020] Step 103: The client verifies the integrity of the parameters and deploys a differential privacy module to inject Gaussian noise with ε≤2;

[0021] Step 104: During the model training phase, the local model update client uses the FedProx algorithm to train on local data, generates encrypted gradient parameters, and compresses the gradients through the SecureAggregation protocol.

[0022] Step 105: The aggregated global model is homomorphically encrypted and returned to the client. The weights are then updated after local decryption.

[0023] Preferably, the comprehensive formula of the homomorphic encryption Paillier algorithm is as follows:

[0024]

[0025] Encryption: c = g m ·r n modn 2

[0026] Decryption: m = L(c λ mod n 2 )·μmod n(μ=(L(g λ mod n 2 )) -1 mod n)

[0027] Where p, q: large prime numbers (foundation for key generation)

[0028] n: Modulus (n = pq)

[0029] λ: Least Common Multiple (lcm(p-1,q-1))

[0030] g: Generator (a random integer that satisfies a specific condition)

[0031] m: Plain text message

[0032] r: random number

[0033] c: Ciphertext

[0034] L(x): Auxiliary function (L(x) = (x-1) / n)

[0035] μ: Decryption coefficient (μ=λ) -1 modn)

[0036] Preferably, the FedProx algorithm formula

[0037]

[0038] Among them, W t+1 : Indicates the weight for the next iteration

[0039] κ: Represents the number of iterations, i.e. the number of loops in the entire optimization process.

[0040] η k : The learning rate in the k-th iteration, which controls the step size of the weight updates.

[0041] N: Total number of iterations, i.e., the total number of iterations that will be performed in the entire training process.

[0042] W k ,t: The weight state at the k-th iteration.

[0043] η (though not directly mentioned, it can be understood from the context as the general learning rate): The learning rate is used to adjust the magnitude of weight updates.

[0044] f k The objective function for the k-th iteration, i.e., the optimization objective.

[0045] μ: Momentum term, used to accelerate convergence and reduce oscillations.

[0046] W t : Indicates the current weight state

[0047] Preferably, in step 4, constructing the "account-transaction-IP" three-dimensional map, the anomaly identification also includes the following steps:

[0048] Step 401: Dynamic graph construction and weight update:

[0049] (1) Definition of multimodal nodes;

[0050] (2) Real-time weight calculation, transaction edge weight: dynamic adjustment formula

[0051]

[0052] Where α, β, and γ are adjustment coefficients, and t is the time decay factor.

[0053] Step 402: Heterogeneous Neighbor Sampling

[0054] (1) Hierarchical sampling strategy:

[0055] Tier 1: Sampling of 50 direct counterparty accounts

[0056] Layer 2: Sample 30 more associated IPs or secondary trading counterparties for each opponent.

[0057] Feature aggregation and training

[0058] (2) Use LSTM aggregation function to process time series transaction features, and after embedding the output nodes, detect closed-loop transactions by cosine similarity.

[0059] Step 403: LOF Spatiotemporal Anomaly Detection

[0060] (1) Feature Engineering

[0061] Spatiotemporal feature vectors: transaction time entropy value, IP geographic displacement velocity anomaly score

[0062] (2) The LOF algorithm calculates the local outlier factor, and LOF>1.5 is judged as an anomaly.

[0063] Preferably, the formula for processing time-series transaction features using the LSTM aggregation function is as follows:

[0064]

[0065] Where h represents the hidden state of node v in the current layer (let's say the l-th layer).

[0066] u represents the hidden state of node v's neighbor node u in the previous layer (layer l-1); u represents a neighbor node of node v.

[0067] N(v): Represents the set of neighbors of node v.

[0068] Preferably, the LOF algorithm calculates the local outlier factor using the following formula:

[0069]

[0070] k represents the number of nearest neighbors considered.

[0071] lrd k (p): Local reachability density of point p, reflecting the density of point p within its k nearest neighbors.

[0072] lr_k(o): Local reachability density of point o, where o represents one of the k nearest neighbors of p.

[0073] N_k(p): The set of the K nearest neighbors of point p, i.e., the set of the k points closest to point p.

[0074] point The number of the k nearest neighbors, i.e., the number of elements in the set N_K(p).

[0075] Preferably, in step 5, the specific steps for fusing the federated learning model with graph analysis to achieve millisecond-level risk interception and multi-signature unfreezing are as follows:

[0076] Step 501: Distributed model inference, each participant (bank, e-commerce, etc.) calculates risk characteristics in real time using local data and generates encrypted local gradient parameters;

[0077] Step 502: The central server aggregates gradients to update the global model and outputs a dynamic risk score (0-100 points). The score threshold is preset by the regulator.

[0078] Step 503: Link the federated score with the "account-transaction-IP" graph in real time and detect funding loops using the GraphSAGE algorithm;

[0079] Step 504: Multimodal risk assessment. If the federated score is >85 and the superimposed map is abnormal, and the IP displacement speed is >500km / h, the interception rule is triggered.

[0080] Step 505: The interception record is uploaded to the blockchain for evidence storage, generating a hash value containing risk details, transaction ID, and reason for interception;

[0081] Step 506: Freezing an account requires two-thirds of the regulators to verify the unfreezing request via digital signature.

[0082] Preferably, step 6, the specific steps of blockchain evidence storage, are as follows:

[0083] Step 601: Data standardization processing. The electronic evidence, contracts, and transaction records are standardized in format and the JSON-LD structured data specification is adopted to ensure that they are machine readable.

[0084] Step 602: Generate a unique hash value for each piece of data using the SHA-256 algorithm, and attach a timestamp and the submitter's digital signature;

[0085] Step 603: Multi-node consensus verification. After data is divided into blocks, it is broadcast to at least 3 geographically dispersed blockchain nodes, and consensus confirmation is achieved through the PBFT consensus mechanism.

[0086] Step 604: Dual evidence storage architecture, the original data is encrypted and stored in IPFS, and only the hash value and metadata are put on the chain to achieve a balance between privacy and verifiability;

[0087] Step 605: Key risk control operations (such as large transaction interception) must be recorded in the operation log simultaneously, including fields such as decision parameters, executor, and timestamp;

[0088] Step 606: Unfreezing high-risk operations requires triggering a multi-signature smart contract, and execution is only possible if 2 / 3 of the regulators collaborate and sign through MPC.

[0089] (III) Beneficial Effects

[0090] Compared with existing technologies, this invention provides a blockchain-based risk control method for cross-border payment transactions, which has the following beneficial effects:

[0091] 1. This blockchain-based cross-border payment transaction risk control method uses a federated learning model (FedProx algorithm) and 256-bit homomorphic encryption (Paillier algorithm) to achieve secure aggregation of gradient parameters, solve the data silo problem, avoid compliance risks in the cross-border transmission of raw data, and realize cross-machine data systems.

[0092] 2. This blockchain-based cross-border payment transaction risk control method uses a three-dimensional graph of "account-transaction-IP" to detect fund loops using the GraphSAGE algorithm and the LOF algorithm to identify spatiotemporal anomalies, thereby achieving dynamic risk identification.

[0093] 3. This blockchain-based cross-border payment transaction risk control method uses a combination of federated scoring and graph analysis to trigger automatic interception with a delay of less than 100ms. Interception records are stored on the blockchain for evidence preservation and support multi-signature unfreezing, thereby ensuring fund security and assisting in rapid auditing. Attached Figure Description

[0094] Figure 1 This is a flowchart of the cross-border payment transaction risk control method of the present invention;

[0095] Figure 2 This is a schematic diagram of the federated learning model of the present invention;

[0096] Figure 3 This is a schematic diagram of the three-dimensional map construction of the present invention;

[0097] Figure 4 This is a flowchart of the blockchain evidence storage process of this invention. Detailed Implementation

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

[0099] Please see Figure 1-4 A blockchain-based risk control method for cross-border payment transactions, characterized by the following steps:

[0100] Step 1: Construct a federated learning model, with participating institutions deploying local training nodes, using 256-bit homomorphic encryption to transmit gradient parameters, and implementing cross-institutional model updates through the Secure Aggregation protocol to avoid cross-border transmission of raw data;

[0101] Step 2: Overlay differential privacy to prevent gradient backpropagation, and start joint training every day at midnight;

[0102] Step 3: Build a custom circuit based on Libsnark to verify the validity of the gradient parameters and the legitimacy of the participants' identities;

[0103] Step 4: Construct a three-dimensional graph of "account-transaction-IP", update the node association weights in real time, use the GraphSAGE algorithm to identify fund loops, and combine the LOF algorithm to detect spatiotemporal anomalies;

[0104] Step 5: The federated learning model outputs a real-time risk score, which is then fused with the graph analysis results to achieve millisecond-level risk interception. Unfreezing requires the signatures of 2 / 3 of the regulatory authorities.

[0105] Step 6: Blockchain evidence storage. Key risk control operations are stored on the blockchain to support regulatory audit traceability.

[0106] Example 1

[0107] The specific steps for constructing the federated learning model in step 1 are as follows:

[0108] Step 101: Local Data Standardization

[0109] Each participating party independently completes data cleaning and feature alignment to ensure data format compatibility, unifies timestamp and ID mapping rules, adopts encrypted sample alignment technology, identifies users shared across institutions, and avoids the exchange of raw data.

[0110] Step 102: The central server generates initial model parameters and distributes them to each client using the homomorphic Paillier algorithm;

[0111] Step 103: The client verifies the integrity of the parameters and deploys a differential privacy module to inject Gaussian noise with ε≤2;

[0112] Step 104: During the model training phase, the local model update client uses the FedProx algorithm to train on local data, generates encrypted gradient parameters, and compresses the gradients through the SecureAggregation protocol.

[0113] Step 105: The aggregated global model is homomorphically encrypted and returned to the client. The weights are then updated after local decryption.

[0114] The comprehensive formula for the homomorphic encryption Paillier algorithm is as follows:

[0115]

[0116] Encryption: c = g m ·r n mod n 2

[0117] Decryption: m = L(c λ mod n 2 )·μmod n(μ=(L(g λ mod n 2 )) -1 mod n)

[0118] Where p, q: large prime numbers (foundation for key generation)

[0119] n: Modulus (n = pq)

[0120] λ: Least Common Multiple (lcm(p-1,q-1))

[0121] g: Generator (a random integer that satisfies a specific condition)

[0122] m: Plain text message r: random number c: Ciphertext

[0123] L(x): Auxiliary function (L(x) = (x-1) / n)

[0124] μ: Decryption coefficient (μ=λ) -1 modn)

[0125] The FedProx algorithm formula

[0126]

[0127] Among them, W t+1 : Indicates the weight for the next iteration; κ: Represents the number of iterations, i.e., the number of loops in the entire optimization process.

[0128] η k : The learning rate in the k-th iteration, which controls the step size of the weight updates.

[0129] N: Total number of iterations, i.e., the total number of iterations that will be performed in the entire training process.

[0130] W k ,t: The weight state at the k-th iteration.

[0131] η (though not directly mentioned, it can be understood from the context as the general learning rate): The learning rate is used to adjust the magnitude of weight updates.

[0132] f k : The objective function of the k-th iteration, i.e., the optimization objective μ: the momentum term, used to accelerate convergence and reduce oscillations W t : Indicates the current weight state. In this embodiment, privacy protection: Paillier homomorphic encryption and differential privacy are used to achieve data "usable but not visible," avoiding cross-border transmission of raw data. Cross-institutional collaboration: The FedProx algorithm is used to aggregate encrypted gradients, solving the data silo problem and improving the model's generalization ability.

[0133] Example 2

[0134] In step 4, constructing a three-dimensional map of "account-transaction-IP" and anomaly identification also includes the following steps:

[0135] Step 401: Dynamic graph construction and weight update:

[0136] (1) Definition of multimodal nodes;

[0137] (2) Real-time weight calculation, transaction edge weight: dynamic adjustment formula

[0138]

[0139] Where α, β, and γ are adjustment coefficients, and t is the time decay factor.

[0140] Step 402: Heterogeneous Neighbor Sampling

[0141] (1) Hierarchical sampling strategy:

[0142] Tier 1: Sampling of 50 direct counterparty accounts

[0143] Layer 2: Sample 30 more associated IPs or secondary trading counterparties for each opponent.

[0144] Feature aggregation and training

[0145] (2) Use LSTM aggregation function to process time series transaction features, and after embedding the output nodes, detect closed-loop transactions by cosine similarity.

[0146] Step 403: LOF Spatiotemporal Anomaly Detection

[0147] (1) Feature Engineering

[0148] Spatiotemporal feature vectors: transaction time entropy value, IP geographic displacement velocity anomaly score

[0149] (2) The LOF algorithm calculates the local outlier factor, and LOF>1.5 is judged as an anomaly.

[0150] Preferably, the formula for processing time-series transaction features using the LSTM aggregation function is as follows:

[0151]

[0152] Where h represents the hidden state of node v in the current layer (let's say the l-th layer).

[0153] This represents the hidden state of node v's neighbor node u in the previous layer (layer l-1).

[0154] u: Represents a neighboring node of node v

[0155] N(v): Represents the set of neighbors of node v.

[0156] The formula for calculating the local outlier factor using the LOF algorithm is as follows:

[0157]

[0158] k represents the number of nearest neighbors considered.

[0159] lrd k(p): Local reachability density of point p, reflecting the density of point p within its k nearest neighbors.

[0160] lr_k(o): Local reachability density of point o, where o represents one of the k nearest neighbors of p.

[0161] N_k(p): The set of the K nearest neighbors of point p, i.e., the set of the k points closest to point p.

[0162] :point The number of k nearest neighbors is the number of elements in the set N_K(p).

[0163] In this embodiment, dynamic risk identification is analyzed through three-dimensional mapping, and spatiotemporal anomalies are detected by combining the LOF algorithm (LOF>1.5 is an anomaly) to identify complex money laundering patterns that cannot be covered by traditional rules.

[0164] Example 3

[0165] In step 5, the specific steps for achieving millisecond-level risk interception and multi-signature unfreezing by fusing the federated learning model with graph analysis are as follows:

[0166] Step 501: Distributed model inference, each participant (bank, e-commerce, etc.) calculates risk characteristics in real time using local data and generates encrypted local gradient parameters;

[0167] Step 502: The central server aggregates gradients to update the global model and outputs a dynamic risk score (0-100 points). The score threshold is preset by the regulator.

[0168] Step 503: Link the federated score with the "account-transaction-IP" graph in real time and detect funding loops using the GraphSAGE algorithm;

[0169] Step 504: Multimodal risk assessment. If the federated score is >85 and the superimposed map is abnormal, and the IP displacement speed is >500km / h, the interception rule is triggered.

[0170] Step 505: The interception record is uploaded to the blockchain for evidence storage, generating a hash value containing risk details, transaction ID, and reason for interception;

[0171] Step 506: Freezing an account requires two-thirds of the regulators to verify the unfreezing request via digital signature.

[0172] In this embodiment, the millisecond-level response is achieved through the fusion of federated scoring and graph anomalies, resulting in an interception delay of <100ms.

[0173] Regulatory checks and balances: Freezing an account requires the joint signature of 2 / 3 of the regulatory bodies' MPCs to prevent abuse of power.

[0174] Example 4

[0175] Step 6, the specific steps of blockchain evidence storage:

[0176] Step 601: Data standardization processing. The electronic evidence, contracts, and transaction records are standardized in format and the JSON-LD structured data specification is adopted to ensure that they are machine readable.

[0177] Step 602: Generate a unique hash value for each piece of data using the SHA-256 algorithm, and attach a timestamp and the submitter's digital signature;

[0178] Step 603: Multi-node consensus verification. After data is divided into blocks, it is broadcast to at least 3 geographically dispersed blockchain nodes, and consensus confirmation is achieved through the PBFT consensus mechanism.

[0179] Step 604: Dual evidence storage architecture, the original data is encrypted and stored in IPFS, and only the hash value and metadata are put on the chain to achieve a balance between privacy and verifiability;

[0180] Step 605: Key risk control operations (such as large transaction interception) must be recorded in the operation log simultaneously, including fields such as decision parameters, executor, and timestamp;

[0181] Step 606: Unfreezing high-risk operations requires triggering a multi-signature smart contract, and execution is only possible if 2 / 3 of the regulators collaborate and sign through MPC.

[0182] In this embodiment, end-to-end auditing is implemented: data is standardized (JSON-LD format) and hashed using SHA-256 on the blockchain, supporting direct retrieval and verification by judicial authorities.

[0183] Evidence for high-risk operations (such as large-scale interception) includes fields such as the executor and timestamp, meeting the requirements of the AMLD regulations.

[0184] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0185] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based risk control method for cross-border payment transactions, characterized in that: Includes the following steps: Step 1: Construct a federated learning model, with participating institutions deploying local training nodes, using 256-bit homomorphic encryption to transmit gradient parameters, and implementing cross-institutional model updates through the Secure Aggregation protocol to avoid cross-border transmission of raw data; Step 2: Overlay differential privacy to prevent gradient backpropagation, and start joint training every day at midnight; Step 3: Build a custom circuit based on Libsnark to verify the validity of the gradient parameters and the legitimacy of the participants' identities; Step 4: Construct a three-dimensional graph of "account-transaction-IP", update the node association weights in real time, use the GraphSAGE algorithm to identify fund loops, and combine the LOF algorithm to detect spatiotemporal anomalies; Step 5: The federated learning model outputs a real-time risk score, which is then fused with the graph analysis results to achieve millisecond-level risk interception. Unfreezing requires the signatures of 2 / 3 of the regulatory authorities. Step 6: Blockchain evidence storage. Key risk control operations are stored on the blockchain to support regulatory audit traceability.

2. The blockchain-based risk control method for cross-border payment transactions according to claim 1, characterized in that: The specific steps for constructing the federated learning model in step 1 are as follows: Step 101: Local Data Standardization Each participating party independently completes data cleaning and feature alignment to ensure data format compatibility, unifies timestamp and ID mapping rules, adopts encrypted sample alignment technology, identifies users shared across institutions, and avoids the exchange of raw data. Step 102: The central server generates initial model parameters and distributes them to each client using the homomorphic Paillier algorithm; Step 103: The client verifies the integrity of the parameters and deploys a differential privacy module to inject Gaussian noise with ε≤2; Step 104: During the model training phase, the local model update client uses the FedProx algorithm to train on local data, generates encrypted gradient parameters, and compresses the gradients through the SecureAggregation protocol. Step 105: The aggregated global model is homomorphically encrypted and returned to the client. The weights are then updated after local decryption.

3. The blockchain-based risk control method for cross-border payment transactions according to claim 1, characterized in that: The comprehensive formula for the homomorphic encryption Paillier algorithm is as follows: Encryption: c = g m ·r n mod n 2 Decryption: m = L(c λ mod n 2 )·μ mod n (μ = (L(g λ mod n 2 )) -1 mod n) Where p, q: large prime numbers (foundation for key generation) n: Modulus (n = pq) λ: Least Common Multiple (lcm(p-1,q-1)) g: Generator (a random integer that satisfies a specific condition) m: Plain text message r: random number c: Ciphertext L(x): Auxiliary function (L(x) = (x-1) / n) μ: Decryption coefficient (μ=λ) -1 mod n).

4. The blockchain-based risk control method for cross-border payment transactions according to claim 2, characterized in that: The FedProx algorithm formula Among them, W t+1 : Indicates the weight for the next iteration κ: Represents the number of iterations, i.e. the number of loops in the entire optimization process. η k : The learning rate in the k-th iteration, which controls the step size of the weight updates. N: Total number of iterations, i.e., the total number of iterations that will be performed in the entire training process. W k ,t: The weight state at the k-th iteration. η (though not directly mentioned, it can be understood from the context as the general learning rate): The learning rate is used to adjust the magnitude of weight updates. f k The objective function for the k-th iteration, i.e., the optimization objective. μ: Momentum term, used to accelerate convergence and reduce oscillations. W t : Indicates the current weight state.

5. The blockchain-based risk control method for cross-border payment transactions according to claim 1, characterized in that: In step 4, constructing a three-dimensional "account-transaction-IP" map, the anomaly identification also includes the following steps: Step 401: Dynamic graph construction and weight update: (1) Definition of multimodal nodes; (2) Real-time weight calculation, transaction edge weight: dynamic adjustment formula Where α, β, and γ are adjustment coefficients, and t is the time decay factor. Step 402: Heterogeneous Neighbor Sampling (1) Hierarchical sampling strategy: Tier 1: Sampling of 50 direct counterparty accounts Layer 2: Sample 30 more associated IPs or secondary trading counterparties for each opponent. Feature aggregation and training (2) Use LSTM aggregation function to process time series transaction features, and after embedding the output nodes, detect closed-loop transactions by cosine similarity. Step 403: LOF Spatiotemporal Anomaly Detection (1) Feature Engineering Spatiotemporal feature vectors: transaction time entropy value, IP geographic displacement velocity anomaly score (2) The LOF algorithm calculates the local outlier factor, and LOF>1.5 is judged as an anomaly.

6. The blockchain-based risk control method for cross-border payment transactions according to claim 1, characterized in that: The formula for processing time-series transaction features using LSTM aggregation functions: Where h represents the hidden state of node v in the current layer (let's say the l-th layer). u represents the hidden state of node v's neighbor node u in the previous layer (layer l-1); u represents a neighbor node of node v. N(v): Represents the set of neighbors of node v.

7. The blockchain-based risk control method for cross-border payment transactions according to claim 1, characterized in that: The formula for calculating the local outlier factor using the LOF algorithm is as follows: k represents the number of nearest neighbors considered. lrd k (p): Local reachability density of point p, reflecting the density of point p within its k nearest neighbors. lr_k(o): Local reachability density of point o, where o represents one of the k nearest neighbors of p. N_k(p): The set of the K nearest neighbors of point p, i.e., the set of the k points closest to point p. point The number of k nearest neighbors is the number of elements in the set N_K(p).

8. The blockchain-based risk control method for cross-border payment transactions according to claim 1, characterized in that: In step 5, the specific steps for achieving millisecond-level risk interception and multi-signature unfreezing by fusing federated learning models and graph analysis are as follows: Step 501: Distributed model inference, each participant (bank, e-commerce, etc.) calculates risk characteristics in real time using local data and generates encrypted local gradient parameters; Step 502: The central server aggregates gradients to update the global model and outputs a dynamic risk score (0-100 points). The score threshold is preset by the regulator. Step 503: Link the federated score with the "account-transaction-IP" graph in real time and detect funding loops using the GraphSAGE algorithm; Step 504: Multimodal risk assessment. If the federated score is >85 and the superimposed map is abnormal, and the IP displacement speed is >500km / h, the interception rule is triggered. Step 505: The interception record is uploaded to the blockchain for evidence storage, generating a hash value containing risk details, transaction ID, and reason for interception; Step 506: Freezing an account requires two-thirds of the regulators to verify the unfreezing request via digital signature.

9. The blockchain-based risk control method for cross-border payment transactions according to claim 1, characterized in that: Step 6, the specific steps of blockchain evidence storage: Step 601: Data standardization processing. The electronic evidence, contracts, and transaction records are standardized in format and the JSON-LD structured data specification is adopted to ensure that they are machine readable. Step 602: Generate a unique hash value for each piece of data using the SHA-256 algorithm, and attach a timestamp and the submitter's digital signature. Step 603: Multi-node consensus verification. After data is divided into blocks, it is broadcast to at least 3 geographically dispersed blockchain nodes, and consensus confirmation is achieved through the PBFT consensus mechanism. Step 604: Dual evidence storage architecture, the original data is encrypted and stored in IPFS, and only the hash value and metadata are put on the chain to achieve a balance between privacy and verifiability; Step 605: Key risk control operations (such as large transaction interception) must be recorded in the operation log simultaneously, including fields such as decision parameters, executor, and timestamp; Step 606: Unfreezing high-risk operations requires triggering a multi-signature smart contract, and execution is only possible if 2 / 3 of the regulators collaborate and sign through MPC.

Images