Option pricing method, system, device, electronic equipment, computer readable storage medium and computer program product

Abstract

This application provides an option pricing method, system, apparatus, electronic device, computer-readable storage medium, and computer program product. The method includes: constructing pricing context data, which includes multiple pricing contexts; generating multiple pricing request messages based on the multiple pricing contexts; wherein each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context; sending the multiple pricing request messages to a message queue, which is used by multiple second nodes to read the multiple pricing request messages; repeatedly reading pricing result messages from the message queue, and performing the following operations on each pricing result message: parsing the pricing result message to obtain a first pricing request identifier and a first pricing result; obtaining a first pricing context based on the first pricing request identifier; and performing pricing calculation processing on the first pricing result based on the first pricing context to obtain a second pricing result; thus, large-scale option pricing is achieved.

Description

Technical Field

[0001] This application relates to the field of financial computing and risk management, and in particular to an option pricing method, system, device, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] Option pricing is a core problem in financial engineering, widely applied in risk management, hedging, and investment decision-making. Over-the-counter (OTC) options hold a significant position in financial markets due to their flexible structure and high degree of customization. To accurately assess option value, analytical formulas or numerical methods (such as Monte Carlo simulations) are typically used for calculation, with computational complexity closely related to the option type.

[0003] In existing technologies, large-scale option pricing tasks typically employ single-machine multi-threaded processing or cluster solutions based on HTTP interfaces. Some systems have attempted to introduce distributed architectures to improve concurrency, but their fixed resource scheduling mechanisms make it difficult to dynamically adjust the computational load; simultaneously, the lack of a unified message queue management mechanism leads to low efficiency in task distribution and result retrieval. For scenarios requiring heterogeneous computing support, existing systems often fail to effectively integrate resources, limiting the improvement of overall computing performance.

[0004] When faced with high-frequency, high-concurrency, and large-scale option pricing demands, the aforementioned technical solutions generally suffer from low computational efficiency, poor scalability, and weak fault tolerance, making it difficult to meet the real-time and stability requirements of modern financial businesses. Summary of the Invention

[0005] To address the aforementioned technical problems, embodiments of this application provide an option pricing method, system, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0006] The option pricing method provided in this application embodiment, applied to the first node, includes: Construct pricing context data, which includes multiple pricing contexts; Multiple pricing request messages are generated based on the multiple pricing contexts; wherein each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context; The multiple pricing request messages are sent to a message queue, which is used by multiple second nodes to read the multiple pricing request messages. The message queue is also used to receive multiple pricing result messages returned by the multiple second nodes. The pricing result message is read from the message queue multiple times, and the following processing is performed on each pricing result message: Parse the pricing result message to obtain the first pricing request identifier and the first pricing result; Obtain the first pricing context based on the first pricing request identifier; Based on the first pricing context, the first pricing result is processed to obtain the second pricing result.

[0007] The option pricing method provided in this application embodiment, applied to the second node, includes: Read a first pricing request message from the message queue. The first pricing request message includes a first pricing context and a first pricing request identifier. Based on the first pricing context, a pricing calculation is performed to obtain a first pricing result; Based on the first pricing result and the first pricing request identifier, a first pricing result message is obtained; Send the first pricing result message to the message queue.

[0008] The option pricing device provided in this application embodiment is applied to a first node, and the device includes: The data construction module is used to construct pricing context data, which includes multiple pricing contexts; The data processing module is used to generate multiple pricing request messages based on the multiple pricing contexts; wherein each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context; The first data transmission module is used to send the plurality of pricing request messages to a message queue, the message queue is used by a plurality of second nodes to read the plurality of pricing request messages, and the message queue is also used to receive a plurality of pricing result messages returned by the plurality of second nodes; The data processing module is further configured to read pricing result messages from the message queue multiple times; and perform the following processing on each pricing result message: parse the pricing result message to obtain a first pricing request identifier and a first pricing result; obtain a first pricing context based on the first pricing request identifier; and perform pricing calculation processing on the first pricing result based on the first pricing context to obtain a second pricing result.

[0009] The option pricing device provided in this application embodiment is applied to a second node, and the device includes: The second data transmission module is used to read a first pricing request message from a message queue. The first pricing request message includes a first pricing context and a first pricing request identifier. The data calculation module is used to perform pricing calculation based on the first pricing context to obtain a first pricing result; and to obtain a first pricing result message based on the first pricing result and the first pricing request identifier. The second data transmission module is further configured to send the first pricing result message to the message queue.

[0010] The electronic device provided in this application includes a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute any of the above-described option pricing methods.

[0011] The computer-readable storage medium provided in this application embodiment is used to store a computer program that causes a computer to execute any of the above-described option pricing methods.

[0012] The computer program product provided in this application includes computer program instructions that cause a computer to execute any of the above-described option pricing methods.

[0013] In the technical solution of this application embodiment, pricing context data is constructed, including multiple pricing contexts; multiple pricing request messages are generated based on the multiple pricing contexts; each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context; the multiple pricing request messages are sent to a message queue, which is used by multiple second nodes to read the multiple pricing request messages, and the message queue is also used to receive multiple pricing result messages returned by multiple second nodes; pricing result messages are read from the message queue multiple times, and the following processing is performed on each pricing result message: parsing the pricing result message to obtain a first pricing request identifier and a first pricing result; obtaining a first pricing context based on the first pricing request identifier; and performing pricing calculation processing on the first pricing result based on the first pricing context to obtain a second pricing result; thus, the shortcomings of traditional technologies in large-scale pricing calculation scenarios for over-the-counter options, such as insufficient performance, poor scalability, low reliability, and limited computing resources, are overcome. Based on a distributed computing framework and a stateless microservice architecture, a method and system for implementing large-scale distributed pricing of over-the-counter options is achieved by decoupling the data context processing logic from the calculation logic and combining a reliable message queue to asynchronously interact with pricing messages. This provides a method and system for implementing large-scale distributed pricing of over-the-counter options that is efficient, stable, elastically scalable, and fully utilizes computing resources. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the architecture of the option pricing system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 1 ; Figure 3 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 2 ; Figure 4 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 3 ; Figure 5 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 4 ; Figure 6 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 5 ; Figure 7 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 6 ; Figure 8 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 7 ; Figure 9 This is a schematic diagram of the structure of the option pricing device provided in the embodiments of this application. Figure 1 ; Figure 10 This is a schematic diagram of the structure of the option pricing device provided in the embodiments of this application. Figure 2 ; Figure 11 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permissible, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0018] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows: 1) Financial derivatives: A type of financial contract based on an underlying financial instrument, the value of which depends on one or more underlying assets or indices. Depending on the trading venue, they can be divided into exchange-traded derivatives and over-the-counter derivatives.

[0019] 2) Over-the-counter derivatives: Financial derivative contracts traded outside of exchanges.

[0020] 3) Over-the-counter options: Option contracts traded outside of exchanges typically have complex structures and non-standardized terms. Their pricing process involves various financial models and market parameters, and they are often used for hedging risks or arbitrage strategies.

[0021] 4) Underlying asset: The underlying financial asset linked to the derivative contract.

[0022] 5) Ledger: The account where over-the-counter derivative contracts or hedged securities are locked in the ledger. The ledger code serves as the ledger primary key.

[0023] 6) Risk indicators: Indicators required for hedging risks of financial derivatives, such as the price of the underlying asset, the rate of change, directional risk (DELTA), curvature risk (GAMMA), and hedging exposure.

[0024] 7) Option pricing: Options are priced based on quantitative models, market conditions, volatility and other data, and the present value, DELTA and other indicators are calculated.

[0025] 8) Pricing services: Computer software services for pricing over-the-counter derivatives.

[0026] 9) Pricing Context: An intermediate structure used to store the necessary data for calculating option risk indicators. In this application, this structure includes option definition data, market data (such as underlying asset price, volatility, return, etc.), pricing model parameters, and fields required for business processing (such as notional principal, currency, exchange rate, etc.), and is a key data structure supporting distributed computing.

[0027] 10) Pricing model parameters: Model-related parameters used to perform option pricing calculations, such as the number of paths in the Monte Carlo simulation, random seed, time step, etc. These parameters determine the accuracy and efficiency of the calculation method.

[0028] In recent years, the over-the-counter (OTC) options market has developed rapidly, with its business scale and complexity continuously increasing. Financial institutions hold a growing number of OTC option contracts. Simultaneously, with the rapidly changing market environment and the increasing demand for sophisticated risk management, high-frequency, fast, and accurate pricing calculations for large positions have become a necessity. OTC option pricing is the core foundation for risk measurement, profit and loss accounting, and hedging; its computational performance directly affects a financial institution's risk management capabilities and market competitiveness. Current technology uses a stand-alone mode for batch pricing calculations, and the pricing indicator calculation process is as follows: Step 1: Starting with the pricing batch, all over-the-counter options data that have been booked and are still in effect in the current system are collected from the database.

