System and method for coordinating atomic processing of dependent data transactions in a distributed computing environment

Abstract

A coordination engine facilitates the execution of composite atomic tasks (CATs) in a distributed computing environment. The coordination engine receives CAT requests comprising independent and dependent tasks and queries additional nodes to determine their participation. Based on node responses, the coordination engine allocates tasks entirely to secondary nodes or distributes portions between secondary and additional nodes. If only part of a CAT request is assumed, tasks are divided accordingly. Unallocated portions are deleted to maintain execution consistency. The coordination engine validates task allocations across nodes, ensuring execution dependencies are intact. If execution conflicts arise, the coordination engine may initiate reprocessing to resolve them. Upon successful execution and validation, the coordination engine confirms atomic task completion, ensuring that all execution dependencies have been satisfied.

Description

SYSTEM AND METHOD FOR COORDINATING ATOMIC PROCESSING OF DEPENDENT DATA TRANSACTIONS IN A DISTRIBUTED COMPUTING ENVIRONMENTCross Related Application

[0001] The present specification claims priority from Canadian patent application 3232530, filed March 14, 2024, the entire contents of which are incorporated herein by reference.Field

[0002] The present disclosure relates generally to distributed computing environments and more particularly relates to a system and method for coordinating atomic processing of dependent data transactions in a distributed computing environment.Background

[0003] Distributed computing environments often involve processing multiple interdependent data transactions across various nodes, creating challenges in ensuring atomic execution, minimizing latency, and managing resource allocation efficiently. Traditional approaches to handling such transactions frequently rely on manual intervention or sequential processing, which can increase execution times and lead to inconsistencies or conflicts between related tasks. Additionally, existing methods may struggle to maintain synchronization and coherence across distributed nodes, especially when transactions must be processed concurrently. Addressing these issues requires a mechanism that can dynamically manage dependencies, validate resource availability, and coordinate task execution efficiently.Summary

[0004] An aspect of the specification provides a computer-implemented method for coordinating atomic processing of dependent data transactions in a distributed computing environment, the method including: (a) receiving a composite atomic task (CAT) request from a secondary node, the CAT request including an independent task and a dependent task; the independent taskoriginating from a primary node to the secondary node; (b) querying additional nodes for participation in the CAT request; (c) determining if one or more additional nodes agree to assume part of the CAT request; (d) if none of the additional nodes agree to assume part of the CAT request: (i) allocating the CAT to the secondary node; and (ii) allocating the independent task from the CAT to the secondary node; (e) if at least one additional node agrees to assume part of the CAT request, determining if the additional nodes agree to assume all of the CAT request; (f) if all of the CAT request is assumed by the additional nodes: (i) allocating the entire CAT to the additional nodes; (ii) allocating the independent task from the CAT to the additional nodes; and (iii) allocating the dependent task from the CAT to the additional nodes; (g) if only a part of the CAT request is assumed by the additional nodes: (i) allocating a first portion of the CAT to the additional nodes; (ii) allocating a second portion of the CAT to the secondary node; (iii) allocating a first portion of the independent task from the CAT to the additional nodes; (iv) allocating a second portion of the independent task from the CAT to the secondary node; (v) allocating a first portion of the dependent task from the CAT to the additional nodes; and (vi) allocating a second portion of the dependent task from the CAT to the secondary node; (h) deleting any unallocated portions of the CAT request; (i) validating task allocations across nodes to ensure execution dependencies are intact.

[0005] An aspect of the specification provides a method, wherein querying additional nodes for participation in the CAT request includes transmitting a capability query to each additional node, the capability query including execution parameters, resource requirements, and task dependencies associated with the CAT request.

[0006] An aspect of the specification provides a method, wherein determining if one or more additional nodes agree to assume part of the CAT request includes evaluating responses based on predefined thresholds for resource availability, processing capacity, and latency constraints.

[0007] An aspect of the specification provides a method, wherein validating task allocations across nodes includes generating a validation log that tracks task allocation status, execution timestamps, and dependency fulfillment for each node involved in processing the CAT request.

[0008] An aspect of the specification provides a method, further including, prior to deleting unallocated portions of the CAT request, transmitting a reallocation request to the secondary nodeto determine if the secondary node can assume execution of the unallocated portions based on updated resource availability.

[0009] An aspect of the specification provides a method, wherein: the primary node includes a client terminal associated with a market participant; the secondary node includes an administrator terminal associated with a dealer; and the additional nodes include execution engines associated with market makers, wherein receiving the CAT request from the secondary node includes receiving a task request to coordinate execution of a trade involving both an independent task associated with an options exchange and a dependent task associated with a stock exchange.

[0010] An aspect of the specification provides a method, wherein: the market participant initiates with a trade order for an options contract from the client terminal; the dealer, via the administrator terminal, generates a corresponding CAT request that associates at least a portion of the options contract with the underlying stock according to a strategy; the execution engines associated with the market makers are queried to determine if they will assume execution of part or all of the independent and dependent tasks.

[0011] An aspect of the specification provides a method, wherein the independent task includes executing a trade for an options contract on a primary module configured as an options exchange, and the dependent task includes executing a trade for the underlying stock on a secondary module configured as a stock exchange, wherein validating task allocations across nodes ensures that execution dependencies between the options contract and the underlying stock trade are satisfied.

[0012] An aspect of the specification provides a method, wherein receiving the CAT request from the secondary node includes: (a) constructing the CAT request based on a predefined strategy that specifies: (i) an independent task defining execution parameters for a primary trade involving an options contract, including contract type, strike price, expiration, and quantity; and (ii) a dependent task defining execution parameters for a secondary trade involving an underlying stock, including stock symbol, quantity, and hedge ratio; (b) determining execution dependencies between the independent task and the dependent task based on the predefined strategy, wherein execution of the dependent task is contingent upon parameters derived from the execution of the independent task; and (c) associating the predefined strategy with a task integrity parameter that enforces atomic execution of the independent and dependent tasks, such that either all tasks are executedsuccessfully or none are executed, thereby ensuring consistency across the distributed computing environment.

[0013] An aspect of the specification provides a coordination engine for coordinating atomic processing of dependent data transactions in a distributed computing environment, the coordination engine including processor for executing a aggregation module configured to (a) receive a composite atomic task (CAT) request from a secondary node, the CAT request including an independent task and a dependent task; the independent task originating from a primary node to the secondary node; (b) query additional nodes for participation in the CAT request; (c) determine if one or more additional nodes agree to assume part of the CAT request; (d) if none of the additional nodes agree to assume part of the CAT request: (i) allocate the CAT to the secondary node; and (ii) allocate the independent task from the CAT to the secondary node; (e) if at least one additional node agrees to assume part of the CAT request, determining if the additional nodes agree to assume all of the CAT request; (f) if all of the CAT request is assumed by the additional nodes: (i) allocate the entire CAT to the additional nodes; (ii) allocate the independent task from the CAT to the additional nodes; and (iii) allocate the dependent task from the CAT to the additional nodes; (g) if only a part of the CAT request is assumed by the additional nodes: (i) allocate a first portion of the CAT to the additional nodes; (ii) allocate a second portion of the CAT to the secondary node; (iii) allocate a first portion of the independent task from the CAT to the additional nodes; (iv) allocate a second portion of the independent task from the CAT to the secondary node; (v) allocate a first portion of the dependent task from the CAT to the additional nodes; and (vi) allocate a second portion of the dependent task from the CAT to the secondary node; (h) delete any unallocated portions of the CAT request; (i) validate task allocations across nodes to ensure execution dependencies are intact.

[0014] An aspect of the specification provides a coordination engine claim 1 , wherein the query of additional nodes for participation in the CAT request includes transmitting a capability query to each additional node, the capability query including execution parameters, resource requirements, and task dependencies associated with the CAT request.

[0015] An aspect of the specification provides a coordination engine claim 1, wherein the determining if one or more additional nodes agree to assume part of the CAT request includesevaluating responses based on predefined thresholds for resource availability, processing capacity, and latency constraints.

[0016] An aspect of the specification provides a coordination engine claim 1, wherein the validating task allocations across nodes includes generating a validation log that tracks task allocation status, execution timestamps, and dependency fulfillment for each node involved in processing the CAT request.

[0017] An aspect of the specification provides a coordination engine claim 1, wherein the processor is further configured to, prior to deleting unallocated portions of the CAT request, transmit a reallocation request to the secondary node to determine if the secondary node can assume execution of the unallocated portions based on updated resource availability.

[0018] An aspect of the specification provides a coordination engine, wherein: the primary node includes a client terminal associated with a market participant; the secondary node includes an administrator terminal associated with a dealer; and the additional nodes include execution engines associated with market makers, wherein the CAT request from the secondary node includes a task request to coordinate execution of a trade involving both an independent task associated with an options exchange and a dependent task associated with a stock exchange.

[0019] An aspect of the specification provides a coordination engine, wherein: the market participant initiates with a trade order for an options contract from the client terminal; the dealer, via the administrator terminal, generates a corresponding CAT request that associates at least a portion of the options contract with the underlying stock according to a strategy; the execution engines associated with the market makers are queried to determine if they will assume execution of part or all of the independent and dependent tasks.

[0020] An aspect of the specification provides a coordination engine, wherein the independent task includes executing a trade for an options contract on a primary module configured as an options exchange, and the dependent task includes executing a trade for the underlying stock on a secondary module configured as a stock exchange, wherein validating task allocations across nodes ensures that execution dependencies between the options contract and the underlying stock trade are satisfied.

[0021] An aspect of the specification provides a coordination engine, wherein receiving the CAT request from the secondary node includes: (a) constructing the CAT request based on a predefined strategy that specifies: (i) an independent task defining execution parameters for a primary trade involving an options contract, including contract type, strike price, expiration, and quantity; and (ii) a dependent task defining execution parameters for a secondary trade involving an underlying stock, including stock symbol, quantity, and hedge ratio; (b) determining execution dependencies between the independent task and the dependent task based on the predefined strategy, wherein execution of the dependent task is contingent upon parameters derived from the execution of the independent task; and (c) associating the predefined strategy with a task integrity parameter that enforces atomic execution of the independent and dependent tasks, such that either all tasks are executed successfully or none are executed, thereby ensuring consistency across the distributed computing environment.An aspect of the specification provides a computer readable medium 1-9.Brief Description of the Figures

[0022] The present specification includes the attached Figures, in which:

[0023] Figure 1 shows a system for coordinating processing of dependent data transactions in a distributed computing environment.

[0024] Figure 2 shows a schematic diagram of a non-limiting example of internal components of the a coordination engine of Figure 1.

[0025] Figure 3 shows a schematic diagram of a non-limiting example of a stack of components associated with the coordination engine of Figure 2.

[0026] Figure 4 shows a flowchart depicting a method for processing of dependent data transactions in a distributed computing environment.

[0027] Figure 5 shows a flowchart depicting another method for processing of dependent data transactions in a distributed computing environment.

