Data processing method and apparatus for quantitative trading, and device

Abstract

The present application provides a data processing method and apparatus for quantitative trading, and a device. The method comprises: in response to an execution operation for a quantitative trading strategy, acquiring a market data setting time period for a market data indicator indicated by a preset strategy condition in the quantitative trading strategy, and a target actual execution time period of the quantitative trading strategy; determining a target market data time period on the basis of the market data setting time period and the target actual execution time period; acquiring target market data of a trading instrument during the target market data time period in the quantitative trading strategy, and acquiring an indicator value of the market data indicator on the basis of the target market data; and in response to the indicator value of the market data indicator meeting the preset strategy condition of the quantitative trading strategy, triggering execution of a trading operation indicated by a preset strategy operation in the quantitative trading strategy. Thus, reliable and reasonable execution of quantitative trading can be ensured, and the accuracy of quantitative trading is improved.

Description

Data processing methods, devices and equipment for quantitative trading

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510122696.3, filed on January 26, 2025, entitled "Data Processing Method, Apparatus and Equipment for Quantitative Trading". Technical Field

[0003] This application relates to the field of data processing technology, and in particular to a data processing method, apparatus and equipment for quantitative trading. Background Technology

[0004] Quantitative trading refers to a method that uses mathematical models, computer technology, and statistical analysis, combined with massive amounts of market data, to predict and analyze market prices and trading volumes, and to formulate trading decisions.

[0005] Currently, the regular trading session for virtual resources is during the daytime session. Other trading sessions include the night session, pre-market session, and after-market session. The timeliness and liquidity of orders differ across trading sessions, and trading strategies also have specific requirements for order timeliness and liquidity. Quantitative trading often involves different trading sessions; therefore, how to reasonably handle trading sessions and ensure the reliable and reasonable operation of quantitative trading is the problem this application aims to solve. Summary of the Invention

[0006] This application provides a data processing method, apparatus, and equipment for quantitative trading, which can ensure the reliable and reasonable operation of quantitative trading and improve the accuracy of quantitative trading.

[0007] In a first aspect, this application provides a data processing method for quantitative trading, comprising: in response to an operation of a quantitative trading strategy, obtaining the market setting time period indicated by a preset strategy condition in the quantitative trading strategy, and the target actual running time period of the quantitative trading strategy; determining the target market time period based on the market setting time period and the target actual running time period; obtaining the target market data of the trading object in the quantitative trading strategy under the target market time period, and obtaining the indicator value of the market indicator based on the target market data; and triggering the execution of a trading operation indicated by the preset strategy operation in the quantitative trading strategy in response to the indicator value of the market indicator satisfying the preset strategy condition of the quantitative trading strategy.

[0008] Secondly, this application provides a data processing device for quantitative trading, comprising: a first acquisition module, configured to acquire, in response to an operation of a quantitative trading strategy, a market setting time period indicated by a preset strategy condition in the quantitative trading strategy, and a target actual running time period of the quantitative trading strategy; a first determination module, configured to determine a target market time period based on the market setting time period and the target actual running time period; a second acquisition module, configured to acquire target market data of the trading object in the quantitative trading strategy during the target market time period, and acquire the indicator value of the market indicator based on the target market data; and a trading execution module, configured to trigger the execution of a trading operation indicated by a preset strategy operation in the quantitative trading strategy in response to the indicator value of the market indicator satisfying the preset strategy condition of the quantitative trading strategy.

[0009] Thirdly, this application provides an electronic device, including: a processor and a memory, the memory for storing a computer program, and the processor for calling and running the computer program stored in the memory to perform the methods as described in the first aspect or its various implementations.

[0010] Fourthly, this application provides a computer-readable storage medium for storing a computer program that causes a computer to perform the methods described in the first aspect or its various implementations.

[0011] Fifthly, this application provides a computer program product including computer program instructions that cause a computer to perform the methods as described in the first aspect or its various implementations.

[0012] Sixthly, this application provides a computer program that causes a computer to perform the methods described in the first aspect or its various implementations.

[0013] Other technical features and effects involved in this application will be described in subsequent embodiments, and will not be repeated here to avoid repetition. Attached Figure Description

[0014] The accompanying drawings used in the following description of the embodiments are introduced.

[0015] Figure 1 is a schematic diagram of an application scenario provided by an embodiment of this application;

[0016] Figure 2 is a flowchart of a data processing method for quantitative trading provided in an embodiment of this application;

[0017] Figure 3 is a schematic diagram of a data processing method for quantitative trading provided in an embodiment of this application;

[0018] Figure 4 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0019] Figure 5 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0020] Figure 6 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0021] Figure 7 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0022] Figure 8 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0023] Figure 9 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0024] Figure 10 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0025] Figure 11 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0026] Figure 12 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0027] Figure 13 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0028] Figure 14 is a schematic diagram of another data processing method for quantitative trading provided in an embodiment of this application;

[0029] Figure 15 is a schematic diagram of a data processing device 1500 for quantitative trading provided in an embodiment of this application;

[0030] Figure 16 is a schematic diagram of an electronic device 1600 provided in an embodiment of this application. Detailed Implementation

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0032] It should be understood that the technical solution of this application can be applied to the following scenarios, but is not limited to:

[0033] In one embodiment, this application can be applied to quantitative trading scenarios.

[0034] In one embodiment, as shown in FIG1, the application scenario may include a terminal device 110 and a server 120, and the terminal device 110 and the server 120 may be connected via a wired network or a wireless network.

[0035] The terminal device 110 is equipped with a client for virtual resource trading, and the server 120 is the server corresponding to this client. Specifically, the client includes a client front-end and a client back-end. The client front-end provides an interactive interface for users to build and select quantitative trading strategies and receive trigger operations to execute the quantitative trading strategies. The client back-end serves as the strategy execution end for the quantitative trading strategies, used to actually send market data acquisition requests and trading requests to the interface of the server 120 to execute the quantitative trading strategies.

[0036] After receiving an operation request for a quantitative trading strategy, the client frontend can obtain the market time period set by the market indicators indicated by the preset strategy conditions in the quantitative trading strategy, as well as the target actual running time of the quantitative trading strategy, and determine the target market time period accordingly. Then, it can obtain the target market data from the server based on the target market time period. Finally, it can obtain the indicator value of the market indicators based on the target market data. In response to the indicator value of the market indicators meeting the preset strategy conditions of the quantitative trading strategy, it triggers the execution of the trading operation indicated by the preset strategy operation in the quantitative trading strategy.

[0037] Server 120 can be a single server, a server cluster consisting of multiple servers, or a cloud platform control center, but is not limited to these. Terminal device 110 can be a mobile phone, tablet computer, laptop computer, or desktop computer, but is not limited to these.

[0038] It should be noted that the terminal devices and servers in Figure 1 are merely exemplary, and may include other numbers or types of terminal devices or servers.