[0029] Step 2: For the collected over-the-counter options, read the corresponding underlying market conditions, volatility, dividend yield, return and model parameters required for pricing from the system for each option, and combine them with the option definition data to convert them into structured input parameters required by the core pricing unit. At the same time, save the context data of each option pricing in memory.

[0030] Step 3: Input the pricing parameters into the pricing core unit one by one to perform pricing, and wait for all pricing to be completed.

[0031] Step 4: Combine the pricing results output by the pricing library with the corresponding context data in memory for further processing to obtain the final pricing result.

[0032] Step 5: Summarize the results and write the pricing results into the database.

[0033] However, traditional over-the-counter (OTC) option pricing techniques suffer from insufficient performance, poor scalability, low reliability, and limited computing resources when dealing with large-scale, high-concurrency computing scenarios. To address these issues, this application provides an option pricing method, system, device, electronic device, computer-readable storage medium, and computer program product that enables a method and system for large-scale distributed pricing of OTC options that is efficient, stable, elastically scalable, and fully utilizes computing resources.

[0034] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The above-mentioned related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0035] The following describes exemplary applications of the devices provided in the embodiments of this application. The electronic devices provided in the embodiments of this application can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and vehicle terminals, or they can be implemented as servers.

[0036] See Figure 1 , Figure 1 This is a schematic diagram of the system architecture of the option pricing method provided in the embodiments of this application, for example. Figure 1 The process involves a first node 101, multiple second nodes 102, and a message queue 103.

[0037] In some embodiments, the option pricing system further includes: a pricing configuration service module 104, a market data service module 105, and a basic data service module 106.

[0038] In some embodiments, the pricing configuration service module 104 is responsible for accessing pricing-related configuration items, which include which pricing model parameters are used for each type of option, which volatility and dividend rate are used for each underlying asset of the option, and which yield is used for each currency. The pricing configuration service needs to determine how to read the required dependent data for each option based on the pricing configuration.

[0039] In some embodiments, the market data service module 105 is responsible for storing and retrieving market data related to the underlying asset, such as market price, volatility, dividend yield, and return. The first node needs to read the market data related to pricing from the market data service.

[0040] In some embodiments, the basic data service module 106 is responsible for accessing and storing OTC option definition data, security definition data, and calendar data. The first node 101 needs to read the basic data on which pricing depends from the basic data service.

[0041] In some embodiments, the option pricing system further includes a first database 107 and a second database 108.

[0042] In some embodiments, the first database 107 is used to store intermediate data generated during the pricing task.

[0043] In some embodiments, the second database 108 is used by the first node to read all pricing results of the batch task from the first database, convert them into the data format required by the second database, and save them in batches to the second database.

[0044] In some embodiments, the first node 101, also known as an organization node or pricing organization node, is responsible for reading pricing configurations, OTC option and underlying asset definition data, and market data from other service modules, constructing the pricing input parameters required by the computing nodes, and interacting with each computing node through a reliable message queue, including sending pricing requests and collecting pricing results. Furthermore, the first node temporarily stores context data during the pricing process in the first database 700 and persists the final pricing result in the second database 108.

[0045] In some embodiments, the second node 102, also referred to as a compute node, pricing compute node, etc., is responsible for executing the pricing calculation logic. Each pricing compute node is stateless and horizontally scalable. The maximum number of nodes depends on the hardware resources of the deployed cluster and can be flexibly adjusted according to actual resource availability. The deployment form of compute nodes is not limited, including but not limited to container clouds, Flink compute clusters, etc. Since each compute node is independent of the others and completely decoupled from the pricing organization node through message queues, heterogeneous clusters can be supported at the deployment level. For example, at the compute core processor level, a hybrid CPU / GPU deployment can be supported.

[0046] It should be noted that the embodiments of this application can be applied to various financial scenarios, especially complex computing tasks such as batch pricing, stress testing, and scenario analysis of over-the-counter derivatives. By introducing a distributed computing framework, message queue communication mechanism, and heterogeneous computing scheduling strategy, the shortcomings of traditional single-machine systems in terms of performance, scalability, reliability, and computing efficiency are effectively solved, achieving an efficient, stable, and flexible large-scale option pricing solution. Figure 2 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 1 ,like Figure 2 As shown, it is applied to the first node, and will be explained in detail below.

[0047] Step 201: Construct pricing context data, which includes multiple pricing contexts.

[0048] In this embodiment, the first node can also be called an organization node, pricing organization node, etc., and is responsible for organizing and managing pricing data. For example, in an option pricing system, the system decouples the pricing data organization and management and pricing calculation logic in the pricing process, splitting them into organization nodes and calculation nodes in the system architecture. Calculation nodes are used for numerical calculations of the smallest pricing unit (such as the unit option price), while organization nodes are used for business-related price conversions, currency conversions, and other operations that depend on the complete contract context. By having the organization node combine the result with the context after it is returned, complete decoupling of the calculation logic and business rules is achieved.

[0049] In this embodiment, the pricing context refers to the intermediate structure used to store the necessary data for calculating option risk indicators. Each pricing context contains option definition data, market data (such as underlying asset price, volatility, yield, etc.), pricing model parameters, and fields required for business processing (such as notional principal, currency, exchange rate, etc.), and is a key data structure supporting distributed computing. By constructing multiple independent pricing contexts, parallel pricing calculations for multiple over-the-counter options can be achieved. For example, the organizational node first obtains the definition information of each option from the basic data service, including the underlying asset, effective date, expiration date, notional principal, option type, etc.; then it obtains relevant market data from the market service, such as the closing price of the underlying asset, volatility curve, dividend yield curve, etc.; and then queries the corresponding pricing model parameters according to the option type and pricing scenario.

[0050] In some embodiments, the first node assembles the first field (option definition, market data, pricing model parameters, etc.) required by the second node to generate pricing input parameters and the second field (notional principal, initial price, currency, exchange rate, etc.) required by the first node to perform secondary pricing processing together to form the context of an option pricing.

[0051] In some embodiments, each first node provides an interface for initiating a pricing request task. After any first node is invoked by this interface, it begins preparing to trigger the pricing request task. Specifically, before the first node executes step 201, the process further includes: Receive a pricing request task, which includes pricing request parameters; generate a task context based on the pricing request parameters, which includes a pricing task identifier.

[0052] Accordingly, in some embodiments, pricing context data is constructed based on the task context.

[0053] Here, a pricing request task refers to a business request initiated by a user or the system to trigger the calculation of OTC option pricing. Pricing request tasks can also be called pricing batch tasks. Pricing request tasks typically originate from traders, risk management departments, or other automated system modules. The purpose of a pricing request task is to obtain the pricing results of the next batch or multiple OTC options at a specific point in time. Pricing request tasks are generally submitted to the system through API interfaces, message queues, or scheduled tasks. Each pricing request task is unique and can carry additional business parameters, such as the pricing date, whether to perform stress testing, and whether to enable GPU acceleration.

[0054] Pricing request parameters refer to the specific set of input information that constitutes a pricing request task. These typically include the option number, underlying asset code, pricing model type, pricing scenario (such as benchmark scenario or stress scenario), currency, exchange rate source, and volatility curve selection. Pricing request parameters determine the specific calculation logic and input conditions for each pricing request, ensuring that the pricing process conforms to business needs and market environment assumptions. For example, in cross-currency option pricing, pricing request parameters may include key fields such as the local / foreign currency exchange rate and correlation coefficient.

[0055] A task context is a data structure used in the pricing process to organize and manage information related to pricing tasks. It includes the pricing task identifier, pricing date, and pricing scenario. The task context also records metadata such as its status, progress, and failure reasons. The purpose of the task context is to decouple its organizational logic from the actual computational logic, enabling the system to process different pricing tasks in parallel across multiple nodes while maintaining the consistency and traceability of the task context state.

[0056] In this embodiment, a pricing request task and task context mechanism are introduced to achieve fine-grained control over the pricing process. The option pricing system in this embodiment can support multiple users initiating pricing requests simultaneously, thereby improving response efficiency and further meeting the needs of high-frequency, large-scale pricing. By constructing pricing context data based on task context, data organization and computational logic are separated, avoiding performance bottlenecks caused by computing nodes maintaining complex contexts internally. This improves the system's scalability and stability and enables efficient pricing by fully utilizing distributed computing resources.

[0057] In some embodiments, pricing context data is constructed based on the task context, including: Based on the pricing request parameters, obtain the OTC option sub-definition data, market data, and pricing model parameters; based on the OTC option sub-definition data, market data, and pricing model parameters, construct pricing context data, which includes multiple pricing contexts.

[0058] The pricing context includes a first field and a second field. The first field includes the parameters required by the second node to calculate the first pricing result, and the second field includes the parameters required by the first node to calculate the second pricing result.

