Fund transaction simulation method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a fund transaction simulation method and device, equipment and a storage medium, and specifically discloses the steps that a simulation fund account and fund entrustment for the simulation fund account are created; starting transaction calculation for the fund entrustment at regular time on the next transaction day of creating the fund entrustment; wherein the transaction calculation comprises the steps of obtaining fund market data corresponding to the fund type, performing transaction calculation on the fund market data according to a preset transaction rule corresponding to the fund type, generating a transaction parameter, performing parameter verification on the transaction parameter, and when the transaction parameter is found to be abnormal through verification, performing transaction calculation on the fund market data. Marking the fund entrustment corresponding to the transaction parameter as a to-be-recalculated state; performing recalculation processing on the fund entrustment marked as the to-be-recalculated state; and according to the transaction parameters passing the parameter verification, asset information of the simulated fund account is updated, and the updated asset information is output as a simulated transaction result.

Description

Technical Field

[0001] This invention relates to the field of computer simulation technology, and in particular to a fund trading simulation method, apparatus, device, and storage medium. Background Technology

[0002] Fund simulation trading generally refers to conducting fund trading operations in a fund trading simulation system, based on real fund market data and trading rules. Existing fund simulation trading systems are mainly aimed at C-end users, implementing basic trading functions, such as accessing market data and setting trading rules to complete simulated fund buying and selling operations, or building an account system to manage funds, display holdings, and calculate cumulative returns.

[0003] However, this type of C-end-oriented design has the following technical limitations: First, the transaction orders generated by the system are all processed in one go, and the data cannot be traced back and recalculated after the transaction is completed, making it difficult to verify the accuracy of the data; Second, the system functions are out of touch with the professional needs of researchers, and it is impossible to quantify the order execution process with multi-dimensional indicators, lacking effective indicator assessment. Summary of the Invention

[0004] The main objective of this invention is to provide a fund trading simulation method, apparatus, device, and storage medium, which aims to solve the problems of existing fund trading simulation systems, such as difficulty in verifying data accuracy, lack of transaction backtracking and recalculation capabilities, and inability to effectively quantify researcher performance indicators, due to their C-end-oriented design and single analysis dimensions.

[0005] In a first aspect, embodiments of this disclosure provide a fund trading simulation method, including: Create a demo account and place fund orders for the demo account; wherein the fund orders include the fund type of the target fund to be traded; the fund type includes exchange-traded funds and off-exchange funds; On the next trading day after the creation of the fund order, a transaction calculation for the fund order is initiated periodically. This transaction calculation involves acquiring fund market data corresponding to the fund type, performing transaction calculations on the fund market data according to preset trading rules corresponding to the fund type, generating transaction parameters, and validating the transaction parameters. If the transaction parameters are found to be abnormal, the fund order corresponding to the transaction parameters is marked as pending recalculation. The fund market data includes market data files used for matching funds traded on the exchange and net asset value (NAV) data used for subscriptions and redemptions of funds traded off the exchange. Recalculation processing is performed on fund orders marked as pending recalculation; wherein, the recalculation processing involves reacquiring the fund market data and re-performing the transaction calculation at regular intervals until the transaction parameters pass the parameter verification. Based on the transaction parameters verified by the parameters, the asset information of the simulated fund account is updated, and the updated asset information is output as the simulated transaction result.

[0006] Secondly, embodiments of this disclosure provide a fund trading simulation device, comprising: A creation module is used to create a demo account and fund orders for the demo account; wherein, the fund order includes the fund type of the target fund for the transaction; the fund type includes exchange-traded funds and off-exchange funds; The calculation module is used to periodically initiate transaction calculation for the fund order on the next trading day after the fund order is created. The transaction calculation involves obtaining fund market data corresponding to the fund type, performing transaction calculations on the fund market data according to preset trading rules corresponding to the fund type, generating transaction parameters, and verifying the transaction parameters. If the verification finds abnormal transaction parameters, the fund order corresponding to the transaction parameters is marked as pending recalculation. The fund market data includes market data files used for on-exchange fund matching and fund net asset values ​​used for off-exchange fund subscriptions and redemptions. The recalculation module is used to perform recalculation processing on fund orders marked as being in the recalculation state; wherein, the recalculation processing involves re-acquiring the fund market data and re-performing the transaction calculation at regular intervals until the transaction parameters pass the parameter verification. The update module is used to update the asset information of the simulated fund account based on the transaction parameters that have passed the parameter verification, and output the updated asset information as the simulated transaction result.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the steps of the method described in the first aspect above.

