Multi-factor quantitative transaction modeling and automatic execution platform based on artificial intelligence

Abstract

The invention belongs to the technical field of financial science and technology, and discloses a multi-factor quantitative transaction modeling and automatic execution platform based on artificial intelligence. The platform comprises a data acquisition and access module, a data preprocessing and factor management module, a strategy modeling and configuration module, a model training and effect evaluation module, a back test and simulation execution module, a real disk transaction execution module, an operation monitoring and risk control module and the like. The platform processes multi-source market data and external data through a unified factor management library, a strategy configuration library and a model version library, constructs a multi-factor artificial intelligence strategy model, generates a transaction instruction in a back test environment and a real disk environment according to a consistent data processing and model calling process, and performs data processing on the transaction instruction. And the transaction is automatically adjusted or limited in combination with a risk monitoring result, so that centralized management and end-to-end automatic execution of a quantitative strategy are realized.

Description

Technical Field

[0001] This invention belongs to the field of financial technology, specifically a multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence. Background Technology

[0002] Quantitative trading technology has been widely adopted in markets such as stocks, futures, and cryptocurrencies. The common practice is to build multi-factor models based on historical market data and some fundamental and macroeconomic data, generate buy and sell signals through programmatic means, and automatically place orders through brokerage or exchange interfaces. Some systems are now beginning to try to introduce machine learning, deep learning and other models to predict price trends, volatility levels or market conditions, and use them to assist in factor selection and timing decisions.

[0003] At the engineering implementation level, existing mass trading systems often separate market data access, factor calculation, strategy modeling, model training, backtesting, and live trading into relatively independent modules. Factor calculation formulas, feature processing rules, and model structures are often stored in a scattered manner in the form of embedded scripts or local configurations. There is a lack of a centralized factor management library and strategy configuration library. The data caliber and model version correspondence between the training phase, backtesting phase, and live trading phase are not clear enough. It is common for the same strategy to show inconsistent signals at different stages and for the cause to be difficult to trace.

[0004] Meanwhile, existing automated trading systems often focus on simple threshold controls at the account level, such as single order limits and daily loss limits. Backtesting results and live trading data are usually compiled separately by different systems. There is a lack of a mechanism to uniformly calculate risk exposure by account, strategy, and asset dimensions and continuously monitor it in conjunction with performance indicators. There is also a lack of closed-loop control capabilities to automatically adjust positions, restrict opening positions, or suspend strategies when drawdowns, abnormal trading concentrations, or interface performance abnormalities are detected. In scenarios where multi-factor models and artificial intelligence prediction models are superimposed and trading frequency is high, the above problems can easily lead to a disconnect between strategy development, model training, backtesting verification, and live trading execution, resulting in insufficient precision in risk identification and control response. Summary of the Invention

[0005] The purpose of this invention is to provide an artificial intelligence-based multi-factor quantitative trading modeling and automatic execution platform to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence. The platform is deployed in the same network environment and integrates data collection, data processing, strategy modeling, model training, backtesting and verification, live trading execution, and operation monitoring and risk control into a closed-loop process. By connecting the research, backtesting and live trading links within a unified platform, the problem of unstable strategy implementation caused by inconsistent data standards, scattered model configurations, disconnect between backtesting and live trading, and fragmented risk control in the prior art is solved. The platform includes at least a data acquisition and access module, a data preprocessing and factor management module, a strategy modeling and configuration module, a model training and performance evaluation module, a backtesting and simulation execution module, a live trading execution module, and an operation monitoring and risk control module. All modules work together under a unified architecture. The data acquisition and access module establishes connections with stock, futures, cryptocurrency exchanges, brokerage firms, and third-party data service interfaces to continuously acquire historical and real-time market data at the tick level and K-line level generated at preset time intervals. It also simultaneously accesses macroeconomic data, news sentiment data, and social media sentiment data. The module adds trading instrument identifiers, data source identifiers, and timestamps to data from different sources and writes them into the data cache, providing a foundation for subsequent unified data processing. The data preprocessing and factor management module reads the aforementioned market data and external data from the data cache. It performs missing value imputation, outlier identification and removal, field name and unit standardization, and time alignment on the read data to form cleaned data with consistent format and timeline. Based on this, it calculates price factors, transaction factors, structural factors, and sentiment factors according to preset rules. It also registers the name, calculation formula, data source, applicable targets, and statistical performance in the historical sample interval of each factor in the factor management library, so as to centrally manage factor information and provide traceable and reusable factor data for the strategy modeling and model training stages. The strategy modeling and configuration module, based on the factors registered in the factor management library, combined with the trading instruments, holding periods, risk constraints and trading restrictions set by the user, selects target factors and constructs a feature set for model input, and builds a strategy model for predicting price trends, volatility levels or market conditions. This module further solidifies the data reading order, feature processing rules, model calling order and trading signal generation rules in a structured way into a strategy configuration file and stores it in the strategy configuration library, thereby abstracting the strategy logic from the code level into a configurable file, which is convenient for consistent calling in the training, backtesting and live trading stages; The model training and performance evaluation module connects the strategy configuration library and the factor management library. Based on the selected strategy configuration file, it extracts the training set, validation set, and test set from the historical data associated with the factor management library. It then trains and adjusts the parameters of the strategy model using the model structure described in the strategy configuration file. After training, the module evaluates the training results according to pre-set return indicators, risk indicators, and stability indicators. Only strategy models that meet the preset standards, along with their parameters, training data time intervals, and applicable scenarios, are registered in the model version library to form a manageable model version system. The backtesting and simulation execution module connects the strategy configuration library, model version library, and factor management library. In the backtesting environment, it calls the target strategy configuration file and target model version, loads historical factor data from the factor management library that uses the same field caliber and time alignment rules as the live execution phase, and drives the strategy model to generate trading signals along the historical time axis according to the data reading order and feature processing flow recorded in the strategy configuration file. Under the pre-set matching rules, slippage rules, and fee structure, the module simulates order submission, matching transactions, and position changes, and outputs a backtesting result report containing the profit curve, historical maximum drawdown, capital usage, and transaction details, providing a basis for performance evaluation before the strategy goes live. The live trading execution module connects the model version library, strategy configuration library, and data acquisition and access module. During live trading, it calls the strategy configuration file and model version that have been backtested and verified. It receives market data and external data pushed by the data acquisition and access module in real time. It generates live trading signals according to the same data reading and feature processing process as in the backtesting phase and converts the trading signals into trading instructions in a unified format within the platform. Before submission, the module performs trading frequency checks such as account available funds checks, position limit checks, preset maximum position checks, and minimum order interval checks on the trading instructions. It completes order submission, status query, and cancellation through interaction with exchange interfaces and brokerage interfaces, realizing the automatic execution of the strategy in the live trading environment. The operation monitoring and risk control module connects the data acquisition and access module, the backtesting and simulation execution module, and the live trading execution module. It summarizes the backtesting results and live trading results, calculates and displays risk indicators such as risk exposure, floating profit and loss, and historical maximum drawdown by account, strategy, and asset dimensions. At the same time, it monitors the operation performance indicators such as data acquisition latency, backtesting task execution time, and trading interface response time. When it detects that the drawdown exceeds the preset threshold, trading behavior is abnormally concentrated in a short period of time, or key performance indicators exceed the threshold, this module issues control instructions to the live trading execution module to reduce the position, limit the number of new positions, or suspend the trading of the specified strategy according to the pre-configured control strategy, and records the control actions for timely intervention and subsequent traceability of risk events.

[0007] Furthermore, the data acquisition and access module preferably includes a market data access submodule, an external data access submodule, and a cache management submodule, which are used to access multi-source data under a unified architecture and to perform cache management under a unified timeline and field caliber. The market data access submodule establishes a connection with the network interfaces of stock exchanges, futures exchanges, digital currency trading platforms, and brokerage counter systems. In accordance with the API or protocol specifications provided by each exchange or brokerage, it receives tick-level data of stocks, futures, and digital currencies, as well as K-line level historical market data and real-time market data generated at preset time intervals. When receiving data, it adds a trading instrument identifier, data source identifier, and standardized timestamp to each data item, so that market data from different sources and different instruments can participate in subsequent processing under a unified time benchmark. The external data access submodule establishes connections with APIs or data subscription interfaces of macroeconomic data services, news and public opinion data services, and social media data services. It acquires structured or semi-structured macroeconomic data, news and public opinion data, and text or sentiment index data from social media according to the specifications of each interface. It also parses and standardizes the time field of the acquired data to generate external data records with timestamps and data source identifiers. This allows the external data to correspond with market data on the timeline, providing aligned multi-source information for subsequent factor construction and model training. The cache management submodule receives data from the market data access submodule and the external data access submodule, respectively. Based on the data type and trading instrument, it writes the data into the configured real-time data cache and historical data cache, which are used for short-term high-speed access and long-term persistent storage, respectively. The cached data is organized and indexed in an orderly manner according to the timestamp, so as to provide the data preprocessing and factor management module with a data entry with a unified format and unified time order. This reduces the overhead caused by repeated processing of multi-source data and improves the stability and consistency of the upper-level factor calculation and strategy modeling process.

