An intelligent transaction method and system fusing high-frequency transaction and RPA automatic control

Abstract

The application provides a kind of intelligent transaction method and system of fusing high-frequency transaction and RPA automatic control, the intelligent transaction method includes: S1, market data and execution data are collected and preprocessed, and transaction strategy is generated;S2, transaction strategy is converted into standardized transaction instruction;S3, according to the task type in standardized transaction instruction and real-time index, high-frequency execution channel or RPA execution channel is automatically selected;S4, according to standardized transaction instruction, execute transaction in high-frequency execution channel or RPA execution channel, and output execution transaction result;S5, risk monitoring is carried out to execution transaction result;S6, execution transaction result is stored, and execution result is returned to S1 as execution data, and the transaction strategy generated in the next round is optimized through execution data.The application realizes high-performance, automation, safety compliance, traceable integrated transaction architecture through unified interface management, intelligent scheduling mechanism and global risk control system.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to an intelligent trading method and system that integrates high-frequency trading and RPA automatic control. Background Technology

[0002] With the rapid development of fintech and the energy trading market, automated and intelligent trading systems have become core technologies for improving trading efficiency and reducing operational risks. These systems are used in various trading scenarios, including financial derivatives, high-frequency quantitative trading, and carbon asset and energy trading. Trading systems need to respond to market changes in extremely short time, rapidly placing orders based on strategy signals, completing trades, and performing real-time risk control.

[0003] Traditional order book trading relies primarily on traders manually executing trades through clients or web pages. This includes logging into the trading system, selecting the trading instrument, entering parameters such as price, quantity, and direction, submitting the order, waiting for confirmation, and exporting or recording the execution results. While this operational model is simple and intuitive, it suffers from drawbacks in modern markets, including execution delays leading to missed trading opportunities, susceptibility to human factors (such as emotional instability or lack of concentration) causing errors, high complexity due to multiple system operations, significant compliance and auditing difficulties, and lagging risk control. These problems result in low execution efficiency, poor stability, and weak compliance of traditional trading, making it unsuitable for the needs of enterprise-level, high-frequency, or regulatory-level trading activities.

[0004] Currently, the industry has proposed some improvement solutions, such as Chinese invention patent application number 201910577482.X, which discloses a low-latency, high-frequency trading system and method. This invention patent is based on FPGA and DPDK high-speed network card, and performs rapid hardware pre-processing of network-interactive trading data within the FPGA. The data is processed in parallel at the edge and then transmitted to the trading application software for processing with low latency via the high-speed network card, effectively solving the problem of low execution efficiency in traditional trading. However, current intelligent trading systems still have the following problems:

[0005] (1) Dispersed interface management: Different modules maintain their own interface call logic, lacking a unified encapsulation layer;

[0006] (2) Inconsistency between scheduling and risk control: The high-frequency side and the RPA side use different risk control systems, and the data standards and response mechanisms are incompatible;

[0007] (3) Lacks continuous optimization capability: Unable to optimize strategy models in real time based on historical data;

[0008] (4) Difficulty in switching channels: When the high-frequency interface is abnormal or the trading system is limited, it cannot automatically switch to the RPA channel for stable execution. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings and deficiencies of the prior art and provide an intelligent trading method that integrates high-frequency trading and RPA automatic control.

[0010] Another objective of this invention is to provide an intelligent trading system that integrates high-frequency trading and RPA automatic control.

[0011] The objective of this invention is achieved through the following technical solution: an intelligent trading method integrating high-frequency trading and RPA automatic control, comprising:

[0012] S1. Preprocessing and Strategy Generation: Collect market data and execution data and preprocess them, then generate trading strategies through strategy models;

[0013] S2, Standardized Instructions and Transmission: Encapsulate trading strategies into standard API requests, and convert the data in the standard API requests into standardized trading instructions for transmission to the scheduling engine;

[0014] S3. Intelligent Scheduling: The scheduling engine automatically selects the execution channel based on the task type and real-time indicators in the standardized trading instructions. The execution channel includes a high-frequency execution channel or an RPA execution channel.

[0015] S4. Output execution results: Execute transactions in the high-frequency execution channel or RPA execution channel according to standardized trading instructions, and output the execution results;

[0016] S5. Risk Monitoring: Monitor the risks associated with the execution results of transactions to determine whether the execution results trigger risk rules.

[0017] If triggered, it will automatically execute commands to cancel the order, downgrade the channel, or freeze the task;

[0018] If not triggered, proceed to step S6;

[0019] S6. Result Storage and Analysis: Store the execution results of the transactions and upload them to the log. At the same time, send the execution results back to S1 as execution data. Optimize the strategy model using the execution data to generate a new strategy model.

[0020] Furthermore, the specific steps in S6 to optimize the next round of generated trading strategies through data execution are as follows:

[0021] S611. After the execution data is returned to S1, the execution data is preprocessed, and features that can predict the strategy performance or execution performance are extracted from the preprocessed data as input variables of the strategy model.

[0022] S612. Construct labels and use the returned execution data to label historical data to clarify the target results that the strategy model needs to predict.

