CROSS-REFERENCE TO RELATED APPLICATIONSThis application is a continuation of U.S. patent application Ser. No. 15/052,779, filed Feb. 24, 2016, which claims priority to U.S. Provisional Application Ser. No. 62/120,284 filed Feb. 24, 2015, both of which are incorporated herein by reference in their entireties for all purposes.
BACKGROUNDA financial market allows traders and entities to buy and sell (i.e., trade) financial securities (e.g., stocks and bonds), commodities (e.g., precious metals or agricultural goods), futures contracts, and other investment products. Financial markets work by placing interested buyers and sellers in one “place” (e.g., an actual or electronic marketplace), thus making it easier for market participants to find each other. A trader is a market participant who buys and sells financial instruments such as stocks, bonds, commodities, options, currencies, and derivatives.
Traders generally follow different timelines for transacting within a financial marketplace. Position/trend traders may stay in positions for over a few weeks, sometimes up to a year. Swing traders may hold positions for a few days to a few weeks. Day traders may hold positions throughout a trading day (for periods that are sometimes as short as a few seconds or as long as a few hours) and finish the day with no open positions. This form of trading requires the trader to be present in front of the computer when trading is occurring and to quickly review potentially profitable transactions based on the market data.
BRIEF DESCRIPTION OF THE DRAWINGSEmbodiments of the present invention will be described and explained through the use of the accompanying drawings in which:
FIG. 1 illustrates an example of a network-based environment in which some embodiments of the present invention may be utilized;
FIG. 2 illustrates various components and interactions in an order inheritance system according to one or more embodiments of the present invention;
FIG. 3 illustrates various components of a trading platform which may be used in accordance with various embodiments of the present invention;
FIG. 4 is a flowchart illustrating a set of operations for processing order transfers in accordance with one or more embodiments of the present invention;
FIG. 5 is a flowchart illustrating a set of operations for processing orders in accordance with various embodiments of the present invention;
FIG. 6 is a sequence diagram illustrating various communications between components of a system supporting order inheritance functionality in accordance with some embodiments of the present invention; and
FIG. 7 illustrates an example of a computer system with which some embodiments of the present invention may be utilized.
In the drawings, some components and/or operations may be separated into different blocks or combined into a single block for the purposes of discussion of some of the embodiments of the present invention. Moreover, while the invention is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the invention to the particular embodiments described. On the contrary, the invention is intended to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.
DETAILED DESCRIPTIONVarious embodiments of the present technology generally relate to financial trading. More specifically, some embodiments relate to systems and methods that allow for a trading firm or an exchange to hand off orders to other traders. Many markets operate on a first-in first-out (“FIFO”) basis as a way to determine which participant gets filled first at a given price. For example, a trader who enters a bid for 50 contracts at a price of 90 at 10:00 a.m. will have priority over another user who places a bid for 50 at a price of 90 at 10:01 a.m. If a seller elects to sell 75 contracts at 90, then the first user will be completely filled (assuming they were the first overall to enter an order) and the second user will only get 25 contracts of their order for 50 (and will now be first in queue for any other transactions at that price). As other users enter bids (or offers) at a price, priority queue position can become extremely important. For example, if a user is filled at a price first, the user has the knowledge and ability to interact with other markets for hedging, speculating, or risk management purposes. Additionally, the user may be the only participant filled at that price, likely achieving an optimal execution.
There may be times when a trader within a firm may decide that he or she no longer desires that bid or offer at that specific price, or may have to leave their desk and cannot leave a resting order in the market without being physically present. This can be a problem with traditional systems, as there is currently no ability for that trader to hand off their order to another trader who could benefit from the position in the queue. In some cases, depending on a given market's or exchange's rules, individuals who trade as a team may be able to control, and therefore trade, another trader's orders if they are on the same team. However, these situations are limited severely by exchange rules and are generally not allowed across different accounts or entities. In contrast, various embodiments provide for systems and methods with the capability of an order inheritance or an order exchange that may not be allowed to cross different accounts and/or entities. As a result, a trader could make their order available for assumption by another trader.
For example, in first-in first-out (FIFO) markets, a trader who has achieved an excellent queue position for a buy or sell order may decide to cancel that order. Some embodiments allow other traders (e.g., within a firm) to request that order. If the first trader cancels the order, the order then goes live in the requesting traders' order book. In some embodiments, an exchange can allow users to bid on the ability to use (i.e., inherit) an order in case that order is cancelled by its initial user. Some embodiments provide various display mechanisms to assist in order request/assignment process.
In accordance with various embodiments, a trader within a proprietary trading firm could place an electronic tag on his soon-to-be-abandoned order, which would then highlight that order to other traders within the firm. Various methodologies could be used to determine how other traders could elect to use that order; first to click on the order, priority given to senior traders, priority given to those with a risk need to hedge, highest payer, etc. Some embodiments allow traders to bid on orders within a certain period of time, including prior to the notification that the order is available. This bidding could consist of a payment per contract with or without execution, fixed payments, profit shares, etc. Regardless of the methodology, the decision process would be determined systematically and various display mechanisms can be used to notify users that an order is available.
In accordance with various embodiments, the marketplace or exchange itself could allow any user to bid on the ability to use an order in the event that order is cancelled by the current “owner.” This mechanism would provide benefits to the exchange and its users, in that a given user may not have to invest in prohibitively expensive co-location or high-speed telecom lines in order to always have queue position. Instead, such users (typically lower frequency users) could selectively pay for queue position on demand. The various methodologies for allocating a given order would be similar to the trading firm example mentioned above.
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details. While, for convenience, embodiments of the present technology are described with reference to financial instruments and exchanges, embodiments of the present technology are equally applicable to various other electronic queue-based technologies where individuals may be willing to pay for a place in the queue. For example, the techniques could be extended to the electronic selling of sporting tickets where season ticket holders might have a queue priority for additional venue or sporting tickets such as playoff games. As another example, high-end luxury automobiles that have limited editions often establish a purchasing priority based on a number of factors (e.g., purchase and/or ownership history). As such, the inheritance platform may be product agnostic and have a variety of product queues which can be maintained by the inheritance platform via a common protocol.
Moreover, the techniques introduced here can be embodied as special-purpose hardware (e.g., circuitry), as programmable circuitry appropriately programmed with software and/or firmware, or as a combination of special-purpose and programmable circuitry. Hence, embodiments may include a machine-readable medium having stored thereon instructions that may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, compact disc read-only memories (CD-ROMs), magneto-optical discs, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), application-specific integrated circuits (ASICs), magnetic or optical cards, flash memory, or other types of media/machine-readable medium suitable for storing electronic instructions.
The following applications are hereby incorporated by reference in their entirety for all purposes: U.S. patent application Ser. No. 13/463,753 entitled “METHODS AND SYSTEMS FOR SHOWING PERSPECTIVE IN MARKET DATA” filed on May 3, 2012, U.S. patent application Ser. No. 13/837,945 entitled “METHODS AND SYSTEM FOR SHOWING PERSPECTIVE IN MARKET DATA” filed on Mar. 15, 2013, and U.S. Patent Application No. 61/909,969 entitled “PROVIDING GUARANTEED EXECUTION OF MARKET SPREADS” filed on Nov. 27, 2013.
TerminologyBrief definitions of terms, abbreviations, and phrases used throughout this application are given below.
The phrases “in some embodiments,” “according to some embodiments,” “in the embodiments shown,” “in other embodiments,” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the present invention, and may be included in more than one implementation. In addition, such phrases do not necessarily refer to the same embodiments or different embodiments.
The term “module” or “engine” refers broadly to general or specific-purpose hardware, software, or firmware (or any combination thereof) components. Modules and engines are typically functional components that can generate useful data or other output using specified input(s). A module or engine may or may not be self-contained. Depending upon implementation-specific or other considerations, the modules or engines may be centralized or functionally distributed. An application program (also called an “application”) may include one or more modules and/or engines, or a module and/or engine can include one or more application programs.
General DescriptionFIG. 1 illustrates an example of a network-based environment in which some embodiments of the present invention may be utilized. The embodiments illustrated inFIG. 1 show user interfaces110A-110N running oncomputing devices120A-120N.Computing devices120A-120N can be any computing device capable of receiving user input as well as transmitting and/or receiving data viatrading platform130.Trading platform130 can connect vianetwork140 to electronic marketplace orfinancial market150 andinventory database160. While only onetrading platform130,network140,electronic marketplace150, andinventory database160 are illustrated inFIG. 1, other embodiments may includemultiple trading platforms130,networks140,electronic marketplaces150, and/orinventory databases160.
In one embodiment,computing device120A-120N may be a conventional computer system (e.g., a desktop or laptop computer), a tablet computer, or a mobile device having computer functionality (e.g., a mobile telephone or a smart-phone).Computing devices120A-120N may be configured to communicate withtrading platform130. In some embodiments,computing devices120A-120N can retrieve or submit information totrading platform130 and run one or more applications for interacting with a user. For example,computing devices120A-120N can execute a browser application or a customized client to enable interaction between thecomputing devices120A-120N andtrading platform130.
Trading platform130 may include one or more servers capable of allowing traders to submit and manage orders (natural or synthetic) with an exchange orelectronic marketplace150. For example, trading platform may allow a trader to submit orders for stocks, options, future contracts, commodity contracts, etc.Trading platform130 can be used to generate, manage, execute, distribute, and/or record trading and/or account data received from various sources (e.g., third-party data providers, financial institutions, etc.) through various interfaces. In some embodiments,trading platform130 can include various data processing and analytic tools allowing users of the trading platform to make better trading decisions.
Trading platform130 may be a third-party service accessed by various financial institutions or individuals. In some cases, a trading firm, individual or unaffiliated users, exchange members, and/or other groups may sign up for the service and submit and manage orders. In other embodiments,trading platform130 may be a private or restricted platform that is owned and operated by an individual (or private) financial institution and only allows access to members of a trading firm or group.Trading platform130 may be a fee for service or provide various membership levels offering different analysis features.Trading platform130, in accordance with one or more embodiments, may allow a trading firm, an exchange, or other user of a marketplace to hand off their orders to other participants or trades, along with different pricing mechanisms (e.g., auction, percentage of total price, fixed fee, pricing tiers based on user groups, pricing based on type of financial instrument, and/or the like) for doing so.
Network140 can include any combination of local area and/or wide area networks using both wired and wireless communication systems. In one embodiment,network140 uses standard communications technologies and/or protocols. Thus,network140 may include links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, CDMA, digital subscriber line (DSL), etc. Similarly, the networking protocols used onnetwork140 may include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), User Datagram Protocol (UDP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP) and file transfer protocol (FTP). Data exchanged overnetwork140 may be represented using technologies and/or formats including hypertext markup language (HTML) or extensible markup language (XML). In addition, all or some links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec).
Inventory database160 can store a variety of information that can be utilized bytrading platform130 and/or electronic marketplace150 (e.g., stock market, bond market, capital market, foreign exchange market, futures market, etc.). For example,inventory database160 may have stored thereon trading and/or account data and information about each user such as, but not limited to, age, contact information, e-mail address, membership level, activity logs, trading logs, and other information. In addition, order information such as, but is not limited to, time received, time executed, identification of a financial product, order identifier, order type, quantity, financial market, restrictions, owner, routing information, current status, and the like may also be stored ininventory database160. According to some embodiments, the some of the data stored ininventory database160 may include various data structures which can be used bytrading platform130,marketplace150, and/or other computer or device. The following is an example of one such a data structure:
|
| Order ID | Order Time | Trader ID | Firm ID | Bid/Ask Price | Quantity | Product |
|
WhileFIG. 1 shows embodiments with a centralized hub collocated with the trading platform for posting, claiming, and processing the order transfers, other embodiments may be based on a peer-to-peer model where there would not be a central hub for the order posting, claiming, and/or processing. For example, in some embodiments, a small group of traders (or private institutions) could agree to interact on their discarded orders directly. Additionally, the traders could leave pre-set instructions on each other's trading systems to automatically hand over orders meeting certain requirements—for example, User A could automatically receive any order in the front month crude oil contract that is more than four ticks off the inside market, with any number of other rules, conditions or economic considerations imposed by the trader to set the automatic transfer. These could be opaque to the order placer, so that the order placer is indifferent when canceling an order and may not even know that the order was automatically assumed by someone in the order placer's peer network. In accordance with various embodiments, the order placer could approve the initial permission for the other user to configure automatic inheritance parameters. Other embodiments may include a hybrid configuration of the central order allocator and a peer-to-peer configuration.
A dynamic element to the order handling (hub, peer, or hybrid structure) may be present in some embodiments. For example, orders further off the market may be held open for claiming for a longer period than those closer to the inside market, and these periods could overall increase/decrease automatically based on market volatility specific to each contract market and/or other factors.
FIG. 2 illustrates various components and interactions in an order inheritance system according to one or more embodiments of the present invention. As illustrated inFIG. 2,user210 can usegraphical user interface220 to interact withtrading platform230 andorder exchange240.User210 can submit an order throughtrading platform230 which submits the order to theorder queue250 for execution onfinancial market260. Once a trade has achieved a queue position, the trader may useGUI220 to indicate that the order is available for inheritance or transfer usingorder exchange240.
In some embodiments, the availability of the order may be created without any interaction from the current owner. For example, when a trader that originally placed the order cancels or modifies the order, the position change may be detected byorder exchange240 and automatically added totrade list270 where other traders may take ownership. Various display indicators may be used to notify other users that the order and queue position are available intrade list270. Once transferred to the new user, the order ownership information can be updated intransfer database280 and inorder queue250. The type of underlying hardware hosting each of the components listed inFIG. 2, may be optimized or selected based on the inherent latencies offinancial market260.
FIG. 3 illustrates various components of atrading platform300 which may be used in accordance with various embodiments of the present invention. According to the embodiments shown inFIG. 3,trading platform300 can includememory305, one ormore processors310,order module315,prioritization module320,offer module325,notification module330,auction module335,pricing module340,transfer module345,accounting module350,tracking module355, and graphical user interface (GUI)generation module360. Other embodiments of the present invention may include some, all, or none of these modules and components along with other modules, applications, and/or components. Still yet, some embodiments may incorporate two or more of these modules and components into a single module and/or associate a portion of the functionality of one or more of these modules with a different module. For example, in one embodiment,transfer module345 andaccounting module350 can be combined into a single module for coordinating and processing payments for order transfers.
Memory305 can be any device, mechanism, or populated data structure used for storing information. In accordance with some embodiments of the present invention,memory305 can encompass any type of, but is not limited to, volatile memory, nonvolatile memory and dynamic memory. For example,memory305 can be any memory noted herein. In accordance with some embodiments,memory305 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memories, processor cache memories, relational databases, flat databases, and/or the like. In addition, those of ordinary skill in the art will appreciate many additional devices and techniques for storing information which can be used asmemory305.
Memory305 may be used to store instructions for running one or more applications or modules on application processor(s)310. For example,memory305 could be used in one or more embodiments to house all or some of the instructions needed to execute the functionality oforder module315,prioritization module320,offer module325,notification module330,auction module335,pricing module340,transfer module345,accounting module350,tracking module355, and/orGUI generation module360. The components may be collocated within or distributed acrosstrading platform130 or electronic marketplace/financial market150.
Order module315 can be configured to receive orders from various trading interfaces (e.g., trading GUIs, algorithmic trading systems, etc.). The orders may be to buy or sell a position, along with all data associated with that position. In other cases, the order may be to transfer the position to a new owner. Still yet, in other cases, the order may be to offer the position for transfer, including, e.g. a price or other consideration to be offered for that position. The order received may include a variety of order information needed by the systems and system components to execute the order. The order information may include, but is not limited to, time received, time executed, identification of a financial product, tag 50 id, order identifier, order type, quantity, financial market, restrictions, owner, routing information, current status, and other information. For example, many exchanges use a tag 50 id to identify the individual operator associated with a particular trade in an order book. As a result, the order may be directly changed within the order book of an exchange. In other embodiments,order module315 may track the ownership without notifying the exchange of the change.
Order module315 can add or remove orders to or from the order queue. Once an order is added to the order queue, processed, or updated (e.g., canceled or transferred) additional order information may be associated with the order and the order information (e.g., metadata fields, logs, etc.) may be updated. For example, when an order is transferred from one owner to another, the owner information may be updated (e.g., by updating a tag 50 id and/or other identification information locally or at an exchange) and logs of all transactions maintained for possible later audit or analysis. In some embodiments, the owner information may identify all prior owners in addition to the current owner. Similarly, the current status may be updated to indicate the position has been transferred. A queue position can be updated based on information from the order queue. Other information may be recorded such as the time of the transfer, price of the transfer, transfer terms (e.g., indicating profit sharing), and others.
Prioritization module320 can be used to determine how to prioritize multiple offers on a transfer that are received throughoffer module325. For example, offers may be prioritized based on a variety of factors, such as, first to click on the order or first to respond (time), priority given to those with a risk needed to be hedged, highest payer, trader seniority, affiliations, account balances, number of trades within a predetermined time period, order type, and/or other factors. Indeed, depending upon various factors such as the business goals of a firm, the prioritization module may implement complex rules to appropriately handle multiple offers.
Notification module330 can be used to generate notifications/indications to other traders. In some embodiments, the notifications may be published in tiers to various traders. For example, the orders may be published first to traders associated within a trading group within a financial institution, then to every trader associated with the financial institution, then to other traders using the trading platform outside of the financial institution, and then broadcast to all traders through the exchange. In some embodiments, time periods (static or dynamic) may be associated with each level of publication before publication to the next level occurs. For example, each level may have a static five minute time period. In this example, the orders could be initially published first to traders associated within a trading group within a financial institution, then five minutes later to every trader associated with the financial institution, then five minutes later to other traders using the trading platform outside of the financial institution, and then broadcast to all traders through the exchange. Dynamic time periods may be adjusted based on a variety of factors including indicia of urgency indicated by the original owner, indications of interest, time till market close, movement in the market, and other factors that could impact the order.
Auction module335 can be used to manage an auction for the order transfers.Pricing module340 can determine a price for the transfer. In accordance with various embodiments, the price may depend on a variety of factors such as order position, order pricing, trader seniority, trader volume, position pricing, trader positions within the queue, affiliations, membership level, interest in the transfer, interest in the underlying financial product, similar orders, exchange rates, and/or other factors. For example, a trader with a higher volume of traders may receive a lower price than a trader with a lower trade volume. As another example, a trader may pay for a transfer membership level that provides a discounted price or provides a fixed pricing structure.
Transfer module345 manages the transfer of ownership from the first owner to the second owner.Transfer module345 can communicate withaccounting module350 to ensure that all fees relating to the transfer are collected. In some embodiments, the transfer pricing may include a fixed portion and/or a variable portion. The variable portion may be related (e.g., a percentage) to a total transaction cost or the profit made by the second owner.Accounting module350 tracks the transaction costs and/or profit made by the second owner and ensures that the fixed portion and/or the variable portion of the pricing structure is properly accounted.
Tracking module355 can be used to create log files that track who an order came from, who the order was transferred to, ultimate resolution of the order (e.g., filled, not filled, cancelled, subsequent transfer, etc.). These logs may be used byaccounting module350 to compute the pricing. In addition, these logs may be used by various reporting, tracking, auditing, and/or compliance systems.Tracking module355 may also monitor order placement and cancellation profiles in an attempt to identify traders that are placing orders without the intent of having them filled. Such a feature may be needed to ensure compliance with various governmental and/or exchange regulations.
For example, detection algorithms applied to the order cancellation and inheritance activity that could determine cancellation rates/percentages, cancellation trends, resting time for orders, etc., so that flags, alerts, or reports could be generated to provide an analysis of a trader's and a firm's order activity. If a trader is canceling orders at a rate greater than those tolerated by exchanges or regulators, or “flashing” orders without the intent to have them filled, then such analytics could alert a firm's compliance personnel so that they could work to mitigate any suspicious activity. The alert, for example, may be sent to compliance software running on a computing device associated with the compliance personnel. The compliance software can be configured to directly access the database and retrieve (automatically or upon request) data stored in database, format the data for analysis by the compliance personnel, and/or provide a recommendation with supporting documentation that the compliance officer can edit. The compliance software, in various embodiments, may present one or more solutions or recommendations, interact with the trading platform to suspend trading or order inheritance privileges, set limits to cancellation frequencies, as well as other features. In some embodiments,tracking module355 may be monitoring activity (e.g., in real or near real-time) and generate signals that cause the trading platform or marketplace to restrict privileges such as trading or inheritance options.
GUI generation module360 can generate one or more GUI screens that allow for interaction with a user of the mobile device. In at least one embodiment,GUI generation module360 generates a graphical user interface allowing a user of the mobile device to set preferences, present reports, and/or otherwise receive or convey information to the user.
FIG. 4 is a flowchart illustrating a set ofoperations400 for processing order transfers in accordance with one or more embodiments of the present invention. The operations illustrated inFIG. 4 can be performed by various systems and components such astrading platform130,electronic marketplace150, processor(s)310,order module315,notification module330,pricing module340,transfer module345,tracking module355, and/or other devices, systems, components, and/or modules. As illustrated inFIG. 4, receivingoperation410 receives a request to publish an order transfer offer so as to transfer an order with a position in an order queue from a first trader to a second trader.
Once received, the order transfer can then be published to one or more other traders inpublishing operation420. In accordance with some embodiments, the trader can select (e.g., through a trading application or graphical user interface) individual traders, groups of traders, and/or all traders to which the order can be published. In other embodiments, a trading platform (or exchange) can select which traders (e.g., groups of traders) will be offered the chance to request the order be transferred to them. For example, the trading platform (or exchange) may use various selection criteria such as, but not limited to, order position, order pricing, trader seniority, trader availability, trader volume, position pricing, trader positions within the queue, affiliations, memberships, and/or other criteria. The selection criteria may be set by the trader, trade group, trading platform, and/or the exchange.
The selected traders may be prioritized in some embodiments and given an amount of time to respond before opening up the offer to additional traders with lower priority levels. In some embodiments, there may be a tiered publishing system where the orders are published to traders within specific tiers before the orders are published to traders in the next lower tier. The price, cost, or fee for transferring the order may be adjusted, in some embodiments, for each tier.
Upon reviewing the published orders, the traders can make a request or offer on the orders. These requests or offers are then received during receivingoperation430. The offers are processed and a second trader is selected as the new owner of the order duringtransfer operation440. In some embodiments, there may be a minimum wait time to receive offers while in other embodiments the orders may be processed on a first come first served basis. An auction may be held (e.g., using auction module335) for the order. The ownership of the order is then recorded duringrecordation operation450.
FIG. 5 is a flowchart illustrating a set ofoperations500 for processing orders in accordance with various embodiments of the present invention. The operations illustrated inFIG. 5 can be performed by various systems and components such as user interface110A-110N,computing devices120A-120N,trading platform130,electronic marketplace150, processor(s)310,order module315,notification module330,transfer module345,tracking module355, and/or other devices, systems, components, and/or modules. As illustrated inFIG. 5,submission operation510 allows a trader to submit an order into a market queue. The order is added to the market queue at a particular position and waits to be executed. In some embodiments,submission operation510 may be automatically performed by a trading system running automated trading algorithms. The automated trading algorithms may also be able to automatically transfer or cancel the order based on detection of various market conditions or trends.
Determination operation520 determines if instructions have been received to transfer or cancel the order. Ifdetermination operation520 determines that no instructions have been received,determination operation520 branches toprocessing operation530 where the order is processed in the market. Ifdetermination operation520 determines that instructions have been received to transfer or cancel the order, thendetermination operation520 branches toinstruction operation540. Ifinstruction operation540 determines that a request to cancel the order has been submitted, theninstruction operation540 branches to canceloperation550 where the order is canceled and removed from the order queue. Ifinstruction operation540 determines that a request to transfer the order has been submitted, theninstruction operation540 branches toownership operation560 where a new owner is determined for the order. Once a new owner has been determinedtransfer operation570 transfers the order to the new owner and the order is processed in the market duringprocessing operation530.
For example, if the inside market of a futures contract traded on an electronic exchange is 98.30 bid, 98.40 offered (0.10 per tick), Trader A may submit a buy order for 100 contracts@97.00 to exchange (13 ticks away from inside market). The exchange receives the order and places the order in order queue at 97.00. Further, assume that at the time of order placement, the order is4th in queue (FIFO method), with the following orders at 97.00 having priority: 25 lot, 25 lot, and 50 lot. After submission of trader A's order, the current state of queue is [25][25][50][100]. As time passes, the 1st 25 lot cancels, as does the 50 lot, and a 30 lot order, a 200 lot order, and a 125 lot order are submitted. As a result, the current state of queue is [25][100 (Trader A's order)][30][200][125].
The inside market descends to 97.20 bid, 97.30 offered. Trader A's order has an increased probability of being filled if the market continues to fall. Trader A becomes busy trading other markets and does not want to focus on this order, and has the option of either cancelling the order which would be deleted from the exchange upon the exchange receiving the cancel message. However, no other trader in the firm could take advantage of trader A's excellent queue position if deleted. Depending on the market, it can be very difficult to get filled due to low volume, low volatility etc. Only a certain number of contracts may trade at each price, so having a queue position that maximizes a trader's ability to get fills is important. As a result, Trader A may elect to notify other traders within the firm (e.g., using IM, popup screen, flashing light at 97.00 on their GUI, etc.) that an order is temporarily available. Traders can then elect to assume that order. As a result, a newly assigned trader assumes the control or ownership of the order. Control or ownership of the order does not mean that the order will be filled or that any other action with respect to the order will be taken. Allocation of the order among multiple traders competing for it could be accomplished by first to respond, seniority, willingness to pay a premium, pro rata, etc.
Various embodiments allow for this order at its existing queue position to become available to other traders within the firm (or outside the firm), providing the other traders with much better queue position (and therefore probability of getting filled) than if they entered a new order at the back of the queue. Assume that the order is allocated to Trader B; Trader B now controls the order and any fills on that order will be sent to Trader B. Trader B now has the option of cancelling the order, waiting for the order to fill, and/or offering the order to other traders.
In some embodiments, the transfer may be controlled at the exchange, instead of residing within a trading firm. In these embodiments, the exchange could utilize the various mechanisms listed above to transfer orders to other market participants. The exchange market structure is best positioned to charge a per-contract fee for assuming an order with optimal queue position. One advantage of the transfer mechanism residing with the exchange is that an exchange-implemented model of this system would decrease the need for some market participants to invest in costly co-location services and other latency-minimizing software and hardware solutions, since the opportunity to assume an existing order mitigates the need to be quickest to a given price.
Some embodiments of the trading platform allow firms to assume various market positions and create an auto hedging position. For example, a house repository may utilize automatic trading algorithms to accept some or all of the available orders and prepare an automatic hedge. If such an order held by the house (before it is claimed by or allocated to a trader or account) is executed and filled, then some embodiments of the system could automatically place a hedging order, based on the firm's analytics or hedging protocols, in order to mitigate that position's risk until the position is unwound or allocated to another trader. An example would be if the house held an order to buy 10-year Treasury futures that was executed, the trading system could automatically execute a sale of the appropriate amount of 10-year Treasury cash bonds (or any number of securities or futures that the firm feels sufficiently hedges their new position) to hedge the futures position.
The techniques disclosed herein may provide a variety of additional technical benefits such as, but not limited to, increasing liquidity within the market. Since traders using embodiments of the present technology can derive an economic benefit from resting orders within the market, the traders are more likely to have actionable orders within an order book. Such availability of orders results in more efficient markets thereby allowing all traders to benefit from the increased liquidity and more efficient pricing. Moreover, electronic trading is executed using complex networks of computing equipment and software. The speed at which the trades are made, positions in the queue allocated and broker accounts reconciled cannot be done by hand, and the coordination required to handle multiple traders across many offices make it impossible for this to be done manually. As a result, the techniques of the various embodiments are significantly more than an abstract ideas as they do not simply implement traditional computer functions, but address specific challenges present in trading technology and are rooted in specific improvements to trading technology.
FIG. 6 is a sequence diagram illustrating various communications between components of a system supporting order inheritance functionality in accordance with some embodiments of the present invention. As illustrated inFIG. 6, a trader places an order using a trading platform. The order is added to the order queue. At some point in time after the order is place, but while the order is still pending in the order queue, the trader publishes that the order is available for transfer. A temporary hold can be placed on the order in the order queue during a transfer period (e.g., less than one minute). A publisher publishes the order availability to other traders. Other traders can request a transfer and a transfer order can be sent to the order queue transferring the order from the original owner to a second owner and releasing the hold. If the order is processed through the electronic market, then the order is removed and an execution confirmation is transmitted from the electronic market to the trading platform.
Exemplary Computer System OverviewAspects and implementations of the order inheritance and transfer system of the disclosure have been described in the general context of various steps and operations. A variety of these steps and operations may be performed by hardware components or may be embodied in computer-executable instructions, which may be used to cause a general-purpose or special-purpose processor (e.g., in a computer, server, or other computing device) programmed with the instructions to perform the steps or operations. For example, the steps or operations may be performed by a combination of hardware, software, and/or firmware.
FIG. 7 is a block diagram illustrating an example machine representing the computer systemization of the order inheritance and transfer system. The order inheritance andtransfer system controller700 may be in communication with entities including one or more users725 (e.g., human and non-human users/traders), client/terminal devices720 (e.g.,devices120A-120N), user input devices705,peripheral devices710, an optional co-processor device(s) (e.g., cryptographic processor devices)715, and networks730 (e.g., network140). Users may engage with thecontroller700 viaterminal devices720 overnetworks730.
Computers may employ central processing unit(s) (CPU) or processor(s) (hereinafter “processor”) to process information. Processors may include programmable general-purpose or special-purpose microprocessors, programmable controllers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), embedded components, combination of such devices and the like. Processors execute program components in response to user and/or system-generated requests. One or more of these components may be implemented in software, hardware or both hardware and software. Processors pass instructions (e.g., operational and data instructions) to enable various operations.
The order inheritance andtransfer controller700 may includeclock765,CPU770, memory such as read only memory (ROM)785 and random access memory (RAM)780 andco-processor775 among others. These controller components may be connected to asystem bus760, and through thesystem bus760 to an interface bus735. Further, user input devices705,peripheral devices710,co-processor devices715, and the like, may be connected through the interface bus735 to thesystem bus760. The interface bus735 may be connected to a number of interface adapters such asprocessor interface740, input output interfaces (I/O)745, network interfaces750, storage interfaces755, and the like.
Processor interface740 may facilitate communication betweenco-processor devices715 andco-processor775. In one implementation,processor interface740 may expedite encryption and decryption of requests or data. Input output interfaces (I/O)745 facilitate communication between user input devices705,peripheral devices710,co-processor devices715, and/or the like and components of thecontroller700 using protocols such as those for handling audio, data, video interface, wireless transceivers, or the like (e.g., Bluetooth, IEEE 1394a-b, serial, universal serial bus (USB), Digital Visual Interface (DVI), 702.11a/b/g/n/x, cellular, etc.). Network interfaces750 may be in communication with thenetwork730. Through thenetwork730, thecontroller700 may be accessible to remote terminal devices720 (e.g., client devices180). Network interfaces750 may use various wired and wireless connection protocols such as, direct connect, Ethernet, wireless connection such as IEEE 702.11a-x, and the like.
Examples ofnetwork730 include the Internet, Local Area Network (LAN), Metropolitan Area Network (MAN), a Wide Area Network (WAN), wireless network (e.g., using Wireless Application Protocol WAP), a secured custom connection, and the like. The network interfaces750 can include a firewall which can, in some embodiments, govern and/or manage permission to access/proxy data in a computer network, and track varying levels of trust between different machines and/or applications. The firewall can be any number of modules having any combination of hardware and/or software components able to enforce a predetermined set of access rights between a particular set of machines and applications, machines and machines, and/or applications and applications, for example, to regulate the flow of traffic and resource sharing between these varying entities. The firewall may additionally manage and/or have access to an access control list which details permissions including, for example, the access and operation rights of an object by an individual, a machine, and/or an application, and the circumstances under which the permission rights stand. Other network security functions performed or included in the functions of the firewall, can be, for example, but are not limited to, intrusion prevention, intrusion detection, next-generation firewall, personal firewall, etc., without deviating from the novel art of this disclosure.
Storage interfaces755 may be in communication with a number of storage devices such asstorage devices790, removable disc devices, and the like. The storage interfaces755 may use various connection protocols such as Serial Advanced Technology Attachment (SATA), IEEE 1394, Ethernet, Universal Serial Bus (USB), and the like.
User input devices705 andperipheral devices710 may be connected to I/O interface745 and potentially other interfaces, buses and/or components. User input devices705 may include card readers, finger print readers, joysticks, keyboards, microphones, mouse, remote controls, retina readers, touch screens, sensors, and/or the like.Peripheral devices710 may include antenna, audio devices (e.g., microphone, speakers, etc.), cameras, external processors, communication devices, radio frequency identifiers (RFIDs), scanners, printers, storage devices, transceivers, and/or the like.Co-processor devices715 may be connected to thecontroller700 through interface bus735, and may include microcontrollers, processors, interfaces or other devices.
Computer executable instructions and data may be stored in memory (e.g., registers, cache memory, random access memory, flash, etc.) which is accessible by processors. These stored instruction codes (e.g., programs) may engage the processor components, motherboard and/or other system components to perform desired operations. Thecontroller700 may employ various forms of memory including on-chip CPU memory (e.g., registers),RAM780,ROM785, andstorage devices790.Storage devices790 may employ any number of tangible, non-transitory storage devices or systems such as fixed or removable magnetic disk drive, an optical drive, solid state memory devices and other processor-readable storage media. Computer-executable instructions stored in the memory may include one or more program modules such as routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. For example, the memory may contain operating system (OS)component795, modules and other components, database tables, and the like. These modules/components may be stored and accessed from the storage devices, including from external storage devices accessible through an interface bus.
The database components can store programs executed by the processor to process the stored data. The database components may be implemented in the form of a database that is relational, scalable and secure. Examples of such database include DB2, MySQL, Oracle, Sybase, and the like. Alternatively, the database may be implemented using various standard data-structures, such as an array, hash, list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in structured files.
The order inheritance andtransfer system controller700 may be implemented in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a Local Area Network (“LAN”), Wide Area Network (“WAN”), the Internet, and the like. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. Distributed computing may be employed to load balance and/or aggregate resources for processing. Alternatively, aspects of thecontroller700 may be distributed electronically over the Internet or over other networks (including wireless networks). Those skilled in the relevant art will recognize that portions of the order inheritance and transfer system may reside on a server computer, while corresponding portions reside on a client computer. Data structures and transmission of data particular to aspects of the order inheritance andtransfer controller700 are also encompassed within the scope of the invention.
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to.” As used herein, the terms “connected,” “coupled,” or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof. Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word “or,” in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.
The above Detailed Description of examples of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific examples for the invention are described above for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative implementations may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or sub-combinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel, or may be performed at different times. Furthermore, any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges.
The teachings of the invention provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various examples described above can be combined to provide further implementations of the invention. Some alternative implementations of the invention may include not only additional elements to those implementations noted above, but also may include fewer elements.
These and other changes can be made to the invention in light of the above Detailed Description. While the above description describes certain examples of the invention, and describes the best mode contemplated, no matter how detailed the above appears in text, the invention can be practiced in many ways. Details of the system may vary considerably in its specific implementation, while still being encompassed by the invention disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the invention should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the invention with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the invention to the specific examples disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the invention encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the invention under the claims.
To reduce the number of claims, certain aspects of the invention are presented below in certain claim forms, but the applicant contemplates the various aspects of the invention in any number of claim forms. For example, while only one aspect of the invention is recited as a computer-readable medium claim, other aspects may likewise be embodied as a computer-readable medium claim, or in other forms, such as being embodied in a means-plus-function claim. Any claims intended to be treated under 35 U.S.C. § 112(f) will begin with the words “means for”, but use of the term “for” in any other context is not intended to invoke treatment under35 U.S.C. §112(f). Accordingly, the applicant reserves the right to pursue additional claims after filing this application to pursue such additional claim forms, in either this application or in a continuing application.