[0008] Furthermore, the data preprocessing and factor management module can be divided into a data cleaning sub-module, a factor calculation sub-module, and a factor registration sub-module. These are used to complete the cleaning and processing of multi-source data, factor calculation, and centralized management of factor information under a unified data standard, providing a stable and traceable factor data foundation for subsequent strategy modeling and model training. The data cleaning submodule is connected to the data acquisition and access module. It reads market data and external data from the aforementioned data cache according to trading varieties and timestamps. It performs missing value filling, abnormal data identification and removal, field name and unit of measurement unification, and cross-market and cross-variety time alignment processing on the read data to obtain cleaned data with consistent format and unified time axis. Through the processing of this submodule, heterogeneous data from different exchanges and different data service providers are normalized to a unified data structure and time benchmark, reducing the interference caused by data source differences in subsequent factor calculation and model training stages. Based on this, the factor calculation submodule takes the cleaned data as input, calls the calculation formulas registered in the factor management library, and calculates price factors, transaction factors, structural factors and sentiment factors respectively to form corresponding factor sequences. The factor management library saves the calculation formulas of various factors in the form of parsable expressions or scripts. The system parses and executes these expressions at runtime, thereby maintaining and expanding the factor set without changing the underlying program structure, enabling the platform to adjust the factor combination according to different market environments or research needs. The factor registration submodule is used to register the metadata of each factor, such as its name, calculation formula, data source, applicable trading targets, and value distribution within a preset historical sample range, into the factor management library. It also provides a standardized access interface for the strategy modeling and configuration module and the model training and performance evaluation module to call. In this way, the platform manages the factor calculation results and their background information in a unified manner, which facilitates the tracing of factor definitions and sources during strategy design, training, and evaluation, and reduces the deviation between backtesting and live trading results caused by inconsistent factor definitions.

[0009] Furthermore, the strategy modeling and configuration module can be further subdivided into a factor selection unit, a feature construction unit, a model building unit, and a strategy configuration generation unit. These units are used to complete the construction of the strategy model based on a unified factor system and to solidify the strategy logic in the form of a configuration file, which facilitates consistent calling during model training, backtesting, and live execution. Among them, the factor selection unit selects and determines the target factor set from the candidate factors based on the factor information registered in the factor management library, combined with the trading instruments, holding period and risk constraint parameters set by the user in the strategy configuration. This makes the strategy modeling based on a unified definition of factors and reduces the impact of inconsistent factor definitions on strategy performance. After factor screening is completed, the feature construction unit constructs model input features based on the target factors. The model building unit then builds a strategy model for predicting price trends, volatility levels, or market conditions, and records the model structure and corresponding parameter information. This ensures that the model has a clear structural description and parameter representation within the platform, facilitating subsequent calling and management. The strategy configuration generation unit is used to organize the identification of target factors, the reference method of feature processing rules, model structure and parameter information, sample partitioning rules, and trading signal generation rules into a structured strategy configuration file, and store the configuration file in the strategy configuration library. In this way, the strategy logic is extracted from the program code into a parsable configuration file. The model training module, backtesting and simulation execution module, and live trading execution module can all complete data reading and model calling based on the same strategy configuration file at runtime, thereby improving the consistency of the process and the convenience of maintenance between different stages.

[0010] Furthermore, the model training and performance evaluation module includes a sample extraction unit, a training unit, an evaluation unit, and a model registration unit, which are used to complete the training, performance evaluation, and version registration of the strategy model based on a unified strategy configuration, so that the trained model is stored in the platform in a versioned form, which is convenient for subsequent backtesting and live trading stages to call according to the specified version. The sample extraction unit extracts training, validation, and test sets from the factor management library according to the pre-defined sample partitioning rules and time intervals in the strategy configuration file. This provides unified control over the partitioning of different strategies in terms of time range and sample structure, reducing differences in training results caused by manual partitioning or inconsistent definitions. The training unit uses the training set as input and performs parameter estimation and iterative updates to the strategy model according to the model structure recorded in the strategy configuration file. It also associates and saves the model parameters generated during training with the training task identifier, ensuring a clear record of the training process and its results within the platform. The evaluation unit calculates the corresponding evaluation indicators and thresholds for profit, risk, and stability categories as specified in the strategy configuration file or platform configuration on the validation or test set, and compares the calculation results with the thresholds to determine whether the currently trained strategy model meets the preset usage conditions. For strategy models whose evaluation results meet the conditions, the model registration unit registers the model's version identifier, trained parameters, time interval of the training data used, and key evaluation indicator values ​​to the model version library, and records the registration time, forming a searchable and comparable model version record. This record is used by the backtesting and live execution modules to call the specified version and trace back to the corresponding training and evaluation process when needed.

[0011] Furthermore, the backtesting and simulation execution module may include a strategy parsing unit, a data loading unit, an execution engine, and a backtesting report unit, which are used to simulate and replay historical data based on a unified strategy configuration and model version, verify the performance of the strategy under different market environments, and provide a reference for strategy deployment. The strategy parsing unit reads the target strategy configuration file from the strategy configuration library and the corresponding target model version from the model version library. It parses the data reading order, feature processing rules, model calling order, and trading signal generation rules recorded in the configuration file, so that the subsequent backtesting process is executed according to the same logic as the live trading stage. The data loading unit loads historical factor data from the factor management library based on the parsing results and organizes the data according to the data reading order recorded in the strategy configuration file. This ensures that the loaded historical factor data is consistent with the caliber used in the live trading stage in terms of field names, units of measurement, and time alignment rules, providing the same data foundation for simulation as for live trading. The execution engine drives the target model version to generate trading signals according to the feature processing rules and model call order determined in the strategy configuration file on the historical timeline. Based on the matching rules, slippage rules, and commission rules preset in the strategy configuration file or platform configuration, it simulates order generation and matching of trading signals, reproducing the process of order submission, matching and execution, and position changes. It provides backtesting results that are close to the actual execution logic without participating in real trading. The backtesting report unit generates backtesting reports based on the simulation results, organizes and saves the transaction details and pre-set performance indicators (such as profit trend, maximum drawdown, and capital usage) for users and the operation monitoring and risk control modules to perform retrospective analysis and comparison, and to evaluate the stability and risk level of the strategy under different parameter configurations and different historical intervals.

[0012] Furthermore, the live trading execution module may include an interface adaptation unit, an instruction generation unit, a verification unit, and a trading interaction unit, used to generate and send trading instructions in a live trading environment according to the backtested strategy configuration and model version, and to maintain a unified instruction format and risk control constraints between different exchange and brokerage interfaces; The interface adaptation unit converts the unified instruction format agreed upon within the platform into the message format required by the interfaces of each target exchange or brokerage, and receives transaction reports and position change information from these interfaces, parses them into the platform's internal record format, and provides a data foundation for subsequent position statistics and risk monitoring. During live trading, the instruction generation unit calls the strategy configuration file and model version that have been backtested and verified. According to the data reading order and feature processing rules determined in the strategy configuration file, it generates trading signals from the market data and external data received by the data acquisition and access module, and converts the trading signals into unified trading instructions within the platform, so that the live execution phase and the backtesting phase are consistent in terms of data processing flow and model calling flow. The verification unit checks the submitted trading instructions based on the numerical verification rules pre-set in the strategy configuration file or platform configuration. The verification rules include at least the constraints such as available funds in the account, position limit, maximum position size for a single strategy, and minimum order interval. For trading instructions that do not meet the constraints, the verification unit selects to reject them or adjusts the instruction parameters according to the rules based on the configuration, and records the verification results in the log for post-event verification and risk analysis. The trading interaction unit sends verified trading instructions to the corresponding exchange or brokerage interface according to the message format converted by the interface adaptation unit. It receives and parses transaction reports and position change information, writes the parsing results to the trading log, and feeds them back to the operation monitoring and risk control module. This enables order status tracking, position updates, and risk exposure monitoring during live trading. Through the collaboration of these units, the live trading execution module, while ensuring consistency between backtesting and live trading logic, introduces real-time risk control checks at the account and strategy levels to reduce live trading risks caused by abnormal instructions or trading frequency.

[0013] Furthermore, the operation monitoring and risk control module includes a data aggregation unit, a risk calculation unit, a performance monitoring unit, an alarm judgment unit, and a control distribution unit, which are used to aggregate and analyze backtesting results and live trading results within a unified platform, calculate risk indicators by account dimension, strategy dimension, and asset dimension, and intervene in live trading execution when risk indicators or abnormal operation performance are detected. The data aggregation unit receives backtesting reports from the backtesting and simulation execution module and live trading results from the live trading execution module. It organizes and aggregates relevant data according to three dimensions: account, strategy, and asset, providing a unified data foundation for subsequent risk calculation and alarm determination. The risk calculation unit calculates risk exposure based on the data organized by the data aggregation unit, according to the account, strategy, and asset dimensions. The risk exposure includes at least the net position value converted according to the latest market price, the current floating profit and loss, and the historical maximum drawdown obtained according to the strategy net value sequence. The calculation results are saved for query and comparison. The performance monitoring unit is used to monitor and record operational performance indicators such as data acquisition latency, backtesting task execution time, and transaction interface response time, enabling the platform to simultaneously focus on strategy risks and system operation status during operation. The alarm judgment unit compares the values ​​of various indicators output by the risk calculation unit and the performance monitoring unit with the corresponding thresholds stored in the strategy configuration file or platform configuration, and identifies abnormally concentrated trading behaviors in a short period of time according to the transaction abnormal concentration judgment rules defined in the platform configuration. An alarm event is generated when any risk indicator or performance indicator exceeds the threshold or when abnormally concentrated trading occurs. Based on alarm events and according to the control policies predefined in the strategy configuration file or platform configuration, the control issuing unit issues control instructions to the live trading execution module to reduce positions, limit the number of new positions, or suspend trading under specified strategies. The control instructions and their execution results are recorded in the operation log for subsequent risk event review and accountability. Through the collaborative work of the above units, the platform forms a risk control closed loop between strategy backtesting, live trading execution, and operation monitoring, and can constrain live trading behavior when anomalies are detected.

