A transaction management method and system for mutual trade

Abstract

The present invention discloses a transaction management method and system for barter trade, and specifically relates to the technical field of transaction management. First, the system records and analyzes the risk level of an order when an order is generated, ensuring that the information is uploaded to a platform in a timely manner. Then, the logistics system is connected to the platform in real time, and the logistics node status is automatically updated, so that the transaction parties can grasp the logistics progress at any time. At the same time, the smart contract sets payment conditions, realizes the automatic connection between payment and logistics status, and ensures that the payment is executed according to the conditions when the logistics status reaches the state of shipped or received. In addition, the system evaluates the real-time data synchronization by monitoring the logistics frequency and payment delay, and sends an early warning signal when the synchronization fails or is delayed, reminding the relevant parties to intervene in time, effectively solving the problem of information asynchrony, and improving the real-time data transmission across systems and the reliability of transaction management.

Description

Technical Field

[0001] The present invention relates to the technical field of transaction management, and in particular to a transaction management method and system for mutual trade. Background Art

[0002] Barter trade is a special form of trade in border areas, usually used to promote economic cooperation between border residents and merchants in neighboring countries. With policy support, this form of trade enables border residents to legally engage in import and export activities within a certain amount. The transaction management process of barter trade involves multiple participants and links, including border residents, processing enterprises, financial institutions, e-commerce platforms, etc. The participating parties achieve the connection of goods circulation, fund settlement and financial statements through complex operations.

[0003] In actual operation, border trade faces problems such as low management efficiency, complex processes, and difficulty in real-time sharing of cross-border information. Traditional management methods rely on manual review and manual accounting, which easily leads to information lags and inconsistencies. With the increase in the number of companies involved in border trade and the increase in transaction volume, these problems have brought great management and monitoring pressure.

[0004] The prior art has the following deficiencies:

[0005] In the process of border trade transactions, data from various links (such as order processing, logistics delivery, financial settlement, etc.) are often distributed in different systems. Since these systems lack a unified data interface and real-time sharing mechanism, information is delayed, missing or inconsistent during transmission. For example, if the logistics status is not updated in time, financial institutions may make advance or delayed payments based on outdated delivery information, resulting in capital retention or overpayment. At the same time, if the transaction information between border residents and processing companies is not synchronized, it is easy for goods to be shipped but funds to not be in place, increasing the risk of trade disputes. These information asynchrony issues not only affect transaction efficiency, but may also form blind spots in cross-border capital supervision. Summary of the invention

[0006] The purpose of the present invention is to provide a transaction management method and system for barter trade to solve the shortcomings of the background technology.

[0007] In order to achieve the above object, the present invention provides the following technical solution: a transaction management method for mutual trade, comprising the following steps:

[0008] S1: When a transaction party generates an order through an e-commerce platform, the system records the order information and generates a unique order number, analyzes historical transaction data, predicts the risk level of the order, and uploads the order information to a unified data management platform;

[0009] S2: After the order is confirmed, the logistics supplier's system is connected to the data management platform in real time to automatically update the logistics status information, including warehousing, outbound, cross-border transportation and arrival status, to ensure that all parties to the order are aware of the logistics progress in real time;

[0010] S3: Payment conditions are set through the smart contract mechanism. When the logistics status is updated to shipped, the smart contract automatically sends a payment trigger signal to the financial institution; when the logistics status is updated to received, the smart contract automatically executes the settlement operation to ensure that the payment is synchronized with the logistics status;

[0011] S4: Analyze the frequency of changes in logistics status and abnormal payment delays, evaluate the synchronization and real-time performance of data in the cross-border trade transaction process based on the analysis results, and send early warning signals when the synchronization and real-time performance is low to notify the transaction parties and financial institutions for timely intervention.

[0012] Preferably, in S1, the features of the new order are compared with the historical transaction data using a random forest model, and the risk level of the order is predicted based on the pre-trained model, specifically:

[0013] Collect historical transaction data from the database, standardize the data and divide it into training set and test set, select features related to order risk prediction, and define the parameters of the random forest model, including the number of trees, the maximum depth of the tree, the minimum number of split samples, and the minimum number of leaf node samples;

[0014] The training set is input into the random forest model for training. The model generates multiple decision trees based on the features and labels of each order. Each tree is trained with different combinations of samples and features.

[0015] For a newly generated order, extract the same features from the order and perform the same data standardization and encoding process;

[0016] Input the feature vector of the new order into the trained random forest model. Each decision tree in the model will make an independent prediction on the risk level of the order.

[0017] The random forest model uses a voting mechanism to determine the final prediction result. Each tree will give a risk level prediction, including low risk, medium risk and high risk.

[0018] The model will select the prediction results of the majority of decision trees as the final risk level; the model outputs the predicted risk level of the order and uploads the information together with the order to a unified data management platform.

[0019] Preferably, in S3, after a transaction order is generated, the order information and logistics status information are recorded through a smart contract, and payment conditions are set; wherein the smart contract includes state variables for automatically triggering payment and settlement, and defines the order number, transaction party identity, payment amount and triggering conditions; the smart contract is connected to the blockchain through the logistics supplier system to ensure real-time updates through the API interface when the logistics status changes; after the payment is triggered and the settlement is completed, the contract records the transaction status, timestamp and payment amount on the blockchain to form an unalterable audit record. If the logistics or payment status is abnormal, the contract will automatically roll back the transaction and trigger an abnormal alarm, notifying the transaction party and the financial institution for review.

[0020] Preferably, in S4, a logistics update frequency fluctuation index is generated based on the fluctuation of the logistics update time change frequency of each logistics node, and the method for obtaining the logistics update frequency fluctuation index is:

[0021] The frequency of status update of each logistics node in each time period is constructed into a time series, recorded as {f1, f2, ..., f n}, where f n Indicates the update frequency of the nth time period, selects an analysis window for quantile calculation, and sets the upper quantile to Q u and the lower quantile is Q l , based on the update frequency data {f1, f2, ..., f n}, calculate the upper quantile as Q u and the lower quantile is Q l , upper quantile: Q u =quantile(f,0.75); lower quantile: Q l =quantile(f, 0.25), calculate the interquartile range IQR, use the high quantile and low quantile to calculate the interquartile range, which is used to set the abnormal range. The expression is: IQR = Q u -Q l ; Determine the upper and lower limits of the abnormal threshold: upper limit = Q u +k·IQR; lower limit=Q u -k·IQR; where k is a constant. The update frequency that exceeds the upper and lower limits is taken as the abnormal update frequency. The abnormal update frequency of each time period is accumulated within the entire analysis time window to obtain the logistics update frequency fluctuation index.

[0022] Preferably, the payment delay frequency abnormality index is generated after analyzing the frequency of payment delay time in different time periods, and the method for obtaining the payment delay frequency abnormality index is:

[0023] Collect payment delay frequency data in each time period and construct it into time series data xt, where t represents the time point. Calculate the current payment delay frequency smoothing value, the expression is: S t =a·x t +(1-a)·S t-1 ; S t is the current payment delay frequency smoothing value, S t-1 The payment delay frequency smoothing value at the previous time point, α is the smoothing coefficient, and the initial payment delay frequency smoothing value is set to S0 to obtain the payment delay frequency smoothing benchmark value ES under normal conditions in historical data. t If the current payment delay frequency smoothing value is greater than the payment delay frequency smoothing benchmark value, it is regarded as an abnormal payment delay frequency smoothing value, and the standard deviation of all abnormal payment delay frequency smoothing values ​​is calculated, that is, the payment delay frequency abnormality index is calculated.

[0024] Preferably, the logistics update frequency fluctuation index and the payment delay frequency anomaly index are converted into feature vectors, and the feature vectors are used as inputs of the machine learning model. The machine learning model uses each group of feature vectors to predict the synchronization real-time value label of the data in the process of self-trade transactions as the prediction target, and takes minimizing the sum of prediction errors of the synchronization real-time value labels of all data in the process of self-trade transactions as the training target. The machine learning model is trained until the sum of prediction errors converges and the model training is stopped. The synchronization real-time value of the data in the process of self-trade transactions is determined according to the model output results, wherein the machine learning model is a polynomial regression model.

[0025] Preferably, the synchronization real-time value of the data obtained during the mutual trade transaction is compared with the synchronization real-time benchmark value preset under normal conditions in the historical data. If the synchronization real-time value of the data during the mutual trade transaction is greater than or equal to the synchronization real-time benchmark value preset under normal conditions in the historical data, it means that the synchronization real-time of the data during the mutual trade transaction is high. At this time, no warning signal is generated and no intervention is required. If the synchronization real-time value of the data during the mutual trade transaction is less than the synchronization real-time benchmark value preset under normal conditions in the historical data, it means that the synchronization real-time of the data during the mutual trade transaction is low. At this time, a warning signal is generated to notify the transaction parties and financial institutions to intervene in a timely manner.

[0026] The present invention also provides a transaction management system for barter trade, including an order analysis module, a logistics management module, a payment management module and a data synchronization monitoring module;

[0027] Order analysis module: When a transaction party generates an order through an e-commerce platform, the system records the order information and generates a unique order number, analyzes historical transaction data, predicts the risk level of the order, and uploads the order information to a unified data management platform;

[0028] Logistics management module: After the order is confirmed, the logistics supplier's system is connected to the data management platform in real time to automatically update the logistics status information, including warehousing, outbound, cross-border transportation and arrival status, to ensure that all parties to the order are aware of the logistics progress in real time;

[0029] Payment management module: Payment conditions are set through the smart contract mechanism. When the logistics status is updated to shipped, the smart contract automatically sends a payment trigger signal to the financial institution; when the logistics status is updated to received, the smart contract automatically executes the settlement operation to ensure that the payment is synchronized with the logistics status;

[0030] Data synchronization monitoring module: Analyze the frequency of changes in logistics status and abnormal payment delays, evaluate the synchronization and real-time performance of data in the cross-border trade transaction process based on the analysis results, and send early warning signals when the synchronization and real-time performance is low to notify the transaction parties and financial institutions for timely intervention.

[0031] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0032] 1. The present invention realizes unified management and real-time data synchronization of each transaction link through the data management platform, solving the problems of delay, information loss and inconsistency caused by data dispersion in traditional systems. The system predicts risks when an order is generated and uploads order information to the platform in real time; the logistics status is updated to the smart contract on the blockchain in real time through the API interface, triggering payment and settlement conditions to ensure the synchronization of capital flow and logistics status; through the analysis of the logistics update frequency fluctuation index and the payment delay frequency abnormality index, the real-time monitoring of data synchronization is carried out in real time, and the generated abnormal detection mechanism effectively prevents the occurrence of capital retention, overpayment and cross-border capital supervision blind spots.

[0033] 2. The present invention introduces a machine learning model to dynamically predict the real-time value of data synchronization during the transaction process based on the logistics update frequency and payment delay data, and automatically evaluate the health status of the system. When the real-time performance is lower than the preset benchmark value, the system triggers an early warning signal to notify the transaction parties and financial institutions to intervene in time, thereby ensuring the smoothness and security of cross-border trade transactions. Through intelligent and automated real-time monitoring and abnormal early warning mechanisms, the present invention effectively improves the accuracy and reliability of cross-system data transmission, providing a solid guarantee for the security and efficiency of cross-border trade transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0035] Figure 1 The figure is a flow chart of the method of the present invention.

[0036] Figure 2 It is a system module diagram of the present invention. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0038] Example 1, please refer to Figure 1 and Figure 2 As shown, the transaction management method for mutual trade described in this embodiment includes the following steps:

[0039] S1: When a transaction party generates an order through an e-commerce platform, the system records the order information and generates a unique order number, analyzes historical transaction data, predicts the risk level of the order, and uploads the order information to a unified data management platform;

[0040] S2: After the order is confirmed, the logistics supplier's system is connected to the data management platform in real time to automatically update the logistics status information, including warehousing, outbound, cross-border transportation and arrival status, to ensure that all parties to the order are aware of the logistics progress in real time;