[0008] Fourthly, embodiments of this disclosure provide a computer-readable storage medium for storing computer-executable instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0009] Fifthly, embodiments of this disclosure provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the steps of the method described in the first aspect above.

[0010] The at least one technical solution provided by the embodiments of the present invention can achieve the following technical effects: In this embodiment of the invention, a closed-loop control of data accuracy is achieved by introducing parameter verification and recalculation mechanisms. T+1 timed calculations ensure the timeliness of the trading simulation. When the verification process detects anomalies in the transaction parameters, the corresponding fund order is automatically marked as pending recalculation based on the anomaly determination result. This triggers the recalculation process, re-acquiring data and recalculating the abnormal order until its transaction parameters pass all verifications. This embodiment transforms the traditional one-time, static, and unrecoverable simulated trading data processing mode into a precise calculation process with cyclical verification and dynamic compensation, effectively solving the problem of distorted and unverifiable simulation results caused by abnormal data sources or calculation errors. Furthermore, this embodiment significantly improves the reliability, auditability, and process controllability of simulated trading data, fundamentally ensuring that the output results meet the needs of professional researchers for data accuracy and quantitative analysis. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is one of the flowcharts illustrating a fund trading simulation method provided in an embodiment of the present invention; Figure 2 This is a second schematic flowchart of a fund trading simulation method provided in one embodiment of the present invention; Figure 3 A schematic diagram of the module composition of a fund trading simulation device 300 provided in one embodiment of the present invention; Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] The technical solutions provided by the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0014] Please see Figure 1 , Figure 1 This is one of the flowcharts illustrating a fund trading simulation method provided in an embodiment of the present invention, such as... Figure 1As shown, the method includes the following steps: Step 102: Create a demo account and fund orders for the demo account; the fund order includes the type of the target fund to be traded; the fund type includes exchange-traded funds and off-exchange funds.

[0015] Step 104: On the next trading day after the creation of the fund order, the transaction calculation for the fund order is started at regular intervals. The transaction calculation involves obtaining the fund market data corresponding to the fund type, performing transaction calculations on the fund market data according to the preset trading rules corresponding to the fund type, generating transaction parameters, and verifying the transaction parameters. If the verification finds abnormal transaction parameters, the fund order corresponding to the transaction parameters is marked as pending recalculation. The fund market data includes market data files used for on-exchange fund matching and fund net asset values ​​used for off-exchange fund subscriptions and redemptions.

[0016] Step 106: Perform recalculation processing on fund orders marked as pending recalculation; wherein, the recalculation processing involves re-acquiring fund market data and re-performing transaction calculations at regular intervals until the transaction parameters pass parameter verification.

[0017] Step 108: Based on the transaction parameters that have passed the parameter verification, update the asset information of the simulated capital account and output the updated asset information as the simulated transaction result.

[0018] In one embodiment of the invention, a simulated fund account and fund entrustment for the simulated fund account can be created.

[0019] The simulated fund account can be a fund of funds (FOF) portfolio. When creating a simulated fund account, researchers can input information such as portfolio name, initial capital, investment objectives, and creator through the client interface. Based on this information, a record can be created in the preset simulated portfolio fund table, and a globally unique fund_id will be generated as the core identifier of the FOF portfolio.

[0020] In one example, a pre-defined simulated portfolio table can be used to store a snapshot of the current assets of each simulated portfolio account, and its key fields are shown in Table 1: Table 1

[0021] After creating a demo account, researchers can create fund orders for that account. When creating a fund order, the target fund, trading direction (e.g., buy or sell), and order size (i.e., the planned trading unit) must be specified. Crucially, the fund type of the target fund must be explicitly specified. In this embodiment, fund types can be strictly distinguished into exchange-traded funds and off-exchange funds for differentiated processing based on fund type. After creating a fund order, a unique `commission_id` can be generated for each order, and its state can be initialized.

[0022] In one example, an order table can be used to record the details of each transaction order, and its key fields can be shown in Table 2: Table 2