[0039] The following is a description of the various time periods involved in this application:

[0040] In one embodiment, as shown in Figure 3, under time zone 1, the trading hours for virtual resources can be divided into four periods: night session (20:00-4:00), pre-market session (4:00-9:30), intraday session (9:30-16:00), and after-hours session (16:00-20:00). The intraday, pre-market, after-hours, and night sessions can be referred to as full-time sessions. In some trading markets, virtual resources are allowed to be traded outside of regular trading hours (e.g., intraday sessions), such as pre-market, after-hours, and night sessions. The quantitative trading method involved in this application can support trading in at least one of these four periods, thereby ensuring the continuity of market data and trade execution throughout the day, thus ensuring the reliable and reasonable operation of quantitative trading.

[0041] In the embodiments, the market data setting time period, actual running time period, market data time period, order placement time period parameter, transaction setting time period, actual execution time period, transaction execution time period, or transaction time period parameter can all include at least one of the above four time periods.

[0042] Furthermore, different trading sessions correspond to varying levels of liquidity and timeliness. For instance, regarding liquidity, intraday trading sessions have higher liquidity than pre-market and after-hours sessions, and pre-market and after-hours sessions have higher liquidity than night trading sessions. Different investors have varying tolerances and needs for liquidity. In scenarios requiring rapid purchases, orders need to be sent to the exchange server at the current opening time, resulting in a high demand for liquidity. In scenarios where rapid purchases are not necessary, orders can be submitted and executed during intraday trading sessions, allowing for a higher tolerance for low-liquidity trading. Regarding timeliness, 24 / 7 trading offers the highest efficiency, eliminating the need to wait for the market to open and facilitating the timeliness needs of investors in different regions. This application addresses both liquidity and timeliness by determining the target market time period corresponding to the target market data acquired during the execution of a quantitative trading strategy, as well as the target trading execution time period corresponding to the submission of target orders to the corresponding exchange server. This allows for reasonable processing of market time periods and trading execution time periods, ensuring the reliable and efficient operation of quantitative trading and improving its accuracy. This will be described in the following embodiments.

[0043] The following is a brief introduction to some of the terms used in the embodiments:

[0044] Quantitative trading strategies refer to the process of using computer technology to complete trades based on pre-defined strategies. A quantitative trading strategy specifically includes the trading object, preset strategy conditions, and preset strategy operations triggered when the preset strategy conditions are met (such as placing an order or canceling an order).

[0045] Preset strategy conditions include, but are not limited to, the market indicators related to the trading object needing to meet specific conditions. For example, taking the moving average golden cross opening strategy as an example of quantitative trading strategy, when the K-line data of the trading object specified in the quantitative trading strategy crosses the moving average of its K-line data in a certain short period over a certain long period (i.e., the preset strategy conditions are met), a buy order is executed for the trading object.

[0046] The market indicators indicated by the preset strategy conditions can be those that help investors analyze market trends and predict future price movements. These indicators reflect market trends, momentum, volatility, strength, and other characteristics, and can be used to guide trading decisions and generate trading signals. Market indicators can be candlestick data, the Average True Range (ATR), the Relative Strength Index (RSI), or Bollinger Bands, but are not limited to these.

[0047] The market data setting period for market indicators refers to the time period restrictions set by the user for the corresponding market indicators in the preset strategy conditions when configuring a quantitative trading strategy. The trading setting period for preset strategy operations refers to the time period restrictions set by the user for the preset strategy operations when configuring a quantitative trading strategy.

[0048] Specifically, the market data setting time period can include any of the following: a first market data setting time period, a second market data setting time period, and a third market data setting time period. The first market data setting time period includes the intraday session; the second market data setting time period includes the intraday session, pre-market session, and after-market session; and the third market data setting time period includes the intraday session, pre-market session, after-market session, and night session. For example, taking the first market data setting time period as an example in a quantitative trading strategy where the preset strategy conditions are configured, during the operation of the quantitative trading strategy, when retrieving market data, the target market data period can be determined based on the first market data setting time period and the current target actual running time, so that the corresponding market data can be retrieved according to the target market data period. The trading time period can include any of the following: a first trading time period, a second trading time period, a third trading time period, and a fourth trading time period. The first trading time period includes intraday trading hours, the second trading time period includes intraday trading hours, pre-market trading hours, and after-market trading hours, the third trading time period includes intraday trading hours, pre-market trading hours, after-market trading hours, and night trading hours, and the fourth trading time period includes night trading hours. For example, if the trading time period for the preset strategy operation in a quantitative trading strategy is configured as the third trading time period, during the operation of the quantitative trading strategy, when the preset strategy conditions are met, the trading operation indicated by the preset strategy operation can be executed at any time.

[0049] The target actual runtime of a quantitative trading strategy can refer to the time period during which the market data acquisition interface used to obtain the target market data is called. The target actual execution time of a quantitative trading strategy's trading operations can refer to the time period during which the preset strategy operation (such as automatically executing an order placement operation) is triggered during the actual operation of the quantitative trading strategy.

[0050] It is understandable that, based on the above, the liquidity and timeliness of virtual resource trading differ across intraday, pre-market, after-hours, and night trading sessions. Furthermore, as shown in Figure 4, in terms of liquidity, intraday trading is greater than pre-market and / or after-market sessions, and pre-market and / or after-market sessions are greater than all other time periods excluding intraday, pre-market, and after-market sessions. In terms of timeliness, all time periods are greater than pre-market and / or after-market sessions, and intraday trading is greater than pre-market and / or after-market sessions. Therefore, compared to dividing the order placement parameters and market data setting time into four separate periods—intraday, pre-market, after-market, and night trading—the time division method for order placement parameters and market data setting time in this application (layered according to liquidity and timeliness, forward compatible, progressive, and inclusive) can achieve an effective balance between trading liquidity and timeliness in business scenarios, i.e., in the operation of quantitative trading strategies.

[0051] Furthermore, without affecting the ability to acquire intraday market data, it can be gradually expanded to support other time periods for quantitative trading scenarios. This reduces errors and strategy failures caused by time period switching and interface changes, lowering maintenance costs. Simultaneously, it can be easily integrated with the functions and analysis tools of quantitative trading systems that only support intraday trading, without requiring large-scale modifications to existing configurations. This demonstrates high scalability and ease of integration, reducing the complexity and cost of subsequent upgrades. Therefore, while meeting the needs of multi-time period scenarios, it ensures that the integrated market data acquisition interface can implement relatively simple enumeration types, improving data compatibility and flexibility in data acquisition.

[0052] The technical solution of this application will be described in detail below:

[0053] Figure 2 is a flowchart of a data processing method for quantitative trading provided in an embodiment of this application. This method can be executed by the terminal device 110 in the above application scenario, but is not limited thereto. As shown in Figure 2, the method may include the following steps:

[0054] S210: In response to the operation of the quantitative trading strategy, obtain the market setting time period indicated by the preset strategy conditions in the quantitative trading strategy, and the target actual running time of the quantitative trading strategy.

[0055] S220: Determine the target market time period based on the market data setting time period and the target actual running time period;

[0056] S230: Obtain the target market data of the trading object in the quantitative trading strategy during the target market period, and obtain the indicator value of the market indicator based on the target market data;

[0057] S240: In response to the market indicator value meeting the preset strategy conditions of the quantitative trading strategy, the trading operation indicated by the preset strategy operation in the quantitative trading strategy is triggered.

[0058] Upon receiving a run operation for a quantitative trading strategy, the system responds by running the quantitative trading strategy, retrieves the preset trading time period for the strategy operation from the quantitative trading strategy, and determines the target actual running time of the quantitative trading strategy in real time based on the current time information.

[0059] The target market period refers to the time period in which the target market data is used to determine the indicator value of the market indicator.

[0060] In one embodiment, determining the target market time period based on the market data set time period and the target actual running time period may include:

[0061] S220-1: Obtain the first mapping relationship between the market data set time period, the actual running time period, and the market data time period;

[0062] S220-2: Determine the target market time period based on the market data setting time period and the target actual running time period, using the first mapping relationship.

[0063] In the execution of a quantitative trading strategy, the market data set time period for the strategy can be obtained. Then, by calling a market data acquisition interface, the target market data period can be retrieved based on the set time period and the current actual execution time. Specifically, the market data acquisition interface can be set with multiple order placement time period parameters. It should be noted that the time periods involved in the set market data period correspond to the time periods involved in the order placement time period parameters set in the market data acquisition interface. The target market data period can be retrieved by matching the set market data period with the order placement time period parameters and based on the matching result and the current actual execution time. Correspondingly, the first mapping relationship can refer to the mapping relationship between the order placement time period parameters, the actual execution time, and the market data period.

[0064] Specifically, the market data setting time period can be matched with the order time period parameters set in the market data acquisition interface to determine the matching enumerated order time periods; then, based on the matching enumerated order time periods and the target actual runtime period, the target market data time period can be determined based on the first mapping relationship.

[0065] Understandably, the liquidity of trading instruments is highest during intraday trading hours, and the corresponding market data, such as candlestick charts, often exhibits good continuity in time sequence. Market indicators calculated from this data accurately reflect the market trend of the trading instruments, possessing strong readability and reference value. Using these indicators to determine trading signals results in higher accuracy. Conversely, market data outside of intraday trading hours has lower liquidity, and the corresponding data often displays irregular fluctuations, gaps, and other patterns. Market indicators calculated from this data have lower reference value, and using them to determine trading signals results in lower accuracy. Therefore, when users have high requirements for the liquidity of market data, such as for most short-term traders, day traders, or high-frequency traders, using highly liquid market data, such as intraday market data, can effectively reduce slippage losses in quantitative strategy trading and lower transaction costs. When users have high requirements for the timeliness of market data, such as when they need to respond quickly to market changes or try to identify abnormal jumps in market data for specific time periods, if only intraday market data is selected and market data for other time periods is discarded, it will be impossible to obtain the latest market data for all time periods except intraday market data.

[0066] In the above embodiments, the target market time period is determined based on the market data setting time period and the actual running time period. In other words, determining the market indicator value based on the market data of a specific time period simultaneously takes into account the order placement time preset before the quantitative trading strategy runs (corresponding to the market data setting time period) and the actual order placement time during the start of the quantitative trading strategy (corresponding to the actual running time period). This automatic adaptation of the market data setting time period and the actual running time period can meet the needs of trading scenarios under different time periods. Therefore, the above process can ensure that the market data used in the operation of the quantitative trading strategy meets both user needs and conforms to the actual market situation, thereby ensuring the reliability and accuracy of the target market data, and thus guaranteeing the reliable and reasonable operation of quantitative trading and the accuracy of quantitative trading results.

[0067] For example, the market data acquisition interface can be set with an order placement period parameter, which includes multiple enumerated order placement periods. Specifically, the market data setting period and the multiple enumerated order placement periods corresponding to the order placement period parameter can be formatted first (for example, they can be converted to periods in the same time zone and 24-hour format) to obtain the formatted market data setting period and multiple enumerated order placement periods. Then, it can be checked whether each enumerated order placement period overlaps with or completely contains the market data setting period (for example, the start and end times of the formatted market data setting period and multiple enumerated order placement periods can be determined first; then, by comparing the corresponding start and end times, it can be determined whether each enumerated order placement period overlaps with or completely contains the market data setting period). Finally, the enumerated order placement periods that overlap with or completely contain the market data setting period can be determined as the matching enumerated order placement periods.

[0068] For example, the first mapping relationship can be shown in Figure 5, where the set time period refers to the market data set time period, the time period for calling the interface refers to the actual running time period, and the time period corresponding to the market data refers to the market data time period.

[0069] It should be noted that this application does not limit the specific form of the first mapping relationship. For example, the first mapping relationship can be a tree diagram similar to Figure 5. Specifically, in the tree diagram form of the first mapping relationship, the root node can be a name such as "first mapping relationship"; the first-level nodes can be specific categories of market data setting time parameters, such as the first market data setting time, the second market data setting time, and the third market data setting time (or, they can also be specific categories of order placement time parameters); the second-level nodes are located under each first-level node, including the actual running time, such as intraday time, pre-market time, after-market time, and night trading time; the third-level nodes are located under each second-level node, including market data time periods, such as intraday time, pre-market time, after-market time, night trading time, and the intraday time of the previous trading day, etc. Alternatively, different colors or markers can be used to merge the second-level nodes and the third-level nodes into one node to simplify the structure of the first mapping relationship.

[0070] Alternatively, the first mapping relationship can be in tabular form. For example, in a tabular first mapping relationship, the first mapping relationship can be a three-column table, with each column used to record the market data setting period, the actual running period, and the market data period, respectively; each row represents a specific mapping relationship in the first mapping relationship.

[0071] For example, when launching a quantitative trading strategy for live trading, suppose that when a user builds a quantitative trading strategy based on the visualization interface provided by the client front end, the time period limit set for the corresponding market indicators in the preset strategy conditions is all-day. The time period that triggers the call to the market data acquisition interface during the execution of the quantitative trading strategy (i.e., the actual running period) is the pre-market period. Then, according to the first mapping relationship, the target market period can be determined to be the pre-market period. Accordingly, the market data acquisition interface determines the target market period to be the pre-market market period, and the market data acquisition interface can return the real-time market data of the trading object, such as a virtual resource, during the pre-market market period.

[0072] Alternatively, if the market data is set to be intraday and the actual trading period is pre-market, then according to the first mapping relationship, the target market data period can be determined to be intraday. Accordingly, the target market data period returned by the market data acquisition interface is the intraday closing time of the previous trading day. That is, the market data acquisition interface can return the market data of the trading object at the intraday closing time of the previous trading day.