[0028] Figure 6 shows a flowchart depicting another method for processing of dependent data transactions in a distributed computing environment.

[0029] Figure 7 is a diagram of an example computer system according to the present disclosure.

[0030] Figure 8 is a schematic diagram of the computer system of Figure 7 showing example flows for a riskless-trade-on-option instrument.

[0031] Figure 9 is a schematic diagram of the computer system of Figure 7 showing example flows with call options.

[0032] Figure 10 is a schematic diagram of the computer system of Figure 7 showing example flows for with put options.

[0033] Figure 11 is a signal diagram showing example data messages to enable the example riskless-trade-on-option instrument of Figure 8.

[0034] Figure 12 is a signal diagram showing example data messages for covered- with-stock trades without the riskless-trade-on-option instrument of Figure 8.

[0035] Figure 13 is a flow diagram with tables of example data for trades with and without the example riskless-trade-on-option instrument of Figure 8.

[0036] Figure 14 is a flowchart of an example method for covered-with-stock trading after market close.Detailed Description

[0037] Figure 1 illustrates a system for coordinating processing of dependent data transactions in a distributed computing environment, indicated generally as system 100. System 100 comprises a plurality of adaptive data matching engines 104-1, 104-2, ... 104-n (collectively referred to as engines 104 and generically as engine 104). In system 100, engines 104 connect to a network 108, which may be the Internet, a private data network, or a dedicated communication infrastructure.Network 108 interconnects engines 104 with a plurality of client terminals 116, at least one administrator terminal 118, and a coordination engine 102.

[0038] Each client terminal 116 corresponds to a distinct user 124 interacting with system 100. An identifier object 128 associates each user 124 with their respective client terminal 116, enabling secure and personalized interactions with system 100. Users 124 may submit dependent task requests, monitor task execution, interact with task workflows, and receive finalized outputs. Similarly, each administrator terminal 118 corresponds to a system administrator 126, with an identifier object 132 linking administrator 126 to terminal 118. Administrator 126 may configure execution policies, monitor and, where applicable, manage execution responses, and oversee system- wide execution dependencies.

[0039] Coordination engine 102 coordinates the execution of interdependent tasks across multiple computing nodes, resolving execution dependencies, maintaining atomicity, and preventing conflicting states. Coordination engine 102 comprises a primary module 224-1, a secondary module 224-2, an aggregation module 224-3, and one or more additional modules 224-q. These modules facilitate task execution sequencing, resolution of execution conflicts, and transaction finalization within system 100.

[0040] Engines 104 process execution requests, respond to interdependent computations, and dynamically adjust execution conditions to maintain processing continuity. Each engine 104 may be a specialized processing node, a data synchronization service, or a distributed execution engine, depending on system configuration. These engines 104 receive dependent task requests, determine response parameters based on system state, and return computed outputs to engine 102.

[0041] Network 108 serves as the communication infrastructure linking client terminals 116, administrator terminals 118, coordination engine 102, and engines 104. The infrastructure of network 108 supports real-time data synchronization, request propagation, and execution coordination among the system components, as will be discussed in greater detail below.

[0042] Each client terminal 116 provides a node to initiate, monitor, and interact with task execution workflows, to submit dependent task requests that require coordinated processing acrosssystem 100, and to receive finalized outputs. Each identifier object 128 ensures that user requests and preferences are maintained securely, enabling authentication and access control.

[0043] Each administrator terminal 118 provides a node to respond to dependent task requests, to manage execution, and to receive, validate, and coordinate execution responses to dependent task requests from client terminals 116. Administrator terminals 118 further support the configuration of execution policies, the management of execution conditions, and the resolution of processing conflicts where necessary. Each identifier object 132 associates a respective administrator 126 with a corresponding administrator terminal 118, enabling authentication, access control, and secure administrative interactions.

[0044] System 100 is designed to support distributed, multi-node execution of interdependent tasks, ensuring that all related computations are processed atomically and in a consistent manner. Aggregation module 224-3, in particular, plays a key role in ensuring proper synchronization of dependent task executions, as will be described in greater detail with respect to Figure 4.

[0045] Having described an overview of system 100, it is useful to comment on the hardware infrastructure of system 100. Figure 2 shows a schematic diagram of a non-limiting example of internal components of coordination engine 102. Engine 102 can include at least one input device 204. Input device 204 may include traditional input mechanisms like keyboards or mice. Output device 212 may be a display or could be a speaker for providing real-time feedback.

[0046] Processor 208 may be implemented as a plurality of processors, one or more multi-core processors, field programmable gate arrays (FPGAs) or specialized hardware accelerators, such as Graphics Processing Units (GPUs), Tensor Processing Units (TPUs), or similar parallel processing units optimized for handling large-scale data and / or complex machine learning models. In certain embodiments, processor 208 may include a memory-centric or near-memory compute architecture, where processing elements are co-located with memory cells to minimize data transfer latency and power consumption, which is beneficial for applications involving high-speed inference. Processor 208 may be configured to execute different programming instructions, including those optimized for Al and machine learning tasks, responsive to input received via one or more input devices 204 and to control one or more output devices 212 to generate output on those devices.

[0047] To fulfill its programming functions, processor 208 is configured to communicate with one or more memory units, including non-volatile memory 216 and volatile memory 220. Non-volatile memory 216 can be based on any persistent memory technology, such as an Erasable Electronic Programmable Read-Only Memory (“EEPROM”), flash memory, solid-state hard disk (SSD), other types of hard disks, or combinations thereof. In embodiments using a memory-centric architecture, memory 216 may include processing units embedded within or adjacent to memory cells to reduce latency and improve energy efficiency in data handling, supporting high- performance inference tasks. Non-volatile memory 216 may also be described as a non-transitory computer-readable medium, with multiple types of non-volatile memory 216 provided as needed.

[0048] Volatile memory 220 can be based on any random access memory (RAM) technology, such as Double Data Rate (DDR) Synchronous Dynamic Random-Access Memory (SDRAM). In certain embodiments, volatile memory 220 may incorporate high-speed, low-latency configurations, supporting rapid data access and processing required for real-time inference tasks. Other types of volatile memory 220, such as Low-Power DDR (LPDDR) or High-Bandwidth Memory (HBM), are also contemplated to optimize performance in high-computation environments.

[0049] Processor 208 also connects to network 108 via a network interface 232. As noted, network interface 232 can also be used to connect another computing device that has an input and output device (e.g. administrator terminal 118), thereby obviating the need for input device 204 and / or output device 212 altogether. The network interface 232 facilitates the transmission of interaction data streams from dynamic transaction management engines 104, client terminals 116, and administrator terminal 118 via network 108, enabling real-time adjustments to engine 102 based on evolving interaction sequences.

[0050] Programming instructions in the form of software modules 224 are typically maintained, persistently, in non-volatile memory 216 and used by the processor 208 which reads from and writes to volatile memory 220 during the execution of software modules 224. Various methods discussed herein can be coded as one or more software modules 224. One or more tables or databases 228 are maintained in non-volatile memory 216 for use by software modules 224. Software modules 224 may include execution logic for distributed transactions, real-timecoordination of dependent tasks, synchronization management, and execution prioritization. Databases 228 may store execution logs, state dependencies, transactional data, and historical processing records. Software modules 224 also include executable code for the various methods, and their variants, described herein. Databases 228 may store execution logs, transaction records, processing history, and other structured data relevant to distributed execution workflows.

[0051] The infrastructure of engine 102, or a variant thereon, can be used to implement any of the computing nodes in system 100, including dynamic transaction management engines 104, and client terminals 116.

[0052] By the same token, a plurality of engine 102 may be provided. Overall, the engines 104 and / or engine 102 and other nodes in system 100 may be implemented using cloud computing platforms such as Microsoft Azure™ or Amazon Web Services (AWS)™.

[0053] A person of skill in the art will recognize that the core elements of processor 208, input device 204, output device 212, non-volatile memory 216, volatile memory 220 and network interface 232, as described in relation to the server environment of engine 102, have analogues in the different form factors of client machines such as those that can be used to implement client terminals 116, administrator terminal 118 and engines 104. Furthermore, one or more of the nodes in system 100 (e.g. engine 102, engines 104, including the processing units of client terminals 116 and / or administrator terminals 118) may also be implemented as virtual machines and / or with mirror images to provide load balancing.

[0054] Figure 3 provides a schematic representation of engine 102, illustrating the detailed view of a stack 300 employed in the computing environment of engine 102. Stack 300 depicts the different layers involved in the operation of engine 102, from the application layer 304 down to the physical hardware layer 340.

[0055] At the highest level, the application layer 304 encompasses various modules 224 and application frameworks 308. Software modules 224 include executable code for distributed transaction processing, interdependent task execution, and real-time data coordination. Application frameworks 308 provide libraries and tools that facilitate the development and execution of these software modules.

[0056] Beneath the application layer is the middleware layer 312, which includes tables 228 and other middleware components. Middleware 312 serves as an intermediary, providing essential services like state synchronization, data transaction logging, and execution dependency resolution. Examples of middleware include database management systems, messaging queues, and distributed ledger components that facilitate interaction between various elements of system 100.

[0057] The operating system layer 316 consists of the operating system 320 and kernel 324. The operating system 320 manages hardware resources and provides foundational services to modules 224, while the kernel 324 handles core system operations, facilitating efficient communication between hardware and software components.

[0058] The hardware abstraction layer 328 includes drivers 332 and firmware 336. Drivers 332 allow the operating system 320 and other software to communicate with hardware devices shown in Figure 2, such as input device 204, output device 212, and network interface 232. Firmware 336 enables low-level control of the hardware components in the physical hardware layer 340, facilitating execution stability, device compatibility, and secure interactions between software and hardware components.

[0059] At the base of the stack is the hardware and physical layer 340 of engine 102, which encompasses physical components like the input device 204, processor 208, non-volatile memory 216, volatile memory 220, and network interface 232. This layer provides the processing power, memory, and network infrastructure required for high-throughput execution workflows, state coordination, and multi-node task execution.

[0060] Stack 300 illustrates how the different layers interact within the computing environment of engine 102, enabling the execution of dependent task requests, resolution of execution conflicts, and management of interdependent processing workflows. Each layer is interdependent, relying on the services and capabilities of the layer below it, forming a cohesive system that supports adaptive data matching engines 104, client terminals 116, and administrator terminals 118 within system 100.

[0061] The stack 300 in Figure 3 is adaptable across various computing environments, including server infrastructures for adaptive data matching engines 104, client terminals 116, andadministrator terminals 118. Whether implemented in a traditional server environment or as virtual machines on cloud platforms like Microsoft Azure™ or Amazon Web Services™ (AWS), the described layers of stack 300 provide a framework for distributed execution workflows, transactional integrity, and execution state management.

