Method, apparatus, and system for implementing orders with minimal latency

Abstract

A system and method for matching orders across multiple input ports is disclosed herein. The system may include multiple input ports, a processor, and a storage medium. The processor may be configured to receive multiple data packets from the input ports and define a first message and a second message, the first and second messages having a message type. The processor may be configured to order the first and second messages into a sequence of records based on one or more arbitration rules, evaluate the first and second messages based on the sequence of records to generate matching information, and publish the matching information through a network interface. The processor may be further configured to perform immediate publication of the sequence of records.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 482,798, filed February 2, 2023, entitled "METHODS, APPARATUSES, AND SYSTEMS FOR IMPLEMENTING A SECURITIES TRADING VENUE WITH MINIMAL LATENCY REACTION TIME SENSITIVE ORDERS," and U.S. Provisional Patent Application No. 63 / 503,628, filed May 22, 2023, entitled "PROJECTED MARKET DATA FEEDS, PUBLISHED INJECTED ORDERS, AND EXCHANGE INTEGRATED ALPHA AND EXTERNAL EVENT INJECTION," the contents of each of which are incorporated herein by reference in their entirety.

[0002] SUMMARY OF THE INVENTION The embodiments disclosed herein generally relate to systems and methods for matching orders by observing sequences of messages received and accepted by an exchange. [Background technology]

[0003] In existing electronic markets, many algorithmic trades are based on market data published by trading venues. Often, a single published market data message prompts multiple participants to respond. For example, a trading venue may publish a message indicating that a trade has been made at an offer price. This trade may indicate or trigger a recognition that the price is likely to rise (e.g., the price is already trending upward) at the time of the offer. Upon receiving that published trade event, market makers and algorithmic trading participants may compete to buy more at the current offer price (possibly buying everything available) or may compete to cancel their offers to sell at that price.

[0004] This sequence of events, i.e., the publication of new market data (hereafter also referred to as exogenous events, market tick events) and the corresponding orders (or order cancellations) submitted by market participants in response, is known as the tick-to-trade race.

[0005] Tick-to-trade competition is a result of existing exchange architectures, which generally consist of network equipment for serializing incoming participant messages to a matching engine that may implement a price time matching algorithm.

[0006] A price-time matching algorithm is used to determine which orders are matched with each other to form a trade. If an order is submitted to the market at a market price (e.g., a price that meets or exceeds the best contra-side price, commonly referred to as the price above the spread), it is matched with a contra-side order. The contra-side order is selected first by the one offering the best contra-side price, e.g., with price priority, and second by the contra-side order submitted first, e.g., with time priority.

[0007] While price time matches intuitions of fairness in many scenarios, when tick-to-trade competition occurs, the outcome of price time matching may appear less desirable. For example, one participant may wish to cancel a previously issued quote based on an exogenous event, while another participant may wish to interact with that quote on the same basis. Assuming each of these participants achieves the same reaction time, their respective orders and cancellations will arrive at the electronic market at the same time. Using price time, one of the apparently simultaneous orders (or cancellations) must be selected first. Thus, for example, if both participants (a liquidity taker wanting to trade and a liquidity provider wanting to cancel) respond with the same criteria, one participant is likely to be able to interact with a quote that the other participant wishes to cancel. This scenario effectively results in one participant approving a trade that the other participant did not wish to participate in on the same basis as the other participant wished to trade, and it is difficult to judge this outcome as precisely consistent with creating or supporting a better or more efficient market. Therefore, participants are incentivized to minimize their reaction time.

[0008] Other tick-to-trade races also exist. For example, when the innermost ask (bid) price level opens (e.g., all resting orders at a given price are removed from the order book by matching or cancellation), market participants may compete to issue new resting quotes (offers) (e.g., to be first in line for the final matching) to form a new price level on the other side of the book (sometimes called issuing quotes, or resting bids, bids, offers, or asks).

[0009] Tick-to-trade competition forces participants to invest in fast response times and pressures exchanges to provide proximity through co-location and equal access (e.g., equal cable lengths from co-located servers to exchange network intakes). Even if two orders arrive at the exchange simultaneously, exchange network equipment serializes one before the other (e.g., randomly selects which order advances first). The order that advances first (the winning order) has the advantage, for example, of being able to execute against all of the liquidity available at a given price.

[0010] Thus, orders, cancellations, and other messages in response to certain exogenous events are, in effect, arbitrarily ordered by existing electronic trading venues. This arbitrary ordering is an inherent consequence of current mainstream electronic financial exchange architectures and may not produce fair or equitable results if multiple participants respond on the same basis (based on the same new public information).

[0011] As noted above, mainstream exchange architectures consisting of network equipment for serializing sequences of network messages (including participant orders and order cancellations) to a matching engine lead to uneconomical investments in speed technology and to markets that are inferior to more robust and competitive markets, as certain participants with speed disadvantages are unable to participate when they could have if their speed disadvantages were mitigated. Summary of the Invention [Problem to be solved by the invention]

[0012] Thus, disclosed herein are systems and methods for quickly or immediately publishing exchange market data and market events without any intermediation or processing delays from or by a matching engine, to minimize participant reaction times, to allow all participants to respond at equal speeds to exchange published information, to minimize delays in publishing exchange market data and market events, and for entering or sending participant orders or order cancellations, or other participant requests or API calls, based on any information, market events, or market data aggregated at the exchange itself. [Means for solving the problem]

[0013] In some embodiments, a system for managing a plurality of input ports includes a plurality of input ports including a first input port and a second input port, at least one processor, and a non-transitory processor-readable storage medium. A non-transitory processor-readable storage medium may include one or more programming instructions that, when executed, cause at least one processor to: receive a plurality of data packets from a first input port and a second input port, a first portion of the plurality of data packets defining a first message and a second portion of the plurality of data packets defining a second message, each of the first message and the second message including at least one message type of an order message, a cancel message, a trigger order message, or a limit order message; match the first portion of the plurality of data packets with the first message and match the second portion of the plurality of data packets with the second message; order the first message and the second message within a sequence of records based on one or more arbitration rules; publish the sequence of records through a network interface; after publishing the sequence of records, evaluate orders associated with the first message and the second message using a matching algorithm based on the sequence of records to generate matching information; and publish the matching information through the network interface.

[0014] In some embodiments, the first message is a trigger order message, and the one or more programming instructions further cause the processor to: store the trigger order message in a trigger order queue, the trigger order queue including a trigger condition for the trigger order message; evaluate a status of the trigger condition based on at least one of the second message, the received external condition, and the matching information; and enter an order underlying the first message in the sequence of records based on the evaluation.

[0015] In some embodiments, the one or more programming instructions that cause a processor to publish a sequence of records over a network interface further cause the processor to omit the first message from the publication.

[0016] In some embodiments, the first message is a hidden limit order message, and the one or more programming instructions further cause the processor to: store the hidden limit order message in a hidden limit order queue, the hidden limit order queue including a trigger condition for the hidden limit order message; evaluate a status of the trigger condition based on at least one of the second message and a change in display liquidity associated with the second message; and enter the order underlying the first message in the sequence of records based on the evaluation.

[0017] In some embodiments, the one or more programming instructions that cause the processor to publish the sequence of records through a network interface further cause the processor to edit a portion of the first message.

[0018] In some embodiments, the one or more programming instructions that cause the processor to evaluate the status of the trigger condition further cause the processor to determine message information associated with a second message including at least one of a symbol, a price, and a quantity, and compare the message information to the trigger condition.

[0019] In some embodiments, the one or more programming instructions further cause the processor to receive a third-party market data packet on at least one of the plurality of input ports.

[0020] In some embodiments, the one or more programming instructions further cause the processor to receive a regulatory information data packet at at least one of the plurality of input ports.

[0021] In some embodiments, the first message arrives at the first input port detectably concurrently with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input port in a rotating sequence.

[0022] In some embodiments, the first message arrives at the first input port detectably concurrently with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input port according to an arbitration scheme.

[0023] In some embodiments, the one or more programming instructions further cause the processor to determine whether the first message is at least one of fraudulent and invalid, where the first message is fraudulent if the first message does not include required identifying information sufficient to verify an authorized market participant and the first message is invalid if a parameter of the first message is outside a predetermined threshold range, and based on the determination, omit the first message from the sequence of records.

[0024] In some embodiments, the identification information includes a shared secret key generated by at least one of a symmetric cryptography and a public key cryptography.

[0025] In some embodiments, the identification information comprises an authentication token.

[0026] In some embodiments, the system includes a liquidity tracking unit configured to track an aggregate amount of liquidity of an asset associated with at least one of the first message and the second message.

[0027] In some embodiments, the one or more programming instructions further cause the processor to publish hypothetical future market data.

[0028] In some embodiments, the one or more programming instructions further cause the processor to generate a trigger order message, the trigger condition being based on hypothetical future market data.

[0029] In some embodiments, the first message is a trigger order message, and the one or more programming instructions further cause the processor to: store the trigger order message in a trigger order queue, the trigger order queue including a trigger condition for the trigger order message; evaluate a status of the trigger condition based on the co-hosted predictive model; and enter an order underlying the first message in the sequence of records based on the status.

[0030] In some embodiments, a method for managing a plurality of input ports includes receiving, by a processor, a plurality of data packets from a plurality of input ports, including a first input port and a second input port, wherein a first portion of the plurality of data packets defines a first message and a second portion of the plurality of data packets defines a second message, and wherein the first message and the second message each include at least one message type of an order message, a cancel message, a trigger order message, or a hidden limit order message; matching, by the processor, the first portion of the plurality of data packets with the first message and matching, by the processor, the second portion of the plurality of data packets with the second message; ordering, by the processor, the first message and the second message within a sequence of records based on one or more arbitration rules; publishing, by the processor, the sequence of records through a network interface; after publishing, by the processor, evaluating, by the processor, orders associated with the first message and the second message using a matching algorithm based on the sequence of records to generate matching information; and publishing, by the processor, the matching information through the network interface.

[0031] In some embodiments, the first message is a trigger order message, and the method further includes storing, by the processor, the trigger order message in a trigger order queue, the trigger order queue including a trigger condition for the trigger order message; evaluating, by the processor, a status of the trigger condition based on at least one of the second message, the received external condition, and the matching information; and entering, by the processor, an order underlying the first message in the sequence of records based on the status.

[0032] In some embodiments, the method further includes omitting the first message from the publication of the sequence of records based on a message type of the first message.

[0033] In some embodiments, the first message is a hidden limit order message, and the method further includes storing, by the processor, the hidden limit order message in a hidden limit order queue, the hidden limit order queue including a trigger condition for the hidden limit order message; evaluating, by the processor, a status of the trigger condition based on at least one of the second message and a change in display liquidity associated with the second message; and entering, by the processor, an order underlying the first message in a sequence of records based on the evaluation.

[0034] In some embodiments, publishing the sequence of records further includes redacting a portion of the first message.

[0035] In some embodiments, evaluating the status of the trigger condition further includes determining, by the processor, message information associated with the second message including at least one of a symbol, a price, and a quantity, and comparing, by the processor, the message information to the trigger condition.

[0036] In some embodiments, the method further includes receiving, by the processor, a third-party market data packet at at least one of the plurality of input ports.

[0037] In some embodiments, the method further includes receiving, by the processor, the regulatory information data packet at at least one of the plurality of input ports.

[0038] In some embodiments, the first message arrives at the first input port detectably concurrently with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input port in a rotating sequence.

[0039] In some embodiments, the first message arrives at the first input port detectably concurrently with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input port according to an arbitration scheme.

[0040] In some embodiments, the method further includes determining, by the processor, whether the first message is at least one of fraudulent and invalid, wherein the first message is fraudulent if the first message does not include required identifying information sufficient to verify an authorized market participant and the first message is invalid if a parameter of the first message is outside a predetermined threshold range, and omitting, by the processor, the first message from the sequence of records based on the determination.

[0041] In some embodiments, the identification information includes a shared secret key generated by at least one of a symmetric cryptography and a public key cryptography.

[0042] In some embodiments, the identification information comprises an authentication token.

[0043] In some embodiments, the method further includes tracking, by the processor, at a liquidity tracking unit, an aggregate liquidity amount of the asset associated with at least one of the first message and the second message.

[0044] In some embodiments, the method further includes publishing the hypothetical future market data.

[0045] In some embodiments, the method further includes generating, by the processor, a trigger order message, wherein the trigger condition is based on hypothetical future market data.

[0046] In some embodiments, the first message is a trigger order message, and the method further includes storing, by the processor, the trigger order message in a trigger order queue, the trigger order queue including a trigger condition for the trigger order message; evaluating, by the processor, a status of the trigger condition based on the co-hosted predictive model; and entering, by the processor, an order underlying the first message in the sequence of records based on the status.

[0047] In some embodiments, a system for managing a plurality of input ports includes a plurality of input ports including a first input port and a second input port, at least one processor, and a non-transitory processor-readable storage medium, the non-transitory processor-readable storage medium, when executed, includes receiving a plurality of data packets from the first input port and the second input port, a first portion of the plurality of data packets defining a first message, a second portion of the plurality of data packets defining a second message, the first message being a trigger order message and the second message including at least one message type of an order message, a cancel message, a trigger order message, or a limit order message; matching the first portion of the plurality of data packets with the first message and matching the second portion of the plurality of data packets with the second message; ordering the second message in a sequence of records based on one or more arbitration rules; and sending the first message to a trigger order queue. The storing may include one or more programming instructions that cause at least one processor to: store, wherein the trigger order queue includes a trigger condition for a first message; evaluate a status of the trigger condition based on at least one of the second message, the received external condition, and historical matching information; enter an order underlying the first message in a sequence of records based on the evaluation; evaluate, using a matching algorithm, the orders associated with the first message and the second message based on the sequence of records to generate matching information; and publish the matching information through a network interface.

[0048] In some embodiments, the one or more programming instructions further cause the processor to expose the sequence of records through a network interface before using the matching algorithm.

[0049] In some embodiments, the one or more programming instructions further cause the processor to omit the second message from the publication of the sequence of records based on a message type of the second message.

[0050] In some embodiments, the second message is a hidden limit order message, and the one or more programming instructions further cause the processor to: store the hidden limit order message in a hidden limit order queue, the hidden limit order queue including a trigger condition for the hidden limit order message; evaluate a status of the trigger condition based on at least one of the third message and a change in display liquidity associated with the third message; and enter the order underlying the second message in the sequence of records based on the evaluation.

[0051] In some embodiments, the one or more programming instructions that cause the processor to publish the sequence of records through the network interface further cause the processor to edit a portion of the second message.

[0052] In some embodiments, the one or more programming instructions that cause the processor to evaluate the status of the trigger condition further cause the processor to determine message information associated with a second message including at least one of a symbol, a price, and a quantity, and compare the message information to the trigger condition.

[0053] In some embodiments, the one or more programming instructions further cause the processor to receive a third-party market data packet on at least one of the plurality of input ports.

[0054] In some embodiments, the one or more programming instructions further cause the processor to receive a regulatory information data packet at at least one of the plurality of input ports.

[0055] In some embodiments, the first message arrives at the first input port detectably concurrently with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input port in a rotating sequence.

[0056] In some embodiments, the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input according to an arbitration scheme.

[0057] In some embodiments, the one or more programming instructions further cause the processor to determine whether the second message is at least one of fraudulent and invalid, where the second message is fraudulent if the first message does not include required identifying information sufficient to verify an authorized market participant and the second message is invalid if a parameter associated with the first message is outside a predetermined threshold range, and based on the determination, omit the second message from the sequence of records.

[0058] In some embodiments, the identification information includes a shared secret key generated by at least one of a symmetric cryptography and a public key cryptography.

[0059] In some embodiments, the identification information comprises an authentication token.

[0060] In some embodiments, the system further includes a liquidity tracking unit configured to track an aggregate amount of liquidity of an asset associated with at least one of the first message and the second message.

[0061] In some embodiments, the one or more programming instructions further cause the processor to publish hypothetical future market data.

[0062] In some embodiments, the one or more programming instructions further cause the processor to generate a new trigger order message, wherein a new trigger condition associated with the new trigger order message is based on hypothetical future market data.

[0063] In some embodiments, the one or more programming instructions that cause the processor to evaluate the status of the trigger condition are further based on a co-hosted predictive model.

[0064] In some embodiments, a method for managing a plurality of input ports includes receiving, by a processor, a plurality of data packets from a plurality of input ports, including a first input port and a second input port, a first portion of the plurality of data packets defining a first message, a second portion of the plurality of data packets defining a second message, the first message being a trigger order message and the second message including at least one message type of an order message, a cancel message, a trigger order message, or a limit order message; matching, by the processor, the first portion of the plurality of data packets to the first message and matching the second portion of the plurality of data packets to the second message; and reconciling, by the processor, a sequence of records based on one or more arbitration rules. and ordering the second message based on the received external condition; storing, by the processor, the first message in a trigger order queue, the trigger order queue including a trigger condition for the first message; evaluating, by the processor, a status of the trigger condition based on at least one of the second message, the received external condition, and historical matching information; entering, by the processor, an order underlying the first message in a sequence of records based on the evaluation; evaluating, by the processor, using a matching algorithm, the orders associated with the first message and the second message based on the sequence of records to generate matching information; and publishing, by the processor, the matching information through a network interface.

[0065] In some embodiments, the method further includes exposing the sequence of records through a network interface before using the matching algorithm.

[0066] In some embodiments, the method further includes omitting the second message from the publication of the sequence of records based on a message type of the second message.

[0067] In some embodiments, the second message is a hidden limit order message, and the method further includes storing, by the processor, the hidden limit order message in a hidden limit order queue, the hidden limit order queue including a trigger condition for the hidden limit order message; evaluating, by the processor, a status of the trigger condition based on at least one of the third message and a change in display liquidity associated with the third message; and entering, by the processor, an order underlying the second message in a sequence of records based on the evaluation.

[0068] In some embodiments, publishing the sequence of records further includes redacting a portion of the second message.

[0069] In some embodiments, evaluating the status of the trigger condition further includes determining, by the processor, message information associated with the second message including at least one of a symbol, a price, and a quantity, and comparing, by the processor, the message information to the trigger condition.

[0070] In some embodiments, the method further includes receiving, by the processor, a third-party market data packet at at least one of the plurality of input ports.

[0071] In some embodiments, the method further includes receiving, by the processor, the regulatory information data packet at at least one of the plurality of input ports.

[0072] In some embodiments, the first message arrives at the first input port detectably concurrently with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input port in a rotating sequence.

[0073] In some embodiments, the first message arrives at the first input port detectably concurrently with the second message arriving at the second input port, and the one or more arbitration rules include selecting the first input port and the second input port according to an arbitration scheme.

[0074] In some embodiments, the method further includes determining, by the processor, whether the second message is at least one of fraudulent and invalid, wherein the second message is fraudulent if the first message does not include required identifying information sufficient to verify an authorized market participant and the second message is invalid if a parameter associated with the first message is outside a predetermined threshold range, and omitting, by the processor, the second message from the sequence of records based on the determination.

[0075] In some embodiments, the identification information includes a shared secret key generated by at least one of a symmetric cryptography and a public key cryptography.

[0076] In some embodiments, the identification information comprises an authentication token.

[0077] In some embodiments, the method further includes tracking, by the processor, at a liquidity tracking unit, an aggregate liquidity amount of the asset associated with at least one of the first message and the second message.

[0078] In some embodiments, the method further includes publishing, by the processor, hypothetical future market data.

[0079] In some embodiments, the method further includes generating, by the processor, a new trigger order message, wherein a new trigger condition associated with the new trigger order message is based on hypothetical future market data.

[0080] In some embodiments, evaluating the status of the trigger condition is further based on a co-hosted predictive model.

[0081] Further features of the present disclosure, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It should be noted that the present disclosure is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Further embodiments will be apparent to those skilled in the relevant art(s) based on the teachings contained herein. [Brief explanation of the drawings]

[0082] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate the present disclosure and, together with the description, further serve to explain the principles of the present disclosure and to enable a person skilled in the relevant art(s) to make and use the embodiments described herein.

[0083] [Figure 1] 1 illustrates a stock exchange and system architecture implementing a matching engine according to an exemplary embodiment of the present disclosure.

[0084] [Figure 2A] 1 illustrates a stock exchange and system architecture with minimal latency reaction times, according to an exemplary embodiment of the present disclosure.

[0085] [Figure 2B] 1 illustrates an example of a data packet, according to an exemplary embodiment of the present disclosure.

[0086] [Figure 3A] 1 illustrates an order entry box according to an exemplary embodiment of the present disclosure.

[0087] [Figure 3B] 1 illustrates message order injection logic according to an exemplary embodiment of the present disclosure.

[0088] [Figure 4] 1 illustrates an exchange and system architecture for a condition evaluator, according to an exemplary embodiment of the present disclosure.

[0089] [Figure 5] 1 illustrates a trading algorithm that utilizes a predictive model.

[0090] [Figure 6] 1 illustrates a stock exchange and system architecture implementing a book builder and trade announcer according to an exemplary embodiment of the present disclosure.

[0091] [Figure 7] 1 illustrates a flowchart of a method for prioritizing trigger orders, triggering from the same event, according to an exemplary embodiment of the present disclosure.

[0092] [Figure 8] 1 illustrates a trigger order generator for use in a securities exchange and system according to an exemplary embodiment of the present disclosure.

[0093] [Figure 9] 1 illustrates a flowchart of an algorithm for participant-hosted event / order pair evaluation, according to an exemplary embodiment of the present disclosure.

[0094] [Figure 10] 1 illustrates a flowchart of an algorithm for exchange-hosted event / order pair valuation, according to an exemplary embodiment of the present disclosure.

[0095] [Figure 11] 1 illustrates a flowchart of a trading algorithm that utilizes projected market data, according to an exemplary embodiment of the present disclosure.

[0096] [Figure 12] 1 illustrates a flowchart of multiple trading algorithms utilizing exchange public forecast market data feeds, according to an exemplary embodiment of the present disclosure.

[0097] [Figure 13] 1 illustrates a stock exchange and system architecture integrating predictive models according to an exemplary embodiment of the present disclosure.

[0098] [Figure 14] 1 illustrates a flowchart of a method for managing orders across multiple input ports, according to an exemplary embodiment of the present disclosure.

[0099] [Figure 15] 1 illustrates a block diagram of a computing device according to an exemplary embodiment of the present disclosure.

[0100] Features of the present disclosure will become more apparent from the detailed description set forth below in conjunction with the drawings, in which like reference numerals identify corresponding elements throughout. In the drawings, like reference numerals generally indicate identical, functionally similar, and / or structurally similar elements. Furthermore, the left-most digit(s) of a reference number generally identifies the drawing in which the reference number first appears. Unless otherwise indicated, the drawings provided throughout this disclosure should not be construed as drawings to scale. DETAILED DESCRIPTION OF THE INVENTION

[0101] An introduction to closed-loop reaction time latency

[0102] SUMMARY The present disclosure generally relates to systems and methods for matching orders by observing sequences of messages received, accepted, and modified by an exchange.

[0103] Disclosed herein is an architecture that can be implemented as software or hardware, for example, as a single discrete application-specific integrated circuit (ASIC) hardware device with the necessary software, or as several ASIC hardware devices with the necessary software, or as a field programmable gate array (FPGA) or several FPGA hardware devices with software support. Software embodiments can be implemented by stored programs running on existing networking hardware devices, central processing units (CPUs), graphics processing units (GPUs), tensor processing units (TPUs), or other computing devices capable of executing stored programs.

[0104] In existing exchange architectures, participants can respond to the actions of other market participants when information about those actions is made public. We refer to the information that triggers a response as an exogenous event or exogenous information. In certain cases, the publication of the exogenous event or information is delayed by processing internal to the exchange, e.g., by processing in the exchange matching engine. Receipt of the publication of market data information by market participants, who can act on the information, can be further delayed by the requirement to transmit the information over an electronic network, which can occur, for example, through network equipment such as routers and switches, over network cables, over fiber optic cables, or wirelessly via WiFi, microwave, or other RF transmissions. Clearly, some time elapses between the initiation of the exogenous event (when one participant takes action) and the time another participant responds (it is not possible for one participant to respond to another participant without some time having elapsed). We refer to this elapsed time as the closed-loop reaction time latency. Instant Market Data

