Cross-border payment adaptive risk control method and system based on multi-dimensional segmented threshold

Abstract

The application relates to the technical field of payment risk control, and proposes a cross-border payment adaptive risk control method and system based on a multi-dimensional segmented threshold value.The method comprises the following steps: recording transaction facts on a blockchain in a Merkle tree structure for storage, generating a risk segmentation identifier according to the risk state of the transaction fact record, and associating the risk segmentation identifier to the transaction fact record; reading a currently effective segmented threshold value strategy version from a threshold value strategy account of the blockchain, acquiring a differentiated risk control threshold value and a verification strategy configuration corresponding to the risk segmentation identifier; performing verification according to the verification strategy configuration, and recording a verification result on a chain for storage; outputting a risk control decision result according to the risk segmentation identifier, the differentiated risk control threshold value and the verification result, and writing the risk control decision result and a transaction subsequent state into a feedback queue of the blockchain to trigger an asynchronous threshold value optimization process; and the application can improve the whole-process credibility of cross-border payment risk control.

Description

Technical Field

[0001] This invention relates to the field of payment risk control technology, and in particular to an adaptive risk control method and system for cross-border payments based on multi-dimensional segmented thresholds. Background Technology

[0002] Existing cross-border payment risk control systems typically employ an architecture with unified thresholds and fixed verification rules. Upon transaction arrival, the system evaluates a limited set of dimensions, including order amount, address verification, and third-party risk scoring, based on a pre-defined single risk scoring model or rule engine. The overall score is then compared to globally unified pass / fail thresholds and block boundaries, outputting a pass, pending review, or block conclusion. Adjustments to risk control strategies rely on manual analysis of historical data and modification of configuration files or rule base parameters, resulting in a lack of systematic lifecycle management for strategy versions.

[0003] This architecture faces significant challenges in cross-border payment scenarios. The risk characteristics vary considerably across different countries, currencies, card-issuing regions, and merchant qualifications. A uniform threshold is insufficient to adapt to the actual risk distribution across different scenarios, easily leading to excessively high false positives and false negatives in some areas. Foreign exchange policies, compliance requirements, and risk lists change rapidly, and manual adjustments are significantly lagging, making it difficult to respond promptly to regulatory changes and new risk patterns. Fixed thresholds and verification strategies also struggle to simultaneously achieve a dynamic balance between multiple objectives, including transaction approval rates, chargeback rates, manual review workload, and compliance risk. Summary of the Invention

[0004] To achieve the above objectives, the present invention provides an adaptive risk control method for cross-border payments based on multi-dimensional segmented thresholds, comprising: Step 110: Record the transaction facts on the blockchain and organize and store them in a Merkle tree structure. Generate risk segmentation identifiers based on the risk status of the transaction facts records and associate the risk segmentation identifiers with the transaction facts records. Step 120: Read the currently effective segmented threshold strategy version from the threshold strategy account on the blockchain, and obtain the differentiated risk control threshold and verification strategy configuration corresponding to the risk segmentation identifier; Step 130: Perform verification according to the verification strategy configuration, and record the verification results on the blockchain for evidence storage; Step 140: Output the risk control decision result based on the risk segmentation identifier, differentiated risk control threshold, and verification result. At the same time, write the risk control decision result and the subsequent status of the transaction into the feedback queue of the blockchain to trigger the asynchronous threshold optimization process.

[0005] To address the aforementioned problems, this invention also provides a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, the system comprising: Transaction record storage module: Records transaction facts on the blockchain and organizes them in a Merkle tree structure. Based on the risk status of the transaction fact records, it generates risk segmentation identifiers and associates the risk segmentation identifiers with the transaction fact records. Threshold matching module: Reads the currently effective segmented threshold strategy version from the threshold strategy account on the blockchain, and obtains the differentiated risk control threshold and verification strategy configuration corresponding to the risk segmentation identifier; On-chain verification module: Performs verification according to the verification strategy configuration and records the verification results on the blockchain for evidence storage; Decision Iteration Module: Outputs risk control decision results based on risk segmentation identifiers, differentiated risk control thresholds, and verification results. Simultaneously, it writes the risk control decision results and subsequent transaction status into the feedback queue of the blockchain, triggering an asynchronous threshold optimization process.

[0006] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention establishes a closed-loop architecture that separates real-time decision-making from parameter optimization by recording transaction facts on the blockchain for evidence storage and generating risk segmentation identifiers, reading currently effective segment thresholds and verification strategies from the blockchain strategy account, and writing risk control results into an on-chain feedback queue to trigger asynchronous threshold optimization. The real-time decision-making link relies only on the fixed strategy version already in effect on the blockchain, avoiding inconsistencies caused by dynamic parameter changes during single transaction processing; the asynchronous optimization link drives threshold updates based on trusted feedback data accumulated on the blockchain, enabling strategy adjustments to continuously approximate the true risk distribution of each segment. Thus, it fundamentally overcomes the technical shortcomings described in the background technology, such as the bias in false and missed interceptions caused by fixed thresholds and delayed manual adjustments, and the difficulty of adapting a unified strategy to the differentiated needs of multi-dimensional risk factors.

[0007] 2. Based on historical statistical data accumulated in the on-chain feedback queue and compliance rule constraints, this invention sets pass thresholds, pending review boundaries, interception boundaries, verification item lists, and verification priorities for each risk segment. This ensures that the division of threshold ranges and the allocation of verification intensity have clear data basis and rule constraints. Furthermore, by combining the hit status of each segment in the real-time risk database and compliance matching results, the invention dynamically determines the verification items and their execution order. This avoids redundant verification caused by fixed verification lists and ensures that high-risk segments receive verification intensity commensurate with their risk level. Therefore, based on the differentiated threshold management achieved in the independent claims, this invention further improves the rationality of verification resource allocation and the accuracy of segment decision-making. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating an embodiment of the adaptive risk control method for cross-border payments based on multi-dimensional segmented thresholds provided by the present invention. Figure 2This is a functional block diagram of a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds provided in an embodiment of the present invention; Figure 3 This invention provides a radar chart of differentiated risk control thresholds and multiple compliance red lines in a high-dimensional non-Euclidean space for a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, as an embodiment of the present invention. Figure 4 An asynchronous feedback parameter tuning model and historical indicator decision scatter plot of a cross-border payment adaptive risk control system based on multidimensional segmented thresholds provided in an embodiment of the present invention; Figure 5 This is a nested annular diagram of risk control decision distribution and actual transaction status of a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, provided in an embodiment of the present invention. Figure 6 The graph shows the relationship between the depth of the feedback event queue and the synchronization delay of the blockchain consensus in a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, as provided in an embodiment of the present invention.

[0009] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0010] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0011] This application provides an adaptive risk control method for cross-border payments based on multi-dimensional segmented thresholds. The executing entity of this method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the adaptive risk control method for cross-border payments based on multi-dimensional segmented thresholds can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0012] Reference Figure 1 The diagram shown is a flowchart illustrating an adaptive risk control method for cross-border payments based on multi-dimensional segmented thresholds according to an embodiment of the present invention. In this embodiment, the adaptive risk control method for cross-border payments based on multi-dimensional segmented thresholds includes: Step 110: Record the transaction facts on the blockchain and organize and store them in a Merkle tree structure. Generate risk segmentation identifiers based on the risk status of the transaction facts records and associate the risk segmentation identifiers with the transaction facts records. In this embodiment of the application, existing cross-border payment risk control systems typically use a centralized database to store transaction logs in the data storage stage. This method faces the risk of data tampering and makes it difficult to prove one's innocence.

[0013] When transaction disputes arise, the integrity and authenticity of centrally stored transaction records may be questioned. Auditing firms may find it difficult to verify whether historical data has been modified afterward. Existing risk control processes, such as... Figure 3 As shown.

[0014] The immutability of blockchain technology provides a foundation for solving the above problems, but directly recording and storing transaction facts on the chain will face practical engineering problems such as high storage costs and low query efficiency.

[0015] This step achieves efficient tamper verification capabilities while ensuring data integrity by organizing and storing transaction fact records in a Merkle tree structure.

[0016] Step 110 further includes the following sub-steps. The generation logic for the risk segmentation identifier is as follows: Multi-dimensional risk factors are extracted from transaction fact records, each factor is mapped to a level code, and then concatenated in a predetermined order into a fixed-format identifier string, thereby achieving refined segmentation of transactions based on risk characteristic combinations. The specific implementation is as follows: Receive cross-border payment transaction requests and collect transaction fact data.