[0014] The beneficial effects of this invention are as follows: 1. This invention achieves unified access, unified cleaning, and unified factor registration for multi-source market data and external data by setting up a data acquisition and access module, a data preprocessing and factor management module, a strategy modeling and configuration module, and a model training and performance evaluation module, and by introducing a factor management library, strategy configuration file, and model version library. This allows for centralized management of factor definitions, feature processing rules, model structure, and training intervals within the platform. The training, backtesting, and live trading phases all rely on the same factor management library and strategy configuration, which helps reduce inconsistencies in factor definitions and unclear model versions caused by scattered scripts, and improves the consistency and traceability of multi-factor and artificial intelligence models in the development, adjustment, and maintenance process.

[0015] 2. This invention sets up a backtesting and simulation execution module and a live trading execution module, both based on the same strategy configuration file and model version. During the backtesting phase, the target model is driven to generate trading signals on the historical timeline according to the same data reading order and feature processing rules as live trading, reconstructing the order and position change process under preset matching, slippage, and commission rules. During the live trading phase, through an interface adaptation unit, instruction generation unit, verification unit, and trading interaction unit, the unified trading instructions are converted into messages recognizable by various exchange or brokerage interfaces and executed. This structure maintains the consistency between the backtesting logic and the live trading execution path at the configuration level, facilitating the comparison of backtesting results and live trading performance, and reducing the risk of inconsistent strategy behavior at different stages.

[0016] 3. This invention, by setting up an operation monitoring and risk control module and linking the data aggregation unit, risk calculation unit, performance monitoring unit, alarm judgment unit, and control issuance unit, can aggregate backtesting reports and live trading results at the account, strategy, and asset dimensions. It calculates risk exposure indicators such as net position value, floating profit and loss, and historical maximum drawdown based on the latest market conditions. At the same time, it monitors operational performance such as data collection delay, backtesting task execution time, and trading interface response time. When any risk or performance indicator exceeds a preset threshold, or when abnormal concentration of trading occurs, the module automatically issues control instructions to the live trading execution module to reduce positions, restrict new positions, or suspend strategies, forming a closed loop from monitoring and judgment to intervention. This is beneficial for controlling the operational risks of strategies in complex market environments. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the overall closed-loop process of the platform of this invention. Figure 2 This is a flowchart of the factor and model management process of the present invention; Figure 3 This is a flowchart illustrating the transaction execution and risk control process of this invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] like Figures 1 to 3 As shown, this embodiment of the invention provides a multi-factor quantitative trading modeling and automated execution platform based on artificial intelligence. Deployed in the same network environment, it can utilize multiple servers in the same data center or cloud environment, communicating through an internal network. The platform constructs a closed-loop process around the research and execution of quantitative strategies, from data acquisition, data processing, strategy modeling, model training, backtesting verification to live execution and risk control. In this embodiment, the platform includes functional modules such as a data acquisition and access module, a data preprocessing and factor management module, a strategy modeling and configuration module, a model training and performance evaluation module, a backtesting and simulation execution module, a live trading execution module, and an operation monitoring and risk control module. The modules collaborate with each other through predefined data interfaces and configuration files. The data acquisition and access module establishes connections with stock, futures, cryptocurrency exchanges, brokerage firms, and third-party data service interfaces to continuously acquire tick-level data and K-line-level historical and real-time market data generated at preset time intervals. It also receives macroeconomic data, news sentiment data, and social media sentiment data. The module adds trading instrument identifiers and timestamps to data from different sources and writes them into the data cache to form a unified data entry point. The data preprocessing and factor management module is connected to the data acquisition and access module. It reads the aforementioned market data and external data from the data cache, performs missing value imputation, outlier identification and removal, field standardization, and time alignment on the read data, and obtains cleaned data with consistent format and timeline. On this basis, it calculates price factors, transaction factors, structural factors, and sentiment factors, and registers the calculation formula, data source, applicable targets, and historical performance of each factor in the factor management library, providing unified and traceable factor data for subsequent strategy modeling and model training. The strategy modeling and configuration module connects to the factor management library. Based on the factors registered in the factor management library, and combined with the user-defined trading instruments, holding periods, risk preferences, and trading constraints, it selects target factors and constructs model input features to establish a strategy model for predicting price trends, volatility levels, or market conditions. At the same time, it organizes the data reading order, feature processing steps, model calling order, and trading signal generation rules into a strategy configuration file and stores it in the strategy configuration library, so that the strategy logic can be reused in subsequent stages in a configurable manner. The model training and performance evaluation module connects the strategy configuration library and the factor management library. Based on the selected strategy configuration file, it extracts training samples from the historical data associated with the factor management library, trains the strategy model and adjusts the parameters, and evaluates the training results according to the pre-set return indicators, risk indicators and stability indicators. Only the strategy models that pass the evaluation, their parameters, training data ranges and applicable scenarios are registered in the model version library to form a manageable set of model versions. The backtesting and simulation execution module connects the strategy configuration library, model version library, and factor management library. In the backtesting environment, it calls the target strategy configuration file and target model version, loads historical factor data from the factor management library that uses the same field caliber and time alignment rules as the live execution phase, drives the strategy model to generate trading signals along the historical time axis according to the data reading order and feature processing steps in the strategy configuration file, and simulates order submission, matching transactions, and position changes under preset matching rules, slippage models, and fee structures. It outputs a backtesting result report containing the profit curve, maximum drawdown, capital utilization rate, and transaction details for effect verification before the strategy goes live. The live trading execution module connects to the model version library, strategy configuration library, and data acquisition and access module. During live trading, it calls the strategy configuration files and model versions that have been backtested and verified. It receives market data and external data pushed by the data acquisition and access module in real time, generates trading signals according to the same data reading and feature processing process as in the backtesting phase, and converts the trading signals into trading instructions in a unified format within the platform. Before submitting a trading instruction, it checks constraints such as available funds in the account, existing positions, preset maximum position size, and minimum order interval. Through interaction with the exchange interface and brokerage interface, it completes the submission, status query, and cancellation of orders, realizing the automatic execution of the strategy in the live trading environment. The operation monitoring and risk control module connects the data acquisition and access module, the backtesting and simulation execution module, and the live trading execution module. It summarizes the backtesting results reports and live trading results, calculates indicators such as risk exposure, floating profit and loss, and historical maximum drawdown by account, strategy, and asset dimensions, and monitors operational performance parameters such as data acquisition latency, backtesting task execution time, and trading interface response time. When it detects that the drawdown exceeds the preset threshold, trading behavior is abnormally concentrated in a short period of time, or key performance indicators exceed the threshold, it issues control instructions to the live trading execution module to reduce positions, limit the number of new positions, or suspend trading of specified strategies according to the preset control strategy, and records the relevant control actions for subsequent risk event analysis and operational status tracing.