[0105] The architecture disclosed herein reduces total closed-loop reaction time latency. The disclosed architecture publishes messages immediately. Specifically, the disclosed architecture publishes messages, market data, or market events without unnecessary processing, e.g., by a matching engine. We refer to this market data, published without processing delays and latencies in the matching engine, as real-time market data. Such real-time market data may be in a form such that any interested entity (trader, algorithm, etc.) can reconstruct the state of the order book (e.g., by observing that orders or order cancellations added or removed liquidity at specific prices) and potentially infer that some orders, some orders, a specific order, or several specific orders were matched as trades, or in either case, that some previously offered quantity may be traded, executed, or removed. In certain embodiments, participants subscribed to the real-time market data may be able to identify which particular resting order(s) were matched or deleted, for example, based on the publication of cross orders or order cancellations, respectively. In certain other embodiments, participants subscribed to the real-time market data may not be able to identify the specific individual orders that were matched or deleted, but may still be able to identify and reconstruct the aggregate remaining liquidity at a given price point. The real-time market data may have certain information redacted from its upstream originating messages, e.g., information that may need to be kept confidential by the trading venue for some reason or that may be desired to be kept confidential by the originating market participant. The redacted information may be removed from the data stream by erasing the message fields (e.g., zeroing the data) or by reconstructing the data into a new template (i.e., a privacy template) that does not include the particular message field. Trigger Order

[0106] Additionally, the architecture described herein can also implement trigger orders or predicate orders on behalf of any market participant. A trigger order is composed of an underlying order and a trigger condition or predicate. When a trigger order is issued, the underlying order is not immediately effective; rather, the underlying order is intended to be effective upon or shortly after receipt of new information that satisfies the trigger order's condition or predicate. Thus, an issued or effective trigger order represents the possibility that the underlying order may be effectively issued, conditional on the result of its trigger condition or predicate being satisfied. Any type of information, message, market data, or market event observed by a system or method implementing a trigger order (whether that information comes from a market participant, an external data source, or an exchange-internal data source) can trigger or cause an underlying order to be issued on behalf of a given participant (the sender of the trigger order or predicate order). The underlying order so submitted (triggered or issued) is input into the disclosed architecture for processing and possible interaction with other orders (it would not be permitted to interact with orders of other participants prior to its submission or the time it is triggered). The underlying order so submitted, submitted, or triggered may be serialized into message sequences processed by the exchange, serialized into message sequences or market data sequences published by the exchange, and may further trigger other triggers or predicate orders. Order Entry Box (OEB)

[0107] The architecture disclosed herein implements an electronic trading venue (for electronically traded securities or other assets, e.g., stocks, bonds, futures, options, Treasury bills, swaps, cryptocurrencies, crypto tokens, or any other electronically traded asset) that minimizes latency reaction time-sensitive orders. In certain embodiments, the architecture is described under the name Order Entry Box, or OEB. The OEB architecture may reduce the delay between the arrival of a new participant order and its publication to participants as market data. The OEB architecture may host trigger orders and / or hidden limit orders on behalf of all market participants. The use of trigger orders may reduce the reaction time delay between the arrival of an exogenous event and a participant's order or order change in response to that event. The OEB may be implemented as logic expressed in hardware devices, such as FPGAs or ASICs, as a separate computing platform, or as logic expressed in software, and any representation, implementation, or realization of the OEB may be incorporated into or embedded in a matching engine. The architecture may further include additional mechanisms, implemented as software along with ASIC hardware, FPGA hardware, or other necessary networking devices, that provide support and interfaces to existing exchange and trading system architectures. For example, the architecture described herein may include additional units that build and publish book state as top-of-book and depth-of-book market data update messages. The architecture may include one or more additional units that aggregate and publish individual orders into a structured order book, and one or more additional units that identify matching orders and publish messages indicating individual or aggregated trades (trade summaries), all of which may replace or supplement the functionality of the matching engine; these additional units may be referred to as a book builder and a trade announcer, respectively.

[0108] Additionally, described herein are mechanisms for assisting market participants in using the trading techniques disclosed herein, which may be implemented in any of the disclosed ways (single or multiple ASIC devices, single or multiple FPGA devices, and / or software with necessary networking devices). In particular, a trigger order generator and a trigger order management unit are described herein. Message flow-through design

[0109] Certain hardware embodiments may employ a flow-through design in which messages are processed with no or minimal queuing or processing delays incurred by processing program instructions sequentially. That is, messages flow through a processing pipeline from start to finish and are typically published to participants immediately, i.e., upon exiting the processing pipeline. In one embodiment, the processing pipeline may consist of two stages, the first of which checks the validity (e.g., authentication) of incoming messages, and the second of which compiles personal information. If both such stages are implemented such that messages do not need to be queued or otherwise held, for example, pending the retrieval of validation data from memory or for processing of instruction sequences, e.g., by software, the design is considered to be completely flow-through or backpressure-free. Embodiments with no or minimal backpressure provide the fastest message publication. Embodiments that target no or minimal backpressure as a design goal are referred to herein as flow-through or pipeline designs or embodiments.

[0110] As previously described, these same particular aspects of the present disclosure that may be suitable for the design of fully pipelined, minimal, or backpressure-free hardware or hardware / software co-design need not be implemented in hardware, although the same aspects of the present disclosure may provide superior, more efficient implementations in software, as processed by a CPU, GPU, TPU, or other computing device executing a stored program.

[0111] The embodiments described herein, whether software, hardware, or both, provide significant reductions in message processing latency compared to existing electronic trading venues, based on either instantaneous publication of market data, implementation of trigger orders, and a flow-through, minimal backpressure design.

[0112] The embodiments described herein may process incoming orders and messages in a pipelined manner, and at each pipeline processing stage, if implemented in a dedicated hardware unit, messages may be evaluated, modified, modified, or queued over a period of time. However, messages may not need to be cached in a CPU cache or stored in a separate (i.e., separate from the queuing logic) memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In one embodiment, the published message is substantially the same message as sent by the market participant, except that certain identifying information or other security- or authenticity-sensitive details have been redacted, removed, disabled, or randomized. In some embodiments, the published message may be constructed anew based on input, such as the input message being processed.

[0113] The latency reduction (i.e., increased speed and / or throughput) is expected to be the same whether published messages are streamed as is or created as separate new messages according to the input. Furthermore, some embodiments may employ an intermediate or flow-through approach depending on the type of message or order being processed or reacted to. The different flow-through and intermediate embodiments are expected to achieve the same benefits as all other hardware implementations described herein.

[0114] Existing electronic financial exchanges (such as stock exchanges, futures, options, or currency exchanges, as well as exchanges that trade other derivatives, cryptocurrencies, or crypto tokens) and alternative trading systems (ATSs) can be implemented with matching engines (MEs). Market participants can send orders (e.g., limit orders, marketable limit orders, immediate-or-cancel (IOC) limit or marketable limit orders, order cancellations, and other order types) via electronic messages. These order messages can originate from collocated computing resources or from remote sources (e.g., from an asset management firm's trading desk or from a brokerage firm that processes orders on behalf of investors).

[0115] FIG. 1 illustrates an architecture 100 of an electronic exchange and system that implements a matching engine.

[0116] Electronic trading exchange architectures are often comprised of server computing resources in a data center or a public or private cloud. Within the securities exchange system architecture 100, the server computing resources are operated by various entities, generally the exchange or trading venue operator (exchange side 155) and the market participants (participant side 105). Messages, including orders, order changes, order confirmations, order execution messages, regulatory information, session information, and other related information, are transmitted between and among the various computing resources in the form of network packets. Participant orders 110 and market data subscribers 120 reside on the participant side 105. The market gateway 150 and matching engine 160 reside on the exchange side 155.

[0117] Participant orders 110 may be sent first to an exchange cross-connect, then to a market gateway 150, and then to a matching engine 160. The matching engine 160 implements a matching protocol (e.g., price-time priority or pro rata) and publishes market data updates or messages to source market participants, such as market data subscribers 120. Published market data messages may include orders or limit orders submitted by market participants, indicate when orders are matched (i.e., when a trade occurs), and inform participants about the state of the book (e.g., aggregated bids and offers based on all orders submitted by market participants). These so-called book updates may be further subdivided into top-of-book and depth-of-book. Top-of-book represents the aggregate quantity available at the best bid or lowest ask price for a given venue or across multiple venues. The top-of-book for all U.S. stock venues is known as the National Best Bid and Offer (NBBO), or NBBO.

[0118] Depth-of-book updates publish the quantity of sales or offers at prices lower than the best bid or offer. Published book updates may be generated as a result of participants submitting non-marketable limit orders (i.e., limit orders with limit prices that are not immediately matched to existing bids or offers) with any validity period (e.g., valid today or valid until canceled). Trade, execution, match, or execution summary messages published in market data, or messages for other similar purposes, may include the security or security symbol traded, the matched price (trade price) and the matched quantity (trade quantity), and, depending on the matching engine protocol, may include the number of resting orders executed (orders that were waiting to be executed), or may indicate that a full or partial resting order has been executed.

[0119] Publicly available market data may include book updates (top of book, depth of book, or both) or other updates such as publicly available limit orders, which may indicate the price and quantity (shares, contracts, options contracts, smart contracts, units of currency, digital tokens, or cryptocurrency units) that participants are willing to trade, for example, an offer to buy 100 shares of a given tradable asset with symbol XYZ at a price of $99.99, or a bid to buy 50 shares of symbol XYZ at a price of $99.98.

[0120] Collectively, all bids and offers (whether published or not) that are issued and remain valid form an order book (which may also be called a continuous limit order book). Published bids and offers that are issued and remain valid form the published, displayed, or visible order book. The top of the book can be understood as the best bid and best offer (determined by the most competitive price bid to buy and the price offered to sell) and the respective quantities at the best bid and offer prices. For U.S. regulated National Market System (NMS) stocks, the order book is further aggregated across exchanges to form the national best bid (NBB) and national best offer (NBO) (the NBB and NBO together constitute the national best offer, or NBBO). An existing exchange or trading venue or ATS may publish depth-of-book (also called depth of liquidity) updates indicating fewer competitive prices being bid or offered.

[0121] The offered price points may be referred to as price levels or book levels. The order book can be understood as a top level and deeper levels, on both the bid side and the offer (ask) side. Each level can be understood as including a price, an aggregate quantity, and an aggregate number of orders, or alternatively, as a queue of orders (with time priority) at the price level, each order having its own quantity. The time priority of orders at the price level is typically established by the time (or sequence) the orders are received. Matching engine 160 may expose top-of-book and depth-of-book information in several ways, including as an aggregate level or as individual resting limit orders.

[0122] Additionally, matching engine 160 may keep certain limit orders private (or undisplayed or hidden). Some limit orders may be partially displayed (e.g., a limit order indicating an offer to sell 100 shares but a willingness to undisclose 500 shares). Marketable limit orders may interact with undisplayed (undisplayed) limit orders, in which case the trade is made public. The purpose of undisplayed or hidden liquidity is generally to allow market participants to attempt to trade at a given price without indicating to other market participants the size (or full size) of their interest in liquidating or acquiring a certain amount in a position.

[0123] Otherwise, if one participant discloses their intention to buy or sell (a potentially large position), other market participants may react by adjusting their prices to discourage participants attempting large trades. This is a reflection of supply and demand, where participants wanting to trade in large quantities either increase demand (thus driving up market prices) or increase supply (thus driving down market prices).

[0124] Some venues implement so-called speed bumps that artificially delay orders from certain market participants, i.e., allow time for other participants to cancel or reprice orders under certain market conditions. Some venues offer limit orders that are automatically repriced according to some criteria, for example, but not limited to, orders that are repriced when the NBBO changes.

[0125] Some important aspects of an electronic trading venue include cross-connects, market gateways (or gateways) 150, matching engines (MEs) 160, co-located participant computing resources, and the electronic network equipment that connects them. In current electronic trading venues, certain market participants may use algorithmic trading strategies that automatically submit orders, trades, and order cancellations on behalf of participants (by using rules that may be expressed in a manner similar to trigger orders, or by using predictive pricing models, or by a combination or permutation of these mechanisms). These automated trading algorithms may respond to exogenous events or information by submitting new orders, trades, or order cancellations. Latency-sensitive transactions in existing systems

[0126] In response to market conditions and exogenous or other new information, different participants may arrive at the same insights and trading decisions through algorithmic, rule-based, or other proprietary techniques. When submitting an order in response to new information, the participant that submits the order 110 first is typically the participant whose order is executed (or whose intent to trade is otherwise completed; for example, there are situations in which a participant may wish to cancel a previously valid quote, called a resting order, because they anticipated that prices would move in the opposite direction relative to their quote price). New information that may form the basis for a significant response, e.g., a new order or cancellation, can arrive in several different ways: from a local trading venue, from a different trading venue, from a news feed, from a third-party market data provider, and generally from any electronic information source. Based on the same new information, it may be common for different participants to arrive at the same market view and react accordingly, whether submitting an order 110 that may match a resting bid or offer or submitting a cancellation that may cancel a previous quote at an unfavorable price in the expected market conditions. If several participants reach the same conclusion at the same time, only some of them may be able to fully realize their trading intentions by executing orders or canceling now-outdated quotes. This dynamically sensitive participant, for whom it is desirable to submit an order first or quickly, is referred to as a latency-sensitive participant or a reaction-time-sensitive participant. Such latency-sensitive reactions may typically be triggered by trades or orders published within the same (called local) venue. In such a situation, a closed loop exists, formed by the components: market gateway 150, matching engine 160, collocated computing, and network. For this loop, a lower bound on reaction time may be determined as follows: 1) An event is first published by matching engine 160 and transmitted by the electronic network to collocated computing where an algorithmic trading strategy may be implemented. 2) Some specific trading algorithm consumes the locally generated event and generates a new order or order cancellation. 3) This order or cancellation message is transmitted by the electronic network from the algorithm hosted on the collocated computing to exchange market gateway 150 and then to matching engine 160, closing the loop. 4) Each item in this sequence and each network route has its own time cost (latency), and the sum of these latencies is a lower bound on the reaction time in this market. Minimizing reaction time latency in existing systems

[0127] Thus, participants are incentivized to minimize their decision logic latency. Algorithmic trading schemes may be based on very simple rules, such as a rule that initiates a trade if another participant is buying or selling, or they may be based on predictive models that attempt to determine the future price or return of a traded security based on specific inputs, which may include locally publicly available market data. Although the time to evaluate a predictive model is typically much longer than the time required to evaluate a simple rule, the predictive model may yield significantly better trading decisions. Thus, participants that utilize predictive models may use them to find rules that are applicable to the current market, including all information known to the participants.

[0128] This process may work as follows: The predictive model is first updated with current market conditions. Then, the predictive model is given a hypothetical event, i.e., an event that could occur but has not yet occurred. The predictive model generates a new prediction under the hypothesis of that event. This prediction may be a buy, sell, or cancel instruction, or a price or return prediction, or any other type of prediction. In response to that prediction, the algorithm may result in a buy, sell, or cancel order. If the algorithm results in such an order, i.e., in response to that hypothetical event, it discovers a new rule (specific to current market conditions) and sends the resulting order (buy / sell / cancel) if that particular hypothetical event occurs. The buy, sell, or cancel order may have specific parameters, such as a specific price, quantity, tradable asset, and other parameters determined by the originating algorithm.

[0129] The hypothetical event can be one or several events. Whether starting with a simple rule-based algorithm or using a predictive model to discover such rules, the result is an order that is premised on events, also called a triggered order (TO) or a predicated order (PO). The use of a triggered order or a predicated order can reduce the latency of the decision logic and thus give participants a speed or reaction time or latency advantage. In existing trading venues and exchanges, the triggered order is hosted on the participant's computing resources, e.g., co-located computing resources. Price-time matching in existing systems

[0130] In existing trading venues, exchanges, and alternative trading systems, market data is typically published by a matching engine 160, which implements a certain amount of logic both for publishing book updates and for identifying and publishing or announcing traded, executed, or matched orders. That published market data is driven by the incoming stream of participant orders 110 from market participants, but its publication is delayed by processing time incurred by the matching engine 160.

[0131] A venue may publish rules by which matches are assigned. For example, a trading venue may choose to use a price-time priority algorithm. In the price-time priority algorithm, if a new limit order to buy (or sell) has a matching price, i.e., a price higher (lower) than the lowest offer price (highest bid price) of a resting limit order on the book, a resting limit order to buy (or sell) is matched with the new order at the respective best price. A new order that matches or fills the price of a resting limit order is said to have exceeded the spread. An order that exceeds the spread is also called an aggressing order, and the matched order or orders are called the resting or passive order(s). If an aggressing order is large enough, it may execute by matching with several resting orders. If an aggressing order has a deep enough price, it may match with resting orders at several price levels. Within each price level, the priority with which resting orders are matched is based on the time those orders were received by the exchange. Specifically, within a given price level, the first arriving resting order is matched first, the second arriving resting order is matched second, and so on. Within such an exchange, a matching engine is responsible for implementing this so-called matching algorithm and publishing the results, commonly known as matches, crosses, executions, or trades. Order Match Inference

[0132] Using the published matching rules, any trader, algorithm, stakeholder, regulator, or other entity can infer either the state of the book and / or which orders have been matched if they can observe the sequence of messages received by and accepted by the exchange.

[0133] For example, if a participant can observe messages in the same sequence as observed by an exchange or trading venue, the participant can infer the state of the book and which orders were matched, i.e., which orders were executed against each other. Data Packet Example

[0134] The systems and methods disclosed herein are used to receive, transmit, enhance, analyze, and handle data packets in accordance with the description disclosed herein. Orders, trigger orders, order cancellations, and other units of usable transaction information or trading system metadata are described in data packets that are encoded and transmitted by machines and sent between machines using network equipment, as described herein. Data packets describing orders, and the act of sending an order from one machine to another, may be initiated by a human or a machine. Once received, such orders may be submitted to a queue or pipeline for further processing.

[0135] An example of a data packet order is shown in FIG. 2B. This figure shows portions of a data packet including a header 290, a payload 292, and a trailer 294. The header 290 may include routing information, formatting information, and authentication information. The payload 292 may include authentication information and information associated with the order, including, but not limited to, the order symbol, price, order type, bookside, limit, stock or quantity, validity time, and date. The trailer 294 may include authentication or integrity check data. Multiple data packets may form a frame. A frame may, in turn, include a header and a trailer. As described in more detail herein, a message may be split across multiple data packets arriving across multiple input ports. Individual packets from multiple messages may appear to arrive simultaneously into the system across multiple input ports. Exemplary Data Packet Payload

[0136] Below are examples of exemplary data packet payloads associated with the message types described herein. [Table 1]

[0137] The above exemplary data packet payload data types may be utilized by the system as follows:

[0138] Side: The side of the order (i.e., bid / offer or buy / sell).

[0139] Security ID: A unique identifier for the order.

[0140] Quantity: The quantity associated with the order.

[0141] Price: The price associated with the order.

[0142] Validity Time: The period during which the order can remain valid (e.g., valid today, valid until cancelled, immediate, or cancelled).

[0143] Participant ID: A unique identifier associated with a market participant.

[0144] Participant Authentication Data: Authentication information associated with a participant (e.g., a shared key or authentication token).

[0145] Predicate: The trigger condition of a trigger order.

[0146] Underlying Order: The associated order that is activated in response to the predicate being satisfied. The underlying order may be referenced by an identifier (e.g., security ID) to another message (e.g., a limit order).

[0147] Predicate Type: Classification of the trigger order as adding or removing liquidity.

[0148] Qualifier: A qualification of the trigger order's classification as liquidity removed by downsizing or cancellation, liquidity removed by order execution, or liquidity removed by any means.

[0149] Price Comparison Type: An operational qualification of the price comparison in the predicate evaluator (e.g., absolute value, delta greater than best ask, delta less than best bid).

[0150] Quantity comparison type: The operational qualification of a quantity comparison in a predicate evaluator (e.g., total quantity at a price level, change in quantity at a price level).

[0151] Min Quantity: The minimum quantity associated with the trigger condition.

[0152] Max Quantity: The maximum quantity associated with the trigger condition.

[0153] Min Price: The minimum price associated with the trigger condition.

[0154] Max Price: The maximum price associated with the trigger condition.

[0155] Previous Order ID: A reference to the security ID of the previous order in which the current order was modified (e.g., canceled, downsized, or otherwise changed).

[0156] Quantity Change: A quantity change associated with a change to a previous order.

[0157] Full Cancel?: If no previous order ID is given, a flag indicating that the change is a cancellation of the entire previous order or the entire amount of liquidity posted at the specified price.

[0158] The data packet payloads provided are merely examples. Other data packet payloads are contemplated. For example, the trigger order may alternatively fully integrate the data structure of the underlying order or portions thereof (e.g., participant authentication data). Examples of exchanges with minimal latency

[0159] FIG. 2A illustrates an electronic exchange and system architecture 200 with minimal latency response times, according to an exemplary embodiment of the present disclosure.

[0160] The electronic trading exchange architecture 200 includes computing resources operated by market participants (participant side 105) and computing resources operated by an exchange operator (exchange side 155). The participant order 110 and market data subscriber 120 reside on the participant side 105. The order entry box (OEB) 250, and the book builder 260 and trade announcer reside on the exchange side 155. Observation Sequence

[0161] OEB 250 receives as input participant orders 110 (e.g., limit orders, marketable limit orders, cancel, immediate or cancel limit or marketable limit orders, other types of orders, and other electronic messages) from market participants, and also receives as input information and market data from external programming, remote venues, or other OEBs, as well as information or market data from third-party data sources or regulatory or industry-standard data sources, and other necessary external information. OEB 250 receives participant orders and other messages, forms them into sequences, and then processes those participant orders and messages from said ordered sequences; each such sequence is hereinafter referred to as an observed sequence. Thus, an observed sequence refers to an ordered sequence of network packets, messages, or orders observed by a system entity, for example, by a component of OEB 250, a market data subscriber, a bookbuilder, a trade announcer, or another related system or method contributing to the implementation of an exchange or trading venue.

[0162] Network packets arriving from market participants may not be inherently structured as an observation sequence. In particular, such network packets may arrive at multiple network input ports, and some of the packets may appear to arrive simultaneously at different network input ports. In any case, the observation sequence requires that input network packets, messages, or orders be serialized one after the other according to their arrival times, and if any of them apparently arrive simultaneously, a decision must be made as to which of them should be serialized first, second, third, etc. The input observation sequence of the OEB may be constructed by external network equipment, e.g., a network switch capable of serializing packets from multiple input ports, or by network equipment integrated or embedded in the OEB.

[0163] Thus, for example, a given set of input network packets with particular inputs read from the network simultaneously on different input ports may result in different observation sequences depending on so-called arbitration logic or rules. However, given a particular input observation sequence, it will always result in the same outcome when processed by the trading system disclosed herein, e.g., the same set of matching orders or otherwise withdrawn, canceled, or inactive orders. This serialized sequence of orders, messages, and programming events 110 from market participants may be recorded for post-session audit and compliance.

[0164] Certain embodiments described herein may publish real-time market data such that market data subscribers, market participants, and market observers may infer that an order was executed, traded, or matched, but may not be able to infer exactly which order, or which underlying order, was matched.

[0165] Messages published by OEB 250 may optionally be anonymized, although certain incoming participant orders 110 may optionally not be published (e.g., if they are invalid or marked as not displayed, partially not displayed, hidden, or partially hidden). Other information may optionally be redacted from published messages, for example, if a particular market participant submitted an order with an authentication token, the authentication token may be redacted before the order is published to all market participants.

[0166] A given OEB 250 may process orders and messages for a security or exchange-traded financial instrument (e.g., stocks, futures contracts, options contracts, currencies, cryptocurrencies, tokens, crypto tokens, derivative contracts for any of these, or other exchange-traded products). Alternately, a given OEB 250 may process multiple participant orders 110 and messages. For example, a given OEB 250 may process participant orders 110 and messages for two or more stock symbols, such as Apple (AAPL) and Amazon (AMZN). The OEB 250 may process orders and messages for as many different trading instruments as is feasible given its design capabilities.

