Electronic trading with order matching constraints

Abstract

The present specification provides a system for order matching in electronic trading systems, enhancing processing and computational efficiency. The system can receive orders via a network- connected trading computing system, where each order can be subjected to a unique set of participant-configured constraints, including inclusion and opposing constraints. These constraints can determine the compatibility of orders for potential matching, aiming to execute a trade when all conditions are met, and thereby reduce computational burden of the processor. The system can thus reduce computational overhead by optimizing data processing and network usage.

Description

Electronic Trading with Order Matching ConstraintsFIELD

[0001] The present disclosure relates to technologically efficient configurations of electronic trading systems.BACKGROUND

[0002] Electronic trading systems, which may also be known as electronic exchanges or venues, allow market participants to buy and sell financial instruments, such as stocks, commodities, funds, and similar. Despite their advancements, these systems face several technological challenges that impact their efficiency, reliability, and the ability to meet the evolving and / or increasing demands to process electronic orders. As utilization of these systems scales, the processing and network resources can become strained leading to reduced computational efficiencies. Alternatively, the system may be augmented with what would otherwise be considered overpowered computing resources, provided to manage the increased volume of electronic transactions.SUMMARY

[0003] An aspect of the specification provides a method including: receiving a first order at a trading computing system from a first market participant system via a computer network; receiving a second order at the trading computing system from a second market participant system via the computer network; evaluating a set of constraints on the first order and the second order to determine whether to match the first order and the second order; and executing a trade when the set of constraints is satisfied; wherein the set of constraints is configured by the first market participant and includes: an inclusion constraint on the first order; and an opposing constraint on the second order.

[0004] An aspect of the specification provides a method, wherein the inclusion constraint includes a participation identifier being present in the first order.

[0005] An aspect of the specification provides a method, wherein the inclusion constraint includes an attribute of the first order matching a target value.

[0006] An aspect of the specification provides a method, wherein the attribute includes one or more of: an identifier of the first market participant; an account type; an account number; a session identifier of a connection of the first market participant system to the trading computing system; an order flow identifier; an identifier of a trader of a financial instrument of the first order; an identifier of the financial instrument or category thereof of the first order; a trading side of the first order; or a combination of such.

[0007] An aspect of the specification provides a method, wherein the opposing constraint includes an attribute of the second order matching a target value.

[0008] An aspect of the specification provides a method, wherein the attribute includes one or more of: an identifier of the second market participant; an account type; an account number; a session identifier of a connection of the second market participant system to the trading computing system; an order flow identifier; an identifier of a trader of a financial instrument of the second order; or a combination of such.

[0009] An aspect of the specification provides a method, wherein the opposing constraint includes past market activity of the second market participant matching a target market activity.

[0010] An aspect of the specification provides a method, wherein the past market activity of the second market participant is quantified by an average trade markout.

[0011] An aspect of the specification provides a method, wherein the target market activity is configurable as a discrete value, a range of values, or a quartile of values.

[0012] An aspect of the specification provides a method, wherein the set of constraints further includes a market constraint on a market condition.

[0013] An aspect of the specification provides a method, wherein the market constraint includes the market condition matching a target market condition including: an NBBO spread; an NBBO volume imbalance; an NBBO consensus index; an NBBO price; an NBBO quantity; or a combination of such.

[0014] An aspect of the specification provides a method, further including canceling or suspending the first order when the market constraint is not satisfied.

[0015] An aspect of the specification provides a method, further including modifying the first order when the market constraint is not satisfied.

[0016] An aspect of the specification provides a method, wherein the market constraint includes the market condition matching a prioritizable set of target market conditions.

[0017] An aspect of the specification provides a method, further including enforcing an active interval during which the set of constraints is active.

[0018] An aspect of the specification provides a method, wherein the inclusion constraint and the opposing constraint are prioritizable by the first market participant.

[0019] An aspect of the specification provides a method, wherein the set of constraints is evaluated in conjunction with other sets of constraints for other orders with reference to maximal overall trade quantity.