[0041] S3: Payment conditions are set through the smart contract mechanism. When the logistics status is updated to shipped, the smart contract automatically sends a payment trigger signal to the financial institution; when the logistics status is updated to received, the smart contract automatically executes the settlement operation to ensure that the payment is synchronized with the logistics status;

[0042] S4: Analyze the frequency of changes in logistics status and abnormal payment delays, evaluate the synchronization and real-time performance of data in the cross-border trade transaction process based on the analysis results, and send early warning signals when the synchronization and real-time performance is low to notify the transaction parties and financial institutions for timely intervention.

[0043] In S1, when a transaction party generates an order through an e-commerce platform, the system records the order information and generates a unique order number, analyzes historical transaction data, predicts the risk level of the order, and uploads the order information to a unified data management platform:

[0044] At the moment an order is generated, the system automatically extracts detailed information about the order from the e-commerce platform, including key data such as the order number, the identity information of the transaction party (such as identity ID or corporate information), details of the goods (category, quantity, unit price, etc.), transaction time, destination and expected delivery time. Based on the basic information of the order and the time when the order was generated, the system generates a globally unique order number in combination with certain rules. This number ensures that each order has an independent identification mark, which is convenient for tracking in the subsequent logistics, payment and monitoring process. The generation method can combine factors such as timestamp, transaction party ID and random number to ensure uniqueness and security.

[0045] After an order is generated, the system first standardizes the data of the new order so that it can be compared with historical data. Data standardization includes converting indicators such as order amount, type of goods, and transaction frequency into standard units so that unified analysis can be performed under different dimensions. The system extracts key feature information from the order, such as the transaction history of the transaction party (past order frequency, amount, etc.), goods attributes (whether it is sensitive or high-risk goods), destination (whether it is located in a high-risk area), transaction time (whether it is an abnormal transaction time), etc. By analyzing these features, the system obtains a detailed feature vector of the order. Using machine learning algorithms (such as logistic regression, random forest, or neural network), the system compares the features of the new order with historical transaction data and predicts the risk level of the order based on a pre-trained model. The model can identify common risk patterns (such as abnormal transaction amount, high transaction frequency, or low credit of the transaction party), and classify the risk of the order based on these features (such as low, medium, and high risk). The system will dynamically update the risk assessment model based on the newly generated order and the subsequent behavior of the transaction party. By continuously learning from new data, the model can more accurately identify potential risks and improve the accuracy and timeliness of predictions.

[0046] After completing the risk assessment, the system assigns the order to a risk level, such as "low risk", "medium risk" or "high risk". Each risk level corresponds to different processing procedures and monitoring efforts. For example, high-risk orders will enter a more stringent review process or require additional verification measures. For medium and high-risk orders, the system will generate markings or warning information and notify relevant managers or system modules (such as payment control modules, logistics monitoring modules, etc.) for further verification or monitoring. After completing the risk assessment, the system uploads the basic information of the order (order number, risk level, transaction party information, goods details, etc.) to a unified data management platform. The platform brings together the core data of all orders, so that subsequent logistics status updates and payment processes can be operated based on unified data information.

[0047] In this application, by recording order information, generating unique numbers, and assessing risk levels, the system is able to conduct a comprehensive analysis of the reliability and risks of transactions at the early stages of order generation. This approach not only ensures the integrity and traceability of order data, but also reduces potential transaction risks through intelligent risk prediction, providing reliable data support for subsequent logistics, payment, and regulatory links. Ultimately, the system improves the security and efficiency of cross-border trade transactions, enabling trading parties and financial institutions to more accurately manage financial and logistics risks in cross-border transactions.

[0048] Among them, the random forest model is used to compare the characteristics of new orders with historical transaction data, and the risk level of the order is predicted based on the pre-trained model, specifically:

[0049] First, collect a large amount of historical transaction data from the database. Each historical record should contain relevant features of the order, such as order amount, transaction party information, product type, transaction frequency, transaction time, destination, etc., as well as the risk label of the order (low risk, medium risk, high risk). Clean up outliers and missing values ​​in the data. Methods for handling missing values ​​can include mean filling, mode filling, or deleting data records with high missing rates. Ensure the accuracy and consistency of the data to provide high-quality training samples for the model. Data standardization / normalization: To avoid bias in the model due to different dimensions between features, standardize or normalize the numerical features. For example, scale the transaction amount, frequency, and other values ​​to the same scale to ensure balance during model training.

[0050] The historical data is divided into a training set and a test set (for example, 80% for training and 20% for testing). The training set is used to train the random forest model, and the test set is used to verify the accuracy and stability of the model.

[0051] Select key features related to order risk prediction, such as: Order amount: Orders with larger amounts may be associated with higher risks. Transaction frequency: A large number of transactions in a short period of time may indicate potential risks. Transaction party score / reputation: Orders from low-reputation transaction parties may be riskier. Product type: Sensitive products (such as high-value products) are usually associated with higher risks. Destination: Certain countries or regions may have higher transaction risks. Feature encoding: Encode categorical features (such as product type, transaction party reputation, etc.) and convert them into numerical forms that can be processed by the model. Common encoding methods include One-Hot Encoding or Label Encoding.

[0052] Introduction to the Random Forest Model: The Random Forest Model is an ensemble learning algorithm that generates multiple decision trees and combines their prediction results to improve overall accuracy and noise resistance. Each decision tree is built on the basis of random samples and random features, thereby enhancing the generalization ability of the model.

[0053] Build a random forest model: Define the key parameters of the random forest model, including the number of trees (n_estimators), the maximum depth of the tree (max_depth), the minimum number of split samples (min_samples_split), the minimum number of leaf node samples (min_samples_leaf), etc. These parameters will affect the accuracy and computational efficiency of the model.

[0054] The training set is input into the random forest model for training. The model generates multiple decision trees based on the features and labels (i.e., risk level) of each order. Each tree is trained with different samples and feature combinations to capture complex feature relationships.