[0020] The data acquisition and access module can be deployed in an independent service process as a unified data entry point for the entire platform. This module includes three parts: market data access sub-module, external data access sub-module, and cache management sub-module. Data is transmitted between the sub-modules through message queues and internal interfaces, so that multi-source data from different markets and service providers have completed format unification and time alignment before entering the subsequent factor calculation and model training stages. Implementation method of market data access submodule In this embodiment, the market data access submodule establishes network connections with the market data interfaces provided by stock exchanges, futures exchanges, cryptocurrency trading platforms, and brokerage counter systems; specifically, the following steps are taken: For each data source, the interface address, authentication method (such as API key or certificate), list of subscription target codes, and supported data granularity (Tick level, 1-minute candlestick chart, 5-minute candlestick chart) are pre-registered in the configuration file. The market data access submodule completes login and subscription according to the configuration when it starts up. For tick-level data, the market data access submodule receives fields such as buy / sell direction, price, quantity, and transaction time according to the data source protocol; for candlestick-level data, it receives fields such as opening price, closing price, highest price, lowest price, and trading volume. To ensure cross-source alignment in the future, each received market data record is written to the internal message queue with three standard fields: trading instrument identifier (such as exchange code + contract code), data source identifier, and a unified timestamp. The unified timestamp can be generated by parsing the local time provided by the data source into UTC time and then converting it into a unified millisecond-level integer representation within the platform. The market data access submodule encapsulates the processed market data records into a unified internal data structure (such as a key-value pair set containing "product identifier, timestamp, data source identifier, data type, field name and its value"), and pushes it to the cache management submodule through a message queue, thereby shielding the differences in protocol formats between the interfaces of various exchanges and securities firms, making it convenient for downstream modules to consume directly; Implementation method of external data access submodule The external data access submodule is used to import non-traditional market data such as macroeconomic data, news sentiment data, and social media sentiment data. In this embodiment: For macroeconomic data, the external data access submodule pulls or receives structured data pushed by macro data service providers on a regular basis according to the interface specifications provided by the macro data service provider. This includes data such as GDP indicators, interest rate data, and inflation index. Each record contains fields such as indicator name, statistical scope, publication time, and country or region. For news and public opinion data, the submodule obtains pre-processed structured or semi-structured records from the news and public opinion service interface, including at least the news release time, source media, associated target code or industry tag, and the field of public opinion score calculated by the server. For social media sentiment data, the submodule can receive sentiment index or emotion score results obtained from social media text analysis provided by data service providers, which at least include sampling time, sentiment index value, indicator description and optional associated targets or topic tags; For the three types of external data mentioned above, the external data access submodule uniformly parses and standardizes the time field, converting the release date, release time, or statistical time in each interface into a unified timestamp in the same format as the market data. At the same time, it adds a data source identifier field. The final generated external data record is also encapsulated into a unified internal structure, with fields including at least: timestamp, data source identifier, data category (macro, news, sentiment), associated target or theme, and one or more numerical or categorical indicator values. This design is beneficial for the subsequent factor management module to directly calculate macro factors and sentiment factors based on data in a unified format, avoiding repeated processing of heterogeneous interfaces in each strategy or model. Implementation of the cache management submodule The cache management submodule subscribes to internal data streams from the market data access submodule and the external data access submodule, and stores the received records according to data type and trading instrument. In this embodiment, the cache management submodule maintains a two-level cache. Real-time data caching is used to store high-frequency data from a recent period (e.g., the last few hours or trading days). It can be implemented using a resident database or a memory caching component to support low-latency access to the latest data by subsequent modules during live trading or backtesting preloading phases. Historical data caching is used to store complete historical data over a longer time span. It can be stored in a columnar database to support batch querying and playback by time range and variety. When writing to the cache, the cache management submodule first selects the corresponding table or key space based on the trading instrument identifier and data category (market data or external data) in the data record. Then, it inserts or appends the data in ascending order of timestamp. At the same time, it establishes a time index structure for each instrument (e.g., an index with the instrument identifier + timestamp range as the key) so that the data preprocessing and factor management modules can pull multi-source data within a specified time window in a unified time order. This achieves alignment of tick-level and candlestick-level market data with macroeconomic, public opinion, and sentiment indicators on the time axis. For cases where there are multiple records from different sources within the same timestamp, the cache management submodule determines the merging strategy through data source identifiers and priority rules. For example, it prioritizes using exchange-direct market data as the main source of price data, and uses brokerage or third-party market data as a supplement or verification.

[0021] Among them, the data preprocessing and factor management module is deployed as an independent service. It is used to cache multi-source data output from the data acquisition and access module, standardize the data, and uniformly manage the factor calculation logic. This module includes a data cleaning submodule, a factor calculation submodule, and a factor registration submodule. The submodules work together through internal interfaces and factor management library. The data cleaning submodule establishes a connection interface with the data cache of the data acquisition and access module, supporting batch reading of market data and external data according to the format of trading instrument identifier + timestamp range. To ensure that data from different sources can be processed uniformly, the data cleaning submodule in this embodiment performs at least the following processing steps: Missing value imputation For tick-level and candlestick-level data, key fields such as price and volume are checked in the order of timestamps. For occasionally missing records, the most recent valid value within the same trading day can be used to fill the gaps, or linear interpolation can be used between two adjacent valid records. When implementing this, those skilled in the art can select specific filling strategies through configuration to adapt to the characteristics of different varieties and data sources. For macroeconomic data and public opinion / sentiment data, when there are missing indicators within a certain statistical period, the data service provider can fill the gap with the previous period's indicator value based on the previous period's value, or mark it as unusable and remove it in the subsequent factor calculation stage, according to the previous period's value, the previous period's value, or the previous period's indicator value. Anomaly identification and removal: The data cleaning submodule identifies anomalies based on thresholds and statistical methods. For example, a reasonable fluctuation range can be set for the price field. When the price change of a single record relative to the previous record exceeds a set proportion, and the exchange has not marked it as an adjustment or split event, the record is marked as an anomaly. For the trading volume field, quantile intervals can be calculated based on historical distributions, and isolated peaks that significantly exceed the upper quantile are marked. Records marked as anomalies are ignored in subsequent factor calculations, or their reasonable values ​​are re-estimated through interpolation. Unified Field Names and Units: Field names and units of measurement may differ between exchanges or data service providers. For example, trading volume may be measured in "number of shares" or "lots," and prices may be given with different levels of precision. The data cleaning submodule maintains a field mapping table to map field names from various data sources to the platform's standard field names. When writing cleaned data, the units are unified to the agreed-upon units (such as "shares" and "yuan"). At the same time, the original units and conversion ratios are recorded in the metadata for easy traceability later. Cross-market time alignment processing: For records of the same trading instrument from different data sources, the data cleaning submodule constructs a timeline based on standardized timestamps, resampling or aligning tick-level and candlestick-level data. For example, when calculating 1-minute candlestick-level factors, tick-level data can be aggregated into opening price, highest price, lowest price, closing price, and volume within a 1-minute time window. For external sentiment and opinion data, indicators can be aligned to the corresponding market time periods at minute-level or longer granularity. The cleaned data obtained through the above processing maintains consistency in fields and time dimensions, providing a foundation for subsequent multi-source factor calculations. The cleaned data is stored in the intermediate data area in the form of trading instrument identifier + timestamp + standard field set. All other sub-modules in the data preprocessing and factor management modules operate based on this unified format. In this embodiment, the factor calculation submodule adopts a configuration-driven calculation approach, and its calculation logic comes from the calculation formulas registered in the factor management library. The factor management library stores the calculation rules of various factors in the form of parsable expressions or scripts. Those skilled in the art can use expression trees, SQL fragments or script languages ​​to describe these formulas, so that the platform can parse and execute them at runtime. In practice, the factor calculation submodule can work according to the following process: Based on the task configuration, the list of price factors, transaction factors, structural factors, and sentiment factors to be calculated is read from the factor management library, along with the input fields, time window length, and calculation formula identifier for each factor. Extract the required field sequences from the cleaned data according to the trading varieties and time ranges. Price factors can be calculated based on closing price or high and low price sequences, transaction factors can be calculated based on transaction volume or transaction amount sequences, structure factors can be combined with buy and sell order structures or transaction details, and sentiment factors can be calculated based on fields such as news sentiment scores or social media sentiment indices. The expression parsing engine or script execution environment is invoked to call the corresponding calculation formula for each time point according to a preset time window, generate factor values, and output the results in time series format. The output format is uniformly "factor name + trading instrument identifier + timestamp + factor value". To enable those skilled in the art to implement this directly, typical calculation formula examples for various factors are given below: Example of price-related factors: N-day simple moving average price factor : ; In the formula: The current trading time (which could be the closing time of a trading day or the end time of a candlestick chart); The length of the moving average time window (e.g., 5, 10, 20); At a certain point in time The closing price; At a certain point in time The calculated N-day simple moving average price; N-day return volatility factor σ N First, define the logarithmic return for a single period: ; The average return over the window [t-N+1, t] is: ; The corresponding volatility factor is: ; In the formula: : The logarithmic return of a single period at time point t; Average return within the window; : Volatility of returns when the window length is N; Example of a transaction-related factor: N-day average trading volume factor : ; In the formula: At a certain point in time The trading volume (which has been standardized to a common unit, such as shares, during the data cleaning stage); : A moving average of trading volume with a window length of N; Current quantity relative to mean factor : ; In the formula: The ratio of current trading volume to the N-day average trading volume is used to indicate the degree of increase or decrease in trading volume. Example of structural factors: Taking the order volume of the M-level order book at a certain moment as an example, define the ratio of buy and sell order differences as a factor. : ; In the formula: : The order volume of the i-th order among the buy orders from buy order 1 to buy order M at time point t; : The volume of sell orders in the j-th price range from sell order 1 to sell order M at time point t; M: The number of order book levels involved in the calculation, such as 5 or 10 levels; The percentage difference between buy and sell orders, ranging from -1 to 1, reflects the relative strength of buy and sell orders. Examples of emotion-related factors: Taking news and public opinion data as an example, within the time window Within, the news entries associated with the target of the transaction are recorded as follows: =1,..., Each news item has an emotional score. and weight (For example, it can be related to the release time interval or media ranking); Define the news sentiment weighted index factor NEWS_SENT(t): ; In the formula: The length of the sentiment statistics window, such as 1 hour or 1 trading day; In the window The number of news items related to this target; : No. The sentiment score for each news item can be in the range of [-1, 1], with positive values ​​indicating bullish sentiment and negative values ​​indicating bearish sentiment. : No. The weight of each news item can be reduced over time or set according to the importance of the media. NEWS_SENT(t): News sentiment weighted index at time point t, used to reflect the sentiment tendency of public opinion towards the benchmark in a recent period; Similarly, for social media sentiment data, sentiment indexes or emotional scores can be used as... A weighted average method similar to that described above is used to construct sentiment factors; Implementation of the factor registration submodule The factor registration submodule is used to maintain metadata information and access interfaces in the factor management library, enabling the strategy modeling and configuration module, as well as the model training and performance evaluation module, to reference factors in a unified manner.