[0023] In one embodiment of the present invention, after creating a simulated fund account and a fund order, the transaction calculation for the fund order can be initiated periodically on the next trading day following the creation of the fund order. The transaction calculation can involve obtaining fund market data corresponding to the fund type, performing transaction calculations on the fund market data according to preset trading rules corresponding to the fund type, generating transaction parameters, and validating the transaction parameters. If the validation detects abnormal transaction parameters, the fund order corresponding to the transaction parameters is marked as pending recalculation. In this embodiment of the present invention, the fund market data may include market data files used for on-exchange fund matching and fund net asset values ​​used for off-exchange fund subscriptions and redemptions.

[0024] In this embodiment of the invention, in order to ensure the realism of the transaction simulation, a T+1 mode can be adopted. That is, the fund order created by the researcher on day T is not executed immediately, but is triggered in batches on day T+1 by a background timed task, for example, at 1:00 am every day, to simulate the settlement cycle of "orders placed on the same day, shares confirmed on the next trading day" in real fund transactions.

[0025] After the scheduled task starts, all orders with a status of '0' (not started) or '5' (abnormal and awaiting recalculation) can be filtered out and proceed to the core transaction calculation stage. The core of this stage is to obtain fund market data according to the fund type, using the path corresponding to the fund type, and apply the corresponding preset trading rules for calculation.

[0026] In one embodiment, when calculating a transaction, the fund type in the fund order can be obtained first. If the fund type is an exchange-traded fund (ETF), the market data file used for ETF matching can be obtained. This file is usually provided by an external data service provider and contains minute-level snapshots of all ETFs in the entire market during the trading hours of day T, generally including fields such as timestamp, latest price, and trading volume. All minute-level data for the target fund on day T can be located from this file. Subsequently, the VWAP (Volume Weighted Average Price) rule is applied for calculation. The VWAP rule calculates the average price by weighting the fund price and corresponding trading volume for each minute within a preset time period, resulting in an average price that reflects the true transaction cost within that preset time period. Specifically, the price for each minute during the trading hours of day T can be multiplied by the corresponding minute's trading volume to obtain the transaction amount for that minute. The transaction amounts for all minutes on day T are then summed and divided by the total trading volume on day T to obtain the fund's VWAP average price for day T. This average price more realistically simulates the average transaction cost of large orders in the real market. Finally, multiply the average transaction price by the number of units in the order to obtain the transaction amount. The number of units in the order represents the planned number of units of the target fund to be traded, as set when the fund order was created. After calculating the average transaction price, transaction amount, and the actual number of units traded (usually the number of units in the order), these data can be saved as transaction parameters.

[0027] When the fund type is an off-exchange fund, you can obtain the net asset value (NAV) of the target fund for off-exchange fund subscriptions and redemptions on the trading day. This NAV is a unique price calculated and published by the fund company after the market closes on day T. The unit NAV of the target fund on day T can be obtained through an interface or file. The trading rules for off-exchange funds are relatively simple; this NAV can be used as the transaction price. The transaction amount can be the fund NAV multiplied by the number of shares entrusted. Then, the transaction price, transaction amount, and transaction shares can be determined as the transaction parameters.

[0028] After obtaining the above transaction parameters, these parameters can be validated to ensure the reliability of the input data and the reasonableness of the calculation results. If the validation fails, the calculation results will not be accepted.

[0029] In one embodiment, when validating transaction parameters, the validity of the transaction parameters can be verified first.

[0030] Specifically, for exchange-traded funds (ETFs), the validity of the market data file used for matching ETF transactions can be checked. Validity checks can include: file existence, correct parsing, and whether it contains data for the target fund on day T. If any of these checks fail, the transaction parameters for the order are deemed invalid, and the parameter verification result is an abnormal transaction parameter.

[0031] For off-exchange funds, the validity of the fund net asset value (NAV) used for off-exchange fund subscriptions and redemptions in the fund market data can be checked. This check can include: whether the NAV data was successfully acquired, whether the NAV is a valid positive number, and whether the NAV date matches day T. If the check result is invalid, the parameter validation result will be judged as abnormal transaction parameters.

[0032] In another embodiment, after the validity check passes, the transaction parameters can be further validated for reasonableness to perform logical verification on the calculation result itself. Reasonableness verification includes: verifying whether the transaction amount is non-negative; verifying whether the average transaction price is within a preset reasonable price range; and verifying whether the logical relationship between the transaction shares and the entrusted shares conforms to preset rules. The entrusted shares are the number of units of the target fund to be traded, set when the fund order is created.

