A blockchain-enabled cross-border financial payment transaction intelligent risk control system

Abstract

The application is a blockchain-enabled cross-border financial payment transaction intelligent risk control system, relating to the field of blockchain technology, comprising: a history deviation-based drift compensation and clock anomaly detection module reading history deviation trajectory, fitting deviation change trend and calculating dynamic compensation amount, completing node local time calibration and clock anomaly hierarchical disposal, and outputting calibrated standard time and node clock health profile. In the application, a trusted time anchor and dynamic drift compensation mechanism are constructed, the operation mode of traditional static time synchronization is optimized, the node clock deviation rule can be continuously tracked and dynamic calibration is completed, the time judgment deviation problem caused by long-term clock drift is alleviated, and the consistency and reliability of the whole system time reference are improved; relying on the node individualized performance baseline and hierarchical degradation detection mechanism, the traditional unified threshold monitoring mode is replaced, which can adapt to the performance differences of nodes in different regions, hardware and network environments, and reduce the possibility of false positives and false negatives.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain-enabled intelligent risk control system for cross-border financial payment transactions. Background Technology

[0002] In blockchain-based cross-border payment systems, the time consistency of distributed nodes is fundamental to ensuring transaction sequence verification and the effectiveness of time zone risk control rules. Existing blockchain systems' timestamp verification mechanisms primarily rely on periodic synchronization verification between nodes and a standard time source. Under stable node operating environments, this can meet basic time consistency verification requirements. However, due to the highly heterogeneous deployment environments of cross-border payment nodes, and influenced by multiple factors such as hardware crystal oscillator characteristics, network synchronization latency, and changes in virtualization environment status, node local clocks often exhibit continuous drift. Over long-term operation, this accumulates deviations, potentially impacting time-sensitive business logic such as determining time zone activity windows and calculating transaction processing time.

[0003] For monitoring the operational performance of distributed nodes, existing solutions mostly employ a unified performance threshold alarm mechanism across the entire network. Some optimized solutions also dynamically adjust the judgment criteria through adaptive algorithms, covering most common node failure monitoring scenarios. However, due to factors such as different regional hardware configurations, cross-border network link quality, and differences in traffic volume across time zones, the normal performance baselines of different nodes often vary significantly. A unified threshold has certain limitations in adaptability when dealing with heterogeneous nodes across the entire network. Furthermore, conventional threshold alarms are mostly triggered when performance indicators exceed critical values. For gradual performance degradation processes, there is room for improvement in the lead time of warnings. Some machine learning-based adaptive monitoring solutions also have corresponding adaptation costs in scenarios with high regulatory interpretability requirements and during the cold start phase of new node deployment.

[0004] In actual global operation, the operational status of nodes in a blockchain-based cross-border payment network is affected by various external events. Events such as national holidays, financial institution system maintenance, and regional network fluctuations can all trigger overall changes in the response performance of nodes in the corresponding regions. Existing node monitoring systems primarily focus on detecting and alerting on the nodes' own operational metrics, with relatively little analysis of the correlation between external environmental disturbances and node performance fluctuations. During periods of external events such as holidays and concentrated maintenance, the number of system alarms typically increases significantly, increasing the cost for operations and maintenance personnel to identify genuine faults and placing higher demands on the system's consensus scheduling and adaptive adjustment capabilities under disturbance scenarios. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain-enabled intelligent risk control system for cross-border financial payment transactions in order to solve the above-mentioned problems.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A blockchain-enabled intelligent risk control system for cross-border financial payment transactions includes: The trusted time source anchoring and clock deviation trajectory recording module is deployed in isolation from the consensus process through multi-source trusted time source nodes. It collects the clock deviation values ​​of each consensus node according to the block generation cycle and stores them on the chain, generating continuous historical trajectories of node clock deviations, providing a trusted data source for subsequent drift compensation calculations. The drift compensation and clock anomaly detection module based on historical deviation reads the historical deviation trajectory, fits the deviation change trend and calculates the dynamic compensation amount, completes the node local time calibration and clock anomaly classification and handling, and outputs the calibrated standard time and node clock health record. The node-level personalized response time baseline establishment module establishes a unique response time baseline for each node based on calibration time and stable operation judgment, according to the active window of the time zone, and realizes dynamic iteration. The three-layer progressive degradation detection and network-wide systemic early warning module performs three-layer progressive degradation detection based on a personalized baseline, generating node degradation status and network-wide systemic risk data; The global disturbance event knowledge base and the expected / abnormal disturbance attribution module combine calibration time and degradation data to perform disturbance attribution, and implement targeted adaptive regulation and emergency response, and reverse correct performance early warning strategies.

[0007] Preferably, in the trusted time source anchoring and clock deviation trajectory recording module, the trusted time source node is configured with at least three heterogeneous authoritative time synchronization channels, and a standard time is generated by a majority voting mechanism and accompanied by a digital signature. Every ten new blocks generated, a regular consensus node initiates a time comparison, packaging the deviation value, standard timestamp, local timestamp, and time source signature onto the blockchain to form a clock deviation history track indexed by node dimension.