[0023] S613. Using features as input variables and labels as targets, select a strategy model or fine-tune parameters. At the same time, optimize the strategy model by time series segmentation, feature selection and hyperparameter tuning to obtain a new strategy model.

[0024] S614. Conduct offline verification and backtesting of the new strategy model: Backtest the new strategy model using historical market data and execution data, compare key indicators and perform statistical significance tests to determine whether the new strategy model has the potential to be launched; at the same time, further verify the robustness of the model through out-of-sample testing.

[0025] S615. Randomly select 1% to 5% of small traffic by account or transaction type to import the new strategy model, while monitoring key indicators and verifying the performance of the new strategy model in a real market environment; in addition, indicator thresholds and automatic rollback rules are set to prevent the model from becoming abnormal in real-world scenarios and reduce the risk of going live.

[0026] After S616 and small-volume verification meet the standards, gradually expand the volume to full release. At the same time, through version management, version control is carried out on past strategy models to ensure traceability and rollback. The risks of this part of the volume are closely monitored to promptly discover and deal with problems caused by the failure of new strategy models or market changes. The monitoring data is fed back to S611 to form a complete closed loop of strategy iteration.

[0027] Furthermore, in S3, during the process of the scheduling engine selecting either the high-frequency execution channel or the RPA execution channel, the operating status and performance indicators of the high-frequency execution channel and the RPA execution channel are sampled and analyzed in real time. Performance indicators include: average response latency, instruction execution success rate, anomaly frequency, and task congestion level. Simultaneously, a dynamic weight calculation model is constructed based on these performance indicators: by weighting the performance indicators, the channel health score corresponding to the high-frequency execution channel and the RPA execution channel is calculated. The calculation of the health score H is illustrated below:

[0028] H = α × (1 / Delay Standardization Value) + β × Success Rate - γ × Abnormal Frequency - δ × Queue Length;

[0029] Wherein, α, β, γ, and δ are the weighting coefficients for average response latency, instruction execution success rate, anomaly frequency, and task congestion, respectively, which can be dynamically adjusted based on experience or historical data; the latency standardization value is the ratio of the current average latency to the historical baseline latency; the success rate is the proportion of transactions successfully executed per unit time; the anomaly frequency is the number of interface errors or timeouts per unit time; and the queue length is the number of tasks currently waiting to be executed.

[0030] Furthermore, when the health score of a high-frequency execution channel or RPA execution channel falls below a preset threshold, the following adjustment strategies are automatically implemented for the corresponding channel:

[0031] (1) Reduce the weight coefficient of this channel in the scheduling;

[0032] (2) Reduce the number of new tasks assigned;

[0033] (3) Prioritize assigning new tasks to the channel with a higher health score;

[0034] (4) If the health score continues to decline, the channel will be temporarily frozen and enter a pending recovery state;

[0035] (5) Simultaneously trigger log recording and operation and maintenance alarm mechanisms;

[0036] Once the health score of the channel recovers and continuously reaches the safety threshold, the channel's weight coefficient in scheduling will be gradually restored to avoid instantaneous fluctuations impacting the trading system.

[0037] Furthermore, in S6, the optimized new strategy model has the following effect on the scheduling engine:

[0038] S621. Feed back the real-time performance metrics of the high-frequency execution channel and RPA execution channel obtained through the new strategy model to the scheduling engine, which become the latest input parameters of the dynamic weight calculation model.

[0039] S622: The scheduling engine updates the weight coefficients in the dynamic weight calculation model in real time or periodically based on the latest input parameters, and recalculates the health scores of the high-frequency execution channel and the RPA execution channel.

[0040] S623. The scheduling engine automatically changes the task allocation ratio and channel priority of the high-frequency execution channel and the RPA execution channel based on the updated health score, thereby affecting the execution path selection of the next batch of tasks.

[0041] Furthermore, the preprocessing operations in S1 include:

[0042] (1) Deduplication: Remove duplicate records or duplicate receipts;

[0043] (2) Time alignment: Align multi-source data according to a unified clock and timestamp precision;

[0044] (3) Unit conversion: unifying the units of price, quantity, and time;

[0045] (4) Missing value handling: Imput or discard missing values ​​for key fields;

[0046] (5) Outlier removal or marking: Extreme delay values ​​are marked as outliers and processed separately.

[0047] Furthermore, the specific operations for storing transaction results in S6 include:

[0048] S631. Write the execution results of the transactions into the database according to the time sequence and generate storage records;

[0049] S632. Generate a digest hash for each stored record and store it as evidence;

[0050] S633, aggregate delay distribution, success rate, and slippage distribution metrics are written into a statistics table.

[0051] Another objective of this invention is achieved through the following technical solution: an intelligent trading system integrating high-frequency trading and RPA automatic control, comprising:

[0052] The strategy decision-making module is used to collect market data, generate trading strategies, and send them to the interface management module.

[0053] The interface management module is used to validate the content of the trading strategy. After the validation is successful, a trading order is generated and the trading order is encapsulated into a standard API request.

[0054] The data standardization module is used to convert data in standard API requests into standardized transaction instructions and send them to the intelligent scheduling and execution layer.