[0033] In this embodiment, it can be checked whether the calculated transaction amount is non-negative. A negative transaction amount is illogical in buying and selling. It can also be checked whether the average transaction price is within a preset reasonable price range. For example, the range can be set to [0.01, 100.00] (yuan) to exclude extreme prices (such as 0.001 yuan or 1000.00 yuan) caused by data errors. Furthermore, it can be checked whether the logical relationship between the transaction volume and the order volume conforms to preset rules. For example, for ordinary buying and selling, the transaction volume should not be greater than the order volume; for sell orders, the transaction volume cannot exceed the account's current available holdings in that fund.

[0034] If any of the above-mentioned reasonableness verifications fails, the parameter verification result can be determined to be abnormal transaction parameters. In this case, the fund order corresponding to the transaction parameters can be marked as pending recalculation.

[0035] In one embodiment of the present invention, after parameter verification is completed, data cleaning and status management operations can be performed on the transaction parameters. This process can be implemented through a status rotation mechanism, that is, the status field in the order table can be dynamically updated according to the verification results. Specifically, if the parameter verification passes, that is, both the above validity check and reasonableness verification are successful, the order status can be marked as "data normal"; if any verification fails, the status can be marked as "data abnormal". In this embodiment of the present invention, data abnormality can include, but is not limited to, the following categories: market data file does not exist, fund net asset value does not exist, R007 (i.e., seven-day repurchase rate) data does not exist, etc. This clear division based on different status marks provides a clear identification basis for subsequent abnormal data processing and data recalculation. These abnormal orders can be automatically classified into the recalculation queue for convenient batch recalculation processing.

[0036] In one embodiment of the present invention, a dedicated recalculation process can be executed for fund orders marked as pending recalculation. This recalculation process involves reacquiring fund market data and periodically re-calculating transactions until the transaction parameters pass parameter verification. The core of this recalculation process lies in precise backtracking based on historical data snapshots, which can be achieved through holdings and asset statements.

[0037] In one example, as shown in Table 3, the holdings log can record the detailed holdings of each simulated fund account on a daily basis. Its key fields may include at least one of the following: fund code, number of shares held, cost, and market value of various funds.

[0038] Table 3

[0039] In one example, as shown in Table 4, the asset flow statement can record the overall asset profile of each portfolio on a daily basis, including at least one of the following: total assets in the simulated fund account, cash, and market value of holdings.

[0040] Table 4

[0041] When recalculating a fund order that is in a pending recalculation state, the original order date can be obtained first, i.e., the pre-set date for transaction calculation. Then, based on the original order date (T+1 day when the transaction should have been executed), historical snapshot data of the original order date can be obtained from the holdings and assets statements to accurately restore the account status before the order was executed. Based on this, fund market data can be re-acquired, and the transaction calculation and parameter verification processes can be re-executed.

[0042] To ensure a high recalculation success rate, a multi-tiered retry mechanism can be introduced. First, for dependent external data interfaces, such as market data sources and net asset value (NAV) publishing platforms, multiple polling attempts can be performed. If the polling fails after a preset number of attempts (e.g., 3), an alarm mechanism can be automatically triggered, notifying the corresponding administrator via email, SMS, etc., for manual intervention. The administrator can manually supplement missing data or investigate data source issues before re-triggering the recalculation process to maximize data integrity and eventual consistency.

[0043] In one embodiment of the present invention, after the transaction parameters pass parameter verification, the asset information of the simulated fund account can be updated according to the transaction parameters, and the updated asset information can be output as the simulated transaction result.

[0044] In one embodiment, after completing daily simulated trading, a rebalancing point simulation analysis can be performed to provide researchers with quantitative performance indicators. Specifically, researchers can arbitrarily specify a past date as the rebalancing date on the front-end interface. After determining the rebalancing date, analysis can be performed based on long-term accumulated asset flow data. First, the first net asset value (NAV) trend can be calculated. This first NAV trend represents the NAV movement from a certain starting point, such as the portfolio's inception date, to the rebalancing date, assuming no rebalancing operations were performed before the rebalancing date, with the portfolio maintaining its original holdings. Then, the second NAV trend can be calculated, simulating the NAV movement from the rebalancing date to the current date, based on newly executed fund orders—that is, the new holdings constructed after the rebalancing operation by the analyst. After calculating the first and second NAV trends, two NAV curves and their key indicators, such as cumulative return, annualized volatility, and maximum drawdown, can be generated and compared. The comparison results can then be output to the analyst, providing intuitive and powerful data support for their quantitative evaluation of the merits of the corresponding rebalancing decisions.