[0008] Preferably, the drift compensation and clock anomaly detection module based on historical deviation has a built-in drift compensation calculation engine. After reading the node’s most recent thirty deviation records and removing outliers, the deviation trend is divided into three categories: stable fast drift, stable slow drift, and linear continuous drift. The corresponding average deviation fixed compensation or drift rate prediction compensation is adopted, and the comparison period can be dynamically shortened according to the deviation change rate.

[0009] Preferably, the drift compensation and clock anomaly detection module based on historical deviation classifies clock anomalies into two levels, mild and severe, according to the magnitude of the abrupt change, and performs weight reduction and temporary isolation measures respectively. Simultaneously, the timestamps of transactions from multiple nodes are calibrated one by one and cross-compared. If the deviation exceeds the tolerance threshold, a timestamp inconsistency alarm is triggered and the process is transferred to manual review.

[0010] Preferably, the node-level personalized response time baseline establishment module uses the node's continuous operation for seven days, no abnormal alarms, and stable clock deviation as the admission conditions for the stable period. During the stable period, it collects the end-to-end response time of transactions, groups them according to the active and inactive windows of the time zone, calculates the average value μ, standard deviation σ and P95 quantile to generate a node-specific baseline and stores it on the blockchain.

[0011] Preferably, the node-level personalized response time baseline establishment module integrates the effective data of the day into the original baseline with a 5% weight to achieve smooth updates; when a node undergoes major changes such as hardware upgrades or network migrations, the baseline is automatically triggered for reset. During the reset, the baseline of the node with the same configuration is used as a temporary reference and the alarm threshold is relaxed.

[0012] Preferably, the three-layer progressive degradation detection and network-wide systemic early warning module sets three detection thresholds using the consensus period as the statistical unit: A response time exceeding μ+1.5σ is considered mild degradation, and the risk weight is reduced; a response time exceeding μ+3σ is considered significant degradation, and the system is removed from the evaluation queue and notified to operations and maintenance; a response time of mild degradation or above for three consecutive cycles is considered trend degradation, triggering an early warning and expanding the scope of backup node invitations.

[0013] Preferably, the three-layer progressive degradation detection and network-wide systemic early warning module statistically analyzes the proportion of significantly degraded nodes across the entire network in real time and dynamically extends the transaction confirmation timeout using a tiered strategy; Establish a performance health profile for each node, retain baseline parameters, degradation records and trend data, and record them on the blockchain for evidence throughout the process.

[0014] Preferably, the global disturbance event knowledge base and the expected / abnormal disturbance attribution module maintain a structured disturbance event knowledge base on the chain, recording three types of events: holidays, system maintenance, and network disturbances, and updates are completed by multi-signature of governance nodes; When a performance deviation is detected, the knowledge base is matched. If the deviation is attributed to an expected disturbance, the weight of the affected node is reduced and the number of backup consensus nodes is increased. The configuration is automatically restored after the disturbance ends.

[0015] Preferably, the global disturbance event knowledge base and the expected / abnormal disturbance attribution module trigger a full-scale early warning for abnormal disturbances that do not match the knowledge base. If the disturbances persist for more than four hours, the emergency consensus mode is switched, the consensus node requirement is lowered, and cross-regional emergency nodes are activated. The accuracy of attribution timing is ensured by relying on calibration time, and the attribution results are used to reverse-regulate the degradation early warning strategy.

[0016] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention optimizes the operation mode of traditional static time synchronization by constructing a reliable time anchoring and dynamic drift compensation mechanism. It can continuously track the clock deviation pattern of nodes and complete dynamic calibration, alleviate the time judgment deviation problem caused by long-term clock drift, and improve the consistency and reliability of the time reference of the entire system. Relying on the node personalized performance baseline and hierarchical degradation detection mechanism, it replaces the traditional unified threshold monitoring mode, which can adapt to the performance differences of nodes in different regions, hardware and network environments, and reduce the possibility of false alarms and missed alarms.

[0017] 2. By establishing a global disturbance event knowledge base and attribution determination mechanism, this invention can match and distinguish the collective performance fluctuations of nodes with known external events, identify expected external disturbances and abnormal performance failures, reduce invalid alarms caused by external events, and lower the information screening costs for operation and maintenance personnel. For different types of disturbances, the system can adaptively adjust node weights and consensus scheduling strategies, schedule redundant computing resources to supplement capacity gaps, and ensure the processing efficiency of cross-border transactions and the overall operational stability of the system. Attached Figure Description

[0018] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This is a system structure diagram of the present invention. Detailed Implementation

[0019] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement this application. This application may be embodied in many different forms and for various purposes and should not be limited to the embodiments set forth herein. These embodiments are provided to make this application thorough and complete, and to fully convey the scope of this application to those skilled in the art. The embodiments described do not limit this application.

[0020] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0021] Example 1 Its specific implementation method is combined with the appendix Figure 1 Please provide a detailed explanation.

[0022] In this embodiment, it includes: Module 1: Reliable Time Source Anchoring and Clock Deviation Trajectory Recording Module This module establishes a decentralized, multi-source redundant, isolated, reliable, and end-to-end unified time reference system for the entire system. It corely implements three major functions: reliable time anchoring, periodic time comparison, and retention of clock deviation trajectory chains. It provides a unique and reliable time data source for subsequent clock compensation, anomaly detection, time zone matching, and disturbance attribution, and is the underlying foundation for all decision logic in the entire system.

