Interprocess communication for promoting cell side market-making

Abstract

To provide an electronic exchange platform for transaction of financial securities.SOLUTION: An electronic exchange platform receives a list of each of buy-side attendants approved for each of orders for a plurality of market makings, receives an order of market-making regarding a financial security from each of a plurality of sell-side attendants, performs tracking to a received order and for prices being below the best price by a plurality of ticks in a transaction side in an order book, presents market information to the buy-side attendants identifying orders in which the buy-side attendants are approved, identifies the sell-side attendants in which counter-offer received from the buy-side attendants being approved for transaction with a subset of a plurality of orders has priority, determines a best bid and offer according to distribution of the counter-offer, and maintains the tracking in response to the determination of the new best-bid or the offer by adjusting the remaining offer.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Application No. 62 / 350,141, filed June 14, 2016, U.S. Provisional Application No. 62 / 375,231, filed August 15, 2016, and U.S. Provisional Application No. 62 / 376,665, filed August 18, 2016, all of which are incorporated herein by reference in their entireties.

[0002] Some embodiments relate to sell-side market making in all-to-all markets to support privileged buy-side clients as a private liquidity provider. [Background technology]

[0003] Parties trade financial securities such as stocks, bonds, etc. Summary of the Invention [Problem to be solved by the invention]

[0004] The present invention is directed to solving the problems of the background art. [Brief description of the drawings]

[0005] [Figure 1] FIG. 1 illustrates an exemplary system according to some embodiments. [Diagram 2] 1 illustrates an exemplary method according to some embodiments. [Diagram 3] 1 illustrates an example of an interface that may be used in some embodiments. [Figure 4] 1 illustrates an example of an interface that may be used in some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] The following should be understood as embodiments, not claims.

[0007] First embodiment Various examples of trading systems and methods that can be used in some embodiments are described in U.S. patent application Ser. No. 14 / 059,000 to Sweeting et al. and U.S. patent application Ser. No. 12 / 938,189, also to Sweeting et al., both of which are incorporated by reference in their entireties.

[0008] Some embodiments may place orders with liquidity providers (sell-side banks and / or market makers at high frequency trading / proprietary trading firms in some markets, collectively referred to herein as the "sell-side") to facilitate liquidity for the buy-side (e.g., traditional fund managers, hedge fund managers, commodity trading advisors). Such liquidity-supply orders may be outside of the best bid / offer available through an all-to-all market, such as a central limit order book (CLOB, or simply "order book"). Nevertheless, such liquidity-supply orders may track to the best bid / offer. For example, the market may be manipulated using fractional pricing, where liquidity-supply orders may be set at a price two ticks away from the best bid / offer (lowering the bid and raising the ask in common percentage pricing formats, or lowering the ask and raising the bid in high yield formats). Other implementations may have other conventions, such as values ​​other than fractional values ​​and / or 1, 4, 10 ticks away (or minimum price movement) from the best price displayed in the CLOB. In other implementations, liquidity supply orders may not follow the best bid / offer at all. The platform may offer different system configurations per security section, such as (i) backing off by

[10] $ / m for $

[0100] m, (ii) backing off by

[20] $ / m for $

[0200] m, etc. The numbers in [] may be configurable on a daily or hourly basis, or may be linked to some external factor, such as potential or actual volatility.

[0009] The marketplace may be configured to show a list of trader logins and API connections and whether trading is available to those traders, as well as via the order management and execution management systems (OMS / EMS) of particular buy-side entities that are configured to see such liquidity provision.

[0010] In one example, passive liquidity supply orders to make a market may be $10 per million ($ / m) back from the top of the order book (e.g., a centralized limit order book or CLOB) priced in fractional percentage points. In some embodiments, for example, secured bonds are typically priced in 1 / 32 of a point, and as the top of the book CLOB price approaches a quarter of the recent 1 / 32 for buys and below for sells, the market may limit the price of liquidity supply orders below the top of the book CLOB price in fractional points, even within the traditional 1 / 32 price range of the CLOB displayed on other venues. Passive liquidity supply order prices may be limited to 1 / 32 increments of each fractional price as the fractional price approaches the 1 / 32 level. As a result, the predefined 10$ / m spread back (from the top of the book CLOB price) is temporarily compressed. The trading risk of squeezing the liquidity order may be higher as the 1 / 32 increments approach the all-to-all GLOB market price. This risk may also be limited if the market maker limits the quantity for favored buy-side clients in this liquidity pricing. The market maker compares market data (e.g., available through Phoenix) with other venues to see whether the liquidity order should remain as is (with or without such system-wide limitations) or be canceled given the market squeezing risk. It should be recognized that the increments are provided as non-limiting examples and other embodiments may include other increments (e.g., 1 / 2 of 1 / 32 for some secured notes or 1 / 8 of 1 / 32 for some off-run Treasuries up to 2-year maturity).

[0011] In some embodiments, users who place liquidity orders as described herein may be restricted from seeing the quantities of other users' liquidity orders. Instead, in some embodiments, liquidity orders may be visible only to buy-side entities that are configured by the system to see them, and may be displayed based on a mutual agreement between the market maker placing the liquidity orders to be followed and the buy-side clients viewing them. Such buy-side entities may also limit the disclosure of liquidity orders to those that the market maker wishes to disclose to the market at all times during the day. In some embodiments, additions to the list may be made via the market's production support team or by a "request for compensation" message through the graphical user interface (GUI), as is known in the art.

[0012] In some embodiments, liquidity provision orders may take into account, match, present, and / or use best bid / offer quantities (e.g., best price). A user interface presenting liquidity provision order information may be presented to order-enabling buy-side entities. Information about such orders may be presented to order-enabling buy-side users along with the regular order book. In some embodiments, order-enabling buy-side users may have such information available to them via a mouse-over pop-up interface showing them all of the liquidity available to buy-side traders behind the best bids and offers shown in the order book.

[0013] The quantity of the liquidity supply order may be displayed in the user interface in the new order ticket window. In some embodiments, aggressive liquidity supply order types may also be available. The best price in the order book and the quantity of the liquidity supply order may both be displayed separately in the user interface (e.g., the order book bids / offers above / below the liquidity orders behind these orders in the price specification). In some embodiments, depending on the quantity entered by the aggressive investor in either the buy or sell input element in the user interface, the liquidity supply quantity may be aggregated with the best bid / offer quantity in the order book and the average price of that quantity may be presented in the window. In some embodiments, sell down / buy up options may be available.

[0014] In some embodiments, passive liquidity supply orders may be accepted via FIX and / or the Itch / Ouch API. In some embodiments, market maker passive liquidity supply orders may be provided through the sell-side GUI. In other embodiments, orders may not be available through the sell-side GUI. In both sell-side GUI and API embodiments, visibility of other sell-side liquidity supply orders may be restricted or publicly viewable.

[0015] In some embodiments, traders of buy-side entities may access passive sell-side liquidity orders through aggressive liquidity orders. In some embodiments, if a buy-side entity provides orders in a liquidity order that are contrary to his true intentions to the order pool, such types of orders may be prevented from trading by the buy-side entity. For example, if a buy-side entity bids up a small quantity and raises a liquidity order that represents a set amount of price increment behind the best CLOB bid, it may not be able to hit / sell against a 100m liquidity buy order thereafter.

[0016] In some embodiments, the market may determine when to submit an aggressive liquidity supply order to match a tradable passive liquidity supply order. The market may use various factors in making such a determination. An aggressive liquidity supply order may be submitted when the full quantity is traded at the best price in the order book by a trader of an aggressive liquidity supply order type. The remaining quantity of the aggressive liquidity supply order (from a buy-side trader or a trader configured to use it) may be made tradable in one or more passive liquidity supply orders (from a sell-side trader or a trader configured to use it) behind the best price.

[0017] In some embodiments, orders at the first best price in an order book that has passive liquidity supply orders (e.g., from the same orderer) matching behind the best price may be eligible for execution in preference to aggressive liquidity supply orders at the price level of the passive liquidity order supply due to the matching passive liquidity supply order. Any remaining quantity after such priority execution may be distributed among other orders. The technical effect of this adjustable matching priority is to encourage sell-side traders to place CLOB orders at the best price, which often closes bid / offer spreads on the CLOB at the book price level.

[0018] In some embodiments, if an order at the best price exists, it may be subject to matching of passive liquidity provision orders behind the best price. In some embodiments, matching of liquidity provision orders with corresponding best priced orders behind the best price may occur before matching with orders at the best price.

[0019] In some embodiments, aggressive buy-side investors may assign a "promo code" or priority status to a market maker. If that market maker has a passive liquidity supply order, that order may be given priority in quantity distribution. This may be the case if the market maker does not have the best order book price. In some embodiments, a market maker does not need to provide a passive order to engage with aggressive investors at the passive liquidity supply order price level. A market maker may be identified by a promo code used with an aggressive liquidity supply order, which may result in that passive liquidity supply order being traded in whole or in part. In some embodiments, a market maker may be identified by a promo code used with an aggressive liquidity supply order, and may be invited via electronic message to receive a match and submit a counter offer on a priority basis, even if the market maker does not have a matching passive liquidity supply order. In some embodiments, a promo code may identify multiple market makers. Markets may be identified in order of decreasing priority or may be treated equally. For example, a promotional code identifying four market makers A, B, C, and D would first provide quantity to A, then B, ... In another implementation, quantities for A, B, C, and D may be determined pro rata or according to some other algorithm described herein or elsewhere.