[0062] Figure 4 shows a flowchart depicting a method for coordinating the atomic processing of dependent data transactions in a distributed computing environment, indicated generally at 400. Method 400 can be implemented on system 100, though persons skilled in the art may implement variations thereof, including omitting certain blocks, performing steps in parallel, or reordering the sequence based on system configurations. For explanatory purposes, method 400 is described in the context of system 100, where it operates as, for example, an aggregation module application 224-3 maintained within coordination engine 102, interacting with other system nodes as illustrated in Figure 1.

[0063] Block 404 comprises receiving a dependent task request. To elaborate, block 404 involves coordination engine 102 receiving a request that requires execution with respect to other related computations. A dependent task request may originate from a client terminal 116, an administrator terminal 118, or from an adaptive data matching engine 104. Each request includes execution parameters, data dependencies, and contextual information required for coordinated execution.

[0064] Block 408 comprises validating execution dependencies. In this step, coordination engine 102 assesses the received request to determine whether it has explicit dependencies on other ongoing or pending computations. Dependencies may include sequential task execution constraints, resource availability conditions, or interrelated data states. If the dependencies involve other transactions or task states maintained in system 100, execution validation may involve querying databases 228 to retrieve state consistency information.

[0065] Block 412 comprises determining whether execution dependencies are valid. Coordination engine 102 assesses whether the dependencies identified in block 408 allow for successful execution of the dependent task request. If dependencies are valid, method 400 proceeds to block 420. If dependencies are not valid or result in conflicts, method 400 transitions to block 416 to resolve conflicts before proceeding.

[0066] Block 416 comprises resolving conflicts. If execution dependencies from block 412 indicate conflicts, coordination engine 102 applies resolution mechanisms, such as reordering execution sequences, applying conflict mitigation rules, or invoking administrative intervention via administrator terminals 118. Resolution strategies may involve reassigning priority levels to pending executions, enforcing transaction locks, or retrying execution in a later processing cycle.

[0067] Block 420 comprises determining execution priority. Once dependencies are validated and any conflicts are resolved, coordination engine 102 assigns an execution priority level to the dependent task request. Execution priority may be determined based on predefined scheduling rules, real-time system load balancing constraints, or specific attributes associated with the request. Requests with lower latency requirements or system-defined priority markers may be escalated in execution order.

[0068] Block 424 comprises sending a dependent task request. In this step, coordination engine 102 dispatches the validated and prioritized dependent task request for execution. The task request may be transmitted to one or more adaptive data matching engines 104, another coordination engine 102 instance, or external computing nodes interfacing with system 100. Communication may occur over network 108 using system-defined message formats or standardized application programming interface (API) protocols.

[0069] Block 428 comprises receiving dependent task responses. Following execution of the dispatched request in block 424, coordination engine 102 collects responses from the executing nodes. Responses may include execution results, status updates, or error indicators. Coordination engine 102 evaluates these responses to determine whether execution was completed successfully or if additional intervention is required.

[0070] Block 432 comprises determining whether task execution was successful. Coordination engine 102 evaluates execution responses received in block 428 to determine if the dependent task request was executed as intended. If execution is unsuccessful, method 400 transitions to block 416 to resolve conflicts and potentially retry execution. If execution is successful, method 400 proceeds to block 436.

[0071] Block 436 comprises confirming atomic task completion. In this step, coordination engine 102 verifies that all required task dependencies have been fully resolved and that execution results are consistent with system-wide state integrity. This may involve cross-verifying execution logs stored in databases 228 or reconciling results with prior computations.

[0072] Block 440 comprises committing the final state across nodes. Once atomic execution is confirmed in block 436, coordination engine 102 updates global state information across all relevant system nodes. This ensures that system 100 maintains a consistent execution history and that no partial or conflicting states persist in distributed execution environments. Committing the final state may involve updating tables 228, notifying dependent systems, or logging results for auditability.

[0073] The foregoing general description applies to various environments. For example, coordination engine 102 can be implemented as a transactional execution engine where primary module 224-1 governs primary execution workflows, and secondary module 224-2 manages conditional execution constraints. In this example, client terminals 116 can be used by general system users, while administrator terminals 118 facilitate execution oversight, ensuring that dependent execution requests comply with system-imposed policies. Execution workflows within system 100 may be further supported by distributed transaction engines 104, which operate as autonomous processing entities capable of participating in transactions between client terminals 116, administrator terminals 118 and coordination engine 102. These engines 104 may interact with coordination engine 102 to facilitate the resolution of distributed transactions, contribute to execution scalability, and support system-wide transaction coordination. Depending on system configuration, engines 104 may respond to execution requests, validate transaction dependencies, or provide state updates that inform coordinated task processing.

[0074] As a specific example, coordination engine 102 can be a trading engine where primary module 224-1 is electronic trading platform for trading securities and where secondary module 224-2 is an electronic trading platform for trading options or derivatives that are based on underlying securities available on primary module 224-1. In this example, client terminals 116 can be used by market participant users 124, while administrator terminal 118 can be used by dealer administrators 126, and engines 104 can be provided by market makers.

[0075] (In some implementations, coordination engine 102 may itself be distributed across multiple instances, where one instance executes primary module 224-1, a second instance executes secondary module 224-2, and a third instance executes aggregation module 224-3. These instances may be deployed virtually or as dedicated hardware nodes, operating in parallel or as needed to support execution workloads. Various configurations are contemplated, including subsets of these instances or alternative distributions of software modules 224 across separate execution environments, depending on system architecture. As a specific example, primary module 224-1 may be a securities exchange, secondary module 224-2 may be an options exchange while 224-3 executes independently or local to either primary module 224-1 or secondary module 224-2.)

[0076] Thus, block 404 comprises receiving, from, for example, terminal 116-1, a request for execution that is dependent on the successful completion of a prerequisite task, where execution feasibility is determined based on system constraints and execution policies. As a specific example, coordination engine 102 can be a trading engine where primary module 224-1 operates as an electronic trading platform for trading securities, and secondary module 224-2 operates as an electronic trading platform for trading options or derivatives that are based on underlying securities available on primary module 224- 1.

[0077] For instance, a market participant user 124, using client terminal 116-1, submits an order to buy a call option contract for a security. This order is transmitted to coordination engine 102, which processes the request by assessing execution dependencies. As part of execution validation (block 408), coordination engine 102 determines that the options trade requires establishing a hedge position in the underlying stock. In response, the order is routed to dealer administrator 126, who assesses execution feasibility and determines whether to take the other side of the trade while managing risk exposure.

[0078] If the dealer administrator 126 accepts the trade, coordination engine 102 determines execution priority (block 420) based on factors such as market conditions, pricing algorithms, and trade sequencing rules. Dealer administrator 126 may establish a hedge position in the underlying security on primary module 224-1 before allowing the option trade to proceed on secondary module 224-2. The dependent option trade is then sent for execution (block 424), where it may be fully or partially filled by market maker systems 104. Market makers 104 evaluate the bid-offerspread and determine order fulfillment based on available liquidity. If a market maker 104 participates, it may assume part or all of the option position, and coordination engine 102 updates execution records accordingly.

[0079] Figure 5 shows a flowchart depicting a method for coordinating the atomic processing of dependent data transactions in a distributed computing environment, indicated generally at 4000. Method 4000 can be implemented on system 100, though persons skilled in the art may implement variations thereof, including omitting certain blocks, performing steps in parallel, or reordering the sequence based on system configurations.

[0080] For explanatory purposes, method 4000 is described in the context of system 100, where it operates as, for example, an aggregation module application 224-3 maintained within coordination engine 102, interacting with other system nodes as illustrated in Figure 1. Furthermore, method 4000 contemplates the processing of a composite atomic task request (CAT), which includes a combination of an independent task that is performed by primary module 224- 1 and a dependent task that is performed by secondary module 224-2

[0081] Block 4004 comprises receiving a Composite Atomic Task (CAT) Request from a secondary node. The request may originate from various nodes in system 100 and includes execution parameters, task dependencies, and contextual information necessary for coordinated execution. In an example embodiment, block 4004 involves the aggregation module 224-3 receiving a request that specifies both an independent task and a dependent task from administrator 126 that require coordinated execution. The independent task typically arises from an initial message (not shown in method 4000) from, for example, client terminal 116-1 to administrator terminal 118-1, for an independent task to be performed on primary module 224-1. The administrator terminal 118-1 then generates a corresponding dependent task involving secondary module 224-2, which is combined into the CAT request.

[0082] Block 4008 comprises querying additional nodes for participation in the CAT request. In a present embodiment, block 4008 involves the coordination engine 102 transmitting queries to engines 104 to assess their capacity to execute portions of the CAT request. The query may include information about the independent task for primary module 224-1 and the dependent task for secondary module 224-2.

[0083] Block 4012 comprises determining whether additional nodes are assuming part of the request. In an example embodiment, the additional nodes are engines 104. Block 4012 thus involves the coordination engine 102 assessing responses from engines 104 to determine if one or more of engines 104 will take on parts of the CAT request. If additional nodes send signals agreeing to participate, the method proceeds to the decision at block 4024; otherwise, a “no” determination is made at block 4012 and there is a transition to block 4016.

[0084] Block 4016 comprises allocating the entire CAT to the secondary node. Continuing the present example, block 4016 involves the coordination engine 102 allocating tasks specified in the CAT request to the administrator terminal 118-1.

[0085] Block 4020 comprises allocating the entirety of the independent task from the CAT to the secondary node. Continuing the example, block 4020 involves the coordination engine 102 allocating execution of the independent task to the administrator terminal 118-1, making use of primary module 224- 1 to execute the independent task. At this point the method advances to block 4060, which will be discussed later below.

[0086] Returning to block 4012, a “yes” determination leads to block 4024. Block 4024 comprises determining whether the additional nodes are assuming all of the CAT request. To elaborate, in the present example, block 4024 involves evaluating responses from the one or more engines 104 that generated the “yes” at block 4012. The responses are evaluated to determine if engines 104 can execute all of tasks in the CAT request, including both independent and dependent tasks.

[0087] A “yes” determination at block 4024 leads to block 4028 which comprises allocating the entire CAT request to the additional nodes. To elaborate, block 4028 involves the coordination engine 102 distributing the entirety of the tasks within the CAT request to the one or more engines 104 whose response led to the “yes” responses at block 4012 and block 4024.

[0088] Block 4032 comprises allocating the entire independent task to the relevant additional nodes. In the present example, the relevant additional nodes are the engines 104 that led to the branch down from block 4028. Block 4032 involves making use of the function of primary module 224- 1 in relation to fulfilment of the independent task. At this point, the method advances to block 4036.

[0089] Continuing the example, block 4036 comprises allocating the entire dependent task from the CAT request to the additional node(s). According to the specific example, block 4036 involves the coordination engine 102 allocating execution of the dependent task to the relevant engines 104, making use of the function of secondary module 224-2 to execute the dependent task. At this point the method advances to block 4060, which will be discussed later below.

[0090] Returning to block 4024, a “no” determination at block 4024 leads to block 4040 which comprises allocating a first portion of the CAT request to the additional node(s). To elaborate, block 4040 involves the coordination engine 102 distributing the portion of CAT requests to the engines 104 that triggered the path to block 4040. Block 4040 is roughly equivalent to block 4028, except in block 4040, only a portion of the CAT requests is allocated.