[0167] The matching algorithm used by the exchange or venue operating OEB 250 may be selected so that a given set of inputs, when serialized into a particular observed sequence, always produces the same result—for example, so that the same orders are matched as executed trades. That is, the participant orders 110 that are matched and executed (and canceled or otherwise not executed) can be inferred from pairing a particular matching algorithm (or matching rule) with a particular serialized sequence of input orders. For a given trading session, the matched participant orders 110 follow as a logical consequence of the particular matching algorithm or matching rule and the sequence of orders and messages observed after serialization.

[0168] The observed sequence of orders and messages may include various types of orders or messages, including, but not limited to, limit orders, marketable limit orders, market orders, hidden limit orders, silent orders, immediate or cancelled (IOC) orders, current day orders, good-until-cancelled (GTC) orders, market-on-open (MOO), limit-on-open (LOO), market-on-close (MOC), limit-on-close (LOC), and other order types known but not contemplated herein, as well as other order types not yet known or contemplated but which may be consistent with the present disclosure.

[0169] The observation sequence may also include specific messages indicating the trading state, such as, for example, available for trading or unavailable for trading, or the location (possibly price and quantity or other details) of the NBB, NBO, or NBBO. The observation sequence may also include specific messages indicating the time window of the auction matching protocol, such as, for example, to open the auction or to close the auction. The matching algorithm or rule may be price-time, pro rata, auction, batch auction, or any known, contemplated, or yet unknown matching algorithm or rule consistent with the present disclosure.

[0170] Serialization of input packets, orders, and messages may be accomplished by the OEB 250 or by separate network equipment. Whether packet, message, or order serialization is implemented by equipment, systems, or methods integrated into the OEB or by external, separate networking devices, systems, or methods, this functionality and associated systems and methods will hereinafter be referred to as a network serializer. For brevity, the network serializer may or may not be integrated into the OEB.

[0171] If the network serializer is equipped to receive multiple incoming participant orders 110 or messages at once, for example, if the network serializer provides multiple network input ports, devices, taps, or connections such that multiple messages appear to arrive simultaneously (within a given time window), the network serializer can determine which of the multiple simultaneously arriving participant orders 110 or messages will be processed first, which of them will be processed second, third, and so on. This process of determining which of the simultaneously arriving inputs will proceed first is called arbitration and may be implemented by an arbitration algorithm or rule. The network serializer can use any arbitration rule or algorithm, such as, for example, randomly selecting specific apparently simultaneous inputs or using a round-robin selection order. However, the end result is a sequence that identifies the order in which the inputs should be processed, i.e., the observation sequence.

[0172] For example, if two messages "A" and "B" appear to arrive at the same time (detectably simultaneously), e.g., at the time resolution possible to the OEB250 or other serialization device, unit, network hardware, router, switch, network card, custom hardware FPGA, custom hardware ASIC, or software, or network processing software, the arbitration rules are responsible for determining whether "A" or "B" should be processed first. Whichever is selected, "A" or "B," is said to be first in the observed sequence of participant orders 110 and messages.

[0173] Serialization may be implemented by routing all incoming messages and participant orders 110 to the same network device, tap, cable, fiber optic line, or channel, i.e., alternately, so that only one message arrives at a time. Serialized packets, messages, or participant orders 110 may have timestamps or similar information attached, added, injected, templated, or loaded into them. When timestamps are so added or introduced into packets, messages, or orders 110, they may be used to determine the observed sequence of packets, messages, and orders 110 when the packets, messages, or orders are available or published in different or arbitrary orders.

[0174] The serialized packets, messages, or participant orders 110 may have message sequence numbers, sequence numbers, or similar additional information attached, added, injected, templated, or loaded in. When sequence numbers are so added or introduced into packets, messages, or orders 110, they may be used to determine the observed sequence of packets, messages, and orders 110 when packets, messages, or orders are available or published in different or arbitrary sequences or orders.

[0175] The sequence number or timestamp may be generated, created, derived, or selected by software or hardware running on the OEB, or within the network serializer, or on other computing resources. Message Identification Token

[0176] The OEB 250 may add an identification token to any participant order 110 or message it processes. To do so, it may add, paste, inject, input, or fill a placeholder in a template to or within the participant order 110 or other messages it processes. The identification token may uniquely identify that participant order 110 or message within the associated context. The identification token may be constructed, generated, selected, or programmed to globally uniquely identify the message or participant order 110 relative to other possible types of messages or participant orders 110, or may be generated such that the message or participant order 110 is uniquely identified by the token along with other relevant information and context, such as the calendar date or particular market data feed or channel to which the participant order 110 was sent, published, or belongs.

[0177] The identification token may be constructed, generated, selected, or programmed so as not to reveal other identifying information about that participant order 110. Thus, the identification token may be published within or along with that participant order 110 or message when it is published to market participants or other third parties. The token may be constructed, selected, or programmed so as not to reveal information about who the original market participant was. The identification token may be constructed, generated, selected, programmed, or derived by software or hardware implemented within the OEB 250 itself, or by software or hardware implemented on or within other software or hardware hosted by the venue operating the OEB 250.

[0178] The identification token may be used by a market participant, the exchange or venue operating OEB 250, OEB 250, or a third party. For example, if the same market participant later wishes to cancel or update a message or participant order 110, the market participant may use the identification token to reference a particular participant order 110 or a previously sent or transmitted message.

[0179] For example, assume participant A submits a limit order to an exchange or venue. OEB 250 can create, select, generate, or choose an identification token for that order, which can be generated in a manner independent of and not connectable to participant A. This identification token may be attached, appended, templated, imported, or embedded in the participant order 110 when it is published to the market participant, or when it is recorded, or when it is sent to another hardware or software operated by the venue, company, or organization operating OEB 250. OEB 250, or other exchange-hosted hardware or software, can send a message (an order confirmation message) back to participant A alerting them that their particular identification token has been assigned to their participant order 110. The order confirmation message may be sent in parallel or simultaneously with the publication of real-time market data, or the order confirmation message may be sent after processing by a book builder, trade announcer, or other subsequent processing step.

[0180] Later, if a particular market participant (participant "A") wishes to cancel that participant order 110, it can send a cancel, downsize, or modify message (referred to herein as a cancellation message) directly to OEB 250 that references that order by its previously assigned specific identification token. Alternately, participant A can send a cancellation message to the exchange or venue, identifying their order in a different manner, and the exchange or venue can look up the identification token on the participant's behalf and then send a cancellation message to OEB 250 referencing the participant order 110 using the unique identification token. Book builder (BB) and trade announcer (TA) functions

[0181] The OEB 250 can publish real-time publishing sequences or real-time publishing market data feeds 262 to market data subscribers, for example. The OEB 250 can forward, transmit, or publish output observation sequences of participant orders 110 and messages (e.g., sequences of records) to either (or both) a book builder (BB) or a trade announcer (TA) 260. The book builder 260 consumes, ingests, and processes observation sequences from the OEB 250, from other technologies of similar purpose or effect, or from any source of participant orders 110 and messages. The sequences of records may not have deleted, redacted, or anonymized information. The book builder 260 may publish book updates 264 (top of book and depth of book) for market participants according to the messages and participant orders 110 that it consumes and processes. Such published book updates may be anonymized or the information may be redacted.

[0182] The trade announcer 260 consumes, ingests, and processes observation sequences from the OEB 250, from other technologies of similar purpose or effect, or from any source of participant orders 110 and messages. The observation sequences input by the trade announcer 260 may not have information removed, redacted, or anonymized. The trade announcer 260 may publish trade or match messages for market participants in a market data feed 264 according to the messages and participant orders 110 it consumes and processes. The published trades or matches may be anonymized or have information redacted. The trade announcer may record its output, e.g., the sequence of matched orders that make up a trade, for eventual clearing and settlement.

[0183] Both the book builder and the deal announcer 260 can be implemented in hardware, as dedicated hardware, in an FPGA, or in an ASIC, which may require or use additional hosting, programming, or startup software. Both the book builder and the deal announcer 260 can be implemented in software or as software running on one or more computing resources (CPUs, embedded CPUs, tensor cores, ML cores, tensor processing units, floating point units, graphical processing units, ML processing units, AI processing units, or other stored program / software processing units).

[0184] Both the book builder and the deal announcer 260 may require, implement, or include network devices (network interface cards or dedicated network hardware) to consume or ingest participant orders 110 and messages and publish their conforming book updates and deal or match messages. Either the book builder or the deal announcer 260 may be implemented as separate hardware units or on the same hardware resource. As software, they may be implemented as separate software processes or threads or as the same software process or thread. When implemented as logically separate or distinct entities, they can communicate with each other as needed.

[0185] Messages and publications created and sent by book builder 260 may reflect the information and data it aggregates and collects, for example, in response to a new limit order being consumed and processed to buy 100 shares of XYZ at a price of $200.01 or less until cancelled, the book builder may publish a book update depth of book level 3, price 200.01, new quantity of symbol XYZ, 500 new order number 8 (e.g., if the level 3 quantity at price $200.01 was previously 400 and the order number was previously 7).

[0186] The trade or match messages published by the trade announcer 260 may indicate which participant orders 110 were matched or executed, or may indicate the aggregate amount executed, or both. For example, if a newly entered limit order exceeds the spread and interacts with three resting limit orders on the opposite bookside, the trade announcer 260 may send three individual trade, execution, or match messages, or it may send one aggregated trade, execution, or match message indicating the entire traded, executed, or matched quantity. The trade announcer 260 can send both styles of trade publications. To generate these trade, execution, or match messages, the trade announcer 260 implements matching rules associated with the particular security being traded, established by the rules, practices, and relevant regulatory environment (if any) of the trading venue. The trade announcer may also send replenishment or execution notifications to the individual participants involved in the trade or matched execution. The trade announcer may also record the sequence of matched orders (ie, trades) in a drop copy format, or may transmit or record the sequence for clearing and settlement. Fungible Order Matching Protocol (FOMP)

[0187] The disclosed architecture can implement the Fungible Order Matching Protocol or FOMP, which decouples the immediate publication of market data and market events from the final order-by-order matching.

[0188] In a fungible order matching protocol, an order cancellation or quantity size-down amendment does not need to reference a specific prior order. Rather, an order cancellation of any amount simply removes liquidity from the book if the participant sending the cancellation is still providing liquidity at the reference price or reference price level. Using FOMP, a participant sending a cancellation can optionally reference, refer to, or identify the specific order to cancel (or is required to do so). Even if a participant references a specific prior order for the cancellation (if it chooses or needs to), the venue can publish the cancellation as or in a fungible order format when and if it publishes the cancellation; for example, the venue and the equipment it operates can redact, delete, or anonymize the order identification token that the participant sending the cancellation used to reference the prior order.

[0189] For example, assume that one participant ("A") has a resting limit order to sell 50 shares of XYZ at a price of $543.21. That limit order may be at the head of the queue by time priority for that price level, e.g., it may have the highest priority and form the top of the book; e.g., its limit price may be the lowest or best quoted price to sell for that security at a given time. Further, assume that a different participant ("B") quotes a price for 50 shares to sell at the same $543.21 price (but their quotes are second in priority). If a third participant ("C") decides to buy 50 shares of XYZ at $543.21, and some time later, participant "A" decides to cancel that quote, the following sequence of events may occur: "C" sends a limit order to buy 50 shares of XYZ at $543.21. This limit order logically interacts with the 50 available liquidity, but as long as order-by-order matching is not fully completed, there remains the possibility that "A" can cancel their quote and reallocate the match and resulting execution to participant "B." For exchange operators using FOMP, there is flexibility as to whether order-by-order matching is performed proactively (so that the time window in which "A" can cancel or downsize is minimized) or delayed (so that the time window in which "A" can cancel or downsize is maximized). If a trading venue chooses to utilize delayed FOMP, participants can request matches and executions for specific orders at their option.

[0190] Market participants subscribed to message publications may not know the identity of each participant or the identity of the orders underlying the published orders in a fungible format, for example, if OEB 250 redacts or anonymizes the participant's identity and / or redacts the order identification token attached to the outgoing order cancellation message. Nonetheless, these market data subscribers 120 may correctly infer that both quotes to sell 50 shares of XYZ at $543.21 were removed from the book (e.g., one quote was removed by the match and one quote was removed by the cancellation).

[0191] From the above example, participants A, B, and C may not be able to infer, based on the instantaneous publishing sequence, which of their previously resting quotes have been canceled and which have been executed, because certain orders identifying tokens may not be present in the instantaneous market data (e.g., they may be edited, deleted, nulled, or obscured). Thus, the bookbuilder or trade announcer may notify participants involved in trading, matching, and cancellations of the status of their orders, for example, based on instantaneous market data, or in any case where such ambiguity may exist. If the OEB 250, exchange, or trading venue employs a fungible order message protocol, another unit, potentially the bookbuilder and / or trade announcer 260, may be used to capture, read, or process all of the original participant orders 110 and messages, so that the actual underlying orders and original orders (potentially including all order and participant identification information and tokens) can be correctly attributed, matched, canceled, and / or executed. Final trade settlement and real-time execution notifications may depend on this additional functionality being implemented. FOMP implementation of liquidity tracking unit

[0192] The implementation of FOMP may be aided by a liquidity tracking unit (LTU) 314. The LTU may be implemented by the OEB or by any other device that may benefit from using FOMP. The liquidity tracking unit tracks total liquidity by both underlying asset, bookside, and price level (total aggregate), and liquidity aggregated by underlying asset, bookside, price level, and participant (participant aggregate), but may not track individual orders. The LTU may be used to identify potentially self-matching orders; the LTU may be used to identify cancellations, order modifications, and / or downsizing requests that target liquidity that has already been removed from the book.

[0193] For example, an LTU can accept as input a given asset symbol, bookside (e.g., bid or ask), and price level and return as output the total aggregate, i.e., the total quantity offered or bid at that price for that symbol.

[0194] For example, an LTU can accept as input a given asset symbol, bookside, price level, and participant, and return as output total aggregates and / or participant aggregates, e.g., the total quantity offered or bid at that price for that symbol, and the quantity offered or bid by that participant at that price for that symbol.

[0195] For example, an LTU can also accept multiple participants as input and return multiple participant aggregates as output. Also, an LTU can optionally return only one or more participant aggregates, or the aggregates or them together with a total aggregate.

[0196] Thus, LTU may use as inputs the participant ID, the underlying asset symbol, the bookside, and the price level, for example, "Participant A, symbol XYZ, sell at $543.21."

[0197] [Table 2]

[0198] Based on that input, the LTU indexes into a specific memory structure using either a software data structure or hardware memory. For example, in software, various encodings of the input data (e.g., a participant ID expressed in binary format or another software-accessible representation) can be used to index into various well-known software data structures. This process is sometimes referred to as a key / value lookup. Such software data structures can be constructed, for example, as a map or a map of maps, or a dictionary or a dictionary of dictionaries, or a hash table or a hash table of hash tables, or some combination of these data structures, or as a database; for example, the LTU can be implemented in software with any number of commonly known software key / value implementations. In hardware, various input data can be used to construct an index into a given memory row or cell, where a quantity of fluidity corresponding to the input data is stored. A given memory cell may be in embedded memory, such as a block RAM or LUT on an FPGA, or in SRAM on an ASIC, or in DRAM attached to a given hardware implementation of the LTU.

[0199] Based on the input, the LTU may provide as output the total quantity of its underlying asset bid or offered at the input price level (total aggregate) and / or the total quantity bid or offered to one or more participants identified at the price level (participant aggregate or multiple participant aggregate).

[0200] For example, assume participant "A" submits one limit order to sell 10 units of XYZ at $543.21 and a second limit order to sell 20 units of XYZ at $543.21, and participant "B" submits five separate limit orders to sell 100 units of XYZ each at $543.21. Examples of valid limit orders for LTU:

[0201] [Table 3]

[0202] For an input of "A, XYZ, Sell, $543.21" (input values ​​by position are participant, symbol, bookside, and price level), LTU provides the following as output: "30, 530", where the output values ​​are participant aggregate (liquidity) and total aggregate (liquidity), across all participants, by position.

[0203] For an input of "B, XYZ, Sell, $543.21", the LTU provides as output: "500, 530", indicating that participant B offered a quantity of 500 at a price of $543.21, and that the total quantity offered at the price of $543.21 is 530 (across all participants).

[0204] The value in the LTU may be incremented when a participant activates a new resting limit order and may be decremented when a marketable limit order is processed or when a participant cancels a previous limit order.

[0205] When a new resting limit order becomes effective, the LTU increments both the total aggregate and the participant aggregate.

[0206] When a new marketable limit order is activated, the LTU decrements the total aggregate, subject to the following invariants, and the decremented amount cannot exceed the bid or offered total aggregate: When a new marketable limit order is activated, the LTU cannot decrement the participant aggregate because information about which specific participant order was matched may not be available.

[0207] As new marketable limit orders are processed, but before they become effective, information obtained from the LTU can be used to identify self-matching orders. For example, if participant "A" submits two separate limit orders to sell a total of 30 units of XYZ at a price of $543.21, and then participant "A" submits a marketable limit order to buy 50 units of XYZ at a price of $543.21, the LTU can be used to identify a potentially self-matching order for the 30 units. An OEB, or other device that implements or uses LTUs, can handle identified potentially self-matching orders in several ways. For example, a marketable limit order to buy 50 units of XYZ at $543.21 can be withdrawn or converted into two different orders: one to cancel 30 units of XYZ at a price of $543.21, and one to buy 20 units of XYZ (the difference between 50 and 30) at a price of $543.21. If some (or all) of the marketable limit orders are so converted into cancellations, the LTU may decrement the participant aggregate offered or bid at that price level by the amount of the quantity so converted.

[0208] When a new cancellation, downsize, or change is processed but before it takes effect or is sent to the bookbuilder and / or trade announcer or other processor responsible for order-by-order matching, information retrieved from the LTU may be used to identify cancellations that cover liquidity that has already been removed from the book. For example, assume that initial conditions are set according to the example limit order above, i.e., participants "A" and "B" submit limit orders such that the total aggregate of XYZ offered for sale at $543.21 is 530. Next, assume that a marketable limit to buy 520 units of XYZ at $543.21 is processed. The LTU state may be as follows: [Table 4]

[0209] The aggregate remaining quantity of XYZ sold for $543.21 is 10, but because LTU may not be able to track individual orders, the entries for participants A and B may not be updated. Next, suppose participant A sends a cancellation of 30 units of XYZ at $543.21. We note that, according to the information obtained from LTU, only 10 units of XYZ were offered at $543.21. OEB, or other devices that implement or use LTU, can then process this information in several ways, with the cancellation partially covering the liquidity that has already been removed. For example, OEB or other devices that use LTU could convert the cancellation into a cancellation of only a quantity of 10. State synchronization from LTU to bookbuilder, trade announcer, and / or matching engine

[0210] The output message sequence from the OEB (e.g., a sequence of records) can be sent to a downstream consumer for use as input. For example, the OEB can send the sequence of records to a book builder, a trade announcer, a matching engine, or another such consumer of its output. This downstream entity that consumes the sequence of records can implement order-by-order matching and can record, publish, or both record and publish the output of its order-by-order matching algorithm.

[0211] Downstream entities that may implement per-order matching may need to keep their information and state synchronized with the information stored in the LTU and the state of the LTU.

[0212] For example, if order-by-order matching is implemented by a trade announcer device (matching processor) that consumes a sequence of records as its input, before announcing each match, the matching processor may need to update the state of the LTU by subtracting the matched amount from the specific participant's aggregate liquidity. The matching processor can use a message sent to the LTU or an API call to the LTU interface for this state update (match request message or API call). When a match request is received by the LTU, if the participant identified for the match does not have sufficient liquidity or no remaining liquidity (e.g., because the participant canceled some or all of the quantity in the bid or offer), the LTU notifies the matching processor using a message or API call (partial match or match unavailable message or API call). The order matching processor then reassigns the match to the next potentially matching order in its priority queue and sends another match request depending on the number of remaining unmatched orders and the number of next resting orders in the priority queue.

[0213] Thus, the matching processor may send or invoke a match request to the LTU to attempt to subtract the matched quantity from a particular participant aggregate. If that participant has a remaining balance of at least that amount, the match request is successful. If the match request is successful, the participant aggregate is decremented. An unsuccessful match request is any such request in which the participant does not have at least that amount or no quantity remaining. For unsuccessful requests, if the participant has a remaining balance, the participant aggregate is set to 0 and a partial match message or API call can be sent or invoked to notify the matching processor of the result, and a partial match can indicate the amount matched as such. If the participant has no remaining balance, a no match message or API call can be sent or invoked to the matching processor.

[0214] For example, consider the following sequence of events: First, participant A submits a resting limit order to sell 50 units of symbol ABC at a price of $123.45. Next, participant B submits a resting limit order to sell 75 units of symbol ABC at a price of $123.45. Next, participant C submits a marketable limit order to buy 30 units of ABC at a price of $123.45. Next, participant A submits an order to cancel the 50 units of ABC previously offered at a price of $123.45, as shown in the table below. [Table 5]

[0215] If Order 4 is processed by LTU (to cancel the quantity of 50 ABC offered at $123.45) before the Matching Processor can update the LTU state using the match request based on Order 3, the Matching Processor can reallocate the match of 30 quantities to Order 2. On the other hand, if Order 4 is processed by LTU after the Matching Processor has updated the LTU state using the match request (based on Order 3), Participant A will only be offered 20 quantities, and their cancellation (Order 4) will only cancel those remaining 20 quantities.

[0216] Thus, when coordinating with LTUs, a trade announcer or device, apparatus, or software implementing order-by-order matching (a matching processor) may wait for a successful or partial order response based on an LTU match request before recording, publishing, or recording and publishing a particular individual order match. If a failed update indicates that a non-zero amount remains incomplete for a participant, that remaining amount may be allocated to that participant before the matching processor reallocates the remaining cross quantity to the next order in its priority order. For example, if a matching processor attempts to update participant "X" to decrement the quantity to 50 when attempting to match 50 cross quantities, but the partial match response indicates that X only has 10 remaining, the matching processor may publish, record, or publish and record a match of 10 quantities for participant "X," and then reallocate the remaining 40 cross quantities to the next resting order according to its prioritization scheme. Trade Announcer Allocation to LTU Sync

[0217] A trade announcer or other similar device, apparatus, or software implementing order-by-order matching (matching processor) can do so according to one of several policies. For example, the matching processor can attempt to find a match by immediately sending a match request for an LTU update upon receipt of a cross or marketable order. Alternatively, the matching processor can send a match request only if the participant indicates that they want immediate notification of a match for their individual order. Such a request for immediate notification of a match can be requested by a participant throughout a trading session or on-demand, for example, by the participant sending a participant match request message to the exchange. Alternatively, the matching processor can send a match request only after a price level is no longer the highest price level or upon participant request. Obviously, if all liquidity at a given price level is consumed, a match request may not be necessary because valid orders must provide the exact quantity to cross in order to match. Clearly, a policy of waiting a maximum time before the matching processor attempts an LTU update gives participants a maximum time in which they can optionally cancel orders, i.e., even if their orders within a given price level are matched according to priority. FOMP implemented using alternative quantization orders

[0218] OEB 250, or hardware or software that feeds messages or participant orders 110 to OEB 250, can split received participant orders 110 into separate orders of shares, contracts, tokens, or other trading quantities that meet certain minimum and / or maximum quantities determined by the exchange or trading venue implementing OEB 250 or other substantially similar technology. For example, if the maximum quantity is 1 and an order for 100 shares is received, that participant order 110 may be split into 100 individual orders with a quantity of 1 each. If the minimum quantity is 5 and the maximum quantity is 5, then an order for 100 shares is received, that order may be split into 20 individual orders with a quantity of 5 each.

[0219] Implementing such minimum, maximum, or quantity quantization can reduce the amount of logical reasoning required to establish remaining quantities at a particular price level after orders and cancellations interact with that price level. For example, if each participant order 110 must have a quantity of exactly five, then all orders at a given price level are, from a market observer's perspective, fungible. Furthermore, using this policy, order cancellations may not need to refer to specific orders. For example, if all orders have a quantity of exactly five (e.g., five shares or five contracts), order cancellations can cancel any order (with respect to a particular order) as long as the order statement remains at that price level.