[0022] Its main functions include: Metadata Registration When a factor is added or modified, the factor registration submodule registers the factor's name, calculation formula identifier, data source (such as market data, macro data, news data, and sentiment data), and applicable trading instruments (such as applicable only to stocks or futures) in the factor management library, and records the list of fields that the factor depends on and the length of the time window. Historical value distribution statistics To support subsequent feature selection and standardization processing before model training, the factor registration submodule can calculate statistical characteristics for each factor on a preset historical sample interval (such as several years of historical transaction data), including minimum, maximum, mean, standard deviation and several quantiles; the calculated value distribution information and factor metadata are stored together for subsequent modules to directly call when performing factor selection (such as filtering factors that have hardly changed over a long period of time) or feature scaling. Access interface provided The factor registration submodule provides a unified access interface for the strategy modeling and configuration module as well as the model training and performance evaluation module. The interface supports retrieving existing factor sequences by factor name, target range, and time interval. It also supports returning the corresponding metadata and value distribution information of the factors. Through this interface, when defining the input features of the strategy model, the upper-level module only needs to reference the factor name and target set, without having to directly manipulate the underlying data table structure.

[0023] The strategy modeling and configuration module is deployed as an independent application service, interacting with the factor management library, model training and performance evaluation module, and backtesting and simulation execution module through internal interfaces. The strategy modeling and configuration module consists of a factor selection unit, a feature construction unit, a model building unit, and a strategy configuration generation unit. It converts the factors registered in the factor management library into features that can be input into the artificial intelligence model, and solidifies the model structure and trading signal generation rules in the form of a machine-parseable strategy configuration file, ensuring consistency of the same configuration throughout the model training, historical backtesting, and live execution phases. Implementation of factor selection unit In this embodiment, the factor selection unit establishes an interface connection with the factor management library, and can retrieve factors based on the trading instrument identifier, factor type, and time interval. The factor management library registers metadata such as name, data source, applicable trading instrument range, time window length, and historical value distribution for each factor. The factor selection unit performs factor screening based on the above metadata and user-side configuration. Specifically, users specify the target set of trading instruments (e.g., a stock pool, a group of futures contracts, or a cryptocurrency trading pair), the expected holding period (e.g., intraday, short-term, or medium-to-long-term), and risk constraint parameters (e.g., maximum acceptable drawdown, factor limit, etc.) in the strategy configuration draft through the platform's front-end interface or API. After reading the draft configuration, the factor selection unit first filters out candidate factors from the factor management library that have complete historical data on the specified trading instruments and cover the specified training sample range. Then, based on the historical value distribution information registered in the factor management library, it removes factors that have hardly changed in the long term or have excessively high missing rates. On this basis, it can control the redundancy between factors according to preset correlation rules. For example, when the correlation coefficient between two candidate factors in the historical sample range is higher than a preset threshold, only one of them is retained. After the above screening, the factor selection unit generates a list of target factors. The list records the unique identifier, factor type, data source mark and time window parameters of each target factor. The list of target factors is then passed to the feature construction unit as the basis for subsequent feature construction. In this way, the strategy modeling stage uses structured factors as the basic unit, without directly facing the underlying raw market and public opinion data, which is conducive to reusing the factor system among different strategies. Implementation of feature building blocks The feature construction unit is used to convert the list of target factors into a sequence of feature vectors that can be input into the strategy model. In this embodiment, the feature construction unit constructs input features on a time series sample basis to ensure the comparability of different factors in the same model. The feature construction unit first reads the corresponding factor value sequence from the factor management library according to the trading instrument and timestamp based on the factor identifier and time window parameters recorded in the target factor list; for each factor... Calculate the mean of the factor within a preset sample interval. and standard deviation The factor values ​​are then standardized using the following formula: ; In the formula, For time indexing, For factor index, As a factor The average value within the sample interval. As a factor The standard deviation within the sample interval. These are the standardized factor values; through the above standardization process, factors with different dimensions and value ranges are mapped to comparable numerical intervals, making them easier to use in a unified model. In the time dimension, feature construction units are arranged according to a preset sequence length. Organize the standardized factor sequences into sample segments; for example, for each trading instrument, at a specific time point. The length of the structure is input sequence ,in: For time points The feature vector consists of all target factors and has dimension K. For length is Each time step has the following dimensions: The feature matrix; For factors that require cross-sectional sorting, the feature construction unit can also sort or group the factor values ​​by trading instrument on the same time cross section and write the quantile label as an additional feature into the feature matrix. In terms of label construction, the feature construction unit generates supervised learning label values ​​based on the task type recorded in the strategy configuration (e.g., predicting the price direction of the next period or predicting the return rate of the next N periods), using historical price data associated with the factor management library. Taking "predicting the positive or negative return rate of the next trading period" as an example, the label can be defined as follows: ; In the formula, For time points Relative to a point in time The rate of return; the feature building unit will use the feature matrix With corresponding tags The samples are combined to form training samples, which are then used by the model building unit and the model training and performance evaluation module. The above construction method clearly shows the correspondence between the model input and output in the financial time series scenario, avoiding the problem of insufficient disclosure caused by simply stating "constructing features". Implementation of model building units The model building unit is used to define the strategy model structure based on the feature samples and standard states output by the feature building unit, and records the model structure and key hyperparameter information to ensure consistency during subsequent training and deployment; this implementation uses an LSTM-based price direction prediction model as an example for illustration; In this example, the model building unit will have a length of Each step has a dimension of Feature sequences As input to the LSTM network; the network consists of at least one LSTM hidden layer and one fully connected output layer; for time steps The LSTM layer follows a recursive relationship: ; In the formula, For time step The hidden state vector. The previous time step hidden state, LSTM This represents a recurrent unit containing a forget gate, an input gate, and an output gate; the network ends at the end of the sequence. Hidden state As a feature representation of the sequence, the predicted output is calculated through a fully connected layer: ; in, Here, w is the sigmoid function, and w is the output layer weight vector. For bias terms, This is a probability estimate of the model's output that the return in the next cycle is positive. When creating the network structure, the model building unit records structural parameters such as the number of hidden layer units, the number of layers, the type of activation function, and the dimension of the output layer of the LSTM, as well as the form of the loss function (e.g., cross-entropy loss) and the type of optimization algorithm (e.g., Adam), and stores them in the policy configuration in the form of a structural description. For other types of models (such as regression models based on gradient boosting trees or sequence models based on Transformers), the model building unit records the network structure and key hyperparameters in the same way, so that the same structure can be reproduced during the model training and inference stages. Implementation of the strategy configuration generation unit The strategy configuration generation unit is used to solidify the key information generated by the factor selection unit, feature construction unit, and model building unit into a strategy configuration file in a format agreed upon within the platform. This strategy configuration file can be stored in a structured text format and includes, but is not limited to, the following: Factor section: Records a list of target factors. Each factor includes a factor identifier, factor type, data source identifier, time window length, and whether it participates in standardization and ranking. Feature section: Records the feature construction rules, including sequence length L, sample step size, label definition method (e.g., future N-period return or price direction), training set / validation set / test set partitioning rules, etc. Model section: Record the model type (e.g., LSTM, ensemble learning model, etc.), network structure parameters (number of layers, number of units per layer, activation function), loss function type, and training-related hyperparameters (e.g., learning rate, batch size, maximum number of training epochs). Signal generation section: Records how the model output is transformed into trading signals, for example when... A buy signal is generated when the value is greater than the first threshold. A sell signal is generated when the value is less than the second threshold. The mapping rules between the threshold value and the position direction are explicitly given in the configuration file. Interface conventions section: Records the data paths, field names, and calling order that the model training and performance evaluation module, backtesting and simulation execution module, and live trading execution module need to follow when parsing the configuration file, so that each module can complete sample loading, model calling, and signal generation based on the same strategy configuration file without modifying the internal code; When generating the configuration file, the strategy configuration generation unit establishes a mapping relationship between the factor identifier, model identifier and the records in the factor management library and model version library, and writes the corresponding version number or hash value into the configuration file to ensure that the model structure and parameters called in subsequent backtesting and live execution are consistent with those in the strategy modeling stage.