[0091] Block 4044 comprises allocating a second portion of the CAT request to the secondary node. Block 4044 is roughly equivalent to block 4016, except in block 4044, only a portion of the CAT requests is allocated.

[0092] Block 4048 comprises allocating a first portion of the independent tasks to the relevant additional node(s). In the present example, the relevant nodes are the engines 104 that triggered the path to block 4040. The first portion is allocated to the relevant engines 104, making use of the function of primary module 224-1 to execute the independent task. Block 4048 is roughly equivalent to block 4032, except that only a portion of the independent tasks is allocated. At this point, the method advances to block 4052.

[0093] Block 4052 comprises allocating a second portion of the independent task from the CAT request to the additional node(s). In the present example, block 4052 involves the coordination engine 102 associating execution of the relevant second portion of the independent task to the administrator terminal 118-1, making use of the function of primary module 224- 1 to execute the independent task. Block 4052 is roughly equivalent to block 4020, but only a portion of the independent task is assigned. At this point the method advances to block 4056, which will be discussed later below.

[0094] Block 4056 comprises allocating a first portion of the dependent task from the CAT request to the additional node(s). In the present example, block 4056 involves the coordination engine 102associating execution of the relevant first portion of the dependent task to the relevant engines 104, making use of the secondary module 224-2 to execute dependent task. Block 4056 is roughly equivalent to block 4036, except that only a portion of the dependent tasks is allocated. At this point, the method advances to block 4060.

[0095] Block 4060 comprises deleting any unallocated portions of the CAT request. To elaborate, block 4060 involves the coordination engine 102 identifying any residual or unallocated tasks within the CAT request that have not been assigned to either the secondary node or to the additional nodes. If such unallocated portions are detected, the coordination engine 102 executes a deletion process to remove these portions, ensuring that no incomplete or orphaned tasks remain within system 100. This deletion process may include updating task logs and databases to reflect the removal of these tasks, thereby maintaining system consistency and preventing execution conflicts.

[0096] Block 4064 comprises validating task allocations across nodes. To elaborate, block 4064 involves the coordination engine 102 verifying that all tasks assigned to the secondary node (e.g. administrator terminal 118-1) and the additional nodes (e.g. one or more of engines 104) have been allocated correctly and that execution dependencies are intact. This validation step may include checking task execution logs, cross-referencing state data maintained in system databases, and otherwise ensuring that all task dependencies specified in the CAT request have been fulfilled. If inconsistencies or errors are detected, the coordination engine 102 may trigger a reallocation process or issue alerts to administrator terminal 118 to other nodes for manual intervention. Successful validation at block 4064 allows the method to proceed to commit the execution results across all nodes, ensuring atomicity and consistency in the distributed computing environment.

[0097] Potential implementations for method 4000 include deploying coordination engine 102 as an electronic trading engine in which primary module 224-1 serves an options exchange and secondary module 224-2 serves as a stock exchange.

[0098] Method 4000 contemplates that a user 124 can be a market participant, wherein client terminals 116 serve as primary nodes; administrator 126 can be a dealer, wherein administrator terminals 118 serve as secondary nodes,; while engines 104 serve as additional nodes associated with market makers. Thusly, client terminals 116 are primary nodes, administrator terminals 118 are secondary nodes, and engines 104 are additional nodes.

[0099] In the trading engine example, prior to invocation of method 4000, the example contemplates the initiation of an independent task from a client terminal 116 to an administrator terminal 118. The independent task is a request to acquire options by the user 124 from the administrator 126 via the nodes in system 100, with the administrator 126 developing a strategy that is implemented as a CAT for hedging the options by triggering a dependent task in the form of acquiring common stock or other securities that underlie the options.

[0100] While Figure 1 shows coordination engine 102 encapsulating software modules 224, each module 224 may be implemented in its own separate engine, or some modules 224 may be combined. For example, the options exchange (primary module 224-1) and the stock exchange (secondary module 224-2) may be remote from each other, located in different cities, leading to further challenges and requirements when it comes to atomicity, considering latency between all of the nodes in system 100, further exacerbated by the distance between primary module 224-1 and secondary module 224-2. Likewise, aggregation module 224-3 may be local to either primary module 224- 1 or secondary module 224-2, or may be remote from all of them, further exacerbating technical challenges.

[0101] The present specification provides a novel means of ensuring atomicity across all nodes in system 100 despite the distributed and asynchronous nature of the nodes in system 100 without the benefit of aggregation module 224-3.

[0102] Figure 11 , which will also be discussed in greater detail below, shows a signal flow diagram that generally corresponds to using method 4000 according the example where coordination engine 102 is deployed as a trading engine. Table I shows a concordance between various blocks in method 4000 of Figure 5, and lines in Figure 11. Of note that the branch from block 4040 to block 40056 is directly shown in Figure 11, with the other two branches being implied in Figure 12.Corresponding Figure 11Figure 5 / Method 4000 Block Line4004 - Receive Composite Atomic Task Request 400a4008 - Query Additional Nodes 402a4012 - Additional nodes assuming part of request Implied4016 - Allocate CAT to secondary node 408a / 410a (Implied)4020 - Allocate independent task to secondary node 416a / 418a (Implied)Corresponding Figure 11Figure 5 / Method 4000 Block Line4024 - Additional nodes assuming all of request (Implied)4028 - Allocate entire CAT to additional nodes 404a / 406a (Implied)4032 - Allocate independent task to additional nodes 412a / 414a (Implied)4036 - Allocate dependent task to additional nodes 420a / 422a (Implied)4040 - Allocate first portion of CAT to additional nodes 404a / 406a4044 - Allocate second portion of CAT to secondary node 408a / 410a4048 - Allocate first portion of independent task to additional412a / 414a nodes4052 - Allocate second portion of independent task to secondary 4 ga / 4 ganode4056 - Allocate first portion of dependent task to additional420a / 422a nodes4060 - Delete any unallocated portions 424a4064 - Validate allocations across nodes (Implied)

[0103] Figure 6 shows a flowchart depicting a method for coordinating the atomic processing of dependent data transactions in a distributed computing environment, indicated generally at 5000. Method 5000 can be implemented on system 100, though persons skilled in the art may implement variations thereof, including omitting certain blocks, performing steps in parallel, or reordering the sequence based on system configurations.

[0104] For explanatory purposes, method 5000 is described in the context of system 100, where it operates as, for example, an aggregation module application 224-3 maintained within coordination engine 102, interacting with other system nodes as illustrated in Figure 1. Furthermore, method 5000 contemplates the processing of a composite atomic task request (CAT), which includes a combination of an independent task that is performed by primary module 224- 1 and a dependent task that is performed by secondary module 224-2.

[0105] Block 5004 comprises receiving a Composite Atomic Task (CAT) Request from a secondary node. In an example embodiment, block 5004 involves the aggregation module 224-3 receiving a request that specifies both an independent task and a dependent task from administrator 126 that require coordinated execution. (Block 5004 is roughly analogous to block 4004 in Figure 5).

[0106] Block 5008 comprises querying additional nodes for participation in the CAT request. In a present embodiment, block 5008 involves the coordination engine 102 transmitting queries to engines 104 to assess their capacity to execute portions of the CAT request. The query may include information about the independent task for primary module 224-1 and the dependent task for secondary module 224-2.

[0107] Block 5012 comprises determining whether additional nodes are assuming part of the request. In an example embodiment, the additional nodes are engines 104. Block 5012 thus involves the coordination engine 102 assessing responses from engines 104 to determine if one or more of engines 104 will take on parts of the CAT request. If additional nodes send signals agreeing to participate, the method proceeds to the decision at block 5024; otherwise, a “no” determination is made at block 5012 and there is a transition to block 5016.

[0108] Block 5016 comprises allocating the entire CAT to the secondary node. Continuing the present example, block 5016 involves the coordination engine 102 allocating tasks specified in the CAT request to the administrator terminal 118-1.

[0109] Block 5020 comprises allocating the entirety of the independent task from the CAT to the secondary node. Continuing the example, block 5020 involves the coordination engine 102 allocating execution of the independent task to the administrator terminal 118-1, making use of primary module 224- 1 to execute the independent task.

[0110] Block 5022 comprises allocating the entirety of the dependent task from the CAT to the secondary node. Continuing the example, block 5022 involves the coordination engine 102 allocating execution of the dependent task to the administrator terminal 118-1, making use of secondary module 224-2 to execute the dependent task.

[0111] Returning to block 5012, a “yes” determination leads to block 5024. Block 5024 comprises determining whether the additional nodes are assuming all of the CAT request. To elaborate, in the present example, block 5024 involves evaluating responses from the one or more engines 104 that generated the “yes” at block 5012. The responses are evaluated to determine if engines 104 can execute all of the tasks in the CAT request, including both independent and dependent tasks.

[0112] A “yes” determination at block 5024 leads to block 5028, which comprises allocating the entire CAT request to the additional nodes. To elaborate, block 5028 involves the coordination engine 102 distributing the entirety of the tasks within the CAT request to the one or more engines 104 whose response led to the “yes” responses at block 5012 and block 5024.

[0113] Block 5032 comprises allocating the entire independent task to the relevant additional nodes. In the present example, the relevant additional nodes are the engines 104 that led to the branch down from block 5028. Block 5032 involves making use of the function of primary module 224- 1 in relation to the fulfillment of the independent task.

[0114] Continuing the example, block 5036 comprises allocating the entire dependent task from the CAT request to the additional node(s). According to the specific example, block 5036 involves the coordination engine 102 allocating execution of the dependent task to the relevant engines 104, making use of the function of secondary module 224-2 to execute the dependent task.

[0115] Returning to block 5024, a “no” determination at block 5024 leads to block 5040, which comprises allocating a first portion of the CAT request to the additional node(s). To elaborate, block 5040 involves the coordination engine 102 distributing a portion of CAT requests to the engines 104 that triggered the path to block 5040. (Block 5040 is roughly equivalent to block 5028, except only a portion of the CAT is allocated at block 5040).

[0116] Block 5044 comprises allocating a second portion of the CAT request to the secondary node. Block 5044 is roughly equivalent to block 5016, except in block 5044, only a portion of the CAT requests is allocated.

[0117] Block 5048 comprises allocating a first portion of the independent tasks to the relevant additional node(s). In the present example, the relevant nodes are the engines 104 that triggered the path to block 5040. The first portion is allocated to the relevant engines 104, making use of the function of primary module 224- 1 to execute the independent task. (Roughly equivalent to block 5032).

[0118] Block 5052 comprises allocating a second portion of the independent task from the CAT request to the additional node(s). In the present example, block 5052 involves the coordination engine 102 associating execution of the relevant second portion of the independent task to theadministrator terminal 118-1, making use of the function of primary module 224- 1 to execute the independent task. (Roughly equivalent to block 5020).