[0020] An aspect of the specification provides a computing system configured to perform the method.

[0021] An aspect of the specification provides a non-transitory machine-readable medium including instructions that, when executed by a processor, perform the method of any of the preceding claim.BRIEF DESCRIPTION OF THE FIGURES

[0022] FIG. 1 is a diagram of an example system for processing order messages according to constraints.

[0023] FIG. 2 is a diagram of an example set of constraints.

[0024] FIGs. 3A - 3F are diagrams of example graphical user interfaces for configuring constraints.

[0025] FIG. 4 is another diagram of an example user interface for configuring constraints including an order flow identifier.

[0026] FIG. 5 is another diagram of an example user interface for configuring constraints including an order flow identifier.DETAILED DESCRIPTION

[0027] The techniques discussed herein aim to give market participants greater control and flexibility over how their orders are matched and traded beyond the traditional price priority or price and time priority.

[0028] With reference to FIG. 1 , a system 100 includes a trading computing system 102, a plurality of market participant systems 104, a computer network 106, and a market data computing system 108. The trading computing system 102, market participant systems 104, and market data computing system 108 are connected to the computer network 106 and may share data via the computer network 106.

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

[0030] The processor 120 may include a central processing unit (CPU), a microprocessor, a processing core, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a similar device capable of executing the instructions 126. The terms “a processor” and “the processor,” as used herein, mean one or more processors that collectively execute instructions 126. When multiple processors are used, one processor may execute some instructions and another processor may execute other, cooperating instructions.

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

[0032] The network interface 124 includes hardware, such as a network adaptor, and software, such as a driver, to facilitate data communications via the computer network 106.

[0033] In this example, the trading computing system 102 operates according to an auction methodology. Orders are received and accumulated over a predefined period, such as 100 milliseconds (ms), at the end of which accumulated orders are matched to the extent possible and resulting trades are executed. Such periods are repeated continuously over the course of a trading day. This or similar auction methodology may be referred to as a micro-auction. In other examples, various techniques discussed herein may be used with continuous trading. For example, the opposing constraints discussed herein may be particularly well suited for continuous trading. The present disclosure is not limited to an auction methodology.

[0034] The instructions 126 implement the trading methodology as a matching engine or similar body of code. The instructions 126 further apply a set of constraints 128 on order matching, as will be discussed in detail below. The set of constraints 128 may also be stored at the medium 122.

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

[0036] Each market participant system 104 may include a general-purpose or special -purpose computer with one or more processors and a non-transitory machine-readable medium to receive input data and provide output data related to trades to be carried out at the trading computing system 102. Each market participant system 104 is capable of generating order messages 130 and transmitting order messages 130 to the trading computing system 102.

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

[0038] The market data computing system 108 includes a general-purpose or special-purpose computer with a processor and non-transitory machine -readable medium to obtain trading and / or order data 132 from various trading computing systems, such as the system 102, and publish related market data in human- or machine-intelligible formats. There may be any number of market data servers 108.

[0039] Market data provided by the market data server 108 may include trade data, such as trade price, trade volume, and trade time; and order data, such as order type (e.g., new, modification, cancelation, etc.), order side, order price, order volume, order time, order condition (e.g., limit or stop conditions), etc. Market data may be provided for various different financial instruments. The market data server 108 may publish market data in real time, at intervals, or according to a schedule.

[0040] The trading computing system 102 receives order messages 132 from the market participant systems 104. Received order messages 132 are processed to become orders. As mentioned above, the trading computing system 102 accumulates orders for a period. When the period elapses, the trading computing system 102 evaluates a set of constraints 128 and matches orders according to the set of constraints 128. The set of constraints 128 applicable to an order (buy or sell) and an opposing order (sell or buy) must be satisfied for the orders to be matched and a trade to result. Constraints 128 may reference market data, which may be obtained from the market data computing system 108 or from the trading computing system 102.

