Inter-process communication that facilitates sell-side market making

Abstract

We provide an electronic exchange platform. [Solution] The system receives a list of approved buy-side participants for each of multiple market-making orders, tracks market-making orders received by the trading side for financial securities and prices that are several ticks lower than the best price on the trading side in the order book, presents market information to buy-side participants who identify approved market-making orders, receives counter-offers from buy-side participants who have been approved to trade a subset of multiple market-making orders, identifies sell-side participants for whom the counter-offers have priority, distributes the counter-offers, determines new best bids and offers according to the distribution, adjusts the remaining market-making offers, and maintains tracking in response to the determination of new best bids or offers.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims priority to U.S. Provisional Application No. 62 / 350,141, filed on June 14, 2016; U.S. Provisional Application No. 62 / 375,231, filed on August 15, 2016; and U.S. Provisional Application No. 62 / 376,665, filed on August 18, 2016. All of these applications are hereby incorporated by reference in their entirety.

[0002] Some embodiments relate to cell - side market making in an all - to - all market for supporting specially - privileged side customers as private liquidity providers.

Background Art

[0003] Parties trade financial securities such as stocks and bonds.

Summary of the Invention

Problems to be Solved by the Invention

[0004] The present invention is for solving the problems of the background art.

Brief Description of the Drawings

[0005] [Figure 1] A diagram showing an exemplary system according to some embodiments. [Figure 2] An exemplary method according to some embodiments is shown. [Figure 3] An example of an interface that can be used in some embodiments is shown. [Figure 4] An example of an interface that can be used in some embodiments is shown.

Modes for Carrying Out the Invention

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

[0007] First Embodiment Various examples of trading systems and methods that can be used in several embodiments are described in U.S. Patent Applications 14 / 059,000 and 12 / 938,189 by Sweeting et al., both of which are incorporated herein by reference in their entirety.

[0008] In some embodiments, orders may be placed with liquidity providers (market makers of sell-side banks and / or high-frequency / proprietary trading firms in certain markets, collectively referred to herein as “sell-side”) to ensure 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 all-to-all best bid / offer tradable through the market, such as a central limit order book (CLOB, or simply “order book”). Nevertheless, such liquidity supply orders can be made to track the best bid / offer. For example, the market may be manipulated using decimal pricing, and liquidity supply orders may be set at a price two ticks away from the best bid / offer (in general percentage pricing formats, lowering the bid and raising the ask price, or in high-yield formats, lowering the ask price and raising the bid price). Other implementations may have other arrangements, such as non-decimal values ​​and / or prices one, four, ten ticks away (or minimum price fluctuation) from the best price displayed in the CLOB. In other implementation methods, liquidity supply orders do not follow the best bid / offer at all. The platform may offer various system configurations for each security section, such as (i) returning by $10 / m for $0100m, or (ii) returning by $20 / m for $0200m. The numbers in brackets may be configurable on a daily or hourly basis, or may be linked to some external factor, such as potential or actual fluctuations.

[0009] The market can be configured to show traders whether they are logged in and connected to an API, and to indicate whether trading is possible for these traders, as well as through order management and execution management systems (OMS / EMS) of specific buy-side entities configured to see such liquidity provision.

[0010] In one example, a passive liquidity supply order to create a market might be $10 ($ / m) per million decimal from the top of an order ledger (e.g., a central limit order ledger or CLOB) priced in decimal 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 one-quarter of the most recent 1 / 32 for buys and one-quarter for sells, the market may restrict the price of liquidity supply orders that fall decimal below the top of the book CLOB price, even if they are within the range of the conventional 1 / 32 of a CLOB price displayed elsewhere. The passive liquidity supply order price may be restricted to increments of 1 / 32 as the decimal price as the decimal price approaches the 1 / 32 level. As a result, a predetermined $10 / m spread back (from the top of the book CLOB price) is temporarily compressed. The trading risk of price compression in this liquidity supply order may increase as the 1 / 32 increments approach the all-to-all GLOB market price. This risk may be limited if the market maker limits the quantity for specially favored buy-side clients in this liquidity supply pricing. The market maker should compare market data (e.g., available through Phoenix) with other venues to determine whether the liquidity supply order should remain as is (with or without such system-scale limitations) or be canceled considering the market price compression risk. It should be noted that the increments should be given as non-exclusive examples, and other embodiments may include other increments (e.g., 1 / 2 of 1 / 32 of certain secured bonds, or 1 / 8 of 1 / 32 of certain off-run government bonds maturing up to 2 years).

[0011] In some embodiments, users placing liquidity supply orders as described herein may be restricted from knowing the quantities of other users' liquidity supply orders. Alternatively, in some embodiments, liquidity supply orders may be displayed only to buy-side entities configured by the system to see them, in which case the display may be based on an agreement between the market maker placing the followed liquidity supply orders and the buy-side customers viewing them. Such buy-side entities may also have the market maker limit the disclosure of liquidity supply orders to the market to daytime only, and only those orders that they wish to disclose liquidity to the market at all times. In some embodiments, additions to the list may be made through the market production support team or by a “compensation claim” message via the graphical user interface (GUI), as is conventionally known.

[0012] In some embodiments, liquidity supply orders may take into account, adapt, present, and / or use the best bid / offer quantity (e.g., best price). A user interface presenting liquidity supply order information may be presented to a buy-side entity capable of placing orders. Information about such orders may be presented to buy-side users capable of placing orders, along with the regular order book. In some embodiments, buy-side users capable of placing orders may access such information via a mouseover pop-up interface, showing them all the liquidity available to buy-side traders behind the best bids and offers shown in the order book.

[0013] The quantity of a liquidity supply order may be displayed in the user interface of the new order ticket window. In some embodiments, an aggressive liquidity supply order type may also be available. The best price in the order book and the quantity of a liquidity supply order may both be displayed separately in the user interface (e.g., bids / offers in the order book that are above / below the liquidity orders behind these orders in the price setting). In some embodiments, the liquidity supply quantity may be aggregated along with the best bid / offer quantity in the order book by the quantity entered by an aggressive investor in either the buy or sell input element of the user interface, and the average price of that quantity may be displayed 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 the FIX and / or Itch / Ouch APIs. In some embodiments, market maker passive liquidity supply orders may be provided through a sell-side GUI. In other embodiments, orders may not be possible through the sell-side GUI. In both the sell-side GUI and API embodiments, viewing of other sell-side liquidity supply orders may be restricted or made publicly accessible.

[0015] In some embodiments, traders of a buy-side entity may access sell-side passive liquidity supply orders through aggressive liquidity supply orders. In some embodiments, if a buy-side entity provides orders in a liquidity supply order group that are contrary to its true intentions, such types of orders may be prevented from being traded by the buy-side entity. For example, if a buy-side entity has bid up a small quantity to pull up a liquidity supply order that sets an incremental price behind the best CLOB bid price, it may then be prevented from hitting or selling a 100m liquidity supply buy order.

[0016] In some embodiments, the market may decide when to present aggressive liquidity orders to match tradable passive liquidity orders. The market may use a variety of factors in making such decisions. Aggressive liquidity orders may be presented so that the entire quantity is traded at the best price in the order book by traders of the type that employ aggressive liquidity order methods. The remaining quantity of the aggressive liquidity order (from buy-side traders or traders configured to use it that way) may be made tradable in one or more passive liquidity orders (from sell-side traders or traders configured to use it that way) behind the best price.

[0017] In some embodiments, the first best-price order in each order book with a matching passive liquidity supply order (e.g., from the same customer) behind the best price may be given priority over aggressive liquidity supply orders at the price level of the passive liquidity supply matching. The remaining quantity after such priority execution may be distributed to 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 results in closing the bid / offer spread on CLOBs at the book price level.