[0024] The model training and performance evaluation module is deployed as an independent service, communicating with the strategy configuration library, factor management library, model version library, and backtesting and simulation execution module through internal interfaces. This module consists of a sample extraction unit, a training unit, an evaluation unit, and a model registration unit. It is used to complete the construction of training data, update model parameters, evaluate performance, and register the version of training results according to the rules agreed in the strategy configuration file, so that subsequent backtesting and live execution have a clear version source and traceability when calling the model. Implementation of the sample extraction unit The sample extraction unit extracts training, validation, and test sets from the factor management library according to the sample division rules and time intervals specified in the strategy configuration file. In this embodiment, the sample extraction unit first parses the data-related configuration items in the strategy configuration file, including: the target trading instrument set, the list of target factors used and their time window length, the start and end time of training samples, the start and end time of verification samples, the start and end time of test samples, as well as the sequence length, step size, and label construction method. Based on the above information, the sample extraction unit sends a query request to the factor management library and reads the factor value sequence of the target factor and the corresponding price sequence of the underlying asset within the specified time interval according to the trading instrument and timestamp. In order to ensure that there is no time overlap between the training set, validation set and test set, the sample extraction unit divides the complete time axis into three non-overlapping segments according to the time boundaries agreed in the strategy configuration file, and constructs pairs of input features and labels in each segment according to a preset step size, and marks them as training samples, validation samples or test samples respectively. When processing data across multiple trading instruments, in one implementation, the sample extraction unit divides the training set, validation set, and test set according to the underlying asset. In another implementation, the sample extraction unit mixes multiple underlying assets at a time cross-section to construct training samples and retains the trading instrument identifier in the sample record so that the training unit can filter by underlying asset or by strategy granularity when needed. The sample extraction unit performs integrity checks on the constructed training set, validation set, and test set respectively. After confirming that each sample contains the required factor values, labels, and timestamp information, it passes the sample set path or index to the training unit and the evaluation unit. Through the above sample extraction process, the model training and performance evaluation module constructs samples based on the unified factor data and label construction rules output by the factor management library, ensuring that the training samples are consistent with the factor system used in the strategy modeling stage, and avoiding the situation where the training set and the actual trading factor caliber are inconsistent due to manual splitting of the dataset and manual construction of samples. Implementation of training units The training unit is used to estimate parameters and iteratively update the policy model based on the training set and the model structure recorded in the policy configuration file. In the specific implementation, the training unit first reads the model type, network structure parameters (such as the number of layers, the number of units per layer, and the activation function type) and training-related hyperparameters (such as the learning rate, batch size, the upper limit of the number of training epochs, and the regularization method) from the policy configuration file, and instantiates the corresponding model structure according to these configurations; then, the training unit loads the training samples into memory in batches according to the training set index provided by the sample extraction unit, and performs forward inference, loss calculation, and parameter update. During each training round, the training unit cycles multiple times on the training set according to the preset strategy, and calculates the evaluation index on the validation set after each training round. The changes in loss and evaluation index during the training process are recorded together with the training task identifier for subsequent analysis. When the evaluation index on the validation set does not improve or deteriorates significantly in several consecutive rounds, the training unit terminates the training according to the early stopping conditions specified in the strategy configuration file to reduce the risk of overfitting. After training, the training unit establishes a correspondence between the final model parameters, the actual number of training rounds, the time interval of the training set used, and the configuration summary (including the policy configuration version number and the factor list version number) related to the training task and the training task identifier, and writes this information into the intermediate result storage for the evaluation unit to call. Through the policy configuration-driven training process, it can be ensured that the model structure is consistent and the training process is repeatable when training multiple times under the same policy configuration. Implementation of the evaluation unit The evaluation unit calculates and compares the evaluation indicators and corresponding thresholds specified in the strategy configuration file or platform configuration on the validation set or test set to determine whether the strategy model meets the evaluation requirements. In this implementation, the evaluation metrics may include consistency metrics between the predicted results and the actual labels (e.g., classification accuracy, recall), return level metrics calculated based on the backtesting return curve (e.g., annualized return level, excess return level), risk metrics calculated based on the volatility of the return curve (e.g., maximum drawdown, return volatility), and risk-return ratio metrics that comprehensively consider both returns and risks. The specific metrics used and the thresholds for each metric are given by the strategy configuration file or the platform's global configuration. After receiving the trained model and corresponding configuration summary from the training unit, the evaluation unit selects a validation set or a test set according to the sample partitioning rules in the strategy configuration file, and performs batch evaluation of the samples based on the feature construction and data preprocessing process consistent with the training phase. For classification tasks, the evaluation unit statistically analyzes the consistency between the prediction results and the true labels and the error distribution. For revenue-related tasks, in one implementation, the evaluation unit converts the model output into trading instructions according to the signal mapping rules agreed upon with the backtesting and simulation execution modules, replays the corresponding trading sequence during the validation or testing period, and calculates the values ​​corresponding to the evaluation indicators. The evaluation unit compares the calculated results of each evaluation indicator with the preset thresholds in the strategy configuration file or platform configuration to determine whether the evaluation conditions are met. When a key indicator fails to reach the threshold or the combination of indicators does not meet the requirements, the evaluation unit marks the training task as unsuccessful and records the reason for failure and the specific indicator value so that strategy researchers can retrain the model after adjusting the factor combination or model structure. The evaluation unit marks the model as a qualified model only when all required indicators reach or exceed the preset thresholds. Implementation method of model registration unit When the evaluation unit determines that the strategy model meets the evaluation threshold, the model registration unit is responsible for registering the key information of the model version to the model version library for subsequent backtesting and live execution phases for reference and traceability. In this embodiment, the model registration unit obtains the following information from the training unit and the evaluation unit: the version identifier of the policy model (which can be generated as a sequence number or hash value based on the model structure, training data time range, and training configuration), the corresponding model structure description (including model type, hierarchical structure, input and output dimensions), the parameter file path or parameter storage identifier after training, the data time range used for training (including the training set time range, validation set time range, and test set time range if necessary), the calculation results of key evaluation indicators, and the registration time, and associates the above information with the version number of the policy configuration file; The model registration unit writes the above information as a model version record into the model version library and sets an available status flag for the version. When the backtesting and simulation execution modules and the live trading execution module parse the strategy configuration file, they can read the corresponding model structure and parameters from the model version library according to the model version identifier referenced in the configuration to complete the prediction and trading signal generation. After a new training task is generated and passed the evaluation, the model registration unit can register the new version as a candidate version or update the default version, but does not delete the existing version record to preserve the complete model evolution history.

[0025] The backtesting and simulation execution module is deployed as an independent service. It interacts with the strategy configuration library, factor management library, model version library, and operation monitoring and risk control module through internal interfaces. This module consists of a strategy parsing unit, a data loading unit, an execution engine, and a backtesting report unit. It is used to reproduce the operation of the strategy model on a historical timeline and generate backtesting reports that can be compared with live trading results. The specific implementation of the backtesting and simulation execution module is as follows: Strategy parsing unit The strategy parsing unit is used to read and parse the target strategy configuration file in the strategy configuration library and the target model version in the model version library; In this embodiment, the strategy parsing unit locates the corresponding strategy configuration file in the strategy configuration library according to the strategy identifier selected by the user, and parses the factor list, feature construction rules, sample partitioning rules, model structure description, trading signal generation rules, matching rules, slippage rules and commission rules recorded therein; at the same time, according to the model version identifier recorded in the strategy configuration file, it reads the corresponding target model version from the model version library and obtains the structural information and trained parameters of the model version. After parsing, the strategy parsing unit organizes the key information in the strategy configuration file into an internally unified strategy operation description, including the data reading order, feature processing flow, model call order, and the mapping rules from trading signals to orders, and associates it with the target model version, providing a unified call entry point for the data loading unit and the execution engine; this ensures that the factors, feature processing logic, and model structure used in the backtesting phase are consistent with those used in the model training phase and the live execution phase. Data loading unit The data loading unit is used to load historical factor data from the factor management library, using the same field caliber as the live trading data, according to the operation description output by the strategy parsing unit; Specifically, the data loading unit determines the trading instruments, time ranges, and factor lists to be loaded according to the data reading order recorded in the strategy configuration file, and calls the factor management library interface to obtain the corresponding factor values ​​on the historical time axis. Since the factor management library has unified the field names and aligned the time for data from different sources, the data loading unit reads the standardized factor data in chronological order, and constructs a complete historical sample sequence when necessary by combining historical price data, trading calendar information, and adjusted information. When processing multi-product or multi-market strategies, the data loading unit aligns the factor sequences of different targets along a unified time axis. For non-trading days or periods without quotes, it processes them according to the rules in the strategy configuration file, such as skipping sample construction or using the state of the previous valid moment. After loading, the data loading unit organizes the historical factor data and corresponding labels into a data structure that can be sequentially traversed by the execution engine. Execution engine The execution engine is used to drive the target model version to generate trading signals on the historical timeline according to the feature processing rules and model call order recorded in the strategy configuration file, and to simulate and generate orders and matching results according to the preset matching rules, slippage rules and commission rules. In this embodiment, the execution engine scans along the historical timeline point by point. When the timeline advances to a certain point in time, the execution engine extracts the corresponding feature sequence from the loaded factor data according to the feature construction rules to form the model input data. Then, it calls the target model version to make a prediction and obtains the model output at that moment. The execution engine converts the model output into a trading signal in an internally unified format, such as buy, sell, add to position, reduce position, or keep the position unchanged, according to the signal generation rules recorded in the strategy configuration file. For the generated trading signals, the execution engine combines the current virtual account's holdings and available funds with constraints such as position limits and single order quantity limits specified in the strategy configuration file to generate simulated orders and determine the price type (e.g., market price, limit price) and quantity. Subsequently, the execution engine simulates the execution of the simulated orders based on the matching rules, slippage rules, and commission rules preset in the strategy configuration file or platform configuration. For example, it can determine whether the order will be executed in the next time step based on historical candlestick data. If it is executed, the execution price is adjusted based on the set slippage on the order price, and the corresponding commission is deducted. At the same time, the cash balance and holding records of the virtual account are updated. If it is not executed, the status of the order not being executed in that time step is recorded. The execution engine maintains the net asset value, position details, and status changes of each order in the virtual account throughout the backtesting process, enabling the backtesting process to reproduce the strategy logic and asset changes without relying on an external trading system. Backtesting Report Unit The backtesting report unit is used to generate and save backtesting reports containing transaction details and performance metrics based on the simulation results after the execution engine has completed the historical playback. In this embodiment, the backtesting report unit obtains information such as the daily or time-step net asset value sequence, holding change records, order and transaction records of the virtual account during the backtesting period from the execution engine. It calculates performance indicators including the return curve, maximum drawdown, holding period distribution, capital usage, transaction count statistics and single transaction profit and loss distribution according to the evaluation dimensions defined in the strategy configuration file, and generates backtesting reports in a structured data format. The backtesting report unit associates and stores backtesting reports with the version number of the strategy configuration file used, the model version identifier, and the time interval of the backtesting data. It also synchronizes the backtesting result summary to the operation monitoring and risk control module so that historical backtesting results and live trading results can be compared and analyzed within the platform.