[0119] Block 5056 comprises allocating a first portion of the dependent task from the CAT request to the additional node(s). In the present example, block 5056 involves the coordination engine 102 associating execution of the relevant first portion of the dependent task to the relevant engines 104, making use of the secondary module 224-2.

[0120] Block 5058 comprises allocating a second portion of the dependent task from the CAT request to the secondary node. Block 5058 involves the coordination engine 102 associating execution of the relevant second portion of the dependent task to the administrator terminal 118- 1, making use of the secondary module 224-2. Block 5058 is roughly equivalent to block 5022, except that only a portion of the dependent tasks is allocated.

[0121] Block 5060 comprises deleting any unallocated portions of the CAT request. To elaborate, block 5060 involves the coordination engine 102 identifying any residual or unallocated tasks within the CAT request and executing a deletion process to remove these portions.

[0122] Block 5064 comprises validating task allocations across nodes. To elaborate, block 5064 involves the coordination engine 102 verifying that all tasks assigned to the secondary node and the additional nodes have been allocated correctly and that execution dependencies are intact.

[0123] Similar to method 4000, potential implementations for method 5000 include deploying coordination engine 102 as an electronic trading engine, where primary module 224-1 serves an options exchange and secondary module 224-2 serves as a stock exchange.

[0124] Figure 12, which will also be discussed in greater detail below, shows a signal flow diagram that generally corresponds to using method 5000 according the example where coordination engine 102 is deployed as a trading engine. Table II shows a concordance between various blocks in method 5000 of Figure 6, and lines in Figure 12. Of note that the branch from block 5040 to block 5058 is directly shown in Figure 12, with the other two branches being implied in Figure 12.Corresponding Figure 12Figure 5 / Method 4000 Block Line5004 - Receive Composite Atomic Task Request 500a5008 - Query Additional Nodes 402a5012 - Additional nodes assuming part of request Implied5016 - Allocate CAT to secondary node 408a / 410a (Implied)5020 - Allocate independent task to secondary node 416a / 418a (Implied)5022 - Allocate dependent task to secondary node 506 / 5085024 - Additional nodes assuming all of request (Implied)5028 - Allocate entire CAT to additional nodes 404a / 406a (Implied)5032 - Allocate independent task to additional nodes 412a / 414a (Implied)5036 - Allocate dependent task to additional nodes 502 / 504 (Implied)5040 - Allocate first portion of CAT to additional nodes 404a / 406a5044 - Allocate second portion of CAT to secondary node 408a / 410a5048 - Allocate first portion of independent task to additional412a / 414a nodes5052 - Allocate second portion of independent task to secondary 4 ga / 4 ganode5056 - Allocate first portion of dependent task to additional502a / 504a nodes5060 - Delete any unallocated portions 424a5064 - Validate allocations across nodes (Implied)

[0125]

[0126] Without limiting the foregoing the following example embodiment is further illustrative as the teachings herein relate to electronic trading systems, such as electronic exchanges. Such systems process a large quantity of data each trading day, requiring a high amount of computational processing and network throughput, as well as low latency. In addition to these technical challenges, electronic trading systems are also challenged to provide liquid and efficient markets. Market participants often wish to have flexibility and stability, while also being able to earn returns on trades.

[0127] An electronic trading system receives from a first market participant computer system a data message defining an order for a first financial instrument and a second financial instrument. The second financial instrument is tied to the first financial instrument. The system fills the orderfor the first financial instrument on behalf of a second market participant against a corresponding order by another market participant and conducts a trade for the second financial instrument between the first market participant and a third market participant in control of a third market participant computer system. The electronic trading system may additionally or alternatively provide for trading after market close, for a relatively short window of time, orders that meet one or more specific conditions

[0128] An aspect of the specification provides an electronic trading system including: a network interface configured to communicate data messages with market participant computer systems over a computer network; and one or more processors configured to collectively: receive from a first market participant computer system a data message defining an order for a first financial instrument and a second financial instrument, wherein the second financial instrument is tied to the first financial instrument; fill the order for the first financial instrument on behalf of a second market participant against a corresponding order by another market participant; and conduct a trade for the second financial instrument between the first market participant and the third market participant in control of the third market participant computer system.

[0129] An aspect of the specification provides an electronic trading system, wherein the data message specifies an indicator indicating that the order for the first financial instrument is to be filled independently of the second financial instrument.

[0130] An aspect of the specification provides an electronic trading system, wherein the one or more processors is configured, based on an instruction received from the first market participant computer system, to collectively compute a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0131] An aspect of the specification provides an electronic trading system, wherein the first financial instrument is an option for the second financial instrument.

[0132] An aspect of the specification provides an electronic trading system, wherein the order is an auction order.

[0133] An aspect of the specification provides a method for electronic trading, the method including: receiving from a first market participant computer system a data message defining anorder for a first financial instrument and a second financial instrument, wherein the second financial instrument is tied to the first financial instrument; filling the order for the first financial instrument on behalf of a second market participant against a corresponding order by another market participant; and conducting a trade for the second financial instrument between the first market participant and a third market participant in control of a third market participant computer system.

[0134] An aspect of the specification provides a method, wherein the data message specifies an indicator indicating that the order for the first financial instrument is to be filled independently of the second financial instrument.

[0135] An aspect of the specification provides a method, further including computing a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0136] An aspect of the specification provides a method, wherein the first financial instrument is an option for the second financial instrument.

[0137] An aspect of the specification provides a method, wherein the order is an auction order.

[0138] An aspect of the specification provides an electronic trading system including: a network interface configured to communicate data messages with computer systems over a computer network; one or more processors configured to collectively: receive from a first market participant computer system a data message defining an order for a first market participant to trade a first financial instrument on behalf of a second market participant and a second financial instrument, wherein the first and second financial instruments are tied; determine whether the order specifies an indicator that the order is to be processed without the second market participant trading the second financial instrument; if the order does not specify the indicator: fill the order for the first financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of a first market participant computer system and / or a third market participant in control of a third market participant computer system; and fill the order for the second financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of the first market participantcomputer system and / or the third market participant in control of the third market participant computer system; and if the order specifies the indicator: fill the order for the first financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of a first market participant computer system and / or a third market participant in control of the third market participant computer system; and fill the order for the second financial instrument on behalf of the first market participant against a corresponding order by the third market participant in control of the third market participant computer system.

[0139] An aspect of the specification provides an electronic trading system, wherein the one or more processors is configured, based on an instruction received from the first market participant computer system, to collectively compute a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0140] An aspect of the specification provides an electronic trading system, wherein the first financial instrument is an option for the second financial instrument.

[0141] An aspect of the specification provides an electronic trading system, wherein the order is an auction order.

[0142] An aspect of the specification provides a method for electronic trading, the method including: receiving from a first market participant computer system a data message defining an order for a first market participant to trade a first financial instrument on behalf of a second market participant and a second financial instrument, wherein the first and second financial instruments are tied; determining whether the order specifies an indicator that the order is to be processed without the second market participant trading the second financial instrument; if the order does not specify the indicator: filling the order for the first financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of a first market participant computer system and / or a third market participant in control of a third market participant computer system; and filling the order for the second financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of the first market participant computer system and / or the third market participant in control of the third market participant computer system; and if the order specifies the indicator: filling the order for the first financial instrument on behalf of the second marketparticipant against a corresponding order made by the first market participant in control of a first market participant computer system and / or a third market participant in control of the third market participant computer system; and filling the order for the second financial instrument on behalf of the first market participant against a corresponding order by the third market participant in control of the third market participant computer system.

[0143] An aspect of the specification provides a method, further including computing a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0144] An aspect of the specification provides a method, wherein the first financial instrument is an option for the second financial instrument.

[0145] An aspect of the specification provides a method, wherein the order is an auction order.

[0146] An aspect of the specification provides an electronic trading system including: a network interface configured to communicate data messages with a plurality of market participant computer systems over a computer network; and one or more processors configured to collectively: receive a data message specifying an order for a first financial instrument and a second financial instrument, after a market has closed, the data message defining at least a portion of the order in the market that has closed; determine whether an after-close window is open in the market that has closed; and if the after-close window is open, process the order to perform a trade in the market that has closed.

[0147] An aspect of the specification provides an electronic trading system, wherein the one or more processors are configured to collectively, if the after-close window is open and a condition for the order is met, process the order to perform the trade in the market.

[0148] An aspect of the specification provides an electronic trading system, wherein the condition includes a minimum quantity of the first financial instrument that the order is to meet or exceed.

[0149] An aspect of the specification provides an electronic trading system, wherein the condition includes a market participant that originated the order demonstrating trading at a day's closing auction.

[0150] An aspect of the specification provides an electronic trading system, wherein the condition includes the order being a covered-with-stock option order.

[0151] An aspect of the specification provides an electronic trading system, wherein the condition includes the order specifying an indicator.

[0152] An aspect of the specification provides an electronic trading system, wherein the first financial instrument is an option that is tied to the second financial instrument.

[0153] An aspect of the specification provides an electronic trading system, wherein the first financial instrument is traded at a first market and the second financial instrument is traded at a second market, wherein one or both of the first and second markets may be determined to be closed.

[0154] An aspect of the specification provides a method of electronic trading, the method including: receiving a data message specifying an order for a first financial instrument and a second financial instrument, after a market has closed, the data message defining at least a portion of the order in the market that has closed; determining whether an after-close window is open in the market that has closed; and if the after-close window is open, processing the order to perform a trade in the market that has closed.

[0155] An aspect of the specification provides a method, wherein, if the after-close window is open and a condition for the order is met, processing the order to perform the trade in the market.

[0156] An aspect of the specification provides a method, wherein the condition includes a minimum quantity of the first financial instrument that the order is to meet or exceed.

[0157] An aspect of the specification provides a method, wherein the condition includes a market participant that originated the order demonstrating trading at a day's closing auction.

[0158] An aspect of the specification provides a method, wherein the condition includes the order being a covered-with-stock option order.

[0159] An aspect of the specification provides a method, wherein the condition includes the order specifying an indicator.

[0160] An aspect of the specification provides a method, wherein the first financial instrument is an option that is tied to the second financial instrument.

[0161] An aspect of the specification provides a method, wherein the first financial instrument is traded at a first market and the second financial instrument is traded at a second market, wherein one or both of the first and second markets may be determined to be closed.

[0162] According to an aspect of this example, an electronic trading system includes a network interface configured to communicate data messages with market participant computer systems over a computer network. The system further includes one or more processors configured to collectively receive from a first market participant computer system a data message defining an order for a first financial instrument and a second financial instrument. The second financial instrument is tied to the first financial instrument. The one or more processors are further configured to fill the order for the first financial instrument on behalf of a second market participant against a corresponding order by another market participant and conduct a trade for the second financial instrument between the first market participant and a third market participant in control of a third market participant computer system.

[0163] The data message may specify an indicator indicating that the order for the first financial instrument is to be filled independently of the second financial instrument.