[0018] In some embodiments, if an order at the best price exists, matching of passive liquidity supply orders behind the best price may be targeted. In some embodiments, matching of liquidity supply orders behind the best price, which have corresponding best price orders, may occur before matching of the order at the best price.

[0019] In some embodiments, aggressive buy-side investors can assign a "promotion code" or priority status to a market maker. If the market maker has a passive liquidity supply order, that order may be given priority in quantity allocation. This occurs when the market maker does not have the best order book price. In some embodiments, the market maker does not need to provide a passive order in order to engage in trading with the aggressive investor at the passive liquidity supply order price level. The market maker can be identified by the promotion code used with the aggressive liquidity supply order, which may result in the passive liquidity supply order being traded in whole or in part. In some embodiments, the market maker can be identified by the promotion code used with the aggressive liquidity supply order, and even if the market maker does not have a matching passive liquidity supply order, it may be invited via electronic message to receive preferential matching and submit a counter-offer. In some embodiments, the promotion code may identify multiple market makers. Markets may be identified in order of priority or treated equally. For example, a promotional code identifying four market makers A, B, C, and D provides quantities to A first, then B, ... Alternatively, quantities may be determined pro-rataly as described herein or elsewhere, or according to some other algorithm.

[0020] In some embodiments, the quantity may be divided according to some ranking coefficient. If the market maker's ranking is high enough, at some point it may receive preferential matching for some or all of the aggressive liquidity supply orders. In other embodiments, the quantity may be divided equally, prorately, and / or according to other priorities such as time and / or quantity.

[0021] In some embodiments, the quantity may be distributed according to the ratio of the quantity traded at the best order book price. In some embodiments, the ratio may be divided by a calculated ranking factor on a daily, weekly, monthly, or annual basis from market participation. Other methods of determining the factor, if used, may also be possible. In some implementation methods, top-ranked market makers may be given priority over other market makers. In some implementation methods, the quantity may be distributed among market makers according to the determined factor.

[0022] In some embodiments, if there is still a residual quantity after such algorithmic quantity allocation, that quantity may be matched with passive liquidity supply orders that do not provide the best-matched order in the order book. In some embodiments, such matching may be done in a pro rata manner. In some embodiments, such matching may be done with priority given to participants who offer better order book prices.

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

[0024] In some embodiments, the promotion code may be default, blank, or an algorithm described elsewhere may be used. In some embodiments, a trader or system specialist may change the default so that the default is not blank but some other promotion code. In some embodiments, a trader may use the GUI to change the default to some other promotion code. If the market maker identified by the promotion code holds passive liquidity supply orders, that market maker will receive the quantities as described elsewhere.

[0025] In some embodiments, the system may determine whether to use all liquidity supply orders to confirm an order. For example, it may be determined that there is sufficient liquidity for orders other than liquidity supply orders, and thus it may be determined that an aggressive investor's order can be confirmed at a better price than the liquidity supply order. In such a situation, the aggressive investor's order may be confirmed at a price desirable to the aggressive investor without using the liquidity supply order. 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 the number of tickets. For example, when using an aggressive liquidity supply order, instead of using multiple tickets at different price levels, an average trade may be made only once at a price slightly better (for the aggressive liquidity supply order user) than the price level of that liquidity supply.

[0027] In some embodiments, elements of trading activity may remain anonymous and / or undisclosed. Such anonymity and / or undisclosed status may last for a limited time. For example, in some embodiments, the quantity of liquidity supply 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 supply transactions may be excluded from the calculation of the day's close high and low. In some embodiments, liquidity supply transactions may be labeled for post-trading STP messaging and trading or regulatory reporting purposes.

[0028] In some embodiments, the randomization of customer identification numbers daily may be attributable 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 activated pool. If fraud occurs, a warning may be issued to the market production support team to conduct an investigation. A warning may also be issued if other suspicious events of market data manipulation occur before liquidity supply orders are hit.

[0029] In some embodiments, the market may adjust liquidity supply orders as the best bid / offer changes. Such orders may be adjusted collectively when the market moves. In some embodiments, a single bid or offer may move the market's best price, and in response, many liquidity supply orders may be adjusted. 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] While we discuss examples of liquidity supply orders that do not provide matching orders at the best price used to provide the quantity, it should be recognized that other implementation methods may not provide access to such orders.

[0031] In some embodiments, the proposed liquidity supply order quantities may be defined by a bilateral permission matrix, allowing the market maker to set a preferred counterparty.

[0032] Some embodiments of the market may interact with an order management system (OMS) such as Fidessa or Aladdin (as is commonly used in the market). The GUI of such a system may order order books in different ways by tagging the quantity of liquidity supply orders. Thus, orders may be distinguished between the quantity of a regular CLOB and the quantity of a liquidity supply order that is achieved only by trading the best CLOB price almost simultaneously.

[0033] Figure 3 shows an example of the interface (as seen by a buy-side user) in the first row, 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 (for the user). In some embodiments, the quantity that can be traded at the liquidity supply price may be significantly higher than the order book price. This example of the interface shows the following: (i) Element 301 is a promotion code as described above. Users can enter promotion code information into the interface element to influence the confirmation of their order. (ii) Elements 303 and 305 show the best order book (CLOB price, buy 99.9700, sell 99.9760) in the top row. The interface may be adjusted in response to changes in the CLOB. The interface displays an "x" to cancel the user's order through the interface, because the user has made a pending offer at the best CLOB price. (iii) Element 307 shows the quantity of buy orders for tradable passive liquidity supply in the second row. (iv) The unavailability of a passive liquidity supply order is indicated in element 309 by 99.9765625 (due to the presence of a buy-side trader's CLOB offer indicated in 99.9760). This can be indicated to the user that the order is unavailable, such as by highlighting the element of the interface, coloring the element of the interface, and / or displaying it in any desired manner. When an order is entered or the CLOB is modified, the availability of the order is changed, and the interface may be adjusted to indicate the change. (v) Element 311 is a sell order for aggressive liquidity supply with a quantity of 242 and a price of 99.9690, ready to be sent to the system for matching. The user can place an order at that price by clicking on the interface above the price display (99.9690). The user may also enter a quantity, such as 242, as shown in the interface, and trade at that quantity. (vi) Element 309 is a price compression in which an offer order for passive liquidity supply placed at 99.9770 is instead compressed to a fractional equivalent price of 1 / 32 of the most recent (99 + 31 and 1 / 4 × 1 / 32) (99.9765625).

[0034] An example of another interface that can be used in some embodiments is shown in Figure 4.

[0035] This interface shares many similarities with the previous interface. It can be used to display liquidity information and / or to place orders. This interface does not include a promotional code section (although promotional codes may be offered in some cases). Furthermore, in this example, price levels are shown as distinct from the leather edge or best bid / best offer price. For example, if you are buying an item with a best bid of 99.9700, as shown in 401, there are 250 units pending at 99.9690, 500 units at 99.9680, and 1050 units at 99.9670. In this interface, these orders are displayed as 250 (-10 from the best bid), 500 (-20 from the best bid), and 1050 (-30 from the best bid). These orders may rise to the actual price as the best bid moves, but they may also remain at the relative price distance. Thus, displaying the difference and the best bid provides information that can be used to derive the actual price. Similarly, the offer side displays +10, +20, +30, etc. In this example, the price compression shown in the interface is not displayed. In some cases, price compression may not be performed. In some cases, price compression may be performed even if it is not displayed in the interface. In other embodiments, price compression may be performed and may be shown in the interface. For example, instead of displaying +10 corresponding to a price of 99.9770, the interface may display +5.625 corresponding to a price of 99.9765625.