[0017] Transaction data includes merchant ID, merchant qualification level, country of transaction, issuing country, card type, transaction currency, settlement currency, order amount, transaction website identifier, IP address, address verification result, and third-party risk score.

[0018] The collected transaction data is packaged according to a preset data format to generate a transaction data package.

[0019] The transaction data packet is digitally signed using the private key of the transaction initiator, generating a transaction fact record carrying the digital signature.

[0020] In one feasible implementation, the digital signature uses the elliptic curve digital signature algorithm.

[0021] In another feasible implementation, the digital signature uses the RSA digital signature algorithm.

[0022] In addition, in one feasible implementation, digital signatures can also use my country's independently developed cryptographic algorithm SM2.

[0023] Regardless of which signature algorithm is used, the authenticity of the transaction record and the integrity of the data during transmission and storage can be ensured, preventing the transaction initiator from denying that it initiated the transaction afterward.

[0024] The transaction record carrying a digital signature is submitted to the consensus node of the blockchain network. The consensus node verifies the digital signature using the public key of the transaction initiator. Once verified, the transaction record is used as data to be stored.

[0025] The transaction fact records to be certified are used as leaf node data. The hash value of each transaction fact record is calculated to obtain the leaf node hash value.

[0026] In one feasible implementation, the hash algorithm used is the SHA-256 algorithm, which outputs a hash value of 256 bits, which is 64 characters long after hexadecimal encoding.

[0027] The SHA-256 algorithm is characterized by strong collision resistance and high computational efficiency, ensuring that the probability of different transaction records generating different hash values ​​is extremely low.

[0028] In another feasible implementation, the hash algorithm uses the SM3 cryptographic hash algorithm, which has an output length of 256 bits and is suitable for application scenarios that need to comply with the national cryptographic standard.

[0029] In addition, in a feasible implementation, the hash algorithm can also be SHA-384 or SHA-512, which is suitable for scenarios with higher security requirements.

[0030] Regardless of which hash algorithm is used, a unique leaf node hash value can be generated for each transaction fact record, providing a reliable cryptographic foundation for subsequent Merkle tree construction and tamper verification.

[0031] The hash values ​​of two adjacent leaf nodes are concatenated and hashed again to generate the hash value of the parent node. This process is repeated layer by layer upwards until a unique root node hash value is generated.

[0032] For cases where the number of leaf nodes is odd, the hash value of the last leaf node is copied, concatenated with itself, and then hashed again to ensure the integrity of the binary tree structure.

[0033] The root node hash value serves as the Merkle root hash of the current batch of transaction facts records.

[0034] The Merkle root hash is written into the block header of the blockchain, and the hash values ​​of each leaf node are associated with the corresponding transaction records and stored in the distributed ledger of the blockchain.

[0035] The hash values ​​of the nodes at each level of the Merkle tree are organized and stored according to the hierarchical relationship, forming a hash chain data structure that can be verified layer by layer.

[0036] By organizing and storing transaction records on the blockchain in a Merkle tree structure, any tampering with a single transaction record will cause a change in the hash value of its leaf node, which in turn triggers a chain reaction of changes up the chain to the root node hash value. This allows for the rapid detection of data tampering by comparing the Merkle root hash in the block header.

[0037] Extract multidimensional risk factors from transaction records.

[0038] Multidimensional risk factors include the country where the transaction occurred, the country of issue, the currency, the merchant's qualification level, the card type, the transaction amount range, the real-time risk database hit status, and the compliance rule matching status.

[0039] Each risk factor is mapped to its corresponding risk level code to obtain the level code value for each risk factor.

[0040] In one feasible implementation, the risk level code adopts a numerical code, with the value ranging from 0 to 9 integers. The larger the value, the higher the risk level corresponding to the risk factor.

[0041] In another feasible implementation, the risk level coding uses integers from 0 to 3, simplifying the segmentation granularity with a four-level division.

[0042] Alternatively, in one feasible implementation, the risk level coding can also use letter coding (A, B, C, D) and be converted into numerical values ​​through a mapping table for concatenation.

[0043] Regardless of which encoding method is used, all of them can be uniformly converted into standardized coded values, providing a basis for subsequent segmentation and identification splicing.

[0044] The risk level code is determined as follows: a risk level mapping table is pre-established for each risk factor, and this mapping table maps each possible value of the risk factor to its corresponding level code value.

[0045] The risk level code of the country where the transaction takes place is determined according to the category of the country in the country risk list published by the International Anti-Money Laundering Organization. High-risk countries correspond to code values ​​of 7 to 9, medium-risk countries correspond to code values ​​of 4 to 6, and low-risk countries correspond to code values ​​of 0 to 3.

[0046] The risk level code for the issuing country is determined based on the degree of deviation of the country's fraud transaction rate statistics from the global average; the greater the deviation, the higher the code value.

[0047] The risk level code for a currency is determined based on a combination of the stringency of its regulation in international trade and the magnitude of its exchange rate fluctuations.

[0048] The risk level code for a merchant's qualification level is directly mapped based on the merchant's qualification level assessment results.

[0049] In one feasible implementation, Level 1 qualification corresponds to code values ​​0 to 2, Level 2 qualification corresponds to code values ​​3 to 5, and Level 3 qualification corresponds to code values ​​6 to 9.

[0050] The risk level code for a card type is determined based on the historical fraud rate statistics for that card type.

[0051] In one feasible implementation, prepaid cards correspond to code values ​​7 to 9, international credit cards correspond to code values ​​4 to 6, and debit cards correspond to code values ​​0 to 3.

[0052] The risk level code for the transaction amount range is determined based on the quantile position of the order amount relative to the merchant's historical transaction amount distribution. Transactions in the higher quantile range correspond to higher code values.

[0053] The risk level code for the real-time risk database hit status is determined based on the type of risk list hit.

[0054] In one feasible implementation, hitting the blacklist corresponds to the code value 9, hitting the graylist corresponds to the code values ​​5 to 7, and not hitting any list corresponds to the code value 0.

[0055] The risk level code for compliance rule matching status is determined based on the risk weight coefficient of the matched compliance rule.

[0056] In one feasible implementation, matching a high-risk weight rule corresponds to a code value of 7 to 9, matching a medium-risk weight rule corresponds to a code value of 4 to 6, and not matching any rule corresponds to a code value of 0.

[0057] By concatenating the level codes of each risk factor in a predetermined order, the risk segment identifier corresponding to the transaction fact record is obtained.

[0058] In one feasible implementation, the concatenation order is as follows: transaction country level code value, card issuing country level code value, currency level code value, merchant qualification level code value, card type level code value, transaction amount range level code value, real-time risk database hit status level code value, and compliance rule matching status level code value, which are arranged in sequence to form a string consisting of 8 digits.

[0059] Alternatively, in another feasible implementation, the splicing order can be adjusted according to actual business needs. For example, the encoded values ​​of the real-time risk database hit status and compliance rule matching status can be arranged at the beginning to highlight the weight of risk rule factors.

[0060] In addition, in one feasible implementation, when a risk factor cannot be obtained due to missing data, a preset default code value is used to fill the gap, which corresponds to the lowest level of risk.

[0061] By concatenating the coded values ​​of each risk factor level into a risk segmentation identifier in a unified format, transaction records with the same combination of risk characteristics will obtain the same segmentation identifier, which facilitates the subsequent differentiated configuration and statistical analysis of threshold strategies based on the segmentation identifier.

[0062] The specific logic for generating risk segmentation identifiers is as follows: multiple risk factors extracted from transaction records (including transaction country, issuing country, currency, merchant qualification level, card type, transaction amount range, real-time risk database hit status, and compliance rule matching status) are each mapped to a level code value from 0 to 9. These are then concatenated into an 8-digit string in a fixed order (e.g., transaction country → issuing country → currency → merchant qualification level → card type → transaction amount range → real-time risk database hit status → compliance rule matching status). This string serves as the unique segmentation index for that transaction record. Transactions with the same combination of risk characteristics receive the same segmentation identifier, thus providing a precise grouping basis for subsequent differentiated threshold strategies.

[0063] The generated risk segmentation identifier is written into the blockchain's evidence storage account as evidence storage content, and an association index is established between the risk segmentation identifier and the transaction fact record.

[0064] By associating risk segmentation identifiers with transaction fact records and writing them into a notarization account, the risk segmentation identifiers are solidified on-chain, enabling subsequent risk control decisions and threshold optimization processes to accurately segment and aggregate data based on the trusted on-chain segmentation identifiers.