[0023] At the time source architecture deployment level, this module independently deploys a dedicated trusted time source node cluster within the blockchain network, with at least five trusted time source nodes deployed across the entire network, distributed across different geographical regions and different operator networks to avoid overall time service interruptions caused by regional network failures. These nodes implement a completely isolated business mechanism, not participating in any core business processes such as transaction broadcasting, consensus voting, block packaging, or ledger updates. They exclusively provide standard time synchronization, time comparison, and time signature services, completely avoiding time base distortion issues caused by business computing power encroachment, consensus attack entanglement, and excessive node load. Each trusted time source node is configured with three completely heterogeneous and independent authoritative time synchronization channels, respectively connecting to the National Time Service Center's standardized NTP time synchronization service, GPS / BeiDou satellite time synchronization signals, and a high-precision atomic clock time synchronization module, achieving multi-source redundancy backup.

[0024] To prevent reference time anomalies caused by single time source failures, network fluctuations, or malicious tampering, the trusted time source node incorporates lightweight Byzantine consistency verification logic. It employs a majority-rule voting mechanism to filter and verify the three time synchronization data streams, automatically eliminating the abnormal time data with the largest deviation. The remaining two consistent data streams or the majority data stream are used as the final network-wide standard time, ensuring that the failure of any single time synchronization channel will not affect the stability and accuracy of the overall time reference. Simultaneously, all standard time outputs are accompanied by the trusted time source node's unique digital signature, ensuring the time reference is traceable and tamper-proof. When a regular node initiates a comparison request, it simultaneously sends requests to three randomly selected trusted time source nodes. The returned standard times are then subject to a majority vote, further reducing the impact of single-point time source anomalies. A 1-second timeout threshold is set for the time comparison request; after a timeout, it automatically retryes with other trusted time source nodes. If three consecutive requests fail, the node is marked as having a time synchronization anomaly and included in the minor anomaly monitoring.

[0025] At the level of periodic time comparison and data storage, all ordinary consensus nodes in the network are equipped with an automatic time comparison mechanism. The periodic comparison strategy driven by block height is adopted. By default, a time calibration request is automatically initiated every ten new blocks generated. Compared with the fixed natural time comparison method, it can perfectly adapt to the blockchain block production rhythm and avoid the problem of misaligned comparison timing caused by block production delay and block congestion.

[0026] During each comparison process, ordinary consensus nodes proactively request standard time data from the trusted time source node cluster. After receiving the authoritative standard time with a digital signature, they automatically calculate their own clock deviation value. The unified calculation formula is: Clock Deviation Value = Node Local Time - Network Standard Time. A positive deviation value indicates that the node's local time is ahead, while a negative deviation value indicates that the node's local time is behind.

[0027] After the comparison is completed, the node packages and uploads the complete comparison data set to the blockchain for permanent storage. Deviation records are uploaded to the blockchain as independent notarized transactions. Transaction fields use a standardized structure, supporting fast retrieval by node public key and block height range. On-chain data is stored in compressed form to reduce ledger bloat. Each notarized record contains five core elements: the clock deviation value, the authoritative standard timestamp corresponding to the comparison, the node's own local timestamp, the digital signature of the trusted time source, and the node's unique public key identifier. All data is written to the blockchain ledger in the form of transactions, and once uploaded, it is permanently immutable, fully traceable, and auditable.

[0028] At the trajectory generation and data value level, nodes continuously accumulate a continuous, orderly, and complete historical trajectory of clock deviation on the blockchain through long-term periodic comparisons. This trajectory is indexed by node dimension, and each new record is automatically sorted by time, supporting filtering and querying by time period and deviation magnitude, providing downstream modules with efficient data reading capabilities. The trajectory fully records the clock deviation magnitude, deviation direction, fluctuation pattern, calibration time, and legality verification information throughout the node's entire lifecycle, accurately restoring the long-term operating status of the node's clock. This trajectory data provides the core calculation basis for the dynamic drift compensation, clock mutation detection, and timestamp calibration of Module 2, and at the same time forms the original archive of the node's clock health status, providing underlying data support for subsequent node operation and maintenance audits, fault tracing, and compliance verification.

[0029] Module 2: Drift Compensation and Clock Anomaly Detection Module Based on Historical Deviation This module relies on the historical clock deviation trajectory stored on the blockchain in Module 1 to achieve four core capabilities: intelligent clock trend recognition, precise dynamic drift compensation, graded detection of clock mutations, and cross-calibration of transaction timestamps. It completely solves problems such as long-term systematic deviation of local clocks of nodes, sudden clock jumps, and inconsistencies in timestamps of multiple nodes, and provides a high-precision, standardized unified time dimension for all performance monitoring, time zone determination, and disturbance matching services across the network.

