Right and interest transaction cancel-after-verification and payment integration method in one-code benefit payment scene
By cleaning and normalizing payment transaction and rights verification data in the Yimahui payment scenario, and combining communication latency feature analysis, the system identifies and automatically compensates for transaction status consistency risks, thus solving the inconsistency problem between the payment and verification systems and improving system stability and user experience.
Patent Information
- Application Number
- CN202511697750.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-19
- Publication Date
- 2026-02-10
AI Technical Summary
In the Yimahui payment scenario, the failure to promptly redeem benefits after a payment transaction leads to a decline in user experience and chaotic benefit management. Furthermore, maintaining the consistency of the existing status relies on manual or scheduled tasks, increasing system maintenance costs and posing business risks.
By asynchronously acquiring payment transaction data and rights verification data, cleaning and normalizing them, and combining them with communication latency characteristics for analysis, the risk of transaction status consistency is identified. A risk prediction model is built using machine learning algorithms, an adaptive compensation strategy is generated, and the compensation operation is automatically executed to ensure consistency.
It significantly reduces the risk of state inconsistency caused by high concurrency and network jitter, improves the accuracy of transactions and equity reconciliation, reduces operational risks, enhances system stability and reliability, and ensures business continuity and user trust.
Smart Images

Figure CN121504459A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of payment integration processing technology, and relates to a method for rights transaction verification and payment integration in the context of One Code Payment. Background Technology
[0002] Yimahui deploys "rights redemption" and "payment transactions" separately in different system modules, achieving separation of fund flow and rights management in the system architecture. However, this separation relies on asynchronous interfaces for inter-system communication, such as using message queues and callback mechanisms. In high-concurrency scenarios or under network jitter conditions, this may lead to the following problems: 1. After a payment transaction is completed, the rights and benefits are not promptly and correctly verified, leading to a decline in user experience and confusion in rights and benefits management. Secondly, it is possible that rights and benefits verification may be successful, but the payment process may experience abnormal rollbacks for various reasons, posing challenges to system consistency and fund management.
[0003] 2. The current mechanism for maintaining consistency between the two states mainly relies on manual triggering or scheduled tasks for compensation. This not only increases the system maintenance cost, but may also lead to further business risks and customer dissatisfaction due to delays or compensation failures, resulting in high operational risks and a crisis of user trust. Summary of the Invention
[0004] In view of the problems existing in the prior art, the present invention provides a method for integrating rights transaction verification and payment in the Yimahui payment scenario to solve the above-mentioned technical problems.
[0005] To achieve the above and other objectives, the technical solution adopted by the present invention is as follows: This invention provides a method for integrating rights transaction verification and payment in the context of One-Code Benefit Payment, which includes the following steps: Step S1: Asynchronously obtain payment transaction data and rights verification data from the payment system and rights verification system through the data interface, and perform data cleaning and normalization on the payment transaction data and rights verification data to obtain transaction verification status data; perform asynchronous communication delay analysis on the transaction verification status data, including message queue transmission delay, callback timeout calculation and network jitter assessment, to obtain communication delay characteristic data. Step S2: Identify transaction status consistency risks based on communication delay feature data. Generate consistency risk index data by calculating the time series deviation and status matching degree between payment status and reconciliation status. Mine historical abnormal patterns based on consistency risk index data. Use clustering algorithm to classify historical abnormal transaction records into patterns to obtain historical abnormal pattern data. Step S3: Train the AI prediction model based on historical anomaly pattern data, construct the transaction consistency risk prediction model using machine learning algorithms, and extract risk feature vectors through feature engineering to obtain the transaction consistency risk prediction model; use the transaction consistency risk prediction model to predict the risk of real-time transaction data, and output the risk probability, risk type and risk time window to obtain the risk prediction result. Step S4: Generate an intelligent compensation strategy based on the risk prediction results. Generate an adaptive compensation strategy based on the risk type, risk probability and historical compensation effect data to obtain compensation strategy data. Execute automatic compensation operation based on the compensation strategy data. Call the payment system rollback interface through API and verify the transaction consistency status after compensation. Confirm the self-healing effect through status consistency check.
[0006] As described above, the method for integrating rights transaction verification and payment in the One-Code-for-Payment scenario provided by the present invention has at least the following beneficial effects: The present invention provides a method for integrating rights transaction verification and payment in the context of One-Code Payment. This method asynchronously acquires payment transaction data and rights verification data, cleans and normalizes them, and analyzes them in conjunction with communication latency characteristics to identify consistency risks in transaction states. This process effectively solves the inconsistency problem caused by asynchronous communication in current payment and verification systems. On one hand, this processing method significantly reduces the risk of state inconsistency caused by high concurrency and network jitter through the calculation of time series deviation and state matching degree, improving the accuracy of transactions and rights verification, thereby avoiding potential business interruptions and user experience losses, while reducing potential operational risks. On the other hand, through the mining of historical abnormal patterns and the training of AI prediction models, the system can proactively prevent and respond to risks in a timely manner, ensuring the efficient and secure operation of the payment and verification system. This intelligent compensation mechanism not only effectively avoids financial losses and user trust crises caused by transaction anomalies, but also improves the overall system's operational stability, ensuring the system's economy and security, and greatly enhancing business continuity and reliability in complex environments. Attached Figure Description
[0007] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0008] Figure 1 This is a schematic diagram showing the connections between the steps of the method of the present invention. Detailed Implementation
[0009] The following description, in conjunction with the implementation of this invention, is merely an example and illustration of the concept of this invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the inventive concept or exceed the scope defined in these claims, all of which should fall within the protection scope of this invention. Example
[0010] Please see Figure 1 As shown, the method for integrating rights transaction verification and payment in the One-Code-for-Payment scenario includes the following steps: Step S1: Asynchronously obtain payment transaction data and rights verification data from the payment system and rights verification system through the data interface, and perform data cleaning and normalization on the payment transaction data and rights verification data to obtain transaction verification status data; perform asynchronous communication delay analysis on the transaction verification status data, including message queue transmission delay, callback timeout calculation and network jitter assessment, to obtain communication delay characteristic data.
[0011] For example, step S1 includes: Step S11: Asynchronously obtain payment transaction data from the payment system through the data interface, and asynchronously obtain rights verification data from the rights verification system. Timestamp and request source identifier are recorded on the obtained data to obtain the original transaction dataset and the original verification dataset. Step S12: Perform format validation and field matching analysis on the original transaction dataset and the original reconciliation dataset, complete missing fields, and remove or correct abnormal data to obtain formatted transaction data and formatted reconciliation data. Step S13: Based on the formatted transaction data and formatted reconciliation data, merge and match data with the same transaction identifier field, and normalize the data according to the order of transaction time and reconciliation time to obtain transaction reconciliation status data. Step S14: Analyze the asynchronous communication process of the transaction reconciliation status data, identify the message queue transmission path and call link, sample and calculate the transmission time of different link nodes, and obtain the message queue transmission delay data. Step S15: Based on the message queue transmission delay data, calculate the timeout time for the system callback process, analyze the response cycle and waiting cycle of different callback nodes, and obtain the callback timeout time data; Step S16: Perform joint fluctuation analysis on message queue transmission delay data and callback timeout time data to identify the delay fluctuation characteristics caused by network jitter during communication and obtain network jitter assessment data; Step S17: Based on message queue transmission delay data, callback timeout data, and network jitter assessment data, perform a comprehensive calculation of the overall latency characteristics of asynchronous communication and output communication latency characteristic data.
[0012] It should be added that step S14 includes: Step S141: Perform link identification analysis on the asynchronous communication information in the transaction reconciliation status data, identify the message queue transmission path and call link node corresponding to each transaction record, establish a link node correspondence table, and obtain asynchronous communication link identification data; Step S142: Based on the asynchronous communication link identification data, sample and calculate the transmission time of each calling link node to obtain the message sending time and receiving time difference between nodes, and obtain node transmission time difference data; Step S143: Based on the node transmission time difference data, perform statistical summarization and averaging of the time difference of the link nodes to obtain the average transmission delay data of each link, and identify abnormal fluctuation nodes to obtain link delay fluctuation data. Step S144: Based on the average transmission delay data and link delay fluctuation data, comprehensively evaluate the overall transmission stability of the message queue, calculate the average delay and fluctuation range of the message queue in the asynchronous communication process, and obtain the message queue transmission delay data.
[0013] In this embodiment of the invention, firstly, unique identifier fields such as message ID, sending node ID, receiving node ID, and calling interface identifier contained in the asynchronous communication information are extracted. By associating and matching the message ID of each transaction record with the corresponding sending node operation log and receiving node operation log, the entire message queue transmission path traversed by each transaction record from the message initiating node to the final receiving node is accurately identified. At the same time, the calling link nodes contained in each path are located one by one. After assigning a unique node identifier code to each calling link node, a link node correspondence table is established. By traversing the full asynchronous communication log of all transaction records, the transmission path information and link node information corresponding to each transaction record are entered into the correspondence table one by one. Then, the data in the table is cleaned to remove duplicate link node records and invalid log association records, and finally, complete asynchronous communication link identification data is obtained. Based on the asynchronous communication link identification data, firstly, all call link node sequences corresponding to each message queue transmission path are selected. Following the system time sequence, the system record time when the node sends a message and the system record time when the next adjacent node receives the message are extracted from the operation logs of each call link node. For each adjacent link node pair, a sampling frequency is set according to the transaction data generation frequency. The transmission process of the same message between adjacent nodes is sampled multiple times. During each sampling, the message receiving timestamp of the later node in the adjacent node pair is subtracted from the message sending timestamp of the previous node to obtain the message sending and receiving time difference between the nodes in that sampling. All sampled time difference data for each adjacent node pair are organized and summarized according to the node pair identifier to obtain the node transmission time difference data. Based on the node transmission time difference data, the data is first grouped according to the dimension of the message queue transmission link. The transmission time difference data of all adjacent node pairs belonging to the same link are grouped together. The transmission time difference data of each adjacent node pair within each group are statistically summarized and calculated. The sum of all transmission time differences for a node pair within a set statistical period is used to divide the sum by the number of samples within the statistical period to obtain the average transmission time difference for that adjacent node pair. Then, the average transmission time differences of all adjacent node pairs on the same link are summed to obtain the total average transmission delay data for that link. Simultaneously, for the transmission time difference data of each adjacent node pair, the standard deviation of its data fluctuation is calculated. The calculation process is as follows: first, the difference between all transmission time differences for that node pair and the average transmission time difference for that node pair is calculated; then, each difference is squared; then, the arithmetic mean of all squared differences is calculated; finally, the square root of the arithmetic mean is taken to obtain the standard deviation of the transmission time difference for that node pair. The calculated standard deviation is compared with a preset threshold. If the standard deviation of a node pair exceeds the preset threshold, the corresponding link node is determined to be an abnormal fluctuation node. Information such as the identifier code, the transmission link ID of the message queue to which the abnormal fluctuation node belongs, the specific value of the standard deviation, and the magnitude of exceeding the threshold for all abnormal fluctuation nodes is collected and summarized to obtain the link delay fluctuation data. Based on average transmission latency data and link latency fluctuation data, a comprehensive assessment of the overall transmission stability of the message queue is conducted. First, the overall average latency of the message queue during asynchronous communication is calculated by summing the average transmission latency data of all message queue transmission links. This sum is then divided by the total number of links to obtain the overall average latency. Next, the fluctuation range of transmission latency is calculated. First, the standard deviation of transmission time difference corresponding to all abnormal fluctuation nodes is extracted from the link latency fluctuation data. Simultaneously, the standard deviation of the average transmission latency of all message queue transmission links is calculated. The maximum value minus the minimum value among all standard deviation data yields the fluctuation range of the message queue's transmission latency. Then, the transmission stability of the message queue is judged by combining it with industry-preset transmission stability evaluation indicators. If both indicators are satisfied, the transmission stability is considered good. If either indicator is not satisfied, the distribution of abnormal fluctuation nodes and the causes of the fluctuations are further analyzed. Finally, the information such as the overall average latency, transmission latency fluctuation range, and stability evaluation results are integrated to obtain the message queue transmission latency data.
[0014] It should be added that step S15 includes: Step S151: Based on the message queue transmission delay data, identify each callback node in the system callback process, establish a node response path table, determine the calling order and dependency relationship of each callback node, and obtain the callback node path data. Step S152: Perform response cycle sampling analysis on the callback node path data, collect the actual response time and request trigger time of each callback node in multiple asynchronous communications, calculate the node response cycle difference, and obtain the callback node response cycle data. Step S153: Based on the callback node response cycle data, calculate the waiting time of each node, and define the node waiting time as the difference between the completion time of the previous node and the response start time of the current node to obtain the callback node waiting cycle data. Step S154: Based on the callback node response cycle data and callback node waiting cycle data, perform timeout comparison analysis on the overall callback process of the system, calculate the timeout deviation value of each node, and determine the system callback timeout threshold by averaging and extreme value comparison to obtain callback timeout data.
[0015] In this embodiment of the invention, based on message queue transmission delay data, each callback operation is analyzed and identified. The position of each callback node in asynchronous communication, the function called, and its response relationship with other nodes are extracted sequentially. The execution order of nodes is identified by comparing interface call logs and timestamps between nodes. Simultaneously, a unique identifier is assigned to each callback node to establish a detailed node response path table. This table records the call order of each node and its dependencies with other nodes, ultimately forming complete callback node path data. Next, this callback node path data is used for response cycle sampling analysis. Specifically, multiple task scheduling simulations are performed in different asynchronous communication instances, recording the response time of each callback node. The time record includes the time interval from the request trigger time to the response completion time. By statistically analyzing the collected data from multiple times, the node response cycle difference is calculated. This difference reflects the variability of the node's response time in different instances, and this data is integrated and stored as callback node response cycle data. Then, based on the above response cycle data, the waiting time of each node is calculated. The waiting time is defined as the time difference between the start of the response time of the current node and the completion of the response of its predecessor node in a node chain. This calculation yields the waiting period for each node. This step aims to reveal the cyclical relationship between responses to assess the transaction dependencies and timeliness between nodes. Finally, combining the obtained callback node response period data and node waiting period data, a series of timeout analyses are performed. In the timeout analysis, the actual response data of the nodes is compared with a preset time baseline to identify which nodes have exceeded the set normal time range, and the timeout deviation values of these nodes are collected. Furthermore, the response times of all nodes are averaged and extreme values are compared to find the maximum, minimum, and median deviation values. A global system callback timeout threshold is then determined, and the callback timeout data is finally output.
[0016] It should be added that step S16 includes: Step S161: Perform time series synchronization processing on message queue transmission delay data and callback timeout data, unify the time base and sampling interval of each data, establish a delay-callback correspondence table, and obtain delay-callback matching data; Step S162: Based on the delayed callback matching data, perform joint difference calculation on the message queue delay fluctuation amplitude and callback timeout deviation within the same time window to obtain the joint communication delay fluctuation data; Step S163: Perform fluctuation frequency trend analysis on the joint fluctuation data of communication delay, identify periodic and non-periodic fluctuation characteristics, calculate the fluctuation synchronization rate between different communication nodes, and obtain node fluctuation synchronization rate data; Step S164: Based on the node fluctuation synchronization rate data, compare the deviation of the joint fluctuation characteristics of each communication node, identify the asynchronous fluctuation segment caused by network jitter, extract the abnormal fluctuation amplitude range, and obtain network jitter deviation data. Step S165: Based on network jitter deviation data and communication delay joint fluctuation data, comprehensively evaluate the fluctuation amplitude, duration and frequency of the overall communication link, calculate the network jitter intensity index, and output network jitter evaluation data.
[0017] In this embodiment of the invention, message queue transmission delay data and callback timeout time data are synchronized using time series processing. This unifies the time base of these two types of data and aligns their sampling intervals, establishing a correspondence table between delay and callback. This processing makes time matching more accurate, forming delay-callback matching data. Next, based on the delay-callback matching data, a joint difference calculation is performed on the message queue delay and callback timeout deviations within the same time window. Specifically, within the same time window, the difference between each delay and callback timeout is calculated sequentially, forming a delay difference sequence within the time period, thus obtaining joint communication delay fluctuation data. Subsequently, based on the joint communication delay fluctuation data, fluctuation frequency trend analysis is performed. This analysis extracts periodic fluctuations by statistically analyzing the number and magnitude of data fluctuations. During the calculation process, the focus is on identifying periodic and non-periodic fluctuation characteristics. After the analysis, the fluctuation synchronization rate between different communication nodes is calculated, thus obtaining node fluctuation synchronization rate data. Based on this data, by comparing the joint fluctuation characteristics of each node, asynchronous fluctuation segments caused by network jitter are identified. This entire process revolves around correlation analysis, comparing the fluctuations of each node with those of other nodes to identify asynchronous phenomena and extract the amplitude range of abnormal fluctuations. The result generated in this process is the network jitter deviation data. Finally, based on the network jitter deviation data and the joint fluctuation data of communication delay, a comprehensive assessment of the fluctuation amplitude, duration, and frequency of the overall communication link is conducted. The mean and dispersion of each indicator are calculated through data integration, thereby generating a network jitter intensity index and outputting the final network jitter assessment data.
[0018] It should be added that step S17 includes: Step S171: Based on message queue transmission delay data, callback timeout data and network jitter assessment data, align and synchronize the time intervals of each data source, unify the time scale and sampling frequency, and obtain delay feature synchronization data. Step S172: Perform node-by-node delay aggregation calculation on the delay feature synchronization data, and calculate the average delay, maximum delay and minimum delay of each communication node to obtain node delay aggregation data; Step S173: Based on the node latency aggregation data, dynamically compare the latency differences between nodes, calculate the latency deviation value between different nodes, and combine the network jitter evaluation data to correct the deviation fluctuations to obtain the latency deviation correction data. Step S174: Based on the delay deviation correction data and callback timeout data, perform fitting analysis on the delay distribution characteristics of the overall asynchronous communication process, identify the delay change trend and high delay interval, and obtain asynchronous communication delay distribution data; Step S175: Based on asynchronous communication delay distribution data, node delay aggregation data, and network jitter evaluation data, perform comprehensive calculations on the overall delay characteristics of the system, determine the average delay, stability coefficient, and fluctuation range of the communication process, and output communication delay characteristic data.
[0019] In this embodiment of the invention, message queue transmission delay data, callback timeout data, and network jitter assessment data are synchronized to form consistent delay characteristic synchronization data based on a unified time interval and sampling frequency. This step aligns the time dimensions of each data source, enabling subsequent analysis of delay characteristics to be logically correlated on the same time scale. Next, node-by-node delay aggregation calculations are performed on the delay characteristic synchronization data, including calculating the average, maximum, and minimum delays of each communication node, to obtain node delay aggregation data, thereby revealing the delay characteristics of each node in more dimensions. Based on this, a comparative analysis of delay differences between nodes is performed, comparing the delay situations of different nodes in the node delay aggregation data pairwise to calculate the delay deviation value between nodes. Then, based on this data and callback timeout data, the delay distribution characteristics in the asynchronous communication process are identified through fitting analysis. This step uses complex data fitting techniques to analyze the overall asynchronous communication delay change trend, especially identifying high-latency intervals, forming asynchronous communication delay distribution data. In the final stage, based on the results of all preliminary steps, including asynchronous communication delay distribution data, node delay aggregation data, and network jitter assessment data, the overall delay characteristics of the system are comprehensively calculated. This process calculates the average delay, stability coefficient, and fluctuation range during communication, thereby outputting comprehensive communication delay characteristic data.
[0020] Step S2: Identify transaction status consistency risks based on communication delay feature data. Generate consistency risk index data by calculating the time series deviation and status matching degree between payment status and reconciliation status. Mine historical abnormal patterns based on consistency risk index data. Use clustering algorithm to classify historical abnormal transaction records into patterns to obtain historical abnormal pattern data.
[0021] For example, step S2 includes: Step S21: Based on communication delay feature data, perform correlation matching between payment status data and reconciliation status data, establish a transaction status matching relationship table, and extract the time series information of the matching transaction pairs to obtain transaction status time series data; Step S22: Calculate the time deviation of the transaction status time series data. The difference between the payment status time and the corresponding cancellation status time is taken as the time series deviation. The data is statistically analyzed according to the transaction identifier to obtain the transaction time series deviation data. Step S23: Based on the transaction time series deviation data, perform a matching degree analysis on the payment status and the reconciliation status. Define the matching degree as the proportion of the transaction time series deviation within a preset threshold range to obtain the transaction status matching degree data. Step S24: Based on the transaction time series deviation data and transaction status matching data, conduct a consistency risk assessment on the overall transaction record, calculate the joint risk weight of delay deviation and matching degree, and obtain consistency risk index data; Step S25: Based on the consistency risk indicator data, perform abnormal sample screening on historical transaction records, extract transaction records whose risk indicators exceed the set threshold, and obtain historical abnormal transaction data; Step S26: Extract pattern features from historical abnormal transaction data, including the time distribution features, state change features, and delay fluctuation features of abnormal transactions, to obtain abnormal pattern feature data; Step S27: Based on the anomaly pattern feature data, use cluster analysis to classify the historical anomaly transaction data into patterns to obtain historical anomaly pattern data.
[0022] In this embodiment of the invention, payment status data and reconciliation status data are correlated and matched using communication delay feature data. Payment and reconciliation information for the same transaction are aggregated using a unique transaction identifier to generate a transaction status matching table. Then, timestamp information is extracted from each matching pair to form transaction status time series data. Subsequently, based on the time series data, the difference between the payment and reconciliation times for each transaction is calculated. The time series deviation data is obtained by subtracting the reconciliation time from the payment completion time, and the deviations are aggregated and statistically analyzed by transaction identifier. Based on these deviation data, a matching degree analysis is performed, where the matching degree is defined as the proportion of time series deviations falling within a preset allowable range, resulting in transaction status matching degree data. Next, a consistency risk assessment is performed on the entire transaction dataset by combining the transaction time series deviation and the matching degree. The joint risk weight is calculated using a hybrid model of delay deviation and matching degree, generating consistency risk index data. Further, based on this risk data, abnormal transaction records exceeding a set risk threshold are filtered out to form a historical abnormal transaction dataset. On these abnormal data, for each transaction record, features such as time distribution, state transition, and delay fluctuations are extracted to comprehensively generate abnormal pattern feature data. Finally, cluster analysis was used to classify the abnormal pattern features. Similar abnormal features were grouped into one category by similarity index, thus obtaining historical abnormal pattern data.
[0023] It should be added that step S24 includes the following steps: Step S241: Based on the transaction time series deviation data, perform fluctuation trend analysis on the time deviation of each transaction record, calculate the direction of change and fluctuation amplitude of the transaction deviation in different time periods, and obtain the transaction time deviation fluctuation trend data. Step S242: Based on the transaction time deviation fluctuation trend data, perform coupling analysis on the transaction status matching degree data, compare the time deviation fluctuation with the matching degree change, identify the degree of influence of time deviation on status matching degree, and obtain deviation matching coupling data. Step S243: Based on the deviation matching coupling data, calculate the correlation strength between delay deviation and matching degree in the transaction record, and use the ratio of the deviation change magnitude to the matching degree decrease magnitude as the joint weight reference to obtain the delay matching joint weight data; Step S244: Normalize the delayed matching joint weight data, unify the weight dimensions between different transaction records, and calculate the risk distribution range of each transaction sample to obtain risk weight normalized data. Step S245: Based on risk weight normalized data and deviation matching coupled data, conduct a comprehensive assessment of consistency risk of the overall transaction records, calculate the joint risk contribution value of delay deviation and matching degree at the system level, and output consistency risk indicator data.
[0024] In this embodiment of the invention, trend calculations are performed on the deviation values of each transaction record over different time periods to capture the direction and magnitude of deviation fluctuations, thus obtaining transaction time deviation fluctuation trend data. Next, based on this trend data, it is coupled with transaction status matching data for analysis. Specifically, time deviation fluctuations are compared and mapped with changes in matching degree to identify the specific impact of time deviation fluctuations on matching degree, forming deviation matching coupling data. This is a crucial stage in understanding the impact of time factors on matching reliability. Then, based on the deviation matching coupling data, the correlation strength between delay deviation and matching degree in the transaction record is calculated. This step uses the ratio between the magnitude of deviation change and the magnitude of matching degree decrease as a joint weight reference to generate delay matching joint weight data, thereby reflecting the impact of weights on matching effectiveness across multiple dimensions. Next, the delay matching joint weight data is normalized to unify the weight dimensions of different transaction records, ensuring consistency and comparability. Simultaneously, the risk distribution range of each transaction sample is calculated, generating risk weight normalized data. This data is used to label the potential impact of individual risks. Finally, by combining risk-weighted normalized data and deviation-matching coupled data, a comprehensive assessment of consistency risk is conducted on all transaction records. In this step, the joint risk contribution value of system-level latency deviation and matching degree is calculated and used as the output consistency risk indicator data.
[0025] It should be added that step S26 includes the following steps: The time distribution statistics of historical abnormal transaction data are analyzed to calculate the frequency and concentration of abnormal transactions in different time periods, thereby obtaining abnormal transaction time distribution characteristic data. Based on the abnormal transaction time distribution characteristic data, the status change records of abnormal transactions are analyzed to extract the change sequence and its transition frequency between payment status and write-off status, thereby obtaining abnormal status change characteristic data. Based on the abnormal state change characteristic data, the trend analysis of the delay fluctuation of abnormal transactions in the communication link is carried out, the delay change range and fluctuation period of abnormal transactions among multiple nodes are calculated, and the abnormal delay fluctuation characteristic data is obtained. Based on the time distribution characteristics of abnormal transactions, the change characteristics of abnormal states, and the fluctuation characteristics of abnormal delays, the multidimensional characteristics of abnormal transactions are integrated and modeled. The joint feature weights of time, state, and delay are extracted, and the abnormal pattern characteristic data are output.
[0026] In this embodiment of the invention, by performing time distribution statistics on historical abnormal transaction data and establishing a time-dimensional frequency statistical model, the frequency and concentration of abnormal transactions within daily, weekly, and other time periods are analyzed to obtain abnormal transaction time distribution characteristic data. Next, based on this time distribution characteristic data, the state change records of abnormal transactions are analyzed in depth to extract the change sequence between payment and reconciliation states in abnormal transactions, and the frequency of these state transitions is calculated to obtain abnormal state change characteristic data. Subsequently, the abnormal state change characteristic data is used to analyze the delay fluctuation trend of abnormal transactions, including capturing the delay change range and fluctuation cycle of abnormal transactions across multiple nodes. Using delay measurement tools, the delay gain and loss of abnormal transactions between various communication nodes are recorded and calculated to obtain abnormal delay fluctuation characteristic data. In the final step, all analysis results—abnormal transaction time distribution characteristic data, abnormal state change characteristic data, and abnormal delay fluctuation characteristic data—are integrated to construct a multi-dimensional characteristic model of abnormal transactions. In this model, by calculating the joint weights of time, state, and delay features, the patterns of abnormal transactions can be described and predicted more accurately, ultimately outputting abnormal pattern characteristic data.
[0027] Step S3: Train the AI prediction model based on historical anomaly pattern data, construct the transaction consistency risk prediction model using machine learning algorithms, and extract risk feature vectors through feature engineering to obtain the transaction consistency risk prediction model; use the transaction consistency risk prediction model to predict the risk of real-time transaction data, output the risk probability, risk type and risk time window, and obtain the risk prediction result.
[0028] For example, step S3 includes: Based on historical abnormal pattern data, transaction records are sampled and data are stratified to extract normal transaction samples and abnormal transaction samples respectively, and training sample sets and validation sample sets are established to obtain stratified sample data. Feature engineering is performed on the stratified sample data to extract multi-dimensional risk feature parameters such as transaction delay features, state matching features, and time deviation features. The feature parameters are then normalized and encoded to obtain risk feature vector data. Based on risk feature vector data, machine learning algorithms are used to model and train transaction consistency risk. The model parameters are optimized through sample iteration and error correction to obtain a transaction consistency risk prediction model. The performance of the transaction consistency risk prediction model is validated by calculating the model's prediction accuracy, recall, and stability indicators. The model output results are compared and evaluated with historical actual risk results to obtain model validation data. Based on model validation data, the parameters of the transaction consistency risk prediction model are adjusted and optimized to determine the final stable model version that can be used for real-time prediction, and the final transaction consistency risk prediction model is output. The risk prediction model for final transaction consistency is used to predict the risk of real-time transaction data. The risk feature vector of the input transaction flow is classified and calculated, and the risk probability, risk type and risk time window are output to obtain the risk prediction result.
[0029] In this embodiment of the invention, transaction records are sampled and stratified based on historical abnormal pattern data. First, a sample screening threshold is set to remove invalid records. Then, normal transaction samples and abnormal transaction samples are extracted according to historical abnormal markers, where 0 represents normal transactions and 1 represents abnormal transactions. Subsequently, a stratified sampling method is used to divide the normal transaction samples and abnormal transaction samples into training samples and validation samples in a ratio of 8:2, thereby establishing a training sample set and a validation sample set to obtain stratified sample data. When performing feature engineering on the stratified sample data, multidimensional risk feature parameters are first extracted. Among them, the transaction delay feature is obtained by calculating the difference between the actual completion time of each transaction and the preset standard completion time of the same type of transaction. The state matching feature is obtained by comparing the actual state identifier of each node of the transaction with the preset normal state flow sequence, and counting the number of nodes with mismatched states and the duration of each mismatched node. The time deviation feature is obtained by calculating the difference between each key time point of the transaction and the average time point of the corresponding time point of the same type of transaction in the same period. After extracting the above features, the min-max normalization method is used to process the feature parameters. That is, each feature parameter value is subtracted from the minimum value of the feature in the training sample set, and then divided by the difference between the maximum and minimum values of the feature, so that the feature value is mapped to the interval [0,1]. One-hot encoding is used to convert the classification features such as transaction type and transaction channel into a binary vector. For example, when the transaction type includes "transfer", "consumption" and "financial management", "transfer" corresponds to the encoding [1,0,0]. Finally, the combined processed features are used to obtain the risk feature vector data. Based on risk feature vector data, a gradient boosting tree machine learning algorithm is used to model and train the transaction consistency risk. The risk feature vector in the training sample set is used as the model input, and the corresponding historical anomaly labels are used as the output labels. The model parameters are initialized, and then the parameters are optimized through iterative training. In each iteration, the prediction error of the current model on the training samples is calculated first, that is, the difference between the predicted label and the actual anomaly label. The weights of each decision tree are adjusted according to the error magnitude. The weights of the decision trees corresponding to samples with large errors are increased, and the weights of samples with small errors are decreased. The split node threshold of the model is also updated. After each iteration, the prediction error is calculated using the validation sample set. When the error no longer decreases after 5 consecutive iterations or reaches the preset number of iterations, the training is stopped, and the transaction consistency risk prediction model is obtained. When validating the model's performance, the prediction accuracy is calculated by dividing the number of samples in the validation sample set whose predicted results match the actual anomaly labels by the total number of samples in the validation sample set. The recall is calculated by dividing the number of samples correctly predicted as anomalies by the total number of samples that are actually anomalies in the validation sample set. When calculating the stability index, the validation sample set is divided into 5 consecutive subsets according to the time series. The accuracy and recall of each subset are calculated separately. First, the average of these indices is calculated. Then, the difference between each indices and the average is calculated. The square of the difference is then averaged to obtain the variance. The square root of the variance is used to obtain the standard deviation. Finally, the standard deviation is divided by the average to obtain the coefficient of variation. The smaller the coefficient of variation, the better the stability. Subsequently, the risk probability of each sample output by the model is compared with the historical actual risk results. The proportion of actual anomalies among samples with risk probabilities higher than a preset threshold, and the proportion of actual anomaly samples with risk probabilities higher than the threshold are statistically analyzed to obtain the model validation data. Based on the model validation data, if the accuracy is below 90%, the recall is below 85%, or the coefficient of variation of the stability index is greater than 0.1, the model parameters are adjusted. After each adjustment, the model is retrained and validated. This process is repeated until all the model indicators meet the standards, the final stable model version is determined, and the final transaction consistency risk prediction model is output. When using this final model to predict risks in real-time transaction data, the latency, state matching, and time deviation features of real-time transactions are first extracted according to the aforementioned feature engineering process. After normalization and encoding conversion, a real-time risk feature vector is obtained. After inputting this vector into the model, the model multiplies each feature value in the real-time feature vector by the corresponding weight coefficient and sums them. Then, it is mapped by the sigmoid function to obtain the risk probability. The risk type is classified according to the risk probability. At the same time, combined with the time pattern of historical high-risk transactions, the risk time window of the real-time transaction is output, and finally the risk prediction result is obtained.
[0030] It should be added that the detailed steps for obtaining risk prediction results are as follows: Based on the final transaction consistency risk prediction model, real-time transaction data is input parsed to extract transaction identifiers, timestamps, payment status and reconciliation status information from real-time transactions, and real-time risk feature input vectors are generated according to the format required by the model to obtain real-time risk feature data. Perform feature matching and vector mapping on real-time risk feature data, and process the real-time feature vectors to be consistent with the risk feature space during model training, so that the dimensions of real-time data correspond to the dimensions of model features, and obtain standardized feature vector data. Based on standardized feature vector data, the final transaction consistency risk prediction model is invoked to perform inference calculations, outputting the risk probability value of each transaction and the corresponding risk classification result, thus obtaining preliminary risk classification data. Based on the preliminary risk classification data, threshold comparison and confidence interval analysis are performed on the risk probability values to identify the distribution range of high-risk and medium-to-low-risk transaction samples, thereby obtaining risk grading data. Based on risk classification data and real-time transaction time information, the prediction results are mapped to time windows to analyze the possible time periods and durations of risk events, thereby obtaining risk time window data. Based on risk classification data and risk time window data, the overall risk prediction results of the transaction flow are comprehensively summarized, and the final risk prediction results including risk probability, risk type and risk time window are output.
[0031] Step S4: Generate an intelligent compensation strategy based on the risk prediction results. Generate an adaptive compensation strategy based on the risk type, risk probability and historical compensation effect data to obtain compensation strategy data. Execute automatic compensation operation based on the compensation strategy data. Call the payment system rollback interface through API and verify the transaction consistency status after compensation. Confirm the self-healing effect through status consistency check.
[0032] For example, step S4 includes: Step S41: Based on the risk prediction results, perform feature analysis on the risk type, risk probability and risk time window of the prediction output, identify high-risk transaction samples and their associated risk triggering conditions, and obtain risk event identification data; Step S42: Based on risk event identification data and historical compensation effect data, perform matching analysis on compensation schemes under different risk types, evaluate the compensation success rate and execution delay of each scheme in similar risk scenarios, and obtain compensation scheme matching data; Step S43: Based on the compensation scheme matching data, perform a weighted calculation on the risk probability and the compensation success rate, prioritize matching high-probability, high-impact risk events with compensation schemes that have a high success rate, and generate preliminary adaptive compensation strategy data; Step S44: Perform an execution feasibility analysis on the preliminary adaptive compensation strategy data, and combine the current resource status of the system and interface availability to filter and dynamically adjust the compensation strategy to obtain the final compensation strategy data; Step S45: Based on the final compensation strategy data, execute the automatic compensation operation by calling the payment system rollback interface through the API, monitor the execution status of the rollback operation and the system response time in real time, and obtain the automatic compensation execution data; Step S46: Perform transaction consistency verification on the automatic compensation execution data, analyze the synchronization between the payment status and the write-off status after compensation, compare the status deviation before and after compensation, and obtain compensation consistency verification data. Step S47: Based on the compensation consistency verification data, evaluate the self-healing effect of the overall consistency status after transaction compensation, calculate the self-healing success rate and the remaining deviation ratio, and output the final self-healing effect data.
[0033] For example, based on the risk prediction results, feature analysis is performed. First, a high-risk judgment standard is set, that is, the risk probability is ≥0.8 and the risk type is marked as "high risk". Based on this, high-risk transaction samples are screened out. Then, for each high-risk sample, its risk triggering conditions are analyzed, such as whether the transaction delay of the sample exceeds twice the average delay of the same type of transaction, transaction delay = actual completion time - average completion time of the same type of transaction, whether the number of mismatched nodes between the status of each node of the transaction and the preset normal flow sequence is ≥2, and the frequency of these triggering conditions in high-risk samples is counted. The high-risk transaction sample ID, the corresponding risk triggering conditions and the triggering frequency are sorted and summarized to obtain risk event identification data. Based on risk event identification data and historical compensation effect data, which includes compensation schemes, number of successful compensations, total number of compensations, and execution time difference for each compensation over the past two years for different risk types, we first match all compensation schemes for the same risk type in the historical data according to the risk type in the risk event identification data. Then, for each matched compensation scheme, we filter the compensation records in the history that are similar to the current risk scenario and calculate the compensation success rate of the scheme in similar scenarios. The compensation success rate = number of successful compensations ÷ total number of compensations. At the same time, we calculate the execution delay of the scheme and organize the correspondence between each risk type and the corresponding compensation scheme, compensation success rate, and execution delay to obtain compensation scheme matching data. Based on the compensation scheme matching data, we first set the risk probability weight to 0.6 and the compensation success rate weight to 0.4. For each high-risk event, we calculate the weighted score of its risk probability and the corresponding compensation scheme success rate (weighted score = risk probability × 0.6 + compensation success rate × 0.4). Then, combined with the degree of risk impact, we set transaction amounts ≥ 10,000 yuan as high impact, 5,000-10,000 yuan as medium impact, and < 5,000 yuan as low impact. We prioritize matching high-probability, high-impact risk events with high-success-rate compensation schemes that have a weighted score ≥ 0.8 and a compensation success rate ≥ 90%. For example, if a high-risk event has a risk probability of 0.92 and a high degree of impact, and is matched with a scheme with a compensation success rate of 93%, its weighted score = 0.92 × 0.6 + 0.93 × 0.4 = 0.924, which meets the priority matching condition. Based on this, we generate preliminary adaptive compensation strategy data. A feasibility analysis is performed on the preliminary adaptive compensation strategy data. First, the current resource status of the system is obtained, including CPU utilization, memory usage, interface availability, and preset resource thresholds. For each compensation scheme in the preliminary strategy, it is determined whether the resources required to execute the scheme are within the range of currently available resources. If the current CPU utilization is 76% and memory usage is 73%, the scheme is not feasible and the scheme is adjusted. At the same time, the real-time availability of the payment rollback interface and status synchronization interface on which the compensation scheme depends is checked. If the availability of a certain interface is 92% < 95%, the scheme that depends on the interface is excluded. After screening and adjustment, the final compensation strategy data is obtained. Based on the final compensation strategy data, API call parameters are generated according to the scheme type. The payment system rollback interface is called to execute the automatic compensation operation. The execution status returned by the interface is monitored in real time, and the system response time is recorded every n seconds. The transaction ID, compensation scheme type, execution status, and response time sequence are organized into automatic compensation execution data. Transaction consistency verification is performed on the automatic compensation execution data. First, the payment status and reconciliation status of the transaction after compensation are obtained, and the synchronization status is compared. The number of synchronized transactions is counted, and the synchronization rate is calculated as: Synchronization rate = Number of synchronized transactions ÷ Total number of compensation transactions. At the same time, the state deviation before and after compensation is calculated as: Number of nodes with mismatched state before compensation - Number of nodes with mismatched state after compensation. The change in state deviation for each transaction is obtained. The synchronization rate and the change in deviation for each transaction are organized into compensation consistency verification data. Based on the compensation consistency verification data, the self-healing success rate is calculated as: Number of transactions with completely synchronized state after compensation and a deviation of 0 ÷ Total number of compensation transactions. The remaining deviation ratio is calculated as: Number of transactions with deviations after compensation and a deviation > 0 ÷ Total number of compensation transactions. The self-healing success rate, the remaining deviation ratio, and the corresponding transaction details are integrated to output the final self-healing effect data.
[0034] 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.
[0035] It should be understood that determining B based on A does not mean determining B solely based on A; it also means determining B based on A and / or other information.
[0036] 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.
[0037] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A method for integrating rights transaction verification and payment in the context of One-Code-Payment, characterized in that, The method includes: Step S1: Asynchronously obtain payment transaction data and rights verification data from the payment system and rights verification system through the data interface, and perform data cleaning and normalization on the payment transaction data and rights verification data to obtain transaction verification status data; perform asynchronous communication delay analysis on the transaction verification status data, including message queue transmission delay, callback timeout calculation and network jitter assessment, to obtain communication delay characteristic data. Step S2: Identify transaction status consistency risks based on communication delay feature data. Generate consistency risk index data by calculating the time series deviation and status matching degree between payment status and reconciliation status. Mine historical abnormal patterns based on consistency risk index data. Use clustering algorithm to classify historical abnormal transaction records into patterns to obtain historical abnormal pattern data. Step S3: Train the AI prediction model based on historical anomaly pattern data, construct the transaction consistency risk prediction model using machine learning algorithms, and extract risk feature vectors through feature engineering to obtain the transaction consistency risk prediction model; use the transaction consistency risk prediction model to predict the risk of real-time transaction data, and output the risk probability, risk type and risk time window to obtain the risk prediction result. Step S4: Generate an intelligent compensation strategy based on the risk prediction results. Generate an adaptive compensation strategy based on the risk type, risk probability and historical compensation effect data to obtain compensation strategy data. Execute automatic compensation operation based on the compensation strategy data. Call the payment system rollback interface through API and verify the transaction consistency status after compensation. Confirm the self-healing effect through status consistency check.
2. The method for integrating rights transaction verification and payment in the "One-Code Benefit Payment" scenario according to claim 1, characterized in that, Step S1 includes: Step S11: Asynchronously obtain payment transaction data from the payment system through the data interface, and asynchronously obtain rights verification data from the rights verification system. Timestamp and request source identifier are recorded on the obtained data to obtain the original transaction dataset and the original verification dataset. Step S12: Perform format validation and field matching analysis on the original transaction dataset and the original reconciliation dataset, complete missing fields, and remove or correct abnormal data to obtain formatted transaction data and formatted reconciliation data. Step S13: Based on the formatted transaction data and formatted reconciliation data, merge and match data with the same transaction identifier field, and normalize the data according to the order of transaction time and reconciliation time to obtain transaction reconciliation status data. Step S14: Analyze the asynchronous communication process of the transaction reconciliation status data, identify the message queue transmission path and call link, sample and calculate the transmission time of different link nodes, and obtain the message queue transmission delay data. Step S15: Based on the message queue transmission delay data, calculate the timeout time for the system callback process, analyze the response cycle and waiting cycle of different callback nodes, and obtain the callback timeout time data; Step S16: Perform joint fluctuation analysis on message queue transmission delay data and callback timeout time data to identify the delay fluctuation characteristics caused by network jitter during communication and obtain network jitter assessment data; Step S17: Based on message queue transmission delay data, callback timeout data, and network jitter assessment data, perform a comprehensive calculation of the overall latency characteristics of asynchronous communication and output communication latency characteristic data.
3. The method for integrating rights transaction verification and payment in the "One-Code Benefit" payment scenario according to claim 2, characterized in that, Step S15 includes: Step S151: Based on the message queue transmission delay data, identify each callback node in the system callback process, establish a node response path table, determine the calling order and dependency relationship of each callback node, and obtain the callback node path data. Step S152: Perform response cycle sampling analysis on the callback node path data, collect the actual response time and request trigger time of each callback node in multiple asynchronous communications, calculate the node response cycle difference, and obtain the callback node response cycle data. Step S153: Based on the callback node response cycle data, calculate the waiting time of each node, and define the node waiting time as the difference between the completion time of the previous node and the response start time of the current node to obtain the callback node waiting cycle data. Step S154: Based on the callback node response cycle data and callback node waiting cycle data, perform timeout comparison analysis on the overall callback process of the system, calculate the timeout deviation value of each node, and determine the system callback timeout threshold by averaging and extreme value comparison to obtain callback timeout data.
4. The method for integrating rights transaction verification and payment in the "One-Code Benefit" payment scenario according to claim 2, characterized in that, Step S16 includes: Step S161: Perform time series synchronization processing on message queue transmission delay data and callback timeout data, unify the time base and sampling interval of each data, establish a delay-callback correspondence table, and obtain delay-callback matching data; Step S162: Based on the delayed callback matching data, perform joint difference calculation on the message queue delay fluctuation amplitude and callback timeout deviation within the same time window to obtain the joint communication delay fluctuation data; Step S163: Perform fluctuation frequency trend analysis on the joint fluctuation data of communication delay, identify periodic and non-periodic fluctuation characteristics, calculate the fluctuation synchronization rate between different communication nodes, and obtain node fluctuation synchronization rate data; Step S164: Based on the node fluctuation synchronization rate data, compare the deviation of the joint fluctuation characteristics of each communication node, identify the asynchronous fluctuation segment caused by network jitter, extract the abnormal fluctuation amplitude range, and obtain network jitter deviation data. Step S165: Based on network jitter deviation data and communication delay joint fluctuation data, comprehensively evaluate the fluctuation amplitude, duration and frequency of the overall communication link, calculate the network jitter intensity index, and output network jitter evaluation data.
5. The method for integrating rights transaction verification and payment in the One-Code-for-Payment scenario according to claim 4, characterized in that, Step S2 includes: Step S21: Based on communication delay feature data, perform correlation matching between payment status data and reconciliation status data, establish a transaction status matching relationship table, and extract the time series information of the matching transaction pairs to obtain transaction status time series data; Step S22: Calculate the time deviation of the transaction status time series data. The difference between the payment status time and the corresponding cancellation status time is taken as the time series deviation. The data is statistically analyzed according to the transaction identifier to obtain the transaction time series deviation data. Step S23: Based on the transaction time series deviation data, perform a matching degree analysis on the payment status and the reconciliation status. Define the matching degree as the proportion of the transaction time series deviation within a preset threshold range to obtain the transaction status matching degree data. Step S24: Based on the transaction time series deviation data and transaction status matching data, conduct a consistency risk assessment on the overall transaction record, calculate the joint risk weight of delay deviation and matching degree, and obtain consistency risk index data; Step S25: Based on the consistency risk indicator data, perform abnormal sample screening on historical transaction records, extract transaction records whose risk indicators exceed the set threshold, and obtain historical abnormal transaction data; Step S26: Extract pattern features from historical abnormal transaction data, including the time distribution features, state change features, and delay fluctuation features of abnormal transactions, to obtain abnormal pattern feature data; Step S27: Based on the anomaly pattern feature data, use cluster analysis to classify the historical anomaly transaction data into patterns to obtain historical anomaly pattern data.
6. The method for integrating rights transaction verification and payment in the One-Code-for-Payment scenario according to claim 5, characterized in that, Step S24 includes the following steps: Step S241: Based on the transaction time series deviation data, perform fluctuation trend analysis on the time deviation of each transaction record, calculate the direction of change and fluctuation amplitude of the transaction deviation in different time periods, and obtain the transaction time deviation fluctuation trend data. Step S242: Based on the transaction time deviation fluctuation trend data, perform coupling analysis on the transaction status matching degree data, compare the time deviation fluctuation with the matching degree change, identify the degree of influence of time deviation on status matching degree, and obtain deviation matching coupling data. Step S243: Based on the deviation matching coupling data, calculate the correlation strength between delay deviation and matching degree in the transaction record, and use the ratio of the deviation change magnitude to the matching degree decrease magnitude as the joint weight reference to obtain the delay matching joint weight data; Step S244: Normalize the delayed matching joint weight data, unify the weight dimensions between different transaction records, and calculate the risk distribution range of each transaction sample to obtain risk weight normalized data. Step S245: Based on risk weight normalized data and deviation matching coupled data, conduct a comprehensive assessment of consistency risk of the overall transaction records, calculate the joint risk contribution value of delay deviation and matching degree at the system level, and output consistency risk indicator data.
7. The method for integrating rights transaction verification and payment in the One-Code-for-Payment scenario according to claim 5, characterized in that, Step S26 includes the following steps: The time distribution statistics of historical abnormal transaction data are analyzed to calculate the frequency and concentration of abnormal transactions in different time periods, thereby obtaining abnormal transaction time distribution characteristic data. Based on the abnormal transaction time distribution characteristic data, the status change records of abnormal transactions are analyzed to extract the change sequence and its transition frequency between payment status and write-off status, thereby obtaining abnormal status change characteristic data. Based on the abnormal state change characteristic data, the trend analysis of the delay fluctuation of abnormal transactions in the communication link is carried out, the delay change range and fluctuation period of abnormal transactions among multiple nodes are calculated, and the abnormal delay fluctuation characteristic data is obtained. Based on the time distribution characteristics of abnormal transactions, the change characteristics of abnormal states, and the fluctuation characteristics of abnormal delays, the multidimensional characteristics of abnormal transactions are integrated and modeled. The joint feature weights of time, state, and delay are extracted, and the abnormal pattern characteristic data are output.
8. The method for integrating rights transaction verification and payment in the "One-Code Benefit" payment scenario according to claim 1, characterized in that, Step S3 includes: Based on historical abnormal pattern data, transaction records are sampled and data are stratified to extract normal transaction samples and abnormal transaction samples respectively, and training sample sets and validation sample sets are established to obtain stratified sample data. Feature engineering is performed on the stratified sample data to extract multi-dimensional risk feature parameters such as transaction delay features, state matching features, and time deviation features. The feature parameters are then normalized and encoded to obtain risk feature vector data. Based on risk feature vector data, machine learning algorithms are used to model and train transaction consistency risk. The model parameters are optimized through sample iteration and error correction to obtain a transaction consistency risk prediction model. The performance of the transaction consistency risk prediction model is validated by calculating the model's prediction accuracy, recall, and stability indicators. The model output results are compared and evaluated with historical actual risk results to obtain model validation data. Based on model validation data, the parameters of the transaction consistency risk prediction model are adjusted and optimized to determine the final stable model version that can be used for real-time prediction, and the final transaction consistency risk prediction model is output. The risk prediction model for final transaction consistency is used to predict the risk of real-time transaction data. The risk feature vector of the input transaction flow is classified and calculated, and the risk probability, risk type and risk time window are output to obtain the risk prediction result.
9. The method for integrating rights transaction verification and payment in the One-Code-for-Payment scenario according to claim 8, characterized in that, The detailed steps for obtaining risk prediction results are as follows: Based on the final transaction consistency risk prediction model, real-time transaction data is input parsed to extract transaction identifiers, timestamps, payment status and reconciliation status information from real-time transactions, and real-time risk feature input vectors are generated according to the format required by the model to obtain real-time risk feature data. Perform feature matching and vector mapping on real-time risk feature data, and process the real-time feature vectors to be consistent with the risk feature space during model training, so that the dimensions of real-time data correspond to the dimensions of model features, and obtain standardized feature vector data. Based on standardized feature vector data, the final transaction consistency risk prediction model is invoked to perform inference calculations, outputting the risk probability value of each transaction and the corresponding risk classification result, thus obtaining preliminary risk classification data. Based on the preliminary risk classification data, threshold comparison and confidence interval analysis are performed on the risk probability values to identify the distribution range of high-risk and medium-to-low-risk transaction samples, thereby obtaining risk grading data. Based on risk classification data and real-time transaction time information, the prediction results are mapped to time windows to analyze the possible time periods and durations of risk events, thereby obtaining risk time window data. Based on risk classification data and risk time window data, the overall risk prediction results of the transaction flow are comprehensively summarized, and the final risk prediction results including risk probability, risk type and risk time window are output.
10. The method for integrating rights transaction verification and payment in the "One-Code Benefit" payment scenario according to claim 1, characterized in that, Step S4 includes: Step S41: Based on the risk prediction results, perform feature analysis on the risk type, risk probability and risk time window of the prediction output, identify high-risk transaction samples and their associated risk triggering conditions, and obtain risk event identification data; Step S42: Based on risk event identification data and historical compensation effect data, perform matching analysis on compensation schemes under different risk types, evaluate the compensation success rate and execution delay of each scheme in similar risk scenarios, and obtain compensation scheme matching data; Step S43: Based on the compensation scheme matching data, perform a weighted calculation on the risk probability and the compensation success rate, prioritize matching high-probability, high-impact risk events with compensation schemes that have a high success rate, and generate preliminary adaptive compensation strategy data; Step S44: Perform an execution feasibility analysis on the preliminary adaptive compensation strategy data, and combine the current resource status of the system and interface availability to filter and dynamically adjust the compensation strategy to obtain the final compensation strategy data; Step S45: Based on the final compensation strategy data, execute the automatic compensation operation by calling the payment system rollback interface through the API, monitor the execution status of the rollback operation and the system response time in real time, and obtain the automatic compensation execution data; Step S46: Perform transaction consistency verification on the automatic compensation execution data, analyze the synchronization between the payment status and the write-off status after compensation, compare the status deviation before and after compensation, and obtain compensation consistency verification data. Step S47: Based on the compensation consistency verification data, evaluate the self-healing effect of the overall consistency status after transaction compensation, calculate the self-healing success rate and the remaining deviation ratio, and output the final self-healing effect data.