Event-driven quantitative trading strategy simulation backtesting framework and system

Abstract

The present invention relates to the technical field of software development, and discloses a quantitative trading strategy simulation backtesting framework and system based on event-driven. The quantitative trading strategy simulation backtesting framework includes: a data layer, which is used to provide the data required for the quantitative trading strategy simulation backtesting and trigger the generation of event objects required for the simulation backtesting; a trading layer, which is used to execute the implementation logic of the corresponding simulation backtesting based on the event objects output by the data layer; an analysis layer, which is used to receive the output instructions of the trading layer, dynamically adjust the holding ratio of each asset in the investment portfolio adopted by the corresponding quantitative trading strategy, and calculate a variety of key indicators in real time, as well as collect various types of relevant data related to quantitative trading, perform performance attribution analysis on the quantitative trading strategy, and output a quantitative trading strategy simulation backtesting report. The present invention not only ensures the simulation accuracy and backtesting efficiency of the backtesting system, but also further improves the system operation fluency, framework extensibility and flexibility.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to an event-driven quantitative trading strategy simulation backtesting framework and system. Background Art

[0002] Quantitative trading strategy simulation backtesting, also known as strategy backtesting, refers to the process of using historical data of the trading market and simulated transactions to verify and evaluate the effectiveness and feasibility of quantitative strategy execution, as well as some key indicators. Its main purposes include: First, verify the investment strategy: verify the strategy based on historical market conditions to determine whether it can generate stable returns in the past market environment. Second, optimize strategy parameters: help optimize and adjust strategy parameters by continuously adjusting parameters, quantitative models and other operations to obtain better trading results. Third, compare strategies horizontally: when it is uncertain which type of strategy has better execution effect and returns, you can compare the execution effects of different strategies horizontally based on strategy backtesting, so as to select a better strategy to participate in real trading.

[0003] There are many securities investment strategy simulation backtesting systems on the market. These backtesting systems can be used to accurately simulate various business scenarios, so as to analyze the profitability of securities investment strategies under a series of influencing factors such as the market, system, and risk control, and finally decide whether to enter real trading. In order to improve the simulation accuracy and backtesting efficiency of the backtesting system, the existing technology usually improves and optimizes from the dimensions of system functions and implementation processes. For example, patent CN118469706A proposes an exchange simulation system and method for quantitative trading strategy verification, which mainly optimizes the matching program of trading strategy orders in terms of system functions and implementation processes. Although the patent improves the simulation accuracy and backtesting efficiency of the backtesting system to a certain extent, there is still a lot of room for optimization in the overall system operation performance. Patent CN117745432A proposes a quantitative backtesting system and method based on a microservice architecture, which mainly adopts a cluster design architecture of microservices. Each functional module of the system is composed of a cluster of multiple service nodes. Each system module is physically isolated from each other and does not affect each other, thereby achieving system-level decoupling and improving the overall performance of the system. Although the patent has been improved and optimized in terms of system design architecture and improved the overall performance of the system, there is still much room for optimization in terms of system operation smoothness, framework scalability and flexibility. Summary of the invention

[0004] The main purpose of the present invention is to provide an event-driven quantitative trading strategy simulation backtesting framework and system, aiming to solve the technical problem of how to further improve the system operation smoothness, framework scalability and flexibility while ensuring the simulation accuracy and backtesting efficiency of the backtesting system.

[0005] The first aspect of the present invention provides an event-driven quantitative trading strategy simulation backtesting framework, the quantitative trading strategy simulation backtesting framework comprising: a data layer, a trading layer and an analysis layer;

[0006] The data layer is used to provide the data required for the simulation backtesting of the quantitative trading strategy and trigger the generation of the event objects required for the simulation backtesting of the quantitative trading strategy; the trading layer is used to execute the implementation logic of the simulation backtesting of the corresponding quantitative trading strategy based on the event objects output by the data layer, including strategy construction, signal generation, transaction execution and risk management; the analysis layer is used to receive the output instructions of the trading layer, dynamically adjust the holding ratio of each asset in the investment portfolio adopted by the corresponding quantitative trading strategy, and calculate a variety of key indicators in real time, as well as collect various relevant data related to quantitative trading, perform performance attribution analysis on the quantitative trading strategy, and output a simulation backtesting report for the quantitative trading strategy;

[0007] The data layer includes: a data access module, a data call module and an event engine module; the data access module is used to interact with several data sources, including data access, data storage and data query; the data call module includes multiple data call interfaces, each of which corresponds to a data call logic, which is used to call specific data according to a given data call logic, and the specific data includes basic contract information, trading calendar, historical market conditions, dividend splits, suspension and price limit dates, calendar data and the latest market data; the event engine module is centered on the message queue and is divided into two parts: the event source component and the event bus component. The event source component is used to receive data from different data sources and convert them into event objects, and the event bus component is used to distribute event objects to other modules for consumption;

[0008] The trading layer includes: a strategy module, an order management module and an exchange module; the strategy module is used to dynamically construct a quantitative trading strategy through a custom strategy class, and generate corresponding trading signals at corresponding trading time points according to the constructed quantitative trading strategy, while monitoring and limiting potential risks in the quantitative trading process, and the custom strategy class is used to encapsulate specific trading logic; the order management module is used to generate trading orders according to the quantitative trading strategy, and manage and track the execution process of all trading orders; the exchange module is used to simulate the real trading environment according to the trading orders and market data generated by the quantitative trading strategy, and realize the transaction process of the trading orders;

[0009] The analysis layer includes: a portfolio holding module and a performance attribution module. The portfolio holding module is used to simulate and record the holdings of various types of assets in the investment portfolio, and calculate multiple key indicators in real time. The key indicators include holding costs, account fund changes, and account profit and loss changes; the performance attribution module is used to collect various relevant data related to quantitative trading, calculate the performance evaluation indicators of portfolio holdings during the backtest period, and perform performance attribution analysis on quantitative trading strategies based on each of the performance evaluation indicators, and output a quantitative trading strategy simulation backtest report. The relevant data includes the key indicators, and the performance attribution analysis includes performance attribution analysis based on net value, performance attribution analysis based on positions, and performance attribution analysis based on a custom analyzer.

[0010] Optionally, in a first implementation method of the first aspect of the present invention, the event object adopts a unified event model for describing different event types and event attributes and supports extended custom attributes, and the event model includes the type, timestamp and data content of the event; the event types include: time period type, transaction object type, market situation type and operation command type.