[0045] In one example, the portfolio rebalancing details table can be shown as shown in Table 5: Table 5

[0046] The rebalancing details table shown in Table 5 can accurately track the specific fund orders, transaction times, and key parameters associated with each rebalancing action. The precise mapping between orders and rebalancing times established through this table effectively supports rebalancing point analysis, enabling quantitative comparisons and strategy attribution analysis of investment performance before and after each rebalancing operation.

[0047] In one embodiment of the present invention, to further improve calculation accuracy, a calculation back-calculation logic is introduced. Specifically, the calculation back-calculation logic is implemented as follows: the fund order information in the FOF simulated portfolio is synchronized to another independent trading system, and the same original data (such as market data files, fund net asset values, etc.) is used in parallel to perform simulated calculations within this independent trading system. After the calculation is completed, the calculation results from the other independent trading system can be synchronized back to the FOF system, compared with the current calculation results on a transaction-by-transaction basis, and the difference between the two results is calculated. When the difference exceeds a preset threshold, such as 0.001, a data accuracy alarm can be automatically triggered, indicating a possible problem with the calculation logic or data source inconsistency, facilitating timely manual investigation and intervention by technical personnel.

[0048] Additionally, it can integrate BI (Business Intelligence Reporting) reporting functionality to visualize simulated trading results. BI reports can present multi-dimensional analytical charts including portfolio net asset value curves, holding distribution, and performance attribution, and specifically highlight data points with discrepancies identified through reverse logical comparison, thus providing researchers with comprehensive decision support.

[0049] In one example, such as Figure 2 The diagram shows an overall flowchart of a fund trading simulation in an embodiment of the present invention: First, a demo account and fund orders can be created. Researchers can start by creating a demo FOF portfolio (i.e., a demo account) and generating a globally unique fund_id as the core identifier for that FOF portfolio. Then, researchers can create fund orders for this account, specifying the target fund's code, trading direction, order size, and, crucially, the fund type (i.e., on-exchange or off-exchange). A unique identifier, commission_id, is generated for each order, and its status is initialized (e.g., "Not Started"), laying the foundation for subsequent status-driven processes.

[0050] Then, the transaction calculation can be initiated on a T+1 schedule. The calculation is started via a scheduled task on the next trading day (T+1) after the order creation date (T) to ensure the simulation pace is synchronized with the real market. Next, differentiated transaction calculations can be performed. Different rules are used to acquire market data and perform calculations based on the type of fund in the order, achieving refined simulation: for exchange-traded funds, minute-level data is extracted from market data files and calculated according to VWAP rules; for off-exchange funds, the fund's net asset value (NAV) for the day is used directly for calculation, generating key transaction parameters such as average transaction price and transaction amount. After the transaction calculation is executed, multi-level parameter validation can be performed to rigorously validate the transaction parameters. This includes checking the existence of valid basic data, such as market data files and fund NAVs ("existence check"), and performing "logic validation" on the calculation results themselves, such as the positive or negative value of the amount and the reasonableness of the price. The validation results directly drive the state rotation: if successful, the order status is marked as "normal" and proceeds to the asset update step; if an anomaly is found, such as missing data or logical errors, the status is immediately marked as "abnormal," triggering the anomaly handling process.

[0051] For orders marked as abnormal, a recalculation process based on historical snapshots and third-party data compensation can be initiated. This process is not a simple recalculation, but rather a precise backtracking to the original transaction day of the order, i.e., T+1 day, to restore the asset and position context at that time by querying the position and asset transaction records. Based on the correct historical snapshot, requests can be re-sent to the third-party data source to obtain previously missing or erroneous data, and a polling strategy can be used for multiple retries. If the polling fails after exceeding a fixed number of times, an alarm can be automatically triggered, switching to manual intervention mode. After successful data compensation, the transaction calculation and verification can be re-executed, forming a closed loop, until the parameter verification passes or the set maximum number of retries is reached.

[0052] Finally, for valid orders, the system can simulate the asset information of the funding account and output the results. Furthermore, the process supports advanced analytics features, such as rebalancing point analysis, allowing researchers to evaluate the effectiveness of rebalancing at specific points in time, thus providing in-depth strategy review value for the entire simulated trading process.