[0055] To ensure the robustness of the model, cross-validation (such as K-fold cross-validation) is performed to continuously evaluate the accuracy of the model on the training set, and parameter optimization is performed to prevent overfitting or underfitting.

[0056] For a newly generated order, the same features (such as order amount, transaction frequency, transaction party score, etc.) are extracted from the order, and the same data standardization and encoding processing is performed.

[0057] The feature vector of the new order is input into the trained random forest model, and each decision tree in the model will make an independent prediction of the risk level of the order.

[0058] The random forest model uses a voting mechanism to determine the final prediction result. Each tree will give a risk level prediction (such as "low risk", "medium risk" or "high risk"), and the model will select the prediction result of the majority decision tree as the final risk level. For example, if the majority of decision trees believe that the order is "high risk", the model will output "high risk".

[0059] The model outputs the predicted risk level of the order (such as "low risk", "medium risk" or "high risk") and uploads this information to a unified data management platform together with the order. If a new order is assessed as "high risk", the system triggers an early warning mechanism and sends the early warning information to relevant managers and system modules for further verification or action. The prediction results and actual order execution are stored to provide data for future model updates and retraining. The system can periodically retrain the model with new data to improve the model's adaptability and prediction accuracy in new trading environments.

[0060] Use the test set to evaluate the model's accuracy, recall, F1 score and other performance indicators to ensure the model's effectiveness in predicting order risks. In particular, the prediction effect of "high-risk" orders should be evaluated to ensure that the system can identify most high-risk orders. Risk patterns may change over time and as the market changes. The system can periodically retrain the random forest model or introduce incremental learning methods to add new data based on historical data, thereby improving the model's generalization and timeliness.

[0061] In this application, by using the random forest model, this method realizes the intelligent prediction of the risk level of new orders. The model uses historical transaction data and order characteristics to judge the risk level of orders through the integrated voting method of multiple decision trees. Every time a new order is generated, the system can quickly predict the risk level and store the results in a unified data management platform. High-risk orders will automatically trigger early warnings, notifying relevant parties to take measures to ensure the security and stability of cross-border trade transactions.

[0062] S2: After the order is confirmed, the logistics supplier's system is connected to the data management platform in real time to automatically update the logistics status information, including warehousing, outbound delivery, cross-border transportation and arrival status, to ensure that all parties to the order are aware of the logistics progress in real time.

[0063] A standardized data interface is established between the data management platform and the logistics supplier's system to ensure that information between different systems can be smoothly transmitted. The interface design can be based on API (application programming interface) or EDI (electronic data interchange) protocol to achieve two-way communication. Define and unify the standard format of logistics status, including specific descriptions of warehousing, outbound, cross-border transportation and arrival, as well as the timestamp corresponding to each status. This ensures that logistics suppliers can upload standardized data to the platform at different logistics stages. In order to ensure data security, logistics suppliers need to pass identity authentication (such as API key or OAuth) to access the data management platform, and upload and view the logistics status of related orders according to preset permissions.

[0064] After the order is confirmed, the system first receives the warehouse information update. When the goods enter the warehouse stage, the logistics provider's system will update the "in-warehouse" status to the data management platform, and attach detailed information such as the time of entry and storage location. The real-time update of the warehouse status ensures that the transaction parties can confirm that the goods are ready to enter the logistics process. When the order is picked up from the warehouse and ready for transportation, the logistics provider's system will update the "out-of-warehouse" status to the data management platform, and attach the out-of-warehouse time. At this time, the system automatically generates an outbound notification to remind the transaction parties that the goods have been shipped and start cross-border transportation preparations. During the cross-border transportation stage, the logistics provider's system will continuously update the transportation status of the goods. For example, when the goods pass the checkpoint or customs inspection, the system will mark the "passed customs" or "in transit" status. Each update of the transportation node is accompanied by a timestamp and location information, and uploaded to the data management platform in real time. This process can use GPS positioning and Internet of Things (IoT) technology to ensure the accuracy and real-time nature of the transportation status. When the goods arrive at the destination (such as a border receiving warehouse or a processing enterprise warehouse), the logistics provider's system will update the "arrived" status with the specific arrival time. This status marks the completion of cross-border transportation and triggers the conditions for notifying financial institutions to settle funds.

[0065] After each logistics status update, the data management platform will automatically push the updated information to relevant parties, such as trading parties, financial institutions and regulatory agencies. The push method can be through API interface, email or SMS notification to ensure that all relevant parties can obtain logistics dynamics in the first time. The data management platform will display the latest logistics status on the user interface of trading parties and financial institutions. Through the visual interface, users can see the current status of the order, logistics node time, geographic location and other information to track the progress of the goods. The system can automatically notify relevant parties according to the preset trigger conditions. For example, after the logistics status changes to "arrived", the system automatically triggers the notification of the financial institution to start the settlement process to ensure the synchronization of payment and logistics.

[0066] The data management platform is equipped with an abnormal monitoring function to check the rationality of the logistics status in real time. For example, if the logistics status is not updated to "cross-border transportation" or "arrived" for a long time after "shipped", the system will identify it as a potential abnormality. Once an abnormality in the logistics status update (such as status lag or position deviation) is found, the system will automatically send an early warning message to notify the logistics supplier, the transaction party and the financial institution so that the relevant parties can intervene in time. The early warning mechanism can effectively prevent logistics delays, cargo loss, etc., and ensure a smooth transaction process.

[0067] The data management platform will record the logistics status updates of each order, including the status, timestamp and location information of each logistics node. All historical records will be saved in chronological order to form a complete logistics record chain for easy tracking afterwards. The platform automatically generates an audit log of the logistics status, recording the details of each status update, including the source, time and relevant personnel of the data update. This provides regulators with an auditable logistics tracking basis to improve the transparency and compliance of cross-border transactions.