[0059] Here, OTC option sub-definition data refers to the specific definition information of each OTC option contract obtained by the first node from the basic data service module, such as the underlying asset, effective date, expiration date, notional principal, and option type. OTC option sub-definition data is used to clarify the basic structure and business attributes of options, providing fundamental input for subsequent calculations. For example, in cross-currency options, OTC option sub-definition data also includes key information such as exchange rates and currency pairs.

[0060] Here, market data refers to the market data related to the underlying asset linked to the option, obtained by the first node from the market data service module. This includes the underlying asset's closing price, volatility curve, dividend yield curve, and yield curve. Market data is used in option pricing to directly determine the calculation results of option prices and their risk indicators, and is an indispensable dynamic input in the pricing process. For example, in Monte Carlo simulations, changes in volatility and dividend yield can affect the generation of price paths.

[0061] Here, pricing model parameters refer to the computational parameters obtained by the first node from the pricing configuration service module, determined based on the option type and pricing method, such as the number of iterations, step size, and random seed for Monte Carlo simulation. Pricing model parameters determine computational accuracy and efficiency and can be adjusted according to different scenarios. For example, European options can use the Black-Scholes formula, while exotic options may employ Monte Carlo simulation or a binomial tree model.

[0062] By combining and encapsulating the three types of data (OTC option sub-definition data, market data, and pricing model parameters) into a complete pricing context data structure, it can be ensured that each pricing unit has an independent and complete set of information. Furthermore, by combining and encapsulating these three types of data into a complete pricing context data structure, each computing node can independently process the pricing context data, thereby achieving decoupled computation and distributed execution. The constructed pricing context data contains multiple pricing contexts, each corresponding to the pricing requirement of an option. This data structure configuration enables the system to flexibly support various application scenarios such as batch pricing, stress testing, and scenario analysis, and the system itself is easy to expand and maintain.

[0063] Here, the pricing context is the combination of the fields required by the second node to generate pricing input parameters (option definition, market data, pricing model parameters, etc.) and the fields required by the first node to perform secondary pricing processing (notional principal, initial price, currency, exchange rate, etc.), which together constitute the context of an option pricing.

[0064] Furthermore, if stress testing or scenario analysis of options requires pricing specific pricing parameters under different offset scenarios, then the original context data is further derived to obtain the context for the specific scenario (e.g., a 1% price offset on the underlying asset, a 5% volatility offset, etc.). The resulting pricing context then serves as a data structure spanning the entire lifecycle of requests, computations, and results. This is not simply parameter passing, but a distributed computing context management model with externalized state. It ensures that computing nodes are stateless while still supporting complex subsequent result processing, unlike existing technologies that typically maintain context internally within computing nodes and couple business processing logic.

[0065] In some embodiments, by persisting the task context to a first database, the system can achieve high-concurrency, high-reliability task scheduling and state management. The first database can be a caching middleware.

[0066] In some embodiments, the first node further performs the following: obtaining the total number of multiple pricing contexts to obtain the total number of pricing; initializing the number of successful pricing and the number of failed pricing to a first value; and setting the total number of pricing, the number of successful pricing, and the number of failed pricing in the task context.

[0067] Here, the total number of pricing requests refers to the number of all pending option pricing requests in the current batch of tasks. The first node performs statistics based on all OTC option definition data, market data, and pricing context data generated from model parameters selected in the pricing batch task to arrive at the total number of pricing requests. For example, in a pricing batch containing 10,000 option contracts, the first node generates a corresponding pricing context for each option, and after statistically analyzing these pricing contexts, the final total number of pricing requests is 10,000.

[0068] The first value is usually zero (0), indicating that no pricing operations have been completed at the start of the task. The pricing success count records the number of pricing requests that have been successfully executed in the current task, while the pricing failure count records the number of pricing requests that failed to be executed successfully for various reasons.

[0069] By acquiring and counting the total number of pricing transactions, the first node can provide a basis for subsequent task status management, accurately determine whether all tasks have been completed, and provide support for status synchronization between distributed nodes.

[0070] In some embodiments, the total number of pricing transactions, the number of successful pricing transactions, and the number of failed pricing transactions are placed in a task context cached in a first database. The number of successful pricing transactions and the number of failed pricing transactions are initialized to zero before the task begins so that they can be updated incrementally during task execution.

[0071] Step 202: Generate multiple pricing request messages based on multiple pricing contexts; wherein each pricing request message includes each pricing context and the pricing request identifier corresponding to each pricing context.

[0072] In this embodiment, a pricing request message refers to a message body containing a pricing context and a unique identifier corresponding to that pricing context, used to be sent to a computing node via a message queue to perform pricing calculations. Each pricing request message corresponds to the basic input of an option pricing task. The pricing request identifier is a unique string used to identify the association between each pricing request and the pricing result corresponding to that pricing request.

[0073] Here, the first node generates a unique ID for each piece of pricing context data as a pricing request identifier, and uses this unique pricing request identifier as the key to cache the context data in the cache middleware. It then converts the pricing context data into formatted pricing input parameters required by the compute nodes, encapsulates these input parameters along with the pricing request identifier into the body of a pricing request message, and sends the pricing request message to the message queue. In this step, a pricing request for an option is associated with its corresponding pricing context data through the pricing request identifier. By sending the pricing request message to the message queue, multiple second nodes (i.e., compute nodes) can asynchronously read and execute the corresponding pricing tasks.

[0074] In some embodiments, the first node performs the following processing on each pricing context: generating a pricing request identifier corresponding to the pricing context, wherein the pricing request identifier includes a pricing task identifier; and storing the pricing context in a first database through the pricing request identifier, wherein the first database is used to store data generated during the pricing process.

[0075] See here. Figure 3 , Figure 3 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 2This means that the first node generates a unique pricing request identifier for each pricing context and concatenates the pricing request identifier with the pricing task identifier to associate it with the pricing task, thus achieving unique identification and management of each pricing task. This embodiment ensures that data from different pricing tasks are isolated from each other, thereby avoiding data confusion and supporting high-concurrency, large-scale distributed pricing computation. Specifically, the pricing request identifier is a unique ID generated by the first node for each pricing context. The pricing request identifier consists of a pricing task identifier and a random sequence and is used as a key in the first database, i.e., the cache middleware, to associate pricing contexts, pricing request messages, and pricing result messages. The pricing request identifier is not only used for data indexing and retrieval but also plays a crucial role in the entire pricing process, including tracking task status, matching results, and retrying in case of failure. For example, the implementation of generating the pricing request identifier corresponding to the pricing context can be based on generating a globally unique identifier based on UUID to ensure no conflicts occur in a multi-node environment. A unique identifier can also be generated based on a combination of timestamp, task ID, and sequence number using a data identification method. This method is suitable for application scenarios with clearly defined task divisions.

[0076] The first database, also known as a caching middleware (such as Redis), is a storage medium used to persistently store data generated during the pricing process. The first database typically possesses high availability and high-performance read / write capabilities, sufficient to handle large volumes of data writes. For example, the first node stores the pricing context in the first database using the pricing request identifier. A key-value pair storage method is used, with the pricing request identifier as the key and the pricing context content as the value, enabling efficient data retrieval.

[0077] In this embodiment, the system generates and uses a pricing request identifier to manage the pricing context. The system stores the pricing context in a dedicated first database. Thus, this embodiment can achieve fine-grained management of the pricing process and efficient persistence of data. Consequently, this embodiment can significantly improve the system's computing efficiency and data processing capabilities in a large-scale distributed environment.

[0078] Step 203: Send multiple pricing request messages to the message queue. The message queue is used by multiple second nodes to read multiple pricing request messages. The message queue is also used to receive multiple pricing result messages returned by multiple second nodes.

[0079] In this embodiment, a message queue is a message middleware used for asynchronous communication between multiple nodes. It is responsible for receiving pricing request messages from the organization node and for multiple compute nodes to consume these messages. Simultaneously, it also receives pricing result messages returned by the compute nodes for the organization node to read and process. The message queue supports high concurrency, reliable transmission, and decoupling characteristics, making it a core component for realizing the distributed capabilities of the system. The message queue ensures the reliable delivery of pricing request messages and allows compute nodes to dynamically consume tasks based on their own load, thereby achieving horizontal scalability and fault tolerance. Furthermore, the message queue can guarantee either message order or unordered delivery, depending on the system design requirements.

[0080] In some embodiments, the message queue includes a pricing topic, which includes a first pricing topic and a second pricing topic; the types of second nodes include a first type of second node and a second type of second node; the first type of second node is used to read multiple pricing request messages within the first pricing topic from the message queue; the second type of second node is used to read multiple pricing request messages within the second pricing topic from the message queue.

[0081] In some embodiments, sending multiple pricing request messages to a message queue includes: determining a pricing topic corresponding to each pricing request message based on each pricing context; and sending each pricing request message to a first pricing topic or a second pricing topic in the message queue.