[0053] In this embodiment of the invention, a closed-loop control of data accuracy is achieved by introducing parameter verification and recalculation mechanisms. T+1 timed calculations ensure the timeliness of the trading simulation. When the verification process detects anomalies in the transaction parameters, the corresponding fund order is automatically marked as pending recalculation based on the anomaly determination result. This triggers the recalculation process, re-acquiring data and recalculating the abnormal order until its transaction parameters pass all verifications. This embodiment transforms the traditional one-time, static, and unrecoverable simulated trading data processing mode into a precise calculation process with cyclical verification and dynamic compensation, effectively solving the problem of distorted and unverifiable simulation results caused by abnormal data sources or calculation errors. Furthermore, this embodiment significantly improves the reliability, auditability, and process controllability of simulated trading data, fundamentally ensuring that the output results meet the needs of professional researchers for data accuracy and quantitative analysis.

[0054] Figure 3 The fund trading simulation device 300 shown can achieve Figure 1 The method described in the embodiment achieves the same technical effect, and can be specifically referred to in the above description. Figure 1 The description of the fund trading simulation in the illustrated embodiment will not be repeated here. The fund trading simulation device 300 includes: A creation module 301 is used to create a simulated fund account and fund orders for the simulated fund account; wherein, the fund order includes the fund type of the target fund for the transaction; the fund type includes exchange-traded funds and off-exchange funds; The calculation module 302 is used to periodically start the transaction calculation for the fund order on the next trading day after the fund order is created; wherein, the transaction calculation involves obtaining fund market data corresponding to the fund type, performing transaction calculation on the fund market data according to the preset trading rules corresponding to the fund type, generating transaction parameters, and verifying the transaction parameters. If the verification finds that the transaction parameters are abnormal, the fund order corresponding to the transaction parameters is marked as pending recalculation; the fund market data includes market data files used for matching funds on the exchange and fund net asset values ​​used for subscription and redemption of funds off the exchange. The recalculation module 303 is used to perform recalculation processing on fund orders marked as being in the recalculation state; wherein, the recalculation processing involves re-acquiring the fund market data and re-performing the transaction calculation at regular intervals until the transaction parameters pass the parameter verification. The update module 304 is used to update the asset information of the simulated fund account according to the transaction parameters verified by the parameters, and output the updated asset information as the simulated transaction result.

[0055] Optionally, the computing module 302 is used for: When the fund type is an exchange-traded fund, the price data of the target fund on the trading day is obtained from the market data file. A preset volume-weighted average price rule is used to calculate the average transaction price, and the transaction amount is determined based on the average transaction price and the number of units ordered. The volume-weighted average price rule involves calculating a weighted average of the fund price and corresponding transaction volume for each minute within a preset time period to obtain an average price that reflects the true transaction costs within the preset time period. The number of units ordered is the number of units of the target fund to be traded, set when the fund order is created. If the fund type is an off-exchange fund, the net asset value of the target fund on the trading day is obtained as the transaction price, and the transaction amount is determined based on the net asset value and the entrusted shares.

[0056] Optionally, the transaction parameters include at least one of the following: average transaction price, transaction amount, and transaction share; the calculation module 302 is used for: If the fund type is an exchange-traded fund, check whether the market data file used for matching exchange-traded funds is valid. If the check result is negative, determine that the parameter verification result is that the transaction parameters are abnormal. If the fund type is an off-exchange fund, check whether the net asset value of the fund used for the subscription and redemption of the off-exchange fund in the fund market data is valid, and if the check result is negative, determine that the parameter verification result is that the transaction parameter is abnormal.

[0057] Optionally, the computing module 302 is used for: If the parameter verification result indicates that the transaction parameters are normal, a reasonableness verification is performed on the transaction parameters. If the reasonableness verification fails, the parameter verification result is determined to be abnormal. The reasonableness verification includes: verifying whether the transaction amount is non-negative; verifying whether the average transaction price is within a preset reasonable price range; and verifying whether the logical relationship between the transaction shares and the entrusted shares conforms to preset rules. The entrusted shares are the number of units of the target fund to be traded, set when creating the fund entrustment.

[0058] Optionally, the recalculation module 303 is used for: Obtain a holdings statement and an asset statement; wherein, the holdings statement is used to record at least one of the following on a daily basis: fund code, holding shares, cost, and market value of various funds in the simulated fund account; the asset statement is used to record at least one of the following on a daily basis: total assets, cash, and market value of holdings in the simulated fund account; Based on the original order date of the fund order, obtain historical snapshot data of the original order date from the holdings statement and the asset statement, and re-execute the transaction calculation based on the historical snapshot data; wherein, the original order date is the date pre-set for the fund order to perform the transaction calculation.