[0068] In this application, through the real-time connection between the data management platform and the logistics supplier system, the logistics status of the order can be updated and shared in time at each key node (warehousing, outbound, cross-border transportation, arrival). After each logistics status update, the platform will push the latest information to the relevant parties to ensure that the trading parties and financial institutions are aware of the logistics progress at any time and make corresponding operational decisions. In addition, by introducing an abnormal monitoring and early warning mechanism, the system can identify and respond to abnormal situations in the logistics process in real time. Combined with blockchain technology, this method can enhance the security and transparency of logistics data and provide solid guarantees for the efficient management and compliance supervision of barter trade.

[0069] S3: Payment conditions are set through the smart contract mechanism. When the logistics status is updated to shipped, the smart contract automatically sends a payment trigger signal to the financial institution. When the logistics status is updated to received, the smart contract automatically executes the settlement operation to ensure that the payment is synchronized with the logistics status.

[0070] Develop smart contracts on the blockchain platform and write contract code using a smart contract programming language (such as Solidity). The contract code should include payment condition logic, trigger conditions, and status variables to ensure that the contract can automatically trigger the payment process based on the logistics status. Define the key parameters of the smart contract, such as order number, transaction party identity (shipper, receiver, financial institution, etc.), payment amount, logistics status ("shipped" or "received"), etc. The relevant information of each order will be stored as input parameters in the smart contract. Deploy the smart contract on the blockchain network to ensure that all participants (including transaction parties and financial institutions) can access and view the status of the contract on the blockchain. The deployed smart contract address will become the unique identifier of the order, which will be used for subsequent payment triggering and settlement operations.

[0071] Two key status variables are defined in the smart contract: shipmentStatus (logistics status) and paymentStatus (payment status). For example, the value of shipmentStatus can be "pending shipment", "shipped", "received", and the value of paymentStatus can be "pending payment", "paying", "paid". Shipment triggers payment signal: The contract stipulates that when shipmentStatus is updated to "shipped", the smart contract automatically sends a payment trigger signal to the financial institution and updates paymentStatus to "paying". This condition ensures that the payment process will only be initiated after the goods are shipped and the shipment is confirmed. Receipt triggers settlement: The contract also stipulates that when shipmentStatus is updated to "received", the smart contract automatically executes the final settlement operation and updates paymentStatus to "paid". This condition ensures that the payment settlement will be completed only after the goods arrive at the recipient and the receipt is confirmed, reducing transaction risks.

[0072] Ensure that the logistics supplier's system is connected to the blockchain network in real time. When the logistics status changes (such as from "pending shipment" to "shipped"), the logistics system will send a status update request to the blockchain through the API interface. The logistics system sends the logistics status update to the smart contract through the API interface. The blockchain network verifies the legitimacy of the update request, and after confirmation, records the new logistics status in the smart contract (such as updating shipmentStatus to "shipped" or "received"). After the logistics status is updated, the smart contract automatically executes the preset logical judgment to detect whether the current shipmentStatus meets the trigger condition ("shipped" or "received"). When the conditions are met, the contract immediately starts the corresponding payment process.

[0073] When the smart contract detects that shipmentStatus is updated to "shipped", the contract automatically sends a payment trigger signal to the specified financial institution address. This signal is usually an event on the blockchain, and the financial institution's system receives the payment signal by subscribing to blockchain events. After sending the payment trigger signal, the smart contract updates paymentStatus to "paying", indicating that the payment process has been initiated but the settlement has not been completed. After receiving the payment trigger signal, the financial institution's system automatically connects to the payment platform (such as a bank or payment gateway) to complete the funds transfer. After the funds transfer is completed, the financial institution feeds back the payment completion information to the blockchain.

[0074] When the logistics status is updated to "Received", the logistics system will send an update request for the status to the blockchain. After receiving this update, the smart contract updates the shipmentStatus to "Received". When the smart contract detects that the shipmentStatus is "Received", the contract automatically performs the settlement operation and updates the paymentStatus to "Paid". This operation marks the completion of the transaction and the end of the payment process. The smart contract records the final payment status and timestamp on the blockchain, forming an unalterable payment record to ensure that all parties can view and confirm the completion status of the transaction.

[0075] An anomaly detection mechanism is designed in the smart contract to monitor abnormalities in payment and logistics status. For example, if the shipmentStatus is not updated to "shipped" or "received" within the scheduled time, the smart contract will trigger an abnormal alarm and notify the relevant parties to intervene in the investigation. If an abnormality in logistics or payment status is detected (such as timeout or insufficient funds), the smart contract can automatically roll back the unfinished transaction and reset the payment status to "pending payment". The contract will record the abnormal situation when rolling back and notify the transaction parties and financial institutions for further manual review.

[0076] Every time the logistics status is updated, payment is triggered and settlement is completed, the smart contract will record the timestamp, operator (smart contract execution), payment amount, status and other information on the blockchain. This information is permanently recorded on the blockchain, forming an audit record that cannot be tampered with. Financial institutions and regulators can query the logistics and payment status of each order at any time through the blockchain browser or system interface to ensure the transparency and traceability of the transaction process.

[0077] In this application, payment conditions are set through the smart contract mechanism, achieving a high degree of automation and synchronization between logistics status and payment process. When the logistics status is updated to "shipped" or "received", the smart contract automatically triggers the payment or settlement operation according to the preset conditions. The entire process is guaranteed by the blockchain to ensure the transparency and immutability of data, thereby ensuring the efficiency, security and compliance of the payment process. Through the automatic anomaly detection and rollback mechanism, the system can effectively handle abnormal situations, further enhancing the security and stability of transactions.

[0078] S4: Analyze the frequency of changes in logistics status and abnormal payment delays, evaluate the synchronization and real-time performance of data in the cross-border trade transaction process based on the analysis results, and send early warning signals when the synchronization and real-time performance is low to notify the transaction parties and financial institutions for timely intervention.

[0079] Collect updated data on logistics status from historical transaction records, including timestamps of status changes and corresponding logistics node information. Record the time intervals for each status change, such as the time from "shipped" to "in transit" or "in transit" to "arrived". Calculate the distribution of time intervals between each logistics status to understand the average time span between nodes under normal conditions. Use statistical methods (such as those based on standard deviation or IQR intervals) to identify abnormally long time intervals in logistics status changes. For example, the average time from "shipped" to "in transit" is 2 hours. If it exceeds 6 hours, it is considered that the node may be abnormal.