[0011] Optionally, in a second implementation of the first aspect of the present invention, the event source component extracts data from each data source and converts it into an event object; when the quantitative trading strategy adopts the backtesting mode, the event source component extracts time calendar data from the data source, generates time stage type events and submits them to the event bus component for distribution; when the quantitative trading strategy adopts the real-time mode, the event source component generates an event production thread separately, and extracts the latest data from the data source through the event production thread, and checks whether it reaches a given time point. If it reaches the given time point, a real-time event object is generated and sent to an internal queue, and the internal queue is used to isolate the event production thread generated by the event source component from the event consumption threads generated by other modules.

[0012] Optionally, in a third implementation of the first aspect of the present invention, the event bus component allows other modules to register event listeners, and when the event listener detects the arrival of a corresponding event, it triggers the corresponding module to execute a callback so that the corresponding module can execute corresponding processing logic according to the type and content of the event.

[0013] Optionally, in a fourth implementation of the first aspect of the present invention, the order management module includes:

[0014] The command interface submodule is the entry point for issuing order instructions. It is used to receive order instructions and generate corresponding order objects. One order object uniquely corresponds to one order.

[0015] The risk control filtering submodule is used to check whether the target amount of the order meets the risk control standards, whether it exceeds the preset amount, and whether the proportion is in violation of the rules;

[0016] The order verification submodule is used to verify whether the numerical format of the order meets the custom rules, including whether there is sufficient funds, whether it is the transaction time, whether the minimum transaction amount is reached, and whether it is a multiple of the minimum transaction unit;

[0017] The order routing submodule is used to send orders to the corresponding exchange for matching and update the latest order transaction information back to the position portfolio;

[0018] The cost estimation submodule is used to estimate the transaction cost corresponding to the order before the order is placed, and the transaction cost includes commission, tax and management fee;

[0019] The order algorithm submodule is used to provide a variety of intelligent order placement algorithms. The algorithm objects corresponding to the order placement algorithms include opening a position at a specified time, daily purchase ratio, opening a position at a specified price, closing a position at a specified time, closing a position at a specified price, take-profit order, stop-loss order, retracement, and closing a position after a rebound.

[0020] Optionally, in a fifth implementation of the first aspect of the present invention, the exchange module includes:

[0021] The order preprocessing submodule is used to receive order information generated based on the quantitative trading strategy and verify the validity of the order, wherein the order information includes order type, buying and selling direction, quantity and price;

[0022] The order matching submodule is used to obtain the latest market data from the data source in real time or at a set frequency, and simulate order matching based on the latest market data and the set price matching mechanism. The market data includes price, transaction volume, and buy and sell order data;

[0023] The transaction result processing submodule is used to record the transaction order information and push the order status and the transaction result of the order to the message bus. The transaction order information includes the transaction price, transaction volume, and transaction time.

[0024] Optionally, in a sixth implementation of the first aspect of the present invention, the combined position module includes:

[0025] The capital initialization submodule is used to set the initial capital or initial position for the trading account before the backtest begins;

[0026] The fee setting submodule is used to set the cost rate related to quantitative trading, which includes the portfolio management rate and the financing rate;

[0027] The fund change record submodule is used to record the fund changes of the trading account after each quantitative transaction is completed. The fund changes include the amount of assets bought or sold and the transaction fees;

[0028] The position management submodule is used to record the type, quantity, and cost price of assets held in the position structure corresponding to the current quantitative trading strategy;

[0029] The profit and loss calculation submodule is used to calculate the profit and loss of the account in real time based on the transaction records and positions, and to leave a cross-sectional snapshot at the time of settlement on the same day;

[0030] The persistence submodule is used to record the position data within the portfolio, provide a basis for incremental backtesting during simulated quantitative trading, and record daily snapshot data to provide a basis for performance evaluation indicators.

[0031] Optionally, in a seventh implementation of the first aspect of the present invention, the performance attribution module includes:

[0032] The data collection submodule is used to collect various data related to quantitative trading, including order and transaction details, daily cross-sectional snapshot data of positions, daily statistics of account and portfolio positions, benchmark index net value and user-defined indicators;

[0033] The indicator calculation submodule is used to calculate the performance evaluation indicators of the portfolio holdings during the backtest period based on the collected various relevant data related to quantitative trading. The performance evaluation indicators include the annualized rate of return, Sharpe ratio, Sortino ratio, Karma ratio, and maximum drawdown for net asset value attribution analysis, as well as industry allocation returns, interaction effect returns, individual stock selection returns, and factor style returns for position attribution analysis;

[0034] The report drawing submodule is used to draw a visualized quantitative trading strategy simulation backtesting report based on the results of attribution analysis. The quantitative trading strategy simulation backtesting report supports time dimension scaling and selective multi-standard comparison;

[0035] The result persistence submodule is used to persist the indicator data and report files generated by each submodule in the performance attribution module locally and upload them to a remote server through a preset interface.

[0036] Optionally, in an eighth implementation of the first aspect of the present invention, the quantitative trading strategy simulation backtesting framework further includes:

[0037] An entry module, used to access the quantitative trading strategy simulation backtesting framework to perform event-driven quantitative trading strategy simulation backtesting;

[0038] Wherein, the entry module includes:

[0039] The entry point submodule is the entry point of the entire quantitative trading strategy simulation backtesting framework and serves as the executor of the quantitative trading strategy simulation backtesting. It is used to read configuration files, instantiate components, and execute the backtesting process of the quantitative trading strategy simulation.

[0040] A module manager is used to manage the construction, configuration, and destruction of all modules in the quantitative trading strategy simulation backtesting framework, and to allow users to customize plug-ins;

[0041] The context submodule is used to carry the references of each key module and important information in the backtesting process and transmit them in the quantitative trading strategy simulation backtesting framework;

[0042] The parameter configuration submodule is used to adjust the parameters in each module in the quantitative trading strategy simulation backtesting framework.

[0043] A second aspect of the present invention further provides a quantitative trading strategy simulation backtesting system, wherein the quantitative trading strategy simulation backtesting system comprises any of the above-mentioned event-driven quantitative trading strategy simulation backtesting frameworks.

[0044] In the technical solution provided by the embodiment of the present invention, the architectural design of the quantitative backtesting framework follows the principles of clarity and efficiency, clarifies the functions and interfaces of each module (component), and ensures smooth data flow and strategy execution. In the embodiment of the present invention, the framework includes multiple modules such as data source, data processing, strategy development, event engine and attribution analysis. Each module performs its own duties and jointly supports the smooth progress of the entire backtesting process. In order to cope with the diversified needs of different investment strategies and markets, the quantitative backtesting framework of the embodiment of the present invention supports a variety of data sources, strategy writing languages ​​and backtesting parameter configurations, while maintaining good compatibility and maintainability. The framework adopts a modular design to separate trading strategies from data sources, exchanges, attribution analysis and other parts, so that users can easily combine and customize various parts later to meet specific needs. The event-driven architecture design framework of the present invention has significant advantages in improving the flexibility, scalability, reliability, real-time processing capabilities of the backtesting system, and promoting openness and integration between systems, which are specifically reflected in the following aspects:

[0045] (1) Loose coupling and high scalability

[0046] Loose coupling: The event-driven architecture uses events as a communication mechanism between components, which reduces the coupling between components. Components only need to focus on the generation and processing of events without having to understand the specific implementation details of other components. This loose coupling feature makes the system more flexible and easy to modify and expand.

[0047] Highly scalable: Due to the decoupling between components, the system can easily add, remove or replace components to adapt to changing needs and scale. New components can register and respond based on events, thereby achieving dynamic expansion of the system.

[0048] (2) Asynchronous processing and efficiency

[0049] Asynchronous processing: Event-driven architecture emphasizes asynchronous processing, that is, components can process events asynchronously after receiving them, without immediately blocking and waiting for results. This asynchronous approach improves the responsiveness of the system, enables the system to process multiple events simultaneously, and supports high concurrency and large-scale processing.

[0050] Efficiency: The asynchronous processing mechanism enables the system to utilize resources more efficiently, avoiding resource waste and performance bottlenecks caused by synchronous waiting.

[0051] (3) High reliability and fault tolerance

[0052] High reliability: Event-driven architecture improves the overall reliability of the system by isolating errors to individual components. Even if a component fails or is unavailable, other components can continue to publish events and work normally, thus reducing the impact of single point failures.

[0053] Fault Tolerance: The fault tolerance of the system is also enhanced because the loose coupling between components enables the system to cope with various abnormal situations more easily.

[0054] (4) Real-time processing and data stream processing

[0055] Real-time processing: Event-driven architecture is suitable for scenarios with real-time processing and streaming data. Through the real-time generation and processing of events, the system can respond to changes in a timely manner and perform real-time data processing and analysis. This is very useful for application scenarios that require fast response and real-time decision-making.

[0056] Data stream processing: Event-driven architecture can efficiently process data streams, support real-time analysis and processing of large amounts of data, and provide strong support for business decision-making.

[0057] (5) Openness and integration

[0058] Openness: The event-driven architecture provides rich cross-product and cross-platform connectivity capabilities, facilitating integration between different systems such as cloud products, applications, and SaaS services.

[0059] Integration: By defining a well-defined event interface, the event-driven architecture can achieve loosely coupled integration with external systems, simplifying the complexity of integration and improving system interoperability.

[0060] (6) Easy to maintain and expand

[0061] Easy to maintain: Due to the loose coupling and asynchronous processing mechanism between components, the event-driven architecture makes system maintenance and upgrades simpler and more efficient.

[0062] Easy to extend: It is also easier to extend the system because new components can easily register with the event bus and respond to relevant events. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 The present invention is a schematic diagram of an embodiment of a quantitative trading strategy simulation backtesting framework based on event-driven in an embodiment of the present invention. DETAILED DESCRIPTION

[0064] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" or "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0065] For ease of understanding, the event-driven quantitative trading strategy simulation backtesting framework in the embodiment of the present invention is described below. Figure 1 In an embodiment of the present invention, an embodiment of a quantitative trading strategy simulation backtesting framework based on event-driven includes:

[0066] 1. Data Layer

[0067] The data layer 10 is used to provide the data required for the quantitative trading strategy simulation backtesting and trigger the generation of the event objects required for the quantitative trading strategy simulation backtesting. In this embodiment, the data layer 10 further includes:

[0068] 1.1 Data access module

[0069] The data access module 101 is used to interact with several data sources, including data access, data storage and data query.

[0070] As the cornerstone of the backtesting system, the design of the data layer is directly related to the efficiency and accuracy of data processing and the scalability of the system. This embodiment specifically designs the data access module from multiple aspects such as data source selection, data access and storage, and data access.

[0071] To ensure the accuracy of backtesting, at least data such as trading calendar, market conditions, dividends and stock splits are required during the backtesting process. On top of this, to facilitate the writing of quantitative trading strategies, fundamental data, macroeconomic data, alternative data and other data need to be introduced. These data can be obtained from exchanges, third-party data service providers, self-crawling and other channels, and stored in the internal investment research database. When selecting a data source, factors such as the comprehensiveness, accuracy, real-time and cost of the data need to be considered.

[0072] After completing the design of the data source, the data access module can be designed to be responsible for the interaction with the data source (database), including data access, storage, query and other functions. Since external data usually has its own definition, this embodiment needs to set specifications to unify and standardize it to facilitate subsequent data processing and access.

[0073] The data access support in this embodiment includes but is not limited to: querying calendars, querying contract information, querying market data, and querying dividends and stock splits. Considering that with the development of business and the increase in data sources, the data layer needs to be able to flexibly access new data sources and process new data types. That is, it is necessary to clean data from different sources and different markets into a unified investment research data warehouse, so this embodiment provides:

[0074] External data source access interface: responsible for the interface paradigm of connecting to the data warehouse, the query interface will include data cleaning logic. At the same time, a matching synchronization component is designed to read its data and synchronize it to the local database; Local data source access interface: connect to the local database through the SqlAlchemy framework, the data is clean and tidy, and can be read and called directly without cleaning and conversion. It allows connection to any type of relational database.

[0075] In addition, in this embodiment, for other backtesting categories that are not stored in the database, when custom file data needs to be used for backtesting, the framework is also capable of importing data into an in-memory database of the sqlite type, reusing the local data source access interface function.

[0076] 1.2 Data call module

[0077] The data call module 102 includes multiple data call interfaces, each of which corresponds to a data call logic, and is used to call specific data according to the given data call logic. The specific data includes basic contract information, trading calendar, historical market conditions, dividends and stock splits, suspension and price limit dates, calendar data, and the latest market data.

[0078] In this embodiment, in order to make the data easier to use, a layer of calling components is wrapped on the query data interface to form a data calling module, which queries the database on demand by specifying the target and provides a cache function to reduce IO performance consumption. In this embodiment, the data calling module retrieves specific data according to a given logic, such as a specific date, dividends, latest prices, etc.

[0079] For example, when the exchange module wants to use the latest transaction price to match orders, it will call the data call module to obtain data, and the underlying data will operate according to the following logic:

[0080] First, check whether the market data corresponding to the order is in the cache. If not, query the underlying market data stored in the cache based on the start and end dates of this backtest. Then, query the transaction price of the most recent trading day of the market data based on the system's latest backtest date.