[0164] The one or more processors may be further configured, based on an instruction received from the first market participant computer system, to collectively compute a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0165] The first financial instrument may be an option for the second financial instrument.

[0166] The order may be an auction order.

[0167] According to another aspect of this disclosure, a method for electronic trading includes receiving from a first market participant computer system a data message defining an order for a first financial instrument and a second financial instrument. The second financial instrument is tied to the first financial instrument. The method further includes filling the order for the first financialinstrument on behalf of a second market participant against a corresponding order by another market participant and conducting a trade for the second financial instrument between the first market participant and a third market participant in control of a third market participant computer system.

[0168] The data message may specify an indicator indicating that the order for the first financial instrument is to be filled independently of the second financial instrument.

[0169] The method may further include computing a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0170] The first financial instrument may be an option for the second financial instrument.

[0171] The order may be an auction order.

[0172] According to another aspect of this disclosure, an electronic trading system includes a network interface configured to communicate data messages with computer systems over a computer network. The system further includes one or more processors configured to collectively receive from a first market participant computer system a data message defining an order for a first market participant to trade a first financial instrument on behalf of a second market participant and a second financial instrument. The first and second financial instruments are tied. The one or more processors are further configured to collectively determine whether the order specifies an indicator that the order is to be processed without the second market participant trading the second financial instrument. If the order does not specify the indicator, the one or more processors fill the order for the first financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of a first market participant computer system and / or a third market participant in control of a third market participant computer system and fill the order for the second financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of the first market participant computer system and / or the third market participant in control of the third market participant computer system. If the order specifies the indicator, the one or more processors fill the order for the first financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of a first market participant computer systemand / or a third market participant in control of the third market participant computer system and fill the order for the second financial instrument on behalf of the first market participant against a corresponding order by the third market participant in control of the third market participant computer system.

[0173] The one or more processors may be configured, based on an instruction received from the first market participant computer system, to collectively compute a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0174] The first financial instrument may be an option for the second financial instrument.

[0175] The order may be an auction order.

[0176] According to another aspect of this disclosure, a method for electronic trading includes receiving from a first market participant computer system a data message defining an order for a first market participant to trade a first financial instrument on behalf of a second market participant and a second financial instrument. The first and second financial instruments are tied. The method further includes determining whether the order specifies an indicator that the order is to be processed without the second market participant trading the second financial instrument. If the order does not specify the indicator, the method includes filling the order for the first financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of a first market participant computer system and / or a third market participant in control of a third market participant computer system and filling the order for the second financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of the first market participant computer system and / or the third market participant in control of the third market participant computer system. If the order specifies the indicator, the method includes filling the order for the first financial instrument on behalf of the second market participant against a corresponding order made by the first market participant in control of a first market participant computer system and / or a third market participant in control of the third market participant computer system and filling the order for the second financial instrument on behalf of the first market participant against a corresponding order by the third market participant in control of the third market participant computer system.

[0177] The method may further include computing a quantity of the second financial instrument for the trade based on a quantity of the first financial instrument specified in the order.

[0178] The first financial instrument may be an option for the second financial instrument.

[0179] The order may be an auction order.

[0180] According to another aspect of this disclosure, an electronic trading system includes a network interface configured to communicate data messages with a plurality of market participant computer systems over a computer network. The system further includes one or more processors configured to collectively receive a data message specifying an order for a first financial instrument and a second financial instrument, after a market has closed, the data message defining at least a portion of the order in the market that has closed. The one or more processors are further configured to determine whether an after-close window is open in the market that has closed and, if the after-close window is open, process the order to perform a trade in the market that has closed.

[0181] The one or more processors may be further configured to collectively, if the after-close window is open and a condition for the order is met, process the order to perform the trade in the market.

[0182] The condition may include a minimum quantity of the first financial instrument that the order is to meet or exceed.

[0183] The condition may include a market participant that originated the order demonstrating trading at a day’s closing auction.

[0184] The condition may include the order being a covered-with-stock option order.

[0185] The condition may include the order specifying an indicator.

[0186] The first financial instrument may be an option that is tied to the second financial instrument.

[0187] The first financial instrument may be traded at a first market and the second financial instrument is traded at a second market, wherein one or both of the first and second markets may be determined to be closed.

[0188] According to another aspect of this disclosure, a method of electronic trading includes receiving a data message specifying an order for a first financial instrument and a second financial instrument, after a market has closed, the data message defining at least a portion of the order in the market that has closed, determining whether an after-close window is open in the market that has closed, and, if the after-close window is open, processing the order to perform a trade in the market that has closed.

[0189] The method may further include, if the after-close window is open and a condition for the order is met, processing the order to perform the trade in the market.

[0190] The condition may include a minimum quantity of the first financial instrument that the order is to meet or exceed.

[0191] The condition may include a market participant that originated the order demonstrating trading at a day’s closing auction.

[0192] The condition may include the order being a covered-with-stock option order.

[0193] The condition may include the order specifying an indicator.

[0194] The first financial instrument may be an option that is tied to the second financial instrument.

[0195] The first financial instrument may be traded at a first market and the second financial instrument is traded at a second market, and one or both of the first and second markets may be determined to be closed.

[0196] With reference to Figure 7, a computer system 100a includes an electronic trading system 102a, a plurality of market participant computer systems 104a, and a computer network 106a. The electronic trading system 102a and market participant computer systems 104a are connected to the computer network 106a to facilitate data communications.

[0197] The electronic trading system 102a includes a special-purpose computer with one or more processors 120a, a network interface 122a, a non-transitory machine-readable medium 124a configured to receive, match, and fill orders received from the market participant computer systems 104a. Such orders may include new orders, cancelations, modifications, etc. and may take the form of electronic data messages 112a. Such orders may be auction orders. The trading system 102a may facilitate the trading of a plurality of different financial instruments, such as ETFs, stocks, funds, bonds, etc., under various symbols or identifiers.

[0198] The electronic trading system 102a may include multiple electronic markets which may operate on different financial instruments. For example, one market may trade stocks and another market may trade options. A data message and resulting order 102a, as discussed herein, may in reality be made up of multiple related data messages and orders at different markets.

[0199] Each market participant computer system 104a may include a general -purpose or specialpurpose computer with a processor and non-transitory machine -readable medium to receive input data and provide output data related to trades carried out at the trading system 102a. A market participant computer system 104a may include a server, terminal, or similar computing device that generates data messages 112a. A market participant computer system 104a may be operated by a person, may be partially automated, or may be fully automated (e.g., running a trading program with little to no human intervention).

[0200] Market participant computer systems 104a may be controlled by various parties such as investors, dealers, and market makers. The capabilities of a particular market participant computer system 104a depends on the party in control. Dealers and sophisticated investors and market makers may have specialized trading hardware and / or software installed. Unless otherwise mentioned herein, a first market participant is a dealer, a second market participant is a dealer’s client, and a third market participant is another party, such as a market maker.

[0201] Dealers, also known as brokers, may control their computer systems 104a to interact with the electronic trading system 102a on behalf of their clients, which may include investors and market makers. Sophisticated investors and market makers may control their computer systems 104a to interact directly with the electronic trading system 102a.

[0202] The computer network 106a may include a local-area network (LAN), wide-area network (WAN), virtual private network (VPN), a mobile network, the internet, or a combination of such. The computer network 106a may be wired, wireless, or both.

[0203] Regarding the electronic trading system 102a, the one or more processor 120a may include a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or similar processor. The one or more processor 120a cooperates with the medium 124a and may also cooperate with volatile memory, such as a random-access memory (RAM), to execute instructions 126a.

[0204] The network interface 122a includes hardware, such as a network adaptor, and software, such as a driver, to facilitate data communications via the computer network 106a and specifically with the market participant computer systems 104a.

[0205] The non-transitory machine-readable medium 124a may include an electronic, magnetic, optical, or other type of non-volatile physical storage device that encodes the instructions 126a that implement the functionality discussed herein. Examples of such storage devices include a non- transitory computer-readable medium such as a hard drive (HD), solid-state drive (SSD), readonly memory (ROM), electrically-erasable programmable read-only memory (EEPROM), or flash memory.

[0206] The instructions 126a may be directly executed, such as binary or machine code, and / or may include interpretable code, bytecode, source code, or similar instructions that may undergo additional processing to be executed. All of such examples may be considered executable instructions.

[0207] The instructions 126a are configured to conduct trades among market participant computer systems 104a, as will be discussed in detail below.

[0208] With reference to Figure 8, the electronic trading system 102a is configured to provide a riskless-trade-on-option instrument by facilitating underlying trades among market participant computer systems 104a that include a dealer computer system 104a-D controlled by a dealer 200a and a market-maker computer system 104a-MM controlled by a market maker 202a.

[0209] The dealer computer system 104a-D may receive instructions from a client market participant 204a, who may control a respective market participant computer system 104a-MP to provide such instructions. Alternatively, the market participant 204a may instruct the dealer 200a using out of band communications, such as email, telephone, or the like.

[0210] The electronic trading system 102a receives from the dealer computer system 104a-D a data message (ref. 112a in Figure 7) defining an order for the market participant 204a to buy a first financial instrument, which is tied to a second financial instrument by, for example, being a derivative of the second financial instrument, without the market participant 204a trading the second financial instrument. In the examples discussed herein, the first financial instrument is an option for the second financial instrument, which is a stock. In another example, the first instrument is a stock and the second instrument is a corresponding futures contract that is tied to the stock. In still another example, the first instrument is a futures contract and the second instrument is a corresponding stock that is tied to the future. In still other examples, other types of tied financial instruments may be used. As will be discussed below, the dealer 200a will meet a portion of the options trade. Accordingly, the order may be a cross order specifying an order made by the market participant 204a and a complementary order made by the dealer 200a.

[0211] Further, it should be noted that a first financial instrument may be a group of first financial instruments. That is, actions discussed as applying to a first financial instrument may be carried out on a set of one or more first financial instruments. Likewise, a second financial instrument may be a group of second financial instruments, and actions discussed as applying to a second financial instrument may be carried out on a set of one or more second financial instruments.

[0212] The electronic trading system 102a fills the order for the option against the complementary order made by the dealer 200a and another complementary order made by the market maker 202a. As such, an options trade 210a is formed between the market participant 204a and the dealer 200a and another options trade 212a is formed between the market participant 204a and the market maker 202a. The market participant 204a has their option order filled by a combination of the dealer 200a and the market maker 202a. The relative contribution of the dealer 200a and the market maker 202a is variable and may differ from trade to trade. For example, if the market participant204a buys N options, M may be filled by the dealer 200a and the balance, N - M, may be filled by the market maker 202a.

[0213] The electronic trading system 102a further conducts a trade 214a for the stock itself between the dealer 200a and the market maker 202a.

[0214] Accordingly, the market maker 202a obtains a riskless-trade-on-option instrument by providing a portion of the options obtained by the market participant 204a and taking a corresponding position on the underlying stock. For its part, the market participant 204a obtains options for the stock without taking a position on the underlying stock, which may be desirable for certain investors. The dealer 200a facilitates the trades for both the market participant 204a and the market maker 202a by providing a portion of the options to the market participant 204a and by taking a counter-position on the stock to the market maker 202a.