[0082] Here, the message queue sets up pricing topics, which can include a first pricing topic and a second pricing topic. The first pricing topic can be a GPU pricing topic, and the second pricing topic can be a CPU pricing topic. These pricing topics are used to support differentiated processing for different types of compute nodes. Specifically, compute nodes are split into first-type second nodes and second-type second nodes. The first-type second nodes can be GPU compute nodes deployed in a GPU cluster; the second-type second nodes can be CPU compute nodes deployed in a CPU cluster. The GPU cluster listens to the GPU pricing topic in the message queue, and the CPU cluster listens to the CPU pricing topic in the message queue. In this way, by classifying compute node types, the most suitable computing resources can be dynamically selected based on the computing requirements of different priced tasks. When scheduling the computing process, computing efficiency can be optimized, and overall system performance can be improved.

[0083] Before sending a pricing request message to the message queue, the first node determines whether the pricing request should be computed using a GPU or a CPU, based on information such as the option type and pricing model parameters in the corresponding context data. For example, pricing using Monte Carlo simulation should be computed using a GPU, while pricing that can be solved analytically should be computed using a CPU. Pricing requests that should be computed using a GPU are sent to the GPU pricing topic, and those that should be computed using a CPU are sent to the CPU pricing topic. GPU computing nodes consume the pricing request through the GPU pricing topic, complete the pricing using the GPU, and push the pricing result to the message queue. CPU computing nodes consume the pricing request through the CPU pricing topic, complete the pricing using the CPU, and similarly push the pricing result to the message queue.

[0084] Step 204: Read pricing result messages from the message queue multiple times, and perform the following processing on each pricing result message: Step 2041: Parse the pricing result message to obtain the first pricing request identifier and the first pricing result; Step 2042: Obtain the first pricing context based on the first pricing request identifier; Step 2043: Perform pricing calculation processing on the first pricing result based on the first pricing context to obtain the second pricing result.

[0085] In this embodiment, the pricing result message refers to a message body containing a pricing request identifier and a preliminary pricing result. It is generated by the compute node and returned to the message queue for the organization node to parse and process. The pricing result message serves as the carrier of the calculation result, ensuring that the calculation result can be tracked and processed. The organization node reads the pricing result message multiple times from the message queue, one message at a time, and extracts the pricing request identifier and the preliminary pricing result. Next, the organization node reads the corresponding pricing context from the cache middleware based on the pricing request identifier, and performs a secondary calculation on the preliminary pricing result using business parameters (such as notional principal, currency, exchange rate, etc.) in the pricing context to obtain the final pricing value that meets business requirements. After all pricing results have been processed, the organization node reads all the final pricing results of this batch of tasks in batches from the cache middleware and persists them to the second database, completing the entire pricing batch task.

[0086] In practice, the organization's nodes count the number of successful and failed pricing transactions. After all pricing results have been processed, they attempt to preempt the task-level distributed lock to ensure that only one node can execute the persistence operation of the final result. This attempt to preempt the task-level distributed lock guarantees the integrity and consistency of task execution, preventing data inconsistencies caused by concurrent operations.

[0087] As can be seen from the above, the option pricing method provided in this application, by constructing a decoupled system architecture, separates data organization from computational logic, making computational nodes stateless and improving the system's scalability and reliability. By introducing a message queue mechanism, asynchronous task distribution and result collection are achieved, enhancing the system's concurrent processing capabilities and stability. Furthermore, by supporting heterogeneous computing with CPUs and GPUs, computational efficiency is further improved, meeting the needs of large-scale over-the-counter option pricing.

[0088] In some embodiments, after obtaining the second pricing result, the following processing is performed on each second pricing result: obtaining the first pricing date, the first pricing scenario, and the first pricing option based on the first pricing context; and storing the second pricing result, the first pricing date, the first pricing scenario, and the first pricing option in the first database through the first pricing request identifier.

[0089] Here, the organization node consumes pricing result messages through a message queue, parsing the message to obtain a pricing request ID and a pricing result output parameter. It then reads the corresponding pricing context data from the caching middleware using the pricing request identifier, and performs secondary calculations on the pricing result based on this context data. For example, it performs secondary calculations on the first pricing result output by the calculation node based on fields such as the notional principal and exchange rate source of the option contract in the pricing context to obtain the final pricing value that meets business expectations—the second pricing result. Afterward, the processed pricing result value is assembled with the pricing date, pricing scenario, and unique pricing option ID from the pricing context and cached in the caching middleware. The node then attempts to consume the next pricing result message again, and the process repeats.

[0090] In actual deployments, the second database can be a relational database (such as MySQL or PostgreSQL) or a distributed database (such as Cassandra or MongoDB). The choice of the second database depends on the system's performance requirements and scalability needs.

[0091] In some embodiments, for each second pricing result, the first node further performs the following processing: obtaining a first pricing task identifier from a first pricing request identifier, the first pricing task identifier corresponding to a first pricing task and a first task context; determining whether the second pricing result is successful; if the pricing is successful, incrementing the number of successful pricing corresponding to the first task context by one through the first pricing task identifier; if it fails, incrementing the number of failed pricing in the first task context by one.

[0092] Here, all organizational nodes consume pricing result messages from the message queue and parse the pricing task identifier from the pricing request identifier in the pricing result message. After processing the pricing result corresponding to the current pricing result message and saving it to the cache middleware, if the pricing result is successful, the number of successful pricing in the task context in the cache middleware is incremented by one using the pricing task identifier. This step can be completed through atomic operations to ensure correct counting when multiple nodes are in parallel. If the pricing result is unsuccessful, the number of unsuccessful pricing in the task context is incremented by one.

[0093] In some embodiments, the first node further performs the following: determining whether the sum of the number of successful pricing and the number of failed pricing equals the total number of pricing; if not equal, then reading the pricing result message from the message queue; if equal, then performing distributed lock preemption processing on the first pricing task based on the first pricing task identifier to obtain the preemption state, which includes a successful preemption state or a failed preemption state.

[0094] In some embodiments, the first node further performs the following: if the preemption status is a successful preemption status, then read all the second pricing results corresponding to the first pricing task from the first database based on the first pricing task identifier; and store all the second pricing results in the second database, which is used to store the pricing result data after the pricing task is completed.

[0095] Here, the first node checks if the current number of successful pricing transactions plus the number of failed pricing transactions equals the total number of pricing transactions. If they don't equal, it continues to try consuming the next pricing result message. If they do equal, it attempts to preempt a distributed lock corresponding to the task in the cache middleware. If preemption fails, no action is taken. If preemption succeeds, all pricing results for this task are read from the cache middleware, appropriate data transformations are performed, and then the results are saved to the database.

[0096] In some embodiments, the first node further performs the following: determining whether the number of pricing failures is a first value; if it is not the first value, determining that the pricing status of the first pricing task is a pricing failure status; if it is the first value, determining that the pricing status of the first pricing task is a pricing success status.

[0097] Here, the first node checks if the number of failures is 0. If it is not 0, the task status is determined to be failed, and manual intervention is required to analyze the specific reasons for the failure. If the number is 0, the task is determined to be successful. The task status result is recorded in the system, and the task is completed.

[0098] Figure 4 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 3 ,like Figure 4 As shown, applied to the second node, the option pricing method includes: Step 401: Read the first pricing request message from the message queue. The first pricing request message includes the first pricing context and the first pricing request identifier.

[0099] In this embodiment, the computing nodes are split into GPU computing nodes and CPU computing nodes. At the code level, except for pricing which utilizes GPUs and CPUs respectively, the logic for message parsing and interaction with the message queue remains consistent. They are deployed in GPU clusters and CPU clusters respectively. The GPU cluster listens for GPU pricing topics in the message queue, and the CPU cluster listens for CPU pricing topics in the message queue.

[0100] In some embodiments, the message queue includes a pricing topic, which includes a first pricing topic and a second pricing topic; the types of second nodes include a first type of second node and a second type of second node; reading a first pricing request message from the message queue includes: The first type of second node reads multiple pricing request messages from the message queue within the first pricing topic; the second type of second node reads multiple pricing request messages from the message queue within the second pricing topic.

[0101] Here, before sending a pricing request message to the message queue, the organization node determines whether the pricing request should be computed using GPU or CPU based on information such as the option type and pricing model parameters in the corresponding context data (for example, pricing using Monte Carlo simulation should use GPU, while pricing that can be solved analytically should use CPU). Pricing requests that should be computed using GPU are sent to the GPU pricing topic, and pricing requests that should be computed using CPU are sent to the CPU pricing topic.

[0102] Step 402: Calculate the pricing based on the first pricing context to obtain the first pricing result.

[0103] In this embodiment, the computing node consumes pricing request messages through a message queue, parses the message to obtain a pricing request ID and a pricing request parameter, inputs the pricing request parameter into the pricing calculation function, and waits for the calculation to complete to obtain the pricing calculation result.

[0104] Step 403: Based on the first pricing result and the first pricing request identifier, obtain the first pricing result message.