[0065] In this embodiment of the application, by recording the transaction facts on the blockchain for evidence preservation and simultaneously generating on-chain associated risk segment identifiers, the integrity and authenticity of the transaction data are guaranteed, and a reliable data foundation is provided for subsequent differentiated risk control decisions based on segment dimensions, thus realizing the atomic binding of evidence preservation and segmentation.

[0066] Step 120: Read the currently effective segmented threshold strategy version from the threshold strategy account on the blockchain, and obtain the differentiated risk control threshold and verification strategy configuration corresponding to the risk segmentation identifier; In this embodiment of the application, the strategy configuration of the existing cross-border payment risk control system is usually stored in a centralized configuration center or local database, and the strategy version is synchronized to each decision node by message broadcasting or timed retrieval mechanism.

[0067] This approach faces the risk of inconsistent policy versions in distributed deployment scenarios. Different decision nodes may read different versions of threshold configurations at the same time, resulting in different risk control results for the same transaction due to routing to different nodes.

[0068] The control over the effective time of strategies also lacks fine-grained management capabilities, and new strategies cannot be atomically effective on all nodes simultaneously after being released.

[0069] Step 120 fundamentally solves the global consistency problem of policy distribution by deploying the threshold policy in the form of a smart contract on the blockchain network and utilizing the consensus mechanism and state synchronization characteristics of the blockchain.

[0070] Build threshold strategy management smart contracts deployed on blockchain networks.

[0071] Threshold strategy management smart contract maintenance strategy version mapping table.

[0072] The policy version mapping table uses the version number as the primary key and records the start time, end time, and status identifier of each version.

[0073] The version number is an auto-incrementing integer, with an initial version number of 1, and the version number is incremented by 1 each time a new version is released.

[0074] The effective start and end times are set in Unix timestamp format, accurate to the second, ensuring precise control over when the policy takes effect.

[0075] The status identifier is an enumeration type, including four statuses: pending, effective, expired, and rolled back, enabling status tracking throughout the entire lifecycle of the policy version.

[0076] Call the query interface of the threshold strategy management smart contract, input the current timestamp, query the strategy version mapping table, and obtain the target version number whose current timestamp is between the effective start time and effective end time and whose status is effective.

[0077] In one feasible implementation, the current timestamp is determined by the block time of the blockchain network, ensuring that all consensus nodes obtain a consistent time base.

[0078] In another feasible implementation, the current timestamp can also be passed in as a query parameter by the caller, which is suitable for scenarios that require backtracking queries on historical time points.

[0079] In addition, in one feasible implementation, the query conditions can be further limited to a unique record with a status of being effective and the largest version number, in order to deal with the abnormal situation of accidentally writing multiple effective versions within the same time interval.

[0080] Regardless of which method is used, it can ensure that all risk control decision nodes query the same target version number at the same time, avoiding strategy version discrepancies.

[0081] Based on the target version number, read the policy configuration data corresponding to that version from the threshold policy account on the blockchain.

[0082] The strategy configuration data is organized and stored using risk segment identifiers as indexes, with each risk segment identifier corresponding to a set of independent strategy configuration items.

[0083] In one feasible implementation, policy configuration data is stored in key-value pairs, where the key is a risk segment identifier string and the value is a serialized policy configuration item data structure.

[0084] In another feasible implementation, the strategy configuration data is stored in the smart contract's storage variables in the form of a mapping table, and efficient querying is achieved through the mapping type of the Solidity language.

[0085] Alternatively, in one feasible implementation, the policy configuration data can also be organized and stored in the form of a Merkle tree, with the Merkle root of the complete policy configuration set written into the threshold policy account, while the specific policy configuration items are distributed and stored in an off-chain storage system. The integrity of the configuration data is verified by Merkle proof during querying.

[0086] Regardless of which storage method is used, efficient indexing and querying between strategy configuration data and risk segmentation identifiers can be achieved, ensuring low latency requirements in the real-time risk control decision-making process.

[0087] For each risk segment identifier, set the corresponding pass threshold, pending review boundary, interception boundary, verification item list and verification priority to obtain the segment's strategy configuration items.

[0088] The threshold is the lower limit of the risk score. Transactions with a risk score higher than or equal to the threshold are considered to have passed.

[0089] The interception boundary is the upper limit of the risk score. Transactions with a risk score higher than or equal to the interception boundary are considered to be intercepted.

[0090] The pending boundary is a critical value between the pass threshold and the block threshold. Transactions with risk scores between the pass threshold and the pending boundary, as well as transactions between the pending boundary and the block threshold, enter different levels of the pending process.

[0091] In one feasible implementation, the risk score is a dimensionless value after normalization, ranging from 0 to 100.

[0092] In another feasible implementation, the risk score can also be represented as a decimal between 0 and 1, which is convenient for aligning with the probabilistic interpretation.

[0093] Alternatively, in one feasible implementation, risk scoring can also employ an integer scoring system, such as integers from 0 to 1000, to provide a finer scoring granularity.

[0094] Regardless of which scoring unit is used, the relative size relationship between the pass threshold, the pending boundary, and the interception boundary remains unchanged, that is, the pass threshold is lower than the pending boundary and the pending boundary is lower than the interception boundary.

[0095] The preferred value range for the threshold is 40 to 70.

[0096] The preferred value range for the interception boundary is 75 to 95.

[0097] The preferred value range for the boundary to be examined is 55 to 80.

[0098] The determination of the above three boundary values ​​is based on statistical analysis of the distribution of historical transaction risk scores. Typically, the historical fraud rate of transactions with a risk score below 40 is less than 0.05%, while the historical fraud rate of transactions with a score above 80 is more than 2%. Therefore, setting the threshold between 40 and 70 and the interception boundary between 75 and 95 can cover the risk stratification needs of the vast majority of transactions.

[0099] The pending review boundary is set between the pass threshold and the block boundary, and the specific location is dynamically adjusted based on the manual review capacity.

[0100] The threshold is determined as follows: read the historical feedback statistics corresponding to the risk segment identifier from the feedback queue account of the blockchain, obtain the pass rate statistics of the segment in the historical transaction period, and determine the risk score percentile corresponding to the pass rate statistics as the benchmark value of the pass threshold.

[0101] The baseline value is then adjusted according to the compliance rules of the segmented matching, and the lower of the baseline value and the adjusted value is taken as the passing threshold.

[0102] The compliance rules and constraints include, but are not limited to, the minimum approval rate requirements of the regulatory authorities for the merchant type to which this segment belongs and the hard threshold for anti-money laundering compliance review.

[0103] The interception boundary is determined by reading the historical feedback statistics corresponding to the risk segment identifier from the feedback queue account of the blockchain, and obtaining the chargeback rate and missed interception rate statistics of the segment in the historical transaction cycle.

[0104] The lower of the risk score quantiles corresponding to the chargeback rate and the missed interception rate is determined as the benchmark value for the interception boundary.

[0105] The baseline value is then adjusted according to the compliance rules of the segmented matching, and the higher of the baseline value and the adjusted value is taken as the interception boundary.

[0106] The compliance rules include, but are not limited to, the maximum risk exposure limit allowed by the regulatory authorities for the transaction type to which the segment belongs, and the red line requirements for anti-fraud compliance.

[0107] The method for determining the boundary to be reviewed is as follows: based on the width of the interval between the pass threshold and the interception boundary, and according to the degree of deviation of the statistical value of the manual review volume of each segment within the historical transaction cycle from the preset upper limit of the manual review volume, the specific location of the boundary to be reviewed is determined within this interval.

[0108] The maximum number of manual reviews can be preset based on the available manpower for different time periods.

[0109] When the number of manual reviews exceeds the preset limit, the review boundary moves towards the threshold to narrow the review interval, thereby reducing the number of transactions entering the review process.

[0110] When the number of manual reviews is lower than the preset limit, the pending review boundary moves towards the interception boundary to expand the width of the pending review interval, thereby increasing the number of transactions entering the pending review process to utilize idle review capacity.

[0111] The step size of the pending review boundary is positively correlated with the degree to which the manual review volume deviates from the preset upper limit. The greater the deviation, the larger the step size, thereby achieving a dynamic balance between review capacity and pending transaction volume.

[0112] The list of verification items includes any combination of address consistency verification, 3DS verification, email validity verification, phone number verification, KYC supplementary verification, transaction limit control, and manual review.