[0081] The data call module has many similar query logics, which can be generally classified into three categories:

[0082] The first category is historical data, including basic contract information, trading calendar, historical market conditions, dividends and stock splits, trading suspension and price limit dates, etc.

[0083] The second category is calendar data, which provides functions such as trading day and trading period query and supports multiple exchanges;

[0084] The third category is the latest data, which provides the latest market data. When backtesting, data can be extracted from historical data, and when trading in real time, components can be replaced to obtain market data from external middleware such as Redis and MQ.

[0085] In this embodiment, the calling logic of the data calling module will form a data API interface for calling by other components of the backtesting framework.

[0086] 1.3 Event Engine Module

[0087] The event engine module 103 is centered on the message queue and is divided into two parts: an event source component and an event bus component. The event source component is used to receive data from different data sources and convert it into event objects, and the event bus component is used to distribute event objects to other modules for consumption.

[0088] The event engine module is responsible for receiving and processing events from data sources (such as historical market data, transaction data, etc.), and triggering corresponding processing logic based on these events, such as executing transactions, updating positions, calculating profits and losses, etc. Therefore, in terms of design ideas, the event engine module is centered on the message queue and is divided into two parts: event source and event bus. The event source object is responsible for extracting and storing events from the data source, while the event bus is responsible for distributing the imported event objects for consumption by other components (modules) of the backtesting system.

[0089] 1.3.1 Event Object

[0090] In this embodiment, the event object adopts a unified event model to describe different event types and event attributes and supports extended custom attributes. The event model includes the type, timestamp and data content of the event; event types include: time period type, transaction object type, market situation type and operation command type.

[0091] In order to better describe different types of events and their attributes, it is necessary to define a unified event model. The event model should contain basic information such as event type, timestamp, data content, and support expansion to accommodate more custom attributes.

[0092] In this embodiment, event types include: time stage types, such as system initialization, strategy initialization, before opening, during opening, before closing, after closing, given transaction time point, given time frequency, after strategy execution, system completion, etc.; transaction object types, such as order creation, order status update, order completion, transaction by transaction, etc.; market situation types, such as K-line, tick snapshot, etc.; operation command types, such as data persistence, capital inflow and outflow, manual order, etc.

[0093] In this embodiment, after the relevant data is imported from the data source or other plug-in modules through the event engine module, the data is converted into event objects and then placed on the event bus for consumption by other components (modules) of the backtesting system.

[0094] 1.3.2 Event Source Component

[0095] In this embodiment, the event source component extracts data from each data source and converts it into event objects; when the quantitative trading strategy adopts the backtesting mode, the event source component extracts time calendar data from the data source, generates time stage type events and submits them to the event bus component for distribution; when the quantitative trading strategy adopts the real-time mode, the event source component generates an event production thread separately, and extracts the latest data from the data source through the event production thread, and checks whether it reaches the given time point. If it reaches the given time point, a real-time event object is generated and sent to the internal queue (message queue). The internal queue is used to isolate the event production thread generated by the event source component from the event consumption threads generated by other modules.

[0096] In this embodiment, the event source component is responsible for generating events. The event source component is connected to the data layer, thereby continuously extracting data from various data sources to generate related event objects. Depending on the different operating modes, the generation and processing methods of event objects will also be different.

[0097] For example, if the quantitative trading strategy adopts the backtesting mode, it mainly extracts time calendar data from the data source, generates time stage type events, and then directly distributes them to the event bus. Considering that the quantitative trading strategy may be designed for a large number of targets, it is recommended that users give priority to using the time stage type event object, and actively pull data for logical processing through the callback function at each time point, rather than subscribing to market data and waiting for callback triggers, thereby reducing backtesting consumption.

[0098] If the quantitative trading strategy is adopted, the event source component will start a separate thread to extract the latest data from the external data source and check whether it reaches the given time point. If it reaches the given time point, it will generate a real-time event object and send it to the internal queue. The queue isolates the event production thread and the event consumption thread to avoid resource competition in multi-threaded situations.

[0099] 1.3.3 Event Bus Component

[0100] In this embodiment, the event bus component allows other modules to register event listeners. When the event listener detects the arrival of a corresponding event, the corresponding module is triggered to execute a callback so that the corresponding module can execute corresponding processing logic according to the type and content of the event.

[0101] The event bus component allows other communication components (modules) to register message processing functions (event listeners) with themselves, thereby triggering callbacks when corresponding events arrive, so that corresponding processing logic can be executed according to the type and content of the event.

[0102] In this embodiment, the event bus component is essentially an implementation of the publish & subscribe model, providing a centralized event processing mechanism, allowing different components to communicate with each other without being interdependent, achieving loose coupling, and thereby improving the modularity of the system, reducing the complexity of the system, and improving the readability and maintainability of the code.

[0103] 2. Transaction Layer

[0104] The trading layer 20 is used to execute the implementation logic of the corresponding quantitative trading strategy simulation backtesting based on the event objects output by the data layer, including strategy construction, signal generation, transaction execution and risk management.

[0105] In this embodiment, the transaction layer 20 further includes:

[0106] 2.1 Strategy Module

[0107] The strategy module 201 is used to dynamically construct quantitative trading strategies through custom strategy classes, and generate corresponding trading signals at corresponding trading time points based on the constructed quantitative trading strategies, while monitoring and limiting potential risks in the quantitative trading process. The custom strategy class is used to encapsulate specific trading logic.

[0108] In this embodiment, since the strategy module determines the logical implementation and backtesting effect of the trading strategy, it is designed to be divided into strategy construction, signal generation, transaction execution and risk management.

[0109] The strategy module first needs to support flexible strategy construction. This is usually achieved by defining strategy classes, each of which encapsulates specific trading logic. The strategy class contains multiple parameters that allow users to tune according to market conditions and personal preferences. For example, in a moving average crossover strategy, the number of periods of the short-term and long-term moving averages can be defined as parameters, which will be repeatedly tested during the strategy backtesting process to find the optimal value.

[0110] The core of the strategy module is signal generation. The strategy module generates trading signals such as buy, sell or hold at each trading time point based on market data and internal logic. These signals need to be effectively managed, including signal storage, query, and logic for executing trading orders based on signals. To improve system efficiency, signal generation usually needs to be closely integrated with data processing to ensure that new trading signals can be quickly generated after data is updated.

[0111] The strategy module also includes a complete risk management mechanism to monitor and limit potential risks in the transaction process, including but not limited to position limits, stop loss and take profit settings, capital utilization management, etc. By integrating the risk management module, the strategy module can effectively control risk exposure while ensuring transaction returns.