[0030] At the drift compensation calculation level, the module has a built-in dedicated high-precision drift compensation calculation engine, which serves as the sole calculation entry point for the entire system's time calibration. Before performing node time calibration and activity assessment, the engine automatically retrieves the most recent thirty sets of historical clock deviation data for the target node from the chain. It first uses the Grubbs test to remove outliers with significant deviations, eliminating the interference of single random deviations on trend judgment. Then, it uses the least squares method to complete the deviation trend fitting analysis, accurately classifying the node clock running state into three types of trends: stable fast, stable slow, and linear continuous drift.

[0031] For different trend types, the engine implements differentiated and precise compensation strategies: For nodes that are stable but slightly faster or slower than normal, with small fluctuations in deviation values ​​and no obvious linear change pattern, the engine takes the arithmetic mean of the most recent thirty deviation values ​​as a fixed compensation amount, and completes standardized calibration by calculating the calibrated time as the node's local time minus the average deviation value. For nodes with linear drift, i.e., the node clock continuously speeds up or slows down over time, the engine first accurately fits the drift rate per unit time, then combines it with the time interval from the last calibration to the current moment to calculate the cumulative drift amount, and adds it to the basic average deviation value to form a dynamic total compensation amount, achieving predictive and precise calibration and completely eliminating long-term accumulated clock errors. The calibration results of the drift compensation engine are applied to all time-sensitive logic in the entire system, including time zone activity determination, transaction response time statistics, disturbance event time matching, and consensus timeout calculation, while the original local timestamp in the block header is retained for traceability and auditing.

[0032] Meanwhile, the engine has adaptive sampling frequency adjustment capabilities, which can dynamically optimize calibration accuracy. When the system detects an abnormal increase in the node clock deviation rate, a single-hour deviation fluctuation exceeding 100 milliseconds, or frequent deviation direction jumps, it automatically shortens the time comparison period of that node from every ten blocks to every two blocks, increases the data sampling frequency, and finely tracks dynamic clock changes, preventing calibration failures caused by sudden clock fluctuations.

[0033] At the level of clock anomaly detection and handling, the module establishes a standardized clock mutation identification mechanism, employing a two-compare verification mechanism. A significant deviation in a single comparison does not directly determine an anomaly; only when the mutation amplitude conditions are met in two consecutive comparisons is an anomaly classification formally triggered, preventing misjudgments caused by single network latency. The system continuously compares the fluctuation difference between the node's current deviation value and the average of the last five historical deviations to accurately capture unnatural clock jumps and implements a two-level classification handling based on the fluctuation amplitude. The first level is a mild clock anomaly, corresponding to a mutation amplitude in the range of 5 to 30 seconds. The system marks this node as clock unstable, and in the network-wide time zone activity assessment and node risk scoring system, the node's weight is reduced to 50% of that of normal nodes, weakening the interference of abnormal nodes on the overall judgment results. At the same time, complete internal log records are retained, and no external alarms are triggered, preserving the node's self-recovery space.

[0034] The second level is severe clock anomaly, corresponding to a sudden change exceeding 30 seconds, which constitutes a serious clock distortion issue. The system immediately performs isolation measures, temporarily removing the node from time zone activity statistics, consensus node candidate pool, and the network-wide performance evaluation system, suspending its participation in all time-related decision-making. Normal business permissions are only gradually restored after the node completes three consecutive stable time comparisons, the deviation value returns to the normal range, and the fluctuation stabilizes. The occurrence time, block height, anomaly level, handling strategy, and recovery record of all clock anomaly events are all stored on the blockchain, forming a unique and tamper-proof clock health profile for each node.

[0035] At the level of accurate transaction timestamp verification, the module implements personalized timestamp calibration and multi-node cross-verification at the single-transaction level. When determining transaction time periods, calculating transaction processing delays, and verifying cross-node transaction ordering and settlement sequence, the system does not directly accept the original timestamps of nodes. Instead, it calibrates the transaction timestamps issued by each node individually based on the real-time compensation amount of each node, eliminating individual clock deviations. After calibration, the system performs a consistency comparison of the standard timestamps calibrated by multiple nodes. If the calibration time deviation between nodes exceeds a preset tolerance threshold of 2 seconds, a timestamp inconsistency alarm is immediately triggered, the corresponding transaction is marked as having questionable time credibility, and it is automatically transferred to the manual review process. Reviewers can access the clock health records and deviation trajectories of the corresponding nodes to check the cause of the anomaly. If it is confirmed to be a node malfunction, a fault handling process is triggered; if it is confirmed to be an occasional interference, it is marked as an invalid alarm and a record is retained. The relevant review results are synchronously uploaded to the blockchain for evidence storage, ensuring the compliance and accuracy of the time dimension of cross-border transactions.

[0036] Module 3: Establishing a Node-Level Personalized Response Time Baseline This module completely abandons the traditional monitoring mode of a uniform static threshold across the entire network. Based on the real operating data of each node, it establishes a personalized performance baseline for each consensus node and each time zone operating window that is exclusive, dynamically iterative, and auditable and reconfigurable. It accurately adapts to the individual differences of nodes in different time zones, hardware configurations, and network environments around the world, and solves the false alarm and missed alarm problems caused by the uniform threshold from the root. At the same time, it adopts deterministic statistical rules throughout the process, without machine learning black boxes, and fully meets the compliance requirements of cross-border payment supervision that are explainable and traceable.