[0041] Each market participant system 104 may be in control of a set of constraints 128 or multiple sets of constraints 128. The market participant operating the market participant system 104 may configure their set of constraints 128 to facilitate their trading objectives. The instructions 126 at the trading computing system 102 configure and evaluate various sets of constraints 128 on behalf of market participant systems 104.

[0042] From the perspective of a market participant, a set of constraints 128 belonging to the market participant may constrain the orders made by the market participant, any opposing orders that may match with the market participant’s orders to form a trade, and market conditions. When all constraints are met, an order may trade, provided that price and other traditional priorities are also respected. In other words, a market participant’s set of constraints enables the market participant to dictate which of their orders will be allowed to match opposing orders, which opposing orders will be allowed to match their orders, and which market conditions must be present for a match to be made. This allows market participants to shape the logic that controls how their orders are matched, which gives market participants greater control and flexibility in meeting their trading objectives. Further, having constraints 128 evaluated by the trading computing system 102 in general or specifically at the matching engine at the trading computing system 102, may provide for faster and more reliable processing of orders.

[0043] The trading computing system 102, or a computer system connected thereto, may provide a graphical user interface (GUI) configured to allow market participants to manage their constraints 128. The GUI may be provided as a website or application.

[0044] FIG. 2 shows an example set of constraints 200 that may be applied to the matching of a market participant’s orders. If the constraints 200 are satisfied, then an order will trade with the subset of opposing orders that satisfy the constraints 200. If the constraints 200 are not satisfied, then other action is taken, such as the order trading normally or not trading. The set of constraints 200 includes an inclusion constraint 202 and an opposing constraint 204.

[0045] An inclusion constraint 202 is applied to the market participant’s own orders. An inclusion constraint 202 is configurable by the market participant and allows the market participant to define which of their orders are subject to the opposing constraint 204 and other constraints discussed below. If the inclusion constraint is not met, the order will trade normally. Any number and combination of inclusion constraints 202 may be implemented with the following being examples of useful inclusion constraints 202.

[0046] An example inclusion constraint 202 is a participation identifier being present in an order. When the participation identifier is present in the order, the order will be subject to other constraints. When the participation identifier is absent, the order will not be subject to otherconstraints and will trade normally. The participation identifier acts as a flag that enables or disables constraint functionality for a given order.

[0047] Another example inclusion constraint 202 is an attribute of a market participant’s order matching a target value. When an attribute that is present in the order or the order message that created the order matches the target value, then the order will be subject to other constraints. When the attribute does not match the target value, then the order will not be subject to other constraints and will trade normally. Attributes may also be referred to as fields, tags, properties, and so on.

[0048] Example attributes include an identifier of the market participant who created the order (e.g., trading firm ID), an account type associated with the order or market participant, an account number associated with the order or market participant, a session identifier of a connection of the market participant system to the trading computing system, an identifier of a trader of a financial instrument that is the subject of the order, an identifier of the financial instrument or category thereof of the order, and a trading side (e.g., buy or sell) of the first order. Another example attribute includes order flow identifier, that labels the order flow. If an order flow identifier is not provided, the system defaults the order to the lowest tiered flow associated with the origin of the order. In general, the order flow identifier can be used for categorizing or prioritizing orders within the trading system. (As used herein, "order flow" refers to the aggregate of buy and sell orders submitted to a trading system over a given period of time. It captures the dynamic flow of trade requests, including market orders, limit orders, and cancelations, that market participants send to a stock exchange, electronic trading platform, or other trading venue.) Firms can leverage order flow identifiers to segment their order flow based on performance metrics like trade markout. By assigning distinct identifiers to orders originating from different strategies, traders, or types of clients, firms can track and analyze the performance of each segment independently. Additionally, order flow segmentation allows firms to set constraints that prevent specific flow interaction like passive flow from trading against aggressive flow, which could lower the trade quality / performance, which in turn negatively impacts processor efficiency. FIG. 4 and FIG 5 show additional example user interfaces that include the ability to include an order flow identifier, according to the label “Counterparty Flow ID”. In FIG. 4, the field is blank, but in FIG 5. it is populated.