[0105] In this embodiment of the application, the pricing calculation result and the pricing request ID are encapsulated together in the pricing result message body, sent to the message queue, and the system attempts to consume the next pricing request message again.

[0106] Step 404: Send the first pricing result message to the message queue.

[0107] In this embodiment, GPU computing nodes consume pricing requests through GPU pricing topics, complete pricing using the GPU, and push the pricing results to a message queue. CPU computing nodes consume pricing requests through CPU pricing topics, complete pricing using the CPU, and similarly push the pricing results to a message queue. Organizational nodes consume pricing results from both GPU and CPU computing nodes simultaneously through the message queue, without needing to consider which node the results originated from; they can proceed with subsequent processing in a uniform manner.

[0108] As can be seen from the above, the option pricing method provided in this application, through clustered management and distributed pricing of the pricing service, enables the system to use server clusters for parallel computing, thereby accelerating the pricing speed. As business volume increases, performance issues can be addressed by increasing the number of servers. By splitting the system into organization nodes and computing nodes, the data organization and processing logic and the computing logic are decoupled, and each node is stateless, allowing each node to support flexible expansion and solving the horizontal scaling problem. Because each node is stateless, and organization nodes and computing nodes interact through reliable message queues, single points of failure are avoided. By utilizing the message queue's message submission and confirmation mechanism, it is ensured that the system will not experience missing pricing data due to the failure of a single node, thus improving the overall reliability of the system. The distributed computing nodes distribute the server load and also improve the flexibility of the deployment topology, enabling the mixed deployment of CPU and GPU computing nodes. This solves the problem of a single computing core architecture in the original system, fully utilizing the computing power of different computing resources and improving pricing efficiency.

[0109] The following will illustrate the option pricing method provided in this application embodiment under the OTC option pricing scenario, with reference to exemplary applications and implementations provided in the embodiments of this application. In recent years, my country's OTC option market has developed rapidly, with its business scale and complexity continuously increasing. Financial institutions hold an increasingly large number of OTC option contracts. Simultaneously, with the rapidly changing market environment and the increasing demand for refined risk management, high-frequency, fast, and accurate pricing calculations for large positions have become a business necessity. OTC option pricing is the core foundation for risk measurement, profit and loss accounting, and transaction hedging; its computational performance directly relates to the risk management capabilities and market competitiveness of financial institutions. However, traditional OTC option pricing techniques face severe technical challenges when dealing with large-scale, high-concurrency computational scenarios, specifically in the following four aspects: I. Massive computational load and severe time consumption. Over-the-counter options, especially complex exotic options, typically rely on numerical methods such as Monte Carlo simulations for pricing. To ensure computational accuracy, a single pricing operation often requires simulating hundreds of thousands or even millions of price paths, making the calculation process extremely time-consuming. When batch pricing or revaluation of a large number of contracts is required, traditional single-machine architectures can take hours or even days to complete, failing to meet business timeliness requirements.

[0110] Second, poor scalability and low resource utilization. Existing technologies mostly adopt single-machine multi-threading or cluster solutions based on traditional HTTP interface calls. The computing power of single-machine solutions is limited by physical hardware and cannot be horizontally scaled. Although traditional cluster solutions can utilize multiple machines, resource allocation is rigid and it is difficult to elastically scale according to dynamically changing computing loads, resulting in low resource utilization.

[0111] Third, weak fault tolerance and insufficient system reliability. Hardware failures are common in large-scale computing tasks. Traditional computing frameworks typically lack robust fault tolerance mechanisms. The failure of any node in the computing cluster can cause the entire pricing task, which lasts for several hours, to fail, requiring manual intervention and starting from scratch, which greatly affects the stability and availability of the system.

[0112] Fourth, the traditional computing architecture is too simplistic to support heterogeneous parallel computing. In over-the-counter option pricing, Monte Carlo simulation is a common method for solving complex exotic options. The inherent data parallelism of this algorithm is highly compatible with the parallel computing architecture of GPUs, thus using GPUs to price such options can significantly improve efficiency. Meanwhile, European vanilla options and binary options can be solved analytically using formulas, and their calculation process is relatively simple, requiring only CPU computation. Traditional systems, due to limitations in their architecture, cannot simultaneously utilize both CPUs and GPUs, thus restricting the improvement of computational efficiency in terms of resource allocation.

[0113] The original system used a standalone mode for batch pricing calculations. The pricing indicator calculation process was as follows: At the start of a pricing batch, all book-entered and still-in-term OTC option data were collected from the database. For each collected OTC option, the corresponding underlying asset market data, volatility, dividend yield, return, and model parameters required for pricing were read from the system and converted into structured input parameters required by the pricing core unit, combined with option definition data. Simultaneously, the context data for each option's pricing was stored in memory. The pricing input parameters were then input into the pricing core unit for pricing, and the process continued until all pricing was completed. The pricing results output from the pricing library were combined with the corresponding context data in memory for further processing to obtain the final pricing result. The results were then summarized and written to the database.

[0114] Existing pricing methods have the following drawbacks: 1. Low computational efficiency and long processing time. The original design used single-machine computing, which had limited computing resources. As the business scale expanded and the number of ongoing contracts increased, the batch computing time increased linearly with the business scale, eventually causing the system to fail to meet the performance indicators for normal business operations.

[0115] 2. Poor system scalability. The key data relied upon in the pricing process resides in memory, and the pricing calculation logic is coupled with pricing context management, task state management, and other logics, making it impossible to achieve horizontal scaling of the pricing system across multiple nodes.

[0116] 3. Weak fault tolerance and insufficient system reliability. If the service crashes and restarts unexpectedly during the pricing batch execution process, all option pricing will fail, requiring the batch to be initiated again and a full revaluation to be performed. The time cost incurred is unacceptable for a system with a large volume of business.

[0117] 4. Difficulty in supporting heterogeneous computing. In single-machine scenarios, it is difficult to achieve hybrid heterogeneous computing using CPUs and GPUs, making it impossible to optimize pricing resource allocation for the pricing complexity of options, thus limiting the improvement of pricing efficiency.

[0118] To overcome the shortcomings of traditional technologies in large-scale OTC option pricing calculations, such as insufficient performance, poor scalability, low reliability, and limited computing resources, this paper proposes a method and system for large-scale distributed pricing of OTC options. This is based on a distributed computing framework and a stateless microservice architecture. It decouples data context processing logic from computation logic and uses a reliable message queue to asynchronously handle pricing message interactions. This results in a system that is efficient, stable, elastically scalable, and fully utilizes computing resources. See also... Figure 5 , Figure 5 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 4 .

[0119] Step 501, Begin.

[0120] Step 502: The organization node reads all the option definition data that needs to be priced.

[0121] Step 503: Organize the node to read the definition and market information of the underlying asset of the option.

[0122] Step 504: Organize the node to read the target volatility, dividend yield, and currency yield.

[0123] Step 505: Organize the node to read the pricing model parameters.

[0124] Step 506: Organize the node to build context data for each option pricing and save it to the cache middleware.

[0125] Step 507: The organization node converts the pricing context of each option into the structured input parameters required for pricing.

[0126] Step 508: The organization node sends the pricing library input parameters to the message queue.

[0127] Step 509: The compute node obtains the pricing message.

[0128] Step 510: The computing node performs pricing calculations.

[0129] Step 511: The computing node outputs the pricing result to the message queue.

[0130] Step 512: Organize the node to read the pricing results.

[0131] Step 513: The organization node reads the pricing context from the cache middleware and performs a secondary calculation.

[0132] Step 514: The organization node saves the final pricing result to the cache middleware.

[0133] Step 515: The organization node determines whether all option pricing has ended.

[0134] If the process is not yet complete, proceed to step 512 until all option pricing is finished.

[0135] Step 516: The organization node reads all pricing results from the cache middleware.

[0136] Step 517: The organization node persists the pricing results to the database.

[0137] Step 518, Result.

[0138] Firstly, this application provides a method for organizing the contextual data of over-the-counter option pricing.

[0139] In a conventional single-machine pricing model, after calculating the minimum pricing unit (e.g., the unit option price), secondary processing operations are typically performed within the same process. These operations include price conversion based on the notional principal and initial price of the underlying asset in the option contract definition, currency conversion based on the exchange rate field (e.g., for cross-currency options) in the option contract definition, and conversion based on the option contract type using relevant business rules. Only then can the final result that meets business requirements be obtained. The various field parameters required to generate the minimum pricing unit input parameters, as well as the fields such as the option notional principal, initial price of the underlying asset, exchange rate, and option contract type on which the secondary processing depends, constitute the pricing context. In a distributed pricing model, the computing nodes focus on calculating the minimum pricing unit (e.g., the unit option price), while business-related operations such as price conversion and currency conversion, which depend on the complete contract context, are processed by the organizing nodes after the results are returned, combining the context with the calculations. This achieves complete decoupling between the computational logic and business rules. The pricing context is organized as follows: Retrieve OTC option sub-definition data. In the system, OTC option books are recorded in the form of contracts, which define the underlying asset, effective date, expiration date, notional principal, option type, and the book to which it belongs. Based on pricing needs, select option contracts that require pricing through certain criteria.