[0036] In some embodiments, compression may be optional and / or variable. For example, compression may move in a direction better than a set increment (e.g., 1 / 32), so that the price of a liquidity supply order becomes more desirable than a 1 / 32 increment. The extent to which this desirable price is reached may vary. As mentioned above, the increment may be 99.9765625, and an order at 99.9770 may, in some embodiments, be compressed relative to the increment. In other embodiments, the order may be compressed 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 the participant level, the order level, and / or the instrument level. For example, a sell-side participant may not use compression on one security but use incremental-level compression on another security, and use a better compression than incremental-level compression on yet another security (e.g., submitting compression information to the market). In some embodiments, participants may decide how much the compression should be increased (for example, by submitting the compression information to the market).

[0037] In some embodiments, parties (e.g., sell-side participants placing passive liquidity supply orders, buy-side participants placing active orders) may decide which counterparties they wish to trade with. This may also be a market requirement for trading to be possible in the market. For example, participants may be required to submit at least three counterparties they wish to trade with. The market may maintain valid trading party information privately and securely. For example, the market may store information in an encrypted matrix that matches each party with approved counterparties. The matrix of approved counterparties may be accessed to determine which orders each party is able to access. In some implementations, such approval may apply to all trades. In other implementations, such approval may apply to liquidity supply trades but not to CLOB trades. Approval may be performed at the entity level, order level, security level, etc.

[0038] In some embodiments, the user interface may present liquidity supply order information to the parties. To determine what information should be presented through the user interface, the market may access an approved counterparty matrix to determine whether a counterparty has bilateral approval with the party in question. For each counterparty in which the matrix indicates bilateral approval, information regarding liquidity supply orders may be determined and used, thereby incorporating it into the interface. Thus, the parties may be disclosed information regarding liquidity supply orders with counterparties that have bilateral approval.

[0039] In some embodiments, buy-side participants may be given the option to request liquidity supply orders from specific sell-side participants. For example, a buy-side participant might want to see a liquidity supply order from JP Morgan. The market may determine such an order and present it to the buy-side participant (e.g., if the parties have bilaterally approved it). This feature may remove an element of anonymity for sell-side participants. However, this feature makes it easier for buy-side participants to trade with participants who have a good relationship. Other embodiments may not have features to protect anonymity.

[0040] In some embodiments, a sell-side participant may place a passive liquidity supply order but cannot view orders from other participants. In some embodiments, a sell-side participant may enter a CLOB order and a passive liquidity supply order but cannot enter an aggressive liquidity supply order. In some embodiments, a buy-side participant may enter a CLOB order and an aggressive liquidity supply order but cannot enter a passive liquidity supply order.

[0041] It should be understood that the examples shown herein are not limiting. Other embodiments may include additional, fewer, or different elements. Embodiments can be combined with each other in any modification. In some embodiments, they are used for FX trading, financial trading, secured bonds, any OTC trading, and / or other desired trading.

[0042] Second Embodiment Some embodiments provide a platform for trading financial securities, such as secured bonds. The platform may allow any number of sell-side participants to enter market-making orders that track the best bid price or best offer price of the financial security. Sell-side market-making orders may be available to buy-side participants approved by the sell-side. The platform may distribute the quantity of counter-offers 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 those participants. The platform may fold sales to fractional amounts and provide price compression protection when its price approaches fractional amounts obtained through the market and / or other venues.

[0043] Figure 1 shows an example of a platform that may be used in several 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] Market 101 may include a computing device configured to enable trading of financial securities. The market may accept buy and sell orders for one or more financial securities. The computing device may manage, track, match, and settle orders. The computing device may include a matching engine configured for fast, low-latency matching of orders.

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

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

[0047] The market may provide APIs through which buy-side and sell-side participants can communicate orders. For example, orders may be placed in the market using FIX messaging over a communication network such as the internet. The market may receive information through APIs and interpret that information as orders.

[0048] The market may allow sell-side participants to act as market makers of financial securities. Sell-side participants may act as market makers by placing market-making orders on the market. In some implementations, market-making orders may be unilateral (e.g., sell orders or buy orders). In other implementations, there may be bilateral orders (both sell and buy orders can be used).

[0049] For example, a sell-side participant 107 may place a market-making buy order on a financial security (e.g., mortgage) 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 an associated quantity. This quantity may have to match the market's minimum order quantity, which is higher than a normal order book order (e.g., 200,000,000 compared to 1,000,000).

[0050] Similarly, a second sell-side participant 109 may use API and FIX messages to place a second market-making buy order on the same financial security. 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] Therefore, multiple sell-side participants may market-make on the same side of a single financial security. All sell-side participants may act as market makers on a single order side of a single financial security.

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

[0053] It should be understood that the 2-tick and tick count examples of fractional pricing are merely non-limiting examples. 2 ticks may provide a level of price protection that the market maker deems appropriate in this market example. For securities with more or less liquidity and / or volatility, the level of protection can be increased or decreased.

[0054] When the best bid or offer in the order book changes, the market maker's bids and offers may be adjusted and followed by the market to maintain a consistent relationship. For example, if the best bid in this example changes based on a new buy price received at 100.00, the market maker's buy order price will be adjusted accordingly to 99.90.

[0055] In some embodiments, the market may, depending on the circumstances, deviate from standard tracking of market makers' orders to the best bid or offer. For example, one market may operate on a fractional pricing model, while another may operate on a fractional pricing model (e.g., 1 / 4 of 1 / 32). In a fractional pricing market, if price adjustments to maintain tracking conflict with the price in a fractional pricing model, the market may instead set the price fractionally. This may provide market makers with a certain level of price compression protection. For example, in one market, if the best offer is set at 99.9760 with a tick of 0.0005, the market-making offer may typically be set at 99.9770. However, if compression protection is in place and a fractional price boundary exists at 99.9765625, the price may be set at the boundary of 99.9765625. This number may be rounded to or truncated to the 99.9765 level in some implementations.

[0056] In some embodiments, compression may be configurable by a market maker. The market maker may command the market not to apply compression to a security type for all orders, specific orders, etc. The market may act accordingly. The market maker may issue commands to a security type, all orders, specific orders, etc., for all orders, specific orders, etc., to use a standard incremental level of compression (e.g., compression to the boundary). The market may act accordingly. The market maker may issue commands to a security type, all orders, specific orders, etc., to use a method better than incremental level compression (e.g., compression to a better level than the boundary). The market may act accordingly. The market maker may provide information (e.g., by percentage, reference point, price, etc.) to identify how much better than incremental level compression must be than the boundary. The market may take action accordingly. The market maker may optionally modify such compression attributes. In some embodiments, the market maker may not use compression for one security, but may use incremental-level compression for other securities, and may use compression that is better than incremental-level compression for yet another security in any desired combination.

[0057] In some embodiments, a sell-side market maker's orders may be open to the entire market. In other embodiments, a market maker's orders may be open only to buy-side participants. In yet another embodiment, a market maker's orders may be limited to buy-side participants authorized to trade with the sell-side participants that make up the market. Creating a market involves risks of gaming and data breaches. Therefore, participants involved in this activity may need anonymity and protection of their information. By limiting the entities that can trade with market-making orders, the market may provide sell-side market makers with a level of security that promotes market-making and hinders market gaming.

[0058] A sell-side participant may identify in the market a list of buy-side entities that are approvers of a market-making order. The approved list may differ for each order and / or for each sell-side participant. The market may receive the list before, simultaneously 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 a first buy-side participant can trade in a 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 a second buy market-making order. The market may take action to ensure these intentions are fulfilled. For example, in that market, this could be achieved by preventing a second market-making participant from seeing, accessing, or trading in the first buy market-making order from the first sell-side participant.

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

[0060] In some embodiments, a buy-side participant may identify a list of approved sell-side entities in the market. The approved list may differ for each order and / or for each buy-side participant. The market may receive the list before, simultaneously with, and / or after an order. The market may place an order against a buy-side participant with bilateral approval (e.g., approval from both a buy-side participant and a sell-side participant).