[0020] In some embodiments, the quantity may be divided according to some ranking factor. If a market maker is ranked high enough, at some point it may receive preferential matching for some or all of the aggressive liquidity providing orders. In other embodiments, the quantity may be divided evenly, pro-rate, and / or according to other priorities such as time and / or quantity, etc.

[0021] In some embodiments, the quantity may be distributed according to the percentage of the quantity traded at the book price of the best order. In some embodiments, the percentage may be divided by a ranking factor calculated daily, weekly, monthly, or yearly from market participation. Other methods of determining the factor, if used at all, may also be used. In some implementations, the top-ranked market makers may be prioritized over other market makers. In some implementations, the quantity may be distributed among the market makers according to the determined factor.

[0022] In some embodiments, if there is still remaining quantity after such algorithmic quantity allocation, that quantity may be matched with passive liquidity providing orders that do not provide a best matching order in the order book. Such matching may, in some embodiments, be done on a pro rata basis. Such matching, in some embodiments, may be done with preference given to participants providing better order book prices.

[0023] In some embodiments, a promotion code or priority status may be available through the GUI and / or API of FIX. Such a promotion code may indicate that the market will prioritize a particular market maker's passive liquidity supply orders even if the standard quantity allocation algorithm does not match that market maker.

[0024] In some embodiments, the promo code may be the default or may be blank and an algorithm described elsewhere may be used. In some embodiments, a trader or systems specialist may change the default so that the default is not blank but some other promo code. In some embodiments, a trader may use a GUI to change the default to some other promo code. If the market maker identified by the promo code has a passive liquidity supply order pending, the market maker will receive the quantity as described elsewhere.

[0025] In some embodiments, the system may determine whether to use all of the liquidity-supply orders to fill an order. For example, the system may determine that there is sufficient liquidity for orders outside of the liquidity-supply orders so that the aggressive investor's order may be filled at a better price than the liquidity-supply orders. In such a situation, the aggressive investor's order may be filled at a price that is desirable to the aggressive investor without using the liquidity-supply orders. This situation may occur, for example, when there is a large amount of liquidity at the best bid or offer.

[0026] In some embodiments, trade confirmations may be aggregated to reduce ticket size. For example, when using an aggressive liquidity supply order, instead of using multiple tickets at different price levels, an average trade may be made once at a price that is just a little better (to the aggressive liquidity supply order user) than the price level of the liquidity supply.

[0027] In some embodiments, elements of trading activity may remain anonymous and / or undisclosed. Such anonymity and / or undisclosed status may continue for a limited time. For example, in some embodiments, the quantity of liquidity providing transactions may not be immediately disclosed, but may be added to the total quantity traded at the end of the trading day. In some embodiments, liquidity providing transactions may be excluded from end of day high and low calculations. In some embodiments, liquidity providing transactions may be labeled for post-trade STP messages and trading or regulatory reporting purposes.

[0028] In some embodiments, a random daily client identification number may be attributed to all buy-side entities. This number may be added to post-trade STP messages for sell-side market makers. Sell-side market makers may use such information to request that fraudulent buy-side entities be removed from the enabled pool. Fraud may alert market production support teams to investigate. Alerts may also be issued if other suspicious events of market data manipulation occur prior to the liquidity supply order being hit.

[0029] In some embodiments, the market may adjust liquidity-supply orders as the best bid / offer changes. Such orders may adjust collectively as the market moves. In some embodiments, a single bid or offer may move the best price in the market, causing many liquidity-supply orders to adjust in response. In some embodiments, the market and / or orders may include quantity thresholds and / or fractional price increments that must be achieved before the liquidity-supply orders are adjusted.

[0030] It should be appreciated that while examples are discussed of liquidity provision orders that do not provide matching orders at the best price used to provide quantity, other implementations may not have access to such orders.

[0031] In some embodiments, the submitted liquidity provision order quantity may be governed by a bilateral permission matrix to allow market makers to set preferred counterparties.

[0032] Some embodiments of the marketplace may interact with an order management system (OMS) such as Fidessa or Aladdin (as commonly used in the marketplace). The GUI of such a system may tag the quantity of liquidity supply orders to order the order book differently. Thus, orders may be differentiated between regular CLOB quantities and quantities of liquidity supply orders that are only achieved by trading the best CLOB prices at approximately the same time.

[0033] Figure 3 shows, in the first row, an example interface (as seen by a buy-side user) where an order is placed at the best price in the order book and a liquidity supply order is placed at a less desirable price (to the user). The quantity available to trade at the liquidity supply price may, in some embodiments, be significantly higher than the order book price. This example interface shows the following example: (i) Element 301 is a promotion code as described above. A user can input promotion code information into the element of the interface to affect order confirmation. (ii) Elements 303 and 305 show the best order book (CLOB prices, BUY 99.9700, SELL 99.9760) on the top row. The interface may adjust as the CLOB changes. The interface displays an "x" to cancel the user's order through the interface because the user has a pending offer at the best CLOB price. (iii) Element 307 indicates the amount of passive liquidity buy orders available in the second row. (iv) Unavailability of a passive liquidity supply order (due to the presence of a buy-side trader CLOB offer, shown at 99.9760) is indicated in element 309 at 99.9765625. This may indicate to the user that the order is unavailable by brightening the interface element, coloring the interface element, and / or displaying in any desired manner. As orders are entered or the CLOB is changed, the availability of the order may change and the interface may adjust to indicate the change. (v) Element 311 is an active liquidity supply sell order at a price of 99.9690 in quantity 242 ready to be sent to the system for matching. A user can click on the interface on the price display (99.9690) to place an order at that price. A user may enter as the quantity shown on the interface, e.g., 242, and trade at that quantity. (vi) Element 309 is a price compression where a passive liquidity supply offer order placed at 99.9770 is instead compressed to the decimal equivalent price of one-quarter of the most recent 1 / 32 (99+31 and one-quarter x 1 / 32) (99.9765625).

[0034] Another example of an interface that may be used in some embodiments is shown in FIG.

[0035] This interface has many similarities to the previous interface. It can be used to display liquidity information and / or place orders. This interface does not include a promo code portion (although in some cases a promo code may be provided). Additionally, in this example, price levels are shown as different from the razor edge and best bid / best offer prices. For example, if you are buying an item with a best bid of 99.9700, as shown in 401, there is a quantity of 250 pending at 99.9690, a quantity of 500 pending at 99.9680, and a quantity of 1050 pending at 99.9670. In this interface, these orders would be shown as 250 at -10 from the best bid, 500 at -20 from the best bid, and 1050 at -30 from the best bid. These orders may rise in the actual price as the best bid moves, but may also remain at a relative price distance. Thus, by showing the delta and the best bid, we are showing information from which the actual price can be derived. Similarly, offerers are shown +10, +20, +30, etc. In this example, price compression shown in the interface is not shown. In some cases, price compression may not occur. In some cases, price compression may occur even if not shown in the interface. In other embodiments, price compression may occur and be shown in the interface. For example, instead of showing +10, which corresponds to a price of 99.9770, the interface may show +5.625, which corresponds to a price of 99.9765625.

[0036] In some embodiments, compression may be optional and / or variable. For example, rather than compressing to a set increment (e.g., 1 / 32), compression may move the liquidity supply order price in a more favorable direction than a 1 / 32 increment. The degree to which the price is more favorable may vary. As noted above, the increment may be 99.9765625, and an order at 99.9770 may compress to the increment in some embodiments. In other embodiments, the order may compress beyond the increment, for example, to 99.9766. The amount of compression is configurable. Whether compression is applied is also configurable. Such configurability may be based on a participant level, order level, and / or instrument level. For example, a sell-side participant may not use compression for one security, but may compress at the increment level for another security, and may compress better than the increment level for yet another security (e.g., submit compression information to the market). In some embodiments, participants may decide how large the compression increments will be (eg, by submitting compression information to the market).

[0037] In some embodiments, parties (e.g., sell-side participants placing passive liquidity provisioning orders, buy-side participants placing active orders) may determine which counterparties they wish to trade with. This may be a market requirement to allow trading on the market. For example, participants may be required to submit at least three counterparties with which they wish to trade. The market may keep valid trading party information private and secure. For example, the market may store the information in an encrypted matrix that matches each party with an approved counterparty. The matrix of approved counterparties may be accessed to determine which orders each party may have access to. In some implementations, such approval may apply to all transactions. In other implementations, such approval may apply to liquidity provisioning transactions but not to CLOB transactions. Approval may occur at the entity level, order level, security level, etc.

[0038] In some embodiments, the user interface may present liquidity provision order information to the party. To determine the information to be presented through the user interface, the market may access an approved counterparty matrix to determine which counterparties to the party have bilateral approval. For each counterparty for which the matrix indicates bilateral approval, information regarding the liquidity provision order may be determined and used to populate the interface. Thus, the party may be shown information regarding liquidity provision orders for counterparties for which they have bilateral approval.