[0112] In addition, in this embodiment, the design of the strategy module further takes into account scalability and modularity. Through modular design, functions such as strategy logic, data processing, and risk management are separated into independent modules for easy maintenance and upgrading. At the same time, modular design also improves the scalability of the strategy module, allowing users to add new functions or strategies as needed. This type of design makes the backtesting system more flexible and powerful.

[0113] In this embodiment, the quantitative trading strategy is represented by a strategy object, which mainly includes: an initialization method, which is responsible for parameterized construction and will subsequently provide an analysis layer to support parameter optimization; an event callback method, which corresponds to the event callback logic, for example, triggering the moving average strategy after each K-line cycle is completed, executing the moving average calculation logic, and thus generating corresponding buy and sell signals.

[0114] In addition, in this embodiment, considering the flexibility of quantitative trading strategies, a large amount of information query or interaction with other components may be involved in the actual process of making trading decisions, such as:

[0115] (1) Subscribe to time point events to trigger model training at 9:00 a.m. every day; (2) Query the latest price and historical market data in each K-line cycle to calculate whether the signal is triggered; (3) Query the current portfolio's position level and available cash to determine the order target and quantity; (4) In the order management module, query the order execution status and choose to update or cancel the order; (5) Subscribe to the transaction event of the event bus and send a notification every time a transaction is completed.

[0116] In order to solve the above-mentioned problem of large-scale information query or interaction with other components, this embodiment further introduces a context environment object, which encapsulates references to all components (modules) of the backtesting system, as well as common variable data such as time and contract information of the backtesting system, to facilitate the calling of strategy objects. The context environment object adopts a singleton mode in design and will be constructed when the backtesting system is initialized. Each component (module) in the backtesting system can call the context object as needed.

[0117] 2.2 Order Management Module

[0118] The order management module 202 is used to generate trading orders according to the quantitative trading strategy, and manage and track the execution process of all trading orders.

[0119] In this embodiment, in order to manage and track the execution process of all transaction orders and ensure the accuracy, efficiency, flexibility, timeliness and compliance of transactions, the order management module is divided into six sub-modules in actual implementation:

[0120] 2.2.1 Command interface submodule is the entry point for issuing order instructions. It is used to receive order instructions and generate corresponding order objects. One order object uniquely corresponds to one order.

[0121] 2.2.2 The risk control filtering submodule is used to check whether the target amount of the order meets the risk control standards, whether it exceeds the preset amount, and whether the proportion is in violation of regulations.

[0122] 2.2.3 Order verification submodule is used to verify whether the numerical format of the order meets the custom rules. The custom rules include whether there is sufficient funds, whether it is the transaction time, whether the minimum transaction amount is reached, and whether it is a multiple of the minimum transaction unit.

[0123] 2.2.4 Order routing submodule is used to send orders to the corresponding exchange for matching and update the latest order transaction information back to the position portfolio.

[0124] 2.2.5 Cost estimation submodule is used to estimate the transaction cost corresponding to the order before the order is placed. The transaction cost includes commission, tax and management fee. In order to simulate the transaction more realistically, taxes must be considered before placing an order. For example, when buying 10% of A-share stocks, it is actually adjusted to only place an order for 9.975% of the amount, and adjusted downward to an integer multiple of 100 shares.

[0125] 2.2.6 Order algorithm submodule is used to provide a variety of intelligent order placement algorithms. The algorithm objects corresponding to the order placement algorithm include opening a position at a specified time, daily purchase ratio, opening a position at a specified price, closing a position at a specified time, closing a position at a specified price, take-profit order, stop-loss order, retracement, and closing a position after a rebound.

[0126] In this embodiment, in addition to the traditional limit order and market order, the order types generated by the command interface submodule are further enriched in this embodiment to support strategy implementation, such as ordering by amount, ordering by target total amount, ordering by number of shares, ordering by target total number of shares, ordering by percentage, ordering by target total percentage, and ordering by percentage of a basket of targets.

[0127] In addition, in some scenarios, orders are not issued all at once, but need to wait for the right time and execute according to the set conditions. To meet the needs of such scenarios, this embodiment further designs algorithmic orders in the order algorithm submodule. Different ordering algorithms correspond to different algorithm objects, thereby generating different algorithmic orders. For example:

[0128] Algorithm object 1: Open a position at a specified time, and continue to increase the position to a specified upper limit within a specified time period. For example, within the next month, purchase 1% of the portfolio's A stock every day to the upper limit of 10%;

[0129] Algorithm object 2: Open a position at a specified price. When the set price is reached, a corresponding limit order or market order is immediately issued.

[0130] Algorithm object 3: Take profit order, when the price of a certain target breaks through the given upper limit, all positions of the target will be cleared;

[0131] Algorithm object 4: Stop loss order, when the price of a certain target falls below a given lower limit, all positions of the target will be cleared;

[0132] Algorithm object 5: Close the position after a retracement or rebound. When the price drops a certain amount from the highest point or rebounds a certain amount from the lowest point within a given period in the past, the position will be closed.

[0133] In this embodiment, a quantitative trading strategy can execute multiple algorithmic orders at the same time. In order to better manage algorithmic objects, it is necessary to design the priority order of execution of different algorithmic orders. For example, the priority order based on the time point triggers the execution of algorithmic orders when the corresponding time point is reached; the priority order based on the first priority execution level adopts a static method and is set manually; based on the second priority execution level, a dynamic method is adopted, such as judging in real time according to the market environment whether the arbitrage algorithm should place a buy order or a sell order first.

[0134] 2.3 Exchange Module

[0135] The exchange module 203 is used to simulate the real trading environment and realize the transaction process of the trading order based on the trading orders and market data generated by the quantitative trading strategy.

[0136] In this embodiment, the exchange module includes:

[0137] The order preprocessing submodule is used to receive order information generated based on quantitative trading strategies and verify the validity of the order. The order information includes order type, buy and sell direction, quantity and price;

[0138] The order matching submodule is used to obtain the latest market data from the data source in real time or at a set frequency, and simulate order matching based on the latest market data and the set price matching mechanism. The market data includes price, transaction volume, and buy and sell order data;

[0139] The transaction result processing submodule is used to record the transaction order information and push the order status and the transaction result of the order to the message bus. The transaction order information includes the transaction price, transaction volume, and transaction time.

[0140] In this embodiment, the exchange module will simulate the real trading environment based on the orders and market data generated by the quantitative trading strategy to realize the order transaction process. The design of this module needs to comprehensively consider multiple factors such as market trading rules, matching mechanism, transaction fees, etc. to ensure the accuracy and authenticity of the backtest results.