[0049] Target values for any such attributes may be configured by the market participant, so that the inclusion constraint 202 is operable to select the orders created by the market participant that will be subject to opposing constraints 204 and other constraints.

[0050] An opposing constraint 204 is applied to orders from other market participants. An opposing constraint 204 is configurable by the market participant and allows the market participant to define what kinds of opposing orders will match their own orders. If the opposing constraint is not met, the order will not trade. Any number and combination of opposing constraints 204 may be implemented with the following being examples of useful opposing constraints 204.

[0051] An example opposing constraint 204 is an attribute of an opposing market participant’s order matching a target value. When an attribute that is present in the opposing order or the order message that created the opposing order matches the target value, then the opposing order will be matchable with the market participant’s orders. When the attribute does not match the target value, then the opposing order will not be matchable with the market participant’s orders.

[0052] Example attributes for opposing orders include an identifier of the opposing market participant who created the order (e.g., trading firm ID), an account type associated with the opposing order or opposing market participant, an account number associated with the opposing order or opposing market participant, a session identifier of a connection of the opposing market participant system to the trading computing system, and an identifier of a trader of a financial instrument that is the subject of the opposing order.

[0053] Target values for any such attributes may be configured by the market participant who owns the opposing constraint 204, so that the opposing constraint 204 is operable to select the opposing orders created by opposing market participants that are matchable with the market participant’s own orders.

[0054] An example opposing constraint 204 is past market activity of an opposing market participant matching a target market activity. When past market activity of an opposing market participant matches the target market activity, then the opposing market participant’s orders will be matchable with the market participant’s orders. When past market activity of an opposingmarket participant does not match the target market activity, then the opposing market participant’s orders will not be matchable with the market participant’s orders.

[0055] Past market activity may be defined with respect to market participant identifier, market participant identifier and trader identifier, market participant identifier and account number, or similar single or combination of identifiers, such as those mentioned above. Past market activity may be defined in this way to be specific to the party that exhibits the market activity.

[0056] Past market activity may be quantified by various techniques, such as an average trade markout, trade volume analysis, order-to-trade ratio, or average order size, to name a few examples. Trade volume analysis may look for large volume traders that provide liquidity, and thus increase the likelihood that trades are filled completely. Data concerning past market activity may originate from a specific marketplace or from multiple marketplaces.

[0057] Target market activity may be configurable as a discrete value, a range of values, or a quartile of values. In the case of a discrete value, the opposing constraint 204 is satisfied when past market activity equals the discrete value. For a range, the opposing constraint 204 is satisfied when past market activity falls within the range of values. The same applies to a quartile, which is a specific kind of range, e.g., top 25%, bottom 25%, etc.

[0058] The set of constraints 200 may further a market constraint 206.

[0059] A market constraint 206 is applied to market conditions. An example market constraint 206 is a market condition matching a target market condition. When the market condition matches the target market condition, then an opposing market participant’s orders will be matchable with the market participant’s orders. When the market condition does not match the target market condition, then the opposing market participant’s orders will not be matchable with the market participant’s orders.

[0060] Examples of target market conditions include various indicators, a National Best Bid and Offer (NBBO), or other information contained in or derivable from market data. For example, an NBBO spread, an NBBO volume imbalance, an NBBO consensus index, an NBBO price, or an NBBO quantity may be referenced.

[0061] When the market constraint 206 is not satisfied, the order may not trade, the order may be suspended or canceled, or the order may be modified. A price / quantity curve may be applied depending on a market data factor and execution price. An example price / quantity curve executes a portion of the full quantity of an order against a matching price. For example, a curve may be defined for an order as: 100% of the order may be traded at a price between the NBBO and the NBBO midpoint, 50% of the order may be traded at the NBBO midpoint, and 25% may be traded at a price worse than the NBBO midpoint.