[0026] Among them, the live trading execution module is deployed as an independent service. It interacts with the data acquisition and access module, strategy configuration library, model version library and operation monitoring and risk control module through a unified instruction interface. This module consists of an interface adaptation unit, instruction generation unit, verification unit and trading interaction unit, and is used to execute trading instructions according to the strategy configuration in the live trading environment. Interface adapter unit The interface adaptation unit is used to convert the unified instruction format within the platform into the message format required by the target exchange or brokerage interface, and to receive and parse the transaction reports and position changes from the target interface to generate records that can be recognized within the platform. In this embodiment, the interface adaptation unit maintains the communication parameters and message format descriptions of various exchange interfaces and brokerage counter interfaces, including the mapping relationship of login authentication method, order message field, order cancellation message field and transaction report field. For unified trading instructions generated internally by the platform, the interface adaptation unit constructs the corresponding order message according to the target interface type, maps the internal fields, including the target code, direction, quantity, price type, etc., to the specific field names and field value formats required by the target interface, and sends them to the corresponding interface through network connection. Meanwhile, the interface adaptation unit listens to the transaction reports and position change messages returned by the exchange or brokerage, parses the order number, transaction quantity, transaction price, transaction time, order cancellation status and latest position information into a unified format within the platform, and pushes it to the transaction interaction unit and the operation monitoring and risk control module to update account status and risk indicators. Instruction Generation Unit During live trading, the instruction generation unit calls the backtested strategy configuration file and model version, and receives market data and external data from the data acquisition and access module according to the data reading order and feature processing rules determined by the strategy configuration file, in order to generate trading signals and convert them into unified instructions within the platform. Specifically, the instruction generation unit receives tick-level or candlestick-level market data related to the target trading instrument, as well as external data such as macroeconomic data and news sentiment data, from the data acquisition and access module in real time according to the data reading order in the strategy configuration file. It generates the model input features for the current moment according to the feature construction rules, calls the strategy model specified in the model version library for inference, and obtains the model output for the current moment. The instruction generation unit converts the model output into buy, sell, or position adjustment signals based on the signal generation rules defined in the strategy configuration file. It then combines the account's current position information and strategy constraints to generate a unified trading instruction within the platform that includes fields such as target code, trading direction, price type, order quantity, and associated strategy identifier. This instruction is then submitted to the verification unit for inspection. Verification Unit The verification unit is used to check the transaction instructions output by the instruction generation unit according to the verification rules specified in the strategy configuration file or platform configuration. In this embodiment, the verification rules include at least checks on available account funds, position limits, maximum position size for a single strategy, and minimum order interval. After receiving a trading instruction, the verification unit obtains the current total assets, available funds, and existing positions from the account status data maintained by the platform. Based on the trading direction and target quantity, it calculates the expected funds required and the adjusted position level. The calculation results are compared with the thresholds in the verification rules. When a trading instruction results in negative available funds or exceeds the preset position limit or maximum position size for a single strategy, the verification unit intercepts, reduces, or delays the execution of the instruction according to the processing method specified in the strategy configuration file, and records the verification results and reasons. When it is detected that the number of orders placed for the same strategy within a preset time window exceeds the minimum order interval requirement, the verification unit restricts the sending of subsequent instructions according to the rules. Only transaction instructions that pass the verification will be forwarded to the transaction interaction unit for transmission; the verification unit will also write the failed transaction instructions and the reasons to the verification log, and notify the operation monitoring and risk control module of the relevant information for the triggering of subsequent risk control strategies. Transaction Interaction Unit The transaction interaction unit is used to send the verified transaction instructions to the corresponding interface after being converted by the interface adaptation unit, and to process the transaction results and position changes. Specifically, after receiving the trading instructions output by the verification unit, the trading interaction unit forwards them to the interface adaptation unit to generate a message. Then, it sends the message through the network connection established with the exchange or brokerage. When receiving a transaction confirmation or order cancellation confirmation, the trading interaction unit updates the internal order status and position records according to the parsing results returned by the interface adaptation unit, and writes the updated order and position information into the trading log. At the same time, the trading interaction unit notifies the operation monitoring and risk control module of key trading events such as order placement, transaction, order cancellation, and order rejection, so that the latter can keep track of the transaction execution status in real time.

[0027] The operation monitoring and risk control module is deployed as an independent service. It interacts with the backtesting and simulation execution module, the live trading execution module, and the data acquisition and access module through internal interfaces. This module consists of a data aggregation unit, a risk calculation unit, a performance monitoring unit, an alarm judgment unit, and a control issuance unit. It is used to continuously monitor the risk and performance indicators during the strategy operation process and issue control instructions to the live trading execution module when the conditions are met. Data aggregation unit The data aggregation unit is used to aggregate the backtest reports output by the backtesting and simulation execution module and the live trading results output by the live trading execution module, and organize them by account, strategy, and asset dimensions. In this implementation, the data aggregation unit periodically or when an event is triggered obtains structured backtest reports from the backtesting and simulation execution module, transaction logs, order status, and position change records from the live trading execution module, and the latest market prices from the data acquisition and access module. The data aggregation unit archives the net value curves, position structures, and transaction records of the backtesting and live trading phases according to three dimensions: account, strategy, and asset, forming a unified data view that can be directly used by the risk calculation unit and the performance monitoring unit. Risk Calculation Unit The risk calculation unit is used to calculate and save risk exposures based on data organized by the data aggregation unit, according to account, strategy and asset dimensions. In practice, the risk calculation unit calculates the net holding value of each asset and strategy based on the latest market price and the number of positions, calculates floating profit and loss in combination with the cost price or opening price, and scans the net value sequence of the account or strategy on the time axis to obtain risk indicators such as the historical maximum drawdown. The risk calculation unit stores the above risk exposure indicators in the form of time series or snapshots and provides a query interface for the alarm judgment unit. Performance monitoring unit The performance monitoring unit is used to monitor and record performance metrics during operation.

[0028] In this embodiment, the performance monitoring unit statistically records the data push delay of the data acquisition and access module, the task execution time of the backtesting and simulation execution module, and the response time of the trading interface in the live trading execution module. For the trading interface response, the performance monitoring unit records the time interval between the generation of the instruction and the receipt of the transaction report, as well as the number of times the interface call fails or times out within a certain time window, in order to determine whether there are performance abnormalities in the trading execution chain. Alarm determination unit The alarm determination unit is used to compare the indicator values ​​of the risk calculation unit and the performance monitoring unit with the corresponding thresholds stored in the strategy configuration file or platform configuration, and generate an alarm event when it detects that any threshold is exceeded or an anomaly is detected according to the transaction anomaly determination rules defined in the platform configuration. Specifically, the alarm determination unit periodically reads risk exposure indicators and performance indicators and compares them with pre-set thresholds such as drawdown limit, daily loss limit, single strategy capital occupation limit, data latency limit, and interface response time limit. When an indicator exceeds the corresponding threshold, or when consecutive order rejections or abnormal transaction prices occur within a preset time window and are defined as abnormal trading concentration, the alarm determination unit generates an alarm event containing alarm type, trigger time, trigger indicator, and related account or strategy identifier, and transmits it to the control and distribution unit. Control distribution unit The control issuing unit is used to issue control commands to the live trading execution module based on alarm events and according to the control strategies predefined in the strategy configuration file or platform configuration, and to record the control commands and their execution results in the operation log. In this embodiment, the control issuing unit parses the alarm event and reads the control strategy corresponding to the alarm type, such as reducing position size, limiting the number of new positions, or suspending a specified strategy. For the control strategy of reducing position size, the control issuing unit generates an instruction to adjust the target position size, adjusting the available funds limit or target holding ratio of the strategy to below a preset value. For the control strategy of limiting new positions, the control issuing unit generates an instruction to modify the minimum order interval or the maximum number of positions opened per day. For the control strategy of suspending a specified strategy, the control issuing unit generates an instruction to suspend the strategy corresponding to a certain strategy identifier. The control issuing unit sends the aforementioned control instructions to the live trading execution module, which then executes the new restrictions during the subsequent instruction generation and verification process. Simultaneously, the control issuing unit records the control instructions, issuance time, and execution results fed back by the live trading execution module in the operation log, so as to trace which control actions were taken under what risk and performance conditions.