[0140] Obtain market data. Based on the underlying asset linked to the OTC option, retrieve the closing price of the underlying asset from the system, and obtain the volatility curve, dividend yield curve, and yield curve corresponding to the option currency as needed for pricing. For cross-currency options, obtain the foreign exchange rate and the correlation coefficient between the underlying asset and the foreign exchange rate.

[0141] Retrieve pricing model parameters. Based on the OTC option type and pricing scenario, query the pricing model parameters configured in the system.

[0142] Constructing pricing context data. Pricing computation nodes are only responsible for the computation of the smallest priced unit. Therefore, the organization node needs to construct the pricing input parameters for this smallest priced unit, which are derived from the pricing context. Assembling the fields required to generate the pricing input parameters (option definition, market data, pricing model parameters, etc.) and the fields required for secondary processing (notional principal, initial price, currency, exchange rate, etc.) together constitutes the context for an option pricing. Further, if stress testing or scenario analysis of the option requires pricing specific pricing parameters under different offset scenarios, the original context data is further derived to obtain the context for the specific scenario (e.g., underlying price offset of 1%, volatility offset of 5%, etc.). The resulting pricing context then serves as a data structure spanning the entire lifecycle of request-computation-result. This is not a simple parameter passing but a distributed computation context management model with externalized state. It ensures that the computation nodes are stateless while supporting complex subsequent result processing, unlike existing technologies that typically maintain the context internally within the computation nodes and couple business processing logic.

[0143] Generate a unique ID for each pricing context, using the ID as the key and the context content as the value, and persist the context to a caching middleware (such as Redis). The pricing context is associated one-to-one with the pricing request and pricing result through the ID, so that it can be read through the ID when performing secondary processing.

[0144] Secondly, the system separates and decouples the two parts of pricing context data organization and management and pricing calculation in the pricing process, and splits them into two modules in the system architecture: organization node and calculation node.

[0145] The organization node reads option definition data, market data, pricing model parameters, etc. to construct a pricing context.

[0146] Next, the organization node generates a unique ID for each piece of context data as a pricing request identifier, and uses this unique ID as the key to cache the context data in the caching middleware. The context data is then converted into the formatted pricing input parameters required by the compute node, and these parameters, along with the pricing request ID, are encapsulated in the body of a pricing request message. This pricing request message is then sent to the message queue. In this step, the pricing request ID is used to associate an option pricing request with its corresponding context data.

[0147] Further, see Figure 6 , Figure 6 This is a schematic diagram of the option pricing process provided in the embodiments of this application. Figure 5The compute node consumes pricing request messages through the message queue, parses the message to obtain a pricing request ID and a pricing request parameter, inputs the pricing request parameter into the pricing calculation function, waits for the calculation to complete, and obtains the pricing calculation result. The pricing calculation result and the pricing request ID are then encapsulated together in a pricing result message body and sent to the message queue. The node then attempts to consume the next pricing request message, and the process repeats.

[0148] Step 601, Begin.

[0149] Step 602: Attempt to read the pricing request message from the message queue.

[0150] Step 603: Determine if the data has been read.

[0151] Step 604: Parse the pricing request message to obtain the pricing request identifier and pricing request context.

[0152] Step 605: Input the pricing request context into the pricing function to execute pricing.

[0153] Step 606: Encapsulate the pricing result and pricing request identifier into a pricing result message and send it to the message queue.

[0154] Further, see Figure 7 , Figure 7 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 6 The organization node consumes pricing result messages through the message queue, parses the message to obtain a pricing request ID and a pricing result output parameter. Using the pricing request ID, it reads the context data corresponding to the pricing result from the caching middleware, and performs subsequent processing on the pricing result based on the context data. For example, it performs secondary calculations on the unit pricing result output by the computing node based on fields such as the notional principal of the option contract and the source of the exchange rate in the context to obtain the final pricing value that meets business expectations. The processed pricing result value is then assembled with the pricing date, pricing scenario, and unique pricing option ID from the pricing context and cached in the caching middleware. The node then attempts to consume the next pricing result message again, and the process repeats.

[0155] Step 701, Begin.

[0156] Step 702: Attempt to read the pricing result message from the message queue.

[0157] Step 703: Determine if the data has been read.

[0158] Step 704: Parse the pricing result message to obtain the pricing request identifier and the first pricing result.

[0159] Step 705: Combine the pricing context to process the pricing result a second time, and obtain the second pricing result.

[0160] Step 706: Save the second pricing result to the cache middleware.

[0161] Step 707: Determine whether the pricing task has been completed.

[0162] Step 708: Read all second pricing results from the cache middleware and save them to the database.

[0163] Step 709, End.

[0164] Furthermore, once all pricing is complete, the organization node reads all pricing results for this batch of tasks from the cache middleware, converts them into the data format required by the database, and saves them to the database in batches.

[0165] Thirdly, the organization and management methods for option pricing batch tasks are explained in detail.

[0166] The first step involves each organizational node providing an interface to initiate a pricing batch task. Once this interface is invoked on any node, preparations begin to trigger the pricing batch task. First, a task context is generated based on the interface request parameters. This context includes the business date of the pricing, the corresponding custom scenario information, etc. Then, option data, market data, etc., are queried according to the input parameter requirements to generate a context for each pricing request. The number of contexts is counted as the total number of pricing requests. The number of successful and failed pricing requests is initialized to 0. The total number of pricing requests, the number of successful pricing requests, and the number of failed pricing requests are then placed into the task context.

[0167] Next, the organization node that initiated the task generates a unique ID for the task context as the task ID, and uses the task ID as the key to save the task context to the cache middleware. When generating a pricing request ID for each subsequent pricing context, the task ID is appended to the pricing request ID, thus establishing the association between each pricing context, pricing request, pricing result, and task, as described above. Figure 3 As shown.

[0168] Furthermore, the organization node sends the pricing request to the message queue, the compute node consumes the pricing request message, completes the pricing calculation, and then sends the pricing result back to the message queue.

[0169] Furthermore, each organizational node consumes pricing result messages from the message queue and parses the task ID from the pricing request ID in the message. After processing the pricing result corresponding to the current message and saving it to the cache middleware, it checks if the pricing result is successful. If so, it increments the number of successful pricing transactions in the task context in the cache middleware by one using the task ID. This step is performed atomically to ensure correct counting when multiple nodes are in parallel. If the pricing result is unsuccessful, it increments the number of unsuccessful pricing transactions in the context by one.

[0170] Furthermore, the organizing node checks if the current number of successful pricing transactions plus the number of failed pricing transactions equals the total number of pricing transactions. If they do not equal, it continues to try consuming the next pricing result message. If they equal, it attempts to preempt a distributed lock corresponding to the task in the caching middleware. If preemption fails, no action is taken. If preemption succeeds, all pricing results for this task are read from the caching middleware, appropriate data transformations are performed, and then the results are saved to the database.

[0171] Furthermore, the organization node checks if the number of failures is 0. If it is not 0, the task status is determined to be failed, and manual intervention is required to analyze the specific reasons for the failure. If the number is 0, the task is determined to be successful. The task status result is recorded in the system, and the task is considered complete.

[0172] Fourthly, a method for heterogeneous parallel pricing calculation of GPU computing nodes and CPU computing nodes is provided.

[0173] The first step is to split the compute nodes into GPU compute nodes and CPU compute nodes. At the code level, aside from the pricing mechanism utilizing GPUs and CPUs respectively, the logic for message parsing and interaction with the message queue remains consistent. These are deployed separately in GPU clusters and CPU clusters. The GPU cluster listens for GPU pricing topics in the message queue, and the CPU cluster listens for CPU pricing topics in the message queue.

[0174] Next, before sending the pricing request message to the message queue, the organization node determines whether the pricing request should be computed using GPU or CPU based on information such as the option type and pricing model parameters in the corresponding context data (for example, pricing using Monte Carlo simulation should use GPU, while pricing that can be solved analytically should use CPU). Pricing requests that should be computed using GPU are sent to the GPU pricing topic, and pricing requests that should be computed using CPU are sent to the CPU pricing topic.

[0175] Furthermore, GPU compute nodes consume pricing requests through the GPU pricing topic, complete the pricing using the GPU, and push the pricing result to the message queue. CPU compute nodes consume pricing requests through the CPU pricing topic, complete the pricing using the CPU, and similarly push the pricing result to the message queue.

[0176] Furthermore, the organization's nodes simultaneously consume pricing results from both GPU and CPU compute nodes via message queues, without needing to identify the node from which the results originated; they can then process them uniformly. The overall process is as follows: Figure 8 As shown, Figure 8 This is a flowchart illustrating the option pricing method provided in the embodiments of this application. Figure 7 .