[0039] In some embodiments, buy-side participants may be given the option to request liquidity orders from specific sell-side participants. For example, a buy-side participant may want to see liquidity orders from JP Morgan. The market may determine such orders and present them to the buy-side participant (e.g., if the parties are bilaterally authorized). This feature may remove an element of anonymity for sell-side participants. However, this feature may allow buy-side participants to more easily trade with participants with whom they have good relationships. Other embodiments may not include features to protect anonymity.

[0040] In some embodiments, sell-side participants may place passive liquidity provisioning orders, but may not view orders from other participants. In some embodiments, sell-side participants may enter CLOB orders and passive liquidity provisioning orders, but may not enter aggressive liquidity provisioning orders. In some embodiments, buy-side participants may enter CLOB orders and aggressive liquidity provisioning orders, but may not enter passive liquidity provisioning orders.

[0041] It should be understood that the examples provided herein are not limiting. Other embodiments may include additional, fewer, or different elements. The embodiments may be combined with each other in any arrangement. Some examples are used for FX trading, treasury trading, secured bonds, any OTC trading, and / or any other desired trading.

[0042] Second embodiment Some embodiments provide a platform for trading financial securities, such as secured notes and the like. The platform may allow any number of sell-side participants to enter market-making orders that follow the best bid or best offer price of the financial security. The sell-side market-making orders may be available to sell-side approved buy-side participants. The platform may allocate counter-offer quantities in the market-making orders based on one or more factors discussed herein. The platform may adjust the market-making orders in response to market movements. The platform may provide market-making orders available to buy-side participants through an interface identifiable to the participants. The platform may fractionalize sales and provide price compression protection when the price approaches fractional values ​​available through the market and / or other venues.

[0043] 1 illustrates an example of a platform that may be used in some embodiments. As shown, the platform may include a market 101, a first buy-side participant 103, a second buy-side participant 105, a first sell-side participant 107, and a second sell-side participant 109.

[0044] The marketplace 101 may include a computing device configured to enable trading of financial securities. The marketplace may accept orders to buy and sell one or more financial securities. The computing device may manage, track, match, and settle the orders. The computing device may include a matching engine configured for high speed, low latency matching of orders.

[0045] Buy-side participants 103 and 105 may include, for example, hedge funds or other participants that make up the buy-side of a market. Buy-side participants may engage in buying and selling financial securities through the market. Buy-side participants may include computing devices configured to enable transactions through the market. Such computing devices may include order management systems configured to reliably track trading intent for buy-side entities.

[0046] Sell-side participants 107 and 109 may include, for example, high frequency trading entities or other participants that make up the sell-side of the market. Sell-side participants may engage in buying and selling financial securities through the market. Sell-side participants may include computing devices configured to facilitate transactions through the market.

[0047] The marketplace may provide an API through which buy-side and sell-side participants may communicate orders. For example, orders may be placed into the marketplace using FIX messaging over a communications network such as the Internet. The marketplace may receive information through the API and interpret the information as orders.

[0048] A market may allow sell-side participants to act as market makers for financial securities. Sell-side participants may act as market makers by placing market-making orders in the market. In some implementations, market-making orders may be one-sided (e.g., sell orders or buy orders). In other implementations, market-making orders may be two-sided (sell orders and buy orders may be used).

[0049] For example, a sell-side participant 107 may place a market-making buy order on a financial security (e.g., a mortgage bond) using the market's API and FIX message format. The market may receive the order and add the sell-side participant as a buy-side liquidity provider for the financial security. The market-making buy order may have a quantity associated with it. This quantity may also have to match the market's minimum order quantity, which may be higher than a regular order book order (e.g., 200,000,000 compared to 1,000,000).

[0050] Similarly, a second sell-side participant 109 may place a second market making buy order into the market for the same financial security using the API and FIX messages. The market may receive the second order and add the second sell-side participant as a buy-side liquidity provider for the financial security.

[0051] Thus, multiple sell-side participants may make markets on the same side of a single financial instrument, and all sell-side participants may act as market makers on a single order side of a single financial instrument.

[0052] The market maker order price may be governed by the market. The price may track to the best bid and / or best offer pending in the market order book. For example, if the best bid is currently 99.95, then the market making buy orders (such as those received in the example from the first and second sell-side participants) may be tracked at some level relative to 99.95. In some implementations, that level may be two ticks below the highest market price (i.e., the floor price adjustment). For example, if the floor price adjustment in the market is 0.05, then in this example the market making buy orders for each of the sell-side participants would be set at 99.85.

[0053] It will be understood that the fractional pricing example of 2 ticks and the number of ticks are all provided as non-limiting examples only. 2 ticks may provide a level of price protection deemed appropriate by the market maker in this market example. For securities with more or less liquidity and / or volatility, the level of protection may be increased or decreased.

[0054] As the best bid or offer in the order book moves, the market maker's bids and offers may adjust with the market to maintain a tracked relationship. For example, if the best bid in this example changes based on a new bid price received for 100.00, the price of the market maker's buy order will adjust accordingly to 99.90.

[0055] In some embodiments, markets may deviate from standard tracking of market maker orders to best bids or offers under certain circumstances. For example, markets may operate with a fractional pricing model while other markets may operate with a fractional pricing model (e.g., 1 / 4 of 1 / 32). In fractional pricing markets, if price adjustments to maintain tracking are inconsistent with the price in the fractional pricing model, the market may instead price fractionally. This may provide a level of price compression protection to market makers. For example, if a market has a best offer set at 99.9760 with a tick of 0.0005, then typically market making offers may be set at 99.9770. However, if a fractional price boundary exists at 99.9765625 when compression protection is applied, then the price may be set to the boundary of 99.9765625. This number may be rounded or truncated to the 99.9765 level in some implementations.

[0056] In some embodiments, compression may be configurable by the market maker. The market maker may issue a command to the market to not apply compression to a type of security for all orders, specific orders, etc. The market may act accordingly. The market maker may issue a command to the security type, all orders, specific orders, etc. to use a standard incremental level of compression (e.g., compress to a boundary) for a type of security, all orders, specific orders, etc. The market may act accordingly. The market maker may issue a command to the security type, all orders, specific orders, etc. to use a better than incremental level of compression (e.g., compress to better than a boundary level). The market may act accordingly. The market maker may submit information (e.g., by percentage, reference point, price, etc.) to identify how much better than a boundary a better incremental level of compression must be. The market may act accordingly. The market maker may change any such compression attribute. In some embodiments, a market maker may use no compression for one instrument, incremental level compression for other instruments, and better than incremental level compression for still other instruments in any desired combination.

[0057] In some embodiments, sell-side market maker orders may be open to the entire market. In other implementations, market maker orders may be open only to buy-side participants. In still other embodiments, market maker orders may be limited to buy-side participants approved to trade by the sell-side participants that make up the market. Making a market involves risks of gaming and information leakage. As such, participants who engage in this activity may need to protect their anonymity and information. By limiting those entities that can trade with market making orders, the market may provide sell-side market makers with a level of security that encourages market making and discourages market gaming.

[0058] A sell-side participant may identify in the market a list of buy-side entities that are approvers for the market-making order. The approved list may vary from order to order and / or from sell-side participant to sell-side participant. The market may receive the list prior to, contemporaneously with, and / or after the order. The market may make the order available only to approved buy-side entities. For example, a first sell-side participant may identify that only the first buy-side participant can trade in the buy market-making order. A second sell-side participant may identify that both the first and second buy-side participants should be able to trade in the second buy market-making order. The market may take action to ensure that these intentions are carried out. For example, in the market, this may be by preventing the second market-making participant from being able to see, access, or trade the first buy market-making order from the first sell-side participant.

[0059] The sell-side participant may adjust the approved buy-side participants after the order is listed by adding or removing participants. The buy-side participant may be assigned a random number ID each day. That ID may be included in activity reports such as transactions with the sell-side participant for that day. This allows the sell-side participant to track activity without revealing its actual identity. If the sell-side participant believes that the buy-side participant is engaging in suspicious activity, the sell-side participant may notify the market of the random ID number. In this way, the sell-side participant may remove the buy-side participant from the approved list without enjoying the identity of the buy-side participant.

[0060] In some embodiments, a buy-side participant may identify a list of approved sell-side entities to the market. The approved list may vary from order to order and / or from buy-side participant to buy-side participant. The market may receive the list prior to, contemporaneously with, and / or after the order. The market may place an order to a buy-side participant with bilateral approval (e.g., approval from both the buy-side participant and the sell-side participant).

[0061] The market may store buy-side and sell-side authorization information. Such information may be stored in a bilateral counterparty authorization matrix. Each cell of the matrix may store the bilateral authorization status for a pair of counterparties. For example, rows of a two-dimensional matrix may indicate buy-side participants and columns may indicate sell-side participants. The cell data structure may include an indication of whether the pair of sell-side and buy-side participants in that cell have been mutually authorized to transact. Bilateral authorization for a buy-side participant may be determined by scanning across the rows of the buy-side participant matrix to locate each cell that indicates authorization for both sides. Upon obtaining an authorization list from the sell-side participant, an indicator may be set in each appropriate cell to identify that the sell-side participant has authorized the buy-side participant. In response to receiving an authorization list from the buy-side participant, an indicator may be set in each appropriate cell to identify that the buy-side participant has authorized the sell-side participant. If both such indicators are set in the cell, bilateral authorization occurs for the buy-side and sell-side pair.