[0113] Verification priority refers to the execution order of each item in the verification item list. Verification priority is represented by an ordinal number, with a smaller ordinal number indicating that the item is executed earlier.

[0114] The verification item list and verification priority are determined by: determining the verification items to be performed for the segment based on the hit status of the segment in the real-time risk database and the matching results of compliance rules.

[0115] Then, sort each verification item from highest to lowest according to its impact on risk assessment to generate verification priorities.

[0116] The hit status in the real-time risk database includes three statuses: hit the blacklist, hit the graylist, and not hit any list.

[0117] The matching results of compliance rules include the risk weight coefficient of the matched compliance rules. The risk weight coefficient is a pre-configured positive value with a range of 1 to 100.

[0118] In one feasible implementation, the degree of impact of the verification item on risk assessment is determined based on the historical distinguishing ability index of the verification item. The higher the historical distinguishing ability index, the earlier the execution order of the verification item is.

[0119] In another feasible implementation, the degree of impact of verification items on risk assessment can also be pre-configured with a fixed priority order based on expert experience.

[0120] In addition, one feasible approach is to combine the two methods mentioned above, using historical distinguishing ability indicators as the primary factor and expert experience as a supplement, to comprehensively determine the execution priority of each verification item.

[0121] The historical discrimination capability index is calculated by comparing the difference between the proportion of transactions identified as fraud after the verification item was performed and the proportion of transactions identified as fraud when the verification item was not performed.

[0122] The larger the difference, the stronger the ability of the verification item to distinguish fraudulent transactions, and the higher the execution priority should be given.

[0123] All policy configuration items corresponding to risk segment identifiers are summarized according to segment identifiers to form the complete policy configuration set for this version.

[0124] The complete policy configuration set is associated with the version number and appended with the current timestamp before being written into the threshold policy account on the blockchain, forming segmented threshold policy data.

[0125] After the complete policy configuration set is written to the threshold policy account, the threshold policy management smart contract updates the status identifier of that version to the pending state and sets the effective start time to the current timestamp plus the effective delay time according to the preset effective delay time.

[0126] Alternatively, in one feasible implementation, the effective date can be specified as a future point in time, with the policy administrator explicitly specifying the start and end times of the effective date during the release.

[0127] By writing segmented threshold strategy data into the threshold strategy account on the blockchain and managing the version status uniformly through the threshold strategy management smart contract, it ensures that the strategy version read by all real-time risk control decision nodes has global consistency and timeliness, avoiding strategy version discrepancies caused by network latency or cache inconsistency in the traditional centralized configuration and distribution method.

[0128] In this embodiment of the application, the strategy version management method combined with blockchain smart contracts is used to achieve on-chain atomic release and global synchronous effect of risk control thresholds, providing a reliable, consistent and traceable strategy configuration foundation for the real-time risk control decision-making process.

[0129] Step 130: Perform verification according to the verification strategy configuration, and record the verification results on the blockchain for evidence storage; In this embodiment of the application, when executing verification strategies, existing cross-border payment risk control systems typically call each verification service in a fixed order. Whether or not each verification item is executed is unrelated to the risk segmentation of the transaction. Low-risk transactions and high-risk transactions accept the same set of verification items.

[0130] This fixed verification checklist approach leads to low-risk transactions being over-verified, increasing unnecessary processing delays, while high-risk transactions may fail to effectively identify fraud risks due to insufficient verification depth.

[0131] Verification results are usually recorded in a centralized log system. When a transaction dispute occurs, it is difficult to prove the credibility and completeness of the verification process to the auditing firm.

[0132] Step 130 executes the segmented list of verification items in sequence according to verification priority and solidifies the verification results by storing them on the blockchain, thereby achieving precise adaptation of verification strength and reliable traceability of the verification process.

[0133] Verification is performed according to the verification policy configuration.

[0134] In one feasible implementation, the list of verification items and verification priorities are parsed from the verification strategy configuration obtained in step 120.

[0135] The verification item list contains at least one verification item, which is selected from one or more combinations of address consistency verification, 3DS verification, email validity verification, telephone number verification, KYC supplementary verification, transaction limit control, and manual review.

[0136] Verification priority refers to the execution order of each verification item, represented by an ordinal number. The smaller the ordinal number, the earlier the execution order.

[0137] Verification items are executed sequentially in descending order of verification priority.

[0138] If the current verification item returns a "passed" status, then proceed to the next verification item.

[0139] If the current verification item returns a verification status of failure and the verification item is marked as a blocking verification, the execution of subsequent verification items will be terminated, and the current verification status will be used as the verification result.

[0140] If the current verification item returns a failure status but the verification item is marked as a non-blocking verification, then the failure status of the item is recorded and the next verification item is executed.

[0141] Whether a verification item is blocking is determined by the blocking flag in the verification policy configuration. When the blocking flag is true, it means that the item is a blocking verification, and when it is false, it means that the item is a non-blocking verification.

[0142] In one feasible implementation, the address consistency verification is performed by comparing the address verification result in the transaction fact record with the standard address returned by the third-party address verification service. If the similarity is higher than the preset similarity threshold, it is determined to pass; otherwise, it is determined to fail.

[0143] The preferred range for the preset similarity threshold is 80% to 95%, and this range is determined based on the general acceptance standard for address matching in the industry's anti-fraud standards.

[0144] Alternatively, in a feasible implementation, address consistency verification can be combined with the two methods mentioned above. If both methods pass, the address consistency verification is considered successful; if either method fails, the verification is considered unsuccessful.

[0145] In one feasible implementation, 3DS verification is performed as follows: a 3DS verification request is sent to the card issuer, and the card issuer returns the verification result.

[0146] 3DS verification results include four states: fully passed, cardholder not registered for verification service, issuing bank system timeout, and verification failed.

[0147] In some embodiments, a 3DS verification response indicating that the cardholder has not registered for the verification service is considered a non-blocking verification failure.

[0148] In another feasible implementation, if 3DS verification returns a status indicating that the cardholder has not registered for the verification service, it is considered that the verification needs to be supplemented by other verification items before a comprehensive judgment is made.

[0149] In addition, in one feasible implementation, 3DS verification adopts the 3DS version 1.0 protocol.

[0150] In another feasible implementation, 3DS verification uses the 3DS 2.0 version protocol, which supports richer transaction context information transmission and a smoother verification experience.

[0151] Alternatively, in one feasible implementation, 3DS verification can also employ a card issuer-specific cardless verification protocol.

[0152] In one feasible implementation, the email validity verification is performed as follows: an email containing a unique verification link is sent to the email address. If the cardholder clicks the verification link within the preset validity period, the verification is considered successful; otherwise, it is considered a failure.

[0153] The preferred range for the preset validity period is five to thirty minutes. This range is determined by a trade-off between user experience and security. A validity period that is too short will cause a large number of real users to time out their verification, while a validity period that is too long will increase security risks.

[0154] In another feasible implementation, email validity verification can also be performed by querying an email domain reputation database. If the email domain is in the list of reputable domains, it is considered to have passed; if it is in the list of high-risk domains, it is considered to have failed.

[0155] In another feasible implementation, phone number verification can also be performed by verifying whether the mobile phone number's location matches the country where the transaction occurred. If they match, the transaction is considered successful; otherwise, it is considered a failure.

[0156] In addition, in one feasible implementation, phone number verification can also detect whether the mobile number belongs to a virtual number segment or a prepaid number segment, and transactions belonging to the above number segments are marked as requiring extra attention.

[0157] In one feasible implementation, the KYC supplementary verification is performed by sending a supplementary identity information collection page to the cardholder, requiring the cardholder to upload a photo of their ID card or a facial recognition photo.

[0158] The results of KYC supplementary verification include four statuses: information submitted successfully and verified, information submitted successfully but verification failed, information submission timed out, and information not submitted.

[0159] In one feasible implementation, KYC supplemental verification is performed only as a non-blocking verification item. Its verification failure does not directly lead to transaction blocking, but rather serves as an input factor for the comprehensive risk score.

[0160] In another feasible implementation, KYC supplemental verification is performed as a blocking verification item, and its failure directly leads to the interception of the transaction.

[0161] In another feasible implementation, the KYC supplementary verification method uses optical character recognition technology to extract identity information from the ID card photo and compares it with the cardholder's name and address in the transaction record.

[0162] Alternatively, in one feasible implementation, KYC supplemental verification uses facial recognition technology to compare the identity document photo with the person's identity document.