[0220] In one particular embodiment, an alternative order matching protocol arises from an exchange or trading venue that adopts or implements a policy that all orders displayed have some constant, fixed quantity, regardless of whether the individual orders are issued in individual messages or published in a message aggregating orders. The adopted policy may be that each order has a quantity of exactly 1. Such participant orders 110 may be published as individual messages; i.e., if a participant sends an order with a quantity of 100, it may be split into individual messages with a quantity of 1 each when published to market data subscribers or other exchange participants. Such individual messages, each with a fixed quantity, are less likely to leak information about the size of competitors' orders to other market participants.

[0221] Interchangeable orders with fixed quantities can also be published in messages that aggregate several interchangeable orders together. Other parameters of the interchangeable orders may vary depending on the needs of the market participant submitting the order; for example, if all interchangeable orders are required (by convention) to have a quantity of 5, there may be multiple interchangeable orders for symbol XYZ with a quantity of 5 at a price of $10.00 and multiple other orders for symbol XYZ with a quantity of 5 at a price of $10.01. Interchangeable orders are distinct from the underlying orders submitted by market participants, but effectively represent those orders when published. Interchangeable orders can have information redacted, deleted, or anonymized and can have a token that identifies the order. Trigger orders and hidden limit orders, when published, may be published or displayed as interchangeable orders or in an interchangeable order format. The orders underlying interchangeable orders may also be published (or not), and information may be redacted, deleted, or anonymized when published or otherwise made visible to third parties.

[0222] Such publication (aggregating several fixed-size orders into one message) can reduce the number of messages required to publish a given participant's intent. For example, if a given participant wishes to trade a quantity larger than the fixed fungible quantity established by the fungible order message protocol, it can use an aggregated message. The fungible order message protocol can employ a fixed order size (e.g., 1) and a maximum aggregate size (e.g., 5). In one example, an order for a quantity of 5 is published in one message, and an order for a quantity of 21 is published in five messages (four messages of five quantities each and one message of the remaining quantity of 1). The aggregate size can be arbitrarily large, and the minimum trade size can be any size down to the minimum trade size supported by the venue, e.g., typically a quantity of 1, but may be a fractional quantity if fractional quantities are supported by the trading venue or underlying asset. FOMP with various matching algorithms

[0223] A fungible order message or matching protocol can be combined with a pro rata (or other) matching algorithm. Participants who subscribe to a fungible order message published by OEB 250 (or a similar device) can infer book states according to the message, such as resting limit orders that add quantity, marketable limit orders, and cancellations that remove quantity. However, a book builder or trade announcer 260, or other post-process with access to the underlying order attributes (i.e., non-fungible attributes such as participant ID of the underlying order published as a fungible order), can allocate matches according to a pro rata (or other) matching algorithm and then send replenishment and execution notifications according to that algorithm.

[0224] For example, assume that participant A submits a limit order to sell 10 shares at a particular ask price that forms the best offer level, followed by participant B submitting a limit order to sell 90 shares at the same price. These orders may be published to market participants as 20 separate limit order messages, each with a quantity of 5. Next, if participant C submits an immediate-or-cancel (IOC) order to buy 10 shares at the ask price, participants subscribed to the published market data may immediately remove the first 10 orders from their book view. However, according to a pro rata matching implementation, in the post-trade session or trade announcer, one of those shares may be allocated to participant A and nine of those shares may be allocated to participant B.

[0225] Auction matching may be implemented using alternative order message protocols. For example, the OEB 250 may publish "start" and "end" auction messages. The venue or entity operating or hosting the OEB 250 may send messages to the OEB 250 to start and publish auctions, or the OEB 250 may generate these messages automatically.

[0226] During the auction time frame, participants can submit orders and messages to participate in the auction. These orders can include limit orders and market orders. In the case of an opening or closing auction, these orders can be called market on open (MOO), market on close (MOC), limit on open (LOO), and limit on close (LOC), among others. OEB can immediately publish all orders and messages submitted to the auction (e.g., anonymized and possibly in standardized amount increments).

[0227] At the end of the auction, the orders participating in the auction are made public, and participants can use the published auction rules to guess which orders were matched at which prices. For example, the market clearing price may be determined by finding the price at which the largest quantity is matched. If there are two or more possible market clearing prices based on the largest matched quantity, the market clearing price may be determined in that price range by finding the midpoint or by selecting the price belonging to the bookside with the larger unfilled quantity (imbalance). Briefly, participants can determine the matched quantity (number of shares, contracts, etc.) and market clearing price by pairing the auction rules with the published auction message.

[0228] Some auction participants may prefer that their auction orders or messages not be published immediately. The OEB may keep these particular messages in a queue of messages that are not published immediately upon receipt. This queue of messages may be published just before the auction close message, i.e., so that participants can infer the auction results based on the messages and orders participating in the auction. In one embodiment, the OEB stops accepting auction participation orders (or holds them for the next auction) once the not displayed / pending queue begins to be published. In another embodiment, the OEB may accept new participating auction messages while publishing pending messages.

[0229] Some auction participants may prefer that their auction orders not be displayed unless they are matched in the auction. OEB 250 may hold these particular messages in the same (or similar) pending queue described in the previous paragraph and then not publish messages that are not matched in the auction. To facilitate the decision of which pending messages to publish, at the end of the auction, OEB 250 may utilize pending queues by price level. If the market clearing price and matched quantity are known, OEB 250 may start publishing pending orders and messages from the most aggressive price level, publish pending orders and messages from deeper price levels, and finally stop publishing undisplayed pending orders and messages when all matched messages have been published. TOQ, TO-IL, HLOQ, and HLO-IL

[0230] Figure 3A illustrates an order entry box 250 according to an exemplary embodiment of the present disclosure. Figure 3B illustrates a message order injection 320 according to an exemplary embodiment of the present disclosure.

[0231] The OEB 250 can implement message injection 320 for triggered orders (TO) and hidden limit orders (HLO) using additional elements disclosed herein, specifically, a triggered order queue (TOQ) 328, a triggered order injection logic (TO-IL) 326, a hidden limit order queue (HLOQ) 324, and a hidden limit order injection logic (HLO-IL) 322.

[0232] TOQ 328 implements a method or system for storing trigger orders on behalf of multiple market participants. The TOQ method or system may be implemented in hardware with the necessary programming and hosting software, or as software with the necessary network equipment. A stored trigger order consists of two parts: 1. The underlying order 372, order cancellation, or other participant message or API call; and 2. Trigger condition or predicate373.

[0233] For example, a stored trigger order may consist of an underlying order 372 to buy 100 shares of X at a price up to $100.01, and a trigger condition or predicate 373 that an order to buy A is observed at or above $49.99.

[0234] A trigger order (TO) may have as its underlying order 372 a buy order, sell order, order cancel, order change, order size down message, another trigger order containing its predicate and underlying order, any other participant programming message, or any other participant API call that a participant may wish to send to the exchange based on the trigger condition or predicate being fulfilled 374, unless otherwise specified.

[0235] Upon receiving 371 any new order message, order change or cancellation message, or any other information, TO-IL 326 implements a system or method that evaluates trigger order conditions or predicates 373 and activates the underlying order 372 according to such conditions or predicates being met 374. TO-IL 326 receives information from various external sources, for example, from input observation sequences (i.e., sequences of messages accepted by a trading venue or exchange) or, for example, from remote market data feeds 330 (e.g., prevailing market conditions, market signals, trading signals, market events, market data, other information, or other data processed by OEB 250). Remote market data 330 may be evaluated for authentication and validation 316 and / or injected into processes after authentication and validation 316. That information is compared to a trigger condition or predicate 373 for each input trigger order (TO), and if the trigger condition or predicate is met 374, the TO-IL 326 can publish the underlying order 372 from the trigger order to an output observation sequence (i.e., a sequence of records 340) such that the underlying order is published as an inforce order, message, or API call to a financial exchange or venue. If multiple trigger conditions 373 are met 347, the TO-IL will inforce publish all of the underlying orders 372 that have their conditions so met. One or more underlying orders 372 may be sequenced by a recirculating serializer 318. The TO-IL 326 method or system may be implemented in hardware along with the necessary programming and hosting software, or as software along with the necessary network equipment and interfaces.

[0236] Together, the TOQ 328 and TO-IL 326 store trigger orders, evaluate 371 whether a trigger event has occurred, and inject underlying orders that conform to the sequence of records when a trigger event occurs, on behalf of market participants. The TOQ 328 and TO-IL 326 may be implemented as hardware, software, or a combination thereof, and may be integrated into the OEB 250, integrated into a proximate computing resource, or otherwise connected to the OEB 250 or an exchange, or may be a venue that operates the OEB 250, or another exchange or venue that does not operate the OEB 250 but implements trigger orders.

[0237] The HLOQ 324 is implemented as hardware or software along with necessary network equipment and is a mechanism that stores hidden limit orders (HLOs) on behalf of market participants. In some existing systems, hidden limit orders are book-dependent limit orders, i.e., they can be matched or interacted with new marketable orders, IOC orders, or other orders, but are not disclosed to market participants. Such hidden limit orders may have a different queue priority than published limit orders. For example, such hidden limit orders may have a lower queue priority than published limit orders, even if the hidden limit order was sent to the exchange before the published limit order in a sequence of messages accepted by the venue or exchange.

[0238] In some embodiments, hidden limit orders may be implemented using mechanisms similar to trigger orders. Specifically, in certain embodiments, hidden limit orders are formed by hidden limit order messages containing underlying limit orders that are activated (revealed) when remaining visible or published liquidity falls below a certain threshold. An order can be hidden by withholding the publication and issuance of its underlying limit order until the remaining visible quantity falls below a participant-selected threshold. Thus, the disclosed invention improves in some systems by providing lower latency to the publication of hidden limit orders by displaying the hidden limit orders in an immediate publication sequence, and by reducing the amount of calculation and logic required in the final downstream matching processor, for example, because the hidden limit order functionality has been moved from the trade announcer, book builder, and / or matching processor to the OEB.

[0239] The HLO-IL 322 implements a system or method for evaluating conditions or predicates that cause non-displayed limit orders to be published. The HLO-IL 322 receives information from various external sources, such as input observation sequences (i.e., a series of messages accepted by a trading venue or exchange) and information from, for example, the Liquidity Tracking Unit (LTU) 314. That information is compared (371) with trigger conditions or predicates 373 for each non-displayed limit order (HLO), and if any trigger conditions or predicates are met (374), the HLO-IL 322 publishes the non-displayed limit order.

[0240] If the HLO-IL 322 observes an event or condition that causes one (or several) stored hidden limit orders to be published (e.g., this may occur when an aggressing order uses up some or all of the published or visible liquidity at a particular price level), the HLO-IL may inject the hidden limit orders into the sequence of record and / or the immediate publication sequence. The injected hidden limit orders may be issued before the order that triggered their injection in the sequence of record or the immediate publication sequence; for example, subscribers, listeners, and observers of published market data may infer that the hidden limit order (now published) has interacted with its triggering order (this is in contrast to TO-IL, which may issue the triggered underlying order in turn after the triggering order or message). The HLO-IL evaluates the market conditions that trigger the injection of hidden limit orders and injects the hidden limit orders into published market data 360. The HLO-IL322 method or system may be implemented in hardware along with the necessary programming and hosting software, or as software along with the necessary network equipment and interfaces.

[0241] TOQ 328, TO-IL 326, HLOQ 324, and HLO-IL 322 may be similar in their implementation details but may differ in the purpose of the messages and participant orders 110 they are intended to inject. TOQ 328 stores trigger order predicates along with their underlying orders, cancellations, or other participant programming requests or API calls, which react to events, orders, or messages that are validly issued or published, visible to other market participants, or injected into the observation sequence. HLOQ 324 stores orders that represent hidden (or unseen or dark) liquidity. To allow participants to infer which other orders have interacted with that hidden liquidity, HLOs may be published in sequence before the interacting orders. Thus, even though the HLOQ and HO-IL 322 have similar or identical implementations in their respective embodiments, in one embodiment of the overall OEB 250, the HLOQ and HO-IL 322 can inject their stored orders 372 before their trigger orders, and the TOQ 328 and TO-IL 326 can inject their stored underlying orders 372 after their trigger orders.

[0242] This distinction in sequencing, i.e., TOs are injected into sequences of orders and messages such that they are after their triggering events, and HLOs are injected into sequences of orders and messages such that they are before their triggering events, is not necessary for all embodiments, but it does mean that current market norms are respected, i.e., the underlying orders in TOs are responsive to their triggering events, and that hidden limit orders can interact with newly improved prices published by other market participants.

[0243] In existing trading venues, HLO is implemented by a matching engine that mediates between incoming orders and published updates. In existing financial exchanges and electronic trading venues, the matching engine checks both available displayed and undisplayed liquidity and then publishes the resulting execution or trade messages and corresponding book updates. Some embodiments disclosed herein improve upon the prior art by implementing HLO using order trigger logic, e.g., HLO is published and predicated in response to displayed liquidity falling below a certain threshold. This partially aligns HLO implementations with TO implementations, allowing both to be processed in a similar manner. Some embodiments further improve upon the prior art by enabling HLO implementations outside of the matching engine, e.g., within an exchange network gateway or other network-connected computing resource located between the exchange gateway and the matching engine or similar resource.

[0244] In some embodiments, OEB 250 and / or any of HLOQ 324 & HLO-IL 322 and TOQ 328 & TO-IL 326 need not be intermediate between orders coming in from participants and those published. Rather, the embodiments described herein may immediately publish all participant orders 110 with minimal or no queuing or backpressure (optionally dropping invalid or fraudulent orders and optionally redacting personal information) and inject HLOs or TOs into the published observation sequence based on HLO-IL 322 and TO-IL 326. Thus, HLOQ & HLO-IL 322 and TOQ 328 and TO-IL 326 implement HLOs and TOs in a novel way by having HLOs or TOs have queue priority and injecting their respective order, cancel, or other API calls as published order, cancel, or messages into the published sequence of market data when a trigger event is observed. This provides lower latency and faster reaction times on behalf of market participants.

[0245] In certain embodiments, after being triggered, i.e., after its trigger conditions are met, the trigger order is injected into the observation sequence 340 and published to market participants 360. Once published, it may be flagged as an injected trigger order or may otherwise appear as a regular limit order or other message, indistinguishable by information from orders or other messages that may have been sent directly by market participants, e.g., rather than being stored and then triggered.

[0246] Optionally, in architecture 300, trigger orders and hidden limit orders may be recirculated using recirculation logic 335. Depending on the implementation of OEB 250 (or a similar device), trigger orders and hidden limit orders that are triggered, i.e., injected into the observation sequence, may trigger other trigger orders or cause hidden limit orders to be triggered or injected.

[0247] For example, assume the following two trigger orders (TOs) have been submitted by market participants and accepted or accepted by the exchange for potential delivery as actual valid orders: [Table 6]

[0248] The first of these two trigger orders, TO1, has an underlying order to buy 100 shares of XYZ at a limit price of $654.32 (or greater), with a trigger condition (or predicate) that an order to buy 100 (or greater) shares of XYZ at a price of $654.32 (or greater) is observed. The second of these two trigger orders, TO2, has an underlying order to buy 100 shares of XYZ at a limit price of $654.32 (at the highest price), with a trigger condition (or predicate) that an order to buy ABC (any quantity) is observed at a limit price of $234.56 or greater. Upon admission or acceptance into a financial exchange or trading venue, the trigger orders (TO1 and TO2) are stored in a trigger order queue (TOQ 328) or are stored, stored, or held as valid orders for continued evaluation of their predicates and possible dispatch (i.e., if one of the trigger conditions or predicates is satisfied).

[0249] When a limit order to buy ABC for $234.56 is observed, for example, when such a limit order is processed, handled, or observed by OEB 250 (whether implemented in hardware, software, or hardware / software co-design, and whether implemented as a flow-through or interim design), it satisfies or fulfills the predicate of trigger order TO2, causing the underlying order of TO2 to be emitted, validated, or serialized into a sequence of records. The underlying order from TO2, upon its publication, issuance, or insertion into a sequence of records, satisfies the trigger condition (or predicate) of TO1. Thus, in certain embodiments of OEB 250, for example, the publication and issuance of the underlying order from TO2 can trigger the publication and issuance of the underlying order from TO1.

[0250] Certain embodiments are practiced using a flow-through pipeline design approach, which may be implemented by incorporating the following devices into OEB 250 as a data processing pipeline: 1. A message serializer 312; 2. Message authentication device 316; 3. Decision logic or message routing logic 320 that injects standard orders into the sequence of records 340 and / or routes new TOs and HLOs to the TOQ 328 and HLOQ 328 (respectively); 4.TOQ328 and TO-IL326, 5.HLOQ324 and HLO-IL322, 6. Optionally, recirculation logic 335 for recirculating the orders underlying the trigger orders 372 when their trigger conditions or predicates are satisfied 374 so that they are serialized 318, published, and / or enabled; 7. Optionally, a liquidity tracking unit (LTU) 314. 8. An anonymizer 350 for removing private data in the message before publication 360. 9. Outgoing publishing port 360 for publishing or transmitting sequences of published and effective orders and other market events (immediate publishing sequences) to market participants and other market data subscribers. 10. An outgoing publication port 340 for publishing or transmitting sequences of recorded and effective orders and other market events to any exchange or venue hosted downstream processing (e.g., to a book builder and / or trade announcer, and / or to eventual downstream logic such as an order-by-order matching processor or program, or a system or method for implementing a matching algorithm) or to market participants and other market data subscribers.

[0251] In embodiments of a flow-through pipeline, certain units may copy messages or inputs in unmodified form from their inputs to their outputs, depending on their particular function and inputs. Alternately, those same units may modify the messages flowing through them, or inject another message before or after a message input, depending on their function and their inputs.

[0252] Any of the aforementioned devices (e.g., the initial serialization device 312, or the TO-IL device 326, or others) can be followed by a tap point that sends the device's output to be recorded, e.g., as a pcap file or any other recording format for a sequence of packets, messages, or orders, for real-time or post-session audit, review, archiving, AI / ML model training or fitting, or other purposes. Such records of order or message sequences obtained by tap points or others can include timestamps, sequence numbers, or other attached identifying data or metadata. Records of message sequences as observed by any tap point can include specific data that would otherwise be redacted in the immediately published sequence. Such post-session audits or reviews can establish that the system operated as designed and specified. Such real-time or post-session audits or reviews can be used to establish which participants will share pro rata in the transaction.

[0253] Certain embodiments are practiced using an intermediary design approach, as opposed to a flow-through or pipeline design approach, in which messages or orders received from participants may be held or stored in memory while processing, program execution, other logic, or other computer software or hardware instructions perform any necessary or optional mechanisms underlying message authentication, triggered or predicted order lookup and retrieval, trigger condition or predicate evaluation 371, and insertion, publication, or issuance of messages or orders upon the realization of any satisfied 374 trigger condition or satisfied predicate. In an intermediate design approach, the final message or issued or published order, whether substantially identical to the incoming participant message order or the result of publishing or publishing an underlying order from a triggered or predicated order, can be constructed or reconstructed based on program rules and logic, i.e., the orders and messages ultimately so published or published can be forwarded or modified versions of the same order or message received from the market participant, compared to a flow-through design (e.g., certain information redacted for privacy, security, or any other concerns, and certain information or metadata added, such as timestamps or sequence numbers).

[0254] Whether the embodiments are implemented in a flow-through pipeline design approach, as an intermediate design, or as a combination of both design styles, and whether the final embodiment is implemented in hardware with possibly required hosting software (ASIC, FPGA, or otherwise), in software, or through a hardware / software co-design, the embodiments can achieve and provide the same benefits, such as reduced latency and increased throughput. Published triggered order (PTO)

[0255] A trigger order may be published 360 to market participants before its trigger condition is met or before its predicate 373 is met. Such published trigger orders or predicates are referred to herein as published trigger orders or PTOs. Such publication of trigger orders may occur in addition to all other necessary or optional aspects described herein; for example, published trigger orders may also be stored in the triggered order queue TOQ 328 along with all other (published or unpublished) trigger orders whose predicates or trigger conditions remain valid but have not yet been met. In contrast, unpublished trigger orders are placed in the trigger order queue, and their underlying orders may be published only if their trigger conditions or predicates are met. Whether a trigger order is published (when or before its conditions or predicates are met) may be determined by requests from market participants, venue or exchange rules, or external regulatory requirements. Triggered or predicated cancellations or order changes (i.e., trigger orders or predicated orders whose underlying order is a cancellation or order change) may also be published. A published trigger order is still referred to herein as a published trigger order or PTO, regardless of whether its underlying order is to buy, sell, cancel, or modify a previous order, or a different programming message or API call. In certain embodiments, a participant may indicate whether they wish to publish a particular trigger order by, for example, setting a value in a field in a trigger order input message. Public trigger orders (PTOs) can serve the purpose of increasing market transparency, thereby providing better, more transparent, and more liquid financial markets. Considerations for trigger order validity period

[0256] A trigger order (TO) may also include a validity time parameter. A trigger order (TO) with a definite validity time that is not ultimately triggered, i.e., the trigger condition is not met or its predicate is not met, will be canceled after its validity time expires.

[0257] The validity time parameter of the trigger order may be any one of a variety of known validity time parameters or validity time parameters or concepts not yet discussed. For example, the trigger order may have a validity time that is valid until the end of the trading session for the day, or that is valid for a set amount of time, such as one second, or that is valid for a particular specified fraction of a second, etc.

[0258] The validity period of a triggering order may differ from the validity period of its underlying orders, for example, a triggering order may have a validity period of 5 seconds from the time of its issuance, while its underlying orders may have a validity period of immediate or cancel.

[0259] If a private trigger order expires without its trigger condition being met or its predicate being met, the trigger order may or may not be revealed to other market participants or market data subscribers. Such expired private trigger orders may be known or revealed only to the participant that sent it, OEB 250, and the exchange, ATS, or venue operating OEB 250, and, where appropriate, regulatory bodies. Predicate Evaluators and Accumulator Predicates and Conditions

[0260] FIG. 4 illustrates a financial exchange and system architecture 400 for a condition evaluator, in accordance with certain example embodiments of the present disclosure.

[0261] The TOQ 328 and TO-IL 326 and / or HLOQ 324 and HLO-IL 322 can implement trigger conditions that accumulate information across multiple incoming messages 410 in the system architecture 400. The accumulated information may be valid only within a certain specified time window or may be valid indefinitely. For example, a market participant wishing to utilize such accumulated information in a trigger condition or predicate could submit the following (example) trigger order: Buy 100 shares of XYZ at a maximum price of $12.34 per share, with the trigger condition being that 50 (or more) shares of XYZ are bought at $12.34 (or more) within a 5-second window. [Table 7]

[0262] As another example of a trigger order (TO) that uses trigger conditions or predicates that incorporate information across multiple market events or other messages or data processed by an exchange or trading venue, a participant may submit the following (example) trigger order: Buy 100 shares of XYZ at a maximum price of $12.34 per share, with a trigger condition of a 5-second window of a 1-second moving average of the quantity of ABC matched at $43.21 (or greater) being 50 or greater. [Table 8]

[0263] Information aggregated or accumulated from multiple messages 410, orders, other market events, or data may be stored, processed, evaluated, aggregated, or otherwise implemented by an accumulator 420. The accumulator 420 may be implemented in specific hardware with various underlying hardware implementations (e.g., ASIC or FPGA) or as software program code. Such accumulated or aggregated values ​​may be stored directly in the accumulator hardware, inline with trigger orders or hidden limit orders that reference accumulated value conditions or predicates, or in a separate memory or software data structure indexed according to the needs of TO, PO, HLO, or other orders that reference accumulated values. The accumulator 420 may implement various functions, such as simple averages, moving averages, exponential moving averages, minimums, maximums, or percentiles, or any other aggregation function or any transformation of the information accumulated across multiple messages processed by the accumulator.

[0264] Thus, in TOQ 328, TO-IL 326, HLOQ 324, and / or HLO-IL 322, whether implemented in hardware as an ASIC or FPGA, in software, or a combination of software and hardware, multiple messages 410 may be processed across architecture 400, and information from multiple these messages may be accumulated and evaluated 430 against a particular trigger order condition or predicate. Additionally, the accumulated value may be reset under certain circumstances, for example, by resetting the stored value in accumulator 420 to zero or to a different given initial or reset value. For example, the accumulated value may be reset according to a reset condition, such as resetting the accumulated value to zero if more than 10 seconds have passed without a new message being processed.