[0055] The intelligent scheduling and execution layer includes a high-frequency execution channel and an RPA execution channel. If the task in the standard API request is real-time or latency-sensitive, it is automatically assigned to the high-frequency execution channel; if the task in the standard API request is a multi-step approval or batch operation, it is assigned to the RPA execution channel; if the high-frequency execution channel or the RPA execution channel encounters an anomaly, the channel is automatically switched and retried; finally, the execution transaction results are sent to the risk control and monitoring module.

[0056] The risk control and monitoring module determines in real time whether the execution result triggers risk rules; risk rules include exceeding limits, duplicate delegation, and abnormal slippage.

[0057] The log and replay module is used to record the entire transaction activity and provides a complete traceability mechanism.

[0058] The data feedback and strategy optimization module is used to clean and normalize the execution results of the transactions and then send the processed results back to the strategy decision module.

[0059] Furthermore, the interface management module includes:

[0060] Interface module: Reads the basic information records of the interface and generates configuration metadata including protocol type, field mapping table, and authentication method;

[0061] Parameter mapping and format conversion module: Based on the field mapping rules in the configuration metadata, it maps the trading strategy from "standard field to target field", and performs format conversions such as precision truncation, date formatting, and type conversion, outputting the target system's structured data and finally generating a trading order.

[0062] Interface security module: Used to strengthen the security of structured data in transaction orders;

[0063] Protocol parsing module: Determines the protocol type based on the configuration metadata, selects the corresponding encapsulation method, and encapsulates the transaction order data into a standard API request.

[0064] Furthermore, the risk control and monitoring module adopts a component-based rule orchestration architecture. Through the combination of atomic components and EL expression orchestration, it achieves unified management and differentiated execution of heterogeneous businesses such as high-frequency trading and RPA under the same risk control platform.

[0065] In summary, the present invention has the following beneficial effects:

[0066] (1) This invention integrates the control interface of the high-frequency execution channel and the control interface of the RPA execution channel into the same standard system through the interface management module, realizing the fusion of the two execution mechanisms on the same platform. It can intelligently select the optimal execution channel according to the task type, network latency and risk level, achieving a balance between high performance and stability while ensuring security and compliance.

[0067] (2) This invention ensures that all trading activities are controllable, traceable, and replayable through risk control and monitoring modules as well as log and replay modules; and automatically feeds back data such as latency and transaction rate to the strategy engine after execution, forming a self-learning closed loop, thereby enabling the system to continuously optimize. Compared with the prior art, this invention not only achieves integrated improvement in execution speed and reliability, but also forms systematic innovation in interface standardization, security compliance, and intelligent optimization, providing an efficient, scalable, and regulatory technical foundation for automated trading across multiple markets and platforms. Attached Figure Description

[0068] Figure 1 This is a flowchart illustrating the intelligent trading method that integrates high-frequency trading and RPA automatic control as described in this invention.

[0069] Figure 2 This is a flowchart of the collaborative workflow of the internal modules of the interface management module described in this invention. Detailed Implementation

[0070] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0071] like Figures 1 to 2 As shown, an intelligent trading method integrating high-frequency trading and RPA automatic control includes:

[0072] S1. Preprocessing and Strategy Generation: Market data and execution data are collected and preprocessed, then a trading strategy is generated through a strategy model; the process of generating a trading strategy through the strategy model includes:

[0073] S11. Feature Construction and State Recognition: Extract key features such as price, trading volume, order book depth and volatility from market data, and extract execution features such as historical transaction time, channel success rate and order cancellation rate from execution data, thereby constructing the current market state vector and the execution environment state vector.

[0074] S12. Based on the market state vector and the execution environment state vector, perform strategy reasoning, and output the trading direction (buy / sell), trading quantity, price range and execution priority to form a trading strategy.

[0075] S13. Perform a preliminary risk control rule check on the generated trading strategy to determine whether the trading strategy meets the account risk, market constraints and system execution capabilities. Automatically correct or abandon the generation of trading strategies that do not meet the requirements. The trading strategy includes information such as strategy number, underlying asset code, buy / sell direction, order price, order quantity, priority tag, real-time level, and risk control mark.

[0076] S2, Standardized Instructions and Transmission: Encapsulate trading strategies into standard API requests and convert data into standardized trading instructions for transmission to the scheduling engine;

[0077] S3. Intelligent Scheduling: The scheduling engine automatically selects the execution channel based on the task type and real-time indicators in the standardized trading instructions. The execution channel includes a high-frequency execution channel or an RPA execution channel.

[0078] S4. Output execution results: Execute transactions in the high-frequency execution channel or RPA execution channel according to standardized trading instructions, and output the execution results;

[0079] S5. Risk Monitoring: Monitor the risks associated with the execution results of transactions to determine whether the execution results trigger risk rules.

[0080] If triggered, it will automatically execute commands to cancel the order, downgrade the channel, or freeze the task; for example, for quick order placement and batch order placement, if the order is not closed under certain conditions (time, price fluctuation, etc.), it will be automatically canceled.

[0081] If not triggered, proceed to step S6;