[0037] At the personalized baseline initialization level, the system sets strict stability period admission standards, with three judgment conditions rigorously verified: continuous operation for seven days means no offline disconnection record exceeding 10 minutes; abnormal alarm records include all alarms of three categories: clock anomaly, consensus anomaly, and network anomaly; and clock deviation stability means the deviation value fluctuation range does not exceed ±500 milliseconds for seven consecutive days with no sudden changes. Baseline collection and modeling will only be initiated when a node simultaneously meets all three stability conditions. During the stability period, the system accurately collects the node's full-process transaction response time data, with statistical scope covering the complete end-to-end time consumption from transaction request reception, queue processing, transaction signature verification, consensus verification to result receipt return, fully restoring the node's real business processing performance. The collection process is subdivided by transaction type, divided into three categories: ordinary transfer transactions, cross-border large-amount transactions, and contract call transactions, with each category having its own independent baseline, further improving the accuracy of the baseline.

[0038] The system meticulously groups the collected data according to time zone operating rules, primarily dividing it into two main scenarios: active business periods and inactive business periods corresponding to the respective time zone. The division of the active time zone window is set based on the legal working hours and peak patterns of cross-border payment business in the corresponding time zone. The window boundaries can be adjusted through governance proposals to adapt to the needs of different business stages. It also supports further refinement into multiple time-segment subgroups based on business requirements. For each set of scenario-based data, the system calculates three core baseline parameters using deterministic statistical algorithms: mean μ, standard deviation σ, and P95 quantile. These parameters respectively characterize the node's normal performance level, performance fluctuation range, and normal performance upper limit under extreme scenarios. These three parameters together constitute the exclusive performance baseline for the node's corresponding time zone window. All baseline parameters are permanently stored on the blockchain and uniquely bound to the node's identity.

[0039] At the baseline dynamic iteration update level, the module is designed with a lightweight and smooth update mechanism to adapt to long-term natural performance changes of nodes. During the daily low-peak business period in the early morning, the system automatically filters the previous day's valid operating data, first filtering the current day's data for anomalies, removing response time data that occurred during periods of degradation alarms, clock anomalies, or network fluctuations. The filtering standard is to exclude all samples whose response time exceeds the P99 quantile of the day, avoiding abnormal data contaminating the baseline. After filtering, the valid data of the day is integrated into the historical baseline with a low weight of 5%, and iteratively updated according to a fixed formula: new baseline = 95% historical baseline + 5% valid data of the day. This mechanism allows the baseline to slowly adapt to the natural performance fluctuations caused by hardware aging, network quality fine-tuning, and system version iterations, while avoiding short-term accidental fluctuations from damaging the baseline stability, ensuring that the baseline closely matches the actual operating level of the nodes in the long term.

[0040] At the baseline reset and full-process auditing level, the module is equipped with a major node change trigger mechanism. When a node undergoes structural changes such as hardware upgrades, data center migrations, cross-border carrier changes, or core software version iterations, the system automatically determines that the original baseline is invalid and immediately triggers the baseline reset process. The system clears historical old baseline data, restarts a 30-day stable data collection cycle, and generates a dedicated baseline adapted to the node's new operating state. During the baseline reset, the system automatically matches the baseline of a normal node in the same geographical region, with the same hardware configuration, and the same network carrier as the new node as a temporary reference, while relaxing the alarm threshold by 30%. After the new baseline is established, it automatically switches back to the personalized threshold to ensure the effectiveness of monitoring during the cold start phase.

[0041] All daily iterations, updates, and major changes to baselines are recorded on the blockchain, with complete documentation of the triggering reasons, baseline parameters before and after the update, operation block height, and system execution signature. This ensures that the entire lifecycle of the baseline is traceable, auditable, and monitorable, completely resolving the pain points of traditional static baselines, such as rigidity, poor adaptability, and lack of change records. It also provides accurate, reliable, and personalized judgment criteria for subsequent performance degradation detection.

[0042] Module 4: Three-layer progressive degradation detection and network-wide systemic early warning module Based on the node-specific time zone performance baseline output by Module 3, this module builds a hierarchical, progressive, predictable, and controllable deterministic performance degradation detection system. It does not rely on any machine learning model, has no cold start defects, and can accurately distinguish between occasional node performance fluctuations and continuous performance degradation. It achieves full-gradient monitoring from early minor anomalies to severe failures, while also supporting the identification of systemic risks across the entire network and adaptive adjustment of global parameters.

[0043] The core of the module constructs a three-layer progressive degradation detection mechanism. Each layer corresponds to a clearly defined performance deviation threshold, judgment logic, and handling strategy, with gradient coverage of all performance anomaly scenarios. Performance degradation detection uses a single consensus cycle as the statistical unit, with each consensus cycle corresponding to the duration of 100 blocks. The average response time of all transactions on that node within the statistical cycle is used as the judgment criterion. If the number of valid transaction samples in a single cycle is less than 20, a level judgment is not triggered to avoid statistical errors caused by small samples.