[0141] In addition, in order to realize the functions of each sub-module of the exchange module, basic functional components such as the matchmaker, slippage calculator, and tax calculator are further integrated in the exchange module. The matchmaker will match orders according to the order book, supporting competitive matching, OTC matching, and custom price type matching; when calculating the matching price according to the K-line, it is necessary to add slippage through the slippage calculator; when performing quantitative trading strategy simulation backtesting, the cost estimation submodule inside the order management module will be directly called for cost estimation.

[0142] 3. Analysis Layer

[0143] The analysis layer 30 is used to receive the output instructions of the trading layer, dynamically adjust the holding ratio of each asset in the investment portfolio adopted by the corresponding quantitative trading strategy, calculate multiple key indicators in real time, and collect various relevant data related to quantitative trading, perform performance attribution analysis on the quantitative trading strategy, and output a quantitative trading strategy simulation backtest report;

[0144] In this embodiment, the analysis layer 30 further includes:

[0145] 3.1 Portfolio holding module

[0146] The portfolio holding module 301 is used to simulate and record the holdings of various assets in the investment portfolio, and calculate a variety of key indicators in real time, including holding costs, account fund changes, and account profit and loss changes.

[0147] In this embodiment, in the order of calling, the combined position module supports the following functions:

[0148] 1. Fund initialization: Before the backtest begins, set the initial funds or initial position for the trading account. This is the basis for simulated trading and the starting point for subsequent calculation of profit and loss and backtest results.

[0149] 2. Rate setting: used to set the cost rate related to quantitative trading, including portfolio management rate and financing rate;

[0150] 3. Position management is used to record the types, quantities, and cost prices of assets held in the position structure corresponding to the current quantitative trading strategy, which can help users understand the position structure of the quantitative trading strategy and facilitate the execution of corresponding transactions or risk control decisions.

[0151] 4. Transaction entry is used to record the changes in funds in the trading account after each quantitative transaction is completed. The changes in funds include the amount of assets bought or sold and transaction fees;

[0152] 5. Profit and loss calculation is used to calculate the profit and loss of the account in real time based on transaction records and positions, and leave a cross-sectional snapshot at the time of settlement on the same day. The profit and loss calculation needs to take into account all transaction and holding costs.

[0153] 6. Persistence is used to record the position data within the portfolio, provide a basis for incremental backtesting during simulated quantitative trading, and record daily snapshot data to provide a basis for performance evaluation indicators.

[0154] In this embodiment, in order to better fit the actual trading scenario, the design of the quantitative trading strategy is divided into multiple levels, including from top to bottom:

[0155] Level 1: Each quantitative trading strategy corresponds to a combination object;

[0156] Level 2: Each portfolio object can have multiple account objects, such as A-share account, Hong Kong stock account, stock account, and futures account;

[0157] Level 3: Each account object can have multiple position objects, such as cash position, stock position, and bond position; each account object manages multiple types of asset positions, including at least one cash position and several other asset positions;

[0158] Level 4: Each position object contains multiple position amount values, such as total position, liquidable position, in-transit position, frozen position, and borrowed position.

[0159] In this embodiment, the above four levels will be called from top to bottom to complete the implementation of the above six functions. For example, for transaction entry, the calling logic is as follows:

[0160] 1. The combination object routes the transaction to the corresponding account object;

[0161] 2. The account object continues to issue it to the existing position object of the target for processing (if there is no such position, a new one will be created). This operation will return the capital change brought about by this transaction, which will then be handed over to the cash position under the account for processing.

[0162] 3. The target position object will change the existing position, frozen amount, etc. according to the direction and amount of the transaction. Similarly, the cash position object will also be changed accordingly.

[0163] 3.2 Performance Attribution Module

[0164] The performance attribution module 302 is used to collect various relevant data related to quantitative trading, calculate the performance evaluation indicators of the portfolio holdings during the backtesting period, and perform performance attribution analysis on the quantitative trading strategy based on each performance evaluation indicator, and output a quantitative trading strategy simulation backtesting report. The relevant data includes key indicators, and the performance attribution analysis includes performance attribution analysis based on net value, performance attribution analysis based on positions, and performance attribution analysis based on a custom analyzer.

[0165] In this embodiment, the performance attribution module further includes:

[0166] (1) Data collection submodule, which is used to collect various data related to quantitative trading, including order and transaction details, daily cross-sectional snapshot data of positions, daily account and portfolio position statistics, benchmark index net value and user-defined indicators.

[0167] In this embodiment, the relevant data collected by the data collection submodule includes:

[0168] 1) Order and transaction details;

[0169] 2) Daily cross-sectional snapshot data of positions, including the position amount, profit and loss of each position asset;

[0170] 3) Daily statistics of account and portfolio positions, including total account value, portfolio net value, and daily returns;

[0171] 4) Benchmark index net value: By comparing the performance of quantitative trading strategies with market indices or similar strategies, the relative merits of the strategies can be judged;

[0172] 5) User-defined indicators usually use factor values ​​and signal values ​​generated during the backtesting of quantitative trading strategies to facilitate subsequent corroborative analysis;

[0173] (2) The indicator calculation submodule is used to calculate the performance evaluation indicators of the portfolio holdings during the backtest period based on the collected various relevant data related to quantitative trading. The performance evaluation indicators include annualized rate of return, Sharpe ratio, Sortino ratio, Karma ratio, and maximum drawdown for net asset value attribution analysis, as well as industry allocation returns, interaction effect returns, individual stock selection returns, and factor style returns for position attribution analysis.

[0174] In this embodiment, the indicators that need to be calculated by the indicator calculation submodule in the performance attribution analysis include:

[0175] 1) Net value attribution: a performance indicator that directly evaluates the effectiveness of a strategy, which requires calculation of indicators such as annualized rate of return, Sharpe ratio, Sortino ratio, Karma ratio, maximum drawdown, Alpha, Beta, etc.

[0176] 2) Position attribution: Calculate the risk-return sources of the decomposition strategy at the asset level and the category level. Indicators such as industry allocation returns, interaction effect returns, individual stock selection returns, and factor style returns need to be calculated.

[0177] In addition, considering that different types of quantitative trading strategies may have different performance analysis focuses, this embodiment also allows the use of user-defined analyzers. For example, the performance analysis of fixed income strategies will add analysis of indicators such as duration and yield to maturity.

[0178] (3) Report drawing submodule, which is used to draw a visualized quantitative trading strategy simulation backtesting report based on the results of attribution analysis. The quantitative trading strategy simulation backtesting report supports time dimension scaling and selective multi-standard comparison;