[0215] In anticipation of the trades 210a, 212a, 214a and to facilitate the counter-position against the market maker 202a, the dealer 200a may have previously taken an initial position in the stock, such that the counter-position taken by the dealer in the trade 214a with the market maker 202a lessens or eliminates the initial position. For example, if the trade 214a requires the dealer 200a to sell the stock to the market maker 202a, the dealer 200a may have previously bought the stock. This initial position in the stock is useful to help the dealer 200a establish the price for the option.

[0216] Figure 9 shows the riskless-trade-on-option instrument of Figure 8 in the case of call options. As can be seen, the riskless-trade-on-option instrument includes the sale of call options 300a by the market maker 202a to the market participant 204a and the purchase of the underlying stock 302a by the market maker 202a from the dealer 200a. The dealer 200a also sells call options 304a to the market participant 204a to fill the demand of the market participant 204a.

[0217] Figure 10 shows the riskless-trade-on-option instrument of Figure 8 in the case of put options. As can be seen, the riskless-trade-on-option instrument includes the sale of put options 310a by the market maker 202a to the market participant 204a and the sale of the underlying stock 312a by the market maker 202a to the dealer 200a. The dealer 200a also sells put options 314a to the market participant 204a to fill the demand of the market participant 204a.

[0218] Figure 11 shows example data messages communicated by a dealer computer system 104a- D and a market-maker computer system 104a- MM with an electronic trading system 102a to enable the riskless-trade-on-option instrument discussed above. Figure 11 describes a method of communicating and processing data messages that may be implemented by processor-executable instructions, such as instructions 126a of Figure 7.

[0219] Example data message contents are shown in the figure with FIX™ (Financial Information eXchange) codes being used where helpful for explanation. Any suitable protocol may be used, with FIX being a salient example. Note that acknowledgment messages are omitted for sake of clarity.

[0220] Initially, a market participant (“MP” in the figure), such as an investor, places an order for an option. In this example, for sake of explanation only, the order is for 100a units. The market participant (“MP”) may be referred to as must-be-filled (“MBF”).

[0221] The dealer computer system 104a-D constructs a data message 400a reflecting the market participant’s option order and transmits the data message 400a to the electronic trading system 102a. The data message 400a specifies that the market participant is the buyer of the options, the buy order has an identifier of “la” (e.g., the FIX code I la may be used), the dealer is the seller of the options, the sell order has an ID of “2a”, the quantity of the option to be traded (e.g., 100a in this example), the type of security (e.g., FIX code 167a) is a multi-leg instrument, and an indicator, such as a flag or type (e.g., “CrossVariant=RTO”), indicating the riskless-trade-on-option instrument. The indicator may also indicate that the market participant’s option order must be filled. Other data, such as the identifier of the option or underlying stock, is also provided in the data message 400a.

[0222] Next, an auction occurs. A market-maker computer system 104a-MM may construct a data message 402a indicating the willingness to participate in the fill of the market participant’s option order and transmits the data message 402a to the electronic trading system 102a. In this example, the market maker (“MM” in the figure) is willing to provide 30a units of the lOOa-unit option order.

[0223] In response to the data message 402a, the electronic trading system 102a constructs a data message 404a indicating the market maker’ s willingness to partially fill the option order. The data message 404a specifies the identifier “la” for correlation to the market participant’s initial order of the data message 400a. The electronic trading system 102a transmits the data message 404a to the dealer computer system 104a-D.

[0224] The electronic trading system 102a constructs a data message 406a indicating to the market maker that the market maker’s order to sell the option, as expressed by data message 402a, is accepted. The electronic trading system 102a transmits the data message 402a to the market-maker computer system 104a-MM.

[0225] The electronic trading system 102a constructs a data message 408a indicating that the balance of the market participant’s option order (i.e., 70a units under order ID “la”) will be filled by the dealer. The electronic trading system 102a transmits the data message 408a to the dealer computer system 140a-D.

[0226] Likewise, the electronic trading system 102a constructs a data message 410a indicating that the dealer is to sell the balance of the market participant’s option order (i.e., 70a units under ID “2a”). The electronic trading system 102a transmits the data message 410a to the dealer computer system 140a-D.

[0227] The electronic trading system 102a executes the market-maker portion of the option order and constructs respective data messages 412a, 414a indicating such. The electronic trading system 102a transmits the data message 412a to the dealer computer system 104a-D and transmits the data message 414a to the market-maker computer system 104a-MM. In these data messages 412a, 414a, the type of security is indicated to be the option (“OPT”) and the quantity is the agreed portion (e.g., 30a units). The data message 412a destined to the dealer computer system 104a-D also indicates the order ID “la” for correlation to the market participant’s original order contained in the data message 400a.

[0228] Similarly, the electronic trading system 102a executes the dealer portion of the option order and constructs respective data messages 416a, 418a indicating such. Each data messages 416a, 418a indicates a respective order ID “la”, “2a” for correlation to the original orders contained inthe data message 400a. The electronic trading system 102a transmits the data messages 416a, 418a to the dealer computer system 104a-D. In these data messages 412a, 414a, the type of security is indicated to be the option (“OPT”) and the quantity is the remaining portion of the option order not filled by the market maker (e.g., 70a units).

[0229] Subsequently, the electronic trading system 102a executes an underlying stock trade between the market-maker and the dealer. The electronic trading system 102a constructs a data message 420a indicating to the dealer that the dealer bought / sold a quantity (e.g., 1200a) of the stock (e.g., FIX code “CS”) from / to the market maker. Likewise, the electronic trading system 102a constructs a data message 422a indicating to the market maker that the market maker sold / bought the quantity (e.g., 1200a) of the stock (e.g., FIX code “CS”) to / from the dealer. The electronic trading system 102a transmits each data message 420a, 422a to the respective computer system 104a-D, 104a-MM.

[0230] As discussed above, when call options are involved, the market maker buys the underlying stock from the dealer. As such, the message 420a would indicate “sell” and the message 422a would indicate “buy.” Conversely, when put options are involved, the market maker sells the underlying stock to the dealer. As such, the message 420a would indicate “buy” and the message 422a would indicate “sell.”

[0231] The quantity of the underlying stock traded between the dealer and the market maker, as indicated by data messages 420a, 422a is directly related to the number of units of the option sold by the market maker to the market participant. The number of shares of the underlying stock may be automatically computed by the electronic trading system 102a and may equal the number of units of the option sold by the market maker to the market participant multiplied by the unit size (e.g., 100a shares per unit) multiplied by the option’s delta. In the example shown in Figure 11, assuming a delta of 40a%, the number of shares is computed as 30a*100a*40a% = 1200a.

[0232] Finally, the electronic trading system 102a determines that the trades necessary to complete the order defined by the data message 400a are complete and constructs a respective data message 424a and transmits this data message 424a to the dealer computer system 104a-D.

[0233] The electronic trading system 102a may be programmed with instructions to receive and respond to a data message 400a containing the indicator (e.g., “Cross Variant=RTO”) that indicates the riskless-trade-on-option instrument and any subsequent data message 402a received from a market maker. The electronic trading system 102a may be programmed to validate the incoming data messages 400a, 402a, conduct the trades indicated by the incoming data messages 400a, 402a, and generate and transmit respective outgoing data messages 404a - 424a to the respective computer systems 104a-D, 104a-MM.

[0234] In this example, one market maker indicated willingness to participate in the trade by generating and transmitting a data message 402a. In various examples, any suitable number of market makers may do so. In various examples, time priority may be used to determine which of multiple market makers may participate in the trade.

[0235] Figure 12 shows example data messages communicated by a dealer computer system 104a- D and a market-maker computer system 104a-MM with an electronic trading system 102a when the riskless-trade-on-option instrument is not used. Figure 12 describes a method of communicating and processing data messages that may be implemented by processor-executable instructions, such as instructions 126a of Figure 7. Figure 11 and related description may be referenced for details not repeated here. Like reference numerals and terminology denote like components.

[0236] Initially, a market participant (“MP” in the figure), such as an investor, places an order for an option. In this example, for sake of explanation only, the order is for 100a units.

[0237] The dealer computer system 104a-D constructs a data message 500a reflecting the market participant’s option order and transmits the data message 500a to the electronic trading system 102a. The data message 500a is similar to the data message 400a discussed above but lacks the indicator (e.g., “Cross Variant=RTO”) indicating the riskless-trade-on-option instrument.

[0238] Consequently, data messages 502a - 508a are required to be generated by the electronic trading system 102a and transmitted to respective computer systems 104a-D, 104a-MM to fulfill stock trades to provide approximate equivalence to the example of Figure 11. As such, in comparison to the example of Figure 11, at least two additional data messages 506a, 508a arerequired. Generation and transmission of additional data messages places a greater demand on computational resources of at least the electronic trading system 102a and places a greater throughput demand on the computer network 106a (Figure 7). As such, the riskless-trade-on- option instrument methodology of Figure 11 is more efficient in terms of processing and network usage.

[0239] Figure 13 shows a trading flow with example data.

[0240] At block 600a, a posted market for a specific security (e.g., XIU) exists.

[0241] At block 602a, an auction occurs for a market participant’s (MP) order for a number of units of a put option for the security. The dealer and a market maker (MM) agree to fill the order.

[0242] If the initial order does not have an indicator (e.g., “CrossVariant=RTO”), the market participant wishes to also buy the stock underlying the option. At block 604a, the electronic exchange system 102a (Figure 7) processes the auction results from block 602a with the market participant buying the underlying stock along with the put option and with both the dealer and the market maker selling a quantity of the underlying stock to the market participant. From the perspective of the market maker, the counterparty on the equity leg is the market participant. Note that in the case of a call option, these stock positions would be reversed. The process of Figure 12 may be referenced for further detail.

[0243] If the initial order has an indicator (e.g., “CrossVariant=RTO”), the market participant does not wish to buy the underlying stock. At block 606a, the electronic exchange system 102a (Figure 7) processes the auction results from block 602a with the market participant buying the put option, without buying the underlying stock, and with the market maker selling a quantity of the underlying stock to the dealer, who may have established a hedge position prior to block 600a (e.g., shorted the stock in advance). From the perspective of the market maker, the counterparty on the equity leg is the dealer. The number of shares is 125a units sold by the market maker multiplied by the unit size and the delta (i.e., 125a*100a*0a.58a = 7250a). There is no equity leg trade between the dealer and the market participant. Note that in the case of a call option, these stock positions would normally expected to be reversed. The process of Figure 11 may be referenced for further detail.

[0244] Figure 14 shows an example method 700a for covered-with-stock trading after market close. The order types, order processing, and other techniques discussed above may be used with the method 700a. The method 700a may be implemented with processor-executable instructions at an electronic trading system, such as the system 102a discussed above.