[0082] S6. Result Storage and Analysis: Store the execution results of the transactions and send the execution results back to S1 as execution data. Optimize the strategy model using the execution data to generate a new strategy model.

[0083] The specific steps for generating a new policy model in S6 are as follows:

[0084] S611. After the execution data is returned to S1, it is preprocessed, and features that can predict policy performance or execution performance are extracted from the preprocessed data as input variables for the policy model; commonly used features include:

[0085] Execution performance characteristics: latency, latency of the last 10 transactions, success rate;

[0086] Market characteristics: price volatility, imbalance between buy and sell orders;

[0087] Strategy characteristics: signal strength, such as percentage deviation from the moving average, trading session, and recent trading volume;

[0088] Scheduling characteristics: channel health score at the time of transmission, and queue length at the time of transmission.

[0089] Derived features:

[0090] (1) Use methods such as exponentially weighted moving average, differencing, and normalization to generate time series derived features;

[0091] (2) Combine cross features to capture conditional behavior.

[0092] S612. Construct labels and use the returned execution data to label historical data to clarify the target results that the strategy model needs to predict.

[0093] Tag definition example:

[0094] Two categories: whether the transaction was profitable or successfully executed;

[0095] Regression: Execution delay, realized rate of return.

[0096] Tag construction methods include:

[0097] (1) Directly use the data callback field (average price - market price);

[0098] (2) Normalize or logarithmically transform continuous labels to stabilize the training process.

[0099] S613. Using features as input variables and labels as targets, perform policy model selection or parameter tuning. Simultaneously, optimize the policy model through time series segmentation, feature selection, and hyperparameter tuning to obtain a new policy model; where:

[0100] Time series segmentation: Use rolling windows or time series cross-validation to avoid future data leakage;

[0101] Feature selection: Use regularization or tree-based feature importance selection to avoid collinearity;

[0102] Hyperparameter tuning: Overfitting is prevented through cross-validation.

[0103] S614. Conduct offline verification and backtesting of the new strategy model: Backtest the new strategy model using historical market data and execution data, compare key indicators (average price, success rate, number of risk control triggers, maximum drawdown, etc.) and perform statistical significance tests to determine whether the new strategy model has the potential to be launched; out-of-sample testing further verifies the robustness of the model.

[0104] S615. Randomly select 1% to 5% of the new strategy model by account or transaction type and import it into the new strategy model. At the same time, monitor key indicators (latency, success rate, risk control trigger rate, etc.) for several hours to several days, depending on the nature of the trading strategy. Validate the performance of the new strategy model in a real market environment. In addition, set indicator thresholds (such as success rate decrease >1% or latency increase >10%) and automatic rollback rules to prevent the model from malfunctioning in real-world scenarios and reduce the risk of going live.

[0105] After S616 and small-scale verification meet the standards, gradually expand the traffic to full release. Simultaneously, through version control, version control of past strategy models is implemented to ensure traceability and rollback. The risks associated with this increased traffic are closely monitored to promptly identify and address issues arising from new strategy model failures or market changes. Monitoring data is then fed back to S611, forming a complete closed loop for strategy iteration. The monitoring of the gradually expanding traffic includes the following:

[0106] (1) Real-time dashboard monitoring of key KPIs: latency, success rate, average slippage, risk control event rate, etc.;

[0107] (2) Set up automatic alarm strategies, such as automatically triggering rollback / pause when the delay increases by 10%, the success rate decreases by 1%, or the risk control events increase by 50%;

[0108] (3) Maintain the ability to roll back to previous versions at any time (versioning management and rollback scripts).

[0109] The process by which the scheduling engine in S3 selects between the high-frequency execution channel and the RPA execution channel is as follows: The operating status and performance indicators of the high-frequency execution channel and the RPA execution channel are sampled and analyzed in real time. Performance indicators include: average response latency, instruction execution success rate, anomaly frequency, and task congestion level. Simultaneously, a dynamic weight calculation model is constructed based on these performance indicators: by weighting the performance indicators, the channel health score corresponding to the high-frequency execution channel and the RPA execution channel is calculated. The calculation of the health score H is illustrated below:

[0110] H = α × (1 / Delay Standardization Value) + β × Success Rate - γ × Abnormal Frequency - δ × Queue Length;

[0111] Wherein, α, β, γ, and δ are the weighting coefficients for average response latency, instruction execution success rate, anomaly frequency, and task congestion, respectively, which can be dynamically adjusted based on experience or historical data; the latency standardization value is the ratio of the current average latency to the historical baseline latency; the success rate is the proportion of transactions successfully executed per unit time; the anomaly frequency is the number of interface errors or timeouts per unit time; and the queue length is the number of tasks currently waiting to be executed.

[0112] The system can calculate the health scores of the high-frequency execution channel and the RPA execution channel at any point in time, as shown in Table 1:

[0113] Table 1

[0114]

[0115] When the health score of a high-frequency execution channel or RPA execution channel falls below a preset threshold, the following adjustment strategy will be automatically applied to the corresponding channel:

[0116] (1) Reduce the weight coefficient of this channel in the scheduling;

[0117] (2) Reduce the number of new tasks assigned;