[0080] If the change frequency of some logistics nodes is significantly lower than that of other nodes, or a certain status (such as "in transit") has not been updated for a long time, it may indicate that the logistics data has not been synchronized to the platform on time. If some logistics statuses are frequently missing or jumping, it may mean that the data upload process of the logistics party is unstable, resulting in some data not being synchronized to the platform.

[0081] The logistics update frequency fluctuation index is generated based on the frequency fluctuation of the logistics update time of each logistics node. The method for obtaining the logistics update frequency fluctuation index is as follows:

[0082] The frequency of each logistics node's status update in each time period (such as every hour, every day) is constructed into a time series, recorded as {f1, f2, ..., f n}, where f n Indicates the update frequency of the nth time period, and selects an analysis window (such as 1 week or 1 month of historical data) for quantile calculation. The length of the time window can be set according to business needs and frequency fluctuation characteristics.

[0083] Choose appropriate high and low quantiles (e.g., 75% and 25%, or more extreme 95% and 5%) for identifying outliers. Set the upper quantile to Qu and the lower quantile is Q l , these quantiles will be used as thresholds for anomaly detection. Based on the updated frequency data {f1, f2, ..., f n}, calculate the upper quantile as Q u and the lower quantile is Q l , upper quantile (such as 75% quantile): Q u =quantile(f,0.75); lower quantile (such as 25% quantile): Q l =quantile(f, 0.25), calculate the interquartile range IQR, use the high quantile and low quantile to calculate the interquartile range, which is used to set the abnormal range. The expression is:

[0084] IQR=Q u -Q l ; Determine the upper and lower limits of the abnormal threshold: define the upper and lower limits of the abnormal threshold according to the interquartile range to determine whether the update frequency in a certain period of time is abnormal. The expression of the upper and lower limits of the abnormality is: Upper limit = Q u +k·IQR; lower limit=Q u -k·IQR k is a constant, usually 1.5 or 3, which is used to control the width of the abnormal range. A larger k value will expand the normal range, and a smaller k value will more strictly determine the abnormality. The update frequency that exceeds the upper and lower limits is taken as the abnormal update frequency, and the abnormal update frequency of each time period is accumulated in the entire analysis time window to obtain the logistics update frequency fluctuation index.

[0085] When the logistics update frequency fluctuation index is large, it means that the update frequency of logistics nodes in the process of cross-border trade transactions fluctuates violently, and the real-time synchronization of data is poor. An increase in the index usually indicates that the update time of logistics information is unstable, with delays or frequent interval anomalies. This instability may cause the parties to the transaction to be unable to accurately grasp the logistics status, affect the accuracy of fund settlement, and increase transaction risks. Therefore, a large fluctuation index indicates that the data synchronization mechanism needs to be optimized to improve the timeliness of the system in updating logistics status.

[0086] On the contrary, when the logistics update frequency fluctuation index is small, it indicates that the update frequency of the logistics node is relatively stable and the synchronization and real-time performance of the data is good. The small fluctuation index reflects the stability and consistency of the logistics status update, so that the trading parties and financial institutions can obtain accurate logistics information in real time and ensure the coordination and consistency of capital flow and logistics status. A smaller fluctuation index helps to improve the operating efficiency and reliability of the system, thereby ensuring the smoothness and security of cross-border trade transactions.

[0087] Payment delay exception refers to the situation where the payment status fails to be updated in time after the logistics status reaches a certain point. For example, when the logistics status is updated to "shipped", the system should send a payment trigger signal to the financial institution within a reasonable time. If the payment status is not updated on time, it indicates that the data synchronization is lagging behind.

[0088] Collect the timestamps of payment trigger events and settlement completion events, as well as the time when the corresponding logistics status changes. Obtain payment status update records for each order to calculate the delay between the trigger condition (such as "shipped" or "received") and the actual payment trigger time.

[0089] The payment delay frequency abnormality index is generated by analyzing the frequency of payment delays in different time periods. The method for obtaining the payment delay frequency abnormality index is as follows:

[0090] Collect payment delay frequency data in each time period (such as every hour, every day), construct it into time series data xt, where t represents the time point, and calculate the current payment delay frequency smoothing value, the expression is: S t =a·x t +(1-a)·S t-1 ; S t is the current payment delay frequency smoothing value, S t-1 The smoothed value of the payment delay frequency at the previous time point, α is the smoothing coefficient (0<α≤1). A higher α gives a higher weight to the most recent data, making the exponential average more sensitive to changes in new data. The choice of smoothing coefficient is usually set according to the characteristics of the data, and the value is between 0 and 1. A larger α value (for example, 0.7-0.9) means that the expression focuses more on the latest delay data and responds more quickly to changes in delay frequency; a smaller α value (for example, 0.2-0.3) means that the expression is smoother and suitable for data that does not change frequently. Set the initial payment delay frequency smoothing value to S0, which can be set to the average value of the delay frequency series or the first delay frequency value in the historical data. Get the payment delay frequency smoothing baseline value ES under normal conditions in the historical data t If the current payment delay frequency smoothing value is greater than the payment delay frequency smoothing benchmark value, it is regarded as an abnormal payment delay frequency smoothing value, and the standard deviation of all abnormal payment delay frequency smoothing values ​​is calculated, that is, the payment delay frequency abnormality index is calculated.

[0091] When the payment delay frequency abnormality index is large, it means that the synchronization and real-time performance of payment data in the cross-border trade transaction process is poor. This situation indicates that the system has detected abnormal payment delay frequency in multiple time periods, that is, the execution of payment instructions has not been synchronized with the logistics status in a timely manner. This delay may lead to asynchrony of information flow between transaction links, increase the risk of capital retention and logistics delays, and increase the financial risk and regulatory difficulty of the transaction parties. Therefore, the larger the payment delay frequency abnormality index, the more it means that the payment and data management system needs to be optimized immediately to improve the real-time performance of the data and the system response speed.