[0061] The market may store buy-side and sell-side approval information. Such information may be stored in a bilateral counterparty approval matrix. Each cell in the matrix may store the bilateral approval status for the pair of trading partners. For example, the rows of a two-dimensional matrix may represent buy-side participants, and the columns may represent sell-side participants. The cell data structure may include an indicator of whether approval has been given to each other for the sell-side and buy-side participant pair in that cell. Bilateral approval for a buy-side participant can be determined by looking horizontally through the rows of the buy-side participant matrix and finding each cell that indicates approval on both sides. Once an approval list is obtained from a sell-side participant, an indicator may be set in each appropriate cell to identify that the sell-side participant has approved the buy-side participant. In response to receiving an approval list from a buy-side participant, an indicator may be set in each appropriate cell to identify that the buy-side participant has approved the sell-side participant. If both such indicators are set in a cell, bilateral approval is made for the buy-side and sell-side pair.

[0062] One party may access such a matrix to determine which orders are available to each party. For example, one may access such a matrix to decide which orders to display to participants. In some implementations, such approval may be applied to all transactions. In other implementations, such approval may be applied to liquidity supply transactions but not to CLOB transactions.

[0063] Matched orders may be distributed among approved sell-side participants according to market judgment. In some embodiments, market-making orders may be given matching priority if the sell-side participants of the order have order books and order holds at the corresponding best bid or offer. For example, if a first sell-side participant has an order held to buy on 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, the 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 that order. The 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 the first buy-side participant enters "confirm or cancel" on the market for a 600,000,000 unit sell offer, the order is first matched against the best bid of 1,000,000 from the first sell-side participant. This leaves a quantity of 599,000,000 in the offer. The market may then match the next order after the market-making order due to market priority. The first sell-side participant is given priority on the basis of having the best bid price in the order book. Thus, the offer of 500,000,000 may then be matched with the market-making order of the first sell-side participant. Subsequently, the remaining 99,000,000 in the offer may be matched with the market-making order of 800,000,000 of the second sell-side participant.

[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 adjust their price, returning one tick to remain two ticks below the new best bid, or they may be updated by the second sell-side participant to 800,000,000. This is done automatically in response to changes in market conditions.

[0066] In the above embodiment, 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 match the first one. Instead, matching may begin with a market-making order. For example, an order of 500,000,000 would match all 500,000,000 market-making orders from the first sell-side participant and would not match any best bid. This does not significantly affect the price, as market-making orders may be substantially larger than the best bid or offer. This adjustment may improve the speed of trading and reduce labor consumption by reducing the instructions required for processing and messaging used for reporting. If additional order quantities exist after matching with market-making orders, the embodiment may either match with the best bid or move to other market-making orders. Using other market-making orders first allows for more efficient energy operation.

[0067] In some embodiments, if multiple sell-side market-making participants have the best bid or offer, or neither, the quantity is distributed in various ways. For example, a pro-rate method may be used, priority may be given to active participants, priority may be given by time orders, or priority may be given by the price of order-book orders.

[0068] Buy-side participants may have priority in dealing with one or more sell-side participants. For example, preventing information leaks is of paramount importance to buy-side participants. Another example is research, which is of paramount importance to buy-side participants. Some sell-side participants may have a priority relationship with buy-side participants for information security and / or research provision. Buy-side participants may identify priority indicators for markets where traditional matching decisions may be prioritized.

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

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

[0071] To incorporate such interfaces along with useful information, the market may access an approved counterparty matrix to determine which counterparties have bilateral approval for a buy-side participant presenting the interface. For each counterparty the matrix indicates bilateral approval, information regarding market-making orders from that participant may be determined and used to incorporate this information into the interface. Thus, a buy-side participant can show information regarding market-making orders to a counterparty with bilateral approval, but will not show other orders that the buy-side participant cannot trade.

[0072] In some embodiments, buy-side participants may be given the option to request the market to incorporate information about market-making orders from specific sell-side participants into the interface. For example, a buy-side participant might 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 have bilateral approval). This feature may remove an element of anonymity for sell-side participants. However, this feature makes it easier for buy-side participants to trade with participants who have a good relationship. Other embodiments may not have features to protect anonymity.

[0073] In some embodiments, the market may decide whether to use market-making orders or standard order book orders when confirming an order. Such a decision may be based on the best interests of the aggressive investor. For example, if there are pending orders outside of market-making orders that would offer a better price to the aggressive investor, matching may also be performed against standard orders. For example, this may be the case when there is sufficient liquidity at the best bid to confirm the aggressive investor's order. If the standard order does not come to a confirmation, the market-making order system may be used instead.

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

[0075] Some embodiments may include performing a certain method. Such a method may be performed by the platform to enable trading using market-making orders from sell-side participants. This method may be performed by a computing unit based on the execution of one or more instructions stored on a non-temporary medium. Figure 2 shows an exemplary method that may be used in some embodiments.

[0076] As shown in the figure, some embodiments may include receiving a list of approved buy-side participants for each of the multiple market-making orders placed by each sell-side participant in the market for a financial security. As shown in the figure, some embodiments may include receiving each market-making order on the same side of the trade for the financial security from each of the multiple sell-side participants. As shown in the figure, some embodiments may include tracking all received market-making orders and prices that are multiple ticks lower than the best price on the trading side in the order book. As shown in the figure, some embodiments may include presenting market information to buy-side participants that identify approved market-making orders. As shown in the figure, some embodiments may include receiving counter-offers from buy-side participants authorized to trade a subset of multiple market-making orders that identify preferred sell-side participants. 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 approved trades with the buy-side participant, then to market-making orders where the buy-side participant has approved trades and the sell-side orderer has offered an order to match the initial order, and finally to market-making orders where the buy-side participant has approved trades and the sell-side orderer has not offered an order to match the initial order. As shown in the figure, some embodiments may include determining new best bids and offers after distribution. As shown in the figure, some embodiments may include adjusting the remaining market-making offers to maintain follow-through after determining new best bids or offers. It should be understood that this method is illustrative only. Other embodiments may include other methods involving different orders and / or different actions.

[0077] While various embodiments and features are shown throughout, it should be understood that such embodiments are not limiting. The methods of implementation may include any desired combination of elements in any order shown in any of the various embodiments described herein. Other embodiments may include additional or different elements as needed.

[0078] For example, in some implementations, the price may be calculated in increments of 1 / 32, or 1 / 16. Such embodiments may provide a high level of price granularity in a well-known system. In another embodiment, some embodiments may bypass compression protection beyond the incremental wall, allowing traders to perform such analysis.

[0079] In another embodiment, instead of liquidity supply orders following the laser edge or the best CLOB price, some embodiments may include separate books, namely CLOBs and blockbooks. The CLOB may operate on orders of small quantities (e.g., no quantity limit, minimum 1,000,000, etc.). The blockbook may operate on orders of larger quantities (e.g., 100,000,000, 500,000,000, 1,000,000,000, 2,000,000,000, etc.). The order quantities in such books may vary based on the financial security (e.g., the more liquidity the security, the larger the minimum quantity). The electronic market may maintain separate CLOBs and blockbooks for each financial security. In some embodiments, liquidity suppliers may enter orders of any quantity that can satisfy any minimum quantity in the CLOB. However, generally, smaller orders are also possible, and in other embodiments, there may be a minimum quantity in the CLOB (e.g., less than or equal to the minimum value in the blockbook). Larger orders that meet a larger minimum quantity may be placed in a blockbook. This embodiment of the blockbook may operate similarly to the liquidity supply orders described above, with the exception that the blockbook orders are not tied to or follow CLOB orders. CLOB price changes may not affect blockbook prices. Similarly, liquidity providers may not be required to place orders on CLOBs in order to participate in the blockbook in such embodiments. In some embodiments, order confirmation occurs through a book selected by the liquidity acquirer (for example, if the acquirer hits a CLOB and the CLOB order is confirmed, if the acquirer hits a blockbook offering an order of a minimum quantity or more, the blockbook order is confirmed). Order confirmation may use a priority mechanism such as the promotional codes described above. Some embodiments may prioritize larger liquidity providers, liquidity providers with CLOB orders at razor-edge prices, etc.In some embodiments, order confirmation may be performed by a market-determined book (for example, by matching the minimum order quantity, as described below).