[0044] The first layer is mild degradation detection, belonging to the early warning and perception level. When the average response time of a node in the current period exceeds its own baseline average value μ + 1.5 times the standard deviation σ, the system judges it as mild degradation, indicating that the node's performance has deviated from the normal fluctuation range and has shown initial abnormal deviation. This level of anomaly does not affect the operation of core business. The system only reduces the node's risk score weight to 0.7, weakening its proportion in the overall network activity assessment, while automatically increasing the frequency of performance data collection for this node from minute-level collection to second-level sampling, continuously tracking performance change trends. The system fully retains internal operation logs and does not push alarms externally, giving the node a buffer period for self-recovery of performance and avoiding unnecessary maintenance disturbances caused by minor fluctuations. If mild degradation persists for 5 consecutive periods, it is automatically upgraded to the significant degradation handling process.

[0045] The second layer is significant degradation detection, belonging to the deterministic fault determination level. When a node's response time exceeds the baseline average μ + 3 standard deviations σ, combined with the statistical 3σ criterion, occasional network jitter, short-term business congestion, and other accidental factors can be completely ruled out, determining that the node has experienced a substantial performance failure. The system immediately executes isolation and control strategies, completely removing the node from the network-wide latency risk scoring system and activity assessment queue, prohibiting it from participating in consensus scheduling and node weight calculation. At the same time, an operation and maintenance work order is automatically generated, pushing it for manual intervention to investigate and promptly address substantial faults at the node's hardware, network, and system levels, preventing the spread of single-point failures and impacting cross-border transaction efficiency. After a significantly degraded node completes fault repair, a 24-hour stable observation period is required. Only if there are no degradation records during the observation period can the weight be gradually restored, first to 50% weight and running for 12 hours, and then to 100% normal weight, avoiding frequent scheduling and switching caused by repeated faults.

[0046] The third layer is the trend degradation early warning, which belongs to the continuous risk prediction level. The system analyzes the long-term operating status of nodes. If the performance status of a node remains at a level of mild degradation or above for three consecutive complete consensus cycles, it can be determined that the node has an irreversible and continuous performance deterioration trend, and is not a temporary fluctuation. The system immediately triggers a gradual degradation early warning and initiates network-wide adaptive optimization scheduling. It proactively expands the scope of backup consensus node invitations for this type of transaction, upgrading from scheduling nodes in the same region to scheduling multiple nodes across time zones and regions. At the same time, it temporarily increases the consensus priority of the corresponding transaction, prioritizing the scheduling of high-performance nodes to participate in consensus, replenishing redundant consensus computing power in advance, avoiding consensus bottlenecks caused by faulty nodes, and ensuring the stability of transaction confirmation efficiency across the entire network.

[0047] At the level of systemic risk management across the entire network, the module possesses macro-level situational awareness capabilities. The system continuously monitors the percentage of consensus nodes in a significantly degraded state across the network and employs a tiered adjustment strategy: when the percentage of significantly degraded nodes reaches 10%, the timeout is extended by 2 seconds; at 20%, by 5 seconds; and at 30%, by a maximum of 10 seconds. As the percentage declines, it gradually reverts to the corresponding tier, achieving a smooth transition. When the percentage exceeds a preset threshold of 20%, the entire network is deemed to have entered a state of systemic latency risk, with a general decline in overall node performance. At this point, the system automatically and globally optimizes the transaction confirmation mechanism, dynamically extending the transaction timeout threshold to reduce false timeouts, transaction retries, and transaction failures caused by the general slowdown of nodes across the network, significantly improving the overall transaction success rate in complex scenarios. When the percentage of abnormal nodes falls back to a safe threshold, the system automatically restores default parameters, achieving adaptive control of network-wide risk.

[0048] Meanwhile, the system establishes a dynamically updated performance health profile for each node. The profile is updated daily at midnight, retaining detailed data for the most recent 90 days and statistical summaries for the entire year. Detailed data exceeding the expiration date is archived, balancing query efficiency and storage costs. The profile integrates node baseline parameters across all time zones, records of all baseline updates and resets, successive degradation detection levels, early warning trigger records, risk handling results, and 30-day performance change trends. All data is stored on-chain and is tamper-proof, providing comprehensive data support for node operation and maintenance optimization, fault recovery, network-wide performance status analysis, and regulatory compliance audits.

[0049] Module 5: Global Disturbance Event Knowledge Base and Expected / Abnormal Disturbance Attribution Module This module serves as the scenario identification and intelligent control module for the entire system. Relying on the precise time benchmark of Module 2 and the performance anomaly data of Module 4, it builds a global disturbance event knowledge base and a two-way attribution mechanism to accurately distinguish between known external environmental disturbances and actual node fault disturbances. It then executes differentiated risk control strategies accordingly, thoroughly solving the problems of alarm overload and fault inundation in complex cross-border scenarios, and achieving precise early warning, adaptive control, and scenario adaptability.

[0050] At the level of building and governing the global disturbance knowledge base, the system constructs a decentralized, governable, and tamper-proof structured disturbance event knowledge base on the blockchain. This knowledge base stores all known external disturbance events related to global cross-border payments in a standardized calendar format, corely covering three categories of events: global public holidays, fixed system maintenance windows of major cross-border financial institutions, and major regional network disturbance events (including fiber optic cable construction, network expansion, network congestion during large-scale public events, and regional maintenance shutdowns). The knowledge base is divided into three levels based on impact: Level 1 represents major events across the entire domain; Level 2 represents regional holidays and maintenance events; and Level 3 represents small-scale, localized disturbances. Different levels correspond to different weight adjustments and node expansion ratios. The level classification standards are uniformly formulated by the governance committee.