[0163] In one feasible implementation, the transaction limit control is executed as follows: obtain the single transaction limit threshold and the daily cumulative transaction limit threshold corresponding to the risk segment identifier; if the current transaction amount is lower than or equal to the single transaction limit threshold and the cardholder's daily cumulative transaction amount is lower than or equal to the daily cumulative transaction limit threshold, it is determined to pass; otherwise, it is determined to fail.

[0164] The preferred range for the single transaction limit threshold is the equivalent of one thousand US dollars to the equivalent of ten thousand US dollars.

[0165] The preferred range for the daily cumulative transaction limit threshold is between the equivalent of three thousand US dollars and the equivalent of thirty thousand US dollars.

[0166] The range of the above-mentioned limit thresholds is determined based on the reporting thresholds for cross-border payment transactions in anti-money laundering regulations and the reasonable transaction volume distribution under different merchant categories.

[0167] In one feasible implementation, the manual review is performed by assembling the transaction fact records and the results of all completed verification items into a manual review work order, which is then sent to the review queue to await processing by reviewers.

[0168] The verification status of manual review includes two states: review passed and review rejected.

[0169] The time required for manual review to be completed depends on the depth of the review queue and the processing speed of the reviewers, and typically ranges from ten minutes to twenty-four hours.

[0170] In one feasible implementation, when the list of verification items includes items requiring manual review, the execution result of that item is temporarily recorded as pending until the manual review is completed. The risk control decision-making process waits for the manual review result to be returned before continuing execution.

[0171] In another feasible implementation, when the list of verification items includes items to be manually reviewed, the risk control decision process can first output a provisional decision result pending review, and then update the final decision result through an asynchronous callback after the manual review is completed.

[0172] After all verification items have been completed, verification result data will be generated.

[0173] In one feasible implementation, the verification result data includes the name of each verification item, the execution status of each verification item, the execution timestamp of each verification item, the total number of verification items, the number of passed items, and the number of failed items.

[0174] The verification results will be recorded on the blockchain for evidence storage.

[0175] The verification result data is packaged according to the preset evidence storage format to generate a verification result evidence storage data package.

[0176] In one feasible implementation, the verification result evidence data packet is digitally signed by the private key of the risk control decision node to generate a verification result evidence record carrying the digital signature.

[0177] The verification result record carrying the digital signature is submitted to the consensus node of the blockchain network. The consensus node verifies the digital signature using the public key of the risk control decision node. After successful verification, the verification result record is written into the distributed ledger of the blockchain.

[0178] In one feasible implementation, the verification result storage record and the transaction fact record stored in step 110 are associated through the transaction serial number, so that the transaction fact record and the verification result record of the same transaction can establish a complete association on the chain.

[0179] In another feasible implementation, the verification result record can be written onto the chain as a separate blockchain transaction and stored using the same Merkle tree structure as the transaction fact record.

[0180] In another feasible implementation, the verification result record can also be associated with the leaf node hash value of the transaction in step 110, and the verification result can be stored as an extended attribute of the transaction fact record in the same leaf node.

[0181] Alternatively, in one feasible implementation, the verification result records can be packaged in batches and stored on the blockchain in a unified manner to reduce the overall overhead of on-chain storage.

[0182] The granularity of batch packaging is dynamically adjusted based on system throughput and the block interval of the blockchain network.

[0183] By recording the verification results on the blockchain for evidence storage, the verification process is made credible and solidified. Once the verification results are written into the blockchain, they cannot be tampered with, providing an irrefutable evidentiary basis for subsequent audit reviews and dispute arbitration.

[0184] In this embodiment, by executing the segmented exclusive verification item list sequentially according to the verification priority and storing the verification results on the blockchain, the verification intensity and risk segment are precisely matched, avoiding the inefficient and redundant verification caused by a fixed verification list. This ensures the integrity and credibility of the verification process and provides a traceable verification basis for risk control decision results. Step 140: Output the risk control decision result according to the risk segment identifier, differentiated risk control threshold and verification result. At the same time, write the risk control decision result and the subsequent status of the transaction into the feedback queue of the blockchain to trigger the asynchronous threshold optimization process. In this embodiment, after completing the risk control decision for a single transaction, the existing cross-border payment risk control system usually only records the decision result in the local log. There is a lack of structured association storage between the decision result and the transaction facts.

[0185] Subsequent optimization of risk control strategies relies on manual, periodic data export from decentralized log systems, cleaning and summarizing, followed by statistical analysis. This process involves long feedback loops and difficulty in guaranteeing data quality.

[0186] Actual performance metrics for each risk segment, such as pass rate, chargeback rate, false interception rate, and missed interception rate, cannot be automatically fed back to the strategy optimization module after the transaction is completed, causing threshold adjustments to lag behind changes in business risk.

[0187] Step 140 combines the decision results with the subsequent transaction status into structured feedback event data and writes it into the feedback queue of the blockchain. Then, it triggers an asynchronous optimization process with on-chain events, thus constructing a complete closed loop from decision execution to strategy evolution.

[0188] Risk control decision results are output based on risk segmentation identification, differentiated risk control thresholds, and verification results.

[0189] In some embodiments, the risk segmentation identifier is obtained from step 110, the pass threshold and the interception boundary in the differentiated risk control threshold are obtained from step 120, and the verification result is obtained from step 130.

[0190] The execution status of all blocking verification items in the verification results will be comprehensively determined.

[0191] If any blocking verification item returns a failure status, the blocking decision result is output directly.

[0192] If all blocking verification items return a pass status, the overall risk score is calculated based on the number of failures and the failure weights of the non-blocking verification items.

[0193] In other embodiments, the overall risk score may also be determined by a combination of a third-party risk score and a failure weighted value of the verification project.

[0194] The overall risk score is compared with the pass threshold and interception boundary obtained in step 120.

[0195] If the overall risk score is lower than the passing threshold, the passing decision result will be output.

[0196] If the overall risk score is higher than or equal to the interception boundary, the interception decision result is output.

[0197] If the overall risk score is higher than or equal to the pass threshold but lower than the interception boundary, the pending decision result will be output.

[0198] In some embodiments, the decision to be reviewed can be further subdivided into two levels: priority review and regular review. Priority review corresponds to the range where the comprehensive risk score is close to the interception boundary, while regular review corresponds to the range where the comprehensive risk score is close to the pass threshold.

[0199] In other embodiments, the decision result may also include an enhanced verification decision result, which outputs an enhanced verification decision result to require the cardholder to provide additional identity verification information when the overall risk score is in the pending range but matches a gray list in the real-time risk database.

[0200] The risk control decision results and subsequent transaction status are written into the feedback queue of the blockchain.

[0201] The risk control decision results and subsequent transaction status data are combined into feedback event data.

[0202] In some embodiments, the risk control decision results include decision type, decision timestamp, hit threshold version number, risk segmentation identifier, and summary of decision basis.

[0203] The post-transaction status data includes the final transaction result, manual review result, chargeback flag, refund flag, fraud confirmation flag, policy change events, and risk database change events.

[0204] The final result of a transaction is its final settlement status in the payment and clearing system, which includes two statuses: successful and failed. This status is usually determined within minutes to days after the risk control decision is made.

[0205] The manual review result is the review conclusion of the transaction corresponding to the pending decision result after manual review, including two statuses: review passed and review rejected.

[0206] A chargeback flag is a flag issued by the cardholder or issuing bank after a transaction has been completed, and includes two states: chargeback and non-chargeback.

[0207] The refund flag is a marker indicating that the merchant has initiated a refund after the transaction is completed, and includes two statuses: refunded and not refunded.

[0208] A fraud confirmation flag is a marker indicating that a transaction has been subsequently confirmed as fraudulent, and includes two states: confirmed fraud and unconfirmed fraud.

[0209] Policy change events refer to events in which regulatory agencies issue new cross-border payment policies or adjust existing policies, including the policy type, effective date, and a summary of the policy content.

[0210] Risk database change events are events involving the addition, deletion, and update of risk lists in the real-time risk database, including list type, update operation type, and update content summary.

[0211] Call the write interface of the feedback queue smart contract deployed on the blockchain network to submit the feedback event data to the feedback event queue maintained by the feedback queue smart contract.

[0212] In some embodiments, the feedback event queue maintained by the feedback queue smart contract is a first-in-first-out queue data structure.

[0213] In other embodiments, the feedback event queue can also be organized into multiple parallel sub-queues according to the risk segment identifier, and the feedback events of different segments are written into the corresponding sub-queues to improve the processing efficiency of subsequent segmented reading.