[0179] In this embodiment, after completing the relevant attribution analysis, the attribution analysis results can be visualized to display the analysis results in an intuitive way. For example, pyecharts is selected as the underlying library for visualization to assist in drawing interactive and dynamic charts. The output charts in this embodiment support:

[0180] 1) Time dimension scaling, for example, you can scale the net value to a certain interval to observe the trend or the maximum drawdown of a certain interval;

[0181] 2) Selective comparison of multiple benchmarks, for example, you can add comparison of benchmark net asset value trends and risk-free net asset value trends, and select performance indicator comparisons for specific periods.

[0182] At the same time, this embodiment can also generate a report in HTML format, and can also embed the report in HTML format into the web page service, thereby leaving an additional optional solution for future production applications.

[0183] (4) Result persistence submodule, which is used to persist the indicator data and report files generated by each submodule in the performance attribution module locally and upload them to the remote server through the preset interface.

[0184] In this embodiment, the indicator data and report files generated by the performance attribution module can be processed with traces. Experiment traces can help users record the relevant files of each experiment and determine which data, codes and parameters are used to obtain a specific result.

[0185] In this embodiment, the business logic of quantitative trading strategy simulation backtesting can be realized through the above data layer, transaction layer and analysis layer. In order to facilitate user operation, in this embodiment, the quantitative trading strategy simulation backtesting framework is further provided with an entry module.

[0186] The entry module is used to access the quantitative trading strategy simulation backtesting framework to perform event-driven quantitative trading strategy simulation backtesting;

[0187] Among them, the entry module includes:

[0188] The entry point submodule is the entry point of the entire quantitative trading strategy simulation backtesting framework and serves as the executor of the quantitative trading strategy simulation backtesting. It is used to read configuration files, instantiate components, and execute the backtesting process of the quantitative trading strategy simulation.

[0189] Module manager, which is used to manage the construction, configuration, and destruction of all modules in the quantitative trading strategy simulation backtesting framework, and allows users to customize plug-ins;

[0190] The context submodule is used to carry the references of each key module and important information in the backtesting process and transmit them in the quantitative trading strategy simulation backtesting framework;

[0191] The parameter configuration submodule is used to adjust the parameters in each module in the quantitative trading strategy simulation backtesting framework.

[0192] In this embodiment, the parameter configuration module is the key to ensure the flexibility and scalability of the framework, and is the bridge between the strategy and the execution environment. The configuration file allows users to flexibly adjust various parameters in the backtesting process according to different market environments and strategy requirements. For example, in the stock backtesting scenario, users can easily modify parameters such as moving average slippage and taxes, examine the impact cost of the strategy without directly modifying the code, and improve the efficiency and convenience of backtesting adjustments.

[0193] In this embodiment, the complete configuration file content includes:

[0194] 1) Basic parameters: backtest frequency, start date, end date;

[0195] 2) Data access and call module: database connection URL, transaction calendar type;

[0196] 3) Event engine module: event source type (real, simulation);

[0197] 4) Order management module: order verification operations, tax calculator types;

[0198] 5) Exchange module: exchange type, slippage calculator type, matchmaker type;

[0199] 6) Portfolio holding module: initial capital, initial position, management fee rate, financing fee rate;

[0200] 7) Performance attribution module: analyzer type, result storage type.

[0201] In the actual backtesting process, for most modules, this embodiment adopts the dependency injection mode for construction, imports the corresponding component type and parameters from the configuration file to instantiate the module, and then imports it into the system for calling.

[0202] The present invention also provides a quantitative trading strategy simulation backtesting system, which includes the event-driven quantitative trading strategy simulation backtesting framework described in any of the above embodiments.

[0203] Since the embodiments of the quantitative trading strategy simulation backtesting system part correspond to the embodiments of the above-mentioned quantitative trading strategy simulation backtesting framework, please refer to the embodiments of the above-mentioned framework for the introduction of the quantitative trading strategy simulation backtesting system provided by the present invention. The present invention will not be repeated here, and it has the same beneficial effects as the above-mentioned quantitative trading strategy simulation backtesting framework.

[0204] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0205] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An event-driven quantitative trading strategy simulation backtesting framework, characterized in that: The quantitative trading strategy simulation backtesting framework includes: data layer, trading layer and analysis layer; The data layer is used to provide the data required for the simulation backtesting of the quantitative trading strategy and trigger the generation of the event objects required for the simulation backtesting of the quantitative trading strategy; the trading layer is used to execute the implementation logic of the simulation backtesting of the corresponding quantitative trading strategy based on the event objects output by the data layer, including strategy construction, signal generation, transaction execution and risk management; the analysis layer is used to receive the output instructions of the trading layer, dynamically adjust the holding ratio of each asset in the investment portfolio adopted by the corresponding quantitative trading strategy, and calculate a variety of key indicators in real time, as well as collect various relevant data related to quantitative trading, perform performance attribution analysis on the quantitative trading strategy, and output a simulation backtesting report for the quantitative trading strategy; The data layer includes: a data access module, a data call module and an event engine module; the data access module is used to interact with several data sources, including data access, data storage and data query; the data call module includes multiple data call interfaces, each of which corresponds to a data call logic, which is used to call specific data according to a given data call logic, and the specific data includes basic contract information, trading calendar, historical market conditions, dividends and stock splits, suspension and price limit dates, and the latest market data; the event engine module is centered on the message queue and is divided into two parts: the event source component and the event bus component. The event source component is used to receive data from different data sources and convert it into event objects, and the event bus component is used to distribute event objects to other modules for reception and processing; The trading layer includes: a strategy module, an order management module and an exchange module; the strategy module is used to dynamically construct a quantitative trading strategy through a custom strategy class, and generate corresponding trading signals at corresponding trading time points according to the constructed quantitative trading strategy, while monitoring and limiting potential risks in the quantitative trading process, and the custom strategy class is used to encapsulate specific trading logic; the order management module is used to generate trading orders according to the quantitative trading strategy, and manage and track the execution process of all trading orders; the exchange module is used to simulate the real trading environment according to the trading orders and market data generated by the quantitative trading strategy, and realize the transaction process of the trading orders; The analysis layer includes: a portfolio holding module and a performance attribution module. The portfolio holding module is used to simulate and record the holdings of various assets in the investment portfolio, and calculate multiple key indicators in real time. The key indicators include holding costs, account fund changes, and account profit and loss changes; the performance attribution module is used to collect various relevant data related to quantitative trading, calculate the performance evaluation indicators of portfolio holdings during the backtest period, and perform performance attribution analysis on quantitative trading strategies based on the performance evaluation indicators, and output a simulation backtest report of the quantitative trading strategy. The relevant data includes the key indicators, the The performance attribution analysis includes performance attribution analysis based on net value, performance attribution analysis based on positions and performance attribution analysis based on custom analyzers. The relevant data include order and transaction details, daily cross-sectional snapshot data of positions, daily account and portfolio holdings statistics, benchmark index net value and user-defined indicators. The performance evaluation indicators include annualized rate of return, Sharpe ratio, Sortino ratio, Karma ratio, maximum drawdown for net value attribution analysis, and also include industry allocation returns, interaction effect returns, individual stock selection returns and factor style returns for position attribution analysis.