[0265] Other reset conditions are possible, and in general, any type of trigger condition can be used as the condition for resetting the accumulated value. The accumulated value can be reset by reset logic or reset program code 440 or by directly programming a reset message 410. The programming message 410 can originate from the participant that submitted the order, or from the exchange or venue operating OEB 250, or from an authorized third party. A value other than zero may be used at the time of reset. Various other types of trigger conditions

[0266] OEB 250 can receive as input, process as input, or consume as input any type of information that can be encoded in a network packet, including, but not limited to, electronic messages 410 conveying price predictions for specific or all traded securities or assets. Any such information received as input, including price prediction messages 410, can be used as a trigger condition for a trigger order. FIG. 5 illustrates a trading algorithm that includes the use of a predictive model. Exemplary predictive models can include linear models, tree models, and neural network models. Any predictive model publication or aspect of a predictive model result (whether or not publicly available to all participants, whether or not generated by an algorithm developed by the exchange or venue operating OEB 250, whether or not generated by a publicly or generally known algorithm, or whether or not generated by an algorithm developed by a participant or other third party, and whether or not computed or implemented on the exchange or venue's computing resources, the participant's computing resources, or other third party resources) can be used as a trigger condition or predicate for a trigger order or forecast order.

[0267] In some embodiments, the exchange or venue operating the OEB 250, or a third party, can implement a predictive model 540 or algorithm that makes predictions according to certain rules or according to certain so-called trading signals. The resulting predictions can indicate a prediction that the price of a traded asset is likely to rise (or fall) in the future. For example, some predictive algorithms can infer that an asset's price is likely to rise if buying activity (predictive signal) is observed for that asset, or for a correlated or other related asset. Conversely, an exemplary predictive algorithm can infer that an asset's price is likely to fall if selling activity (predictive signal) is observed. Once a predictive signal is observed, the predictive algorithm can publish or transmit 560 a prediction to the OEB based on a decision threshold 550. Alternatively, the predictive algorithm may be embedded in the OEB.

[0268] A forecasting model can produce results of different forms. For example, a forecasting model can produce the following set of results: {no change, price increase, price decrease}. A forecasting model can alternately produce a real value whose magnitude and sign indicate the size and direction of the expected price change, respectively. A forecasting model can alternately produce a real value whose value is the expected return r, where r is the expected price p expected and the current price p current is defined in terms of, for example, r=p expected / p current -1. A predictive model can, in turn, directly yield an expected future price of an asset. There are obviously other ways, not contemplated herein, to express prices, forecasts, or predictive model results numerically or symbolically.

[0269] For example, a participant can send out a trigger order using a price prediction in its condition or predicate, e.g., buy 100 shares of XYZ at a limit price up to $24.99 per share upon receiving a price prediction that its price will rise. [Table 9]

[0270] For example, a participant can send a trigger or forecast order using a price prediction in a condition or predicate to sell 100 shares of ABC at a limit price of (up to) $52.01 per share upon receiving a price prediction value of -0.04 or less. [Table 10] The "-0.04 or less" trigger value may represent (for example) the expected near-term future return minus 4 basis points, but may be in any units.

[0271] An exchange or trading venue operating OEB 250 may implement proprietary, publicly known, or open-source predictive algorithms or models. Price predictions may be made publicly available to OEB 250 or market participants. These price predictions may be used by OEB as conditions for trigger orders. Those price predictions may be used by participants as part of their own trading logic or algorithms or models, or may be used by models and algorithms implemented in the trigger order generator.

[0272] Market participants or other third parties may implement proprietary, publicly known, or open-source forecasting algorithms or models. These price predictions may be submitted publicly or privately to OEB 250 and may be used in the same manner as price predictions generated by an exchange or venue. Market participants or third parties may submit price predictions or opaque values ​​(wrapped in trigger messages or other messages that can be processed by OEB or TO-IL or HLO-IL) so that participants' trigger orders can trigger on opaque conditions, e.g., conditions that are mysterious to third parties, including the exchange or venue itself.

[0273] As an example of an opaque trigger condition, consider the following trigger order: Sell 100 shares of XYZ at a limit price of $88.01 / share (or more), conditional on receipt of a trigger message. [Table 11] The trigger message may optionally contain a specific token known only to the participant that sent the trigger order, which must match the same token value that was programmed when the original trigger order was received. [Table 12] The trigger message may also include rules for the secret token, for example, if the secret token can be interpreted as a real value (e.g., as an IEEE floating point value), the trigger condition may trigger upon receiving a particular value, for example, a value greater than or equal to 0.05. The secret token and the rule(s) for its interpretation may vary depending on the capabilities published by the OEB and the TO-IL or HLO-IL. [Table 13]

[0274] If the exchange or venue operating OEB250 and other participants are able to observe trigger messages sent by participants, they may not understand why the trigger message was sent or may be able to infer further insight from the trigger value or other information encoded in the trigger message.

[0275] The TO-IL or HLO-IL may evaluate information, market data, messages, publications, events, or other data received from third parties, i.e., data not published or transmitted by market participants and not transmitted, published, generated, or created by exchanges, trading venues, or entities operating OEB250 or technologies similar in purpose or effect. Such information may include, but is not limited to, publicly available market data from other exchanges and trading venues. Such information may include, but is not limited to, information, market data, events, or data transmitted on data feeds such as securities information processors (SIPs) or transmitted on proprietary data feeds. Such information may include, but is not limited to, information regarding or derived from corporate events or disclosures or other news events. Such trigger information or messages may include messages transmitted privately between third parties by or through proprietary market data feeds. Such third-party messages, information, or trigger conditions may be transmitted directly from third parties to OEB250 or technologies similar in purpose or effect, or may be relayed by market participants and forwarded to OEB250. Authentication and Anonymization

[0276] The OEB 250 may verify 316 incoming orders for either participant identity, or authenticity, or order validity (e.g., for validity with respect to other market rules, such as compliance or margin requirements). Invalid, fraudulent, or otherwise unauthenticated orders may be marked as invalid, fraudulent, or otherwise not published. Whether published or withdrawn, such orders marked as invalid or fraudulent may also be recorded by tap points previously disclosed and described herein for real-time or post-session audit and review.

[0277] OEB 250 may anonymize 350 orders by removing the originating participant's identifying information before publishing the order. Additionally, OEB 250 may include, template, attach, inject, or add to any order or message 410 that publishes an attribute that corresponds in some way to the market participant or principal that sent the order or message. This attribute may be categorical and may indicate that the market participant is either a retail, professional, or investment fund. This attribute may also be more specific, such as a participant ID number, whether the correlation between the participant ID number and the actual principal participant is publicly known or not. Regulatory Messages

[0278] OEB 250 can also inject certain other messages into the observed sequence of published messages 410 and any other recorded sequence of messages. For example, upon receiving information from an external market data feed, e.g., SIP, the SIP can inject regulatory and compliance-related messages, such as indicators of where the National Best Bid Price (NBB) or National Best Offer Price (NBO) exists, into the immediate published sequence and / or recorded sequence, such as a trading halt message (for example) based on a regulatory rule or rules, such as the LULD rule. OEB 250 may or may not inject NBO, NBB, or NBBO messages into its output observed sequence. Such additional messages can be used by market participants to infer whether a nominally matching order actually constitutes a trade or not, based on whether the NBO, NBB, or NBBO is local to the venue or at another remote venue. OEB250 may inject or have injected a message indicating a trading halt based on, for example, a limit up / limit down rule (LULD rule) or other compliance or regulatory issue, such as any other circuit breaker compliance rule.

[0279] In some embodiments, the ability to adhere to compliance requirements in various jurisdictions may be provided by injecting trading halts, NBB / NBO / NBBO messages, or one or more other metadata messages into the observation sequence. Tap Point

[0280] The OEB 250 may record or archive its sequence of records, its immediate release sequence, or any other sequence of orders and / or messages from different serialization points therein for later use or real-time use. Any location at which a sequence of orders or messages is recorded or a sequence of messages is sent for recording may be referred to as a tap point.

[0281] In some embodiments, there may be tap points that record the serialized sequence of messages received from participants, remote sites, and third-party data sources. In some embodiments, there may be tap points that record the sequence of messages after the TO-IL 326 and / or after the HLO-IL 322 and / or after any other device, algorithm, or logic that injects messages in the serialized sequence of messages for processing by any component of the OEB 250. Additionally, there may be a tap point after the order identification token is attached. There may also be a tap point to record the immediate release sequence.

[0282] Among other things, tap points can be useful for enabling post-event reconstruction or replay of a trading session. A recorded sequence of messages from a tap point can be useful for enabling post-session settlement, audit, or regulatory compliance verification. The sequence of messages from a given tap point may or may not be recorded, may or may not be made public, and may or may not be consumed or processed by another hardware, software, algorithm, or device, local or remote to the venue, hosted by the venue or a third party, as described herein. Bookbuilder and Trade Announcer

[0283] FIG. 6 illustrates a stock exchange and system architecture 600 implementing a book builder and trade announcer according to an exemplary embodiment of the present disclosure.

[0284] The architecture 600 can receive an order feed 610 (e.g., a sequence of records 340). The architecture 600 can include a trade announcer (TA) 620 and a book builder (BB) 640. The OEB 250 can be paired with the book builder and / or the trade announcer 620, both described herein. The BB 640 and the TA 620 can consume as input a sequence of participant orders and other related messages (e.g., regulatory trading halt messages, BBO location messages, etc.). This input sequence of participant orders and other related messages can be an output sequence from the OEB 250. The BB and TA 620 can implement systems and methods for bookbuilding and order matching logic 640.

[0285] The BB 640 can aggregate published limit orders into so-called price levels and then publish top-of-book and depth-of-book messages for market participants. The BB 640 can publish 650 updates to the book. These messages may be redundant with respect to real-time market data, but may be useful to certain market participants who consume aggregated book information rather than inferring the state of the book from a sequence of published orders.

[0286] The trade announcer 620 can implement matching logic and publish 630 trade messages when orders are matched. This information may be redundant to real-time market data, but may be useful to market participants who directly consume information about the trade or match, rather than inferring that information from real-time market data. The trade announcer can record or cause to be recorded the sequence of matched orders (trades) for post-session or real-time clearance and settlement. The trade announcer can implement a Fungible Order Matching Protocol (FOMP) according to embodiments disclosed herein.

[0287] The OEB250, book builder, and trade announcer 620 may include protocol conversion algorithms or logic, such as book logic 640, to convert their output messages into existing protocols and encodings. For example, any of the embodiments disclosed herein may optionally include algorithms, hardware logic, software logic, or software programs that convert the native OEB250, BB640, and TA620 protocols into the Financial Information Exchange (FIX) protocol.

[0288] BB640 and TA620 may require that their input observation sequences include all messages processed by OEB250, as opposed to the subset of messages published to participants as real-time market data. BB640 and TA620 may require that their input sequences provide messages that have not been anonymized or edited in any way. Messages published by BB640 and TA620, such as top-of-book, depth-of-book, and trade messages, may optionally have certain information redacted. Such information that may be redacted, cleared, set to 0, or set to any or random value by BB640 or TA620 may include, but is not limited to, participant identification and participant authentication token.

[0289] OEB 250 may not implement order-by-order matching to facilitate rapid publication of real-time market data, thereby enabling OEB 250 to publish orders or messages that would not otherwise be published by prior art matching engines, such as self-matching and / or cancellation or size-down messages that target liquidity that has already been removed from the book.

[0290] The price-time algorithm is the most common matching algorithm in use today, is simple to implement, and is easy to understand or reason about. In one preferred embodiment of the teachings disclosed herein, a trading venue or exchange adopts the price-time algorithm as its matching algorithm.

[0291] Using a price-time matching algorithm, the priority of orders with the same price is determined by order arrival time. In some embodiments, an order is said to have arrived earlier than another order if it appears before the other order in the observation sequence, i.e., the sequence of orders and messages published by the OEB. In certain embodiments, no timestamp is required to determine the before-and-after relationship of arrival times; only knowledge of the position of the message in the sequence is required.

[0292] Thus, in certain embodiments, the observation sequences published by the OEB and used as input to the book builder and trade announcer determine the priority of all orders. Prioritization of triggered and hidden limit orders

[0293] FIG. 7 illustrates a prioritization scheme 750 for prioritizing the issuance of underlying orders, cancellations, downsizing, messages, or other exchange-supported API calls based on a subset of previously made trigger orders based on a particular newly processed event, data, or data satisfying a condition or predicate. The prioritization scheme 750 provides a series of tiers 755 / 757 / 759 / 761 / 763 / 765 for prioritizing the issuance of underlying valid orders. When multiple orders are triggered at the same tier, the multiple orders may be ordered according to one or more arbitration rules. For example, multiple orders may be split and interleaved, e.g., individual orders may be split into smaller (otherwise identical) orders, and multiple smaller orders may be interleaved, resulting in different participants taking turns ordering, e.g., entering a sequence of records for evaluation by a matching processor. For example, orders that have been split before being issued may be selected for sequential issuance within the sequence of records according to, e.g., a random selection of participant IDs, so that all participants have an equal chance of being issued their orders earlier in the sequence. Utilizing splitting and interleaving, participants may more fairly share the trade, cancellation, or queue priority of new resting quotes resulting from the underlying orders so issued. Sharing according to event responses and the identified criteria for that response (trigger event), as described herein, compares favorably with existing prioritization of competing orders, e.g., price-time, that is often determined according to tick-to-trade competition.

[0294] An order or message, such as an immediate or cancel (IOC), limit order (LO), hidden limit order (HLO), or trigger order (TO), conflicts with another order or message if it has the same symbol or underlying asset, the same side (buy or sell), and overlaps in price with that order. Conflicting orders need not be identical; other order parameters may differ, including, for example, but not limited to, quantity, allocation number, or validity time. Additionally or alternatively, two or more orders may conflict if one of them is a cancellation of a previously validly issued quote and the other is attempting to substantially interact (match) with that quote.

[0295] In the prior art, the priority of competing orders is typically established by a matching algorithm, e.g., price time. When a particular trigger event triggers multiple TOs or HLOs such that multiple competing underlying orders become active (based on that trigger event), the question remains of how to prioritize those competing orders. The OEB 250 can use arrival time, also known as time priority, to prioritize competing TOs, HLOs, and other orders or messages held or stored in the OEB 250. In addition to arrival time, the OEB 250 can use other methods of prioritizing the TOs, HLOs, and other orders or messages held or stored in the OEB.

[0296] In certain embodiments, OEB 250 may prioritize underlying orders of TOs and HLOs sent by participants, who optionally choose to disclose their identities 762 or the identities of beneficial buyers / sellers, or both. In certain embodiments, OEB 250 may also give priority to underlying orders 754 of published TOs, such as giving priority to published trigger orders or underlying orders of PTOs. In certain embodiments, OEB 250 may give priority to underlying orders of TOs if the underlying orders are canceled or downsized 758. In certain embodiments, OEB 250 may prioritize underlying orders of a particular TO if the trigger conditions of the particular TO have a lower threshold (e.g., assuming more risk) relative to other underlying orders triggered by the same event, message, market data, or other data processed by OEB 760. In certain embodiments, OEB 250 may combine, split, or interleave orders underlying multiple TOs or HLOs if those underlying orders are triggered by the same event, message, market data, or other data processed by OEB. In certain embodiments, OEB 250 may prioritize orders based on incentive arrangements between participants and the company or organization operating OEB 250.

[0297] As shown in Figure 7, OEB250 may implement any subset (or none) of these additional prioritization schemes, and if it does implement any of them, it may be programmed to give priority first to one scheme and then to another. For illustrative purposes and purposes only, OEB250 may prioritize competing underlying orders in a subset of TOs for which a trigger condition has been met based on a layering of the aforementioned and other priority considerations, of which there are obviously others that may not be contemplated herein. For example, 1. Whether TO has been published 754, 2. If the underlying order adds liquidity 756, 3. If the underlying order is cancelled or downsized 758; 4. If the threshold of the TO trigger condition is small, e.g., if the required amount observed at trigger 760 is small, 5. Whether the TO was anonymized 762; 6. No further distinctions764. According to the above exemplary prioritization scheme 750, for example, if four TOs are triggered based on a given event processed by a TO-IL, then: [Table 14]

[0298] In this example, a set of four underlying orders are published in the following sequence identified by their TO index numbers: TO3, TO1, TO4, and finally TO2.

[0299] Such a tiered priority scheme for the placement of orders underlying trigger orders can improve market transparency and liquidity. For example, for well-known trigger moments, participants may disclose their trigger orders to increase their priority, thereby increasing market transparency through the disclosure of trigger orders. For example, allowing quote cancellations to take priority over liquidity withdrawals is expected to allow greater amounts of liquidity to be offered at tighter spreads, thereby improving market prices available to many participants. For example, assigning priority to responses with lower trigger thresholds is expected to encourage unique trading strategies to compete based on risk tolerance and market insight, thereby increasing the speed of price discovery. Alternative prioritization schemes, such as permutations of the hierarchy disclosed above, may also be considered.

[0300] Clearly, other priority considerations may be identified. The use of a tiered priority system for the placement of orders underlying trigger orders may improve market liquidity and transparency, and improves upon the prior art by identifying additional considerations that are not present and cannot be taken into account in existing exchange systems, e.g., considerations that are not present in price-time matching systems, that are not present in pro rata matching systems, that are not present in auction systems, and that are generally not present in existing electronic exchange or trading venue systems.

[0301] Trigger orders can have different limit prices but can compete for the same opposite price levels. For example, there can be two trigger orders. The first order may be to buy 100 shares of ABC at or below $50.00 per share, with the trigger condition being observing a cross order of quantity 10 (or more) to buy ABC. The second order may be to buy 50 shares of ABC at or below $55.00 per share, with the trigger condition being observing a cross order of quantity 50 (or more) to buy ABC. [Table 15]

[0302] The underlying orders for TO1 and TO2 have different limit prices, but they can both be triggered simultaneously and both can be matched at the same price. For example, if the current best offer for ABC is to sell at $50.00 per share, then observing another order to buy 50 shares of ABC at $50.00 will trigger the underlying orders for both TO1 and TO2, and both can be matched at a price of $50.00 per share.

[0303] Because both may be triggered and matched at the same price, a participant may consider sending a trigger order artificially deeper and with a better limit price in order to gain price priority. However, the deeper limit price may not be significant unless it allows for price improvement on the quote with which it interacts. If price improvement is not possible, then for purposes of establishing priority between such competing orders, OEB 250 may disregard limit price and may consider other factors previously disclosed, such as disclosure, de-anonymization, or risk thresholds. Briefly, OEB 250 may consider priority between triggered underlying orders at matching prices using any or all of the other possible prioritization schemes. TO-IL and HO-IL Indexing and Exemplary Memory Implementation

[0304] The trigger order (TO), hidden limit order (HLO), or any other encapsulation of an order may be stored in a memory device by software, such as stored in a data structure, list, queue, map, hash map, tree, hash tree, pointer, list of pointers, linked list, array, tree, pile, memory region, memory map, or file, or by hardware, such as stored in an SRAM, DRAM, flip-flop, register, latch, block RAM, LUT, analog memory, or other hardware memory device.

[0305] Upon receiving a new event, message, order, or other information, the OEB 250, TOQ 328, TO-IL 326, HLOQ 324, HLO-IL 322, or other trigger order injection mechanism or necessary program evaluation logic or hardware component can read trigger orders, predicate orders, hidden limit orders, or other encapsulations of orders one at a time from their respective storage locations. On each read of a TO or HLO from memory or storage, it can evaluate whether the stored trigger conditions or predicates have been satisfied or triggered. This method of reading related sets of encapsulated orders to evaluate their trigger conditions or predicates one at a time is referred to herein as sequential evaluation.

[0306] The subset of such trigger orders that are triggered may then be stored in a separate storage device, written back to the same storage device but flagged as triggered, or cleared from memory after their underlying orders are issued or published. After discovering the subset of trigger orders that are triggered and require injection into the observation sequence, a sorting mechanism can be used to sort the triggered underlying orders by their priority. The sorting mechanism may be a software algorithm or a hardware mechanism such as a priority encoder. The sorting mechanism can use parallelism in either software, such as multiple threads or processes, or hardware.

[0307] In contrast to the sequential evaluation methods previously disclosed herein, upon receiving a new event, message, order, or other information, OEB 250, TOQ 328, TO-IL 326, HLOQ 324, HLO-IL 322, or other trigger order injection mechanism or necessary program evaluation logic or hardware component can read trigger orders, hidden limit orders, or other encapsulations of orders from their respective memory locations, possibly several times or in their entirety in a single memory access. The trigger conditions or predicates can then be evaluated several at a time or in their entirety by parallel hardware condition or predicate evaluators or by parallel programs, whether implemented as processes, threads, or other parallelized software techniques. This method of reading related sets of encapsulated orders to evaluate several trigger conditions or predicates one at a time or in their entirety is referred to herein as parallel evaluation.

[0308] After the subset of underlying orders that require injection into the triggered observation sequence has been discovered, the subset orders can be sorted or sequenced using techniques previously disclosed herein.

[0309] Trigger orders may be stored in software or hardware storage devices or memory media such that their storage locations (by memory addresses or indexes to locations within data structures or files or mapped files, or by physical locations on a hardware memory device) indicate their priority relative to one another. Thus, OEB250, TOQ328, TO-IL326, HLOQ324, HLO-IL322, or other devices, software, hardware, or mechanisms that implement trigger order storage, evaluation, and injection can read triggered orders from their respective storage locations in a sequence that respects their mutual prioritization.

[0310] Using the parallel evaluation method disclosed above, two or more trigger orders can have trigger conditions or predicates evaluated simultaneously. Thus, OEB250, TOQ328, TO-IL326, HLOQ324, HLO-IL322, or other devices, software, hardware, or mechanisms that implement trigger order storage, evaluation, and injection can simultaneously read multiple trigger orders from storage and store them in their order of priority. The trigger conditions or predicates of the multiple trigger orders can then be evaluated some or all at once.

[0311] Since the trigger orders are pre-sorted by priority, the mechanism that evaluates their trigger conditions can inject the highest priority of the triggered subset into the message observation sequence and reserve the remainder of the triggered subset for subsequent injection according to priority. Alternately, the mechanism can directly enqueue the triggered subset in its correct sequence for injection into the message and order observation sequence. In some embodiments, the mechanism can directly queue or inject only the highest priority trigger order whose trigger condition was met, or some of the highest priorities, and write the remainder back to their respective memory locations so that the process can be repeated until no remaining trigger orders can meet their conditions.

[0312] Upon receiving a new trigger order (TO) from a market participant, the OEB250, TOQ328, TO-IL326, HLOQ324, HLO-IL322, or other software or hardware hosted or operated by the venue, may evaluate the prioritization of that trigger order relative to all other related trigger orders currently stored on behalf of the market participant. That is, the priority of the newly submitted trigger order may be evaluated relative to all other current trigger orders upon receipt. Once the priority of the newly submitted trigger order is known, the trigger order may be stored in its appropriate location, or its priority index may be recorded in an appropriate memory, file, location, or software data structure. Speed ​​Bump

[0313] A speed bump is a device, hardware, software, algorithm, or storage device that intentionally delays incoming messages. In some embodiments, a speed bump may be implemented as an additional cable run or an additional spool of fiber optic cable along which messages must travel or propagate before processing at the exchange. OEB250 or the exchange, ATS, or venue operating OEB250, or a similar device or apparatus for the purpose, can optionally implement speed bumps for particular market participants, for particular order or message types, or for particular routes of messages to the exchange or to the computing resources of co-located participants.

[0314] In some embodiments, a speed bump can be inserted between all communications non-local to the trading venue and the computing resources of all co-located market participants with direct market access. In further embodiments, the speed bump can mitigate cross-venue latency arbitrage. The criteria for whether an order goes through a particular speed bump or does not go through a speed bump may vary depending on the general market or jurisdiction or needs. Managed Triggered Order (MTO) and Managed Triggered Order Unit (MTOU)