[0118] (3) Prioritize assigning new tasks to the channel with a higher health score;

[0119] (4) If the health score continues to decline, the corresponding channel will be temporarily frozen and enter a waiting-to-recovery state;

[0120] (5) Simultaneously trigger log recording and operation and maintenance alarm mechanisms;

[0121] Once the health score of the channel recovers and continuously reaches the safety threshold, the channel's weight coefficient in scheduling will be gradually restored to avoid instantaneous fluctuations impacting the trading system.

[0122] Example:

[0123] Suppose that at a certain moment, the scheduling engine receives a standardized transaction instruction, the content of which is:

[0124] Task type: Buy at a limit price of 50

[0125] Time requirement: Medium

[0126] Risk level: Low to medium

[0127] Supported execution channels: High-frequency execution channel / RPA execution channel

[0128] The scheduling engine samples the real-time running status of the high-frequency execution channel and the RPA execution channel to obtain their respective performance indicators, and calculates the health score based on the performance indicators.

[0129] Ultimately, the scheduling engine makes the following decision based on the comparison of the health scores of the two execution channels:

[0130] If the health score of the RPA execution channel is higher than that of the high-frequency execution channel, the transaction instruction will be assigned to the RPA execution channel for execution, while the task allocation ratio of the high-frequency execution channel will be reduced. The high-frequency execution channel will be marked as "high load" and put into degraded mode. When subsequent sampling shows that the latency and queue length of the high-frequency execution channel have returned to normal, the scheduling engine will automatically restore the priority of the high-frequency execution channel.

[0131] If the health score of the high-frequency execution channel is higher than that of the RPA execution channel, the transaction instruction will be assigned to the high-frequency execution channel for execution, while the task allocation ratio of the RPA execution channel will be reduced. The RPA execution channel will be marked as "high load" to put it into degraded mode. When subsequent sampling shows that the RPA execution channel latency and queue length have returned to normal, the scheduling engine will automatically restore the priority of the high-frequency execution channel.

[0132] In S6, the optimized new policy model has the following effect on the scheduling engine:

[0133] S621. Feed back the real-time performance metrics of the high-frequency execution channel and RPA execution channel obtained through the new strategy model to the scheduling engine, which become the latest input parameters of the dynamic weight calculation model.

[0134] S622: The scheduling engine updates the weight coefficients in the dynamic weight calculation model in real time or periodically based on the latest input parameters, and recalculates the health scores of the high-frequency execution channel and the RPA execution channel.

[0135] S623. The scheduling engine automatically changes the task allocation ratio and channel priority of the high-frequency execution channel and the RPA execution channel based on the updated health score, thereby affecting the execution path selection of the next batch of tasks.

[0136] The preprocessing operations in S1 include:

[0137] (1) Deduplication: Remove duplicate records or duplicate receipts;

[0138] (2) Time alignment: Align multi-source data according to a unified clock and timestamp precision;

[0139] (3) Unit conversion: unifying the units of price, quantity, and time;

[0140] (4) Missing value handling: Imput or discard missing values ​​for key fields;

[0141] (5) Outlier removal or marking: Extreme delay values ​​are marked as outliers and processed separately.

[0142] The specific operations for storing transaction results in S6 include:

[0143] S631. Write the execution results of the transactions into the database according to the time sequence and generate storage records;

[0144] S632. Generate a digest hash for each stored record and store it as evidence;

[0145] S633, aggregate delay distribution, success rate, and slippage distribution metrics are written into a statistics table.

[0146] An intelligent trading system integrating high-frequency trading and RPA automatic control includes:

[0147] The strategy decision-making module is used to collect market and execution data, generate trading strategies, and send them to the interface management module. Specific functions of the strategy decision-making module include:

[0148] Market data access: Access real-time market data, account information, and other data sources through a unified data gateway;

[0149] Strategy model modeling and analysis: Supports multiple quantitative models and adopts an event-driven mechanism to respond to market fluctuations in real time;

[0150] Trading strategy generation: The system outputs standardized trading signals (such as "buy", "sell", "cancel order") based on strategy conditions;

[0151] Instruction Packaging and Transmission: The trading strategy is packaged into API instructions in a unified format (initial packaging) and transmitted to the interface management layer.

[0152] The interface management module is used to validate the content of trading strategies. It primarily verifies the completeness of fields, the validity of data types, and business logic (such as account existence). Upon successful validation, it generates a trading order and encapsulates it into a standard API request for transmission to the intelligent scheduling and execution layer. This interface management module includes:

[0153] The interface module is used to read the basic information records of the interface and generate configuration metadata that includes protocol type, field mapping table and authentication method;

[0154] The protocol parsing module supports multiple communication protocols, such as REST, WebSocket, and TCP binary protocol.

[0155] Parameter mapping and format conversion module: Based on the field mapping rules in the configuration metadata, it maps the trading strategy from "standard field to target field", and performs format conversions such as precision truncation, date formatting, and type conversion, outputting the target system's structured data and finally generating a trading order.

[0156] Interface security module: Used to strengthen the security of structured data in transaction orders, specifically:

[0157] (1) Inject anti-duplicate factors such as timestamps and random numbers to prevent requests from being submitted repeatedly;

[0158] (2) Encrypt sensitive fields such as account passwords;

[0159] (3) Generate tamper-proof digital signatures based on the full dataset;

[0160] (4) The final output is the protected service load;

[0161] Protocol parsing module: Determines the protocol type based on configuration metadata and selects the corresponding encapsulation method.

[0162] REST / HTTP: Assemble HTTP messages containing Header, Method, and Body;

[0163] WebSocket: A message encapsulated in Frame format;

[0164] TCP binary: assembled into a TCP byte stream according to the private protocol serialization;

[0165] The above encapsulation method encapsulates the data of the transaction order into a standard API request.

[0166] Data Standardization Module: This module defines its internal data structure using a standardized data model (JSON). All fields include a field name, data type, version number, required field identifier, and validation rules. When the interface management module returns transaction responses (such as order number, transaction status, error code, etc.) from different systems, the data standardization module automatically converts them to its internal unified format, eliminating field differences between platforms. This module enables unified data parsing across systems, format compatibility, and unified judgment at the strategy layer, avoiding signal misjudgments or transaction execution deviations caused by inconsistent fields. The data standardization module also supports dynamically expanding fields, allowing the addition or modification of field definitions without altering the upper-level logic, thus ensuring the system's scalability and long-term compatibility across multiple platforms and protocols.

[0167] The intelligent scheduling and execution module includes a high-frequency execution channel and an RPA execution channel. If the task in the standard API request is real-time or latency-sensitive, it is automatically assigned to the high-frequency execution channel; if the task in the standard API request is a multi-step approval or batch operation, it is assigned to the RPA execution channel; if the high-frequency execution channel or the RPA execution channel encounters an anomaly, the channel is automatically switched and retried; finally, the execution transaction results are sent to the risk control and monitoring module.

[0168] Among them, the high-frequency execution channel and the RPA execution channel have the following characteristics:

[0169] High-frequency execution channel:

[0170] It is responsible for completing high-speed transactions in a low-latency environment; the high-speed transaction is a trading method that uses high-speed computers, algorithm models and ultra-low latency networks to perform a large number of buy and sell operations in a very short time (milliseconds or even microseconds), and is mainly used in financial markets such as securities and futures.

[0171] Millisecond-level communication is achieved using shared memory and memory queue mechanisms;

[0172] The execution of instructions adopts an asynchronous submission + synchronous confirmation mode;

[0173] Supports parallel execution of multiple accounts and matching engine routing;

[0174] All results are returned with a timestamp in milliseconds for subsequent auditing purposes.

[0175] RPA execution channel:

[0176] Used to control the automatic execution of complex process tasks;

[0177] Define the execution flow using task templates (e.g., "Log in → Select target → Enter price → Submit").

[0178] Call the target system interface to complete the operation and return the execution status;

[0179] Supports retry on failure, timeout alerts, and manual takeover mechanisms.

[0180] The risk control and monitoring module adopts a component-based rule orchestration architecture. Through a combination of atomic components and EL expression orchestration, it achieves unified management and differentiated execution of heterogeneous high-frequency trading and RPA businesses within the same risk control platform. It can determine in real time whether the execution result triggers risk rules. Risk rules include exceeding limits, duplicate orders, and abnormal slippage. Specifically, the risk control and monitoring module includes the following functions:

[0181] (1) Account risk management: monitoring fund balance, position ratio, number of orders, etc.;

[0182] (2) Strategy risk management: Detecting abnormal trading frequency, price deviation, and duplicate orders;

[0183] (3) Channel health detection: Real-time detection of API response time and availability;

[0184] (4) Security and access control: Perform user authentication, access control and operation log recording.

[0185] The specific implementation method of the risk control and monitoring module is as follows:

[0186] (1) Data standardization input parameters

[0187] Data from the high-frequency execution channel and the RPA execution channel will be parsed by the corresponding adapter and uniformly injected into the RiskContext. All risk control components will only read standardized data such as price and symbol from this context to ensure the consistency of the judgment criteria.

[0188] (2) Perform component checks according to link rules

[0189] HFT Fast Link: According to the THEN(A,WHEN(B,C)) rule, the capital check component A is executed serially first; if the capital check component A determines that there is no risk, the position check component B and the slippage monitoring component C are triggered in parallel.

[0190] RPA interaction link: According to the THEN(A,SWITCH(D).to(E,F)), the funds check component A is executed first; if there is no risk, the OCR recognition result component D is called, and then the process is dynamically routed to the processing component E or the processing component F to perform the check based on the return value of the OCR recognition result component D.

[0191] (3) Preemptive risk assessment for parallel detection

[0192] Components that execute in parallel (such as position checking component B and slippage detection component C) run using CompletableFuture or a separate thread pool, and are configured with ignoreError=false. If any parallel component determines that a risk has been triggered, the engine will immediately interrupt other threads and return a rejection instruction; only when all parallel components determine that there is no risk will the subsequent process proceed.

[0193] (4) Real-time update determination of dynamic rules