2. The event-driven quantitative trading strategy simulation backtesting framework according to claim 1, characterized in that: The event object adopts a unified event model to describe different event types and event attributes and supports extended custom attributes. The event model includes the type, timestamp and data content of the event; the event types include: time stage type, transaction object type, market situation type and operation command type.

3. The event-driven quantitative trading strategy simulation backtesting framework according to claim 2, characterized in that: The event source component extracts data from each data source and converts it into event objects; when the quantitative trading strategy adopts the backtesting mode, the event source component extracts time calendar data from the data source, generates time stage type events and submits them to the event bus component for distribution; when the quantitative trading strategy adopts the real-time mode, the event source component generates an event production thread separately, and extracts the latest market and trading data from the data source through the event production thread, and checks whether it reaches the given time point. If it reaches the given time point, a real-time time event object is generated and sent to the internal queue. The internal queue is used to isolate the event production thread generated by the event source component from the event consumption threads generated by other modules.

4. The event-driven quantitative trading strategy simulation backtesting framework according to claim 3 is characterized in that: The event bus component allows other modules to register event listeners. When the event listener detects the arrival of a corresponding event, it triggers the corresponding module to execute a callback so that the corresponding module can execute corresponding processing logic according to the type and content of the event.

5. The event-driven quantitative trading strategy simulation backtesting framework according to claim 1, characterized in that: The order management module includes: The command interface submodule is the entry point for issuing order instructions. It is used to receive order instructions and generate corresponding order objects. One order object uniquely corresponds to one order. The risk control filtering submodule is used to check whether the target amount of the order meets the risk control standards, whether it exceeds the preset amount, and whether the proportion is in violation of the rules; The order verification submodule is used to verify whether the numerical format of the order meets the custom rules, including whether there is sufficient funds, whether it is the transaction time, whether the minimum transaction amount is reached, and whether it is a multiple of the minimum transaction unit; The order routing submodule is used to send orders to the corresponding exchange for matching and update the latest order transaction information back to the position portfolio; The cost estimation submodule is used to estimate the transaction cost corresponding to the order before the order is placed, and the transaction cost includes commission, tax and management fee; The order algorithm submodule is used to provide a variety of intelligent order placement algorithms. The algorithm objects corresponding to the order placement algorithms include opening a position at a specified time, daily purchase ratio, opening a position at a specified price, closing a position at a specified time, closing a position at a specified price, take-profit order, stop-loss order, retracement, and closing a position after a rebound.

6. The event-driven quantitative trading strategy simulation backtesting framework according to claim 1, characterized in that: The exchange module includes: The order preprocessing submodule is used to receive order information generated based on the quantitative trading strategy and verify the validity of the order, wherein the order information includes order type, buying and selling direction, quantity and price; The order matching submodule is used to obtain the latest market data from the data source in real time or at a set frequency, and simulate order matching based on the latest market data and the set price matching mechanism. The market data includes price, transaction volume, and buy and sell order data; The transaction result processing submodule is used to record the transaction order information and push the order status and the transaction result of the order to the message bus. The transaction order information includes the transaction price, transaction volume, and transaction time.

7. The event-driven quantitative trading strategy simulation backtesting framework according to claim 1, characterized in that: The combined position module includes: The capital initialization submodule is used to set the initial capital or initial position for the trading account before the backtest begins; The fee setting submodule is used to set the cost rate related to quantitative trading, which includes the portfolio management rate and the financing rate; The fund change record submodule is used to record the fund changes of the trading account after each quantitative transaction is completed. The fund changes include the amount of assets bought or sold and the transaction fees; The position management submodule is used to record the type, quantity, and cost price of assets held in the position structure corresponding to the current quantitative trading strategy; The profit and loss calculation submodule is used to calculate the profit and loss of the account in real time based on the transaction records and positions, and to leave a cross-sectional snapshot at the time of settlement on the same day; The persistence submodule is used to record the position data within the portfolio, provide a basis for incremental backtesting during simulated quantitative trading, and record daily snapshot data to provide a basis for performance evaluation indicators.

8. The event-driven quantitative trading strategy simulation backtesting framework according to claim 1, characterized in that: The performance attribution module includes: The data collection submodule is used to collect various data related to quantitative trading; The indicator calculation submodule is used to calculate the performance evaluation indicators of the portfolio holdings during the backtest period based on the collected various relevant data related to quantitative trading; The report drawing submodule is used to draw a visualized quantitative trading strategy simulation backtesting report based on the results of attribution analysis. The quantitative trading strategy simulation backtesting report supports time dimension scaling and selective multi-standard comparison; The result persistence submodule is used to persist the indicator data and report files generated by each submodule in the performance attribution module locally and upload them to a remote server through a preset interface.

9. The event-driven quantitative trading strategy simulation backtesting framework according to any one of claims 1 to 8, characterized in that: The quantitative trading strategy simulation backtesting framework also includes: An entry module, used to access the quantitative trading strategy simulation backtesting framework to perform event-driven quantitative trading strategy simulation backtesting; Wherein, the entry module includes: The entry point submodule is the entry point of the entire quantitative trading strategy simulation backtesting framework and serves as the executor of the quantitative trading strategy simulation backtesting. It is used to read configuration files, instantiate components, and execute the backtesting process of the quantitative trading strategy simulation. A module manager is used to manage the construction, configuration, and destruction of all modules in the quantitative trading strategy simulation backtesting framework, and to allow users to customize plug-ins; The context submodule is used to carry the references of each key module and important information in the backtesting process and transmit them in the quantitative trading strategy simulation backtesting framework; The parameter configuration submodule is used to adjust the parameters in each module in the quantitative trading strategy simulation backtesting framework.

10. A quantitative trading strategy simulation backtesting system, characterized in that: The quantitative trading strategy simulation backtesting system includes the event-driven quantitative trading strategy simulation backtesting framework described in any one of claims 1-9.

Images