[0177] Step 801, Begin.

[0178] Step 802: Read the dependency data and build the pricing context.

[0179] Step 803: Determine whether to use GPU pricing.

[0180] Step 804: If yes, send a pricing request to the GPU pricing topic.

[0181] Step 805: GPU node pricing.

[0182] Step 806: If not, send a request to the CPU pricing topic.

[0183] Step 807: CPU node pricing.

[0184] Step 808: The compute node sends the pricing result to the message queue.

[0185] Step 809: Message pricing results, continue processing.

[0186] As can be seen from the above, the option pricing method provided in this application can solve the problems of slow batch pricing calculation speed, poor scalability, insufficient reliability, and single computing core architecture in the original system. The clustered management and distributed pricing of the pricing service enable the system to use server clusters for parallel computing, accelerating the pricing speed. As business volume increases, performance issues can be addressed by increasing the number of servers. By splitting the system into organization nodes and computing nodes, the data organization and processing logic and the computing logic are decoupled, and each node is stateless, allowing each node to support flexible expansion and solving the horizontal scaling problem. Because each node is stateless, and organization nodes and computing nodes interact through reliable message queues, single point of failure is avoided. By utilizing the message queue's message submission and confirmation mechanism, it is ensured that the system will not experience missing pricing data due to the failure of a single node, thereby improving the overall reliability of the system. The distributed computing nodes distribute the server load and also improve the flexibility of the deployment topology, enabling the mixed deployment of CPU and GPU computing nodes, thus solving the problem of a single computing core architecture in the original system, fully utilizing the computing power of different computing resources, and improving pricing efficiency.

[0187] Figure 9 This is a schematic diagram of the structural composition of the option pricing device provided in the embodiments of this application. Figure 1 Applied to the first node, such as Figure 9 As shown, the option pricing device 900 includes: The data construction module 901 is used to construct pricing context data, which includes multiple pricing contexts.

[0188] The data processing module 902 is used to generate multiple pricing request messages based on the multiple pricing contexts; wherein each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context.

[0189] The first data transmission module 903 is used to send the plurality of pricing request messages to a message queue, the message queue being used by a plurality of second nodes to read the plurality of pricing request messages, and the message queue being used to receive a plurality of pricing result messages returned by the plurality of second nodes.

[0190] The data processing module 902 is further configured to read pricing result messages from the message queue multiple times; and perform the following processing on each pricing result message: parse the pricing result message to obtain a first pricing request identifier and a first pricing result; obtain a first pricing context based on the first pricing request identifier; and perform pricing calculation processing on the first pricing result based on the first pricing context to obtain a second pricing result.

[0191] In some embodiments, prior to constructing the pricing context data, the option pricing device 900 further includes a data acquisition module 904.

[0192] The data acquisition module 904 is used to receive a pricing request task, which includes pricing request parameters.

[0193] The data processing module 902 is further configured to generate a task context based on the pricing request parameters, wherein the task context includes a pricing task identifier.

[0194] In some embodiments, the data construction module 901 is further configured to construct the pricing context data based on the task context.

[0195] In some embodiments, the data acquisition module 904 is further configured to acquire over-the-counter option sub-definition data, market data, and pricing model parameters based on the pricing request parameters.

[0196] In some embodiments, the data construction module 901 is further configured to construct the pricing context data based on the OTC option sub-definition data, the market data, and the pricing model parameters. The pricing context data includes the plurality of pricing contexts. The pricing context includes a first field and a second field. The first field includes the parameters required by the second node to calculate the first pricing result, and the second field includes the parameters required by the first node to calculate the second pricing result.

[0197] In some embodiments, the data acquisition module 904 is further configured to acquire the total number of the plurality of pricing contexts to obtain the total number of pricing; In some embodiments, the data processing module 902 is further configured to initialize the number of successful pricing and the number of failed pricing to a first value; and to set the total number of pricing, the number of successful pricing, and the number of failed pricing in the task context.

[0198] In some embodiments, the data processing module 902 is further configured to perform the following processing on each of the pricing contexts: Generate a pricing request identifier corresponding to the pricing context, wherein the pricing request identifier includes a pricing task identifier; The pricing context is stored in a first database using the pricing request identifier. The first database is used to store data generated during the pricing process.

[0199] In some embodiments, the message queue includes a pricing topic, which includes a first pricing topic and a second pricing topic; the second node includes a first type of second node and a second type of second node; the first type of second node is used to read the plurality of pricing request messages within the first pricing topic from the message queue; the second type of second node is used to read the plurality of pricing request messages within the second pricing topic from the message queue.

[0200] In some embodiments, the data processing module 902 is further configured to determine the pricing topic corresponding to each pricing request message based on each pricing context.

[0201] The first data transmission module 903 is further configured to send each of the pricing request messages to the first pricing topic or the second pricing topic in the message queue.

[0202] In some embodiments, after obtaining the second pricing result, the following processing is performed on each of the second pricing results: The data acquisition module 904 is further configured to acquire the first pricing date, the first pricing scenario, and the first pricing option based on the first pricing context; The data processing module 902 is further configured to store the second pricing result, the first pricing date, the first pricing scenario, and the first pricing option into the first database using the first pricing request identifier.

[0203] In some embodiments, the data acquisition module 904 is further configured to obtain a first pricing task identifier from the first pricing request identifier, wherein the first pricing task identifier corresponds to a first pricing task and a first task context.

[0204] In some embodiments, the data processing module 902 is further configured to determine whether the second pricing result is successful. If the pricing is successful, the number of successful pricing corresponding to the first task context is incremented by one through the first pricing task identifier; if it fails, the number of failed pricing in the first task context is incremented by one.

[0205] In some embodiments, the data processing module 902 is further configured to determine whether the sum of the number of successful pricing and the number of failed pricing is equal to the total number of pricing; if not equal, then read the pricing result message from the message queue; if equal, then perform distributed lock preemption processing on the first pricing task based on the first pricing task identifier to obtain a preemption state, the preemption state including a successful preemption state or a failed preemption state.

[0206] In some embodiments, the data processing module 902 is further configured to, if the preemption state is the preemption success state, read all the second pricing results corresponding to the first pricing task from the first database based on the first pricing task identifier; and store all the second pricing results in a second database, the second database being used to store pricing result data after the pricing task is completed.

[0207] In some embodiments, the data processing module 902 is further configured to determine whether the number of pricing failures is a first value; if it is not the first value, the pricing status of the first pricing task is determined to be a pricing failure status; if it is the first value, the pricing status of the first pricing task is determined to be a pricing success status.

[0208] Those skilled in the art should understand that Figure 9 The functions of each unit in the option pricing device shown can be understood by referring to the relevant descriptions of the aforementioned method. Figure 9 The functions of each unit in the option pricing device shown can be implemented by a program running on a processor or by specific logic circuits.

[0209] Figure 10 This is a schematic diagram of the structural composition of the option pricing device provided in the embodiments of this application. Figure 2 Applied to the second node, such as Figure 10 As shown, the option pricing 1000 device includes: The second data transmission module 1001 is used to read a first pricing request message from a message queue. The first pricing request message includes a first pricing context and a first pricing request identifier.

[0210] The data calculation module 1002 is used to perform pricing calculation based on the first pricing context to obtain a first pricing result; and to obtain a first pricing result message based on the first pricing result and the first pricing request identifier.

[0211] The second data transmission module 1001 is further configured to send the first pricing result message to the message queue.

[0212] In some embodiments, the message queue includes a pricing topic, which includes a first pricing topic and a second pricing topic; the types of the second node include a first type of second node and a second type of second node.

[0213] In some embodiments, the second data transmission module 1001 is further configured to: the first type of second node reads the plurality of pricing request messages within the first pricing topic from the message queue; the second type of second node is configured to read the plurality of pricing request messages within the second pricing topic from the message queue.

[0214] Those skilled in the art should understand that Figure 10 The functions of each unit in the option pricing device shown can be understood by referring to the relevant descriptions of the aforementioned method. Figure 10 The functions of each unit in the option pricing device shown can be implemented by a program running on a processor or by specific logic circuits.

[0215] Figure 11 This is a schematic structural diagram of an electronic device 1100 provided in an embodiment of this application. This electronic device is used in the option pricing system provided in this embodiment of the application. The electronic device can be a terminal device or a server. Figure 11 The illustrated electronic device 1100 includes a processor 1110, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0216] Optionally, such as Figure 11 As shown, the electronic device 1100 may further include a memory 1120. The processor 1110 can retrieve and run computer programs from the memory 1120 to implement the methods described in the embodiments of this application.

[0217] The memory 1120 can be a separate device independent of the processor 1110, or it can be integrated into the processor 1110.

[0218] Optionally, such as Figure 11 As shown, the electronic device 1100 may also include a transceiver 1130, and the processor 1110 may control the transceiver 1130 to communicate with other devices. Specifically, it may send information or data to other devices or receive information or data sent by other devices.