[0245] Further, the method 700a may operate on different kinds of tied financial instruments, such as stocks and options or futures and stocks, as discussed above. The method 700a is not limited to any particular instruments. In addition, different instruments may be traded on different markets, which may be hosted by the same or different trading systems 102a (see Figure 7). The method 700a may interact with different trading systems provided that at least one such trading system is configured for after-close trading.

[0246] After an equities (stock) market closes (e.g., at 4a:00a PM), it may be useful to allow the trading of options on the underlying stocks for a short time window, such as 10a or 15a minutes. It may also be useful to allow covered-with-stock trading during this window or a comparable window. Such after-close covered-with-stock trading may be useful with the riskless-trade-on- option instrument and without. The trading system may set the after-close window to a suitable static period, such as 10a or 15a minutes.

[0247] At block 702a, an order is received by an electronic trading system, such as the system 102a discussed above.

[0248] If the trading system determines that the equities market is still open, at block 704a, then the order is traded normally, at block 706a.

[0249] If the market is closed and the trading system determines that the after-close window has elapsed, at block 708a, then the order is rejected, at block 710a.

[0250] If the after-close window is open, then the trading system evaluates one or more conditions, at block 712a, to determine whether the order will be executed. An example condition is a minimum order quantity (e.g., a threshold number of units for an option or a threshold number of shares for a stock). If the order meets or exceeds the minimum size, the condition is met. Another example condition is a market participant identifier. The trading system may establish a condition that only market participants with demonstrated trading after close may do so. Another examplecondition is the order being a covered-with-stock option order. Another example condition is the presence of an indicator (e.g., “Cross Variant=RTO”) indicating a riskless-trade-on-option instrument is being traded, if the trading system wishes to exclude other types of orders from afterclose trading.

[0251] If the condition(s), at block 712a, are met, then the trading system executes the order, at block 714a, after market close.

[0252] The method 700a may be useful in reducing market impact for a large trade by encouraging a market participant to portion the large trade into smaller trades over the trading day. Conditionally (block 712a) extending the allowed time for such trades by the window (block 708a), even by a relatively short widow, may increase stability and / or liquidity.

[0253] In view of the above, it should be recognized that the covered-with-stock trading techniques discussed herein may provide flexibility to investors and market makers. The riskless- trade-on-option instrument may provide a useful tool in markets with relatively low liquidity. The riskless-trade-on-option instrument may also increase efficiency in meeting the requirements of diverse trading parties, such as market makers, dealers, investors, and other market participants. Under certain circumstances, riskless-trade-on-option instrument may reduce execution times from 15a - 20a minutes to la second or less. Computational and network efficiency may also be improved, in that data messages for unnecessary or unwanted stock trades are reduced or eliminated. In addition, the after-close trading techniques discussed herein can offer increased stability and liquidity to various markets.

[0254] It should be recognized that features and aspects of the various examples provided above can be combined into further examples that also fall within the scope of the present disclosure.

Claims

Claims1. A computer-implemented method for coordinating atomic processing of dependent data transactions in a distributed computing environment, the method comprising:(a) receiving a composite atomic task (CAT) request from a secondary node, the CAT request including an independent task and a dependent task; the independent task originating from a primary node to the secondary node;(b) querying additional nodes for participation in the CAT request;(c) determining if one or more additional nodes agree to assume part of the CAT request;(d) if none of the additional nodes agree to assume part of the CAT request:(i) allocating the CAT to the secondary node; and(ii) allocating the independent task from the CAT to the secondary node;(e) if at least one additional node agrees to assume part of the CAT request, determining if the additional nodes agree to assume all of the CAT request;(f) if all of the CAT request is assumed by the additional nodes:(i) allocating the entire CAT to the additional nodes;(ii) allocating the independent task from the CAT to the additional nodes; and(iii) allocating the dependent task from the CAT to the additional nodes;(g) if only a part of the CAT request is assumed by the additional nodes:(i) allocating a first portion of the CAT to the additional nodes;(ii) allocating a second portion of the CAT to the secondary node;(iii) allocating a first portion of the independent task from the CAT to the additional nodes;(iv) allocating a second portion of the independent task from the CAT to the secondary node;(v) allocating a first portion of the dependent task from the CAT to the additional nodes; and(vi) allocating a second portion of the dependent task from the CAT to the secondary node;(h) deleting any unallocated portions of the CAT request;(i) validating task allocations across nodes to ensure execution dependencies are intact.

2. The method of claim 1 , wherein querying additional nodes for participation in the CAT request comprises transmitting a capability query to each additional node, the capability query including execution parameters, resource requirements, and task dependencies associated with the CAT request.

3. The method of claim 1, wherein determining if one or more additional nodes agree to assume part of the CAT request comprises evaluating responses based on predefined thresholds for resource availability, processing capacity, and latency constraints.

4. The method of claim 1 , wherein validating task allocations across nodes comprises generating a validation log that tracks task allocation status, execution timestamps, and dependency fulfillment for each node involved in processing the CAT request.

5. The method of claim 1, further comprising, prior to deleting unallocated portions of the CAT request, transmitting a reallocation request to the secondary node to determine if the secondary node can assume execution of the unallocated portions based on updated resource availability.

6. The method of claim 1, wherein: the primary node comprises a client terminal associated with a market participant; the secondary node comprises an administrator terminal associated with a dealer; and the additional nodes comprise execution engines associated with market makers, wherein receiving the CAT request from the secondary node comprises receiving a task request to coordinate execution of a trade involving both an independent task associated with an options exchange and a dependent task associated with a stock exchange.

7. The method of claim 6, wherein: the market participant initiates with a trade order for an options contract from the client terminal; the dealer, via the administrator terminal, generates a corresponding CAT request that associates at least a portion of the options contract with the underlying stock according to a strategy; the execution engines associated with the market makers are queried to determine if they will assume execution of part or all of the independent and dependent tasks.

8. The method of claim 6, wherein the independent task comprises executing a trade for an options contract on a primary module configured as an options exchange, and the dependent task comprises executing a trade for the underlying stock on a secondary module configured as a stock exchange, wherein validating task allocations across nodes ensures that execution dependencies between the options contract and the underlying stock trade are satisfied.

9. The method of claim 6, wherein receiving the CAT request from the secondary node comprises:(a) constructing the CAT request based on a predefined strategy that specifies:(i) an independent task defining execution parameters for a primary trade involving an options contract, including contract type, strike price, expiration, and quantity; and(ii) a dependent task defining execution parameters for a secondary trade involving an underlying stock, including stock symbol, quantity, and hedge ratio;(b) determining execution dependencies between the independent task and the dependent task based on the predefined strategy, wherein execution of the dependent task is contingent upon parameters derived from the execution of the independent task; and(c) associating the predefined strategy with a task integrity parameter that enforces atomic execution of the independent and dependent tasks, such that either all tasks are executed successfully or none are executed, thereby ensuring consistency across the distributed computing environment.

10. A coordination engine for coordinating atomic processing of dependent data transactions in a distributed computing environment, the coordination engine comprising processor for executing a aggregation module configured to(a) receive a composite atomic task (CAT) request from a secondary node, the CAT request including an independent task and a dependent task; the independent task originating from a primary node to the secondary node;(b) query additional nodes for participation in the CAT request;(c) determine if one or more additional nodes agree to assume part of the CAT request;(d) if none of the additional nodes agree to assume part of the CAT request:(i) allocate the CAT to the secondary node; and(ii) allocate the independent task from the CAT to the secondary node;(e) if at least one additional node agrees to assume part of the CAT request, determining if the additional nodes agree to assume all of the CAT request;(f) if all of the CAT request is assumed by the additional nodes:(i) allocate the entire CAT to the additional nodes;(ii) allocate the independent task from the CAT to the additional nodes; and(iii) allocate the dependent task from the CAT to the additional nodes;(g) if only a part of the CAT request is assumed by the additional nodes:(i) allocate a first portion of the CAT to the additional nodes;(ii) allocate a second portion of the CAT to the secondary node;(iii) allocate a first portion of the independent task from the CAT to the additional nodes;(iv) allocate a second portion of the independent task from the CAT to the secondary node;(v) allocate a first portion of the dependent task from the CAT to the additional nodes; and(vi) allocate a second portion of the dependent task from the CAT to the secondary node;(h) delete any unallocated portions of the CAT request;(i) validate task allocations across nodes to ensure execution dependencies are intact.

11. The coordination engine claim 10, wherein the query of additional nodes for participation in the CAT request comprises transmitting a capability query to each additional node, the capability query including execution parameters, resource requirements, and task dependencies associated with the CAT request.

12. The coordination engine claim 10, wherein the determining if one or more additional nodes agree to assume part of the CAT request comprises evaluating responses based on predefined thresholds for resource availability, processing capacity, and latency constraints.

13. The coordination engine claim 10, wherein the validating task allocations across nodes comprises generating a validation log that tracks task allocation status, execution timestamps, and dependency fulfillment for each node involved in processing the CAT request.

14. The coordination engine claim 10, wherein the processor is further configured to, prior to deleting unallocated portions of the CAT request, transmit a reallocation request to the secondary node to determine if the secondary node can assume execution of the unallocated portions based on updated resource availability.

15. The coordination engine of claim 10, wherein: the primary node comprises a client terminal associated with a market participant; the secondary node comprises an administrator terminal associated with a dealer; and the additional nodes comprise execution engines associated with market makers, wherein the CAT request from the secondary node comprises a task request to coordinate execution of a trade involving both an independent task associated with an options exchange and a dependent task associated with a stock exchange.

16. The coordination engine of claim 15, wherein: the market participant initiates with a trade order for an options contract from the client terminal; the dealer, via the administrator terminal, generates a corresponding CAT request that associates at least a portion of the options contract with the underlying stock according to a strategy;the execution engines associated with the market makers are queried to determine if they will assume execution of part or all of the independent and dependent tasks.

17. The coordination engine of claim 15, wherein the independent task comprises executing a trade for an options contract on a primary module configured as an options exchange, and the dependent task comprises executing a trade for the underlying stock on a secondary module configured as a stock exchange, wherein validating task allocations across nodes ensures that execution dependencies between the options contract and the underlying stock trade are satisfied.

18. The coordination engine of claim 15, wherein receiving the CAT request from the secondary node comprises:(a) constructing the CAT request based on a predefined strategy that specifies:(i) an independent task defining execution parameters for a primary trade involving an options contract, including contract type, strike price, expiration, and quantity; and(ii) a dependent task defining execution parameters for a secondary trade involving an underlying stock, including stock symbol, quantity, and hedge ratio;(b) determining execution dependencies between the independent task and the dependent task based on the predefined strategy, wherein execution of the dependent task is contingent upon parameters derived from the execution of the independent task; and(c) associating the predefined strategy with a task integrity parameter that enforces atomic execution of the independent and dependent tasks, such that either all tasks are executed successfully or none are executed, thereby ensuring consistency across the distributed computing environment.

19. A computer readable medium in accordance with any one of claim 1-9.

Images