[0062] Such a matrix may be accessed to determine which orders are accessible to each party. For example, such a matrix may be accessed to determine which orders to display to participants. In some implementations, such authorization may apply to all transactions. In other implementations, such authorization may apply to liquidity provision transactions but not to CLOB transactions.

[0063] Matched orders may be distributed among approved sell-side participants according to market judgment. In some embodiments, a market making order may be given matching priority if the sell-side participant for that order has an order book and an order pending at a corresponding best bid or offer. For example, if a first sell-side participant has an order pending to buy in the market at the best bid price but a second sell-side participant does not, the first sell-side participant may be given priority over the second sell-side participant.

[0064] In such an example, a first sell-side participant may have an order for 1,000,000 units at the best bid and a market making order for 500,000,000 units two ticks below the best bid. A second sell-side participant may have an order for 1,000,000 units one tick below the best bid and a market making order for 800,000,000 units two ticks below the best bid. When a first buy-side participant enters a “firm or cancel” offer to sell for 600,000,000 units into the market, the order will first match against the best bid of 1,000,000 from the first sell-side participant. This leaves a quantity of 599,000,000 remaining in the offer. The market may match the market making order with the next order due to market priority. The first sell-side participant is given priority based on having the best bid price in the order book. Thus, the offer for 500,000,000 may then be matched with the first sell-side participant's market making order. The remaining 99,000,000 in the offer may then be matched with the second sell-side participant's market making order for 800,000,000.

[0065] In response, the second sell-side participant's order book order of 1,000,000 one tick below the first sell-side participant's original order book order becomes the new best bid. In response, the remaining 701,000,000 market making orders from the second sell-side participant may either have their prices adjusted back one tick to remain two ticks below the new best bid, or may be updated back to 800,000,000 by the second sell-side participant. This is done automatically as market conditions change.

[0066] In the above example, the best bid order for 1,000,000 units from the first sell-side participant is matched and confirmed first. However, in other embodiments, this order may not be matched first. Instead, matching may begin with market making orders. For example, an order for 500,000,000 will match all 500,000,000 market making orders from the first sell-side participant and will not match any best bids. This does not have much impact on price since market making orders may be substantially larger than the best bids or offers. This adjustment may improve the speed of trading and reduce labor expenditure by reducing instructions required for processing and messages used for reporting. If additional order quantity exists after matching with a market making order, an embodiment may match with the best bid or move to another market making order. Using other market making orders first allows for more efficient energy operations.

[0067] In some embodiments, when multiple market making sell side participants are at the best bid or offer, or are neither at the best bid nor offer, quantity may be allocated in various ways, such as using a pro-rate method, giving priority to active participants, giving priority by time order, or giving priority by price of order book orders.

[0068] A buy-side participant may have a preference for trading with one or more sell-side participants. For example, protection against information leakage may be very important to the buy-side participant. As another example, research may be very important to the buy-side participant. Some sell-side participants may have a preference relationship with a buy-side participant due to information security and / or research provision practices. A buy-side participant may specify a preference indicator for a market where it may prioritize traditional matching decisions.

[0069] For example, the first buy-side participant may identify in the above example that it has priority over the second sell-side participant. Instead of matching the first sell-side participant's market making order, the second sell-side participant may match since the market respects priority. In that case, the example may leave the second sell-side participant's order book order as the new best bid and market make the entire 500,000,000 of the first sell-side participant and the remaining 201,000,000 of the second participant's market making order two ticks below any new best bid.

[0070] Buy-side participants may be provided with an interface that displays information regarding market making orders available for trade. Such an interface may indicate the quantity of market making orders available for trade by a particular buy-side participant while maintaining the anonymity of market making participants. Such an interface may display the price of the orders (e.g., as the actual price and / or the difference from the best bid or offer).

[0071] To populate such an interface with useful information, the market may access an authorized counterparty matrix to determine which counterparties have bilateral authorization for the buy-side participant that exhibits the interface. For each counterparty for which the matrix exhibits bilateral authorization, information regarding market making orders from that participant may be determined and used to populate the interface. Thus, a buy-side participant may show information regarding market making orders to counterparties with which it has bilateral authorization, but not other orders with which the buy-side participant cannot trade.

[0072] In some embodiments, buy-side participants may be given the option to request that the market include information about market making orders from certain sell-side participants in the interface. For example, a buy-side participant may want to see market making orders from JP Morgan. The market may determine and present such orders to the buy-side participant (e.g., if the parties are bilaterally authorized). This feature may remove an element of anonymity for sell-side participants; however, this feature may allow buy-side participants to more easily trade with participants with whom they have a good relationship. Other embodiments may not include the feature to protect anonymity.

[0073] In some embodiments, the market may determine whether to use market making orders or standard order book orders to fill the order. Such a determination may be made based on the best interest of the aggressive investor. For example, if there are pending orders outside of market making orders that would provide a better price to the aggressive investor, they may also match against standard orders, such as when there is sufficient liquidity at the best bid to fill the aggressive investor's order. If the standard orders do not result in a fill, the market making order system may be used instead.

[0074] In some embodiments, sell-side participants can place passive market making orders but cannot see orders from other participants. In some embodiments, sell-side participants may enter CLOB orders and passive market making orders but cannot enter aggressive orders against passive market making orders. In some embodiments, buy-side participants can enter CLOB orders and may enter aggressive orders against passive market making orders but not passive market making orders.

[0075] Some embodiments may include executing a method. Such a method may be performed by a platform to enable trading using market making orders from sell-side participants. The method may be performed by a computing device based on execution of one or more instructions stored on a non-transitory medium. Figure 2 illustrates an example method that may be used in some embodiments.

[0076] As shown in the figure, some embodiments may include receiving a respective list of authorized buy-side participants for each of a plurality of market making orders placed by a respective sell-side participant in a market for a financial security. As shown in the figure, some embodiments may include receiving a respective market making order on the same side of a trade for the financial security from each of a plurality of sell-side participants. As shown in the figure, some embodiments may include following all received market making orders and for prices that are multiple ticks below the best price for that side of the trade in the order book. As shown in the figure, some embodiments may include presenting market information to a buy-side participant where the buy-side participant identifies the authorized market making orders. As shown in the figure, some embodiments may include receiving a counter offer from a buy-side participant authorized to trade a subset of the plurality of market making orders, identifying a sell-side participant with a preferred right. As shown in the figure, some embodiments may include distributing counter offers first to the initial order at the best bid or offer, then to market making orders from sell-side participants identified as having the buy-side participant admitted to trade, then to market making orders for which the buy-side participant is admitted to trade and the sell-side orderer has provided a matching order for the initial order, and then to market making orders for which the buy-side participant is admitted to trade and the sell-side orderer has not provided a matching order for the initial order. As shown in the figure, some embodiments may include determining a new best bid and offer upon distributing. As shown in the figure, some embodiments may include adjusting the remaining market making offers to keep up upon determining the new best bid or offer. It will be appreciated that this method is merely exemplary. Other examples may include other methods involving different orders and / or different actions.

[0077] Although various examples and features are set forth throughout, it should be understood that such examples are not meant to be limiting. Method implementations may include any desired combination of elements in any order set forth in any of the various examples described herein. Other embodiments may include additional or different elements as desired.

[0078] For example, in some implementations, prices may run in 1 / 16th of a 1 / 32nd increment. Such embodiments may provide a high level of price granularity in known systems. As another example, some embodiments may bypass compression protections beyond increment walls to allow traders to perform such analysis.

[0079] As another example, rather than following the razor edge or best CLOB price for liquidity provisioning orders, some embodiments may include separate books, i.e., a CLOB and a block book. The CLOB may operate for small quantity orders (e.g., no quantity limit, 1,000,000 minimum, etc.). The block book may operate for larger quantity orders (e.g., 100,000,000, 500,000,000, 1,000,000,000, 2,000,000,000, etc.). The quantities of orders in such books may vary based on the financial security (e.g., the more liquid the security, the larger the minimum quantity may be). The electronic market may maintain a separate CLOB and block book for each financial security. In some embodiments, liquidity providers may enter orders of any quantity that can meet any minimum quantity in the CLOB. However, in general, smaller orders are possible, and in other embodiments, there may be a minimum quantity in the CLOB (e.g., equal to or less than the block book minimum). Larger orders that meet the larger minimum quantity may be placed in the block book. This block book embodiment may operate similarly to the liquidity provision orders described above, with the exception that the block book orders are not tied to or following CLOB orders. Price changes in the CLOB may not affect the price in the block book. Similarly, liquidity providers may not be required to place orders in the CLOB to participate in the block book in such embodiments. In some embodiments, order confirmation occurs through the book selected by the liquidity acquirer (e.g., if the acquirer hits the CLOB and the CLOB order is confirmed, if the acquirer hits a block book offering an order equal to or greater than the minimum quantity, the block book order is confirmed). Confirmation of orders may use priority mechanisms, such as promo codes, as described above. Some embodiments may give priority to larger liquidity providers, liquidity providers with CLOB orders at razor-edge prices, etc.In some embodiments, order confirmation may be by market determined bookkeeping (eg, matching order quantity minimums, as described below).