[0080] While an embodiment of a blockbook with a single minimum quantity is shown, it will be understood that other embodiments may include any number of different quantity limits. For example, a blockbook 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 two-year financial security may have four independent entries in the blockbook: 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 can place orders, and the market may enter them into the appropriate entries in the blockbook that match the order quantities. The blockbook may track, match, and confirm orders separately for each quantity entry. Liquidity acquirers who wish to confirm orders that meet the minimum quantity threshold can place orders into the matching entries in that blockbook. An order placed may be confirmed through the appropriate blockbook entry, including any pending orders within that entry, in accordance with a priority mechanism (e.g., a promotional code).

[0081] In some embodiments, when an order from a liquidity acquirer reaches the electronic market, a decision may be made based on the quantity of the order whether to process it as a CLOB or a blockbook. If the order meets the minimum value of a blockbook, the order may be routed to a blockbook rather than a CLOB. The market may decide which blockbook entry to use to confirm 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 confirm the order. For example, a blockbook of 500,000,000 may process an order of 600,000,000.

[0082] In some embodiments, after aggressive investors' orders have been filled through determined blockbook entries, if there are any unmatched orders remaining, their liquidity can be filled with other orders (e.g., another entry in a CLOB). For example, the next highest minimum blockbook entry may be used to fill the remaining unfilled portion. Once all entries with matching prices have been used, in some embodiments, such remaining liquidity can also be filled using a CLOB. In other embodiments, only a single entry in the blockbook may be used to fill the liquidity of orders that match that entry.

[0083] Some embodiments may protect liquidity providers in the blockbook from manipulation by liquidity takers. Liquidity providers who place orders at higher entries in the blockbook may expect higher prices. Such higher prices represent a liquidity premium. Some embodiments may prevent liquidity takers from placing multiple orders on the trader side for a financial security during a period. The length of the period may be set based on the liquidity of the security. Such periods may range, for example, from milliseconds to 1 second, 5 minutes, or 10 minutes. This order prevention may encourage liquidity takers to obtain the desired liquidity by using orders of appropriate quantities. If a taker places a full quantity order, the taker's preference may be to have the order confirmed in one go at a suitable price. If a taker attempts to split an order into smaller orders to take advantage of lower blockbook entries, the taker may prevent such repeated orders. The electronic market may track placed orders, receive new orders, and compare them to tracked orders. If a new order for a security is placed by the same customer on the same side as a previous blockbook order during the prevention period, the market may notify the customer that they cannot place the order. After that period, the buyer can place another order.

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

[0085] Traditional trading, which does not benefit from modern computing solutions, cannot offer the speed and analysis of multiple data sources that 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 modern electronic markets moving at high speeds, such as those described herein.

[0086] The platform's ability to automatically apply market-making orders to the best bid or offer price may provide a technical solution to technical problems based on electronic trading technology. The acceleration of market activity means that network capacity and processing time can become significant issues. When the market moves, the time it takes to report, process, and respond to that movement can result in significant losses for participants. This is true even if only a few seconds have passed.

[0087] Traditionally, the market operates by trusting traders, monitoring market movements, and adjusting orders to maintain tracked orders based on their price distance from other orders. However, due to the speed of market movements and network and processing delays, a delay can occur as the market moves, allowing traders to adjust their orders. Setting prices locally on the platform eliminates this delay and protects traders from risk. Traditionally, traders are exposed to the risk of competitive conditions after market movements. For example, the market moves, a trader may submit an adjustment to their order, and the price may move accordingly. However, another trader may try to counter the trader's adjustment. Even if a trader wants to change the price of their order, other traders may enter a counter-offer before the trader's wishes reach the conventional market. In some embodiments of the platform described herein, this competitive condition may be substantially eliminated and traders protected by making prices locally track market movements.

[0088] Furthermore, in some embodiments, bandwidth utilization and / or processing operations may be reduced. For example, in a conventional market where a customer automatically adjusts orders, a customer may need to submit many order price adjustments. Each such price adjustment uses bandwidth and needs to be processed in both the adjusted market and the customer who made the adjustment. In some embodiments of the platform described herein, bandwidth utilization may be reduced because no such adjustments are submitted, and the processing that needs to be performed is also reduced because no orders for adjustment are sent or received. This may result in a market that is both energy-efficient and bandwidth-efficient.

[0089] The various embodiments provide a level of anonymity and information security that would not typically be found in public markets. In open-out markets used before electronic trading, trading intent and identity were publicly known. In typical electronic trading systems, orders are widely publicized to the market, and reports of trading activity are similarly widely reported to the market. The various embodiments of this specification address such issues of information flow and lack of identification, allowing participants to participate in the market with confidence.

[0090] Furthermore, order access in both traditional non-electronic and electronic markets is open to everyone. Traditional markets cannot conduct transactions according to the complex web of bilateral approvals and priority rights. The various embodiments described herein may create mappings between market participants to match the priority rights of trading partners, which would be impossible in traditional markets.

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

[0092] term The term "product" means the machine, manufacture, and / or composition of a thing, unless otherwise explicitly specified.

[0093] The term "process" means a procedure, algorithm, method, etc., unless otherwise explicitly specified.

[0094] Each process (whether expressed as a method, algorithm, or otherwise) essentially comprises one or more steps, and therefore every reference to one or more “steps” of a process has an inherent prior limitation in the mere description of a process, or in the mere description of “process” or similar terms. Accordingly, any reference in a claim to one or more “steps” of a process has a sufficient prior limitation.

[0095] Unless explicitly specified otherwise, terms such as "invention" refer to "one or more inventions disclosed in this application."

[0096] Unless explicitly specified otherwise, the terms "embodiment," one or more first or previously described "embodiments," "one or more embodiments," "several embodiments," "a particular embodiment," "one embodiment," and "another embodiment" mean "one or more (but not all) embodiments of the present invention."

[0097] In this invention, the term "modification" means embodiments of the invention unless explicitly specified otherwise.

[0098] The term "indication" is used in a very broad sense. The "indication" of an object should be understood to include anything that may be used to determine that object.

[0099] An object's representation may include an electronic message that identifies the object (e.g., identification of a widget by a serial number attached to the widget, identification of a widget by one or more of its features). An object's representation may include information that can be used to compute and / or retrieve the object (e.g., information that identifies a machine that is a component that a widget can use to determine the widget). An object's representation may specify something related to the object (e.g., a property of the object, a name of the object, a name of an object related to the object). An object's representation may not specify anything related to the object (e.g., the letter "a" may be a representation of a widget in a computer system configured to interpret the letter "a" to identify the widget). An object's representation may include signs, symptoms, and / or tokens of the object. For example, a representation may include a code, reference, example, link, signal, and / or identifier. An object's representation may include information that can represent, describe, and / or associate with the object.

[0100] A change in the representation of an object may also be a representation of an object (for example, an encrypted representation of an object may be a representation of an object). A representation of an object may include the object itself, a copy of an object, and / or a part of an object. A representation of an object may be meaningless to anything not configured to understand the representation (for example, a person cannot understand that the letter "a" indicates a widget, but a computer system can determine from the letter "a" that it is a widget, so there is no doubt that it represents a widget). It should be understood that the fact that a representation of an object can be used to determine something does not mean that the object, or anything else, 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 also include representations of other objects (for example, an electronic message 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] "To represent" means (1) to express, specify, represent, or signify as a word, symbol, etc. represents; (2) to express or specify by a term, character, symbol, etc.; (3) to depict, express, or present a similarity like a picture; or (4) to serve as a sign or symbol.