[0059] Optionally, the device further includes ( Figure 3 (not shown in the image) Receiver module 305 is used to receive the rebalancing date specified by the user; The statistics module 306 is used to calculate, based on the asset information of the simulated fund account, the first net asset value trend of maintaining the original holdings before the rebalancing date, and the second net asset value trend generated based on the newly traded fund orders after the rebalancing date. The output module 307 is used to output the comparison results between the first net value trend and the second net value trend.

[0060] In this embodiment of the invention, a closed-loop control of data accuracy is achieved by introducing parameter verification and recalculation mechanisms. T+1 timed calculations ensure the timeliness of the trading simulation. When the verification process detects anomalies in the transaction parameters, the corresponding fund order is automatically marked as pending recalculation based on the anomaly determination result. This triggers the recalculation process, re-acquiring data and recalculating the abnormal order until its transaction parameters pass all verifications. This embodiment transforms the traditional one-time, static, and unrecoverable simulated trading data processing mode into a precise calculation process with cyclical verification and dynamic compensation, effectively solving the problem of distorted and unverifiable simulation results caused by abnormal data sources or calculation errors. Furthermore, this embodiment significantly improves the reliability, auditability, and process controllability of simulated trading data, fundamentally ensuring that the output results meet the needs of professional researchers for data accuracy and quantitative analysis.

[0061] Figure 4 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Please refer to it. Figure 4 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0062] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0063] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0064] The processor reads the corresponding computer program from non-volatile memory into main memory and then executes it, forming a non-contiguous transfer configuration at the logical level. The processor executes the program stored in memory and specifically performs the following operations: Create a demo account and place fund orders for the demo account; wherein the fund orders include the fund type of the target fund to be traded; the fund type includes exchange-traded funds and off-exchange funds; On the next trading day after the creation of the fund order, a transaction calculation for the fund order is initiated periodically. This transaction calculation involves acquiring fund market data corresponding to the fund type, performing transaction calculations on the fund market data according to preset trading rules corresponding to the fund type, generating transaction parameters, and validating the transaction parameters. If the transaction parameters are found to be abnormal, the fund order corresponding to the transaction parameters is marked as pending recalculation. The fund market data includes market data files used for matching funds traded on the exchange and net asset value (NAV) data used for subscriptions and redemptions of funds traded off the exchange. Recalculation processing is performed on fund orders marked as pending recalculation; wherein, the recalculation processing involves reacquiring the fund market data and re-performing the transaction calculation at regular intervals until the transaction parameters pass the parameter verification. Based on the transaction parameters verified by the parameters, the asset information of the simulated fund account is updated, and the updated asset information is output as the simulated transaction result.

[0065] The above is as stated in this application. Figure 1The fund trading simulation method disclosed in the embodiments described above can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in one or more embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in one or more embodiments of this application can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0066] The electronic device can also perform Figure 1 The fund trading simulation method described herein will not be elaborated upon here.

[0067] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform... Figure 1 The methods of the embodiments shown are not described in detail here.

[0068] This application also proposes a computer program product, which is stored in a storage medium and executed by at least one processor to implement... Figure 1 The methods of the embodiments shown are not described in detail here.

[0069] Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0070] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this application should be included within the scope of protection of one or more embodiments of this application.

[0071] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0072] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined in the embodiments of this application, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0073] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0074] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

Claims

1. A fund trading simulation method, characterized in that, include: Create a demo account and place fund orders for the demo account; wherein the fund orders include the fund type of the target fund to be traded; the fund type includes exchange-traded funds and off-exchange funds; On the next trading day after the creation of the fund order, a transaction calculation for the fund order is initiated periodically. This transaction calculation involves acquiring fund market data corresponding to the fund type, performing transaction calculations on the fund market data according to preset trading rules corresponding to the fund type, generating transaction parameters, and validating the transaction parameters. If the transaction parameters are found to be abnormal, the fund order corresponding to the transaction parameters is marked as pending recalculation. The fund market data includes market data files used for matching funds traded on the exchange and net asset value (NAV) data used for subscriptions and redemptions of funds traded off the exchange. Recalculation processing is performed on fund orders marked as pending recalculation; wherein, the recalculation processing involves reacquiring the fund market data and re-performing the transaction calculation at regular intervals until the transaction parameters pass the parameter verification. Based on the transaction parameters verified by the parameters, the asset information of the simulated fund account is updated, and the updated asset information is output as the simulated transaction result.