[0214] In addition, in some embodiments, the feedback event queue can also be organized by time window, packaging feedback events within the same time window into a batch for storage.

[0215] The feedback queue smart contract associates and stores feedback event data with transaction fact records and risk segmentation identifiers, and arranges them in timestamp order to generate a traceable sequence of feedback events.

[0216] In some embodiments, feedback event data is associated with transaction fact records via transaction serial numbers.

[0217] In other embodiments, feedback event data can also be directly stored in the extended field of the Merkle tree where the transaction fact record is located, thereby achieving a unified tree-like organization of the fact record and feedback event of the same transaction.

[0218] By storing feedback event data in the form of an on-chain queue, the immutability and traceability of feedback samples are ensured, providing a reliable data source for subsequent asynchronous threshold optimization processes.

[0219] Trigger asynchronous threshold optimization process.

[0220] After the feedback event data is written to the feedback queue, the feedback queue smart contract issues an optimization trigger event.

[0221] In some embodiments, the optimization triggering event is implemented using the event log mechanism of the blockchain smart contract, and the event log contains index identifiers of the feedback event data that has been written.

[0222] In other embodiments, the optimization trigger event can also be broadcast to each asynchronous optimization service instance that has subscribed to the event via a message queue middleware of the blockchain network.

[0223] Optimize the index identifier for triggering events to carry the already written feedback event data.

[0224] After the asynchronous optimization service listens for and captures optimization trigger events, it reads the corresponding feedback event data from the blockchain based on the index identifier.

[0225] In some embodiments, the asynchronous optimization service is a background service process that runs independently of the real-time risk control decision-making process.

[0226] In other embodiments, the asynchronous optimization service can also be deployed as multiple parallel instances, which pull feedback events from the feedback queue for processing through a competitive consumption mechanism.

[0227] Alternatively, in some embodiments, the asynchronous optimization service can also be started on demand as a serverless function, creating an execution instance only when there are pending feedback events in the feedback queue.

[0228] The received feedback event data is categorized and summarized according to risk segment identifiers to generate the input dataset to be optimized for each segment.

[0229] Read all feedback event data belonging to the same risk segment identifier from the input dataset to be optimized, and summarize them according to the preset statistical period.

[0230] In some embodiments, the preset statistical period is 24 hours, that is, the feedback statistical indicators of each segment are summarized according to natural days.

[0231] In other embodiments, the preset statistical period can also be a seven-day sliding window to smooth out statistical deviations caused by daily data fluctuations.

[0232] Alternatively, in some embodiments, the preset statistical period can be dynamically adjusted according to the transaction volume of the segment. The segment with a large transaction volume adopts a shorter statistical period to speed up the response, while the segment with a small transaction volume adopts a longer statistical period to accumulate a sufficient statistical sample size.

[0233] Calculate the pass rate, rejection rate, false interception rate, missed interception rate, and manual review volume for each segment.

[0234] The formula for calculating the pass rate is: Pass rate = Number of transactions that pass the decision and ultimately succeed ÷ Total number of transactions that pass the decision × 100%.

[0235] The number of transactions that were approved and ultimately successful reflects the number of transactions that the risk control system correctly approved, while the total number of transactions that were approved reflects the total number of transactions that the risk control system determined to be approved.

[0236] The preferred range for the pass rate is 75% to 95%. This range is based on the benchmark pass rate in leading practices in the cross-border payment industry. A pass rate below 75% indicates that the risk control strategy is too strict and may affect the normal transaction experience, while a pass rate above 95% indicates that the risk control strategy may be too lenient and allow high-risk transactions to pass.

[0237] The formula for calculating the chargeback rate is: Chargeback rate = Number of transactions marked as chargeback after completion ÷ Total number of transactions × 100%.

[0238] The number of transactions marked as chargebacks after completion reflects the number of chargebacks initiated by the cardholder or issuing bank after the transaction was completed, while the total number of transactions reflects the total number of transactions within this segment that have completed risk control decisions.

[0239] The preferred range for the chargeback rate is below 0.5 percent. This range is based on the international card organizations' assessment standards for chargeback rates in cross-border payment transactions. Exceeding this standard may result in the merchant being placed on a high-risk monitoring list by the card organization.

[0240] The formula for calculating the false interception rate is: False interception rate = Number of transactions that were initially blocked or pending review but were ultimately approved as normal transactions ÷ Total number of transactions that were initially blocked or pending review × 100%.

[0241] The number of transactions that were blocked or pending review and were ultimately reviewed as normal transactions reflects the number of normal transactions that were mistakenly blocked by the risk control system, while the total number of transactions that were blocked or pending review reflects the total number of transactions that the risk control system determined required intervention.

[0242] The preferred range for the false blocking rate is below 5%. This range is based on survey data on merchants' tolerance for false blocking by the risk control system. Exceeding this threshold will significantly damage the user experience and transaction conversion rate of merchants.

[0243] The formula for calculating the missed interception rate is: Missed interception rate = Number of transactions that pass the decision and whose final status is confirmed as fraudulent ÷ Total number of confirmed fraudulent transactions × 100%.

[0244] The number of transactions that were approved and whose final status was confirmed as fraud reflects the number of fraudulent transactions that were mistakenly approved by the risk control system, while the total number of confirmed fraudulent transactions reflects the total number of all transactions within that segment that have been confirmed as fraudulent.

[0245] The preferred value for the missed interception rate is less than one percent. This value range is based on the basic requirements of the cross-border payment risk control system for the ability to identify fraudulent transactions. Exceeding this threshold means that the risk control system has failed to effectively identify fraud risks when a transaction occurs.

[0246] The formula for calculating the amount of manual review is: Manual review volume = number of transactions that are pending review as a decision result.

[0247] The manual review volume reflects the number of transactions requiring manual review within this segment, and this indicator directly affects the labor costs and review efficiency of the risk control operations team.

[0248] Obtain the update events of the current real-time risk database and the change events of the compliance rule database, and extract the latest risk level and compliance constraint status of the corresponding risk factors for each segment.

[0249] In some embodiments, update events of the real-time risk database and change events of the compliance rule database are also recorded through an event log mechanism on the blockchain, and the asynchronous optimization service obtains the change content by listening to the corresponding events.

[0250] In other embodiments, the real-time risk database and compliance rule database are stored in separate accounts on the blockchain, and the asynchronous optimization service obtains updated content by reading the latest state on the chain.

[0251] Adjust the approval threshold, pending review boundary, and blocking boundary for each segment based on the approval rate, chargeback rate, false blocking rate, missed blocking rate, manual review volume, latest risk level, and compliance constraint status.

[0252] In some embodiments, when the false interception rate is higher than a preset upper limit, the threshold will be shifted towards a lower risk direction to reduce the proportion of transactions entering the pending and interception range, thereby reducing the number of falsely intercepted transactions.

[0253] When the missed interception rate exceeds the preset upper limit, the interception boundary will be moved towards the lower risk direction to expand the interception range and thus capture more fraudulent transactions.

[0254] When the volume of manual reviews exceeds the preset review capacity limit, the pending review boundary is moved towards the pass threshold to narrow the width of the pending review range and reduce the number of transactions entering the manual review process.

[0255] When the amount of manual review is lower than the preset review capacity limit, the pending review boundary is moved towards the interception boundary to expand the width of the pending review range and make full use of the idle review capacity.

[0256] The adjustment step size is positively correlated with the degree to which the corresponding indicator deviates from the preset target value; the greater the deviation, the larger the adjustment step size.

[0257] Simultaneously update the list of verification items and verification priorities, and generate segmented candidate strategy configuration items.

[0258] The updated list of verification items and verification priorities are combined with the adjusted pass threshold, pending review boundary, and blocking boundary to form the candidate strategy configuration items for this segment.

[0259] All candidate strategy configuration items corresponding to all risk segmentation identifiers are summarized to form candidate segmentation threshold strategy versions.

[0260] The candidate segmentation threshold strategy version is associated with the generation timestamp and then written into the candidate strategy account on the blockchain.

[0261] In some embodiments, the candidate policy account and the threshold policy account are stored in separate spaces, and the candidate policy version does not enter the real-time risk control decision-making process before passing offline sandbox backtesting and grayscale verification.

[0262] In other embodiments, the candidate policy versions stored in the candidate policy account may include multiple candidate sub-versions, each sub-version corresponding to a different adjustment direction and adjustment magnitude, so that the performance differences of each candidate sub-version can be compared in parallel during offline sandbox backtesting.