[0102] The expression “another embodiment” describing one embodiment does not mean that the referenced embodiment is mutually exclusive with other embodiments unless explicitly specified (for example, an embodiment described before the referenced embodiment). Similarly, the fact that two (or more) embodiments are referenced does not mean that those embodiments are mutually exclusive.

[0103] One embodiment of the present invention may include, encompass, or include a plurality of other embodiments of the present 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 "include" and "equip" and their variations mean "to include, but not necessarily to limit," unless explicitly specified otherwise. Therefore, for example, the sentence "The machine includes a red widget and a blue widget" means that the machine includes a red widget and a blue widget, but it may also include one or more other items.

[0105] The term "consisting of" and its variations mean "including" and "limited to" unless explicitly specified otherwise. Therefore, for example, the sentence "The machine consists of a red widget and a blue widget" means that the machine includes a red widget and a blue widget, but does not include anything else.

[0106] The term "composition" and its variations mean "making up the components or parts of the materials" unless explicitly specified otherwise. Therefore, for example, the sentence "The red widget and the blue widget constitute the machine" means that the machine includes the red widget and the blue widget.

[0107] The term "consisting exclusively of" and its variations, unless explicitly specified, means "to be made exclusively of components that constitute or are the sole constituent." Therefore, for example, the sentence "The machine consists only of red and blue widgets" means that the machine is made up of red and blue widgets (i.e., nothing else).

[0108] The number of items, unless explicitly specified, means "one or more." Therefore, for example, the phrase "widget" means one or more widgets unless explicitly specified. Similarly, after quoting the phrase "widget," a subsequent quote of the phrase "that widget" means "one or more widgets." Therefore, it should be understood that a word appearing a second or subsequent time may refer to a specific term that has a basis for prior limitation. For example, if a paragraph refers to a "specific single feature" and then refers to "feature," it should be understood that the phrase "feature" refers to the aforementioned "specific single feature" (the term "single" in "specific single feature" should be understood as meaning "one" specific single feature, not "one or more" distinctive single features).

[0109] The term "plural" means "two or more" unless explicitly specified otherwise.

[0110] The term “in this specification” means “in this application, including all that may be invoked by reference,” unless expressly specified otherwise.