[0062] Market constraints 206 may be prioritizable with respect to each other, as relevant market data may indicate overlapping market conditions. The market participant may provide a priority for each market constraint 206 and a respective action (e.g., cancel, suspect, etc. J to take when the constraint 206 is not met. Market constraints 206 may be evaluated in order of priority with the first unmet constraint 206 dictating the action to take.

[0063] Market constraints 206 may be evaluated based on data provided by a market data computing system 108 (FIG. 1) or based on the same or similar data held by the trading computing system 102. In the latter case, the trading computing system 102 may generate the data itself or may fetch the data from the market data computing system 108.

[0064] The set of constraints 200 may further include an active interval 208. An active interval 208 applies temporal limitations on matching the market participant’s orders. An example active interval 208 may define an interval during which the set of constraints 200 is active and thus in effect. Outside the active interval 208, the order trades normally. Example active intervals include one hour, a trading day, forever, and so on.

[0065] The order of constraints shown in FIG. 2 is merely one example. In various implementations, the types of constraints 202, 204, 206, 208 may be evaluated in different orders. In addition, individual constraints of each type of constraint 202, 204, 206, 208 may be prioritizable with respect to each other. That is, it is not required that all constraints of a given type be evaluated before the constraints of a different type are evaluated. Each individual constraint may have a global priority.

[0066] The set of constraints 200 is evaluated in conjunction with other sets of constraints 200 for orders made by other market participants. Further, each market participant may or may not use constraints 200. Prior to performing price matching, evaluation of all sets of constraints 200 may be performed with the goal of maximal overall trade quantity. A matching algorithm such as price pro-rata or price first-in first-out (FIFO) may be used. A FIFO algorithm may consider broker preferencing, in that an order or market participant specifies brokers with whom trading is preferred. This type of broker preferencing may be used in conjunction with an opposing constraint that specifies a broker. For example, an opposing constraint may specify which brokers are eligible to trade with an order, and broker preferencing may subsequently be used to prioritize the matching of the order with the specified brokers.

[0067] FIGs. 3A - 3F show an example GUI for configuring constraints.

[0068] FIG. 3A shows a dashboard 300 that allows the selection and creation of various sets of constraints. A GUI element 302, such as a button, allows the creation of a new set of constraints. A GUI element 304, such as a button, may be provided to allow selection of an existing set of constraints. Activity and performance data may be displayed.

[0069] FIG. 3B shows an interface 310 that allows for the configuration of a set of constraints. GUI elements 312, such as checkboxes and dropdown selectors, provide for input of inclusion constraints. GUI elements 314, 316 such as checkboxes, dropdown selectors, and sliders, provide for input of opposing constraints.

[0070] FIGs. 3C and 3D show an interface 320 allows for the configuration of a set of constraints. GUI elements 322, such dropdown selectors and textboxes, allow for configuration of conditional (if-then) market constraints. GUI elements 324, such as dropdown selectors, provide for actions to take, such as do not trade, if a constraint is or is not met. A GUI element 326, such as a drag-and- drop handle, may be provided to each constraint to allow prioritization among the constraints. The example data shown in interface 320 relate to selecting trading price and quantity based on market conditions.

[0071] FIGs. 3E and 3F show additional interfaces 330, 340 to allow the configuration of market constraints. The example data shown in interface 330 relate to selecting price vs quantity. The example data shown in interface 340 relate to selecting quantity point.

[0072] In view of the above, it should be apparent that configurable constraints on orders with regard to how orders are matched may provide for greater customizability and flexibility to market participants.

[0073] It should be recognized that features and aspects of the various examples provided above can be combined into further examples that also fall within the scope of the present disclosure. In addition, the figures are not to scale and may have size and shape exaggerated for illustrative purposes.

[0074] The present specification provides certain technological advantages over prior art systems. For example, by implementing a system that evaluates constraints prior to matching orders, the teaching can potentially reduce the latency that would otherwise be associated with the computations for the decision-making process. This is because the constraints can be optimized and streamlined in advance, allowing the trading system to quickly assess compatibility between orders without unnecessary delay.

[0075] Additionally, the computing system's ability to store and retrieve the specific constraints effectively can lead to more efficient memory use. By structuring and indexing the constraints, the system can access and process them quickly, reducing the overhead required to handle large volumes of trading data.

[0076] Furthermore, the computing system can evaluate constraints across potentially large datasets of orders, optimizing usage of processors 120. This can mitigate overburdening of one or more processors 120 with complex calculations, thus maintaining system performance even under high load.

[0077] Furthermore, by focusing on electronic orders which satisfy the preliminary constraints which are further processed for matching, the system can reduce unnecessary data transmission over the network. This helps in conserving bandwidth as only relevant order data that has a higher probability of leading to a trade is communicated between systems.

[0078] In addition, the use of a computer network to interconnect different market participant systems and the trading computing system can allow for distributed processing of orders and constraints. This can help balance the load across multiple systems while enhancing the scalability of the trading system to handle increases in market activity without degradation of performance.

[0079] The system can also be configured to implement sophisticated data structures and databases to manage the constraints and orders efficiently. This includes using optimized query languages and storage mechanisms that enhance data retrieval speeds and reduce the computational cost of managing complex sets of trading data.

[0080] The trading computing system can also be equipped with real-time processing capabilities to handle live market data and instantaneously evaluate constraints. This ensures that trading decisions are based on the most current market conditions, minimizing the risk of outdated information affecting trade outcomes.

Claims

CLAIMS1. A computer-implemented method comprising: receiving a first order at a trading computing system from a first market participant system via a computer network; receiving a second order at the trading computing system from a second market participant system via the computer network; evaluating a set of constraints on the first order and the second order to determine whether to match the first order and the second order; and executing a trade when the set of constraints is satisfied; wherein the set of constraints is configured by the first market participant and includes: an inclusion constraint on the first order; and an opposing constraint on the second order.

2. The method of claim 1, wherein the inclusion constraint comprises a participation identifier being present in the first order.

3. The method of claim 1, wherein the inclusion constraint comprises an attribute of the first order matching a target value.

4. The method of claim 3, wherein the attribute comprises one or more of: an identifier of the first market participant; an account type; an account number; a session identifier of a connection of the first market participant system to the trading computing system;an order flow identifier; an identifier of a trader of a financial instrument of the first order; an identifier of the financial instrument or category thereof of the first order; a trading side of the first order; or a combination of such.

5. The method of claim 1, wherein the opposing constraint comprises an attribute of the second order matching a target value.

6. The method of claim 5, wherein the attribute comprises one or more of: an identifier of the second market participant; an account type; an account number; a session identifier of a connection of the second market participant system to the trading computing system; an order flow identifier; an identifier of a trader of a financial instrument of the second order; or a combination of such.

7. The method of claim 1, wherein the opposing constraint comprises past market activity of the second market participant matching a target market activity.

8. The method of claim 7, wherein the past market activity of the second market participant is quantified by an average trade markout.

9. The method of claim 7, wherein the target market activity is configurable as a discrete value, a range of values, or a quartile of values.

10. The method of claim 1, wherein the set of constraints further comprises a market constraint on a market condition.

11. The method of claim 10, wherein the market constraint comprises the market condition matching a target market condition including: an NBBO spread; an NBBO volume imbalance; an NBBO consensus index; an NBBO price; an NBBO quantity; or a combination of such.

12. The method of claim 10, further comprising canceling or suspending the first order when the market constraint is not satisfied.

13. The method of claim 10, further comprising modifying the first order when the market constraint is not satisfied.

14. The method of claim 10, wherein the market constraint comprises the market condition matching a prioritizable set of target market conditions.

15. The method of claim 1, further comprising enforcing an active interval during which the set of constraints is active.

16. The method of claim 1, wherein the inclusion constraint and the opposing constraint are prioritizable by the first market participant.

17. The method of claim 1, wherein the set of constraints is evaluated in conjunction with other sets of constraints for other orders with reference to maximal overall trade quantity.

18. A computing system configured to perform the method of any of the preceding claims.

19. A non-transitory machine -readable medium comprising instructions that, when executed by a processor, perform the method of any of claims 1-17.

Images