[0080] While an example of a single quantity minimum block book is shown, it will be understood that other embodiments may include any number of different quantity limits. For example, the block book may include multiple leveled ladders of pricing and minimum quantities. The quantity requirements and / or number of steps may be determined based on the characteristics of the financial security (e.g., liquidity). As an example, a 2-year treasury may have four separate entries in the block book: one entry for a minimum order of 100,000,000, one entry for a minimum order of 500,000,000, one entry for a minimum order of 1,000,000,000, and one entry for a minimum order of 2,000,000,000. Liquidity providers may place orders and the market may enter them into the appropriate entry in the block book that matches the order's quantity. The block book may track, match, and fill orders separately for each quantity entry. Liquidity acquirers who wish to fill orders that meet the minimum quantity threshold may place orders in the matching entry in the block book. Submitted orders may be finalized through the appropriate block book entry, including any orders pending within that entry, subject to a priority mechanism (eg, a promotional code).

[0081] In some embodiments, when an order from a liquidity acquirer reaches the electronic marketplace, it may decide whether to process the CLOB or the block book based on the quantity of the order. If the order meets the minimum for the block book, the order may be routed to the block book rather than the CLOB. The market may decide which entry in the block book to use to fill the order. Similarly, such a decision may be based on the quantity of the order. The market may use the entry with the largest minimum quantity requirement that the order meets to fill the order. For example, a block book of 500,000,000 may process an order of 600,000,000.

[0082] In some embodiments, if unmatched orders remain after confirming the aggressive investor's orders through the determined block book entries, their liquidity can be confirmed with other orders (e.g., another entry in the CLOB). For example, the next highest minimum block book entry may be used to continue confirming the unconfirmed portion. Once all price-matching entries have been exhausted, in some embodiments, the CLOB may also be used to confirm such remaining liquidity. In other embodiments, only a single entry in the block book may be used to confirm liquidity for orders that match that entry.

[0083] Some embodiments may protect liquidity providers in the block book from manipulation by liquidity acquirers. Liquidity providers who enter orders in higher entries of the block book may expect higher prices. Such higher prices represent a liquidity premium. Some embodiments may prevent liquidity acquirers from entering multiple orders at the trader side for a financial security during a period of time. The length of the period may be set based on the liquidity of the security. Such a period may range, for example, from milliseconds to one second, five minutes, or ten minutes. This order prevention may encourage liquidity acquirers to obtain desired liquidity using orders of appropriate size. If an acquirer places a full size order, the acquirer's preference may be to place a single order at the appropriate price. If an acquirer attempts to split an order into smaller orders to take advantage of cheaper block book entries, the acquirer may prevent such repeat orders. The electronic market may track the orders placed, receive new orders, and compare them to tracked orders. If a new order for a security is placed by the same orderer during the prevention period on the same side as a previous block book order, the market may notify the orderer that the order cannot be placed. After that period, the order on that side may be placed again by the acquirer.

[0084] The embodiments may improve technical functions, solve technical problems, provide technical solutions, and / or be based on computational techniques.

[0085] Traditional trading without the benefit of modern computing solutions cannot provide the speed and analysis of multiple data sources that the various embodiments provide. Algorithms and matching engines operate at incredibly high speeds. Humans in traditional trading environments could not manually process the vast amounts of data required to interact with fast-moving modern electronic markets such as those described herein.

[0086] Automatic application of market making orders by the platform to the best bid or offer price may provide a technical solution to a technical problem based on electronic trading technology. High speeds of market activity mean that network latency and processing times can become significant issues. When a market moves, the time to report that move, process that move, and respond to that move can result in participants losing significant amounts of capital. This is true even if only a few seconds pass.

[0087] Traditionally, markets rely on orderers to monitor market movements and manipulate by adjusting their orders to keep their orders tracked at a price distance from other orders. However, due to high speed market movements and network and processing delays, market movements can cause delays as orderers adjust their orders. By setting prices locally on the platform, delays are removed and orderers are protected from risk. Traditionally, orderers are exposed to the risk of race conditions after a market move. For example, the market may move and an orderer may submit an adjustment to his or her order, moving the price accordingly. However, another trader may try to beat the orderer's adjustment. An orderer may want to change the price of an order, but another trader may enter a counter offer before the orderer's wishes reach the traditional market. Some embodiments of the platform described herein may protect orderers by having the price track market movements locally, substantially eliminating this race condition.

[0088] Additionally, some embodiments may reduce bandwidth usage and / or processing operations. For example, in traditional markets where orderers automatically adjust their orders, orderers may be required to submit many order price adjustments. Each such price adjustment uses bandwidth and requires processing on both the market that received the adjustment and the orderer that made the adjustment. Some embodiments of the platform described herein may reduce bandwidth usage by not submitting such adjustments, and also require less processing by not sending or receiving orders for adjustments. This may result in both a more energy efficient and a more bandwidth efficient market.

[0089] Various embodiments provide a level of anonymity and information security that would not typically be found in a public market. In the open-out markets used prior to electronic trading, trading intent and identity became public knowledge. In typical electronic trading systems, orders are publicly disclosed to the market, and reports of trading activity are similarly publicly reported to the market. Various embodiments herein address such issues of information distribution and lack of identification, and participants may participate in the market with confidence.

[0090] Furthermore, order access in traditional non-electronic and electronic markets is open to all. Traditional markets do not allow transactions to be conducted according to a complex web of bilateral authorizations and priorities. Various embodiments described herein may create a mapping between market participants to match counterparty priorities, which would not be possible in traditional markets.

[0091] The following sections provide a guide for interpreting this application.

[0092] term The term "product" means a machine, manufacture, and / or composition of matter, unless expressly specified.

[0093] The term "process" means a procedure, algorithm, methodology, or the like, unless expressly specified otherwise.

[0094] Each process (whether expressed as a method, algorithm, or other term) inherently includes one or more steps, and thus any reference to a "step" or "steps" of a process, either in the description of the process alone or in the description of the "process" or similar terms, carries an inherent antecedent limitation. Thus, any reference in a claim to a "step" or "steps" of a process carries a sufficient antecedent limitation.

[0095] "Invention" and like terms refer to "one or more inventions disclosed in this application" unless expressly specified otherwise.

[0096] The terms "embodiment", the first or second occurrences of "embodiment", "one or more embodiments", "some embodiments", "particular embodiments", "one embodiment", "another embodiment", and the like, mean "one or more (but not all) embodiments of the invention", unless expressly specified otherwise.

[0097] The term "variants" of the present invention means embodiments of the present invention, unless expressly specified otherwise.

[0098] The term "representation" is used in a very broad sense: a "representation" of something should be understood to include anything that may be used to determine that thing.

[0099] A representation of an object may include an electronic message that identifies the object (e.g., identifying a widget by a serial number assigned to the widget, identifying a widget by one or more characteristics of the widget). A representation of an object may include information that can be used to compute and / or search for the object (e.g., information identifying a machine of which the widget is a part that can be used to determine the widget). A representation of an object may specify something associated with the object (e.g., characteristics of the object, the name of the object, names of things associated with the object). A representation of an object may not specify something associated with the object (e.g., the letter "a" may be a representation of a widget for a computer system configured to interpret the letter "a" to identify a widget). A representation of an object may include signs, symptoms, and / or tokens of the object. For example, the representation may include codes, references, examples, links, signals, and / or identifiers. A representation of an object may include information that represents, describes, and / or can be associated with the object.

[0100] Modifying the representation of an object may be a representation of the object (e.g., an encrypted representation of an object may be a representation of the object). A representation of an object may include the object itself, a copy of the object, and / or a portion of the object. A representation of an object may be meaningless to those not constructed to understand the representation (e.g., a person may not understand that the letter "a" refers to a widget, but a computer system can determine a widget from the letter "a" and so it does not matter that it represents a widget). It will be understood that the fact that a representation of an object can be used to determine something does not imply that the object, or any other object, is being determined. A representation of an object may also include representations of any number of objects, unless otherwise specified. A representation of an object may include representations of other objects (e.g., electronic messages representing many objects). (Representation may be used as a very broad term in claim language, e.g., receiving a representation of a financial security.)

[0101] "Represent" means (1) to express, designate, represent, or signify, as by a word, symbol, etc.; (2) to represent or designate by a term, character, sign, etc.; (3) to depict or represent or present a pictorial likeness; or (4) to serve as a sign or symbol.

[0102] The phrase "another embodiment" describing an embodiment does not imply that the referenced embodiment is mutually exclusive with other embodiments (e.g., embodiments described before the referenced embodiment), unless expressly specified otherwise. Similarly, the fact that two (or more) embodiments are referenced does not imply that those embodiments are mutually exclusive.

[0103] One embodiment of the invention may include, encompass, or contain multiple other embodiments of the invention. For example, a first embodiment including elements a, b, and c may encompass a second embodiment including elements a, b, c, and d, and a third embodiment including elements a, b, c, and e. Similarly, each of the first, second, and third embodiments may encompass a fourth embodiment including elements a, b, c, d, and e.

[0104] The terms "comprises" and "includes" and variations thereof mean "including, but not necessarily limited to," unless expressly specified. Thus, for example, the sentence "a machine includes a red widget and a blue widget" means that the machine includes a red widget and a blue widget, but may also include one or more other items.