[0092] On the contrary, when the payment delay frequency abnormality index is small, it means that the synchronization of payment and logistics status is relatively timely during the cross-border trade transaction, and the real-time performance of the data is good. This means that the system has maintained a high payment response speed in most time periods, and the payment status can be quickly updated and kept consistent with the logistics status, ensuring the close connection between capital flow and logistics progress. The better the synchronization and real-time performance, the less potential transaction risks can be, the better the overall transaction efficiency and user satisfaction can be, making the cross-border trade management system more stable and reliable.

[0093] The logistics update frequency fluctuation index and the payment delay frequency anomaly index are converted into feature vectors, and the feature vectors are used as the input of the machine learning model. The machine learning model takes each group of feature vectors to predict the synchronous real-time value label of the data in the process of mutual trade transactions as the prediction target, and takes minimizing the sum of prediction errors of the synchronous real-time value labels of all data in the process of mutual trade transactions as the training target. The machine learning model is trained until the sum of prediction errors converges and the model training is stopped. The synchronous real-time value of the data in the process of mutual trade transactions is determined according to the model output results, wherein the machine learning model is a polynomial regression model.

[0094] The method for obtaining the synchronous real-time value of data in the process of mutual trade transactions is: obtain the corresponding function expression from the feature vector training data of the trained machine learning model:

[0095] CG=F(SQ,GH); where F is the output function of the model, SQ is the logistics update frequency fluctuation index, GH is the payment delay frequency anomaly index, and CG is the synchronization real-time value of data in the process of mutual trade transactions.

[0096] The synchronization real-time value of the data obtained during the mutual trade transaction is compared with the synchronization real-time benchmark value preset under normal conditions in the historical data. If the synchronization real-time value of the data during the mutual trade transaction is greater than or equal to the synchronization real-time benchmark value preset under normal conditions in the historical data, it means that the synchronization real-time of the data during the mutual trade transaction is high. At this time, no warning signal is generated and no intervention is required. If the synchronization real-time value of the data during the mutual trade transaction is less than the synchronization real-time benchmark value preset under normal conditions in the historical data, it means that the synchronization real-time of the data during the mutual trade transaction is low. At this time, a warning signal is generated to notify the transaction parties and financial institutions to intervene in a timely manner.

[0097] In this embodiment, during the management of cross-border trade transactions, the system first records the order information and generates a unique order number when the order is generated. At the same time, it analyzes the risk level of the order based on historical data and uploads the information to a unified data management platform. After the order is confirmed, the logistics supplier's system is connected to the platform to update the logistics status (including warehousing, outbound, cross-border transportation and arrival) in real time to ensure that the transaction parties are aware of the logistics progress in real time. Payment conditions are set through smart contracts. When the logistics status reaches "shipped", the system automatically triggers the payment signal, and when it reaches "received", the settlement is completed to ensure that the payment process is synchronized with the logistics status. The system also analyzes the logistics update frequency and payment delay anomalies, and evaluates the accuracy and stability of data synchronization in real time. When the synchronization real-time performance decreases, the system automatically sends an early warning signal to notify the transaction parties and financial institutions to intervene in time to ensure a smooth and safe transaction process.

[0098] Embodiment 2, a transaction management system for mutual trade described in this embodiment, includes an order analysis module, a logistics management module, a payment management module and a data synchronization monitoring module;

[0099] Order analysis module: When a transaction party generates an order through an e-commerce platform, the system records the order information and generates a unique order number, analyzes historical transaction data, predicts the risk level of the order, and uploads the order information to a unified data management platform;

[0100] Logistics management module: After the order is confirmed, the logistics supplier's system is connected to the data management platform in real time to automatically update the logistics status information, including warehousing, outbound, cross-border transportation and arrival status, to ensure that all parties to the order are aware of the logistics progress in real time;

[0101] Payment management module: Payment conditions are set through the smart contract mechanism. When the logistics status is updated to shipped, the smart contract automatically sends a payment trigger signal to the financial institution; when the logistics status is updated to received, the smart contract automatically executes the settlement operation to ensure that the payment is synchronized with the logistics status;

[0102] Data synchronization monitoring module: Analyze the frequency of changes in logistics status and abnormal payment delays, evaluate the synchronization and real-time performance of data in the cross-border trade transaction process based on the analysis results, and send early warning signals when the synchronization and real-time performance is low to notify the transaction parties and financial institutions for timely intervention.

[0103] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0104] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

[0105] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0106] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A transaction management method for mutual trade, characterized in that: The steps include: S1: When a transaction party generates an order through an e-commerce platform, the system records the order information and generates a unique order number, analyzes historical transaction data, predicts the risk level of the order, and uploads the order information to a unified data management platform; S2: After the order is confirmed, the logistics supplier's system is connected to the data management platform in real time to automatically update the logistics status information, including warehousing, outbound, cross-border transportation and arrival status, to ensure that all parties to the order are aware of the logistics progress in real time; S3: Payment conditions are set through the smart contract mechanism. When the logistics status is updated to shipped, the smart contract automatically sends a payment trigger signal to the financial institution; when the logistics status is updated to received, the smart contract automatically executes the settlement operation to ensure that the payment is synchronized with the logistics status; S4: Analyze the frequency of changes in logistics status and abnormal payment delays, evaluate the synchronization and real-time performance of data in the cross-border trade transaction process based on the analysis results, and send early warning signals when the synchronization and real-time performance is low to notify the transaction parties and financial institutions for timely intervention.

2. A transaction management method for mutual trade according to claim 1, characterized in that: In S1, the random forest model is used to compare the characteristics of new orders with historical transaction data, and the risk level of the order is predicted based on the pre-trained model, specifically: Collect historical transaction data from the database, standardize the data and divide it into training set and test set, select features related to order risk prediction, and define the parameters of the random forest model, including the number of trees, the maximum depth of the tree, the minimum number of split samples, and the minimum number of leaf node samples; The training set is input into the random forest model for training. The model generates multiple decision trees based on the features and labels of each order. Each tree is trained with different combinations of samples and features. For a newly generated order, extract the same features from the order and perform the same data standardization and encoding process; Input the feature vector of the new order into the trained random forest model. Each decision tree in the model will make an independent prediction on the risk level of the order. The random forest model uses a voting mechanism to determine the final prediction result. Each tree will give a risk level prediction, including low risk, medium risk and high risk. The model will select the prediction results of the majority of decision trees as the final risk level; The model outputs the predicted risk level of the order and uploads the information together with the order to a unified data management platform.