[0073] In one embodiment, after obtaining the target market data for the target market period, the indicator value of the market indicator can be obtained based on the target market data. The indicator value can be a numerical value used to compare with preset strategy conditions in the quantitative trading strategy to determine whether to trigger a trading operation. If the indicator value meets the preset strategy conditions (e.g., the trading value represented by the indicator value reaches the trading price set in the preset strategy conditions), the trading operation indicated by the preset strategy operation in the quantitative trading strategy can be triggered.

[0074] Specifically, if the market indicator is the target market data, then the target market data can be directly used as the indicator value. If the target market data is the raw data used to determine the market indicator, then the market indicator can be determined first based on the target market data, and then the indicator value can be obtained from the market indicator. For example, the market indicator can be a 5-day moving average, and the indicator value can be obtained from the closing prices within 5 days in the target market data.

[0075] Understandably, different market data and indicators have different characteristics. For example, highly liquid candlestick data exhibits more consistent chart patterns without gaps or breaks, such as "flags," "wedges," or "channels." Therefore, for most quantitative trading strategies targeting short-term, intraday, and high-frequency trading, using highly liquid candlestick data allows for rapid market entry and exit, reduces slippage losses, lowers transaction costs, and more accurately reflects market participant behavior and trends. Furthermore, the continuous and gap-free candlestick data provides strong readability and reference value, making it more suitable for interpreting trading signals and providing more reliable quantitative trading results. For timely candlestick data, which reflects real-time market data and represents the latest price and volume levels, especially during non-market trading hours, candlestick data often displays irregular price movements, large fluctuations, low trading volume, and price gaps. When using non-market candlestick data for technical analysis of market indicators corresponding to preset strategy conditions in quantitative trading strategies, the technical analysis signals may not be as reliable as those during market trading hours. However, when quantitative trading strategies require rapid response to market changes or identification of abnormal price jumps in specific time periods, timely candlestick data allows for quick judgments and immediate action, preventing missed opportunities. In other words, trading liquidity is poor during non-market trading hours, and technical indicators calculated using candlestick data from these periods carry a high risk of misinterpretation due to strong market random fluctuations (noise), which affects the quality of trading signals. However, for quantitative trading strategies with high timeliness requirements and the need for immediate execution, candlestick data from these periods can help avoid missing trading opportunities. The technical solution applied for determines the target market data and indicators by dividing multiple time periods into progressive and inclusive segments based on liquidity and timeliness. Therefore, it can effectively convert and balance liquidity and timeliness, which not only meets the user's own needs but also considers the verification of market data. This balances the impact of liquidity and timeliness on the calculation of market indicators, thereby improving the accuracy and relevance of indicator values.

[0076] In one embodiment, before acquiring target market data for the target market period, the terminal device can first pull multiple market data from a backend service, such as a server, and store them in a storage unit (storage container). This storage unit can be the local storage unit corresponding to the client. After determining the target market period, the terminal device can acquire the target market data for the target market period from the storage unit to improve data acquisition efficiency and quantitative trading efficiency.

[0077] The storage capacity of a storage unit can be fixed, and the amount of data it can store is the number of market data points. For example, a storage unit could be a container that can store 1000 candlestick charts.

[0078] Specifically, before obtaining the target market data for the trading object in the quantitative trading strategy during the target market period, the number of market data points required for calculating market indicators can be obtained first; the number of market data points can be pulled from the backend service; based on the time period involved in the number of market data points, the number of market data points can be stored in the sub-cached unit corresponding to the cache unit; then, market data for a specific market period pushed by the backend service can be obtained, which includes any of the following: intraday session, pre-market session, after-market session, or night session; based on the time period involved in the specific market period, the market data for the specific market period can be stored in the sub-cached unit corresponding to the cache unit, and the historical market data stored in the cache unit can be updated so that the number of market data points stored in the cache unit is the number of market data points.

[0079] The cache unit includes: a first sub-cache unit, a second sub-cache unit, and a third sub-cache unit; the first sub-cache unit is used to store market data during the intraday session; the second sub-cache unit is used to store market data during the intraday session, pre-market session, and after-market session; and the third sub-cache unit is used to store market data during the intraday session, pre-market session, after-market session, and night session.

[0080] Accordingly, the above-mentioned acquisition of target market data for the target market period includes: acquiring target market data for the target market period from the cache unit.

[0081] For example, as shown in Figure 6, after the live trading session is started on the client-side frontend, i.e., after the quantitative trading strategy begins running, the client-side backend can subscribe to and retrieve market data for different time periods from the backend service. The backend service can return the market data for different time periods to the client-side backend via data packets, and the client-side backend can store it in a cache. Simultaneously, the backend service can push new market data to the client in real time, allowing the client to update the cache accordingly to maintain a fixed size and ensure the data in the cache is up-to-date. Furthermore, the client-side backend can process the market data for different time periods, storing the market data for different time periods into corresponding sub-cache units in the cache according to the aforementioned progressive and segmented time-based approach. Afterward, the client-side backend can retrieve the target market data from the cache, i.e., the storage unit.

[0082] As shown in Figure 7, the client installed on the terminal device can first subscribe to and retrieve a certain number of market data points from the backend service, for example, 1000 real-time candlestick charts. The client can then retrieve data packets from the backend service and cache the 1000 market data points in the storage unit. When the client subsequently retrieves the target market data, it can obtain the target market data from the storage unit. Furthermore, the backend service can push new market data in real time, i.e., market data for a specific time period, to the client. For example, if it is currently the pre-market session, the backend service can push the candlestick charts for that session to the client in real time to continuously update the data in the storage unit, ensuring that the retrieved market data is up-to-date.

[0083] Moreover, the above embodiments not only support the simultaneous acquisition of market data in different time periods, but also store market data in different time periods into corresponding sub-cached units through a progressive and included time-segmentation method, ensuring that the acquired target market data is directly corresponding to the target market time period (i.e., market data during the intraday period can be directly acquired; or market data during the intraday, pre-market, and post-market periods; or market data for the entire time period), which can reduce the calculation process and improve performance.

[0084] After obtaining the indicator values ​​of the market data and confirming that the indicator values ​​meet the preset strategy conditions of the quantitative trading strategy, the client backend can be triggered to execute the trading operation indicated by the preset strategy operation in the quantitative trading strategy. This will be described in detail below:

[0085] In one embodiment, the trading operation indicated by the preset strategy operation in the above-mentioned quantitative trading strategy includes:

[0086] S240-1: Obtain the trading time period set by the preset strategy operation in the quantitative trading strategy, as well as the target actual execution time period of the trading operation;

[0087] S240-2: Determine the target transaction execution period based on the transaction's set time period and the target's actual execution time period;

[0088] S240-3: Construct the target order and submit it to the exchange server corresponding to the target transaction execution period.