[0105] The term "consisting of" and variations thereof mean "including" and "limited to," unless expressly specified. So, for example, the sentence "a machine consists of a red widget and a blue widget" means that the machine contains red widgets and blue widgets, but nothing else.

[0106] The term "comprise" and variations thereof, unless expressly specified, means "to make up its component or material parts." Thus, for example, the sentence "The red widget and the blue widget comprise a machine" means that the machine contains a red widget and a blue widget.

[0107] The term "consisting exclusively of" and variations thereof, unless expressly specified, means "to be the only constituent or made up exclusively of components that are the only parts of." Thus, for example, the sentence "Only red widgets and blue widgets comprise the machine" means that the machine consists of red widgets and blue widgets (i.e., nothing else).

[0108] The number of things means "one or more" unless expressly specified otherwise. Thus, for example, the phrase "widget" means one or more widgets unless expressly specified otherwise. Similarly, after a reference to the phrase "widget", a subsequent reference to the phrase "the widget" means "one or more widgets". Thus, a word's second or subsequent appearance shall also be understood to refer to a particular term having a basis for antecedent limitation. For example, if a paragraph refers to "a particular single feature" and then refers to "feature", the phrase "feature" shall be understood to mean to refer to said "particular single feature" (the term "single" in "particular single feature" shall be understood to mean "one" particular single feature, and not "one or more" particular single features).

[0109] The term "plurality" means "two or more" unless expressly specified otherwise.

[0110] The term "herein" means "in this application, including anything that may be incorporated by reference," unless expressly specified otherwise.

[0111] The phrase "at least one" when such phrase modifies a plurality of items (e.g., an enumerated list of items) means a combination of one or more of those items, unless expressly specified otherwise. For example, the phrase "at least one widget, car, and wheel" means any of: (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car, (v) a widget and a wheel, (vi) a car and a wheel, or (vii) a widget, a car, and a wheel. The phrase "at least one" when such phrase modifies a plurality of items does not mean "one of" the plurality of items. For example, the phrase "at least one of a widget, a car, and a wheel" does not mean "one widget, one car, and one wheel."

[0112] When a number such as "1", "2", etc. is used as a base number to indicate a quantity of something (e.g., 1 widget, 2 widgets), it means the quantity indicated by the number, but not at least the quantity indicated by the number. For example, the phrase "1 widget" does not mean "at least 1 widget," and thus the phrase "1 widget" does not cover, for example, 2 widgets.

[0113] The phrase "based on" does not mean "based only on," unless expressly specified. In other words, the phrase "based on" encompasses both "based only on" and "based at least on." The phrase "based at least on" is synonymous with the phrase "based at least in part on." For example, the sentence "element A is calculated based on element B and element C" encompasses an embodiment where element A is calculated as the product of B×C (i.e., A=B×C), an embodiment where A is calculated as the sum of B and C (i.e., A=B+C), an embodiment where A is calculated as the product of B×C×D, an embodiment where A is calculated as the sum of the square roots of B+C+D×E, and so forth.

[0114] The term "represents" and similar terms are not exclusive terms unless expressly specified. For example, the term "represents" does not mean "represents only" unless expressly specified. For example, the phrase "The data represents credit card numbers" encompasses both "The data represents only credit card numbers" and "The data represents credit card numbers and also represents something else."

[0115] The term "whereby" is used herein only before a clause or other group of words that expressly expressly results, objectives, or consequences of something that is preceded by the term "whereby." Thus, when the term "whereby" appears in a claim, any clause or other wording to which the term "whereby" is modified shall not impose further specific limitations on the claim or limit the meaning or scope of the claim.

[0116] The terms "for example," "such as," and similar terms mean "for example," and thus do not limit the term or phrase being described. For example, in the sentence "a computer transmits data (e.g., instructions, data structure) over the Internet," the term "for example" explains that "instructions" are an example of "data" that a computer may transmit over the Internet, and also explains that "data structure" is an example of "data" that a computer may transmit over the Internet. However, both "instructions" and "data structure" are merely examples of "data," and other things besides "instructions" and "data structure" may be "data."

[0117] The term "respective" and similar terms mean "individually." Thus, when two or more things have "respective" properties, each of them has its own unique property, and these properties may, but need not, differ from one another. For example, the phrase "two machines each have a respective function" means that a first of the two machines has a function, and a second of the two machines also has a function. The function of the first machine may, or may not, be the same as the function of the second machine.

[0118] The term "ie" and similar terms are meant to limit the term or phrase being described. For example, in the sentence "a computer sends data (i.e., instructions) over the Internet," the term "ie" explains that the "instructions" are the "data" that a computer sends over the Internet.

[0119] Numeric ranges include integers and non-integer numbers within the range unless explicitly stated otherwise. For example, the range "1 to 10" includes integers from 1 to 10 (e.g., 1, 2, 3, 4, ... 9, 10) and non-integer numbers (e.g., 1.0031415926, 1.1, 1.2, ... 1.9).

[0120] When two or more terms or phrases are synonymous (e.g., by expressly declaring that the terms or phrases are synonymous), an instance of such a term or phrase does not imply that another instance of such a term or phrase must have a different meaning. For example, the meaning of "including" in a description is the same as "including but not limited to," but when used in the phrase "including but not limited to," the term "including" has no other meaning than "including but not limited to."

[0121] II.Decision The term "determining" and its grammatical variations (e.g., determining a price, determining a value, determining which objects meet certain criteria) are used in a very broad sense. The term "determining" encompasses a wide range of actions, and thus "determining" may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, database or other data structure), displaying in an electronic format or digital representation, verifying, and the like. "Determining" may also include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. "Determining" may also include resolving, selecting, choosing, establishing, and the like.

[0122] The term "determining" does not imply certainty or absolute precision, and therefore "determining" may include estimation, extrapolation, prediction, estimation, averaging, and the like.

[0123] The term "determining" does not imply that mathematical operations must be performed, that a numerical method must be used, or that an algorithm must be used.

[0124] The term "determining" does not imply that any particular device must be used, for example, a computer does not necessarily need to perform the determination.

[0125] The term "determining" may include "calculating." The term "calculating" should be understood to include performing one or more calculations. Calculating may include operating, processing, and / or deriving. Calculating may be performed by a computing device. For example, calculating an entity may include applying an algorithm to data by a computer processor and generating an entity as an output of the processor.

[0126] The term "determining" may include "referencing." The term "referencing" should be understood to include, for example, making one or more references to an object. Referencing may include querying, accessing, selecting, choosing, reading, and / or searching. The act of referencing may be performed by a computing device. For example, referencing an object may include reading a memory location where the object is stored by a processor.

[0127] The term "determining" may include "receiving." For example, receiving an object may include capturing the object. In some embodiments, receiving may include an act performed to capture the object, such as manipulating a network interface through which the object is captured. In some embodiments, receiving may be performed without an act performed to capture the object, such as direct memory writing, hardwired circuitry, etc. Receiving an object may include receiving the object from a remote source from which the object may have been computed.

[0128] III. Sentence morphology If a limitation in claim 1 includes one of the features while also including more than one of the features (e.g., a limitation such as "at least one widget" includes one widget as well as more than one widget), and claim 2, when dependent on claim 1, uses a clear term to refer to that limitation (e.g., "the widget"), and this simple usage does not mean that claim 1 includes only one of its features, nor does it assert that claim 2 includes only one of its features (e.g., "the widget" can include both one widget and multiple widgets).

[0129] When ordinal numbers (e.g., "first," "second," "third," etc.) are used as adjectives before a term, the ordinal numbers (unless expressly specified otherwise) are intended to indicate a particular feature, such as to distinguish it from other features described by the same or similar term, and the ordinal numbers are not intended to have any other meaning or limiting effect, but are merely used as a convenient name. For example, a "first widget" may be so named merely to distinguish it from, e.g., a "second widget." Thus, the mere use of the ordinal numbers "first" and "second" before the term "widget" does not indicate any other relationship between the two widgets, nor similarly does it indicate any other characteristics of either or both widgets. For example, the mere use of the ordinal numbers "first" and "second" before the term "widget" does not (1) indicate that either widget appears before or after any other in order or position, (2) indicate that either widget occurs or acts before or after any other in time, or (3) indicate that either widget is ranked above or below any other in importance or quality. The mere use of ordinal numbers does not define numerical limits for the feature identified by the ordinal number. For example, the mere use of the ordinal numbers "first" and "second" before the term "widget" does not convey that there are exactly two widgets.

[0130] Where a single device, article, or other product is described herein, in alternative embodiments, multiple devices or articles (whether or not they cooperate) may be used in place of the single device or article described. Thus, functionality that is described as being possessed by a device may, in alternative embodiments, be possessed by multiple devices or articles (whether or not they cooperate).

[0131] Similarly, where multiple devices, articles, or other products are described herein (whether or not they operate in concert), in another embodiment, a single device or article may be used in place of the multiple devices or articles described. For example, multiple computer-based devices may be substituted with a single computer-based device. In some embodiments, such multiple computer-based devices may operate together to perform a step of a process common in a grid computing system. In some embodiments, such multiple computer-based devices may operate to provide additional functionality to one another, operating together to perform a step of a process, such as a process common in a cloud computing system. (Conversely, a single computer-based device may be replaced with multiple computer-based devices operating in concert with one another. For example, a single computing device may be replaced with a server and a workstation that communicate with one another via the Internet.) Thus, various functions described as being possessed by multiple devices or articles may alternatively be possessed by a single device or article.