[0315] A managed trigger order (MTO) is a trigger order that a third party can place or cancel on behalf of a participant. For example, a managed trigger order may be placed on behalf of a market participant by a financial exchange or trading venue implementing embodiments disclosed herein. The parameters of a managed trigger order may be selected according to algorithmic rules agreed upon between the market participant managing the order and the third party managing the order on behalf of the market participant. The OEB 250 may optionally be paired with a managed trigger order unit (MTOU). The MTOU is a hardware or software implemented device operating on the same underlying computing resource or device as the OEB 250 or in or on a proximate computing resource or device in communication with the OEB. The MTOU generates or manages trigger orders on behalf of the market participant.

[0316] In some embodiments, for example, the MTOU can change the price of an order underlying a TO by canceling the TO and resubmitting it (as a new TO), and the underlying limit order is updated with the new price. Such automatic price changes may occur according to several criteria, such as trade signals published to and consumed by the MTOU.

[0317] In some embodiments, market participants may quote bids and offers 840 but may want to cancel those quotes under certain conditions indicative of price movement. The cancellations may be stored as trigger orders, and the trigger condition may be a trigger message from the participant to the trigger order injection logic. Alternately, for example, the trigger condition may be a price prediction published by the trading venue itself. Alternately, for example, the trigger condition may be a market event indicative of possible price movement. Additionally, participants contemplated herein may be placing trigger orders to quote new bids and new offers at new prices, contingent on the trigger event that triggered the order cancellation(s). After the old quote(s) are canceled and new quote(s) are published, the MTOU can reload with a new set of triggered cancellations and triggered quotes so that participants always have a new set of quotes and TOs in place. Parameterized trigger orders and parameterized hidden limit orders

[0318] A parameterized trigger order is a trigger order whose parameters may be dynamically adjusted based on prevailing market conditions, market signals, trading signals, market events, market data, other information, or other data processed by OEB 250. For example, TOQ 328 or TO-IL 326 may adjust the parameters of a parameterized trigger order based on any information they process. Triggered cancel and non-display limit orders may also be parameterized, i.e., their parameters may be dynamically updated by the same or similar mechanisms. For example, HLOQ 324 or HLO-IL 322 may adjust the parameters of a non-display limit order.

[0319] For example, in certain embodiments, a parameterized trigger order may specify a quantity that may vary within a range of quantities, or a limit price that may be selected from within several ranges of prices. For example, a parameterized trigger order may be to buy up to 100 shares of XYZ stock, but will only appear in the book at $89.99 if an order to buy XYZ stock is observed at a price above $89.99. [Table 16] Using this example, if the best offer for XYZ is currently 100 shares at $89.99, and a marketable limit order is observed to buy 20 shares at $89.99, the parameterized trigger order will trigger at a quantity of 80 shares, since only 80 shares remain in the book. Pair Synthesis Quote

[0320] A paired synthetic quote (PSQ) is formed when a marketable limit order (an order above the spread) interacts with two or more resting limit orders at different price points such that the average price of the trade is favorable to the participants in the trade. A paired synthetic quote is also formed when a new order, which may not be marketable depending on the displayed liquidity, interacts with two or more resting non-displayed limit orders at different price points.

[0321] In some embodiments, the PSQ allows trading with sub-tick resolution, which can provide price improvements to participants seeking immediate liquidity (e.g., by submitting marketable limit orders) and allows market participants to offer better quoted prices but provide price priority at less than one price tick of price improvement. For example, if a security's tick size is $0.01, the PSQ can offer execution or buy / sell in price increments of less than $0.01.

[0322] A PSQ, essentially formed by two orders at two different prices, can be described as having two legs, each with its own volume and price. This disclosure adopts the convention of describing these as a first leg that sets a base price and a second leg that offers some price improvement compared to the base price. The effective price of an executed PSQ is the average of the two leg prices weighted by the respective leg volumes.

[0323] The second leg of the PSQ, offering price improvements to opposing orders, may be undisclosed or unpublished.

[0324] For example, consider a market for a security where valid resting bids and offers are separated by only one price tick. PSQ can offer a trade at the average price between the bid and offer prices. For an order of 100 shares, if 50 shares are executed at the bid price and 50 shares are executed at the ask price, the order is effectively executed at the midpoint price. For a round lot of 100 shares, PSQ orders can compound prices that are 1 / 100th of the tick size increment.

[0325] A PSQ may be implemented to execute, match, or trade subtick-priced orders by pairing a trigger order (TO) with a hidden limit order (HLO). Similarly, a PSQ offering the same subtick pricing can be implemented by pairing a public or displayed limit order with a hidden limit order. For example, consider a market with a bid price of $99.99, an ask price of $100.00, and a tick size of $0.01. The spread is $0.01 or 1 tick. A participant wishes to submit a new offer (bid) to buy and obtain queue priority. With a tick size of $0.01, a better bid cannot be displayed without exceeding the spread. Using a PSQ implemented by the systems and apparatus disclosed herein, the participant can submit a bid to buy at an effective price of $99.9925. The $99.9925 price can grant queue priority to the participant's new bid submitted using a PSQ. The PSQ referenced in this example may be formed by a displayed offer to buy 75 units for $99.99 and an undisplayed limit order to buy 25 units for $100.00. If both the displayed and undisplayed limit orders are executed, the average price will be $99.9925. Alternately, the displayed quantity for $99.99 may be 100, the undisplayed limit order for the pair of 25 may be $100.00, and the cancel pair of 25 may be $99.99. As the paired orders are injected, they are marked as pre-matched with the order that triggered them.

[0326] The second leg of the PSQ may be implemented as a trigger order whose predicate is observing that the first leg of the PSQ has interacted with the opposite interest. The trigger logic for the second leg of the PSQ may be implemented in the TO-IL or HLO-IL.

[0327] Trigger orders, whether published or not, can contain PSQs as their underlying orders; that is, trigger orders can be used to order PSQs. The act of issuing a PSQ order necessarily issues both legs of the PSQ; therefore, if either leg of the PSQ is also a trigger order, a trigger order that issues a PSQ will also issue one or both legs of the PSQ as triggered orders.

[0328] Disclosed embodiments of the OEB, TOQ, TOIL, HLOQ, HLOIL, and other related disclosed methods and apparatus described herein may implement a method or system for publishing or disclosing PSQ transactions, referred to herein as automatic PSQ publishing. Automatic PSQ publishing is implemented by marking or flagging the trigger leg of the PSQ, i.e., the leg of the PSQ that offers a price improvement, as pre-matched. This practice of publishing the second leg of the PSQ before its opposite order allows market participants subscribing to real-time market data to correctly infer that the leg with the price improvement matches its opposite trigger order, and also allows them to correctly infer the resulting book state. Alternately, the leg of the PSQ offering the price improvement can be published some time before or after, referencing its trigger order. Using the reference information, market data subscribers can reconstruct the correct book state.

[0329] When the second leg of a PSQ is published, it may include a flag or other digital information identifying it as a PSQ and may include an additional quantity field that specifies the amount, if any, of the hidden quantity already published in the first leg of the PSQ, in addition to its quantity and price. The purpose of these additional information fields is to allow participating participants to deduce the correct resulting book state. Integrated Trigger Order

[0330] An aggregate trigger order is a trigger order that aggregates the actions, corresponding orders, or underlying orders of two or more triggered orders, possibly on behalf of multiple participants. For example, if there are two triggered orders, one to buy 100 shares of XYZ and one to buy 200 shares of XYZ, each with the same trigger condition, those two trigger orders can be aggregated into one trigger order to buy 300 shares of XYZ according to the shared condition.

[0331] MTOU can be used to generate or issue a consolidated trigger order. If MTOU is used to consolidate a previously issued trigger order, it can also delete that previous trigger order from the TOQ 328 before or in sync with the issuance of the consolidated trigger order.

[0332] The final settlement and reconciliation of an integrated trigger order can be handled according to its underlying constituent orders rather than its apparent form as an aggregate order.

[0333] The MTOU or other technology, software, or hardware that manages or aggregates trigger orders can notify the BB, TA, other matching processor, or exchange order matching hardware or software of the aggregated order. Following receipt of the trigger order aggregated by the components, the BB, TA, or other matching engine or exchange order matching hardware or software can identify and publish specific updates that individually expose the underlying trades and can send order execution and other necessary messages to participants in the trade. The BB and TA or matching engine, or other technology that reports and / or publishes book updates, can alternately listen for or tap on the communications and messages that constitute the aggregate trigger, effectively publishing the same updates to all participants and publishing or sending necessary updates and notifications to participants in the trade. Folding Sequence Trigger Order

[0334] A collapsed sequence trigger order is a trigger order that aggregates actions that logically follow from other trigger orders when triggered. For example, if there are two trigger orders to buy or sell or cancel the same underlying security or asset with conditions A and B, and if A implies B, then those quantities can be aggregated into one trigger order that is conditional only on A. The same reasoning holds for identifying specifically which orders are executed. The BB and TA can publish ex-post and post-trade settlement updates, and reconciliation depends on observing the complete sequence of messages to the OEB 250. Preventing and identifying self-matching

[0335] Self-matching occurs when a participant submits an order that matches or executes, or can potentially order or execute, another similarly submitted order. For example, if participant A submits a limit order to sell at $100.00 / share and then submits another limit order to buy at $100.00 / share, those two orders can match each other and constitute a trade, e.g., a trade in which the same participant buys and sells itself. Even if those two orders do not match directly, they can both be executed during the same time frame by matching with orders from other participants.

[0336] Self-matching can be problematic in that it creates the appearance of additional trading activity for a given security or asset when, in fact, it is a single participant trading against itself. Because visible, displayed, or published orders may be anonymized, self-matching may be impossible for other participants to identify. For example, self-matching can occur without malicious intent when two or more trading desks of the same major market participant arrive at different views at the same time and trade in opposite directions. Self-matching can also occur when a participant wishes to engage in a form of market manipulation and constructs self-matching with explicit intent to create the appearance of trading activity. Regardless of the participant's intent, whether pure, based on views from different desks within the organization, or malicious, it may be desirable to identify and / or prevent self-matching.

[0337] The present specification adopts the rule that self-matching occurs when a participant places two or more limit orders for the same security that overlap in price and trade in opposite directions. According to this definition, self-matching does not require that each of a participant's orders match itself; rather, those orders could have matched each other if both had queue priority at the moment one of those orders matched. For purposes of this specification, there is no self-matching if one or more resting orders are already executed, or if a participant buys or sells at the same price but at different times and does not have any concurrently active opposite orders at the same or overlapping prices.

[0338] Exchanges and trading venues may implement self-matching identification or self-matching prevention. Self-matching identification is implemented by identifying self-matching transactions immediately or within a reasonable timeframe. Self-matching prevention is implemented by prohibiting or preventing self-matching executions and / or the occurrence of self-matching executions. Self-matching identification and / or prevention may be optional, required, or opt-in, depending on the jurisdiction, trading venue, and other rules, laws, and regulations. Self-matching identification or prevention may be implemented by publishing a correction, such as a message or order correcting or notifying a correction to the book state, or by publishing a message or order identifying a match that is also self-matching.

[0339] The bookbuilder and trade announcer, or OEB250, or other software or hardware, can implement either post-hoc self-matching identification or prevention by consuming the observation sequence from OEB250 as input and running a self-matching identification algorithm. Self-matching prevention and / or identification may be implemented by the OEB, BB, or TA by implementing an algorithm to identify self-matches and then publishing messages to identify or cancel self-matches. In certain embodiments, OEB250 can implement self-matching prevention using LTUs. In some embodiments, OEB250 does not perform immediate publishing and thus can implement self-matching prevention through the use of a matching processor implemented in the bookbuilder, trade announcer, or other similarly equipped computing resource. Participant-hosted vs. exchange-hosted trigger orders

[0340] FIG. 9 shows a flowchart illustrating an algorithm 900 for participant-hosted triggered order or event / order pair evaluation (trigger order evaluation). The algorithm, as illustrated, is operated by a given market participant on computing resources different from the exchange or trading venue's computing resources or matching system. An event matcher or condition evaluator 910 receives inputs of various events (e.g., local 520 or remote 510 market data events, firm actions and reports, trading or pricing model forecasts or results, other trading signals 530, or other information). The algorithm 900 proceeds if the event matcher 910 matches a stored event 912 (or event group) with a live or real-time event (or event group) from an information source 510, 520, or 530 in some capacity (e.g., matching an individual event or matching a group of events). If there is a match (“yes”), the associated stored order 922 is sent to the venue (920).

[0341] FIG. 10 shows a flowchart illustrating an algorithm 1000 for exchange or trading venue hosted trigger order or event / order pair evaluation, according to an exemplary embodiment of the present disclosure. The system can host trigger orders or event / order pairs on behalf of multiple market participants. Hosting trigger orders or event order pairs on the trading venue on behalf of a participant can reduce reaction time compared to when the participant must wait to receive event information as required by the original trading venue. If the trading venue is simultaneously the same system or method by which exogenous information is aggregator, publisher of that information, and event responses (trigger orders, event / order pairs, non-display limit orders) are entered or validated on the venue, there may be fewer communication links to traverse, thus reducing closed-loop reaction time latency.

[0342] The event matcher or condition evaluator 1010 may be input with various events (e.g., local 520 or remote 510 market data events, corporate actions and reports, trading or pricing model forecasts or results, other trading signals 530, or other information). The event matcher or condition evaluator compares such events with stored events or conditions programmed into the algorithm by market participants. If the event matcher 1010 matches a stored event 1012 (or event group) with a live or real-time event (or event group) from an information source 510, 520, or 530 in some capacity (e.g., matching an individual event or matching a group of events), the algorithm 1000 proceeds. If there is a match ("yes"), an associated stored order 1022 is entered into a sequence of records on behalf of one of multiple market participants. The stored events 1012 and stored orders 1022 may be stored in an exchange-hosted program or device (e.g., as opposed to a participant-hosted program or device). The stored events 1012 and stored orders 1022 may be evaluated at an exchange or trading venue on behalf of multiple participants on an equal footing, e.g., on an equal footing with respect to reaction time latency (e.g., as opposed to evaluation at a collocated computing resource where there is an incentive to minimize reaction time latency; obviously, responses based on the same event or information may be arbitrarily ordered by the exchange or trading venue). Alternately, underlying orders that would otherwise be validated (e.g., for a non-local BBO) may be forwarded or transmitted to a different or non-local market, exchange, or trading venue.

[0343] Events may include local or remote market data, any information indicative of market outcomes, any information predicting market outcomes, any other trading signals, or any type of information. The underlying orders in an event order pair may be of any type, including, but not limited to, limit orders, immediate or cancel (IOC) orders, order cancellations, order modifications, hidden limit orders, hidden limit order cancellations, partial cancellations, other general order types, any type of contemplated order type, or other order types not yet contemplated, or any other API call to a trading venue API or message accepted by a trading venue protocol. The orders in an event / order pair may have various parameters, such as validity time, display (vs. not display), limit price, or quantity. Such order parameters may include any necessary or otherwise useful parameters, and the parameters may have any values ​​for purposes of describing the event order pair. Finding advantageous trigger orders

[0344] Depending on the market dynamics of the asset in question, finding a triggering order or event / order pair can prove difficult. Traders can use computer algorithms to help generate or discover trades, but those algorithms cannot directly yield event / order pairs. Certain trading algorithms, such as the algorithm shown in Figure 5, can consume events as input and produce trades (or price predictions, or other predictions) as output. Computing the algorithm can be more costly (in time) than detecting the specific event that may have triggered the algorithm to result in a particular trade. Simply put, an order or trade cast as an event-order pair can react faster than an algorithm (which requires some additional computation). One way to find an event-order pair is to feed a hypothetical event (that may occur in the future) into a trading algorithm, e.g., one that generates or produces trades, price predictions, or other trading indicators as its output, e.g., an algorithm that does not directly produce an event-order pair. If the algorithm results in a trade or other interesting or tradable prediction, the event-order pair has been found. Specifically, the event that may have caused the algorithm to trade (or otherwise indicate an outcome of interest) and indicate a corresponding order is an event / order pair. This particular event / order pair may be programmed into the algorithm shown herein in Figures 9 and 10. Market Forecast Data Feed

[0345] Disclosed herein are methods and systems by which an entity, algorithm, market participant, or other generator (e.g., human, random, or otherwise) can generate either expected market events or groups of expected market events. The entity can further publish the expected market events to an expected market data feed or mix them into another market data feed (where they can optionally be marked as expected events). The events or groups of events may be created such that they represent plausible events (randomly or otherwise), and the events or groups of events may be created such that they are more likely to form the basis of new orders or trades or trade cancellations or other material actions (randomly or otherwise).

[0346] Electronic stock exchanges and other trading venues may publish market data feeds or feeds. FIG. 11 shows a flowchart illustrating a trading algorithm 1100 that utilizes forecasted market data, according to an exemplary embodiment of the present disclosure. A market data feed may include events 520 that occur at or on the particular trading venue in question. A market data feed may include events 510 from remote trading venues or other different sources of events or information. A market data feed may include regulatory or trading status messages or events (e.g., NBBO, LULD, trading halt or resume, or other status messages) 530. Importantly, existing market data feeds only include events that have already occurred, i.e., real-time market data or other historical market data, and other related actual events and information (e.g., trading status messages). Actual events published in a market data feed may result in traders or trading algorithms reacting to new orders (by triggering event-order pairs, or by other means such as algorithmic calculations, or otherwise). According to some embodiments, trading venues may publish (and optionally appropriately flag) hypothetical future events 1112 that may form the basis of event / order pairs. Such publications (projected market data or projected market data feeds) are useful for purposes of finding profitable or useful event / order pairs or trigger orders. Projected market data is hypothetical and represents possible future market events.

[0347] A forecasted market data feed is useful in the task of finding profitable event / order pairs or trigger orders 1130. FIG. 12 shows a flowchart illustrating multiple trading algorithms 1210 utilizing an exchange-published forecasted market data feed 1212, according to an exemplary embodiment of the present disclosure. Using the forecasted market data, the trading algorithms can generate event / order pairs 1220. The forecasted market data feed 1212 can include flags, bits, or other markings or information indicating that an event is a forecasted event, i.e., a likely event, i.e., an event that may occur in the future. Using flagged as projected or flagged as hypothetical bits or other information, the forecasted market data 1212 can be published in the same channel or message sequence as a regular real-time market data feed or other market data feed. Alternately, the forecasted market data feed 1212 may be published in a different channel or sequence specifically reserved for forecasted market data. Alternately, forecasted 1212 market data and regular market data can be intermixed without distinction, for example.

[0348] Predicted events may include future events that add liquidity (e.g., liquidity added by a new resting limit order) or remove liquidity (e.g., liquidity removed by modifying or canceling an order, or by executing an order) from the published order book. As an example, assume that a particular trader or algorithm is interested in submitting a trade if it observes another trade of a particular size. A predicted market data feed may indicate the following independent events: [Table 17]

[0349] In the preceding example, the sequence of expected events indicates the trading or execution of increasing amounts of MSFT stock at a particular price. Individual market participants may draw different conclusions from the sequence. One particular market participant may conclude that they will submit an order according to "expected event 3" (if that event occurs). Another market participant may conclude that they will submit an order according to "expected event 4" (if that event occurs).

[0350] While the foregoing example contemplates one way of creating independent sequences of predicted market events, clearly there are other ways. For example, a sequence of predicted events can represent orders that add visible liquidity to the bid or ask, varying the amount or price of the added liquidity. The predicted events can remove (e.g., cancel) quantities from the bid or ask side of the book in various amounts or at various price levels. Furthermore, various parameters, such as quantity or price, can be characterized as greater than, greater than or equal to, less than or equal to, or less than or equal to, rather than by an exact match. Such a predicted event might be "Trade / execute, MSFT, under 10 shares at $315." Various parameters of predicted market data events can also be delta-encoded. Such a predicted event might be "Trade, MSFT, under 10 shares at current midpoint minus 1 / 2 tick." In summary, in predicted market events, any order parameters (quantity, price, symbol, order type, and other order parameters) can be varied, encoded as absolute values, encoded as ranges, or upper or lower bounds, or delta-encoded. Estimated Market Data Timestamp

[0351] The forecasted market data may also include a published timestamp and may indicate a predicted future moment or future time frame in which the forecasted event may occur (forecast timestamp). We extend the previous example of forecasted market data using the following abbreviations: TS for published timestamp, and PTS for forecast timestamp. [Table 18]

[0352] In this example, the predicted timestamp is greater than the published timestamp for each of the predicted events (and this is just one rule that may be chosen). Predicted events 6 through 10 assume the same set of individual predicted events as 1 through 5, but at a further moment in the future (i.e., predicted events 1 through 5 assume events occurring 10 hours after the predicted event's publication, and predicted events 6 through 10 assume events occurring 30 hours after the predicted event's publication).

[0353] The expected timestamps may be known (e.g., by published convention) to be in particular units of time (e.g., nanoseconds or microseconds), or those units of time may be indicated in the expected event message itself (e.g., by a time unit parameter or message field).

[0354] The forecast timestamp may also indicate a time frame, for example, "TS 10, PTS 40-60," indicating a time frame of 30 to 50 hours after the publication of the forecast market data for one of the example forecast events above.

[0355] The forecast timestamps may be delta-coded, e.g., rather than providing absolute timestamps, they may provide timestamps relative to the moment of publication or receipt. For example, one of the forecast events from above may have "TS 10, PTS +100 to +200," indicating a time frame of 100 to 200 hours after publication of the forecasted market data. It may also have only "PTS +100 to +200," indicating a time frame of 100 to 200 hours after receipt of the forecasted market data.

[0356] The forecast timestamp may be known by convention. For example, all forecasted market data events may be forecast at a specific fixed time in the future, e.g., the publication time plus a specific time. Alternately, there may be a fixed epoch of an absolute forecast time period, e.g., all forecasted events (at a specific epoch) are expected to occur at absolute time t0 or between (absolute times) t0 and t1. In these conventional schemes for forecast timestamps, the forecast timestamp need not be included (directly) in the forecasted market data feed (although the epoch number may be included).

[0357] The forecast timestamp or epoch of the forecast market data can be used to cancel event / order pairs found using that particular forecast event. For example, consider a forecast event PE0 with a forecast timestamp having an absolute value of 100 time units. Suppose the current time is 110 time units. In this hypothetical scenario, even if the forecast event occurs, it will occur after the forecast timestamp. In this sense, the forecast event PE0 can be considered stale. Therefore, if an event / order pair is found from PE0, that event / order pair can be considered stale. Subsequently, if the current time has passed beyond the forecast timestamp, any event / order pairs found from the forecast event with the now-stale forecast timestamp can be canceled accordingly. Predicted Market Data Group Sequence

[0358] In some cases, a group of events may form the basis of a trade (e.g., as compared to one particular event or item of information). For example, consider the following group of possible market events: [Table 19]

[0359] The aforementioned anticipated events can be viewed as a group (rather than as individual events). In such a group, the total number of MSFT shares added to the offer or ask side of the book is 100. The aggregate effect of the group (100 shares of added liquidity) may form the basis of a trade, but no one of the aforementioned events, observed in isolation or in isolation, may form the basis of a trade.

[0360] For groups of events, the timing between individual events can also vary and can be a parameter of interest, for example, when potentially forming the basis for a trade. For example, in the above example where an aggregate total of 100 shares are added to a sell offer, the interpretation of the possible events can differ if they are closely spaced in time versus widely spaced in time. The projected market data timestamp (various forms thereof disclosed herein) can be used to distinguish between these different projected market data group timing scenarios. Trigger Order Generator

[0361] FIG. 8 illustrates a system or method for facilitating and assisting the process of creating or discovering trigger orders 860 for use in electronic trading systems and venues 800 according to an exemplary embodiment of the present disclosure.

[0362] The OEB 250 may optionally be paired with an algorithm (hosted or co-located) 830 and a forecast market data feed 810 to implement a Triggered Order Generator (TOG) 870, as shown in system 800. The hosted or co-located algorithm 830 may be a trading algorithm or predictive model, or both, implemented on or in hardware, computing resources, or software integrated with the OEB 250 or otherwise in proximity to or in communication with the OEB 250. The TOG 870 is an algorithm, logic, device, hardware, or software that finds profitable trigger orders based on current market conditions. The TOG 870 and / or hosted algorithm 830 may be utilized by, on behalf of, or in collaboration with participants.