[0089] Among them, the preset strategy operation in the quantitative trading strategy refers to the operation required to continue to execute the quantitative trading strategy after the indicator value of the market indicator meets the preset strategy conditions of the quantitative trading strategy. For example, the trading operation of constructing a target order and submitting the target order based on the acquired target market data.

[0090] The transaction time period corresponding to the preset strategy operation refers to the transaction time period set for the target order to submit the order, i.e., the transaction operation. For example, it can be the transaction time period set by the user based on the client front end.

[0091] The target execution period of a trading operation can refer to the real-time period during which a pre-set strategy operation (such as automatically executing an order placement operation) is triggered during the actual operation of a quantitative trading strategy.

[0092] The target trading execution period refers to the time period during which the preset strategy operation is ultimately executed. Specifically, during the operation of a quantitative trading strategy, the trading time period corresponding to the preset strategy operation can be obtained. Then, by calling a trading interface, the target trading execution period can be obtained based on the preset trading time period and the actual execution time period of the currently called trading interface. Specifically, the trading interface can be set with multiple order placement time period parameters. In one embodiment, similar to the market data acquisition interface, trading time period parameters can be set for the trading interface (used to submit orders, such as target orders). These trading time period parameters can include: a first enumerated trading time period, a second enumerated trading time period, a third enumerated trading time period, and a fourth enumerated trading time period. The first enumerated trading time period includes intraday trading hours; the second enumerated trading time period includes intraday trading hours, pre-market trading hours, and after-market trading hours; the third enumerated trading time period includes intraday trading hours, pre-market trading hours, after-market trading hours, and night trading hours; and the fourth enumerated trading time period includes night trading hours.

[0093] Similarly, as with market data setting periods, trading setting periods include any one of the following: first trading setting period, second trading setting period, third trading setting period, and fourth trading setting period. The first trading setting period includes intraday trading hours, the second trading setting period includes intraday trading hours, pre-market trading hours, and after-market trading hours, the third trading setting period includes intraday trading hours, pre-market trading hours, after-market trading hours, and night trading hours, and the fourth trading setting period includes night trading hours.

[0094] Understandably, similar to the market data acquisition interface and market data setting time periods mentioned above, the progressive and inclusive time period division method can give the trading interface better fault tolerance and scalability. It can be quickly deployed and integrated with the existing intraday trading function without large-scale changes to the existing configuration, and can also support more future upgrade possibilities, reducing long-term maintenance costs.

[0095] Furthermore, the high liquidity of intraday trading sessions ensures sufficient buy and sell orders and a narrowing bid-ask spread, resulting in friendly and stable transaction prices. Therefore, executing trades during intraday sessions guarantees good order liquidity. Outside of intraday trading sessions, due to the scarcity of orders and a lack of counterparties, the bid-ask spread widens. Thus, executing trades throughout the day cannot, to some extent, avoid the transaction risks associated with trading outside of intraday sessions. In scenarios such as panic selling, expiration of options, and bid-ask spread arbitrage, investors prioritize timeliness over liquidity, often needing to quickly clear positions to avoid losses from significant price fluctuations. In such cases, intraday trading alone cannot meet the demand for high timeliness; therefore, all-day execution is required to adapt to 24 / 7 trading. Thus, the aforementioned method of dividing trading sessions based on market data settings and actual execution times not only achieves compatibility with both liquidity and timeliness but also allows investors to flexibly choose trading sessions according to their needs and trading scenarios, significantly increasing trading freedom and flexibility.

[0096] For example, in S240-2, a second mapping relationship between the transaction setting time period, the actual execution time period and the transaction execution time period can be obtained; then, the target transaction execution time period is determined based on the second mapping relationship according to the transaction setting time period and the target actual execution time period.

[0097] It should be noted that the time period involved in the transaction setting period corresponds to the time period involved in the transaction time period parameters set in the transaction interface. The above process can be achieved by matching the transaction setting period with the transaction time period parameters. Correspondingly, the second mapping relationship can refer to the mapping relationship between the transaction time period parameters, the actual execution period, and the transaction execution period. Specifically, the transaction setting period can be matched with the transaction time period parameters set in the transaction interface to determine the matching enumerated transaction time periods; based on the matching enumerated transaction time periods and the target actual execution period, the target transaction execution period is determined based on the second mapping relationship.

[0098] The target trading execution period refers to the time period during which a quantitative trading strategy submits target orders to the corresponding exchange server.

[0099] For example, the second mapping relationship can be shown in Figure 8, where the set time period refers to the transaction set time period, the time period for calling the interface refers to the actual execution time period, and the time period corresponding to the transaction execution refers to the transaction execution time period.

[0100] It should be noted that the process of determining the matching enumeration transaction period is similar to the process of determining the matching enumeration order period described above, and the process of determining the second mapping relationship is similar to the process of determining the first mapping relationship. This application will not elaborate on these aspects.

[0101] Understandably, order execution quality is a crucial indicator for evaluating the effectiveness of trading operations. It involves factors such as execution price, execution speed, and volume. Furthermore, considerations of liquidity and timeliness directly impact execution efficiency and cost (determined based on the aforementioned factors). Specifically, for orders focused on execution price, the primary goal is to ensure execution at the optimal or near-optimal price. This places higher demands on liquidity. Choosing to trade during high-liquidity intraday trading sessions allows for execution at the set price, with appropriate profit-taking and stop-loss management to guarantee execution quality. However, if trading is executed throughout the day, the low liquidity outside of trading hours may prevent execution at the set price, thus failing to achieve the expected strategy returns. For orders that prioritize execution speed, market timeliness is crucial. For example, to minimize the impact of market price fluctuations on trade execution, day traders or algorithmic traders are more concerned with execution speed. If they choose to execute trades throughout the day, the system can provide a rapid response regardless of the current time period, buying or selling immediately at the best available market price, thus ensuring the fastest execution speed. If they choose to execute trades only during the trading session, the order submission will only be executed during that session, often missing trading opportunities. In the above embodiment, the target trade execution period is determined by dividing multiple time periods into a progressive and inclusive manner based on liquidity and timeliness. Therefore, an effective conversion and trade-off can be made between liquidity and timeliness, maximizing resource utilization while supporting all-day trading capabilities and ensuring trade quality.

[0102] For example, for S240-3, a target order can be constructed first based on market indicators; then the target order can be submitted to the exchange server corresponding to the target transaction execution period.

[0103] For example, trading elements can be determined based on market indicators, such as trading quantity, trading price, trading direction, and the type of virtual resource being traded; then, these trading elements can be filled into a preset order template to obtain the target order.