[0132] The functionality and / or features of a single device described may, in other embodiments, be embodied instead in other ways in one or more other devices that are described but are not explicitly described as having such functionality or feature. Thus, other embodiments need not include the described device itself, but rather may include one or more other devices that have such functionality or feature in other embodiments.

[0133] IV. Disclosed Examples and Terminology Are Not Limiting Neither the Title (which appears at the beginning of page 1 of this application) nor the Abstract (which appears at the end of this application) shall be construed as limiting in any way the scope of the disclosed invention, but rather as being used to interpret the meaning of any claim or to limit the scope of any claim. The Abstract is included in this application because an Abstract is required under 37 C.FR § 1.72(b).

[0134] The section headings provided in this application are for convenience only and should not be construed as limiting the disclosure in any way.

[0135] Numerous embodiments are described in this application and are presented for illustrative purposes only. The described embodiments are not, and are not intended to be, limiting in any way. The disclosed invention is broadly applicable to many embodiments, as is readily apparent from the disclosure. Those skilled in the art will recognize that the disclosed invention can be implemented with various modifications and alterations, such as structural, logical, software, and electrical changes. Although particular features of the disclosed invention may be described with reference to one or more specific embodiments and / or drawings, it should be understood that, unless expressly specified, such features are not limited to application in the one or more specific embodiments or drawings in which they are described.

[0136] While one embodiment may be disclosed as including several features, other embodiments of the invention may include less than all such features. Thus, for example, the claims may include less than the entire collection of features in the disclosed embodiment, and such claims should not be interpreted as requiring more features than are expressly recited in the claims.

[0137] No method step or product element embodiment described in this application constitutes an invention described herein or is essential to or coextensive with the invention claimed herein, unless expressly stated (to the claims and the invention defined therein).

[0138] Any claim preamble reciting anything other than a statutory class shall be construed as reciting the purposes, benefits, and possible uses of the claimed invention, and such preamble shall not limit the claimed invention.

[0139] This disclosure is not a listing of all embodiments of the invention, nor is it a listing of features of the invention that must be present in all embodiments.

[0140] All disclosed embodiments are not necessarily covered by the claims (including all pending, amended, issued, and cancelled claims). Moreover, a disclosed embodiment may (but need not) be covered by any number of claims. Thus, if a claim (whether pending, amended, issued, or cancelled) is directed to a particular embodiment, this is not evidence that the other claims do not include that embodiment.

[0141] Devices described as communicating with each other need not communicate with each other continuously, unless explicitly specified. Conversely, such devices need only transmit to each other as needed, and may in fact refrain from exchanging data most of the time. For example, a machine that communicates with other machines over the Internet may not transmit data to the other machines for long periods of time (e.g., weeks at a time). Furthermore, devices that communicate with each other may communicate directly or indirectly through one or more intermediaries. Devices communicate with each other if they may communicate at least one-way with each other. For example, a first device communicates with a second device if the first device may transmit information to the second device. Similarly, a second device communicates with a first device if the second device may receive information from the first device.

[0142] A description of an embodiment with several components or features does not imply that all or any of such components or features are required. On the contrary, a variety of optional components have been described to illustrate the wide variety of possible embodiments of the invention. Unless otherwise specified, no component or feature is essential or required.

[0143] Although process steps, algorithms, and the like may be described or claimed in a particular sequential order, such processes may be configured to function in different orders. In other words, any sequence or order of steps that may be explicitly described or claimed does not necessarily indicate a requirement that the steps be performed in that order. Steps of processes described herein may be performed in any order possible. Furthermore, some steps may be performed simultaneously (e.g., because one step is described after the other) unless specifically described or implied as being performed non-concurrently. Furthermore, the illustration of a process by its depiction in a drawing does not imply the exclusion of other variations and modifications to the illustrated process, does not imply that the illustrated process or any of its steps are required for the invention, and does not imply that the illustrated process is preferred.

[0144] Although a process may be described as including multiple steps, this does not imply that all or any of the steps are preferred, unavailable, or required. Various other embodiments within the scope of the described inventions include other processes that omit some or all of the described steps. Unless otherwise specified, no step is essential or required.

[0145] Although a process may be described in isolation or without reference to other products or methods, in an embodiment a process may interact with other products or methods. For example, such interactions may include linking one business model to another. Such interactions may be provided to increase the flexibility or desirability of the process.

[0146] Although a product may include a number of components, aspects, qualities, features, and / or characteristics, this does not indicate that any or all of these are preferred, essential, or required. Various other embodiments within the scope of the invention(s) described include other products that omit some or all of the listed components.

[0147] An enumerated list of items (which may be numbered or unnumbered) does not imply that any or all of the items are mutually exclusive, unless expressly specified. Similarly, an enumerated list of items (which may be numbered or unnumbered) does not imply that any or all of the items are inclusive of any category, unless expressly specified. For example, the enumerated list "computers, laptops, and PDAs" does not imply that any or all of the three items in the list are mutually exclusive, nor does it imply that any or all of the three items in the list are inclusive of any category.

[0148] An enumerated listing of items (which may or may not be numbered) does not imply that any or all of the items are equivalent to each other or readily substituted for each other.

[0149] All embodiments are illustrative and do not imply that the invention or any embodiment has been made or performed, in any case.

[0150] V. Arithmetic It will be readily apparent to those skilled in the art that the various processes described herein may be implemented, for example, by appropriately programmed general-purpose computers, special-purpose computers, and computing devices. Typically, a processor (e.g., one or more microprocessors, one or more microcontrollers, one or more digital signal processors) receives instructions (e.g., from a memory or similar device) and executes those instructions to perform one or more processes defined by those instructions. The instructions may be embodied, for example, in one or more computer programs, one or more scripts.

[0151] The term "compute" means to make a decision using a processor according to a software algorithm.

[0152] "Processor" means one or more microprocessors, central processing units (CPUs), arithmetic units, microcontrollers, digital signal processors, graphics processing units (GPUs) or similar devices, or any combination of these, regardless of architecture (e.g., chip-level multiprocessing or multicore, RISC, CISC, microprocessors without interlocked pipeline stages, pipelined, simultaneous multithreading, integrated graphics processing unit, GPGPU).

[0153] "Computing Device" means one or more microprocessors, central processing units (CPUs), arithmetic devices, microcontrollers, digital signal processors, graphics cards, mobile gaming devices, or similar devices, or any combination of these, regardless of architecture (e.g., chip-level multiprocessing or multicore, RISC, CISC, microprocessors without interlocked pipeline stages, pipelined, simultaneous multithreading).

[0154] Thus, a description of a process is also a description of an apparatus for performing the process. An apparatus for performing a process may include, for example, a processor and input and output devices suitable for performing the process. For example, a description of a process is a description of an apparatus that includes a processor and a memory that stores a program that includes instructions that, when executed by the processor, cause the processor to perform the method.

[0155] An apparatus for executing a process may include multiple computing devices that cooperate to execute the process. Some of the computing devices may cooperate to execute each step of the process, some of which may act on separate steps of the process, while other computing devices may provide underlying services that facilitate execution of the process. Such computing devices may operate under the direction of a centralized authority. In another embodiment, such computing devices may operate without the direction of a centralized authority. Some examples of apparatuses that operate in some or all of these ways may include grid computing systems, cloud computing systems, peer-to-peer computing systems, computing systems configured to provide software as a service, and the like. For example, an apparatus may include a computing system that performs most of its processing load on a remote server, but outputs display information to and receives user input information from a local user computer, such as, for example, a computing system running VMware software.

[0156] Additionally, programs implementing such methods (as well as other types of data) may be stored and transmitted in a variety of ways using a variety of media (e.g., computer-readable media). In some embodiments, hardwired circuitry or custom hardware may be used in place of or in combination with some or all of the software instructions that may implement the processes of various embodiments. Thus, in place of software alone, various combinations of hardware and software may be used.

[0157] The term "computer-readable medium" refers to any non-transitory medium, combination of the same or different media, that participates in providing data (e.g., instructions, data structures) that can be read by a computer, a processor, or a similar device. Such media can take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes the main memory. Transmission media include coaxial cables, copper wire, and optical fiber, including the wiring that comprises the system bus coupled to the processor. Transmission media may include or transmit acoustic waves, light waves, and electromagnetic radiation, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, other magnetic media, CD-ROM, DVD, any other optical media, punch cards, paper tape, any other physical media with a pattern of holes, RAM, PROM, EPROM, Flash EEPROM, any other memory chip or cartridge, a carrier wave as described below, or any other medium from which a computer can read.

[0158] The term "tangible computer-readable medium" refers to a "computer-readable medium" that includes hardware components such as optical or magnetic disks.