[0051] Each disturbance event added to the database contains complete structured fields: affected geographical time zone, covered node range, event type classification, precise start and end times, event impact level, and official data source credentials. The knowledge base implements a strict governance access mechanism. All additions, modifications, and deletions of expired events must be proposed by the supervisory node or the network governance committee and verified through multi-signature consensus before being uploaded to the blockchain to take effect. This prevents the entry of false events and malicious tampering with knowledge base data, ensuring the authority and accuracy of scenario judgment benchmarks.

[0052] At the level of intelligent attribution and anticipated disturbance control, when Module 4 detects a collective performance deviation from the baseline in a certain time zone or batch of nodes, Module 5 immediately initiates the attribution matching process. The system calls the network-wide standard time calibrated by Module 2, and combines the time zone of the abnormal node with the time period of the anomaly to accurately search the knowledge base for a matching valid disturbance event. The disturbance event matching adopts a two-dimensional verification. The time dimension allows a 15-minute tolerance window before and after, while the node dimension requires that more than 60% of the affected nodes show performance deviation before it is considered a match, avoiding misattribution caused by the coincidence of individual node failures and event timing. If a completely matching known event such as a holiday or routine maintenance is found, the performance deviation is determined to be an anticipated disturbance, belonging to normal external environmental influences and not a node device failure.

[0053] For foreseeable disturbances, the system will automatically initiate pre-adjustments one hour before the event begins, gradually reducing weights and expanding backup nodes. For anticipated disturbance scenarios, the system disables all invalid risk control alarms and simultaneously activates two adaptive network-wide control strategies: first, adaptive weight reduction, temporarily lowering the activity weights of all nodes in the affected time zone based on the disturbance's impact level to prevent normal environmental fluctuations from being misjudged as node risks; second, consensus node expansion scheduling, proactively expanding the scope of backup consensus node invitations, and calling upon redundant nodes across time zones and regions to participate in consensus, compensating for insufficient local node activity and ensuring that cross-border transaction consensus efficiency and confirmation timeliness are not affected by holidays or maintenance events. Once the disturbance event ends on time, the system automatically verifies the node performance recovery status and gradually restores the network-wide default weight configuration and node scheduling strategy within one hour, achieving seamless adaptive control.

[0054] At the level of handling abnormal disturbances and emergency consensus, if the system does not find any matching known disturbance events in the knowledge base, it determines that the performance deviation is an abnormal disturbance, which is a real anomaly caused by unconventional risks such as unknown network failures, node hardware failures, or sudden network attacks. Abnormal disturbances are handled in stages according to their duration: those lasting less than 1 hour maintain a regular warning, those lasting more than 2 hours are upgraded to a key alarm and pushed to the operations and maintenance manager, and those lasting more than 4 hours trigger the emergency consensus mode. The system fully utilizes the risk warning and handling process in Module 4 and promptly pushes operations and maintenance alarms. If the abnormal disturbance lasts for more than 4 hours and does not recover automatically, the system determines that there is a persistent unknown risk across the entire network and automatically activates the advanced emergency consensus mode: lowering the transaction confirmation consensus threshold from two-thirds of the nodes to half of the nodes, while activating a fast consensus channel to simplify non-core verification steps, batch activating a pre-set cross-regional emergency backup node pool, and selecting emergency nodes according to the principle of geographical dispersion, prioritizing deployment in different continents and different operators to avoid regional failures affecting both the main node and emergency nodes simultaneously, maximizing the availability and stability of the blockchain cross-border payment network. Once the abnormal disturbances are eliminated and the performance of all network nodes returns to the baseline and remains stable for more than two hours, the system will automatically exit emergency mode and restore the normal consensus mechanism after governance and verification.

[0055] At the three-module linkage level, this module forms a strong coupling data flow with Modules 2 and 4: Module 2 outputs calibrated and accurate standard time, ensuring zero error in time zone matching and event time alignment; Module 4 outputs accurate data on the range of abnormal nodes, abnormal time periods, and degree of deviation, providing core input for attribution analysis; the attribution results of Module 5 reverse-correct the early warning logic of Module 4, realizing a precise risk control logic of no alarms for expected disturbances and mandatory handling of abnormal disturbances. All attribution results, adaptive control records, and emergency mode switching logs are stored on the blockchain for evidence, which can be used for regulatory audits, scenario reviews, and knowledge base iteration and optimization. After the investigation of abnormal disturbance events is completed, operations and maintenance personnel can submit proposals to add such events to the knowledge base, marking the cause, scope of impact, and duration of the event. After review and approval by the governance committee, the event is officially added to the knowledge base, forming a continuous optimization of detection-handling-review-entry, continuously improving the adaptability to complex scenarios across the entire network.

[0056] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

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

[0058] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0059] In addition, the functional units in the various embodiments of this application 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.