[0104] Different trading sessions are served by different exchange servers. For example, orders placed during the pre-market, intraday, and after-hours sessions can be matched on major exchanges such as the New York Stock Exchange (NYSE) and Nasdaq. In other words, the exchange servers for the pre-market, intraday, and after-hours sessions are the trading servers corresponding to the NYSE and NASDAQ. Orders placed during the night session can be matched on alternative trading systems for US stocks such as BlueOcean ATS (BOATS). In other words, the exchange servers for the night session are the trading servers corresponding to the NYSE and NASDAQ.

[0105] Furthermore, the trading server responsible for executing the pre-defined strategy operation can be determined by combining the order information of the target order and the target transaction execution time period. In one embodiment, the order information of the target order can be obtained, including the transaction object, transaction amount, and transaction quantity. Then, the order information of the target order and the target transaction execution time period are used as matching parameters under various dimensions, and matched with the standard parameters of multiple exchange servers under the corresponding dimensions to determine the trading server responsible for executing the pre-defined strategy operation from among the multiple exchange servers. The standard parameters of each exchange server under the corresponding dimension can be obtained based on the historical order information and historical transaction execution time periods corresponding to historical orders processed by the exchange server. Specifically, the trading server responsible for executing the pre-defined strategy operation can be determined from among multiple exchange servers using the following formula.

[0106] in, Curvalue represents the matching degree between the target order and the j-th exchange server. i This refers to the matching parameters of the target order in the i-th dimension, including order information and the target transaction execution time; refvaluei refers to the standard parameters of a certain exchange server in the i-th dimension, including order information and historical transaction execution times. After obtaining the matching degree between the target order and the j-th exchange server, the exchange server with the highest matching degree can be determined as the trading server that executes the transaction operation indicated by the preset strategy. Determining the trading server that executes the transaction operation indicated by the preset strategy by using the order information and target transaction execution time of the target order can improve the order execution success rate.

[0107] In one embodiment, as shown in Figure 9, the target order can first be submitted to the downstream brokerage server through the client order interface; then, the target order can be processed through the downstream brokerage server, and the processed target order can be routed to the clearinghouse; next, the clearinghouse can perform a verification operation on the processed target order, and the verified target order can be routed to the exchange server corresponding to the target transaction execution period for trading.

[0108] Specifically, target orders can be cached on downstream brokerage servers so that they can be retrieved in real time when needed later (e.g., when the trading market opens, the cached target orders can be retrieved for subsequent trading steps).

[0109] The client can be in the form of a web page or an application, but is not limited to either. The client can perform tasks such as relaying, caching, and managing target orders to ensure transaction continuity.

[0110] In the above embodiments, by defining the target transaction execution period and the exchange server's matching rules for orders in different time periods, transactions in multiple trading venues at different time periods can be realized, thereby maximizing the utilization of the transaction period, ensuring the continuity of transactions in multiple time periods and multiple trading venues, and ensuring the seamless execution of transaction orders in each transaction period, thus improving order flow efficiency.

[0111] In one embodiment, as shown in Figure 10, when submitting a target order to the exchange server, in addition to selecting the corresponding exchange server based on the target transaction execution time (which may include any one of intraday time, intraday time + pre-market time + after-market time, or all-day time), corresponding order flow processing can also be performed according to the order duration of the target order, such as caching, cancellation, and secondary response processing. This will be described below:

[0112] The order period can include the following two types: the validity period on the same day (DAY) and the validity period before cancellation (GTC).

[0113] Specifically, the process can begin by obtaining the order expiration date of the target order. Then, if the order expiration date is valid for the current day, the target order can be cached on the downstream brokerage server. Upon reaching the target trading execution period, the target order can be routed to the corresponding exchange server for trading. If the trade is not successfully executed by the end of the target trading execution period, the target order can be cancelled. Alternatively, if the order expiration date is valid until cancellation, the target order can be cached on the downstream brokerage server. Upon reaching the target trading execution period, the target order can be routed to the corresponding exchange server for trading. If the trade is not successfully executed by the end of the target trading execution period, the target order can be routed to the corresponding exchange server for trading on the next trading day's target trading execution period, until a cancellation request from the target user for the target order is received.

[0114] For example, as shown in Figure 11, assuming the target transaction is executed during the trading session, the target order can first be routed to the downstream brokerage server. Next, the order expiration date can be determined: if the order expiration date is the current day's validity period, the target order can be cached on the server (e.g., the downstream brokerage server) and routed to the exchange server via the clearinghouse for matching when the market opens. If the matching fails by the close, the order can be automatically cancelled. If the order expiration date is the validity period before cancellation, the target order can be cached on the server and routed to the exchange server via the clearinghouse when the market opens. If the matching fails by the close, the order can be automatically returned to the downstream server for caching, and routed to the exchange server again for matching when the market opens on the next trading day, until the order is manually cancelled.

[0115] For example, as shown in Figure 12, assuming the target transaction execution period includes intraday, pre-market, and after-market sessions (i.e., the transaction can be executed at any time during these sessions), if the target execution period is the night session (i.e., the target order is submitted during the night session), the target order can first be routed to the downstream brokerage server. Next, the order expiration date can be determined: if the order expiration date is the current day's validity period, the target order can be cached on the server and routed to the exchange server for matching via the clearinghouse when the market opens. If the matching fails by the close of trading, the order is automatically cancelled. If the order expiration date is the validity period before cancellation, the target order can be cached on the server and routed to the exchange server for matching via the clearinghouse when the market opens pre-market. If the matching fails by the close of trading, the order is automatically returned to the downstream server (e.g., the downstream brokerage server) for caching, and routed to the exchange server again for matching when the market opens pre-market on the next trading day, until the target order is manually cancelled.

[0116] For example, as shown in Figure 13, assuming the target trade can be executed at any time during the trading session (i.e., during intraday, pre-market, after-market, and night trading sessions), and the order validity period is limited to the current day, with the first exchange being exchanges such as NYSE and NASDAQ, and the second exchange being exchanges such as BOATS; the client can first send the trading operation corresponding to the target order to the downstream server; if the trading operation is sent to the downstream server during a non-night trading session, that is, the target order is submitted during a non-night trading session (meaning the actual execution time of the target order is a non-night trading session), then... The target order can be routed to the first exchange server for matching. If the matching fails by the close of the trading day, it is returned to the downstream server for caching. Then, at the opening of the night session, it can be automatically routed to the second exchange server for matching. If the matching fails by the close of the night session, the order is automatically cancelled. If the trading operation is sent to the downstream server during the night session, that is, the target order is submitted during the night session (meaning the actual execution time of the target is during the night session), the client can directly route the target order to the second exchange server for matching. If the matching fails by the close of the night session, the order is automatically cancelled.