[0219] The transceiver 1130 may include a transmitter and a receiver. The transceiver 1130 may further include an antenna, and the number of antennas may be one or more.

[0220] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, 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 the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The 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.

[0221] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The 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. The 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 Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0222] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0223] This application also provides a computer-readable storage medium for storing computer programs.

[0224] Optionally, the computer-readable storage medium can be applied to the network device in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0225] Optionally, the computer-readable storage medium can be applied to the mobile terminal / terminal device in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0226] This application also provides a computer program product, including computer program instructions.

[0227] Optionally, the computer program product can be applied to the network device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0228] Optionally, the computer program product can be applied to the mobile terminal / terminal device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0229] This application also provides a computer program.

[0230] Optionally, the computer program can be applied to the network device in the embodiments of this application. When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0231] Optionally, the computer program can be applied to the mobile terminal / terminal device in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0232] Those skilled in the art will recognize that the units 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.

[0233] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0234] 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 units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units 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 units may be electrical, mechanical, or other forms.

[0235] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0236] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0237] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0238] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An option pricing method, characterized by, Applied to the first node, the method includes: Construct pricing context data, which includes multiple pricing contexts; Multiple pricing request messages are generated based on the multiple pricing contexts; wherein each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context; The multiple pricing request messages are sent to a message queue, which is used by multiple second nodes to read the multiple pricing request messages. The message queue is also used to receive multiple pricing result messages returned by the multiple second nodes. The pricing result message is read from the message queue multiple times, and the following processing is performed on each pricing result message: Parse the pricing result message to obtain the first pricing request identifier and the first pricing result; Obtain the first pricing context based on the first pricing request identifier; Based on the first pricing context, the first pricing result is processed to obtain the second pricing result.

2. The method of claim 1, wherein, Before constructing the pricing context data, the method further includes: Receive a pricing request task, the pricing request task including pricing request parameters; A task context is generated based on the pricing request parameters, and the task context includes a pricing task identifier; Accordingly, the construction of pricing context data includes: Based on the task context, the pricing context data is constructed.

3. The method of claim 2, wherein, The construction of the pricing context data based on the task context includes: Based on the pricing request parameters, obtain the over-the-counter option sub-definition data, market data, and pricing model parameters; Based on the OTC option sub-definition data, the market data, and the pricing model parameters, the pricing context data is constructed, which includes the multiple pricing contexts. The pricing context includes a first field and a second field. The first field includes parameters required by the second node to calculate the first pricing result, and the second field includes parameters required by the first node to calculate the second pricing result.

4. The method of claim 2, wherein, The method further includes: Obtain the total number of the multiple pricing contexts to get the total number of pricing; Initialize the number of successful pricing transactions and the number of failed pricing transactions to the first value; In the task context, set the total number of pricing transactions, the number of successful pricing transactions, and the number of failed pricing transactions.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Perform the following processing for each of the pricing contexts: Generate a pricing request identifier corresponding to the pricing context, wherein the pricing request identifier includes a pricing task identifier; The pricing context is stored in a first database using the pricing request identifier. The first database is used to store data generated during the pricing process.

6. The method according to any one of claims 1 to 4, characterized in that, The message queue includes a pricing topic, which includes a first pricing topic and a second pricing topic; the second node includes a first type of second node and a second type of second node. The first type of second node is used to read the plurality of pricing request messages within the first pricing topic from the message queue; The second type of second node is used to read multiple pricing request messages from the second pricing topic within the message queue; Sending the plurality of pricing request messages to the message queue includes: Based on each of the pricing contexts, determine the pricing topic corresponding to each of the pricing request messages; Each of the pricing request messages is sent to the first pricing topic or the second pricing topic in the message queue.

7. The method according to any one of claims 1 to 4, characterized in that, After obtaining the second pricing result, the method further includes: For each of the second pricing results, perform the following processing: Based on the first pricing context, obtain the first pricing date, the first pricing scenario, and the first pricing option; The second pricing result, the first pricing date, the first pricing scenario, and the first pricing option are stored in the first database using the first pricing request identifier.

8. The method according to claim 7, characterized in that, The method further includes: Obtain the first pricing task identifier from the first pricing request identifier, wherein the first pricing task identifier corresponds to the first pricing task and the first task context; Determine whether the second pricing result is successful. If the pricing is successful, increment the number of successful pricing corresponding to the first task context by one using the first pricing task identifier; if it fails, increment the number of failed pricing within the first task context by one.

9. The method according to claim 8, characterized in that, The method further includes: Determine whether the sum of the number of successful pricing transactions and the number of failed pricing transactions equals the total number of pricing transactions; If they are not equal, then the pricing result message is read from the message queue again; If equal, then the first pricing task is preempted using a distributed lock based on the first pricing task identifier to obtain a preemption state, which includes a successful preemption state or a failed preemption state.

10. The method according to claim 9, characterized in that, The method further includes: If the preemption status is the preemption success status, then all second pricing results corresponding to the first pricing task are read from the first database based on the first pricing task identifier; All the second pricing results are stored in a second database, which is used to store pricing result data after the pricing task is completed.

11. The method according to claim 8, characterized in that, The method further includes: Determine whether the number of pricing failures is a first value. If it is not the first value, determine that the pricing status of the first pricing task is a pricing failure status; if it is the first value, determine that the pricing status of the first pricing task is a pricing success status.

12. An option pricing method, characterized in that, Applied to the second node, the method includes: Read a first pricing request message from the message queue. The first pricing request message includes a first pricing context and a first pricing request identifier. Based on the first pricing context, a pricing calculation is performed to obtain a first pricing result; Based on the first pricing result and the first pricing request identifier, a first pricing result message is obtained; Send the first pricing result message to the message queue.

13. The method according to claim 12, characterized in that, The message queue includes a pricing topic, which includes a first pricing topic and a second pricing topic; the second node includes first type second nodes and second type second nodes; reading the first pricing request message from the message queue includes: The first type of second node reads the plurality of pricing request messages within the first pricing topic from the message queue; The second node of the second type reads the plurality of pricing request messages within the second pricing topic from the message queue.

14. An option pricing system, characterized in that, The option pricing system includes a first node and multiple second nodes; wherein... The first node is used to construct pricing context data, which includes multiple pricing contexts; generate multiple pricing request messages based on the multiple pricing contexts; wherein each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context; and send the multiple pricing request messages to a message queue, which is used by multiple second nodes to read the multiple pricing request messages, and the message queue is also used to receive multiple pricing result messages returned by the multiple second nodes. Each second node is configured to read a first pricing request message from the message queue, the first pricing request message including a first pricing context and a first pricing request identifier; perform pricing calculation based on the first pricing context to obtain a first pricing result; obtain a first pricing result message based on the first pricing result and the first pricing request identifier; and send the first pricing result message to the message queue. The first node is further configured to read pricing result messages from the message queue multiple times, and perform the following processing on each pricing result message: parse the pricing result message to obtain a first pricing request identifier and a first pricing result; obtain a first pricing context based on the first pricing request identifier; and perform pricing calculation processing on the first pricing result based on the first pricing context to obtain a second pricing result.

15. The system according to claim 14, characterized in that, The message queue includes a pricing topic, which includes a first pricing topic and a second pricing topic; the second node includes a first type of second node and a second type of second node. The first type of second node reads the plurality of pricing request messages within the first pricing topic from the message queue; The second node of the second type reads the plurality of pricing request messages within the second pricing topic from the message queue.

16. An option pricing device, characterized in that, Applied to the first node, the device includes: The data construction module is used to construct pricing context data, which includes multiple pricing contexts; The data processing module is used to generate multiple pricing request messages based on the multiple pricing contexts; wherein each pricing request message includes each pricing context and a pricing request identifier corresponding to each pricing context; The first data transmission module is used to send the plurality of pricing request messages to a message queue, the message queue is used by a plurality of second nodes to read the plurality of pricing request messages, and the message queue is also used to receive a plurality of pricing result messages returned by the plurality of second nodes; The data processing module is further configured to read pricing result messages from the message queue multiple times; and perform the following processing on each pricing result message: parse the pricing result message to obtain a first pricing request identifier and a first pricing result; obtain a first pricing context based on the first pricing request identifier; and perform pricing calculation processing on the first pricing result based on the first pricing context to obtain a second pricing result.

17. An option pricing device, characterized in that, Applied to the second node, the device includes: The second data transmission module is used to read a first pricing request message from a message queue. The first pricing request message includes a first pricing context and a first pricing request identifier. The data calculation module is used to perform pricing calculation based on the first pricing context to obtain a first pricing result; and to obtain a first pricing result message based on the first pricing result and the first pricing request identifier. The second data transmission module is further configured to send the first pricing result message to the message queue.

18. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 13.

19. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method described in any one of claims 1 to 13.

20. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method according to any one of claims 1 to 13.

Images