[0029] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0030] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-factor quantitative trading modeling and automated execution platform based on artificial intelligence, characterized in that: Deployed within the same network environment, this forms a closed-loop process from data acquisition, data processing, strategy modeling, model training, backtesting verification to live execution and risk control, including: The data acquisition and access module is used to acquire multi-source market data and external data and write them into the data cache by interacting with stock, futures and cryptocurrency exchange interfaces, brokerage interfaces and third-party data service interfaces; The data preprocessing and factor management module is connected to the data acquisition and access module. It is used to clean, standardize and time-align the data, calculate various trading factors based on the processed data, and register the factors and their calculation information in the factor management library. The strategy modeling and configuration module is connected to the factor management library. It is used to select target factors from the factor management library to form model input features according to the trading instruments, holding periods and risk constraints set by the user, construct strategy models and generate strategy configuration files that record data processing flow and trading signal generation rules, and store them in the strategy configuration library. The model training and performance evaluation module connects the strategy configuration library and the factor management library. It is used to extract historical samples from the factor management library according to the strategy configuration file, train and evaluate the strategy model, and register the qualified models, their parameters and applicable scope to the model version library. The backtesting and simulation execution module connects to the strategy configuration library, model version library and factor management library. It is used to call the target strategy configuration file and target model version in the backtesting environment, generate trading signals based on historical factor data in the factor management library, simulate order and position changes under preset matching and fee rules, and generate backtesting result reports. The live trading execution module connects the model version library, strategy configuration library, and data acquisition and access module. It is used to call the backtested strategy configuration file and model version during live trading, generate trading signals based on real-time data and convert them into trading instructions, and complete the order operation through the exchange interface and brokerage interface after checking the account funds, positions and trading frequency of the trading instructions. The operation monitoring and risk control module connects the data acquisition and access module, the backtesting and simulation execution module, and the live trading execution module. It is used to summarize the backtesting results and live trading results, calculate risk exposure by account, strategy, and asset dimensions, and monitor the operation performance indicators. When the indicators exceed the preset threshold, it issues control instructions to the live trading execution module to adjust positions, restrict opening positions, or suspend strategies.

2. The multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence according to claim 1, characterized in that: The data acquisition and access module includes a market data access submodule, an external data access submodule, and a cache management submodule; The market data access submodule establishes a connection with the network interfaces of stock exchanges, futures exchanges, digital currency trading platforms, and brokerage counter systems. It receives tick-level data of stocks, futures, and digital currencies, as well as K-line level historical market data and real-time market data generated at preset time intervals, in accordance with the API or protocol specifications provided by the exchanges or brokerages. When receiving data, it adds a trading instrument identifier, data source identifier, and standardized timestamp to each data item for cross-source alignment. The external data access submodule establishes connections with the API or data subscription interfaces of macroeconomic data services, news and public opinion data services, and social media data services. It acquires structured or semi-structured macroeconomic data, news and public opinion data, and text or sentiment index data from social media according to the specifications of each interface. It also parses and standardizes the time field of the acquired data to generate external data records with timestamps and data source identifiers. The cache management submodule receives data from the market data access submodule and the external data access submodule, respectively. Based on the data type and trading instrument, it writes the data into the configured real-time data cache and historical data cache, which are used for short-term high-speed access and long-term persistent storage, respectively. The cached data is sorted in ascending order of timestamp and a time index is established so that the data preprocessing and factor management modules can read it in a unified data format and time order.

3. The multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence according to claim 2, characterized in that: The data preprocessing and factor management module includes a data cleaning submodule, a factor calculation submodule, and a factor registration submodule. The data cleaning submodule is connected to the data acquisition and access module. It is used to read market data and external data from the data cache in the data acquisition and access module according to the trading variety and timestamp. The read data is filled with missing values, abnormal data is identified and removed, field names and units are unified, and cross-market time alignment is performed to obtain cleaned data with a unified format. The factor calculation submodule is used to calculate price factors, transaction factors, structural factors and sentiment factors respectively based on the cleaned data and according to the calculation formulas registered in the factor management library, and generate corresponding factor sequences; The factor management library stores the calculation formula in the form of a parsable expression or a script, and the calculation formula can be parsed and executed by the system at runtime; The factor registration submodule is used to register the name, calculation formula, data source, applicable trading target, and value distribution of each factor in the factor management library, and provides an access interface for the factor management library for the strategy modeling and configuration module and the model training and effect evaluation module to call.

4. The multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence according to claim 3, characterized in that: The strategy modeling and configuration module consists of a factor selection unit, a feature construction unit, a model building unit, and a strategy configuration generation unit. The factor selection unit is used to retrieve registered factors from the factor management library and filter and determine target factors based on the trading instruments, holding periods and risk constraint parameters specified by the user in the strategy configuration file. The feature construction unit is used to form model input features based on the target factor; The model building unit is used to construct a strategy model using the model input features and record the structure and parameter information of the strategy model; The strategy configuration generation unit is used to save the target factor identifier, feature processing rule reference, model structure and parameter information, sample partitioning rules and trading signal generation rules as a strategy configuration file and store the strategy configuration file in the strategy configuration library for the model training, backtesting and live execution modules to parse and call and execute in a consistent process.

5. The multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence according to claim 4, characterized in that: The model training and performance evaluation module consists of a sample extraction unit, a training unit, an evaluation unit, and a model registration unit. The sample extraction unit extracts training sets, validation sets, and test sets from the factor management library according to the sample division rules and time intervals specified in the strategy configuration file. The training unit estimates and iteratively updates the strategy model based on the model structure recorded in the training set and the strategy configuration file, and associates and saves the training results with the training task identifier; the evaluation unit calculates the evaluation index on the validation set or test set according to the evaluation index and corresponding threshold specified in the strategy configuration file or platform configuration, and compares the obtained value with the threshold to determine whether the strategy model meets the evaluation threshold. When the evaluation unit determines that the strategy model meets the evaluation threshold, the model registration unit records the version identifier of the strategy model, the trained parameters, the time interval of the training data used, the values ​​of key evaluation indicators and the registration time to the model version library for traceability.

6. The multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence according to claim 5, characterized in that: The backtesting and simulation execution module consists of a strategy parsing unit, a data loading unit, an execution engine, and a backtesting report unit. The strategy parsing unit is used to read and parse the target strategy configuration file in the strategy configuration library and the target model version in the model version library; the data loading unit is used to load historical factor data with the same field caliber as the live trading data from the factor management library according to the data reading order recorded in the strategy configuration file. The execution engine is used to drive the target model version to generate trading signals on the historical timeline according to the feature processing rules and model calling order recorded in the strategy configuration file, and to simulate and generate orders and matching results for the trading signals according to the matching rules, slippage rules and commission rules specified in the strategy configuration file or platform configuration; the backtesting report unit is used to generate and save backtesting reports containing transaction details and performance indicators based on the simulation reproduction results for retrospective analysis.

7. The multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence according to claim 6, characterized in that: The live trading execution module consists of an interface adaptation unit, an instruction generation unit, a verification unit, and a trading interaction unit. The interface adaptation unit converts the unified instruction format within the platform into the message format required by the target exchange or brokerage interface, and receives and parses the transaction reports and position changes from the target interface into internal platform records. During live trading, the instruction generation unit calls the backtested strategy configuration file and model version, and receives market data and external data from the data acquisition and access module according to the data reading order and feature processing rules determined by the strategy configuration file to generate trading signals and convert them into unified instructions within the platform. The verification unit verifies the trading instructions based on the numerical verification rules specified in the strategy configuration file or platform configuration. The verification rules include available funds in the account, position limit, maximum position size for a single strategy, and minimum order interval. Trading instructions that fail the verification are rejected or adjusted according to the configuration rules, and the verification results are recorded. The trading interaction unit sends the verified trading instructions to the corresponding interface after the message is converted by the interface adaptation unit, receives and parses the transaction report and position changes, records the parsing results in the trading log, and feeds them back to the operation monitoring and risk control module for traceability.

8. The multi-factor quantitative trading modeling and automatic execution platform based on artificial intelligence according to claim 7, characterized in that: The operation monitoring and risk control module consists of a data aggregation unit, a risk calculation unit, a performance monitoring unit, an alarm judgment unit, and a control issuance unit. The data aggregation unit is used to aggregate the backtest reports output by the backtesting and simulation execution module and the live trading results output by the live trading execution module, and organize them according to account, strategy, and asset dimensions. The risk calculation unit is used to calculate and save risk exposure based on the data organized by the data aggregation unit, according to account, strategy, and asset dimensions. This includes net position value converted to the latest market price, floating profit and loss, and the historical maximum drawdown calculated according to the strategy net value sequence. The performance monitoring unit is used to monitor and record the operational performance indicators such as data acquisition delay, backtesting task execution time, and trading interface response time. The alarm determination unit is used to compare the indicator values ​​of the risk calculation unit and the performance monitoring unit with the corresponding thresholds stored in the strategy configuration file or platform configuration, and generate an alarm event when it detects that any threshold is exceeded or an anomaly is detected according to the transaction anomaly determination rules defined in the platform configuration. The control issuing unit is used to issue control instructions to the live trading execution module to reduce the position, limit the number of new positions, or suspend the specified strategy based on the alarm event and the control strategy predefined in the strategy configuration file or platform configuration, and to record the control instructions and their execution results in the operation log for traceability.

Images