[0117] Alternatively, as shown in Figure 14, assuming the target transaction execution period is all-day and the order period is the validity period before cancellation; if the target execution period of the transaction operation is outside the night trading session, that is, if the target order is submitted outside the night trading session, the target order can first be routed to the first exchange server for matching. If it is still not matched successfully by the close of the trading day, it is returned to the downstream server for caching. Then, when the night trading session opens, it can be automatically routed to the second exchange server for matching. If it is still not matched successfully by the close of the night trading session, it can be returned to the downstream server for caching again. After that, it can be routed to the first exchange server for matching when the pre-market session opens on the next trading day. After that, the above order routing path can be repeated until the target order is manually cancelled. If the target execution period for the trading operation is the night trading session (i.e., the target order is submitted during the night trading session), the target order can first be directly routed to the second exchange server for matching. If the matching is unsuccessful by the close of the night trading session, it is returned to the downstream server for caching. Then, when the pre-market session opens, it can be automatically routed to the first exchange server for matching. After that, if the matching is still unsuccessful by the close of the after-market session, it can again be returned to the downstream server for caching. When the night trading session opens, it can be routed to the second exchange server for matching. This order routing process can then be repeated until the target order is manually cancelled.

[0118] Through the above embodiments, quantitative trading can be realized with all-weather market data acquisition and live trading, satisfying the requirements of interconnected quantitative trading solutions across multiple time periods and trading venues. It can also simultaneously take into account the liquidity, timeliness, and trading continuity of quantitative trading, improve the quality of trading transactions, and ensure the reliable and reasonable operation of quantitative trading.

[0119] It should be noted that all the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0120] It should be noted that in the specific implementation of this application, various time periods such as set time periods and actual time periods, as well as related data such as market data and order deadlines are involved. When the embodiments of this application are applied to specific products or technologies, user permission, consent or authorization is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0121] Figure 15 is a schematic diagram of a data processing device 1500 for quantitative trading provided in an embodiment of this application. As shown in Figure 15, the device 1500 includes: a first acquisition module 1501, a first determination module 1502, a second acquisition module 1503, a transaction execution module 1504, a third acquisition module 1505, a market data retrieval module 1506, a first storage module 1507, a fourth acquisition module 1508, and a second storage module 1509.

[0122] In one embodiment, the first acquisition module 1501 is used to acquire, in response to the operation of the quantitative trading strategy, the market setting time period indicated by the preset strategy conditions in the quantitative trading strategy, and the target actual running time of the quantitative trading strategy.

[0123] The first determining module 1502 is used to determine the target market time period based on the market time setting and the target actual running time period;

[0124] The second acquisition module 1503 is used to acquire the target market data of the trading object in the quantitative trading strategy during the target market period, and to acquire the indicator value of the market indicator based on the target market data.

[0125] The execution trading module 1504 is used to trigger the execution of the trading operation indicated by the preset strategy operation in the quantitative trading strategy in response to the indicator value of the market indicator meeting the preset strategy conditions of the quantitative trading strategy.

[0126] In one embodiment, the market data setting period includes any one of the following: a first market data setting period, a second market data setting period, and a third market data setting period, wherein the first market data setting period includes intraday trading hours, the second market data setting period includes intraday trading hours, pre-market trading hours, and post-market trading hours, and the third market data setting period includes intraday trading hours, pre-market trading hours, post-market trading hours, and night trading hours;

[0127] The first determining module 1502 is specifically used for:

[0128] Obtain the first mapping relationship between the set market data period, the actual running period, and the market data period;

[0129] The target market time period is determined based on the market data setting time period and the target actual running time period, using the first mapping relationship.

[0130] In one embodiment, the third acquisition module 1505 is used to acquire the amount of market data required for calculating market data indicators.

[0131] The market data retrieval module 1506 is used to retrieve a certain number of market data points from the backend service.

[0132] The first storage module 1507 is used to store the market data into the sub-caching unit corresponding to the cache unit according to the number of market data and the time period involved in the market data.

[0133] The fourth acquisition module 1508 is used to acquire market data pushed by the backend service during a specific market period. The specific market period includes any one of the following: intraday period, pre-market period, post-market period, and night session period.

[0134] The second storage module 1509 is used to store market data for a specific market period into the sub-caching unit corresponding to the cache unit according to the time period involved in the specific market period, and update the historical market data stored in the cache unit so that the number of market data stored in the cache unit is the number of market data.

[0135] The cache unit includes: a first sub-cache unit, a second sub-cache unit, and a third sub-cache unit;

[0136] The first sub-cacher unit is used to store market data for different time periods during trading hours;

[0137] The second sub-cacher unit is used to store market data for intraday, pre-market, and post-market periods.

[0138] The third sub-cacher unit is used to store market data for intraday, pre-market, after-market, and night trading sessions.

[0139] The second acquisition module 1503 is specifically used for:

[0140] Retrieve target market data for the target market period from the cache unit.

[0141] In one embodiment, the transaction execution module 1504 is specifically used for:

[0142] Obtain the trading time period set by the preset strategy operation in the quantitative trading strategy, as well as the target actual execution time period of the trading operation;

[0143] Determine the target transaction execution period based on the transaction's set time period and the target's actual execution time period;

[0144] Construct the target order and submit it to the exchange server corresponding to the target transaction execution period.

[0145] In one embodiment, the trading session includes any one of the following: a first trading session, a second trading session, a third trading session, and a fourth trading session, wherein the first trading session includes an intraday session, the second trading session includes an intraday session, a pre-market session, and an after-market session, the third trading session includes an intraday session, a pre-market session, an after-market session, and an evening session, and the fourth trading session includes an evening session.

[0146] Execution Transaction Module 1504 is specifically used for:

[0147] Obtain the second mapping relationship between the transaction's set time period, the actual execution time period, and the transaction execution time period;

[0148] The target transaction execution period is determined based on the transaction's set time period and the target's actual execution time period, using a second mapping relationship.

[0149] In one embodiment, the transaction execution module 1504 is specifically used for:

[0150] The target order is submitted to the downstream brokerage server through the client-side order interface;

[0151] The target orders are processed through the downstream brokerage servers, and the processed target orders are then routed to the clearinghouse.

[0152] The clearinghouse verifies the processed target orders and routes them to the exchange server corresponding to the target transaction execution period for trading.

[0153] In one embodiment, the transaction execution module 1504 is specifically used for:

[0154] The order deadline for obtaining the target order;

[0155] In response to the order's validity period being valid for the day, the target order is cached through the downstream brokerage server. In response to the arrival of the target transaction execution period, the target order is routed to the corresponding exchange server for trading. If the transaction is not successfully completed by the end of the target transaction execution period, the target order is cancelled.

[0156] In response to the order's expiration date being the validity period before cancellation, the target order is cached through the downstream brokerage server. In response to the arrival of the target transaction execution period, the target order is routed to the corresponding exchange server for trading. If the transaction is not successfully completed by the end of the target transaction execution period, the target order is routed to the corresponding exchange server for trading in response to the arrival of the target transaction execution period on the next trading day, until the target user's cancellation operation for the target order is obtained.