[0194] If dynamic risk control rules are configured using script components such as Groovy and QLExpress, the rule engine will listen for configuration changes and hot-load the scripts. The new judgment logic can be embedded into the execution chain without restarting the JVM and participate in real-time risk judgment.

[0195] The log and replay module is responsible for recording the entire transaction activity and providing a complete traceability mechanism; the log and replay module specifically includes the following functions:

[0196] (1) Transaction log records: including instruction ID, channel type, interface parameters, response time, and result status;

[0197] (2) Execution trajectory replay: The entire transaction process can be replayed according to the timeline or task ID;

[0198] (3) Anomaly tracking: Automatically mark failed steps and generate anomaly reports;

[0199] (4) Compliance audit export: Supports exporting standard format reports to meet regulatory requirements.

[0200] The data feedback and strategy optimization module is used to normalize the execution results of trades and input the processed results as execution data into the strategy decision module. The strategy model in the strategy decision module automatically adjusts the threshold parameters based on the feedback to generate a new feedback processing model, thus forming a self-learning closed loop. The data feedback and strategy optimization module also supports historical data comparison and analysis to automatically identify the trend of strategy return rate changes. The optimization results can be automatically written back to the strategy engine to trigger a new round of trade execution.

[0201] The above description is merely the optimal embodiment of the present invention and is not intended to limit the present invention. Any modifications or substitutions made by those skilled in the art without departing from the essence and scope of protection of the present invention should also be within the scope of protection of the present invention.

Claims

1. An intelligent trading method integrating high-frequency trading and RPA automatic control, characterized in that, include: S1. Preprocessing and Strategy Generation: Collect market data and execution data and preprocess them, then generate trading strategies through strategy models; S2, Standardized Instructions and Transmission: Encapsulate trading strategies into standard API requests, and convert the data in the standard API requests into standardized trading instructions for transmission to the scheduling engine; S3. Intelligent Scheduling: The scheduling engine automatically selects the execution channel based on the task type and real-time indicators in the standardized trading instructions. The execution channel includes a high-frequency execution channel or an RPA execution channel. S4. Output execution results: Execute transactions in the high-frequency execution channel or RPA execution channel according to standardized trading instructions, and output the execution results; S5. Risk Monitoring: Monitor the risks associated with the execution results of transactions to determine whether the execution results trigger risk rules. If triggered, it will automatically execute commands to cancel the order, downgrade the channel, or freeze the task; If not triggered, proceed to step S6; S6. Result Storage and Analysis: Store the execution results of the transactions and upload them to the log. At the same time, send the execution results back to S1 as execution data. Optimize the strategy model using the execution data to generate a new strategy model.

2. The intelligent trading method integrating high-frequency trading and RPA automatic control according to claim 1, characterized in that, The specific steps for generating a new policy model in S6 are as follows: S611. After the execution data is returned to S1, the execution data is preprocessed, and features that can predict the strategy performance or execution performance are extracted from the preprocessed data as input variables of the strategy model. S612. Construct labels and use the returned execution data to label historical data to clarify the target results that the strategy model needs to predict. S613. Using features as input variables and labels as targets, select a strategy model or fine-tune parameters. At the same time, optimize the strategy model by time series segmentation, feature selection and hyperparameter tuning to obtain a new strategy model. S614. Conduct offline verification and backtesting of the new strategy model: Backtest the new strategy model using historical market data and execution data, compare key indicators and perform statistical significance tests to determine whether the new strategy model has the potential to be launched; at the same time, further verify the robustness of the model through out-of-sample testing. S615. Randomly select 1% to 5% of small traffic by account or transaction type to import the new strategy model, while monitoring key indicators and verifying the performance of the new strategy model in a real market environment; in addition, indicator thresholds and automatic rollback rules are set to prevent the model from becoming abnormal in real-world scenarios and reduce the risk of going live. After S616 and small-volume verification meet the standards, gradually expand the volume to full release. At the same time, through version management, version control is carried out on past strategy models to ensure traceability and rollback. The risks of this part of the volume are closely monitored to promptly discover and deal with problems caused by the failure of new strategy models or market changes. The monitoring data is fed back to S611 to form a complete closed loop of strategy iteration.

3. The intelligent trading method integrating high-frequency trading and RPA automatic control according to claim 1, characterized in that: In S3, during the process of the scheduling engine selecting either the high-frequency execution channel or the RPA execution channel, the operating status and performance indicators of the high-frequency execution channel and the RPA execution channel are sampled and analyzed in real time. Performance indicators include: average response latency, instruction execution success rate, anomaly frequency, and task congestion level. Simultaneously, a dynamic weight calculation model is constructed based on these performance indicators: by weighting the performance indicators, the channel health score corresponding to the high-frequency execution channel and the RPA execution channel is calculated. The calculation of the health score H is illustrated below: H = α × (1 / Delay Standardization Value) + β × Success Rate - γ × Abnormal Frequency - δ × Queue Length; Where α, β, γ, and δ are the weighting coefficients for average response latency, instruction execution success rate, anomaly frequency, and task congestion, respectively, which can be dynamically adjusted based on experience or historical data; the latency standardization value is the ratio of the current average latency to the historical baseline latency; the success rate is the proportion of transactions successfully executed per unit time; the anomaly frequency is the number of interface errors or timeouts per unit time; and the queue length is the number of tasks currently waiting to be executed. The scheduling engine automatically adjusts the task allocation ratio and channel priority of high-frequency execution channels and RPA execution channels based on the health score of the execution channels.