[0159] Various forms of computer readable media may be involved to transmit data (e.g., sequences of instructions) to a processor. For example, the data may be (i) sent from a RAM to the processor, (ii) carried over a wireless transmission medium, (iii) formatted and / or transmitted in accordance with a number of formats, standards, or protocols, such as Ethernet (or IEEE 802.3), wireless local area network communications whether approved by the IEEE 802.11 specifications, WiFi Alliance, SAP, ATP, Bluetooth™, and TCP / IP, TDMA, CDMA, and 3G, and / or (iv) encrypted and configured to prevent privacy or fraud in various ways known in the art.

[0160] The term "database" means any electronically stored collection of data that is stored in a searchable format.

[0161] The term "data structure" refers to a database within a hardware machine, such as a computer.

[0162] "Network" means a set of points or nodes interconnected by communication paths. For example, a network may include multiple computers or communication devices interconnected by one or more wired and / or wireless communication paths. A network may interconnect with other networks and may include sub-networks.

[0163] The term "predetermined" means determined in advance, e.g., prior to the current time or current action. For example, the phrase "displaying a predetermined value" means displaying a value that is determined prior to display.

[0164] The word "condition" means (1) something that is premised on the performance of the agreement, or (2) something that is essential to the occurrence or happening of something else.

[0165] The term "transaction" means (1) the exchange or transfer of securities, services, or funds, or (2) any communication or activity involving two persons or things that affect or have an effect on one another.

[0166] Thus, a description of a process is also a description of a computer-readable medium that stores a program for performing the process. The computer-readable medium may store (in any suitable format) the appropriate program elements for performing the method. For example, a description of a process is a description of a computer-readable storage medium that stores a program that includes instructions that, when executed by a processor, directly cause the processor to perform the method.

[0167] The description of various steps in a process does not merely indicate that all steps described are required, and apparatus embodiments include computers or computing devices operable to perform some, but not necessarily all, of the described processes.

[0168] Similarly, just as a description of various steps in a process does not merely indicate that all steps described are required, embodiments of a computer-readable medium storing a program or data structures include computer-readable media storing a program that, when executed, may cause a processor to perform some, but not necessarily all, of the described process.

[0169] Where a database is described, one skilled in the art will understand that (i) alternative database structures to those described may be readily employed, and (ii) memory structures other than databases may be readily employed. Any illustrations or descriptions of sample databases presented herein are exemplary arrangements for representation of stored information. For example, any number of other ways may be employed other than those suggested by the tables illustrated in the drawings or elsewhere. Similarly, any illustrated entries in a database represent exemplary information only, and one skilled in the art will understand that the number and content of entries may differ from those described herein. Furthermore, despite depictions of databases as tables, other formats (including relational databases, object-based models, and / or distributed databases) may be used to store and manipulate the data types described herein. Similarly, object methods or operations of the database may be used to implement various processes as described herein. Furthermore, the database may be stored locally or remotely from devices that access data in such databases in a known manner.

[0170] Various embodiments may be configured to operate in a network environment including a computer in communication (e.g., via a communications network) with one or more devices. The computers may communicate directly or indirectly via wired or wireless media (e.g., the Internet, LAN, WAN or Ethernet, token ring, telephone lines, cable lines, radio channels, optical communications lines, commercial online service providers, bulletin board systems, satellite communications links, or any combination of the above). Each device may be based on a computer or other computing device configured to communicate with the computer, such as an Intel®, Pentium®, or Centrino™, Atom™, or Core™ processor. Any number and type of devices may be in communication with the computer.

[0171] In one embodiment, a server computer or centralized authority may not be necessary or desirable. For example, the present invention may, in one embodiment, be implemented in one or more devices without a central authority. In such an embodiment, any functions described herein as being performed by a server computer or by data described as being stored on a server computer are instead performed by or stored on one or more such devices.

[0172] Where a process is described, in one embodiment the process may operate without any user intervention, while in another embodiment the process includes some human intervention (e.g., performed with or in conjunction with human assistance).

[0173] As used herein, the term "encryption" means hiding information to conceal it so that it cannot be easily understood without special knowledge. The process of encryption may convert raw information, called plaintext, into encrypted information. Encrypted information may be called ciphertext, and the algorithm for converting plaintext to ciphertext may be called encryption. Encryption may also be used to perform the inverse operation of converting ciphertext back to plaintext. Examples of encryption include substitution encryption, transposition encryption, and encryption performed using a rotor machine.

[0174] In various encryption methods, encryption may require supplemental information called a key. A key may consist of, for example, a string of bits. A key may be used with a cipher to encrypt plaintext. A key may be used with a cipher to decrypt ciphertext. In a category of ciphers called symmetric key algorithms (e.g., private key cryptography), the same key is used for both encryption and decryption. Thus, the integrity of the encrypted information may depend on the key being kept secret. Examples of symmetric key algorithms are DES and AES. In a category of ciphers called asymmetric key algorithms (e.g., public key cryptography), different keys are used for encryption and decryption. In asymmetric key algorithms, any member of the public may use a first key (e.g., a public key) to encrypt plaintext into ciphertext. However, only the owner of the second key (e.g., a private key) will be able to convert the ciphertext back to plaintext. An example of an asymmetric key algorithm is the RSA algorithm.

[0175] VI. Pending Applications This disclosure provides one of ordinary skill in the art with an enabling description of several embodiments and / or inventions, some of which are not claimed in this application, but may be claimed in one or more continuing applications claiming benefit of priority to this application.

[0176] Applicants intend to file additional applications to pursue patents directed to subject matter disclosed and enabled but not claimed in this application.

[0177] VII.Abandonment Multiple references to particular embodiments are not intended to disclaim or negate additional, different embodiments, nor does similar reference to descriptions of embodiments all including characteristic features imply a waiver or negation of embodiments that do not include the characteristic features. Any explicit disclaimer or negation in this application will be supported by the language "does not include" or "is not possible."

[0178] VIII. Review Process In interpreting this application (including the claims), one of ordinary skill in the art will refer to the prosecution history of this application, but not to the prosecution history of any other patents or patent applications, regardless of whether those other patents or patent applications are considered to be related to this application, and regardless of whether there are any other patent applications that share a common claim of priority with this application. [Explanation of symbols]

[0179] 101 market 103 First Buy Side Participants 105 Secondary Buy Side Participants 107 First Sell-Side Participant 109 Secondary Sell-Side Participants

Claims

1. receiving a plurality of market making orders for a trading side for a financial security from each of a plurality of sell-side participants in a market for the financial security; receiving, for each of a plurality of market making orders among the plurality of money making orders, a respective list of approved buy-side participants among a plurality of buy-side participants in the market for the financial security; upon receiving the plurality of orders, tracking a price for each of the market making orders of the plurality of money making orders to a relative price and a plurality of ticks below a best price for a trading side of an order book for the market maintained by an electronic exchange platform; upon receiving the plurality of orders, populating a respective interface of each buy-side participant of the plurality of buy-side participants with market information including information about a respective subset of the plurality of market making orders for which the buy-side participant has been identified as an approved buy-side participant; receiving counter offers from buy-side participants that are authorized to trade with the subset of sell-side participants, the counter offers identifying sell-side participants that have priority for the plurality of market making orders; Upon receiving the counter offer, first, the counter offer is first, to orders in the order book according to a priority scheme that distributes liquidity to: first, to orders at the best bid or offer against the counter-offer; second, to market-making orders from sell-side participants having the identified priority; third, to a subset of market-making orders of the plurality of market-making orders for which the buy-side participant is admitted to trade and whose sell-side submitter has the best bid or offer order against the counter-offer; and fourth, to market-making orders for which the buy-side participant is admitted to trade and whose sell-side submitter does not have the best bid or offer order against the counter-offer; determining new best bid and offer prices in the order book in response to said distribution; an electronic exchange platform configured to adjust remaining market making orders of the plurality of market making orders to hold the following price upon determining the new best bid or offer.

2. The electronic exchange platform of claim 1 , wherein the financial securities include bonds.

3. 2. The electronic exchange platform of claim 1, wherein the electronic exchange platform includes a computing device, a network link, and a non-transitory memory having instructions stored thereon that, when executed by the computing device, cause the computing device to perform an operation.

4. 10. The electronic exchange platform of claim 1, wherein tracking the price comprises adjusting the price in response to market movements without input from the sell-side participants.

5. 10. The electronic exchange platform of claim 1, wherein the electronic exchange platform is configured to receive adjustments to a list of approved buy-side participants and to adjust each buy-side participant's interface in response to the adjustments.

6. 2. The electronic exchange platform of claim 1, wherein the electronic exchange platform is configured to import market information for the financial security into a sell-side interface and to control the import and placement of one of the plurality of market making orders by the sell-side participants.

7. 10. The electronic exchange platform of claim 1, wherein the electronic exchange platform is configured to adjust a sell-side participant interface when the price change occurs due to the tracking.

8. 2. The electronic exchange platform of claim 1, wherein the buy-side interface includes an input form for the preferred sell-side participant and a display of order quantity available from accepted sell-side participants at the tracked price.

9. 2. The electronic exchange platform of claim 1, wherein the market making orders include orders to buy the financial security and the counter offers include orders to sell the financial security.

10. The electronic exchange platform of claim 1 , wherein the plurality of ticks comprises two ticks.

11. 2. The electronic exchange platform of claim 1, wherein the market information includes best bids and offers, quantities available at the best bids and offers, and orders of liquidity available to the buy side.

Images