[0263] In this embodiment of the application, by writing the risk control decision results and subsequent transaction status into the blockchain feedback queue and triggering asynchronous threshold optimization through on-chain events, a complete data closed loop from decision execution to strategy evolution is constructed. This makes the adjustment of segmented thresholds no longer dependent on manual periodic export and analysis of data, but automatically triggers the optimization process when the subsequent transaction status is determined, thus realizing the adaptive evolution capability of the risk control strategy.

[0264] like Figure 2 The diagram shown is a functional block diagram of a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds provided in an embodiment of the present invention.

[0265] The cross-border payment adaptive risk control system 100 based on multi-dimensional segmented thresholds described in this invention can be installed in an electronic device. Depending on the functions implemented, the cross-border payment adaptive risk control system 100 may include a transaction storage module 101, a threshold matching module 102, a verification on-chain module 103, and a decision iteration module 104. The module described in this invention can also be referred to as a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and are stored in the memory of the electronic device.

[0266] In this embodiment, the functions of each module / unit are as follows: The transaction record storage module 101 is used to record transaction facts on the blockchain and organize and store them in a Merkle tree structure, and generate risk segmentation identifiers according to the risk status of the transaction fact records, and associate the risk segmentation identifiers with the transaction fact records; The threshold matching module 102 is used to read the currently effective segmented threshold strategy version from the threshold strategy account of the blockchain, and obtain the differentiated risk control threshold and verification strategy configuration corresponding to the risk segmentation identifier. The on-chain verification module 103 is used to perform verification according to the verification strategy configuration and record the verification results on the blockchain for evidence storage. The decision iteration module 104 is used to output risk control decision results based on risk segmentation identifiers, differentiated risk control thresholds, and verification results. At the same time, it writes the risk control decision results and subsequent transaction status into the feedback queue of the blockchain to trigger the asynchronous threshold optimization process.

[0267] like Figure 3 The image shows a radar chart of differentiated risk control thresholds and multiple compliance red lines in a high-dimensional non-Euclidean space for a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, provided in an embodiment of the present invention.

[0268] In the process of differentiated threshold matching, the security decision boundaries established for different risk segment identifiers exhibit a highly nonlinear geometric shape in the five-dimensional polar coordinate feature space. For each risk segment identifier, the system extracts five core indicators, including the pass threshold, lower bound for review, upper bound for review, interception threshold, and compliance grace limit. A radar chart compares the differences in the strategy boundary contours between the "low-risk segment (Tier 1)" and the "high-risk segment (Tier 4)". In low-risk scenarios, thanks to the extremely high merchant qualification level and the absence of high-risk card-issuing countries, the pass threshold is set at a lower percentile (e.g., 40 points), while the interception threshold is relaxed to a higher position (80 points), creating a wide, unobstructed passage space for transactions. Conversely, in the high-risk segment, to prevent imported money laundering and credit card cash-out, the pass threshold is significantly increased (to above 65 points), the review range is compressed, and the compliance grace limit is drastically reduced (tightened to 55 points), forcing the vast majority of abnormal transactions in this segment to directly hit the interception boundary. By using this differentiated stretching and trimming of the five-dimensional boundary, this system abandons the "one-size-fits-all" fixed risk control rules in the background technology, and achieves a geometric fit between the depth of risk control and the risk exposure of the segmented scenario.

[0269] like Figure 4 The figure shows the asynchronous feedback parameter tuning model and historical indicator decision scatter plot of the cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds provided in an embodiment of the present invention.

[0270] The scatter plot details the spatial coordinate distribution of the accumulated false rejection rate (FPR, horizontal axis) and chargeback rate (Chargeback Rate, vertical axis) for each risk segment over the historical period. The size of the bubble is proportional to the total cross-border transaction volume handled by that segment. The external gradient axis on the right visually displays the dynamic numerical distribution of the adaptive optimization sensitivity index. In this parameter tuning model, the algorithm defines two strongly constrained regions in two-dimensional space: the green "safety red line control zone" requires that the chargeback rate of all segments be strictly limited to below 0.5% to meet the risk control standards of international card organizations; the light blue "user conversion optimal control zone" controls the false rejection rate of normal transactions to within 3% to reduce the customer friction costs for merchants. The scatter points exhibit a heterogeneous distribution due to different SegmentIDs. When a segment of scattered points deviates from the two ideal control zones due to a deterioration in the trading environment or tightening of compliance regulations, its sensitivity index will increase sharply, automatically activating the smart contract to issue an optimization trigger event, and accurately locking the input sample of the threshold boundary to be optimized from the data chain.

[0271] like Figure 5The diagram shown is a nested annular graph of risk control decision distribution and actual transaction status for a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, provided by an embodiment of the present invention.

[0272] In practical operation, the outer annular area represents the proportions of three categories—Pass, Review, and Block—determined in real time by the system. The inner annular area represents the actual settlement statuses such as "secure," "fraudulent chargeback," and "manual veto," which are stored in the payment clearing system and card organization dispute database. Consistency quantification of the two-layer classification space is achieved by calculating the Cohen's Kappa coefficient of the confusion matrix and the combined F1-Score: a closed-loop lifecycle tracking is performed on each on-chain evidence-based decision event, recording the mapping deviation between the outer-layer decision and the inner-layer final state, quantifying the system's false positive rate (False Positive Rate) and false negative rate (False Negative Rate). During parameter configuration, the historical fraud chargeback target baseline (FNR Baseline) is set below 0.2%, the user disturbance rate (FPR Limit) is controlled within 5.0%, and the time window range for inner-ring state updates is set to 90 calendar days to ensure that the audit model can comprehensively reflect the system's judgment accuracy in complex cross-border geopolitical payment environments.

[0273] like Figure 6 The figure shown is a graph illustrating the relationship between the depth of the feedback event queue and the synchronization latency of the blockchain consensus in a cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, provided in an embodiment of the present invention.

[0274] In practice, the streaming media gateway packages the received transaction settlement results and audit conclusions into structured feedback event data, and then calls the write interface of the FeedbackQueueContract smart contract. When the event buffer pool reaches a critical section, it performs non-blocking concurrency control, and the consensus nodes package and store the data into blocks in batches. The sensitivity measurement of the interaction between queue depth and consensus latency is achieved by calculating the cross-correlation coefficient between the queue dynamic slope and the broadcast latency between nodes: a high-pass filter is applied to the sampled sequence on the time axis, and the evolution curve of the blockchain block production latency from 10 milliseconds to 80 milliseconds is recorded when the queue depth varies from 50 to 500 entries. During parameter configuration, the upper limit of the feedback queue self-locking protection depth is set to 500 entries, the feedback correction gain (GainCoefficient) for consensus latency is set to 0.25, and the queue probe polling detection cycle is set to 5 seconds to avoid sudden network congestion and data loss during the consensus phase.

[0275] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0276] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0277] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0278] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0279] This application embodiment can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0280] To verify the practical effectiveness of this invention, a blockchain simulation environment (4 consensus nodes, using the Raft consensus protocol) was built using a de-identified historical transaction dataset from a cross-border payment platform (containing 1.2 million real transactions, covering more than 40 countries, 6 mainstream currencies, and 5 merchant qualification levels). The method described in this invention was compared with the traditional "unified threshold + fixed verification list" scheme described in the background section. The experiment lasted for 30 consecutive calendar days, and the evaluation indicators are as follows: The experiment also observed the independent performance of different risk segments. Taking the high-risk segment (Tier 4, including high-risk countries, prepaid cards, and blacklist hits) as an example, the traditional solution had a false interception rate as high as 12.3% due to the low uniform threshold (pass threshold of 50 points). However, the present invention adaptively adjusted the pass threshold to 68 points and the interception boundary to 90 points based on historical data of this segment, reducing the false interception rate to 3.6% and the missed interception rate from 2.5% to 1.1%, verifying the effectiveness of differentiated segment thresholds in extreme risk scenarios.

[0281] Furthermore, the convergence speed of the asynchronous threshold optimization process was recorded during the simulation. After the initial optimization, the system went through three iterations (each with an interval of approximately 2 hours, accumulating over 2000 feedback events), and the core indicators such as the pass rate and rejection rate of each segment reached a steady state, with the fluctuation range reduced to within ±2% of the target value. This indicates that the feedback-driven parameter tuning mechanism of this invention has fast convergence and stability.