[0060] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A blockchain-enabled intelligent risk control system for cross-border financial payment transactions, characterized in that: include: The trusted time source anchoring and clock deviation trajectory recording module is deployed in isolation from the consensus process through multi-source trusted time source nodes. It collects the clock deviation values ​​of each consensus node according to the block generation cycle and stores them on the chain, generating continuous historical trajectories of node clock deviations, providing a trusted data source for subsequent drift compensation calculations. The drift compensation and clock anomaly detection module based on historical deviation reads the historical deviation trajectory, fits the deviation change trend and calculates the dynamic compensation amount, completes the node local time calibration and clock anomaly classification and handling, and outputs the calibrated standard time and node clock health record. The node-level personalized response time baseline establishment module establishes a unique response time baseline for each node based on calibration time and stable operation judgment, according to the active window of the time zone, and realizes dynamic iteration. The three-layer progressive degradation detection and network-wide systemic early warning module performs three-layer progressive degradation detection based on a personalized baseline, generating node degradation status and network-wide systemic risk data; The global disturbance event knowledge base and the expected / abnormal disturbance attribution module combine calibration time and degradation data to perform disturbance attribution, and implement targeted adaptive regulation and emergency response, and reverse correct performance early warning strategies.

2. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 1, characterized in that, In the trusted time source anchoring and clock deviation trajectory recording module, the trusted time source node is configured with at least three heterogeneous authoritative time synchronization channels, and a standard time is generated with a majority voting mechanism and a digital signature attached. Every ten new blocks generated, a regular consensus node initiates a time comparison, packaging the deviation value, standard timestamp, local timestamp, and time source signature onto the blockchain to form a clock deviation history track indexed by node dimension.

3. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 1, characterized in that, The drift compensation and clock anomaly detection module based on historical deviation has a built-in drift compensation calculation engine. After reading the node's most recent thirty deviation records and removing outliers, it classifies the deviation trend into three categories: stable fast drift, stable slow drift, and linear continuous drift. Correspondingly, it adopts fixed average deviation compensation or drift rate prediction compensation, and can dynamically shorten the comparison period according to the deviation change rate.

4. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 3, characterized in that, The drift compensation and clock anomaly detection module based on historical deviation classifies clock anomalies into two levels, mild and severe, according to the magnitude of the sudden change, and performs weight reduction and temporary isolation measures respectively. Simultaneously, the timestamps of transactions from multiple nodes are calibrated one by one and cross-compared. If the deviation exceeds the tolerance threshold, a timestamp inconsistency alarm is triggered and the process is transferred to manual review.

5. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 1, characterized in that, The node-level personalized response time baseline establishment module uses seven consecutive days of node operation, no abnormal alarms, and stable clock deviation as the admission criteria for the stable period. During the stable period, it collects the end-to-end response time of transactions, groups them according to the active and inactive windows of the time zone, calculates the average value μ, standard deviation σ and P95 quantile to generate a node-specific baseline and stores it on the blockchain.

6. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 5, characterized in that, The node-level personalized response time baseline establishment module integrates the effective data of the day into the original baseline with a 5% weight to achieve smooth updates. When a node undergoes major changes such as hardware upgrades or network migrations, the baseline is automatically triggered for reset. During the reset, the baseline of the node with the same configuration is used as a temporary reference and the alarm threshold is relaxed.

7. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 1, characterized in that, The three-layer progressive degradation detection and network-wide systemic early warning module uses the consensus cycle as the statistical unit and sets three-layer detection thresholds: A response time exceeding μ+1.5σ is considered a mild degradation, and the risk weight is lowered. If the degradation exceeds μ+3σ, it is considered a significant degradation, removed from the evaluation queue, and the operations and maintenance department is notified; if the degradation is mild or above for three consecutive cycles, it is considered a trend degradation, triggering an early warning and expanding the scope of backup node invitations.

8. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 7, characterized in that, The three-layer progressive degradation detection and network-wide systemic early warning module provides real-time statistics on the proportion of significantly degraded nodes across the entire network and uses a tiered strategy to dynamically extend the transaction confirmation timeout. Establish a performance health profile for each node, retain baseline parameters, degradation records and trend data, and record them on the blockchain for evidence throughout the process.

9. The blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 1, characterized in that, The global disturbance event knowledge base and the expected / abnormal disturbance attribution module maintain a structured disturbance event knowledge base on the chain, recording three types of events: holidays, system maintenance, and network disturbances. Updates are completed by governance nodes through multi-signature. When a performance deviation is detected, the knowledge base is matched. If the deviation is attributed to an expected disturbance, the weight of the affected node is reduced and the number of backup consensus nodes is increased. The configuration is automatically restored after the disturbance ends.

10. A blockchain-enabled intelligent risk control system for cross-border financial payment transactions according to claim 9, characterized in that, The global disturbance event knowledge base and the expected / abnormal disturbance attribution module trigger a full alert for abnormal disturbances that do not match the knowledge base. If the disturbances persist for more than four hours, the emergency consensus mode is switched, the consensus node requirement is lowered, and cross-regional emergency nodes are activated. The accuracy of attribution timing is ensured by relying on calibration time, and the attribution results are used to reverse-regulate the degradation early warning strategy.

Images