[0111] The phrase "at least one" means one or more combinations of items when such a phrase modifies multiple items (e.g., a list of items) unless explicitly specified otherwise. For example, the phrase "at least one widget, car and wheel" means any of the following: (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, car and a wheel. The phrase "at least one" does not mean "one of" multiple items when modifying multiple items. For example, the phrase "at least one of widgets, cars and wheels" does not mean "one widget, one car, and one wheel."

[0112] When numbers like "1" or "2" are used as base numbers to indicate a quantity (for example, "one widget," "two widgets"), they represent the quantity indicated by the number, but not necessarily the quantity indicated by the number itself. For example, the phrase "one widget" does not mean "at least one widget," and therefore, the phrase "one widget" does not refer to, for example, two widgets.

[0113] The phrase "based on a standard" does not mean "based solely on" unless explicitly specified. In other words, the phrase "based on" encompasses both "based solely on" and "based at least on." The phrase "based at least on" is synonymous with the phrase "based at least partially on." For example, the statement "Element A is calculated based on elements B and C" includes embodiments where element A is calculated as the product of B × C (i.e., A = B × C), embodiments where A is calculated as the sum of B and C (i.e., A = B + C), embodiments where A is calculated as the product of B × C × D, and embodiments where A is calculated as the sum of the square roots of B + C + D × E, etc.

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

[0115] The term "therefore" is used herein only before any clause or other group of words that express only the intended result, purpose, or conclusion of something explicitly stated before the term "therefore." Accordingly, if the term "therefore" is used in a claim, any clause or other wording that modifies the term "therefore" does not impose any further specific limitations on the claim, nor does it limit the meaning or scope of the claim.

[0116] Terms such as "for example," "e.g.," and similar terms mean "to give an example," and therefore do not limit the terms or phrases being described. For example, in the sentence "A computer transmits data over the Internet (e.g., instructions, data structures)," 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 structures" are an example of "data" that a computer may transmit over the Internet. However, both "instructions" and "data structures" are merely examples of "data," and other things besides "instructions" and "data structures" may also be "data."

[0117] The term "each" and similar terms mean "individually." Therefore, when two or more things have "each" characteristics, each has its own unique characteristics, and these characteristics may or may not be different from each other. For example, the phrase "each of the two machines has its own function" means that the first of the two machines has a function, and the 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 "that is" and similar terms mean "in other words," and therefore mean to limit the term or phrase being described. For example, in the sentence "A computer transmits data (i.e., instructions) over the internet," the term "that is" explains that the "instructions" are the "data" that the computer transmits over the internet.

[0119] A numerical range includes integers and non-integers within that range unless explicitly specified otherwise. For example, the range "1 to 10" includes integers (e.g., 1, 2, 3, 4, ..., 9, 10) and non-integers (e.g., 1.0031415926, 1.1, 1.2, ..., 1.9).

[0120] When two or more terms or phrases are synonymous (for example, by explicitly declaring that terms or phrases are synonyms), it does not mean that an instance of such term or phrase must have a different meaning from another instance of such term or phrase. For example, the meaning of "contains" in a description is synonymous with "contains but not limited to," but when used in the phrase "contains but not limited to," the term "contains" does not have any other meaning than "contains but not limited to."

[0121] II.Decision The terms "decision" and "determination" and their grammatical variations (e.g., determining a price, determining a value, determining an object that meets a specific criterion) are used in a very broad sense. The terms "decision" and "determination" encompass a wide range of actions and may therefore include calculation, operation, processing, derivation, investigation, retrieval (e.g., searching within a table, searching in a database or other data structure), display in an electronic format or digital representation, confirmation, etc. Also, "decision" and "determination" may include reception (e.g., receiving information), access (e.g., accessing data in memory), etc. Furthermore, "decision" and "determination" may include resolution, selection, selection, establishment, etc.

[0122] The terms "decision" and "judgment" do not imply certainty or absolute accuracy; therefore, "decision" and "judgment" may include estimation, extrapolation, prediction, estimation, averaging, etc.

[0123] The terms "decision" and "judgment" do not imply that mathematical processing must be performed, that numerical methods must be used, or that algorithms must be used.

[0124] The terms "decision" and "judgment" do not imply that any specific device must be used. For example, a computer does not necessarily have to perform the decision or judgment.

[0125] The terms “decision, judgment” may include “calculation.” The term “calculation” should be understood to include performing one or more calculations. Calculation may include operations, processing, and / or derivation. Calculation may be performed by an arithmetic unit. For example, calculating an object may include applying an algorithm to data by a computer processor and producing an object as the processor’s output.

[0126] The terms “decision, determination” may include “reference.” The term “reference” should be understood to include, for example, creating one or more references to an object. References may include queries, access, selection, selection, reading, and / or retrieval. The act of referencing may be performed by the arithmetic unit. For example, referencing an object may include reading the memory location where that object is stored by the processor.

[0127] The term “decision” may include “reception.” For example, receiving an object may include taking in an object. In some embodiments, reception may include actions performed to take in an object, such as manipulating a network interface into which the object is taken. In some embodiments, reception may occur without any actions performed to take in an object, such as direct memory writing or hardwired circuitry. Receiving an object may include receiving an object from a remote source from which the object would have been computed.

[0128] III. Form of text The limitation of claim 1 includes one feature and more than one feature at the same time (for example, a limitation such as "at least one widget" includes one widget and more than one widget at the same time), and claim 2, if dependent on claim 1, uses clear terminology to refer to that limitation (for example, "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 (for example, "the widget" may include both one widget and multiple widgets).

[0129] When ordinal numbers (e.g., "first," "second," "third," etc.) are used as adjectives before a term, they (unless explicitly specified) merely indicate a special characteristic, such as distinguishing a particular feature from another characteristic described by the same or similar term. The ordinal number does not carry any other meaning or limiting effect and is simply used as a convenient name. For example, "the first widget" can be named simply to distinguish it from, for example, "the second widget." Therefore, when the ordinal numbers "first" and "second" are used before the term "widget," they do not indicate any other relationship between the two widgets, nor do they indicate any other characteristic of either or both widgets. For example, simply using the ordinal numbers "first" and "second" before the term "widget" does not indicate (1) that one widget appears before or after the other in order or position, (2) that one widget occurs or acts before or after the other in time, or (3) that one widget is ranked above or below the other in importance or quality. The mere use of ordinal numbers does not define numerical limits on the features identified by the ordinal numbers. For example, simply using the ordinal numbers "first" and "second" before the term "widget" does not mean that there are exactly two widgets.

[0130] Where a single device, article, or other product is described herein, in other embodiments, multiple devices or articles (whether they work together or not) may be used instead of the single device or article described. Accordingly, the functions described as being possessed by a device may, in other embodiments, be possessed by multiple devices or articles (whether they work together or not).

[0131] Similarly, where multiple devices, articles, or other products are described herein (whether they work together or not), in other embodiments, a single device or article may be used instead of the multiple devices or articles described. For example, multiple computer-based devices may be substituted for a single computer-based device. In some embodiments, such multiple computer-based devices may work together to perform a step in a process common to a grid computing system. In some embodiments, such multiple computer-based devices may work together to provide additional functionality to each other, and multiple devices may be operated together to perform a step in a process common to a process in a cloud computing system. (Conversely, a single computer-based device may be replaced by multiple computer-based devices working together. For example, a single computing device may be replaced by servers and workstations that communicate with each other over 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 functions and / or features of a single device described may, in other embodiments, be embodied in a different way by one or more other devices that are described but not explicitly stated to have such functions or features. Accordingly, other embodiments do not have to include the described device itself, but rather may include one or more other devices having such functions or features.

[0133] IV. The disclosed examples and terms are not limited to those described herein. Neither the title of the invention (as stated at the beginning of page 1 of this application) nor the abstract (as stated at the end of this application) shall in any way limit the scope of the disclosed invention, and shall be construed 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 it is required pursuant to 37C.FR section 1.72(b).

[0134] The section headings provided in this application are for convenience only and should not be considered to limit the disclosure in any way.

[0135] Numerous embodiments are described in this application and are presented for illustrative purposes only. The embodiments described are not, and are not intended to be, limiting in any sense. 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 carried out with various modifications and changes, such as structural, logical, software, and electrical alterations. Specific features of the disclosed invention may be described by reference to one or more specific embodiments and / or drawings, but it should be understood that, unless expressly specified, such features are not limited to their use in one or more specific embodiments or drawings in which they are described.

[0136] One embodiment may be disclosed as including several features, but other embodiments of the present invention may include fewer features than all of such features combined. Accordingly, for example, the claims may be less than the entire set of features in the disclosed embodiments, and such claims will not be construed as requiring features beyond those explicitly mentioned in the claims.

[0137] None of the method steps or product elements described in this application constitute, are essential to, or extend to the inventions described herein, unless expressly stated (with respect to the claims and the invention as defined herein).

[0138] Any claim preamble that references any class other than a statutory class shall be construed as referencing the purpose, benefits and possible uses of the claimed invention, and such preamble shall not limit the claimed invention.

[0139] This disclosure does not represent in text all embodiments of the present invention. Nor does this disclosure enumerate features of the present invention that must be present in all embodiments.

[0140] Not all disclosed embodiments are necessarily included in the claims (including all pending, amended, issued, and revoked claims). Furthermore, disclosed embodiments may be included in some claims (though not necessarily). Therefore, if a claim (whether pending, amended, issued, or revoked) is directed to a particular embodiment, it is not evidence that other claims do not include that embodiment.

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

[0142] Descriptions of embodiments having several components or features do not imply that all or any of such components or features are necessary. On the contrary, various optional components are described to illustrate the wide variety of possible embodiments of the invention. Unless otherwise specified, components or features are neither absolutely essential nor required.

[0143] Process steps, algorithms, etc., may be described or requested in a specific sequential order, but such processes may also be configured to function in a different order. In other words, any order or sequence of steps that may be explicitly described or requested does not necessarily imply that the steps must be performed in that order. The steps of the processes described herein may be performed in any possible order. Furthermore, some steps may be performed concurrently unless specifically described or implied to be performed non-concurrently (for example, because one step is described after another). Furthermore, the illustration of a process by its depiction in the drawings does not imply that other variations and modifications to the illustrated process are excluded, nor does it imply that the illustrated process or any of its steps is necessary for the invention, nor does it imply that the illustrated process is preferred.

[0144] A process may be described as comprising multiple steps, but this does not imply that any or all of the steps are preferred, undesirable, or essential. Various other embodiments within the scope of the described invention also include other processes that omit some or all of the described steps. Unless otherwise specified, the steps are neither absolutely essential nor mandatory.

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

[0146] The product comprises multiple components, aspects, qualities, features, and / or characteristics, but this does not indicate that any or all of these multiple components are preferred, absolutely essential, or required. Various other embodiments within the scope of the invention described herein include other products that omit some or all of the multiple components described herein.

[0147] A list of items (which may or may not be numbered) does not imply that any or all of the items are mutually exclusive unless explicitly stated otherwise. Similarly, a list of items (which may or may not be numbered) does not imply that any or all of the items are inclusive of any category unless explicitly stated otherwise. For example, the list “Computers, Laptops, and PDAs” does not imply that any or all of the three items in that list are mutually exclusive, nor that any or all of the three items in that list are inclusive of any category.

[0148] The enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are equivalent to or readily interchangeable with one another.

[0149] All embodiments are illustrative and do not necessarily imply that the present invention or any of its embodiments have been generated or practiced.

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

[0151] The term "calculation" means making 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 thereof, regardless of architecture (e.g., chip-level multiprocessing or multicore, RISC, CISC, microprocessors without interlocked pipeline stages, pipeline configurations, simultaneous multithreading, integrated graphics processing units, GPGPUs).

[0153] "Computational unit" means one or more microprocessors, central processing units (CPUs), computing units, microcontrollers, digital signal processors, graphics cards, mobile game devices, or similar devices, or any combination thereof, regardless of architecture (e.g., chip-level multiprocessing or multicore, RISC, CISC, microprocessors without interlocked pipeline stages, pipeline configurations, simultaneous multithreading).

[0154] Therefore, a process description is similarly a description of the apparatus for executing the process. The apparatus for executing the process may include, for example, a processor and appropriate input and output devices for executing the process. For example, a process description is a description of an apparatus that includes a processor and memory that stores a program containing instructions that cause the processor to perform that method when executed by the processor.

[0155] A device that executes a process may include multiple computing units that cooperate to execute the process. Some of the computing units may cooperate to execute each step of the process, may act on separate steps of the process, and other computing units may provide underlying services that facilitate the execution of the process. Such computing units may operate under the direction of a central authority. In another embodiment, such computing units may operate without the direction of a central authority. Some embodiments of a device operating in some or all of these ways may include grid computing systems, cloud computing systems, peer-to-peer computing systems, computer systems configured to provide software as a service, and so on. For example, the device may include a computer system that performs most of its processing load on a remote server but outputs display information to a local user computer, such as a computer system running VMware software, and receives user input information from there.

[0156] Furthermore, programs that implement such methods (like other types of data) may be stored and transmitted in various ways using various media (e.g., computer-readable media). In some embodiments, hardwired circuits 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, various combinations of hardware and software may be used instead of software alone.

[0157] The term “computer-readable medium” means any non-temporary medium, or combination of multiple identical or different media, that is involved in providing data (e.g., instructions, data structures) that can be read by a computer, processor, or similar device. Such media include, but are not limited to, non-volatile media, volatile media, and transmission media, and can take many forms. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media typically include dynamic random-access memory (DRAM) that constitutes main memory. Transmission media include coaxial cables, copper wires, and optical fibers, which include wiring including system buses coupled to processors. Transmission media may include, or transmit, sound 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, floppy disks, flexible disks, hard disks, magnetic tapes, other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tapes, any other physical media having a pattern of holes, RAM, PROMs, EPROMs, flash EEPROMs, any other memory chips or cartridges, carriers as described below, or any other media that a computer can read.

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

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

[0160] The term "database" refers to a collection of any electronically stored 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 series 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 subnetworks.

[0163] The term "predetermined" means determined in advance, for example, before the current time or action. For example, the phrase "display a predetermined value" means to display a value that has been determined before it is displayed.

[0164] The term “condition” means that (1) it is predicated on the performance of the agreement, or (2) it is essential for the appearance or occurrence of something else.

[0165] The term “transaction” means (1) the exchange or transfer of securities, services or funds, or (2) communication or activity involving two parties or things that affect each other or influence each other.

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

[0167] Since the description of the various steps in the process does not merely indicate that all the steps described are necessary, the embodiment of the apparatus includes a computer or computing device that can be operated to perform some (but not necessarily all) of the described process.

[0168] Similarly, so as to ensure that a description of various steps in a process does not simply indicate that all described steps are necessary, an embodiment of a computer-readable medium for storing a program or data structure includes a computer-readable medium that, when executed, may execute some (but not all) of the processes described by the processor.

[0169] Where a database is described, a person skilled in the art will understand that (i) alternative database structures can be readily adopted instead of the one described, and (ii) memory structures other than databases can also be readily adopted. Any diagrams or descriptions of the sample databases presented herein are arranged illustratively for the purpose of representing the stored information. For example, any number of other methods other than those proposed by diagrams or tables illustrated elsewhere can be adopted. Similarly, any illustrative entries in a database represent only illustrative information, and a person skilled in the art will understand that the number and content of entries may differ from those described herein. Furthermore, even though the database is depicted as a table, other formats (including relational databases, object-based models, and / or distributed databases) can be used to store and manipulate the data types described herein. Similarly, various processes as described herein can be performed using the object methods or operations of the database. Furthermore, the database may be stored locally or remotely from the device that accesses the data in such a database in known ways.

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

[0171] In one embodiment, a server computer or central authority may not be required or desirable. For example, in one embodiment, the present invention may be implemented on one or more devices without a central authority. In such an embodiment, any function described herein that is performed by a server computer or by data written to be stored on a server computer is instead performed 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. 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 concealing information in order to conceal it so that it cannot be easily understood without special knowledge. The encryption process may convert raw information, called plaintext, into encrypted information. Encrypted information may be called ciphertext, and the algorithm used to convert plaintext to ciphertext may be called encryption. Encryption may also be used to perform the reverse operation of converting ciphertext back to plaintext. Examples of encryption include substitution encryption, inversion encryption, and cryptanalysis 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 an cipher to encrypt plaintext. A key may also be used with an cipher to decrypt ciphertext. In a category of cryptography called symmetric-key algorithms (e.g., private-key ciphers), the same key is used for both encryption and decryption. Therefore, the integrity of the encrypted information may depend on the secret key. Examples of symmetric-key algorithms are DES and AES. In a category of cryptography called asymmetric-key algorithms (e.g., public-key ciphers), different keys are used for encryption and decryption. In an asymmetric-key algorithm, 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 a second key (e.g., a private key) can decrypt the ciphertext back into plaintext. An example of an asymmetric-key algorithm is the RSA algorithm.

[0175] VI. Ongoing Applications This disclosure provides to those skilled in the art a practical description of several embodiments and / or inventions. Some of these embodiments and / or inventions are not claimed in this application but may be claimed in one or more subsequent applications claiming priority of this application.

[0176] The applicant intends to file additional applications to pursue patents relating to subject matter that is disclosed and implementable but not claimed in this application.

[0177] VII.Abandonment Numerous references to specific embodiments are not intended to waive or negate additional, different embodiments, nor do references to descriptions of embodiments that all include distinctive features indicate a waiver or denial of embodiments that do not include distinctive features. Any explicit waiver or denial in this application is supported by the phrases "does not include" or "is not possible."

[0178] VIII. Review Process In interpreting this application (including the claims), a person skilled in the art will refer to the examination history of this application, but will not refer to the examination history of any other patent or patent application, regardless of whether other patents or patent applications are considered to relate to this application, regardless of whether other patent applications exist, and regardless of whether other patent applications share a priority claim with this application. [Explanation of symbols]

[0179] 101 market 103 First Buy-Side Participants 105 Second Buy-Side Participants 107 First sell-side participants 109 Second Sell-Side Participants

Claims

1. The trading side receives multiple market-making orders for the said financial securities from each of several sell-side participants in the financial securities market. For each of the multiple market-making orders among the multiple money-making orders, receive a list of each approved buy-side participant among the multiple buy-side participants in the market for the financial security. Upon receiving the aforementioned multiple orders, the price for each of the market-making orders among the multiple money-making orders is set to follow the relative price to the best trading price in the order book for the market maintained by the electronic exchange platform and a price several ticks lower. Upon receiving the aforementioned multiple orders, market information is imported into the interface of each of the multiple buy-side participants, including information about each subset of the multiple market-making orders in which the buy-side participant is identified as an approved buy-side participant. A buy-side participant authorized to trade with the subset of sell-side participants receives a counter-offer identifying the sell-side participant who has priority over the multiple market-making orders. Upon receiving the aforementioned counter-offer, first, the counter-offer is, In accordance with a priority distribution scheme that first distributes liquidity to orders in the order book, firstly to orders in the best bid or offer opposing the counter-offer, secondly to market-making orders from the identified priority sell-side participants, thirdly to a subset of market-making orders among the multiple market-making orders for which the buy-side participant has been authorized to trade and whose sell-side submitter has an order in the best bid or offer opposing the counter-offer, and fourthly to market-making orders for which the buy-side participant has been authorized to trade and whose sell-side submitter does not have an order in the best bid or offer opposing the counter-offer, In accordance with the distribution, the new best bid and offer prices are determined in the order book. An electronic exchange platform configured to adjust the remaining market-making orders from the aforementioned multiple market-making orders and to hold the following price once the new best bid or offer has been determined.

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

3. The electronic exchange platform according to claim 1, wherein the electronic exchange platform includes a computing device, a network link, and a non-temporary memory storing instructions, and when executed by the computing device, the computing device operates.

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

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

6. The electronic exchange platform according to claim 1, wherein the electronic exchange platform is configured to take in market information for the financial securities into a sell-side interface and to control the sell-side participants so that they can take in and place one of the plurality of market-making orders.

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

8. The electronic exchange platform according to claim 1, wherein the buy-side interface includes an input form for the preferential sell-side participant and a display of the order quantities available from the sell-side participant approved at the bid price.

9. The electronic exchange platform according to claim 1, wherein the market-making orders include buy orders for the financial securities, and the counter-offers include sell orders for the financial securities.

10. The electronic exchange platform according to claim 1, wherein the plurality of ticks include two ticks.

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

Images