2. The method according to claim 1, characterized in that, The step of calculating transactions based on the preset trading rules corresponding to the fund type, using the fund market data, includes: When the fund type is an exchange-traded fund, the price data of the target fund on the trading day is obtained from the market data file. A preset volume-weighted average price rule is used to calculate the average transaction price, and the transaction amount is determined based on the average transaction price and the number of units ordered. The volume-weighted average price rule involves calculating a weighted average of the fund price and corresponding transaction volume for each minute within a preset time period to obtain an average price that reflects the true transaction costs within the preset time period. The number of units ordered is the number of units of the target fund to be traded, set when the fund order is created. If the fund type is an off-exchange fund, the net asset value of the target fund on the trading day is obtained as the transaction price, and the transaction amount is determined based on the net asset value and the entrusted shares.

3. The method according to claim 1, characterized in that, The transaction parameters include at least one of the following: average transaction price, transaction amount, and transaction share; The parameter validation of the transaction parameters includes: If the fund type is an exchange-traded fund, check whether the market data file used for matching exchange-traded funds is valid. If the check result is negative, determine that the parameter verification result is that the transaction parameters are abnormal. If the fund type is an off-exchange fund, check whether the net asset value of the fund used for the subscription and redemption of the off-exchange fund in the fund market data is valid, and if the check result is negative, determine that the parameter verification result is that the transaction parameter is abnormal.

4. The method according to claim 3, characterized in that, The parameter validation of the transaction parameters includes: If the parameter verification result indicates that the transaction parameters are normal, a reasonableness verification is performed on the transaction parameters. If the reasonableness verification fails, the parameter verification result is determined to be abnormal. The reasonableness verification includes: verifying whether the transaction amount is non-negative; verifying whether the average transaction price is within a preset reasonable price range; and verifying whether the logical relationship between the transaction shares and the entrusted shares conforms to preset rules. The entrusted shares are the number of units of the target fund to be traded, set when creating the fund entrustment.

5. The method according to claim 1, characterized in that, The recalculation process for fund delegations marked as being in the recalculation pending state includes: Obtain a holdings statement and an asset statement; wherein, the holdings statement is used to record at least one of the following on a daily basis: fund code, holding shares, cost, and market value of various funds in the simulated fund account; the asset statement is used to record at least one of the following on a daily basis: total assets, cash, and market value of holdings in the simulated fund account; Based on the original order date of the fund order, obtain historical snapshot data of the original order date from the holdings statement and the asset statement, and re-execute the transaction calculation based on the historical snapshot data; wherein, the original order date is the date pre-set for the fund order to perform the transaction calculation.

6. The method according to claim 1, characterized in that, After updating the asset information of the simulated fund account based on the transaction parameters verified by the parameters, and outputting the updated asset information as the simulated trading result, the method further includes: Receive the user-specified rebalancing date; Based on the asset information of the simulated fund account, calculate the first net asset value trend of maintaining the original holdings before the rebalancing date, and the second net asset value trend generated based on the newly executed fund orders after the rebalancing date. Output the comparison results between the first net value trend and the second net value trend.

7. A fund trading simulation device, characterized in that, include: A creation module is used to create a demo account and fund orders for the demo account; wherein, the fund order includes the fund type of the target fund for the transaction; the fund type includes exchange-traded funds and off-exchange funds; The calculation module is used to periodically initiate transaction calculation for the fund order on the next trading day after the fund order is created. The transaction calculation involves obtaining fund market data corresponding to the fund type, performing transaction calculations on the fund market data according to preset trading rules corresponding to the fund type, generating transaction parameters, and verifying the transaction parameters. If the verification finds abnormal transaction parameters, the fund order corresponding to the transaction parameters is marked as pending recalculation. The fund market data includes market data files used for on-exchange fund matching and fund net asset values ​​used for off-exchange fund subscriptions and redemptions. The recalculation module is used to perform recalculation processing on fund orders marked as being in the recalculation state; wherein, the recalculation processing involves re-acquiring the fund market data and re-performing the transaction calculation at regular intervals until the transaction parameters pass the parameter verification. The update module is used to update the asset information of the simulated fund account based on the transaction parameters that have passed the parameter verification, and output the updated asset information as the simulated transaction result.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store computer-executable instructions that, when executed by a processor, implement the steps of the method described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1 to 6.

Images