[0363] The hosted algorithm (HA) 830 may be an algorithm developed and maintained by or on behalf of the trading venue operating the OEB 250, or may be a third-party algorithm shared completely or opaquely as a black box with the venue by a third party. The trigger order generator (TOG) 870 may use the hosted algorithm 830 or a co-located algorithm, or a remotely hosted or remote algorithm.

[0364] To find potentially profitable trigger orders, the TOG 870 merges hypothetical or forecasted market events 810 with orders, cancellations, order changes, or other material outputs of hosted or co-located algorithms 830 that generated their material outputs based on the same hypothetical or forecasted market data 810. For example, the trigger condition 850 is a hypothetical event 810, and the underlying order is the resulting order based on evaluating the hosted or co-located algorithm 830 against the hypothetical event 810. The TOG 870 can send this trigger order directly to the OEB 250 for immediate issuance to the TOQ 328 and TO-IL 324, or it can send it to a market participant for review and approval. In certain embodiments, the TOG 870 system can optionally use multiple streams of hypothetical market events 810 for multiple traded securities or symbols and can evaluate the multiple hypothetical market events 810 against many different trading algorithms on behalf of many different market participants, so that any participant can use the TOG 870 to independently generate trigger orders.

[0365] The TOG 870 system or method or hosted or co-located algorithm 830 may use a third-party algorithm without knowing the details of that algorithm, or may use an open-source algorithm, or a proprietary algorithm developed by or on behalf of the venue itself. Any of these algorithms 830 may be hosted at the venue, co-located, or remote. For example, a hypothetical event 810 may be used by an algorithm or algorithms hosted by a market participant on their own co-located computing resources. If that participant's algorithm originates an order or order cancellation 840 in response to a hypothetical event 810 so published by the TOG 870, that order 840 may be returned directly to the exchange or trading venue operating the OEB and TOG 870 in the form of a trigger order for issuance to a TOQ, or may be sent to the participant's pre-trade risk assessment logic for review and approval before potentially being sent to the venue-operated OEB and TOQ. Order Book and Publication of Order Book

[0366] Trading venues, electronic trading venues, stock exchanges, options exchanges, futures exchanges, crypto exchanges, etc. may maintain a record of open interest to buy or sell a particular security (or derivative, contract, or crypto token, etc.), known as an order book, limit order book, or continuous limit order book. An order book typically consists of all limit orders (and / or other resting orders) to buy or sell the underlying security (stock, option, contract, crypto token). Order books are typically organized by security, symbol, underlying stock, contract, option, derivative, or crypto token; for example, a given order book may be the order book for a particular stock symbol, e.g., GOOG stock. The order book may be organized by price level or tick level; for example, orders sharing the same price or tick level may be grouped together when displayed or stored (in DRAM memory, SRAM memory, CPU cache, on disk, SSD disk, written on paper, or stored in other manner). Orders at a particular price may also be aggregated together when displayed, published, or otherwise viewed by an algorithm, program, or other entity. For example, consider the following three orders (in the order book) that are limit order offers to sell shares of GOOG: Order 1 at a price of $120.00: Limit order to sell 10 shares of GOOG at over $120. Order 2 at a price of $120.00: Limit order to sell 20 shares of GOOG at over $120. Order 3 at a price of $120.00: Limit order to sell 30 shares of GOOG at over $120.

[0367] When displayed, published, or viewed by an algorithm, program, or other entity, these three orders may be aggregated together and displayed as 60 shares (three orders) of GOOG available for $120.

[0368] Orders at a particular price level may have some priority that establishes which order will be executed first when a matching order on the other side is submitted. Often, priority is established by which order (at the price level) was submitted first, but other methods exist (e.g., pro rata).

[0369] Orders in the order book may be public or displayed. Alternately, orders in the order book may be hidden or dark. Public or displayed orders are made visible to market participants by publishing the order book. Publication of the order book may be done on an order-by-order basis, or the exchange or trading venue may publish aggregate updates showing the total aggregate liquidity for each given price level. There may also be other ways of publishing order book information. Hidden or dark orders are not published or known to other trading participants unless they are matched by an opposing interest. Participants are typically interested in submitting or using these so-called hidden (or dark) limit orders when they do not want to reveal the size of their trading interest in a particular trading asset. Public and private exchange-hosted events / order pairs

[0370] In accordance with the exchange hosting event order pairs on behalf of participants, the exchange can form an order book comprised of both limit orders and event order pairs (which may include events that trigger the injection of limit orders, or events that trigger the injection of IOC orders or order cancellations, or other types of orders). This order book extends the standard order book because it includes more information regarding the field of possible trading outcomes. It can therefore be described as an order book at or with higher dimensionality (i.e., higher dimensionality than previously disclosed forms of order books that include only various forms of limit orders or hidden or undisplayed limit orders; this higher dimensional order book includes event order pairs that describe possible future outcomes depending on possible future events). Event order pairs submitted to the exchange can be marked by participants as visible (or public) or invisible (or dark, or hidden, not public). An exchange can publish the displayed event order pairs as a separate market data feed or intermingle the displayed event order pairs into its regular market data feed. Publication of event order pairs by trading participants marking submitted event order pairs as displayed is non-obvious, novel, and useful. Alternative publication methods (e.g., separate market data feeds, intermingling, etc.) can be implemented in the embodiments described herein. Exchange-hosted Events / Order Pair Events

[0371] A variety of different events or quantities of information can form the basis of a trade and, therefore, may be of interest when forming an event-order pair. Any market event published in a common market data feed (e.g., a new order, a canceled order, or one or more orders that have been matched or traded) can form the basis of a trade and can be an event in an event-order pair. These market data events may be received from the same venue (on behalf of the trading participants) hosting the event-order pair, or they may be received from other trading venues. These events may be for the same security or trading asset specified in the order (in the event-order pair) or for different trading assets.

[0372] The particular market data feed events (as contemplated in the preceding paragraph) do not form the universe of events or information volumes that may form the basis of trades and, therefore, are not the only events of interest in forming event order pairs.

[0373] Additionally, the output of a trading algorithm (eg, a price prediction or market direction prediction or other predictive indicator) may form the basis of a trade and thus be an event of interest for an event order pair.

[0374] Additionally, a particular news event or quarterly report, other disclosure event, or other corporate action or announcement may be one or more events that form the basis of a trade and are therefore of interest to an event / order pair. Injecting event / order pair results from exchange-hosted predictive models

[0375] Trading venues, electronic trading venues, stock exchanges, options exchanges, futures exchanges, crypto exchanges, etc. can operate, host, or implement predictive models. These models can consume both local and remote (or other input) market data (e.g., real-time public market data) and can result in price predictions or other predictive indicators.

[0376] Reducing the time to calculate a predictive model can be useful for reducing the reaction time involved from an event (or other input) to a model prediction or outcome. One component of the time required for model calculation is the time required to transmit or transmit market data from its source to the machine on which the model is calculated. The exchange itself may integrate model calculation into its own hardware or software, thereby reducing the time required to transmit market data to the model and thereby reducing the time required to calculate the model outcome.

[0377] 13 illustrates a stock exchange and system architecture 1300 integrating a predictive model 1310, according to an exemplary embodiment of the present disclosure. The model 1310 can receive data directly from the OEB 250 and / or the TA 260. The model 1310 can inject orders back into the OEB 250. The model 1310 can publish future market data and / or events / orders to market data subscribers 120.

[0378] The output can be integrated back into the exchange hardware or software that hosts the event-ordered pairs on behalf of the participants. Specifically, the predictive model results may be used as events to formulate the event-ordered pairs. For example: Event: The result of the prediction model is less than or equal to -0.75. Order: Sell 100 shares of INTC at a price above $29.00 (IOC).

[0379] Specifically, an exchange-integrated forecasting model (a co-hosted model or co-hosted forecasting model) can immediately send its results to the computation unit hosting the event-ordered pairs on behalf of participants, or the exchange-hosted integrated model can reside within or on the same computation unit hosting the event-ordered pairs on behalf of participants. The forecasting model may be integrated into the same program or hardware as the order serialization and processing logic, including any exchange-hosted event-ordered pair evaluation logic, program, or hardware. Integration may be achieved within a single program, process, thread, or hardware device, by programs, logic, and hardware residing on the same computation server, or by different parts residing on exchange-hosted programs, hardware, or servers in close proximity. This direct connection, integration, or sharing of resources between exchange processing (incoming order serialization and matching), model calculation, and event-ordered pair evaluation can reduce overall reaction time (e.g., the reaction time from new information entering the system to event-order evaluation via the forecasting model). How to manage orders across input ports

[0380] 14 illustrates a flowchart of a computer-implemented method 1400 for managing orders across multiple input ports according to an exemplary embodiment of the present disclosure. The method 1400 may include step 1402 of receiving a plurality of data packets from a plurality of input ports. The plurality of input ports may include a first and a second input port. A first portion of the plurality of data packets may define a first message, and a second portion of the plurality of data packets may define a second message. The first message and the second message may include at least one of the following message types: an order message, a trigger order message, and / or a hidden limit order message. Additional data packets may also be received, including, but not limited to, a third-party market data packet and a regulatory information data packet.

[0381] The method 1400 may include matching 1404 a first portion of the plurality of data packets to a first message, and matching a second portion of the plurality of data packets to a second message.

[0382] The method 1400 may include sequencing 1406 the first message and the second message into a sequence of records based on one or more reconciliation rules as described herein.

[0383] The method 1400 may include determining whether the first and / or second message is fraudulent or invalid. A message may be fraudulent if it does not contain necessary identifying information sufficient to verify an authorized market participant. A message may be invalid if a parameter of the message is outside a predetermined threshold range. Authentic or invalid messages may be omitted from the sequence of records. Authentication may be performed using a shared secret key (e.g., using symmetric or public key cryptography). Alternatively, authentication may be performed using an authentication token.

[0384] In one example, if the first message is a trigger order message, sequencing 1406 may further include storing the triggered order message in a trigger order queue, which includes storage for the trigger condition of the trigger order message, the underlying order, modification or cancellation of the order, or other API calls for the trigger order message (the underlying order); evaluating a state of the trigger condition based on at least one of the second message, the received external condition, and the matching information; and inserting the underlying order into the sequence of records according to the trigger condition being met. If the second message is an order message, updating the evaluation of the trigger condition may further include the processor determining message information associated with the second message, including at least one of a symbol, a price, and a quantity, comparing the message information with the first message, and updating the state of the trigger condition based on the comparison. If the trigger condition of the stored trigger order is not satisfied, evaluating the trigger condition may further include integrating information from the second message into an accumulated value parameter that is stored or accessed with or along with the stored trigger condition associated with the first message.

[0385] The method 1400 may include publishing 1408 the sequence of records via a network interface. Some message information may be redacted during publishing 1408. Hidden limit order messages may be omitted entirely from publishing 1408.

[0386] The method 1400 may include evaluating 1410 the first and second messages using a matching algorithm based on the historical message data, the sequence of records, and the message type to generate matching information. The evaluation 1410 may further include a fungible order matching protocol as described herein.

[0387] The method 1400 may include publishing 1412 the matching information via a network interface. Exemplary embodiments:

[0388] In some embodiments, the system includes one or more memories and at least one processor. The system may include circuitry configured to receive a plurality of participant messages or network packets, referred to in these claims as order entry boxes or OEBs. The participant network messages or network packets may include flow-through order types, understood to be well-known order types established by the prior art, such as, but not limited to, limit orders, marketable limit orders, immediate or cancel orders, order cancellations that cancel or attempt to cancel previously placed orders, order adjustments that modify or attempt to modify previously placed orders, or the like (order messages); i.e., predicated, triggered, or conditional order messages, which are messages that include a predicate or trigger condition along with an underlying order, which is generally a limit order, order cancellation, order modification, or another trigger order message. The underlying order in this message is not immediately activated; rather, when the predicate, trigger condition, or condition is met, the underlying order of the predicated, triggered, or conditional order message is activated. These message types may be commonly referred to as trigger orders.

[0389] In some embodiments, the order entry box is configured to process participant packets from an ordered sequence or an ordered sequence of such packets, where the one or more sequences are referred to in this disclosure as one or more input sequences. The one or more input sequences may be generated by a message serialization mechanism external to the order entry box, such that the output of the sequencer is the input sequence to the order entry box. The sequencer may be logic, hardware device, or software that accepts as input multiple incoming network packets on different input ports and emits as output a single sequence of network packets or multiple sequences of packets such that all orders that may relate to the same tradable asset are in the same sequence.

[0390] The one or more input sequences can be generated by a message or packet serialization mechanism integrated into the order entry box such that the order entry box inputs are multiple network packets on multiple input ports. The multiple packets on the multiple input ports can be issued into an ordered sequence or unordered sequences by the integrated sequencing mechanism such that all orders for a given tradable asset can be included in the same sequence. The resulting one or more ordered sequences can be used for further processing by the order entry box.

[0391] The order input box can be configured to produce as output a sequence of records of a trading session (sequence of records), i.e., a sequence of orders that establishes a sequence that can be analyzed to determine which orders trade-matched with which other orders. The sequence of records can contain all information necessary to reconstruct the outcome of a trading session, including, but not limited to, participant identities, order prices, quantities, directions, and other order parameters.

[0392] The order input box can be configured to immediately emit each input flow-through order as an output in the absence, and only in the absence, of any trigger orders or hidden limit orders, i.e., in the absence of any trigger orders or hidden limit orders, any flow-through order received as an input is immediately emitted as an output in the same sequence in which the flow-through order was received from one or more input sequences.

[0393] The order input box can be configured to issue the underlying orders from the trigger orders to its output sequence when any trigger orders are in place, based on the processed orders, any flow through other information processed, or in response to evolving market conditions, book state, or book state as determined by any information processed therein.

[0394] The order input box may be configured to issue non-display limit orders to its output sequence when any non-display limit orders are in place, based on any flow through processed orders, other processed information, or in response to evolving market conditions, book state, or book state as determined by any information processed therein.

[0395] The order entry box can be configured to produce as output a sequence of orders suitable for release to market participants (an immediate release sequence). This output sequence may be identical to the sequence of records or may include orders from the sequence of records, although certain information in this output may be redacted or otherwise obscured. For example, the identity of the participants may be redacted or obscured.

[0396] The order entry box can be configured to store each trigger order in memory, referred to as a trigger order queue (TOQ) regardless of the underlying implementation. The order entry box may also be configured to store each hidden limit order in memory, referred to as a hidden limit order queue (HLOQ) regardless of the underlying implementation.

[0397] The order entry box can be configured to retrieve a set of associated trigger orders from the trigger order queue for each flow through the processed orders. The set of trigger orders retrieved in this way may be all trigger orders sent. The set of trigger orders retrieved in this way may be a subset of trigger orders that can be triggered based on the symbol or underlying traded asset of the flow through the orders being processed. The set of trigger orders retrieved in this way may be a subset of trigger orders that can be triggered based on the symbol and order type, price, or quantity, or other order parameters of the flow through the orders being processed, or based on other available data or information.

[0398] The order entry box can be configured to retrieve a set of associated non-display limit orders from the non-display limit order queue for each flow through a processed order. The set of non-display limit orders so obtained may be all submitted non-display limit orders. The set of non-display limit orders so obtained may be a subset of non-display limit orders that can be triggered, published, or partially published based on the symbol or underlying trading asset of the flow through the order being processed. The set of non-display limit orders so obtained may be a subset of non-display limit orders that can be triggered, published, or partially published based on the symbol and order type, price, or quantity, or other order parameters of the flow through the order being processed, or based on other available data or information.

[0399] The order entry box may be configured to analyze the trigger order based on each flow through the order using one or more predicate evaluators, each such predicate evaluator designed to analyze an individual predicate or condition contained in a given trigger order. The one or more predicate evaluators, independent of its or its underlying implementation as hardware, software, or hardware-software co-design, may be referred to as trigger order injection logic (TO-IL).

[0400] Each predicate evaluator in TO-IL may be configured to receive as input the flow through orders or other data processed and received as input by the order entry box, including, but not limited to, book state such as price and quantity, or aggregated prices and quantities of bids and offers for tradable assets. Each predicate evaluator may be configured to accept as input a trigger order or a trigger order predicate or condition. Each predicate evaluator may be configured to provide as output a determination of whether the trigger order condition or predicate is satisfied based on its input and based on new information gained by analyzing the flow through order entry data.

[0401] The order entry box may be configured to expose, include, or emit underlying orders into a sequence of records from any trigger order where a predicate or condition is met based on one or more outputs of the TO-IL.

[0402] The order entry box may be configured to analyze the hidden limit orders based on each flow through the order using a predicate evaluator or predicate evaluators, each such predicate evaluator designed to analyze an individual predicate or condition contained in a given hidden limit order. One or more predicate evaluators, independent of its or its underlying implementation as hardware, software, or hardware / software co-design, are referred to herein, without limitation, as hidden limit order injection logic (HLO-IL).

[0403] Each predicate evaluator in the HLO-IL may be configured to receive as input the flow through orders or other data processed and received as input by the order entry box, including, but not limited to, book state such as price and quantity, or aggregated prices and quantities of bids and offers for tradable assets. Each predicate evaluator may be configured to accept as input a hidden limit order or a predicate or condition for the disclosure of the hidden limit order. Each predicate evaluator may be configured to provide as output a determination of whether the hidden limit order condition or predicate is satisfied based on its input and based on new information obtained by analyzing the flow through order entry data.

[0404] In some embodiments, the system includes circuitry configured to receive as inputs external or third-party market data packets, external or third-party market data information, or external or third-party market data events, referred to in these claims as third-party market data. Such third-party market data may include, but is not limited to, market data or events published by other trading venues or exchanges. The circuitry may be further configured to utilize the third-party market data to trigger the publication of underlying orders from triggering orders or to cause the publication or partial publication of hidden limit orders. For example, in the context of US NMS stocks, if the third-party market data indicates the position of the NBBO, the circuitry may be further configured to utilize the third-party market data as information to adjust the current venue trading state, and trading may be enabled or disabled accordingly. The circuitry may be further configured to emit the third-party market data at its output in either a recorded sequence or a published sequence.

[0405] The circuitry may be configured to receive or input as input a regulatory information packet, regulatory data, or regulatory event, including, for example, NBBO information or data, LULD information or data, or substantially similar regulatory or compliance information or data. Such information is referred to in these claims as regulatory input data. The circuitry may be further configured to utilize the regulatory input data to trigger the issuance of an underlying order from a trigger order or to cause the publication or partial publication of a hidden limit order. The circuitry may be further configured to utilize the regulatory input data to adjust the current on-site trading situation in the context of US NMS stocks, for example, if the regulatory input data indicates the position of the NBBO, and the trade may then be validated or invalidated accordingly, or if the regulatory input data indicates the suspension or resumption of trading, for any reason. The circuitry may be further configured to emit the regulatory input data at its output in either a recorded sequence or a published sequence.

[0406] The circuitry may be configured to receive other market participant programming events, including, for example, but not limited to, programming metadata associated with trigger orders, conditional orders, or predicate orders. For example, the circuitry may update parameters of programming associated with an already issued conditional or trigger order or parameterized or administrative trigger order.

[0407] The system may include circuitry that implements packet serialization based on the arrival sequence of input network packets on the multiple input ports, the circuitry being either external to and separate from the order input box, or internal to and integrated into the order input box.

[0408] The circuitry may be configured to generate a single sequence of ordered messages based on input of messages from multiple input ports. The circuitry may be configured to generate multiple sequences of ordered messages based on input of messages from multiple input ports, subject to the invariant that all orders for a given tradable asset are always assigned to the same output sequence.

[0409] The circuitry may be configured such that when multiple messages appear to arrive simultaneously, e.g., within a time window that is small enough that the technology underlying the implementation is unable to determine which input packet arrived first, an arbitration mechanism can determine which of the apparently simultaneously arriving input packets should be issued first to the ordered output sequence.

[0410] The arbitration mechanism may be configured as a round-robin mechanism in which inputs from apparently simultaneous input ports are selected in a rotating or wrapping sequence, or the arbitration mechanism may be configured so that inputs from apparently simultaneous input ports are selected randomly or pseudo-randomly, or the arbitration mechanism may be configured so that inputs from apparently simultaneous input ports are selected according to any other arbitration method.

[0411] The system may include circuitry including message filters to prevent fraudulent, invalid, or otherwise undesirable messages from further processing. Such invalid or fraudulent messages may be dropped. In some embodiments, invalid or fraudulent messages may be logged by an audit tap. In particular, but not by way of limitation, such invalid or fraudulent messages may not be processed by the TO-IL or HLO-IL, may not be stored in the TOQ or HLOQ, and / or may not be published in either the output sequence of records or the output publication sequence. A message may be fraudulent if it does not contain necessary identifying information sufficient to verify an authorized market participant. Such identifying information may include, but is not limited to, a shared secret taught by symmetric or public key cryptography, or any of a number of authentication methods. A message may be deemed invalid if its parameters exceed preset or dynamically set system limits for those parameters. For example, if the underlying order price is too high or too low. A message may be deemed undesirable based on other criteria related to the particular trading venue or financial exchange in question.

[0412] The system may implement a liquidity tracking unit (LTU). The LTU may be configured to receive participant orders and identify self-matching. The LTU may be configured to convert self-matching into cancellations, fully or partially (e.g., depending on the amount of the self-matching amount). The LTU may be configured to receive participant orders and identify cancellations that cover liquidity that has already been removed from the book. The LTU may be configured to withdraw cancellation messages or modify the cancellation count depending on the remaining participant aggregate count.

[0413] The system may include audit taps located at multiple different system junctions that are configured to record or transmit for recording all messages, packets, or orders that arrive at the audit tap.

[0414] The system may include a priority sequencer in communication with the TO-IL, whereby if multiple underlying orders from a trigger order are issued in response to a single event being processed, they are issued in a sequence of record and published sequence according to their respective priorities as determined by rules published by the trading venue or financial exchange.

[0415] The system may include a priority sequencer in communication with the HLO-IL, whereby if multiple non-display limit orders are published, published, or partially published in response to a single event being processed, they are published in a sequence of records and a sequence of publications according to their respective priorities determined by rules published by the trading venue or financial exchange.

[0416] The system can include a trigger order queue (TOQ). The TOQ can be a memory table implemented directly in hardware, either as an ASIC or FPGA hardware, with indexes into the memory table constructed based on categories to which the trigger order can respond, e.g., event type and asset. The event type and underlying asset can be indexed, with the event type being a column in the table, and the column indicating priority.

[0417] Publishing an order may include publishing the status of the order book, publishing matching events, and / or notifying participants of accepted orders, fills, or cancellations. Publishing an order may include publishing an order feed that matches an existing order feed. Publishing may be performed by a matching engine.

[0418] In some embodiments, the circuitry is a field programmable gate array (FPGA). The response time between the FPGA and the order entry box can be approximately 25 nanoseconds. In other embodiments, the circuitry is an application specific integrated circuit (ASIC). The response time between the ASIC and the order entry box can be approximately 2.5 nanoseconds. The order entry box generates timestamp data.

[0419] In some embodiments, the queue is a trigger order queue. The queue may be a hidden limit order queue. Queue priority may be ranked by at least one of transparency, risk, equity, or market participation. Transparency may include public and private orders or anonymous orders. Equity may include order cancellations. Risk may include price improvement, minimum size of event type, or public and private orders. Market participation may include pro rata allocation by participation.

[0420] In some embodiments, a computer-implemented method for providing a user with authenticated access to an external system includes receiving, by a management system, authenticated access to the external system, the authenticated access being based on the external system validating an expression; a processor receiving a token for authenticating the identity of the user, the token including identification information of the user; the processor transmitting the token to an interface of an issuing system; the processor receiving a statement validated by the issuing system, the statement being based on the token; the processor generating an expression, the expression being based on the statement; the processor transmitting the expression to the interface of the external system; and receiving, by the processor, authenticated access to the external system, the authenticated access being based on the external system validating the expression. Data Processing System for Implementing the Embodiments of the Present Description

[0421] FIG. 15 illustrates a block diagram of an exemplary data processing system 1500 upon which embodiments may be implemented. Data processing system 1500 is an example of a computer, such as a server or client, upon which computer-usable code or instructions implementing processes for exemplary embodiments of the present invention may be located. In some embodiments, data processing system 1500 may be a server computing device. For example, data processing system 1500 may be implemented on a server or another similar computing device. Data processing system 1500 may include a portion of exchange side 155, as shown in FIG. 2A . Data processing system 1500 may be configured to send and receive information to participant side 105, for example.