[0282] The simulation data above fully demonstrates that the present invention has significant quantitative advantages over existing technologies in reducing false and missed interceptions, improving transaction pass rates, reducing manual review costs, and accelerating strategy response speed. Furthermore, all decision and feedback data are stored on the blockchain, ensuring the credibility and traceability of the entire risk control process.

[0283] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds, characterized in that, The method includes: Step 110: Record the transaction facts on the blockchain and organize and store them in a Merkle tree structure. Generate risk segmentation identifiers based on the risk status of the transaction facts records and associate the risk segmentation identifiers with the transaction facts records. Step 120: Read the currently effective segmented threshold strategy version from the threshold strategy account on the blockchain, and obtain the differentiated risk control threshold and verification strategy configuration corresponding to the risk segmentation identifier; Step 130: Perform verification according to the verification strategy configuration, and record the verification results on the blockchain for evidence storage; Step 140: Output the risk control decision result based on the risk segmentation identifier, differentiated risk control threshold, and verification result. At the same time, write the risk control decision result and the subsequent status of the transaction into the feedback queue of the blockchain to trigger the asynchronous threshold optimization process.

2. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 1, characterized in that, Transaction fact records, including: Receive cross-border payment transaction requests and collect transaction fact data, which includes merchant ID, merchant qualification level, country of transaction, card issuing country, card type, transaction currency, settlement currency, order amount, transaction website identifier, IP address, address verification result, and third-party risk score; The collected transaction fact data is packaged according to a preset data format to generate a transaction data package; The transaction data packet is digitally signed using the private key of the transaction initiator, generating a transaction fact record carrying the digital signature; The transaction record carrying a digital signature is submitted to the consensus node of the blockchain network. The consensus node verifies the digital signature using the public key of the transaction initiator. Once verified, the transaction record is used as data to be stored.

3. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 2, characterized in that, The transaction facts are recorded on the blockchain and stored in a Merkle tree structure, including: The transaction fact records to be notified are used as leaf node data. The hash value of each transaction fact record is calculated to obtain the leaf node hash value. The hash values ​​of two adjacent leaf nodes are concatenated and hashed again to generate the hash value of the parent node. This process is repeated upwards layer by layer until a unique root node hash value is generated. The root node hash value serves as the Merkle root hash of the current batch of transaction fact records. The Merkle root hash is written into the block header of the blockchain, and the hash value of each leaf node is associated with the corresponding transaction record and stored in the distributed ledger of the blockchain; The hash values ​​of the nodes at each level of the Merkle tree are organized and stored according to the hierarchical relationship, forming a hash chain data structure that can be verified layer by layer.

4. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 3, characterized in that, Based on the risk status recorded in the transaction facts, a risk segmentation identifier is generated and associated with the transaction facts record, including: Multidimensional risk factors are extracted from transaction records. These factors include the country where the transaction occurred, the country of card issuance, the currency, the merchant's qualification level, the card type, the transaction amount range, the real-time risk database hit status, and the compliance rule matching status. Each risk factor is mapped to its corresponding risk level code to obtain the level code value for each risk factor; By concatenating the level codes of each risk factor in a predetermined order, the risk segmentation identifier corresponding to the transaction fact record is obtained. The generated risk segmentation identifier is written into the blockchain's evidence storage account as evidence storage content, and an association index is established between the risk segmentation identifier and the transaction fact record.

5. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 1, characterized in that, Read the currently active segmented threshold policy version from the threshold policy account on the blockchain, including: Construct a threshold strategy management smart contract deployed on the blockchain network. The threshold strategy management smart contract maintains a strategy version mapping table, in which the version number is used as the primary key and records the effective start time, effective end time and status identifier of each version. Call the query interface of the threshold strategy management smart contract, input the current timestamp, query the strategy version mapping table, and obtain the target version number whose current timestamp is between the effective start time and effective end time and whose status is effective; Based on the target version number, the policy configuration data corresponding to the version is read from the threshold policy account on the blockchain. The policy configuration data is organized and stored with risk segment identifier as the index.

6. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 5, characterized in that, Obtain the differentiated risk control thresholds and verification strategy configurations corresponding to the risk segmentation identifiers, including: For each risk segment identifier, set the corresponding pass threshold, pending review boundary, interception boundary, verification item list and verification priority to obtain the segment's strategy configuration items; Summarize all the policy configuration items corresponding to the risk segment identifiers according to the segment identifiers to form a complete policy configuration set for the version. The complete policy configuration set is associated with the version number and a timestamp is appended before being written into the threshold policy account on the blockchain to form segmented threshold policy data.

7. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 6, characterized in that, For each risk segment identifier, corresponding pass thresholds, pending review boundaries, interception boundaries, verification item lists, and verification priorities are set to obtain the segment's strategy configuration items, including: Read the historical feedback statistics corresponding to the risk segment identifier from the feedback queue account of the blockchain. The historical feedback statistics include the pass rate, chargeback rate, false interception rate and missed interception rate of the segment in the historical transaction cycle. Based on historical feedback statistics and compliance rules for segmented matching, the pass threshold and block boundary for each segment are set, and the boundary to be reviewed is determined based on the interval between the pass threshold and the block boundary. Based on the hit status of the segment in the real-time risk database and the matching results of compliance rules, the verification items to be performed for the segment are determined, and the verification priorities are generated by sorting each verification item according to its impact on risk assessment. The segmented strategy configuration items will be obtained by combining thresholds, pending boundaries, interception boundaries, verification item lists, and verification priorities.

8. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 1, characterized in that, The risk control decision results and subsequent transaction status are written to the blockchain's feedback queue, including: The risk control decision results and subsequent transaction status data are combined into feedback event data. The subsequent transaction status data includes the final transaction result, manual review result, chargeback flag, refund flag, fraud confirmation flag, policy change event, and risk database change event. Call the write interface of the feedback queue smart contract deployed on the blockchain network to submit the feedback event data to the feedback event queue maintained by the feedback queue smart contract; The feedback queue smart contract associates and stores feedback event data with transaction fact records and risk segmentation identifiers, and arranges them in timestamp order to generate a traceable sequence of feedback events.

9. The cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 8, characterized in that, Triggering the asynchronous threshold optimization process includes: After the feedback event data is written to the feedback queue, the feedback queue smart contract issues an optimization trigger event, which carries the index identifier of the written feedback event data. After the asynchronous optimization service listens for and captures optimization trigger events, it reads the corresponding feedback event data from the blockchain based on the index identifier. The read feedback event data is categorized and summarized according to the risk segment identifier to generate the input dataset to be optimized for each segment; Read all feedback event data belonging to the same risk segment identifier from the input dataset to be optimized, summarize them according to the preset statistical period, and calculate the segment's pass rate, rejection rate, false interception rate, missed interception rate, and manual review volume; Get the update events of the current real-time risk database and the change events of the compliance rule database, and extract the latest risk level and compliance constraint status of the corresponding risk factors for each segment; Based on the pass rate, rejection rate, false interception rate, missed interception rate, manual review volume, latest risk level and compliance constraint status, adjust the pass threshold, pending review boundary and interception boundary of each segment, and update the verification item list and verification priority to generate candidate strategy configuration items for each segment. All candidate strategy configuration items corresponding to all risk segment identifiers are aggregated to form candidate segment threshold strategy versions, and then the candidate segment threshold strategy versions are associated with the generation timestamp and written into the candidate strategy account on the blockchain.

10. A cross-border payment adaptive risk control system based on multi-dimensional segmented thresholds, characterized in that, The system for implementing the cross-border payment adaptive risk control method based on multi-dimensional segmented thresholds as described in claim 1 includes: The transaction record module is used to record transaction facts on the blockchain and organize and store them in a Merkle tree structure. Based on the risk status of the transaction fact records, it generates risk segmentation identifiers and associates the risk segmentation identifiers with the transaction fact records. The threshold matching module is used to read the currently effective segmented threshold strategy version from the threshold strategy account on the blockchain, and obtain the differentiated risk control threshold and verification strategy configuration corresponding to the risk segmentation identifier. The on-chain verification module is used to perform verification according to the verification strategy configuration and record the verification results on the blockchain for evidence storage. The decision iteration module is used to output risk control decision results based on risk segmentation identifiers, differentiated risk control thresholds, and verification results. At the same time, it writes the risk control decision results and subsequent transaction status into the feedback queue of the blockchain, triggering the asynchronous threshold optimization process.

Images