[0157] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, they will not be repeated here. Specifically, the device 1500 shown in FIG15 can execute the above method embodiments, and the foregoing and other operations and / or functions of each module in the device 1500 are respectively for implementing the corresponding processes in the above methods. For the sake of brevity, they will not be repeated here.

[0158] The apparatus 1500 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0159] Figure 16 is a schematic diagram of an electronic device 1600 provided in an embodiment of this application.

[0160] As shown in Figure 16, the electronic device 1600 may include:

[0161] The system includes a memory 1610 and a processor 1620. The memory 1610 stores computer programs and transfers the program code to the processor 1620. In other words, the processor 1620 can retrieve and run the computer program from the memory 1610 to implement the methods described in the embodiments of this application.

[0162] For example, the processor 1620 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0163] In some embodiments of this application, the processor 1620 may include, but is not limited to:

[0164] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0165] In some embodiments of this application, the memory 1610 includes, but is not limited to:

[0166] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0167] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 1610 and executed by the processor 1620 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0168] As shown in Figure 16, the electronic device may further include:

[0169] Transceiver 1630, which can be connected to processor 1620 or memory 1610.

[0170] The processor 1620 can control the transceiver 1630 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 1630 may include a transmitter and a receiver. The transceiver 1630 may further include antennas, and the number of antennas may be one or more.

[0171] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0172] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0173] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, the computer can perform all or part of the corresponding processes in the methods of the embodiments of this application, producing the functions achievable by the methods of the embodiments of this application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0174] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0175] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0176] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

Claims

1. A data processing method for quantitative trading, characterized in that, include: In response to the operation of the quantitative trading strategy, the market setting time period indicated by the preset strategy conditions in the quantitative trading strategy, and the target actual running time of the quantitative trading strategy are obtained. The target market time period is determined based on the market data setting time period and the target actual operating time period; Obtain the target market data of the trading object in the quantitative trading strategy during the target market period, and obtain the indicator value of the market indicator based on the target market data; In response to the market indicator value satisfying the preset strategy conditions of the quantitative trading strategy, the trading operation indicated by the preset strategy operation in the quantitative trading strategy is triggered.

2. The method according to claim 1, characterized in that, The market data setting time period includes any one of the following: a first market data setting time period, a second market data setting time period, and a third market data setting time period. The first market data setting time period includes intraday trading hours, the second market data setting time period includes intraday trading hours, pre-market trading hours, and post-market trading hours, and the third market data setting time period includes intraday trading hours, pre-market trading hours, post-market trading hours, and night trading hours. Determining the target market time period based on the market data set time period and the target actual operating time period includes: Obtain the first mapping relationship between the market data setting time period, the actual running time period, and the market data time period; The target market time period is determined based on the first mapping relationship, according to the market data setting time period and the target actual running time period.

3. The method according to claim 1, characterized in that, Before obtaining the target market data for the target market period, the method further includes: Obtain the quantity of market data required to calculate the market index; Retrieve the specified number of market data points from the backend service; Based on the time period involved in the number of market data points, the number of market data points are stored in the sub-caching unit corresponding to the caching unit; Obtain market data pushed by the background service during a specific market period, wherein the specific market period includes any one of the following: intraday session, pre-market session, post-market session, and night session; Based on the time period involved in the specific market data period, the market data under the specific market data period is stored in the sub-cached unit corresponding to the cache unit, and the historical market data stored in the cache unit is updated so that the number of market data stored in the cache unit is the number of market data. The cache unit includes: a first sub-cache unit, a second sub-cache unit, and a third sub-cache unit; The first sub-cacher unit is used to store market data for different time periods during trading hours; The second sub-caching unit is used to store market data for intraday, pre-market, and after-market periods; The third sub-caching unit is used to store market data for intraday, pre-market, post-market, and nighttime trading sessions. The acquisition of target market data for the target market period includes: The target market data for the target market period is obtained from the cache unit.

4. The method according to any one of claims 1-3, characterized in that, The execution of the trading operation indicated by the preset strategy operation in the quantitative trading strategy includes: Obtain the trading time period of the preset strategy operation in the quantitative trading strategy, and the target actual execution time period of the trading operation; The target transaction execution period is determined based on the transaction's set time period and the target's actual execution time period; Construct a target order and submit the target order to the exchange server corresponding to the target transaction execution period.

5. The method according to claim 4, characterized in that, The trading time period includes any one of the following: a first trading time period, a second trading time period, a third trading time period, and a fourth trading time period, wherein the first trading time period includes intraday trading hours, the second trading time period includes intraday trading hours, pre-market trading hours, and after-market trading hours, the third trading time period includes intraday trading hours, pre-market trading hours, after-market trading hours, and night trading hours, and the fourth trading time period includes night trading hours. Determining the target transaction execution period based on the transaction-defined time period and the target actual execution period includes: Obtain the second mapping relationship between the transaction set time period, the actual execution time period, and the transaction execution time period; The target transaction execution period is determined based on the second mapping relationship, according to the transaction set time period and the target actual execution time period.

6. The method according to claim 4, characterized in that, Submitting the target order to the exchange server corresponding to the target transaction execution period includes: The target order is submitted to the downstream brokerage server via the client-side order interface; The downstream brokerage server processes the target order and routes the processed target order to the clearinghouse. The clearinghouse verifies the processed target order and routes the verified target order to the exchange server corresponding to the target transaction execution period for trading.

7. The method according to claim 4, characterized in that, Submitting the target order to the exchange server corresponding to the target transaction execution period includes: Obtain the order duration of the target order; In response to the order's validity period being valid for the current day, the target order is cached through the downstream brokerage server. In response to the arrival of the target transaction execution period, the target order is routed to the corresponding exchange server for trading. If the transaction is not successfully completed by the end of the target transaction execution period, the target order is cancelled. In response to the order period being the validity period before cancellation, the target order is cached through the downstream brokerage server. In response to the arrival of the target transaction execution period, the target order is routed to the corresponding exchange server for trading. If the transaction is not successfully completed by the end of the target transaction execution period, in response to the arrival of the target transaction execution period on the next trading day, the target order is routed to the corresponding exchange server for trading until a cancellation operation is obtained from the target user for the target order.

8. A data processing device for quantitative trading, characterized in that, include: The first acquisition module is used to respond to the operation of the quantitative trading strategy by acquiring the market setting time period indicated by the preset strategy conditions in the quantitative trading strategy, and the target actual running time of the quantitative trading strategy. The first determining module is used to determine the target market time period based on the market data set time period and the target actual running time period; The second acquisition module is used to acquire the target market data of the trading object in the quantitative trading strategy during the target market period, and to acquire the indicator value of the market indicator based on the target market data. The execution trading module is used to trigger the execution of the trading operation indicated by the preset strategy operation in the quantitative trading strategy in response to the indicator value of the market indicator meeting the preset strategy conditions of the quantitative trading strategy.

9. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the method of any one of claims 1-7 by executing the executable instructions.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1-7.

Images