[0422] In the illustrated example, data processing system 1500 may employ a hub architecture including a northbridge and memory controller hub (NB / MCH) 1501 and a southbridge and input / output (I / O) controller hub (SB / ICH) 1502. NB / MCH 1501 may be connected to a processing unit 1503, main memory 1504, and a graphics processor 1505. Graphics processor 1505 may be connected to NB / MCH 1501 via, for example, an Accelerated Graphics Port (AGP) or a PCI / PCIe interface.

[0423] In the illustrated example, a network adapter 1506 connects to the SB / ICH 1502. An audio adapter 1507, a keyboard and mouse adapter 1508, a modem 1509, a read-only memory (ROM) 1510, a hard disk drive (HDD) 1511, an optical drive (e.g., CD or DVD) 1512, a universal serial bus (USB) port and other communication ports 1513, and PCI / PCIe devices 1514 can be connected to the SB / ICH 1502 via a bus system 1516. The PCI / PCIe devices 1514 can include an Ethernet adapter, an add-in card, and / or a PC card for a notebook computer. The ROM 1510 can be, for example, a Flash Basic Input / Output System (BIOS). The HDD 1511 and the optical drive 1512 can use an Integrated Drive Electronics (IDE) or a Serial Advanced Technology Attachment (SATA) interface. A super I / O (SIO) device 1515 may be connected to the SB / ICH 1502.

[0424] An operating system can run on the processing unit 1503. The operating system can coordinate and provide control of various components within the data processing system 1500. As a client, the operating system can be a commercially available operating system. An object-oriented programming system, such as the Java™ programming system, can work in conjunction with the operating system to provide calls to the operating system from object-oriented programs or applications running on the data processing system 1500. As a server, the data processing system 1500 can be an IBM® eServer™ System® running the Advanced Interactive Executive operating system or the Linux® operating system. The data processing system 1500 can be a symmetric multiprocessor (SMP) system that includes multiple processors in the processing unit 1503. The data processing system 1500 can include cloud processing. Alternatively, a single processor system can be used.

[0425] Instructions for the operating system, object-oriented programming system, and applications or programs are located on storage devices such as HDD 1511 and loaded into main memory 1504 for execution by processing unit 1503. The processing of the embodiments described herein may be performed by processing unit 1503 using computer-usable program code, which may be located in, for example, main memory 1504, a memory such as ROM 1510, or one or more peripheral devices.

[0426] The bus system 1516 may comprise one or more buses. The bus system 1516 may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. A communications unit, such as modem 1509 or network adapter 1506, may include one or more devices that can be used to send and receive data.

[0427] Those skilled in the art will appreciate that the hardware depicted in FIG. 15 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives, may be used in addition to or in place of the hardware depicted. Additionally, data processing system 1500 may take the form of any of a number of different data processing systems, including, but not limited to, a client computing device, a server computing device, a tablet computer, a laptop computer, a telephone or other communications device, a personal digital assistant, etc. In essence, data processing system 1500 can be any known or later-developed data processing system without architectural limitation.

[0428] As disclosed herein, features consistent with the present embodiments may be implemented via computer hardware, software, and / or firmware. For example, the systems and methods disclosed herein may be embodied in various forms, including, for example, databases, digital electronic circuitry, firmware, software, computer networks, data processors such as computers, including servers, or combinations thereof. Furthermore, while some of the disclosed implementations describe specific hardware components, systems, and methods consistent with the innovations herein, any combination of hardware, software, and / or firmware may be implemented. Furthermore, the above-described features and other aspects and principles of the innovations herein may be implemented in a variety of environments. Such environments and related applications may be specially constructed to execute various routines, processes, and / or operations according to the embodiments, or they may include computers or computing platforms selectively activated or reconfigured by code to provide the required functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and may be implemented by any suitable combination of hardware, software, and / or firmware. For example, various machines may be used with programs written in accordance with the teachings of the embodiments, or it may be more convenient to construct specialized apparatus or systems to perform the required methods and techniques.

[0429] Aspects of the methods and systems described herein, such as logic, may be implemented as programmed functions in any of a variety of circuits, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs), programmable array logic (PAL) devices, electrically programmable logic and memory devices, and standard cell-based devices, as well as application-specific integrated circuits. Some other possibilities for implementing aspects include memory devices, microcontrollers with memory (e.g., EEPROMs), embedded microprocessors, firmware, software, etc. Additionally, aspects may be implemented in microprocessors with software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. The underlying device technology may be provided in a variety of component types, such as metal-oxide-semiconductor field-effect transistor (MOSFET) technology, e.g., complementary metal-oxide-semiconductor ("MOS"), bipolar technology, such as emitter-coupled logic (ECL), polymer technology (e.g., silicon-conjugated polymers and metal-conjugated polymer-metal structures), mixed analog and digital, etc.

[0430] It should also be noted that the various logic and / or functions disclosed herein, in terms of their behavior, register transfers, logical components, and / or other characteristics, may be enabled using any number of combinations of hardware, firmware, and / or as data and / or instructions embodied in various machine-readable or computer-readable media. Computer-readable media in which such formatted data and / or instructions may be embodied include, but are not limited to, various forms of non-volatile storage media (e.g., optical, magnetic, or semiconductor storage media), as well as carrier waves that can be used to transfer such formatted data and / or instructions via wireless, optical, or wired signal media, or any combination thereof. Examples of transfer of such formatted data and / or instructions via a carrier wave include, but are not limited to, transfer (upload, download, email, etc.) over the Internet and / or other computer networks via one or more data transfer protocols (e.g., H3P, FTP, SMTP, etc.).

[0431] Unless the context clearly requires otherwise, throughout the specification and claims, words like "comprise," "comprising," and the like, are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is, meaning "without being limited to." Words using the singular or plural also include the plural or singular, respectively. Furthermore, the words "herein," "hereunder," "above," "below," and words of similar import refer to this application as a whole and not to particular portions of this application. When the word "or" is used in reference to a list of two or more items, the word encompasses all of the following interpretations of that word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

[0432] While certain presently preferred implementations of the description have been specifically described herein, it will be apparent to those skilled in the art to which the description pertains that variations and modifications of the various embodiments shown and described herein may be made without departing from the spirit and scope of the implementations. Accordingly, it is intended that the embodiments be limited only to the extent required by the applicable rules.

[0433] The present embodiments may be embodied in the form of methods and apparatuses for practicing these methods. The present embodiments may also be embodied in the form of program code embodied in a tangible medium, such as a floppy diskette, a CD-ROM, a hard drive, or any other machine-readable storage medium, which, when loaded into and executed by a machine, such as a computer, becomes an apparatus for practicing the embodiments. The present embodiments may also be in the form of program code, for example, whether stored on a storage medium, loaded into and / or executed by a machine, or transmitted via some transmission medium, such as electrical wiring or cabling, via optical fiber, or via electromagnetic radiation, which, when loaded into and executed by a machine, such as a computer, becomes an apparatus for practicing the embodiments. When implemented on a processor, the program code segments combine with the processor to provide a unique device that operates similarly to specific logic circuits.

[0434] The software is stored on a machine-readable medium, which can take many forms, including, but not limited to, a tangible storage medium, a carrier wave medium, or a physical transmission medium. Non-volatile storage media include, for example, optical or magnetic disks, such as any of the storage devices of any computer or the like. Volatile storage media include dynamic memory, such as the main memory of such a computer platform. Tangible transmission media include coaxial cables, copper wire, and optical fibers, including the wires that comprise a bus within a computer system. Carrier wave transmission media can take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Thus, common forms of computer-readable media include, for example, disks (e.g., rigid, flexible, or flexible) or any other magnetic media, CD-ROMs, DVDs or DVD-ROMs, any other optical media, any other physical storage media, RAMs, PROMs and EPROMs, FLASH-EPROMs, any other memory chips, carrier waves carrying data or instructions, cables or links carrying such carrier waves, or any other medium from which a computer can read programming code and / or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

[0435] The above description has been set forth with reference to specific embodiments for purposes of explanation. However, the above illustrative description is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments have been chosen and described to best explain the principles of the embodiments and their practical applications, thereby enabling others skilled in the art to best utilize various embodiments with various modifications suited to the particular applications contemplated.

[0436] While the above relates to the embodiments described herein, other and further embodiments may be devised without departing from the basic scope thereof. For example, aspects of the present disclosure may be implemented in hardware or software, or a combination of hardware and software. An embodiment described herein may be implemented as a program product for use with a computer system. The program of the program product defines the functions of the embodiment (including the methods described herein) and may be contained on various computer-readable storage media. Exemplary computer-readable storage media include, but are not limited to: (i) a non-writable storage medium on which information is permanently stored (e.g., a read-only memory (ROM) device within a computer, such as a CD-ROM disk readable by a CD-ROM drive, flash memory, a ROM chip, or any type of solid-state non-volatile memory); and (ii) a writable storage medium on which changeable information is stored (e.g., a floppy disk in a diskette drive or hard disk drive or any type of solid-state random access memory). Such computer-readable storage media, when carrying computer-readable instructions that direct the functions of the disclosed embodiments, are embodiments of the present disclosure.

[0437] Those skilled in the art will understand that the foregoing examples are illustrative and not limiting. All permutations, extensions, equivalents, and improvements thereon will be apparent to those skilled in the art upon reading this specification and studying the drawings, and are intended to be included within the true spirit and scope of the present disclosure. Accordingly, the following appended claims are intended to cover all such modifications, permutations, and equivalents that fall within the true spirit and scope of these teachings.

Claims

1. 1. A system for managing a plurality of input ports, comprising: a plurality of input ports including a first input port and a second input port; at least one processor; A non-transitory processor-readable storage medium that, when executed, receiving a plurality of data packets from the first input port and the second input port, a first portion of the plurality of data packets defining a first message and a second portion of the plurality of data packets defining a second message, each of the first message and the second message comprising at least one message type of an order message, a cancel message, a trigger order message, or a limit order message; matching the first portion of the plurality of data packets with the first message and matching the second portion of the plurality of data packets with the second message; ordering the first message and the second message in a sequence of records based on one or more arbitration rules; Exposing a sequence of records through a network interface; After publishing the sequence of records, evaluating orders associated with the first message and the second message using a matching algorithm based on the sequence of records to generate matching information; Publishing the matching information through the network interface; a non-transitory processor-readable storage medium comprising one or more programming instructions that cause at least one processor to perform the steps of: A system comprising:

2. the first message is a trigger order message; The one or more programming instructions: storing the trigger order message in a trigger order queue; the trigger order queue comprises a trigger condition for the trigger order message; evaluating a status of the trigger condition based on at least one of the second message, the received external condition, and the matching information; entering an underlying order of the first message in the sequence of records based on the evaluation; and The system of claim 1 , further comprising:

3. 2. The system of claim 1, wherein the one or more programming instructions further cause the processor to omit the first message from the publication of the sequence of records based on the message type of the first message.

4. the first message is a hidden limit order message; The one or more programming instructions: storing the non-display limit order message in a non-display limit order queue, the non-display limit order queue comprising a trigger condition for the non-display limit order message; evaluating a status of the trigger condition based on at least one of the second message and a change in display fluidity associated with the second message; entering an underlying order of the first message in the sequence of records based on the evaluation; and The system of claim 1 , further comprising:

5. 2. The system of claim 1, wherein the one or more programming instructions that cause the processor to expose the sequence of records through the network interface further cause the processor to edit a portion of the first message.

6. The one or more programming instructions that cause the processor to evaluate the status of the trigger condition include: determining message information associated with the second message comprising at least one of a symbol, a price, and a quantity; comparing the message information to the trigger condition; The system of claim 2 , further causing the processor to:

7. 10. The system of claim 1, wherein the one or more programming instructions further cause the processor to receive a third-party market data packet on at least one of the plurality of input ports.

8. The system of claim 1 , wherein the one or more programming instructions further cause the processor to receive a regulatory information data packet at at least one of the plurality of input ports.

9. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input port in a rotating sequence. The system of claim 1 .

10. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input port according to an arbitration scheme. The system of claim 1 .

11. The one or more programming instructions: determining whether the first message is at least one of fraudulent and invalid, wherein the first message is fraudulent if the first message does not contain necessary identifying information sufficient to identify an authorized market participant, and the first message is invalid if a parameter associated with the first message is outside a predetermined threshold range; omitting the first message from the sequence of records based on the determination; and The system of claim 1 , further comprising:

12. The system of claim 11 , wherein the identifying information comprises a shared secret key generated by at least one of symmetric cryptography and public key cryptography.

13. The system of claim 11 , wherein the identification information comprises an authentication token.

14. 10. The system of claim 1, further comprising a liquidity tracking unit configured to track the total liquidity of an asset associated with at least one of the first message and the second message.

15. The system of claim 1 , wherein the one or more programming instructions further cause the processor to publish hypothetical future market data.

16. 16. The system of claim 15, wherein the one or more programming instructions further cause the processor to generate a trigger order message, a trigger condition based on the hypothetical future market data.

17. the first message is a trigger order message; The one or more programming instructions: storing the trigger order message in a trigger order queue; the trigger order queue comprises a trigger condition for the trigger order message; evaluating a status of the trigger condition based on a co-hosted predictive model; entering an underlying order for the first message in the sequence of records based on the status; The system of claim 1 , further comprising:

18. 1. A method for managing multiple input ports, comprising: receiving, by a processor, a plurality of data packets from a plurality of input ports comprising a first input port and a second input port, a first portion of the plurality of data packets defining a first message and a second portion of the plurality of data packets defining a second message, each of the first message and the second message comprising at least one message type of an order message, a cancel message, a trigger order message, or a non-display limit order message; matching, by the processor, the first portion of the plurality of data packets with the first message and the second portion of the plurality of data packets with the second message; ordering, by the processor, the first message and the second message in a sequence of records based on one or more arbitration rules; publishing, by said processor, said sequence of records over a network interface; evaluating, by the processor, after revealing the sequence of records, orders associated with the first message and the second message using a matching algorithm based on the sequence of records to generate matching information; publishing, by the processor, the matching information through the network interface; A method comprising:

19. the first message is a trigger order message, and the method includes: storing, by the processor, the trigger order message in a trigger order queue, the trigger order queue comprising a trigger condition for the trigger order message; evaluating, by the processor, a status of the trigger condition based on at least one of the second message, the received external condition, and the matching information; entering, by said processor, an order underlying said first message in said sequence of records based on said status; 20. The method of claim 18, further comprising:

20. 20. The method of claim 18, further comprising omitting the first message from the publication of the sequence of records based on the message type of the first message.

21. the first message is a hidden limit order message, and the method further comprises: storing, by the processor, the non-displayed limit order message in a non-displayed limit order queue, the non-displayed limit order queue comprising a trigger condition for the non-displayed limit order message; evaluating, by the processor, a status of the trigger condition based on at least one of the second message and a change in display fluidity associated with the second message; entering, by said processor, an underlying order of said first message in said sequence of records based on said evaluation; 20. The method of claim 18, further comprising:

22. 20. The method of claim 18, wherein publishing the sequence of records further comprises redacting a portion of the first message.

23. Evaluating the status of the trigger condition comprises: determining, by the processor, message information associated with a second message comprising at least one of a symbol, a price, and a quantity; comparing, by the processor, the message information with the trigger condition; 20. The method of claim 19, further comprising:

24. 20. The method of claim 18, further comprising receiving, by the processor, a third-party market data packet on at least one of the plurality of input ports.

25. 20. The method of claim 18, further comprising receiving, by the processor, a regulatory information data packet at at least one of the plurality of input ports.

26. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input port in a rotating sequence.

20. The method of claim 18.

27. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input port according to an arbitration scheme.

20. The method of claim 18.

28. determining, by the processor, whether the first message is at least one of fraudulent and invalid, wherein the first message is fraudulent if the first message does not contain necessary identifying information sufficient to identify an authorized market participant, and the first message is invalid if a parameter associated with the first message is outside a predetermined threshold range; omitting, by the processor, the first message from the sequence of records based on the determination.

20. The method of claim 18, further comprising:

29. 30. The method of claim 28, wherein the identifying information comprises a shared secret key generated by at least one of a symmetric cryptography and a public key cryptography.

30. 30. The method of claim 28, wherein the identification information comprises an authentication token.

31. 20. The method of claim 18, further comprising tracking, by the processor, in a liquidity tracking unit, the aggregate liquidity of assets associated with at least one of the first message and the second message.

32. 20. The method of claim 18, further comprising publishing, by the processor, hypothetical future market data.

33. 33. The method of claim 32, further comprising generating, by the processor, a trigger order message, wherein a trigger condition is based on the hypothetical future market data.

34. the first message is a trigger order message, and the method includes: storing, by the processor, the trigger order message in a trigger order queue, the trigger order queue comprising a trigger condition for the trigger order message; evaluating, by the processor, a status of the trigger condition based on a co-hosted predictive model; entering, by said processor, an order underlying said first message in said sequence of records based on said status; 20. The method of claim 18, further comprising:

35. 1. A system for managing a plurality of input ports, comprising: a plurality of input ports including a first input port and a second input port; at least one processor; A non-transitory processor-readable storage medium that, when executed, receiving a plurality of data packets from the first input port and the second input port, a first portion of the plurality of data packets defining a first message and a second portion of the plurality of data packets defining a second message, the first message being a trigger order message and the second message comprising at least one of the following message types: an order message, a cancel message, a trigger order message, or a limit order message; matching the first portion of the plurality of data packets with the first message and matching the second portion of the plurality of data packets with the second message; ordering the second message in the sequence of records based on one or more arbitration rules; storing the first message in a trigger order queue, the trigger order queue comprising a trigger condition for the first message; evaluating a status of the trigger condition based on at least one of the second message, a received external condition, and historical matching information; entering an underlying order of the first message in the sequence of records based on the evaluation; and evaluating, using a matching algorithm, an order associated with the first message and the second message based on the sequence of the records to generate matching information; Publishing the matching information through a network interface; a non-transitory processor-readable storage medium comprising one or more programming instructions that cause the at least one processor to: A system comprising:

36. 36. The system of claim 35, wherein the one or more programming instructions further cause the processor to publish the sequence of records through the network interface before using the matching algorithm.

37. 37. The system of claim 36, wherein the one or more programming instructions further cause the processor to omit the second message from the publication of the sequence of records based on the message type of the second message.

38. the second message is a hidden limit order message; The one or more programming instructions: storing the non-display limit order message in a non-display limit order queue, the non-display limit order queue comprising a trigger condition for the non-display limit order message; evaluating a status of the trigger condition based on at least one of a third message and a change in display fluidity associated with the third message; entering an underlying order of the second message in the sequence of records based on the evaluation; and 36. The system of claim 35, further causing the processor to:

39. 37. The system of claim 36, wherein the one or more programming instructions that cause the processor to publish the sequence of records through the network interface further cause the processor to edit a portion of the second message.

40. The one or more programming instructions that cause the processor to evaluate the status of the trigger condition include: determining message information associated with the second message comprising at least one of a symbol, a price, and a quantity; comparing the message information to the trigger condition; 36. The system of claim 35, further causing the processor to:

41. 36. The system of claim 35, wherein the one or more programming instructions further cause the processor to receive a third-party market data packet on at least one of the plurality of input ports.

42. 36. The system of claim 35, wherein the one or more programming instructions further cause the processor to receive a regulatory information data packet at at least one of the plurality of input ports.

43. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input port in a rotating sequence.

36. The system of claim 35.

44. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input according to an arbitration scheme.

36. The system of claim 35.

45. The one or more programming instructions: determining whether the second message is at least one of fraudulent and invalid, wherein the second message is fraudulent if the first message does not contain necessary identifying information sufficient to identify an authorized market participant, and the second message is invalid if a parameter associated with the first message is outside a predetermined threshold range; omitting the second message from the sequence of records based on the determination; and 36. The system of claim 35, further causing the processor to:

46. 46. ​​The system of claim 45, wherein the identifying information comprises a shared secret key generated by at least one of a symmetric cryptography and a public key cryptography.

47. 46. ​​The system of claim 45, wherein the identification information comprises an authentication token.

48. 36. The system of claim 35, further comprising a liquidity tracking unit configured to track the total liquidity of an asset associated with at least one of the first message and the second message.

49. 36. The system of claim 35, wherein the one or more programming instructions further cause the processor to publish hypothetical future market data.

50. 50. The system of claim 49, wherein the one or more programming instructions further cause the processor to generate a new trigger order message, wherein a new trigger condition associated with the new trigger order message is based on the hypothetical future market data.

51. 49. The system of claim 48, wherein the one or more programming instructions cause the processor to evaluate the status of the trigger condition further based on a co-hosted predictive model.

52. 1. A method for managing multiple input ports, comprising: receiving, by a processor, a plurality of data packets from a plurality of input ports comprising a first input port and a second input port, a first portion of the plurality of data packets defining a first message and a second portion of the plurality of data packets defining a second message, the first message being a trigger order message and the second message comprising at least one message type of an order message, a cancel message, a trigger order message, or a limit order message; matching, by the processor, the first portion of the plurality of data packets with the first message and the second portion of the plurality of data packets with the second message; ordering, by the processor, the second messages in a sequence of records based on one or more arbitration rules; storing, by the processor, the first message in a trigger order queue, the trigger order queue comprising a trigger condition for the first message; evaluating, by the processor, a status of the trigger condition based on at least one of the second message, a received external condition, and historical matching information; entering, by said processor, an underlying order of said first message in said sequence of records based on said evaluation; evaluating, by the processor, an order associated with the first message and the second message based on the sequence of the records using a matching algorithm to generate matching information; publishing, by the processor, the matching information through a network interface; A method comprising:

53. 53. The method of claim 52, further comprising publishing the sequence of records over the network interface before using the matching algorithm.

54. 54. The method of claim 53, further comprising omitting the second message from the publication of the sequence of records based on the message type of the second message.

55. the second message is a hidden limit order message, and the method further comprises: storing, by the processor, the non-displayed limit order message in a non-displayed limit order queue, the non-displayed limit order queue comprising a trigger condition for the non-displayed limit order message; evaluating, by the processor, a status of the trigger condition based on at least one of a third message and a change in display fluidity associated with the third message; entering, by said processor, an underlying order of said second message in said sequence of records based on said evaluation; 53. The method of claim 52, further comprising:

56. 54. The method of claim 53, wherein publishing the sequence of records further comprises redacting a portion of the second message.

57. Evaluating the status of the trigger condition comprises: determining, by the processor, message information associated with a second message comprising at least one of a symbol, a price, and a quantity; comparing, by the processor, the message information with the trigger condition; 53. The method of claim 52, further comprising:

58. 53. The method of claim 52, further comprising receiving, by the processor, a third-party market data packet on at least one of the plurality of input ports.

59. 53. The method of claim 52, further comprising receiving, by the processor, a regulatory information data packet at at least one of the plurality of input ports.

60. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input port in a rotating sequence.

53. The method of claim 52.

61. the first message arrives at the first input port detectably simultaneously with the second message arriving at the second input port; the one or more arbitration rules comprising selecting the first input port and the second input port according to an arbitration scheme.

53. The method of claim 52.

62. determining, by the processor, whether the second message is at least one of fraudulent and invalid, wherein the second message is fraudulent if the first message does not contain necessary identifying information sufficient to identify an authorized market participant, and the second message is invalid if a parameter associated with the first message is outside a predetermined threshold range; omitting, by the processor, the second message from the sequence of records based on the determination; and 53. The method of claim 52, further comprising:

63. 63. The method of claim 62, wherein the identifying information comprises a shared secret key generated by at least one of a symmetric cryptography and a public key cryptography.

64. 63. The method of claim 62, wherein the identification information comprises an authentication token.

65. 53. The method of claim 52, further comprising tracking, by the processor, in a liquidity tracking unit, the aggregate liquidity of assets associated with at least one of the first message and the second message.

66. 53. The method of claim 52, further comprising publishing, by the processor, hypothetical future market data.

67. 67. The method of claim 66, further comprising generating, by the processor, a new trigger order message, wherein a new trigger condition associated with the new trigger order message is based on the hypothetical future market data.

68. 53. The method of claim 52, wherein evaluating the status of the trigger condition is further based on a co-hosted predictive model.

Images