3. A transaction management method for mutual trade according to claim 2, characterized in that: In S3, when a transaction order is generated, the order information and logistics status information are recorded through a smart contract, and payment conditions are set; the smart contract includes state variables for automatically triggering payment and settlement, and defines the order number, transaction party identity, payment amount and trigger conditions; the smart contract is connected to the blockchain through the logistics supplier system to ensure real-time updates through the API interface when the logistics status changes; after the payment is triggered and the settlement is completed, the contract records the transaction status, timestamp and payment amount on the blockchain to form an unalterable audit record. If the logistics or payment status is abnormal, the contract will automatically roll back the transaction and trigger an abnormal alarm, notifying the transaction party and financial institution for review.

4. A transaction management method for mutual trade according to claim 3, characterized in that: In S4, a logistics update frequency fluctuation index is generated based on the fluctuation of the logistics update time change frequency of each logistics node. The method for obtaining the logistics update frequency fluctuation index is: The frequency of status update of each logistics node in each time period is constructed into a time series, recorded as {f1, f2, ..., f n }, where f n Indicates the update frequency of the nth time period, selects an analysis window for quantile calculation, and sets the upper quantile to Q u and the lower quantile is Q l , based on the update frequency data {f1, f2, ..., f n }, calculate the upper quantile as Q u and the lower quantile is Q l , upper quantile: Q u =quantile(f,0.75); lower quantile: Q l =quantile(f, 0.25), calculate the interquartile range IQR, use the high quantile and low quantile to calculate the interquartile range, which is used to set the abnormal range. The expression is: IQR = Q u -Q l ; Determine the upper and lower limits of the abnormal threshold: upper limit=Q u +k·IQR; lower limit=Q u -k·IQR; k is a constant. The update frequency that exceeds the upper and lower limits is regarded as the abnormal update frequency. The abnormal update frequency of each time period is accumulated in the entire analysis time window to obtain the logistics update frequency fluctuation index.

5. A transaction management method for mutual trade according to claim 4, characterized in that: The payment delay frequency abnormality index is generated by analyzing the frequency of payment delays in different time periods. The method for obtaining the payment delay frequency abnormality index is as follows: The payment delay frequency data is collected in each time period and constructed into time series data xt, where t represents the time point. The current payment delay frequency smoothing value is calculated, and the expression is: S t =a·x t +(1-a)·S t-1 ; S t is the current payment delay frequency smoothing value, S t-1 The payment delay frequency smoothing value at the previous time point, α is the smoothing coefficient, and the initial payment delay frequency smoothing value is set to S0 to obtain the payment delay frequency smoothing benchmark value ES under normal conditions in historical data. t If the current payment delay frequency smoothing value is greater than the payment delay frequency smoothing benchmark value, it is regarded as an abnormal payment delay frequency smoothing value, and the standard deviation of all abnormal payment delay frequency smoothing values ​​is calculated, that is, the payment delay frequency abnormality index is calculated.

6. A transaction management method for mutual trade according to claim 5, characterized in that: The logistics update frequency fluctuation index and the payment delay frequency anomaly index are converted into feature vectors, and the feature vectors are used as the input of the machine learning model. The machine learning model takes each group of feature vectors to predict the synchronous real-time value label of the data in the process of mutual trade transactions as the prediction target, and takes minimizing the sum of prediction errors of the synchronous real-time value labels of all data in the process of mutual trade transactions as the training target. The machine learning model is trained until the sum of prediction errors converges and the model training is stopped. The synchronous real-time value of the data in the process of mutual trade transactions is determined according to the model output results, wherein the machine learning model is a polynomial regression model.

7. A transaction management method for mutual trade according to claim 6, characterized in that: The synchronization real-time value of the data obtained during the mutual trade transaction is compared with the synchronization real-time benchmark value preset under normal conditions in the historical data. If the synchronization real-time value of the data during the mutual trade transaction is greater than or equal to the synchronization real-time benchmark value preset under normal conditions in the historical data, it means that the synchronization real-time of the data during the mutual trade transaction is high. At this time, no warning signal is generated and no intervention is required. If the synchronization real-time value of the data during the mutual trade transaction is less than the synchronization real-time benchmark value preset under normal conditions in the historical data, it means that the synchronization real-time of the data during the mutual trade transaction is low. At this time, a warning signal is generated to notify the transaction parties and financial institutions to intervene in a timely manner.

8. A transaction management system for mutual trade, used to implement a transaction management method for mutual trade according to any one of claims 1 to 7, characterized in that: Including order analysis module, logistics management module, payment management module and data synchronization monitoring module; Order analysis module: When a transaction party generates an order through an e-commerce platform, the system records the order information and generates a unique order number, analyzes historical transaction data, predicts the risk level of the order, and uploads the order information to a unified data management platform; Logistics management module: After the order is confirmed, the logistics supplier's system is connected to the data management platform in real time to automatically update the logistics status information, including warehousing, outbound, cross-border transportation and arrival status, to ensure that all parties to the order are aware of the logistics progress in real time; Payment management module: Payment conditions are set through the smart contract mechanism. When the logistics status is updated to shipped, the smart contract automatically sends a payment trigger signal to the financial institution; when the logistics status is updated to received, the smart contract automatically executes the settlement operation to ensure that the payment is synchronized with the logistics status; Data synchronization monitoring module: Analyze the frequency of changes in logistics status and abnormal payment delays, evaluate the synchronization and real-time performance of data in the cross-border trade transaction process based on the analysis results, and send early warning signals when the synchronization and real-time performance is low to notify the transaction parties and financial institutions for timely intervention.

Images