4. The intelligent trading method integrating high-frequency trading and RPA automatic control according to claim 3, characterized in that: When the health score of a high-frequency execution channel or RPA execution channel falls below a preset threshold, the following adjustment strategy will be automatically applied to the corresponding channel: (1) Reduce the weight coefficient of this channel in the scheduling; (2) Reduce the number of new tasks assigned; (3) Prioritize assigning new tasks to the channel with a higher health score; (4) If the health score continues to decline, the channel will be temporarily frozen and enter a pending recovery state; (5) Simultaneously trigger log recording and operation and maintenance alarm mechanisms; Once the health score of the channel recovers and continuously reaches the safety threshold, the channel's weight coefficient in scheduling will be gradually restored to avoid instantaneous fluctuations impacting the trading system.

5. The intelligent trading method integrating high-frequency trading and RPA automatic control according to claim 3, characterized in that, In S6, the optimized new policy model has the following effect on the scheduling engine: S621. Feed back the real-time performance metrics of the high-frequency execution channel and RPA execution channel obtained through the new strategy model to the scheduling engine, which become the latest input parameters of the dynamic weight calculation model. S622: The scheduling engine updates the weight coefficients in the dynamic weight calculation model in real time or periodically based on the latest input parameters, and recalculates the health scores of the high-frequency execution channel and the RPA execution channel. S623. The scheduling engine automatically changes the task allocation ratio and channel priority of the high-frequency execution channel and the RPA execution channel based on the updated health score, thereby affecting the execution path selection of the next batch of tasks.

6. The intelligent trading method integrating high-frequency trading and RPA automatic control according to claim 1, characterized in that, The preprocessing operations in S1 include: (1) Deduplication: Remove duplicate records or duplicate receipts; (2) Time alignment: Align multi-source data according to a unified clock and timestamp precision; (3) Unit conversion: unifying the units of price, quantity, and time; (4) Missing value handling: Imput or discard missing values ​​for key fields; (5) Outlier removal or marking: Extreme delay values ​​are marked as outliers and processed separately.

7. The intelligent trading method integrating high-frequency trading and RPA automatic control according to claim 1, characterized in that, The specific operations for storing transaction results in S6 include: S631. Write the execution results of the transactions into the database according to the time sequence and generate storage records; S632. Generate a digest hash for each stored record and store it as evidence; S633, aggregate delay distribution, success rate, and slippage distribution metrics are written into a statistics table.

8. The intelligent trading system integrating high-frequency trading and RPA automatic control according to claim 1, characterized in that, include: The strategy decision-making module is used to collect market data and execution data, generate trading strategies, and send them to the interface management module. The interface management module is used to validate the content of the trading strategy. Once the validation is successful, a trading order is generated and the trading order is encapsulated into a standard API request. The data standardization module is used to convert data in standard API requests into standardized transaction instructions and send them to the intelligent scheduling and execution layer. The intelligent scheduling and execution layer includes a high-frequency execution channel and an RPA execution channel. If the task in the standard API request is real-time or latency-sensitive, it is automatically assigned to the high-frequency execution channel; if the task in the standard API request is a multi-step approval or batch operation, it is assigned to the RPA execution channel; if the high-frequency execution channel or the RPA execution channel encounters an anomaly, the channel is automatically switched and retried; finally, the execution transaction results are sent to the risk control and monitoring module. The risk control and monitoring module determines in real time whether the execution result triggers risk rules; Risk rules include exceeding limits, duplicate orders, and abnormal slippage; The log and replay module is used to record the entire transaction activity and provides a complete traceability mechanism. The data feedback and strategy optimization module is used to clean and normalize the execution results of the transactions and then send the processed results back to the strategy decision module.

9. The intelligent trading system integrating high-frequency trading and RPA automatic control according to claim 7, characterized in that, The interface management module includes: Interface module: Used to read basic information records of the interface and generate configuration metadata including protocol type, field mapping table, and authentication method; Parameter mapping and format conversion module: Based on the field mapping rules in the configuration metadata, it performs "standard field → target field" mapping on the trading strategy, as well as format conversion such as precision truncation, date formatting, and type conversion, outputs the target system's structured data, and finally generates a trading order. Interface security module: Used to strengthen the security of structured data in transaction orders; Protocol parsing module: Determines the protocol type based on the configuration metadata, selects the corresponding encapsulation method, and encapsulates the transaction order data into a standard API request.

10. The intelligent trading system integrating high-frequency trading and RPA automatic control according to claim 7, characterized in that: The risk control and monitoring module adopts a component-based rule orchestration architecture. Through the combination of atomic components and EL expression orchestration, it achieves unified management and differentiated execution of heterogeneous businesses such as high-frequency trading and RPA under the same risk control platform.

Images