JP6184659B2 - Multicomputer distributed processing method to avoid information leakage - Google Patents

Description

Cross-reference of related applications

  The following chapters I to X provide guidance for interpreting the present application.

I. The term “product” means any machine, product, and / or composition of matter, unless otherwise specified.

  The term “process” means any process, algorithm, method, or the like, unless otherwise specified.

  Each process (whether method, algorithm, or other name) inherently includes one or more steps, so all references to “steps” or “multiple steps” of a process are essential. Have the preceding description in the mere description of the term “process” or like terms. Accordingly, any reference to “a step” or “a plurality of steps” of a process in the claims has a sufficient preceding description.

  The term “invention” and like terms mean “one or more inventions disclosed in this application”, unless expressly stated otherwise.

  The terms “an embodiment, embodiment, embodiments, the embodiment, the emblems”, “one or more embodiments”, “some embodiments”, “a particular embodiment,“ one embodiment ” “Another embodiment” or the like, unless stated otherwise, means “one, but not all, of the disclosed invention (s).

  The term “variation” of an invention means an embodiment of the invention, unless expressly specified otherwise.

  Reference to “another embodiment” in describing an embodiment is such that the embodiment referred to is mutually exclusive with another embodiment (eg, the embodiment described before the embodiment referred to). Does not suggest that there is.

  The terms “including”, “comprising”, and variations thereof mean “including but not limited to”, unless expressly specified otherwise.

  The terms “a”, “an”, and “the” mean “one or more” unless stated otherwise.

  The term “plurality” means “two or more”, unless expressly specified otherwise.

  The term “herein” means “in this application, including anything that may be incorporated by reference”, unless expressly specified otherwise.

  The phrase “at least one of” means that when modifying a plurality of things (such as an enumerated list of things), unless otherwise specified, any combination of one or more of those things. For example, the phrase “at least one of a widget, a car, and a vehicle” includes (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car, (v) a widget and a wheel, (vi ) Means either car and wheel, or (vii) widget, car and wheel. The phrase “at least one of” does not mean “one each” of the plurality of things when modifying the plurality of things.

  A number such as “one”, “two”, etc., when used as a radix indicating some quantity (eg, one widget, two widgets) means the quantity indicated by that number, but at least It does not mean the quantity indicated by the number. For example, the phrase “one widget” does not mean “at least one widget”, and thus the phrase “one widget” does not imply, for example, two widgets.

  The phrase “based on” does not mean “based only on,” unless expressly specified otherwise. In other words, the phrase “based on” describes both “based only on” and “based at least on.” The phrase “based at least on” is equivalent to the phrase “based at least in part on”.

  The terms “represent” and like terms are not exclusive, unless expressly specified otherwise. For example, the term “represents” does not mean “represents only”, unless expressly specified otherwise. In other words, the phrase “data represents a credit card number” describes both “data represents only a credit card number” and “data represents a credit card number and represents something else”.

  The term “accordingly” is used herein only in front of a phrase or collection of other words that express only the intended result, purpose, or consequence of something already specified. Thus, when the term “accordingly” is used in a claim, the clause or other words that the term “accordingly” modifies does not establish certain further limitations of the claim, or the claim Does not limit the meaning or scope of the terms in any other manner.

  The term “eg (eg)” and like terms means “for example” and thus does not limit the term or phrase being described. For example, in the sentence “the computer sends data (eg (eg), instructions, data structure) via the Internet”, the term “eg (eg)” means that the “command” It is described that “data” is an example of “data” that can be transmitted via the Internet, and that “data structure” is an example of “data” that can be transmitted by the computer via the Internet. However, both “instructions” and “data structures” are merely examples of “data”, and anything other than “instructions” and “data structures” can also be “data”.

  The terms “respectively” and like terms mean “interpreted individually”. Thus, if two or more things have “respective” characteristics, each such thing has its own characteristics, which may be different from each other, but are necessarily required to be different from each other. Not a translation. For example, the phrase “each of two machines has a respective function” means that a first such machine has a function, and a second such machine has a function as well. The function of the first machine may or may not be the same as the function of the second machine.

  The term “i.e.” and like terms mean “that is” and thus does not limit the term or phrase being described. For example, in the sentence “the computer sends data (ie (ie), instructions) over the Internet”, the term “ie (ie)” means that the “instructions” The “data” to be transmitted will be described.

  Any given numerical range should include integers and decimals within that range. For example, the range “1-10” is particularly an integer of 1-10 (eg, 1, 2, 3, 4,..., 9) and a non-integer (eg, 1.1, 1.2,... 1.9).

  When two or more terms or phrases are synonymous (for example, because a term or phrase is specified as synonymous), one such term / phrase instance is distinct from another such term / phrase Doesn't mean you have to have a meaning. For example, if a sentence indicates that the meaning of "includes" is synonymous with "includes but is not limited to it", simply using the phrase "including but not limited to" The term “including” is not meant to mean anything other than “including but not limited to”.

  The terms “promoting” and like terms may include any action or set of actions that help produce a result. Examples of facilitation may be given throughout this disclosure. Such examples should be construed as non-limiting examples only.

  It should be understood that the order inquiry, when interpreted by the computer module, includes information identifying the order for which trade-related operations are desired. Such information can be interpreted by the computer module to query stored information, such as a stored order information database.

  An inquiry should be understood to include a form of information that can determine a question.

  A computer module should be understood to include any combination of hardware and / or software.

  A firm order is understood to include an order for a financial instrument in which the system fulfills a transaction with a matched order without additional intervening authorization from the buyer of the firm order.

  Financial instruments include debt or asset ownership products, and any derivatives thereof, such as common stocks, stocks, fixed income, bonds, bonds, certificates of interest or deposits, warrants, options, futures, It should be understood to include forwards, swaps, or generally any securities.

  Although some embodiments are described with reference to an order management system understood in the art, it is to be understood that other embodiments may include an order information system. An order information management system should be understood as any system in which information about orders for buying financial products and / or orders for selling financial products is stored, including, for example, order management systems.

  Two things should be understood to match if they share one or more attributes. The exact attributes that are shared may differ in various embodiments. Examples of some attributes include the type of financial product (for example, industry, total stock, risk, etc.), a security identifier (for example, stock symbol), stock amount, price, and the like.

  The representation of things includes any instructions that can derive part of the underlying things.

  Allowing is understood to encompass allowing the operation to be performed. An action provides / activates a mechanism (eg, a button or other control device), for example, that can perform the action (eg, by clicking on a button or activating another control device in another manner) Can be made possible.

  Legally binding acceptance of an order will not allow further intervention in the performance of the transaction and cannot be revoked (for example, accepting can never be revoked, accepting without penalty may be revoked) Not), it should be understood to include accepting transactions that satisfy at least part of the order.

  It should be understood that accepting an order includes an agreement to participate in a transaction that satisfies at least a portion of the order.

  Evidence concealment should be understood to include trying to prevent an order from revealing evidence. Confidential evidence of a situation or action does not disseminate information about that situation or action, disseminates false or misleading information about that situation or action, and obscures the dissemination of information about that situation or action In order to disseminate erroneous or misleading information at some time, and / or any other desired action.

  It should be understood that facilitating transaction performance includes performing any actions that help to realize transaction performance. An action may include, for example, actual fulfillment of a transaction, sending a trade fulfillment request, sending any information useful for realizing the trade, and / or any other action.

  It should be understood that the market includes a platform on which at least the following operations are performed: promotion of order fulfillment, acceptance of order instructions, sorting of matches to orders.

  It should be understood that applying a filter to a set of things includes generating a subset of the set of things where each thing has one or more desired properties.

  A transaction is understood to be a fulfillment part of an order for one or more things if the transaction involves a transfer of ownership of at least a portion of the one or more things according to the order. Implementation can include performing a transaction.

  Participating systems should be understood to include any system that allows the order management system to interface with the market.

II. Determining
“Determining” and its grammatical variants (eg “determine price”, “determine value”, “determine what meets certain criteria”) are used in a very broad sense. The The term “determination” encompasses a wide range of actions, and thus “determination” includes calculation, calculation, processing, derivation, examination, reference (eg, reference to a table, database or other data structure), confirmation, etc. obtain. “Determining” can also include receiving (eg, receiving information), accessing (eg, accessing data in a memory) and the like. Further, “determining” may include resolving, selecting, selecting, establishing and the like.

  The term “decision” does not imply certainty or absolute accuracy, and thus “determination” may include estimation, extrapolation, prediction, inference, and the like.

  The term “decision” does not imply that mathematical processing must be performed, it does not imply that numerical methods must be used, but suggests that an algorithm or process is used is not.

  The term “determining” does not imply that a particular device must be used. For example, the computer does not necessarily have to make a decision.

III. Sentence Form A limitation of the first claim encompasses one feature and more than one feature (eg, a limitation such as “at least one widget” encompasses one widget and more than one widget) ), In a second claim subordinate to the first claim, where the second claim represents a limitation using the definite article “the” (eg, “the widget”). ), Which does not imply that the first claim encompasses only one feature, and does not imply that the second claim encompasses only one feature ( For example, “the widget” may include one widget and two or more widgets).

  When an ordinal number ("first", "second", "third", etc.) is used as an adjective before a term, the ordinal number is the same or similar term (unless otherwise stated) It is only used to indicate a particular feature, such as to distinguish another feature that is described from that particular feature. For example, a “first widget” may only be so named to distinguish it from, for example, a “second widget”. Thus, simply using the ordinal numbers “first” and “second” before the term “widget” does not indicate any relationship between the two widgets, and similarly, for one or both widgets. It does not show any characteristics. For example, simply using the ordinal numbers "first" and "second" before the term "widget" indicates (1) whether the widget comes before or after others in order and place Rather, (2) does not indicate that a widget will occur or operate over time, before or after another, and (3) any widget ranks above or below others in importance or quality It does not indicate that it is attached. Furthermore, simply using ordinal numbers does not define numerical limits on features identified by ordinal numbers. For example, simply using the ordinal numbers “first” and “second” before the term “widget” does not indicate that there must be no more than two widgets.

  Where a single device, article, or other product is described herein, alternatively, two or more devices / things (whether or not they work together) Can be used instead of device / object. Thus, a function described as possessed by a device may alternatively be possessed by more than one device / thing (whether or not they cooperate).

  Similarly, where two or more devices, objects, or other products are described herein (whether or not they work together), alternatively, a single device / object is described. It can be used in place of two or more devices or objects. For example, multiple computer-based devices may be replaced with a single computer-based device. Accordingly, various functions described as possessed by two or more devices or objects may alternatively be retained by a single device / object.

  The functions and / or features of a single device described may alternatively be embodied by one or more other devices that have been described but are not explicitly described as having such functions / features. May be. Thus, other embodiments need not include the described device itself, but rather may include one or more other devices having such functionality / features in those other embodiments.

IV. The examples and terms disclosed are non-limiting names (which appear at the beginning of the first page of the application) and abstracts (which appear at the end of the application) in no way limit the scope of the disclosed invention Shall not be construed as A summary of less than 150 words is a 37C. F. R. Since it is required by §1.72 (b), it is only included in the present application.

  The name of this application and the section headings provided herein are for convenience only and are not to be construed as limiting the disclosure in any way.

  Many embodiments have been described herein and these embodiments are presented for purposes of illustration only. The described embodiments are not limiting in any way and are not intended to be limiting. The invention disclosed in the present application is widely applicable to many embodiments as can be easily understood from the present disclosure. Those skilled in the art will recognize that the disclosed invention can be practiced with various changes and modifications, such as structural changes, logical changes, software changes, electrical changes, and the like. Certain features of the disclosed invention may be described with reference to one or more specific embodiments and / or drawings, but such features are described with reference to, unless expressly stated otherwise. It is not limited to use with one or more particular embodiments or accompanying drawings.

  None of the method steps or product element embodiments described in this application constitute or constitute the claimed invention, unless explicitly stated in this specification or the claims. It is not essential to the invention described in the above, or does not have the same spread as the invention described in the claims.

  The preamble of a claim merely describes the purpose, benefit and possible use of the claimed invention and does not limit the claimed invention.

  This disclosure is not a complete description of all embodiments of the invention. This disclosure is also not a list of features of the invention that must be present in all embodiments.

  Devices that are described as communicating with each other do not necessarily have to communicate with each other unless otherwise specified. Conversely, such devices need only transmit to each other as needed or desired, and may actually refrain from exchanging data for most of the time. For example, a machine that communicates with another machine over the Internet may not send data to the other machine for an extended period of time (eg, several weeks at a time). Furthermore, devices that communicate with each other may communicate directly or indirectly via one or more intermediates.

  The description of embodiments having several components or features does not imply that all or any such components / features are required. Conversely, various optional components are described to illustrate a wide range of possible embodiments of the invention. Unless otherwise stated, the components / features are not essential or required.

  Although process steps or algorithms may be described in the specification or the claims in a specific order, such processes may be configured to be performed in a different order. In other words, any order or order of steps that may be explicitly set forth in the specification or claims does not necessarily indicate a requirement that the steps be performed in that order. The process steps described herein may be performed in any order possible. Further, some steps may be performed simultaneously, even though they are described or suggested as not being performed at the same time (eg, because one step is described after the other step). Further, the illustrated process illustrated in the accompanying drawings does not suggest that the illustrated process excludes other variations and modifications thereto, and that the illustrated process or any of its steps is required for the present invention. Does not suggest that the illustrated process is preferred.

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

  Although the process may be described alone, i.e. without reference to other products or methods, in embodiments, the process may interact with other products or methods. For example, such an interaction may include linking one business model to another business model. Such interactions can be provided to improve process flexibility or desirability.

  A product may be described as including a plurality of components, aspects, qualities, characteristics, and / or features, whether any or all of the plurality is preferred, essential, or It does not indicate that it is necessary. Various other embodiments within the scope of the described invention (s) include other products that omit some or all of what is described as multiple.

  An enumerated list of items (which may or may not be numbered) does not imply that any or all items are mutually exclusive unless specified otherwise. Similarly, an enumerated list of items (which may or may not be numbered) does not imply that any or all items include any category, unless explicitly stated otherwise. For example, an enumerated list of “computer, laptop, PDA” does not imply that any or all of the three items in the list are mutually exclusive, and any of the three items in the list Or does not suggest that all items encompass any category.

  An enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are equivalent to each other or can easily be substituted for each other.

  All embodiments are exemplary and do not imply that the invention or any embodiment was made or practiced.

V. Calculations 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 computing devices. One or more such computers or computing devices may be referred to as a computer system. FIG. 1 shows an example of a computer system. The computer system includes a plurality of server computers 101 and client computers 103. Typically, the processor 105 (eg, one or more microprocessors, one or more microcontrollers, one or more digital signal processors) receives instructions (eg, from the memory 107 or similar device) These instructions are executed, thereby executing one or more processes defined by these instructions. The instructions may be embodied in, for example, one or more computer programs and one or more scripts.

  “Processor” refers to one or more microprocessors regardless of architecture (eg, chip level multiprocessing / multicore, RISC, CISC, microprocessors in which pipeline stages do not interlock, pipeline configuration, simultaneous multithreading) Mean central processing unit (CPU), computing device, microcontroller, digital signal processor, or similar device, or any combination thereof.

  Thus, the description of the process is also a description of the device that performs the process. An apparatus that performs the process may include, for example, a processor, input device, and output device suitable for performing the process.

  In addition, programs that implement such methods (as well as other forms of data) may be stored and transmitted in a number of ways using various media (eg, computer readable media). In some embodiments, wiring circuitry or custom hardware may be used in place of or in combination with some or all of the software instructions that can perform the processes of the various embodiments. Thus, various combinations of hardware and software can be used in place of software alone.

  The term “computer-readable medium” refers to any medium, multiple media, or a combination of different media involved in providing data (eg, instructions, data structures) that can be read by a computer, processor, or similar device. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, an optical or magnetic disk 109 and other permanent memory. As the volatile medium, there is usually a dynamic random access memory (DRAM) 111 constituting the main memory. Transmission media include coaxial cables, copper wire, and optical fiber, including the wires that make up the system bus coupled to the processor. Transmission media can 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, a computer readable floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, DVD, any other optical medium, punch Cards, paper tapes, any other physical medium with a hole pattern, RAM, PROM, EPROM, flash EEPROM, any other memory chip or cartridge, carrier wave described below, or any other medium.

  Various forms of computer readable media may be involved in carrying data (eg, instruction sequences) to the processor. For example, data is (i) sent from RAM to a processor, (ii) carried via a wireless transmission medium, (iii) Ethernet (or IEEE 802.3), SAP, ATP, Bluetooth (trademark), TCP / IP , Format and / or transmit in many formats, standards or protocols such as TDMA, CDMA and 3G, and / or (iv) encrypt in any of a variety of ways well known in the art to ensure privacy Or deter fraud.

  Accordingly, the process description is also a description of a computer-readable medium that stores a program that performs the process. The computer readable medium can store program elements suitable for performing the method (in any suitable form).

  Just as the description of the various steps in the process does not indicate that all the steps described are necessary, the apparatus embodiment may include some (but not all) of the described processes. Including a computer / computing device operable to perform

  Similarly, an embodiment of a computer readable medium storing a program or data structure has been implemented, as well as an explanation of the various steps in the process does not indicate that all described steps are necessary. In some cases, including a computer-readable medium that stores a program capable of causing a processor to perform some (but not necessarily all) of the described processes.

  The computer system may also include one or more input / output devices 113. Such input / output devices may include monitors, keyboards, mice, and any other desired device.

  Some computer systems may include a transmission medium 115, which may be referred to as a communication network, that combines the various internal components of the computer system. Such a communication network may also be referred to as a computer bus in some embodiments. Some computer systems may include a dedicated input / output device 117 that is configured to connect to an external communication network. Such a device may be referred to as a network interface. The external communication network may include a LAN 119 and / or the Internet 121. In some implementations, the edge routing device 123 may operate between the LAN and another network such as the Internet 121. Such a device may include a firewall and / or any other desired security mechanism.

  When a database is described, one of ordinary skill in the art (i) can easily utilize alternative database structures to those described, and (ii) can readily utilize other memory structures other than the database. Will understand. Any example or description of any example database described herein is an example configuration of stored information representations. For example, any number of other configurations other than those suggested by the tables illustrated in the drawings or elsewhere may be utilized. Similarly, any illustrated entry in the database represents exemplary information only. Those skilled in the art will appreciate that the number and content of entries may differ from those described herein. In addition, despite the database being described as a table, other formats (relational databases, object-based models, and / or distributed databases) may be used to store and manipulate the data types described herein. Can also be used. Similarly, various processes as described herein can be implemented using database object techniques or behaviors. Further, the database may be stored in a known manner, either locally or remotely on a device that accesses data in such a database.

  Various embodiments can be configured to operate in a network environment including a computer that communicates (eg, via a communication network) with one or more devices. The computer may be any wired or wireless medium (eg, Internet, LAN, WAN, or Ethernet, token ring, telephone line, cable line, wireless channel, optical communication line, commercial online service provider, bulletin board system, satellite communication link, Any or a combination of these may be communicated directly or indirectly. Each device itself may comprise a computer or other computing device configured to communicate with the computer, such as those based on Intel®, Pentium®, Core, or Centrino ™ processors. Any number and type of devices can communicate with the computer.

  In an embodiment, a server computer or central authority may not be necessary or desirable. For example, the present invention may be implemented in one or more devices without central authority in embodiments. In such embodiments, any function described herein as being performed by a server computer or data described as being stored on a server computer may alternatively be one or more of such Can be executed by or stored on such devices.

  Where a process is described, in an embodiment, the process may operate without any user intervention. In another embodiment, the process includes some human intervention (eg, steps are performed with or with human assistance).

VI. Continuation Application This disclosure provides those skilled in the art with a description that allows several embodiments and / or inventions to be practiced. Some of these embodiments and / or inventions may not be described in the claims of this application, but nevertheless one or more that claim the benefit of priority of this application. In the claims of the continuation application.

  Applicants intend to file additional applications to further patent their subject matter, which is not disclosed in the claims of this application but is disclosed and enabled.

VII. 35U. S. C. § 112 (6)
In the claims, a limitation of a claim that includes the term “means for” or the term “step for” is 35U. S. C. §112 (6) means that the limitation applies.

  In the claims, a claim limitation that does not include the term “means” or the term “step” means that the limitation describes a function that does not describe a structure, material, or operation to perform the function. Regardless of 35U. S. C. §112 (6) means that the limitation does not apply. For example, in the claims, simply using a “step” with reference to one or more steps of the claim or one or more steps of another claim, 35U. S. C. §112 (6) does not mean that step corresponds to that step.

  35U. S. C. For means or steps to perform a particular function in accordance with §112 (6), the corresponding structure, material, or operation described herein, and equivalents thereof, perform additional functions as well as specified functions. obtain.

  Computers, processors, computing devices, and similar products are structures that can perform a wide range of functions. Such a product is operable to perform a specified function by executing one or more programs, such as a memory device within the product or a program stored in a memory device accessed by the product. Can be. Unless otherwise specified, such a program need not be based on any particular algorithm, such as any particular algorithm that may be disclosed in the present application. The specified function can be performed through different algorithms, and which one of several different algorithms is only a design choice for performing the specified function, It is well known to those skilled in the art.

  Therefore, 35U. S. C. With respect to means or steps for performing a specified function in accordance with §112 (6), the structure corresponding to the specified function includes any product programmed to perform the specified function. Such a structure may depend on either (i) the disclosed algorithm for performing the function, (ii) an algorithm similar to the disclosed algorithm, or (iii) a different algorithm for performing the function. Includes programmed products that perform functions regardless of whether they are programmed.

  When a means for performing a function that is a method is described, one structure for performing the method includes a computing device (eg, a general purpose computer) programmed and / or configured with hardware suitable for performing the function. .

  Also included is a computing device (eg, a general purpose computer) programmed and / or configured with appropriate hardware to perform its functions via other algorithms as understood by those skilled in the art.

VIII. Disclaimers Multiple references to a particular embodiment do not indicate additional different embodiments of the disclaimer or disclaimer, and similarly, a reference to a description of an embodiment that includes all the particular features refers to that particular feature. It does not indicate a disclaimer or a denial of an embodiment not included. Apparent disclaimers or denials in this application shall be preceded by the phrase “does not include” or the phrase “cannot execute”.

IX. INCORPORATION BY REFERENCE Any patents, patent applications, or other documents referenced herein are hereby incorporated by reference as part of this disclosure, but are described in 35U. S. C. § 112 (1) description requirements and 35U. S. C. This is only for enablement requirements according to §112 (1) and should not be used to limit, define, or otherwise interpret the terms of this application in any way, If not, it will certainly provide a certain meaning, but rather it will be possible to provide a certain meaning for such terms. Accordingly, those skilled in the art need in no way be limited by any embodiment provided in the reference.

  Any incorporation by reference in its own right is support for any reference, opinion, claim or characterization contained in any incorporated patent, patent application, or other document, unless expressly stated otherwise in this patent application, Does not suggest approval or acquiescence.

X. In the course of interpreting this application (including claims), other patent applications that share the priority claim of this application may or may not exist, regardless of whether there are other patent applications recognized as being relevant to this application. Regardless of whether they exist, one skilled in the art will refer to the application history of the present application, but not the application history of other patents or patent applications.

1 shows an example of a computer system. 1 illustrates an example trading system configured to execute one or more trades. FIG. 4 illustrates an example of a process that may be performed by one or more trading systems. Fig. 4 illustrates an example of a process that may be performed by a trading system participant. Figure 3 shows an example of a process that can be used to query a participant. Fig. 4 illustrates an example of a process that can be used in answering a query. Fig. 4 shows an example of a process that can be used for order entry. An example of an order input interface is shown. FIG. 6 illustrates an example of a process that may be used to present order inquiry information. An example of the interface for presenting order inquiry information is shown. FIG. 4 illustrates an example of a process that may be used in some embodiments involving non-firm orders. 1 illustrates an example of a system that includes an alternative trading system. FIG. 6 illustrates an example of a process that includes an order from an alternative trading system. Fig. 4 illustrates an example of a process that may be performed by an alternative trading system. 1 illustrates an example of a trading system that may be used in some embodiments. 2 illustrates an example of a process that may be performed in some embodiments. 1 is a high-level block diagram illustrating an electronic trading market (ETM) environment according to an embodiment of the invention. FIG. It is a high-level block diagram showing more details of ETM. FIG. 16 is a low-level block diagram illustrating a trading system as shown in FIG. FIG. 4 illustrates a data record stored in an order management system (OMS) database to identify an order according to one embodiment of the invention. Preferably, it is a diagram illustrating an order record stored in the OMS database to indicate an order to a particular venue. FIG. 5 is a diagram illustrating a fulfillment record that is preferably stored in the OMS database to indicate fulfillment of an order. 6 is a flow diagram illustrating operations performed by an embodiment of the present invention when a trader logs on to an ETM. 6 is a flow diagram illustrating operations performed by an embodiment of the present invention after a trader logs on to an ETM. 4 is a flow diagram illustrating operations performed by a preferred embodiment of the present invention when an OMS database is updated in response to transaction fulfillment by an ETM. 1 is a schematic diagram illustrating a preferred embodiment of the present invention. FIG. 2 is a schematic diagram illustrating a preferred system for focusing and disseminating confidential information regarding transaction motivation. FIG. 6 is a flow chart illustrating the steps of a preferred method for disseminating confidential information regarding a willingness to trade. FIG. 6 is a flow chart illustrating the steps of a preferred system for matching a will identified by targeted distribution in fulfilling an auction.

XI. Example Embodiment Information about orders for goods or services may be tracked by an order management system (OMS). The order management system may include data about desired orders, intended orders, deferred orders, completed orders, reviewed orders, ongoing orders, and / or other orders. One typical order management system used for securities trading is the Fidessa order management system. While this order management system and the following embodiments are largely focused on trading securities (eg, stocks, bonds, futures, options, derivatives, etc.), other embodiments are tangible (eg, food, oil, (Collectables, etc.) or intangibles (intellectual property rights, fulfillment of contracts, etc.), it should be appreciated that it can be used in combination with any product and / or service transaction.

  The information stored by the OMS includes (for example, the OMS user, the client of the OMS user, etc.) the desired specific security, the desired security type or classification, the desired security quantity or range amount, The desired price to be used for buying, the price range, and / or the pricing method, the limit to the desired price associated with the limit order for the security, the security to be sold, the price to be used to sell the security, the price range, and / or Or pricing methods, securities desired or available for sale (eg, long-term sell and / or short-term sell), amount of securities to sell, conditional buy and / or sell information (eg, some conditional event occurs Information that identifies a purchase to be made, information that sets the amount based on the contingent price, etc.), and / or any other information.

  The pricing policy can include any desired pricing policy supported by the trading system. In some embodiments, such a pricing policy may be, for example, a midpoint pricing where the price is based on the midpoint between the best sell price and the best buy price, a limited price that cannot exceed the highest price level or the lowest price level. In other words, midpoint pricing may include such restrictions, volume pricing, volume weighted average pricing on which the price is based on the weighted average price during the transaction period. Any other method or combination of pricing policies may be used.

  Market liquidity, a measure of the ability to easily buy and / or sell securities through the market, is recognized as a factor that can affect the price at which securities are traded. For example, it may have a more difficult time to sell less liquid securities, as prospective buyers may fear that they cannot sell the securities again after purchase. Such fears help reduce the fear of such prospective buyers by unnaturally reducing the selling price of the security from the true market value of the security. Accordingly, a more liquid market may promote securities trading at a fair market price, or securities trading at a price closer to a fair market price than trading in a less liquid market.

  Depending on the market, order identification information (eg bids, offers, etc.) that is stored in the order management system or otherwise stored internally by the trading organization or trader is traditionally provided to the market. Not considered as sex. Rather, such orders are usually published to the market and are added to the liquidity of those markets only if other traders in the market can operate on those orders. Such secret orders remain invisible to such markets and can be referred to as liquid “dark pools” or “dark books”.

  By enabling the fulfillment of transactions using such orders, the liquidity of the market is improved, so that more transactions can be executed through the market and / or prices close to fair market value or It is recognized that transactions can be executed with fair market value.

  One issue that may be associated with using such orders in the market is the presence of secret orders, the associated information affects the market and / or information (eg, any insights, knowledge, trading algorithms) It is recognized that it includes a potential that can be used to reduce the benefits attributed to the originator of the In a typical market, if bids and offers match, negotiations can take place between buyers and sellers before closing any trades. Such negotiations typically involve exposing the existence of a matching counterparty, information about the matching order associated with the matching party, and / or the identity of the matching party to both parties involved in the negotiation. By exposing this information, the potential for “manipulating the market” (eg, artificially affecting the market using knowledge of the presence of other people's orders) is increased and embodied by the order. Secret knowledge can be published where possible. For example, a trader may terminate the negotiation by rejecting the order being negotiated. The trader then proceeds to enter the price of the security by entering one or more other orders at a higher or lower price using the knowledge that the matching party is willing to trade in relation to the security. And / or the knowledge embodied by the order can be used to adjust the trading strategy in other ways.

  It will be appreciated that as the size of an order increases, the traders associated with such orders may reduce the opportunity to manipulate the market. Thus, it will be appreciated that large units of liquidity trading can reduce the probability that an operation will occur. Reduces the chance that a trader will attempt to manipulate the market if the trader agrees to fulfill the order without negotiation, without receiving notification prior to fulfillment and / or automatically in other ways It is also permitted to do. Furthermore, it is also recognized that opportunities to manipulate the market are reduced if the trading partner's anonymity is maintained in part or all of the trading exchange. Thus, securities market participants (such as buyer and / or seller participants) may have a higher willingness to participate in a market with one or more such characteristics. Furthermore, such participants may have a stronger will by allowing orders that exist in the OMS to add liquidity to such markets. In markets with such characteristics, for example, large units of securities can be moved relatively quickly compared to traditional trading mechanisms.

  In some markets such as typical securities markets, it is recognized that participants exist in an asymmetric relationship. For example, participants known as selling firms in the securities market generally operate as retail brokers and investor researchers. Participants, known as buying firms within the securities market, generally include investment organizations that tend to buy and / or sell large amounts of securities for money management purposes and keep information about trading intentions secret. Therefore, the desires of these participants may not be the same. Some embodiments may be configured to treat participants with different characteristics in different ways in an attempt to balance the desires of different participants.

  Some embodiments of a trading system may allow access to what may be a liquidity pool (eg, an order in an OMS system) that is not conventionally utilized. Such a system may provide an asymmetric access record to such information to accommodate market participants' wishes and / or preferences. Such systems may include anonymous policies, order size restrictions, incentives, filtering policies, and / or automatic fulfillment of multiple types of orders to encourage participation.

  Some embodiments may read information from an OMS or other order source associated with a buyer market participant. Information about such orders is used to match information from other market participants in the presence of one or more elements of anonymity, automatic order fulfillment, and / or order size policy enforcement Can do. In some embodiments, the information may be narrowcast to potential counterparties that match the orders associated with these parties' OMS. Thus, market participants, such as seller and buyer participants, are committed to adding liquidity to the market with some privacy and / or security that the market is not manipulated by other participants. Orders that are both orders and OMS orders can be submitted. Participants may include people and / or machines engaged in trading in some way with the market. Participants may include an OMS, a computer that interfaces with the OMS, and / or any other type of computer or transaction-related device.

  In some embodiments, a firm order (ie, an order for which a participant has agreed to fulfill an automatic order with a matching order) may be displayed anonymously to those who are less likely to misuse the information. And / or may not be displayed to anyone. In some implementations, such a participant selects a buyer participant who can view information about the firm order if a matching order exists in the OMS associated with each buyer participant. May be included. In some implementations, such participants may include participants with matching firm orders (eg, submitted to a trading system). Limiting the viewing of such information may facilitate high quality unit liquidity transactions using liquidity pools that are not currently provided.

  In some embodiments, control over one or more aspects of disclosing information about an order at the OMS may exist at the purchaser of the order. In some embodiments, a selling participant or other buyer participant who has entered a firm order that matches the order in the buyer participant's OMS has that buyer participant with the order in the OMS. If you agree to the notification and / or agree to fulfill the transaction, you may only be notified of the existence of such a matching order. In some embodiments, the selling participant or other buyer participant is not notified of the buyer participant's identity at all, but rather any matching order is found and / or fulfilled. Only that can be notified.

Example Structure FIG. 2 shows an example of a trading system configured to fulfill one or more transactions. As shown, the trading system may include multiple computer systems at one or more locations. The illustrated embodiment includes a central system with multiple remote computer systems. Other embodiments may include different numbers, configurations, and / or types of computer systems. For example, some embodiments may include fewer remote computer systems or may not include remote computer systems. Some other embodiments may include a larger number of distributed systems, or may include systems that are completely distributed without any central system or having a limited central system.

  The central system 201, i.e. the place where orders are fulfilled, may be referred to as the "market". In some embodiments, firm order inquiry, firm order matching, provision of firm order instruction / firm order match, receipt of firm order query / firm order match indication, and / or any other desired Various operations, such as operations, may be performed upstream from such a market, for example.

  As shown, the trading system may include a central system 201. Central system 201 may include one or more computer systems that are each configured to perform one or more processes. Such a computer system may receive, transmit, and / or process information as desired. In some implementations, the central system 201 receives information related to orders (eg, firm orders), matches firm orders, fulfills trades, facilitates trade fulfillment, clears orders, facilitates order clearing. , Communication with remote system, order resolution, transaction reporting, query remote system to determine if matching order exists, query process or database to see if matching order exists May be configured to perform operations including determining and / or any other desired operation.

  In some embodiments, the central system 201 may be distributed across multiple regional hubs. With such distribution, it may be possible to extend the trading system over a very large geographical area where a very large number of trades can be routed. Such regional hubs may include functional replication and / or distribution.

  In some embodiments, the central system 201 may be responsible for facilitating one or more functions commonly referred to as “back office” functions. For example, the central system 201 may clear the transaction, resolve the transaction, report the transaction, review credit for participants, other functions necessary to comply with rules and regulations, and / or any other desired function Can be promoted.

  In some embodiments, the central system 201 may include a firm order matching system. Such a system may be configured to determine whether a firm order matches another firm order and / or perform other functions related to such firm order matching. In some embodiments, the central system may include an order router matching module. Such a module may be configured to route order inquiries to one or more participants and / or perform any other desired operations related to OMS orders. In some embodiments, the central system may include a regulatory NMS system. Such a system may interface with one or more other securities markets to find better pricing options for orders. Such an action may be required by securities regulations in some embodiments.

  In some embodiments, the central system may be coupled to one or more remote systems by communication network 203. Communication network 203 may include the Internet, one or more local area networks, and / or any other desired communication medium. Communication network 203 may allow a central system to send information to and / or receive information from a remote system, such as a computer system associated with a market participant. In some embodiments, communication between systems, modules, processes, and / or programs may include the use of financial information exchange messaging. Such messaging may or may not be encrypted as desired. In some embodiments, one or more firewalls or other security devices may be included in the communication network 203.

  In some embodiments, the system 200 may include one or more selling computer systems, each indicated at 205. The selling system 205 may include one or more trading computers configured to accept information related to securities offers (eg, firm orders to buy securities and / or firm orders to sell securities). The selling system 205 may be configured to receive, transmit, and / or process information. In some embodiments, the selling system 205 may be configured to send one or more instructions for such orders to the central system 201 via the communication network 203. In some distributed embodiments, the seller system 205 may be configured to send information to one or more other seller systems 205 and / or buyer systems 207. In some embodiments, the selling system 205 may be configured to receive information identifying completed order fulfillment (eg, from the central system 201), and prompting the user for such instructions (eg, Can be provided through a trading interface). In some embodiments, the selling system 205 may be configured to interact with the central system 201 or other style of distributed system. In some embodiments, a separate computer system may serve as an interface between the central system 201 or other style of distributed system and the rest of the selling system 205. While the selling system 205 is shown as a single system, it should be appreciated that any number of computers may be used to perform any desired function of the selling system.

  Some embodiments may include one or more buyer systems, each indicated at 207. In some embodiments, all or part of the buyer system 207 may be deployed with buyer market participants. In some embodiments, all or a portion of the buyer system 207 may be distributed or located in a central location where there is a central system 201.

  In some embodiments, buyer system 207 may include one or more trader systems, each indicated by block 209. Trader system 209 may provide an interface to one or more traders that may obtain or provide information. The trader may enter order information and / or receive instructions associated with the order through trader system 209, for example.

  In some embodiments, buyer system 207 may include one or more OMS systems 211. The OMS system 211 may perform one or more functions typically performed by the OMS. Such functions may include storing order information, providing order information to a trader computer, and / or any other desired function. As described above, the Fidessa OMS system is an example of the OMS system.

  In some embodiments, buyer system 207 may include one or more participant systems 213. In some embodiments, participant system 213 may serve as an interface between central system 201 or other style of distributed system and the remaining systems of buyer system 207. In some embodiments, the participant system stores order information, receives a firm order inquiry, fulfills the order, facilitates order fulfillment, clears the order, facilitates order clearing, sends the order information, matches Determining whether an order exists, providing instructions related to order inquiries, retrieving existing orders, determining whether an order is a firm order or an OMS order, and / or any other desired The functions related to the transaction such as the functions of Participant systems can enhance the functionality of conventional OMS systems by providing the market with a liquidity pool that is not provided without the present invention. In various embodiments, the participant system queries the OMS for update information (pulls information from the OMS), receives updates from the OMS when information in the OMS changes (pushes information from the OMS), and And / or can be synchronized with the OMS in any desired manner.

  In some embodiments, participant system 213 may query OMS system 211 (eg, periodically, randomly, etc.) to generate a copy of the OMS database. In some embodiments, OMS system 211 may send information to participant system 213 in response to such queries and / or without making any queries. Such information may include order instructions in the OMS database (eg, update of previous order, change to order, delete order, new order, copy of completed database, etc.). In some embodiments, participant system 213 may directly access the OMS database of OMS system 211, such as by querying the database (eg, without having to make a copy). In yet other embodiments, the OMS system and the participant system may be a single system, and such a distinction may not be appropriate.

  In some embodiments, buyer order information may be kept privately in a buyer system that may be located at each buyer participant facility. By so holding information, the buying participant may feel more secure about using such information for trading and may be less worried about potential information leaks.

  In some embodiments, one or more software modules may function as part of the OMS system 211 to provide some or all buyer functionality. Such a module may exist in addition to and / or alternatively to the participant system 213. For example, the module may include an update to the OMS software or a program associated with the OMS software program.

  Although FIG. 2 shows the OMS system, participant system, and trading system as separate systems, it should be understood that any configuration of system may be used. For example, a single system may operate as all or part of any other system (eg, a single system may function as an OMS system, a participant system, etc.). Further, various systems may share information and / or distribute functional performance. For example, the OMS system may maintain an order database readable by one or more of a trading system, a participant system, and / or any other desired system.

  In some embodiments, one or more of the buying or selling system may include a mobile device. Such mobile devices may include laptop computers, PDAs, cellular phones, and / or any other desired mobile device.

  In some embodiments, one or more software modules may function in conjunction with and / or in place of transaction interface software and / or OMS software. Such accompanying or replacement software may include additional options and / or different options to the traditional interface and / or OMS software.

  Although FIG. 2 shows the buying system 207 and the selling system 205 as being connected to separate parts of the communications network 203, such systems can be on the same network, such as the Internet or any other communications network. It should be understood that they may be connected.

  In some embodiments, one or more participants may use a virtual OMS rather than a conventional OMS. It should be understood that references to OMS include references to such virtual OMS. The virtual OMS functions as a dedicated OMS for multiple participants, but may actually include a system that is a shared system. For example, in some implementations, the virtual OMS may include a system that is remote from the participant and accessed via the Internet. The system may include a separate database for each such participant to track typical OMS information. It should be understood that some systems may include a single database with participant identifiers and / or any other method of storing information that may be used in providing a virtual OMS service to participants. The use of virtual OMS may provide participants with OMS services without having to maintain and / or purchase a dedicated OMS system.

System Process Example FIG. 3 shows an example process 300 that may begin at block 301. In some embodiments, process 300 may be performed by central system 201. In other embodiments, process 300 may be performed by one or more distributed computer systems.

  As indicated at block 303, the process 300 may include receiving an order instruction. In some implementations, the order can be a firm order. In some embodiments, such instructions may be considered legally binding instructions on the firm order submitter side. For example, the central system 201 may receive instructions for such orders from a buying system (eg, 207) and / or a selling system (eg, 205). Such an order may be entered, for example, by a trader using a trading interface at a buying or selling farm. The firm order indication may identify that the purchaser of the order delegates a transaction (eg, bid, offer, etc.). In some embodiments, the order instructions include the amount of the security to buy or sell, the time that the firm order is open, the price or price range to buy the security, the limit price, the pricing method, the order identifier, and / or others Any information may be indicated. An order may define the trading side of a financial instrument. Each side of a financial product transaction may include a side that wants to buy a financial product and a side that wants to sell the financial product.

  As shown in block 305, the process 300 may include determining whether there are any matching firm orders. Matching orders may include orders that include complementary terms to firm orders. Such provisions may include securities, quantities, prices, time frames, and / or any other desired information. For example, a firm order may indicate that 10,000 eSpeed stocks should be purchased at an average price of $ 100.00 per share. A firm order may have previously been received indicating that 10,000 eSpeed brands should be sold at an average price of $ 100.00 per share. The previous eSpeed order may be determined to match the subsequent eSpeed order in such a situation. In some embodiments, orders within a price range, orders below the maximum price, orders above the minimum price, and / or orders that match in any other desired manner may also be determined to match. . In some embodiments, orders with a greater or lesser number of stocks may be determined to match. In some embodiments, the firm order indication may identify the maximum and / or minimum order size / ratio that may be determined to match other firm orders.

  In some embodiments, according to some priority mechanism, it is determined that multiple orders are matched, so that the total number of stocks of all matching orders is at least the number indicated by the firm order instructions. obtain. In some embodiments where multiple orders are determined to match, priority may be assigned to any number of orders based on one or more characteristics of the order, the purchaser of the order, and / or any other characteristic. Can be assigned.

  In some embodiments, a matching firm order may have been received from a buying or selling system. Such matching orders may be stored on a machine readable medium (eg, a disk drive of central system 201). Determining whether a matching firm order has been previously received may include searching a database or other list of previously received firm orders. Such a database may be important to allow quick reference by securities identifiers (eg, stock symbols) and the like.

  Some embodiments may include maintaining a list of firm orders. Such a list may include a database. Keeping the list can add newly received firm orders to the list, remove fulfilled firm orders from the list, remove expired firm orders from the list, and / or any other Desired operations.

  If it is determined that there is one or more matching firm orders, as shown in block 307, facilitate fulfillment of some or all of those matching firm orders to Can satisfy. Each such matching order may fully or partially fill the received confirmed order. Facilitating fulfillment includes performing a financial exchange of securities, clearing such an exchange, sending information to a remote fulfillment and / or clearing service, notifying participants, and / or Alternatively, any other desired action can be included. Transactions can be facilitated with prices and / or quantities that can be identified from the query.

  In some embodiments where there are multiple matching orders, the matching orders may match the received firm order based on any desired priority mechanism. Such priority mechanisms include prioritization based on securities prices, first-come-first-served basis, prioritizing older and / or most aggressive order placers, matching large orders first and matching closest in price and / or size. May include priority, round robin systems, and / or any other desired prioritization method. In some embodiments, multiple orders may be combined together to fully fulfill as many existing orders as possible. In some embodiments, a portion of each matching order may be fulfilled. That portion may correspond to any feature of the order or the ordering party, such as the order size, the orderer's loyalty, the orderer's aggressiveness, the actual price compared to the desired price.

  In some embodiments, the process 300 may end at block 309 if a matching firm order is found. In some embodiments, if there is one or more matching firm orders but the received firm orders are not fully fulfilled, it facilitates the fulfillment of the matching firm orders and the remaining balance of firm orders is , Can be treated as if a matching firm order was not found (eg, a firm order containing only the remaining order quantity can be used and continued as described below).

  In some embodiments, as shown in block 311, the process 300 may include querying one or more participants to find a matching order. In some embodiments, querying the participant may include sending one or more requests from the central system (eg, 201) to the buying system (eg, 207). In other embodiments, querying a participant may request the request from a computer in the distributed system to another computer in the distributed system, eg, from one buyer participant to another participant, or a seller. Sending from a participant to a buyer participant or the like. In some embodiments, such inquiries are such that one or more participants query one or more further participants, and the one or more further participants themselves continue to query further participants. , And so on, from one participant in a tree style that can be continued to another. Such an action can be taken if no matching firm order is found, or if the matching firm order set found previously is incomplete, as described above. In yet other embodiments, the query sends a request to other processes, threads, memory locations, computer program portions, etc. executed by a single system such as central system 201 or multiple systems such as a distributed system Can include.

  Systems associated with market participants (eg, buyer system 207, participant systems 205, 207) may be configured to accept the request and determine whether there is a matching OMS order. In some situations described in more detail below, some such systems may indicate that a match exists in response to a query. In some implementations, such a response may include an indication that the transaction has already been fulfilled and / or cleared (e.g., any other system by the remote system from which the request was sent). by).

  In some embodiments, some or all of the inquiry actions and / or responses that may be received may be hidden and / or hidden in other manners from the firm orderer and / or any other individual. . For example, if a negative response is received, such a response may be hidden from the purchaser of the firm order. In some embodiments, only positive responses may be revealed, as described below. In some embodiments, negative responses may be deleted or otherwise concealed. By limiting the response, the behavior can be kept secret from the order's buyer and the participant can be given a further level of anonymity, thereby reducing the opportunity and / or opportunity to manipulate the market. , Can encourage participants to participate in the trading system.

  As indicated at block 313, the process 300 may include receiving additional firm orders from various other firm order sources such as buyers and / or seller participants. The receipt of such a new firm order can be made substantially simultaneously with the inquiry to the participant. Such a new firm order may be compared to the received firm order from block 303 to determine whether it matches, as described above in connection with block 305.

  As indicated at block 315, the process 300 may include determining whether a matching order has been found. Finding a matching order may include receiving a new firm order from another source and / or receiving a response from a participant that has a matching order.

  If it is determined that no matching order exists, the process 300 may loop back to block 311. In various embodiments, participants can be periodically queried. The duration can be any length, such as 30 seconds, 30 minutes, a random length, a length based on a trader and / or some characteristic of the order. In various embodiments, a match is found, a matching firm order is received, the time associated with the firm order has elapsed, the firm order has been canceled, and / or until any other desired length of time. You can contact us.

  If it is determined that there is one or more matching orders, the process 300 includes facilitating fulfillment of the transaction that satisfies the firm order and the one or more matching orders, as shown in block 317. obtain. In some embodiments, facilitating fulfills the transaction, clears the transaction, sends an indication that the transaction should be performed or cleared by the remote system, and / or any other desired Operations may be included. In some embodiments, fulfillment of the transaction may occur at a remote server, such as one or more servers (eg, a buyer system, etc.) where a firm order match is found and / or a central system, such as central system 201.

  In some embodiments, matching orders may not fill the entire firm order. In such a situation, process 300 may continue to search for matching orders, for example by querying a remote server and waiting for a new order in a loop to block 311.

  In some embodiments, matching orders can be found within a relatively short time. For example, within a relatively short time, multiple confirmed orders may be received and / or multiple OMS orders may be found at a participant. Such a time may be any desired amount of time, such as 1 second, 1 minute, etc.

  In various embodiments, fulfillment of orders in which such matching orders are found within such a short period of time may be based on several desired priority sets. In such an embodiment, matching orders found in a short time are treated as if they were found at the same time and may be executed based on several other priority mechanisms. For example, a firm order may be fulfilled first, an order found through a participant inquiry may be fulfilled first, an order entered first may be fulfilled first, and a larger order May be fulfilled first, smaller orders may be fulfilled first, older orders may be fulfilled first, newer orders may be fulfilled first, and the best customer order May be fulfilled first, the order of the highest-ranking customer may be fulfilled first, the order of a customer who is willing to pay may be fulfilled first, and / or using any other method Thus, the execution order may be determined. In other embodiments, order fulfillment may be strictly based on the order in which matching orders are found.

  Process 300 may end at block 319 after the promotion of fulfillment of the order is complete. In some embodiments, one or more participants, such as the ordering party, may be notified of the fulfillment. In some embodiments, the order of operations may not be the same as shown in process 300. In some embodiments, process 300 may include additional operations, fewer operations, and / or different operations. Process 300 or similar process may be performed on any computer system or centralized and / or distributed system.

Participant Process Example FIG. 4 shows an example process 400 that may be performed by a participant (eg, a buyer system 207), starting at block 401. In other embodiments, some or all of the processes 400 may be performed at a central location such as the central system 201 or a distributed location such as a seller or buyer system. Process 400 may be performed, in part, to facilitate responses to the queries described above in connection with process 300 and / or to provide instructions for firm orders. In some embodiments, the process 400 may be an OMS system, a separate participant system, a buyer or seller trader computer, or any other computer such as a computer system configured to receive and process orders. Can be performed by the system.

  As indicated at block 403, the process 400 may include receiving an order instruction. Such instructions may be received, for example, from a trader who enters information about the desired transaction through the transaction interface. The instructions include price identification information, quantity of securities to buy or sell, time the order is open, price or price range to buy the securities, limit price, pricing method, order identifier, and / or any other information May be included.

  As shown in block 405, the process 400 may include determining whether the order is a firm order. A firm order may indicate that the order should be fulfilled substantially automatically, as described above. An OMS order may indicate that information about the order should be kept secret from other market participants and / or should not be fulfilled automatically. Some embodiments may not include a separate operation for identifying the type of order. For example, in some embodiments, different processes, threads, and / or systems may receive different types of orders such that the operation of receiving the order itself indicates the type of order. For example, a trader submits an OMS order (eg, to an OMS system, a participant system, etc.) using one interface and a firm order (eg, to a central system, etc.) using another interface. Can do. In some embodiments, a single program may be used to submit different types of orders and the program may identify (eg, based on different buttons pressed, different checkboxes selected, etc.) .

  As shown in block 407, if the order is a firm order, the process 400 may include providing an order instruction to fulfill the firm order. Such providing may include sending information about the order to the central system 201 or distributed system. Such an order may be received by such a system, and such a system may attempt to fulfill the order substantially automatically (eg, using a process similar to process 300). In some embodiments, such providing may include providing information to a processing thread or program executed by one or more computing devices. If the order is a firm order, process 400 may end at block 409. In other embodiments, the process 400 may continue to provide update information about fulfillment of firm orders, such as through a trading computer interface.

  As shown in block 411, if the order is not a firm order, the process 400 may include an operation of storing information about the order. Storing the information may include storing the information on a machine readable medium such as a RAM, a hard disk. The media may be associated with one or more portions / one or more of the OMS system and / or the participant system. The information may be stored in one or more database tables configured to store information about the order. Such a database table may be configured to easily search for orders to determine whether an entered order request matches any order stored in the database. For example, in some embodiments, the database may be keyed on the name of a security.

  Some embodiments may include maintaining stored information. Such information may be retained in the same manner as order information retention in a typical OMS system. In some embodiments, holding may include OMS and / or participant system operations. Holding may include updating the fulfilled order in connection with the matching firm order inquiry. Order information, for example, when an order is fully or partially fulfilled, when an order expires, when an order is explicitly deleted or updated by a trader, and / or for any other desired reason Can be deleted / updated.

  As shown in block 413, process 400 may include receiving an input firm order inquiry. Entered firm order queries include price identification information, quantity of securities to buy or sell, time the order is open, price or price range to buy securities, limit price, pricing method, order identifier, and / or others Any information may be included. In some embodiments, such firm order queries may be received from one or more computer systems that are performing a process similar to the process shown in process 300. In some embodiments, the firm order inquiry may include an order that fulfills some or all of the OMS orders. Such an inquiry may be received at a participant system, an OMS system configured to perform some or all of the operations of process 400, and / or any other desired location.

  As indicated at block 415, the process 400 may include a firm order query determining whether the order matches the order. For example, a result from a database query that includes a clause (eg, security identifier, price, quantity, etc.) identified by a firm order query may return a positive result.

  As indicated at block 417, process 400 may include attempting to facilitate the performance of the transaction with a matching firm order inquiry. Facilitating the fulfillment of a transaction is, for example, displaying a firm order instruction to a trader through one or more transaction interfaces, alarms or other audible alerts for such a transaction, as described in more detail below. Generating and / or any other desired action. In some such embodiments, the trader may be asked whether to accept or reject the matching order. If a trader, in some embodiments, accepts an order, the system fulfills the transaction, fulfills by another system, and / or transfers information about the transaction to be cleared, and / or other Any desired action may be performed to further facilitate the performance of the transaction.

  In some embodiments, by keeping the OMS order secret from other trading participants, the trading system executing the process 400 is in a state where the trader is normally inaccessible, such as an order in the OMS system. Can be made available for matching against firm orders. This promotion can be particularly important for buyer participants, who can usually protect order information. Such use of OMS orders can increase market liquidity using such processes.

  Process 400 may end at block 419 after facilitating fulfillment of the transaction. In some embodiments, one or more participants, such as the ordering party, may be notified of the fulfillment. In some embodiments, information stored in connection with an order may be updated to reflect the fulfillment of the order. In some embodiments where only portions of the OMS order are filled with matching firm orders, the process 400 may include receiving additional firm order queries and facilitating the fulfillment of those transactions.

  In some embodiments, the order of operations in process 400 may not be the same as the order shown in FIG. In some embodiments, process 400 may include additional operations, fewer operations, and / or different operations. Process 400 or similar processes may be performed on any computer system or centralized and / or distributed system. For example, process 400 may be performed by participant systems 205, 207, an OMS system configured to execute one or more portions of process 400, and / or any other system. In some embodiments, process 400 may only be performed in connection with a buyer participant.

Example Query Process FIG. 5 begins at block 501 and, in some embodiments, an example process that may be used to partially execute an inquiry to a participant as shown in block 311 of process 300 described above. 500. Process 500 may be performed by a central computer system that queries participants to match orders, may be performed in a distributed manner by multiple computer systems, and / or may be performed by any other computer system. Also good. In some embodiments, such a process is partially or totally distributed in a tree that allows some participants to query one or more child participants to find matching orders. Can be executed.

  As shown in block 503, the process 500 may include identifying one or more participants. Participants may include one or more remote servers, one or more computer processes, threads, or programs. For example, in some embodiments, the participant includes a buyer system. In other embodiments, participants may include seller systems and / or other systems. Identifying a participant may include querying potential participants in the participant list (eg, sending a ping to an IP address, performing a function call, etc.). In some embodiments, participant identification may include placing one or more items in a predetermined memory location, querying the predetermined memory location for participant information, in a database or other participant list. May include accessing, receiving an indication that a participant is present (eg, from a participant, administrator, etc.) and / or any other desired action. In some embodiments, the identified participants may include child participants in a tree-like participant structure.

  As indicated at block 505, process 500 may include receiving an indication of a firm order. Such a firm order may be substantially similar to the firm order received at block 303 of process 300.

  As indicated at block 507, process 500 may include sending a request to the identified server. Such a request may be substantially similar to that described above with respect to block 311 of process 300. In some embodiments, as described above with respect to process 300, instead of or in addition to querying participants as described above with respect to process 300, received confirmed orders may be stored in other locally stored Matches against confirmed orders.

  In some embodiments, participants may be configured in a distributed manner. For example, in one embodiment, participants can be configured in a tree-like fashion. In such an embodiment, the first participant may query one or more other participants. Other participants may determine whether a match exists locally. If there is a match, the participant may return a positive indication (eg, the querying participant, a firm ordering device, a market, etc.). If no match is found locally, additional participants can query additional participants. The order of queries may be established based on any desired priority mechanism (eg, first query the largest customer, first query the premium customer, first query the highest ranked customer, etc.). In some embodiments, participants can query additional participants regardless of whether a match is found locally.

  As indicated at block 509, process 500 may include determining whether a response has been received from the queried participant. In some embodiments, determining whether a response has been received may include querying a port or socket that may receive the communication from the communication network. In other embodiments, determining whether a response has been received may include querying a register, memory location, process, thread, program, function, and / or any other operation.

  In some embodiments, if no response is received, process 500 may loop back to block 507 to send one or more additional requests. Any number of requests may be sent any number of times. The request transmission interval can be any time (random, periodic, etc.). Process 500 may continue to loop until a response is received, until a matching firm order is found in another manner, until time passes, and / or any other event occurs.

  In some embodiments, the participants queried in each loop may be the same or different. For example, in some embodiments, the first participant group is first queried (eg, a premium participant group, a good customer group, a group of high volume customers, etc.), and then after some time, the second participant Get a group inquiry. Any number of such subgroups can be queried in such an order.

  As indicated at block 511, the process 500 may include filling a matching order in the response to facilitate fulfillment of the transaction. Promotion may include fulfilling a transaction, clearing a transaction, forwarding a request for information, and / or any other desired action. In other embodiments, the response may indicate that the transaction has been fulfilled, fulfilled, cleared, and / or cleared (by a remote system).

  In some embodiments, the response may be received only if a match exists and / or the trader desires to fulfill the transaction. By limiting the response to a positive response, participation may be facilitated because less information will be revealed to the participant. This can be a greater incentive for participants to deliver orders to the market than the traditional market, thereby increasing market flow.

  Other embodiments may include receiving a negative response if no matching order exists and / or the trader does not want to fulfill the transaction.

  In some embodiments, a response may be received for a transaction that does not fully fulfill a firm order. In some embodiments, after fulfilling such an order, process 500 may loop back to block 507 to query the participant again. Further inquiries to the participants may include orders that have been updated with the requested amount reduced by the previous order. In other embodiments, the promotion of such order fulfillment may be limited to complete orders (eg, based on preferences indicated by the order's buyer, trading system preferences, etc.).

  In some embodiments, multiple responses may be received simultaneously or within a relatively short time. Orders so received can be treated as if they were received at the same time. A priority mechanism may be used to determine which of such orders should be fulfilled first. For example, orders associated with high volume customers, premium customers, long term customers, or customers with any other desired characteristics may be given higher or lower priority compared to other orders. In some embodiments, priority may be given to the largest or smallest order. In other embodiments, any desired priority mechanism may be used.

  In some embodiments, process 500 may end at block 513. In some embodiments, process 500 may include notifying one or more traders of fulfillment. In some embodiments, process 500 may include additional operations, fewer operations, and / or different operations. Process 500 or similar process may be performed on any computer system or centralized and / or distributed system.

Passive Order Process Example The process 600 of FIG. 6 illustrates an example process that may be initiated by one or more participants, starting at block 601. Process 600 may include operations similar to process 400 described above. In some embodiments, process 600 may be performed by one or more buyer participants.

  As indicated at block 603, the process 600 may include receiving one or more instructions for one or more orders. Such orders may include OMS orders as described above in connection with process 400. As discussed with respect to block 411, orders may be stored accordingly so that queries can be matched.

  As indicated at block 605, the process 600 may include receiving one or more confirmed order inquiry instructions. Such a firm order inquiry may be sent, for example, by an entity performing a process similar to process 500 and / or process 300 described above.

  As shown in block 607, process 600 may include filtering firm order queries. Final order inquiries include order characteristics (eg, price, securities, quantity (eg, minimum quantity, maximum quantity), etc.), ordering party characteristics (eg, orderer rating, orderer type, specific ordering) And / or order inquiries may be filtered according to any other desired characteristics. In some embodiments, different filters may be applied for different types of securities. For example, a filter set in a security with a large capital may be applied, and another filter set may be applied to a security with a small capital. In some embodiments, certain securities (eg, identified by a stock symbol) may be filtered out or a specific set of filters may be applied to specific securities (eg, identified by a stock symbol) Can do.

  In some embodiments, filtering may allow a participant to filter queries received from or sent to other participants. Filtering may be performed based on any desired feature. Such features may include features that are less likely to turn the order into an order associated with market operations. For example, in one implementation, the filter may block firm orders that do not meet the minimum size requirement, the minimum dollar total requirement, and / or any other desired feature.

  In some embodiments, as another example, a participant may only want to consider orders associated with an orderer that has certain characteristics. Such features may include features that are less likely to turn the order into an order associated with market operations. For example, in one embodiment, the filter may include orders from a particular class of traders (eg, hedge funds, etc.), orders associated with particular traders identified as being involved in market operations by participants, specific Orders from non-trusted participant sets, orders from participant sets with low ratings from other participants, orders from participants with no transaction history, etc. may be blocked.

  In some embodiments, a firm order submitter may wish to filter participants who receive inquiries regarding firm orders. Such a filter may filter participants based on participant characteristics, participant behavior, and the like. For example, in some embodiments, a filter may be established based on a participant's response pattern (eg, how the participant has responded to the query in the past). As an example, a firm order submitter may submit a firm order query (eg, a firm order query, a firm order query from a type of trader, a firm order query for a particular financial instrument, a firm order query for a class of financial instruments, In some cases, it is desirable to send an order only to a participant who has a history of accepting a confirmed order inquiry of a certain range of financial products, a confirmed order inquiry from a submitter, and the like. Such filtering may prevent information about firm orders from being sent to participants who are likely not to respond positively to the order. In one implementation, the firm order submitter may select from one or more response rating ranges (ie, number of queries accepted / number of queries received) that are determined by participants to receive queries. Can be referred to as a risk pool that must be associated (e.g., select among participants having an acknowledgment rate of 1-50%, 51-70%, 71-90%, and / or 91-100%) .

  Some embodiments may include receiving an indication of a desired filter. This indication may be received from one or more traders, participant systems, or any other desired source. The indication may identify any desired feature, feature combination, filtering exception, and / or any other information associated with the filter.

  The filter may be applied in a centralized and / or distributed manner. For example, in some embodiments, the filter may be applied before the request is sent (eg, by a central system, distributed system, etc.). By applying a filter before sending the request, the amount of traffic associated with performing the process 600 may be reduced. Conversely, performing such filtering before transmission can increase the amount of processing performed before transmission, and no one wants to expose even the trading system administrator. There may be some participant exposure filtering preferences. In other embodiments, the filtering may be performed locally for the participant. By performing such filtering locally, the trading system can generate more traffic, more processing can be done at the participant, and filtering options can remain secret.

  In some embodiments, participants may be filtered from received requests based on the wishes of firm order submitters (eg, by a central system or other participants who submitted inquiries, etc.). Such participants may be filtered by identification information, order availability, and / or any other desired characteristics. Such filtering can be performed, for example, by the participant himself (eg, a participant system configured to perform such filtering before or in combination with other participant functions before or in other manners). ), By the central system, by the submitted system, and / or by any other desired system. In some embodiments, for example, if a participant does not have a matching firm order that meets the minimum percentage of firm orders, the participant may not be provided with an inquiry. In other embodiments, such information is unknown until a query is sent, and in such embodiments, it may be determined that matching exists only if the matching meets a minimum percentage. Filtering before query transmission may reduce the amount of outgoing traffic (eg, TCP / IP packets) that can be exposed by snooping transaction information, but a malicious user may attempt to identify such a query in an attempt to identify filtering settings. You can snoop.

  In some embodiments, the participant system may send filtering information to the central system. Such information can be used to perform filtering in the central system. Such information can also be used to provide information to a user who has entered a firm order, as described below.

  In a trading system that allows such filtering, a participant may allow a previously untouched liquidity pool to be open only to a particular trader subset. By allowing such a restriction, participants who open their liquidity pools (eg, order sets at the OMS) can be malicious (for example, traders who gain access to those pools may You can have greater confidence by not using it for the purpose of (manipulating the market).

  As shown in block 609, the process 600 may include determining whether there is an order that matches the firm order query. Such a determination may include searching one or more databases or other lists of OMS orders. The determination may be made at the same or different location as the filtering. The determination may include searching the order list in the buyer participant's OMS. Such a list may include all listed orders, a subset of listed orders identified as searchable by a trader, and / or any other order.

  As shown in blocks 611 and 613, the process 600 may end if it is determined that no matching order exists. Some embodiments may end without providing any indication that the order does not exist. By not providing instructions that specifically identify that an order does not exist, others (eg, other traders, participants, people snooping packets, etc.) may find that the order does not exist or such a response To determine if it was not sent for any other reason (for example, because the trader has been filtered out as described above because it indicated that the trader should not perform the trade as described below) May not be possible. In some embodiments, the instruction that received the inquiry may not be presented to the trading system associated with the trader or the participant that received the inquiry. Keeping such information secret may prevent the recipient of the inquiry from operating the market using information that a firm order exists.

  As shown in blocks 611 and 615, if it is determined that a firm order exists, the process 600 may include providing an indication that a firm order has been received. Providing such information may include transmitting information from one computer system to another via one or more networks. Providing such instructions may include presenting one or more interfaces or icons identifying the firm order to the user (eg, a buying trader associated with the matched OMS order). Such an interface may include an option to accept a firm order, an option to reject a firm order, an option to ignore a firm order, an option to ignore all firm orders (eg, for a desired time), and / or any other Desired options may be included. Such instructions are legal from the perspective of the participant associated with the OMS because the recipient (eg, the participant associated with the matching OMS order) is not obligated to fulfill any order based on the instruction. It can be regarded as an instruction without any binding force. However, the purchaser of the firm order may still have legal binding power to fulfill the order if the recipient of the instruction chooses to accept the order.

  In some embodiments, ignoring a firm order may cease matching using the receipt of firm order inquiry by a participant / firm order query for a minimum amount of time. Such downtime may facilitate participants to accept firm order inquiries. This time may vary based on order characteristics and / or participants.

  In some embodiments, the user may select various options for ignoring future instructions. For example, the user should ignore the instruction unless the price associated with the firm order is at a certain level, and should ignore it unless the firm order has certain desired characteristics, and at a certain time May be ignored, should be ignored for a certain amount of time, should be ignored until the end of the day, and so on.

  In some embodiments, evidence that the user has chosen to ignore the instructions may be hidden. For example, information may be kept confidential in a particular system, kept secret in a central system, or otherwise kept secret. In implementations where different options that ignore the instructions may be selected, evidence for some or all of the information about those options may also be hidden.

  As indicated at block 617, process 600 may include waiting for a response from such an indication. Such an implementation may include receiving a response and determining whether the response is a positive response or a negative response. In other implementations, the response may not be received and may be received only if the response is a positive response. In some embodiments, the amount of time to wait may be indicated to the trader. In some embodiments, the amount of time may vary based on one or more desired characteristics of the securities, participants, orderers, and / or other desired entities.

  As indicated at block 619, process 600 may include determining whether a positive response has been received. Determining whether the response is a positive response is whether or not any mouse button was pressed, if so, which mouse button was pressed or whether any keyboard button was pressed If pressed, determining which keyboard button was pressed, whether any interface control was selected, if selected, which interface control was selected, and / or Any other judgment of the possible possible inputs may be included.

  As indicated at block 621, the process 600 may end if a positive response is not received. In some embodiments, a scheduled default response may be entered after a waiting period. In some embodiments, such default response may include a negative response. In some embodiments, an interface operator (eg, a trader, administrator, etc.) may determine an appropriate amount of time and / or an appropriate default command.

  As shown in block 623, if a positive response is received, the process 600 may include facilitating a transaction that satisfies at least a portion of the matching order and at least a portion of the firm order. Facilitating a transaction may include performing the transaction, clearing the transaction, sending information such that the transaction is remotely fulfilled and cleared, and / or any other desired action. In some implementations, facilitating may include providing a positive response (eg, to a central server, buyer participant, and / or seller participant, etc.). The recipient of the positive response may further facilitate the performance of the transaction if the transaction that satisfies the firm order has not yet been performed. Sending a positive response is a legally binding indication for the transaction because the participant associated with the OMS order may be legally binding to meet a matching firm order by the indication. Can be considered. In some embodiments, legal binding may be contingent on firm orders that have not been met before, rather than participant actions.

  In some implementations, the process 600 may include receiving an update regarding the promotion of performance, such update receiving an indication that the performance has been completed or has not been completed. Can be included. In some implementations, the transaction may be partially completed and the update may indicate that the transaction has been partially completed. For example, a transaction may be partially completed if a positive response is received, if only a portion of the firm order is still waiting to be fulfilled, and if the OMS order includes a larger volume of transactions. In such a situation, in some embodiments, the transaction may be canceled, and in other embodiments, the OMS order may be fulfilled to the extent that a firm order remains, and such an indication may be sent to the participant. In yet other embodiments, the purchaser of the OMS order may contact the updated firm order information and / or perform any other action.

  Process 600 may end at block 625. Process 600 may include notifying one or more participants of the outcome of promoting the performance of the transaction. In some embodiments, process 600 may include additional operations, fewer operations, and / or different operations. Process 600 or similar process may be performed on any computer system or centralized and / or distributed system. Process 600 may be performed in a centralized and / or distributed manner on one or more computer systems.

  It should be understood that the process of querying a participant is given only as an example possible. In various embodiments, other methods of pulling order information from one or more OMSs may be used. In yet other embodiments, order information may be pushed from one or more OMSs to a central system or other system that can perform order matching, rather than pulling order information as described in process 600. In such implementations, the OMS and / or participant system may be configured to provide OMS order information and updates to a trusted system to perform order matching without the need for queries.

Example Order Entry Process FIG. 7 illustrates an example process 700 that may begin with block 701 and participate in an interface used in some embodiments. Process 700 may be performed, for example, in part by an OMS, a trading terminal, and / or any other computer system.

  As indicated at block 703, process 700 may include providing an interface through which one or more of firm orders and / or OMS orders may be entered. Such an interface may allow a user to enter information identifying securities, pricing policies, prices, quantities, and / or any other information about the desired transaction.

  FIG. 8 shows an example of an interface through which a user can input order information. Through such an interface, the user can enter the order type, desired security, pricing policy, expiration time, limit, minimum fill amount, incremental fill amount, quantity, and / or any other desired option. possible. In some embodiments, the same or similar interface may be used for input of one or more of firm order and OMS order information.

  Such a trading interface may show information about the percentage / number of participants that may display a firm order inquiry associated with the entered order, as shown at 801. This information may be based on a filter established by the participant to filter orders as described above. Such information may be collected by a central system (eg, from a participant system). One feature that can be frequently used for order filtering is order size. The percentage / number of participants may reflect the total number of participants willing to accept orders having all features other than size and the number willing to accept size features. Accordingly, the ordering party can adjust his / her order size to increase or decrease the number of participants inquiring.

  As shown in block 705, the process 700 may include receiving information about the entered order. The information may include information entered through the provided interface and / or any other information (eg, default information, identification information, etc.).

  As shown in block 707, process 700 may include determining whether the order is a firm order. Determining whether the order is a firm order may include identifying input signals, interface control features, and / or any other information. Some implementations do not include such identification; rather, an interface, program, computer, etc. that receives an instruction or receives information about the instruction identifies the type without performing a separate action. obtain.

  As shown in block 709, if the order is a firm order, the process 700 may include a firm order that automatically performs against a matching order (eg, a matching firm order, OMS order, etc. submitted before or after). May include sending the indication (eg, to a central system, distributed system, etc.). Process 700 may then end at block 711. In some implementations, process 700 may also include receiving information about matching orders and displaying that information through one or more interfaces.

  As shown in block 713, if it is determined that the order is not a firm order, the process 700 sends an order expression to be matched against the input order query, eg, by a process such as process 400. Can be included. This transmission may include providing different processes, threads, memory locations, etc. In other embodiments, the same program thread server may perform query matching, providing an interface, receiving order information, and / or any other desired action. As indicated at block 715, the process 700 may then end.

  In some embodiments, the process 700 may include receiving information about the order, such as whether a matching query is received. In some embodiments, process 700 may be performed by, for example, a trading computer, OMS system, central system, and / or participant server. In some embodiments, process 700 may include additional operations, fewer operations, and / or different operations. Process 700 or similar process may be performed on any computer system or centralized and / or distributed system. Process 700 may be performed in a centralized and / or distributed manner on one or more computer systems. In some embodiments, entry of OMS orders in such a process may be restricted to market buyer participants.

Passive Order Query Process Example FIG. 9 shows an example process 900 that begins at block 901. Process 900 may be performed, for example, by a buying system, a selling system, and / or any other computer system. In some implementations, a participant server, trader's computer, OMS, and / or any other computer system may perform one or more operations associated with process 900 and / or similar processes. .

  As indicated at block 903, the process 900 may include receiving an indication that the firm order matches the OMS order. Such instructions may include one or more OMS systems, participant servers, central servers, buying systems, selling systems, computer programs, computer processes, computer threads, memory locations, network interfaces, and / or other desired Can be received from any source.

  As indicated at block 905, the process 900 may include providing an interface, icon, and / or other indication that a matching order exists. FIG. 10 illustrates an example interface that may be used as such an indication in some embodiments. Such an interface may display some details of matching orders, as shown. In such an interface, a trader may be able to indicate a positive or negative response to an order (eg, by operating a control device such as a button).

  The process 900 shown at block 907 may include determining whether a positive response has been received within a certain time. In some embodiments, this time may be a default time, an amount of time according to a user profile, an amount of time according to a firm order clause, an amount of time determined in part by the order size and / or dollar value, and / or any other Desired amount of time. In some implementations, receiving a positive response may include receiving an indication that the controller has been selected. If a positive response is not received, process 900 may end at block 909.

  As shown in block 911, if a positive response is received, the process 900 may include sending a request to fulfill a transaction that satisfies at least a portion of the firm order and at least a portion of the matching order. . Other embodiments may include facilitating the performance of such transactions (eg, performance of transactions, clearing of transactions, etc.).

  Process 900 may end at block 913. Other embodiments of process 900 include receiving information about the performance of a transaction, displaying information about such performance, displaying terms associated with the transaction, displaying information about the buyer of a firm order, stored Update / retention of existing order information and / or any other desired action.

  In some embodiments, multiple confirmed orders may match the OMS order. In such embodiments, instructions for each such matching order may be provided. In some embodiments, the instructions may be ordered according to a preference mechanism. Such a preference mechanism provides ordering based on the ordering party, instruction recipient, computer system administrator's preference, and / or any other preference of any individual with respect to any feature of the order, computer system, transaction, etc. May be included. In some implementations, instructions may be pooled into a single instruction without providing separate instructions. Such pooling may include combining a plurality of firm orders according to some preference mechanism so that firm orders meet matching orders. If there are additional firm orders, some embodiments may separately provide information about such firm orders. In some implementations, an interface may be provided that allows a user to access information about individual orders and enter information (eg, order acceptance) even when instructions are pooled. .

  In some embodiments, process 900 may include additional operations, fewer operations, and / or different operations. Process 900 or similar process may be performed on any computer system or centralized and / or distributed system. Process 900 may be performed in a centralized and / or distributed manner on one or more computer systems. In some embodiments, only the buyer participant may receive a firm order inquiry that matches the OMS order.

  Processes 300-700 and 900 are configured to provide a convenient explanation of the concepts disclosed herein. It should be appreciated that not all such processes need to be performed.

Encryption In various embodiments, some or all communications may be encrypted. In various embodiments, some or all information stored on various media may be encrypted. In some embodiments, the information comparison may be performed in an encrypted form. In other embodiments, the encrypted data may be decrypted prior to performing the comparison.

  In some embodiments, encryption algorithms such as well-known PGP, RSA encryption methods may be used for communication between participants, computer systems, and the like. With advances in quantum computing, the security of such encryption can be reduced in the future. Accordingly, some embodiments may include the use of quantum key encryption algorithms or other future proof encryption algorithms designed to eliminate such vulnerabilities.

User Types In some embodiments, different users of the system (eg, central system, buying system, selling system, trader computer, etc.) may access different options. Since the market can be asymmetric, providing the asymmetric option for such user types can best capture the dynamics of the market. For example, in the securities trading market, participants are divided into four example categories that may include hedge funds, investors, brokers, and certified naturals. It should be appreciated that other embodiments may include additional users, alternative users, fewer users, and / or uncategorized users.

  Referring to four example category embodiments, investors may include traders who trade for their own (eg, individual) interests. Hedge funds can include organizations that are typically exempt from standard securities regulations seeking high returns on financial instruments. A broker may include an originator who can trade on behalf of others regulated by standard securities laws. Certified candidates may include brokers who do not act on their own account. To become a qualified person, a broker may need to provide a certificate that does not trade on their own account. In some implementations, a single user may act as more than one type of user in various cases. For example, a broker may act as a broker or a qualified person depending on the circumstances. Options and treatments given to such different categories may reflect the potential for participants to manipulate the market.

  In some embodiments, the information provided to the user may depend on the user type category. For example, based on the user's category, the user may be restricted to receiving certain firm orders, accepting certain firm order matches, etc. In one embodiment, for example, only a buyer participant can receive a firm order inquiry. In such a situation, information about possible transaction fulfillment with the OMS order may not be provided to the buyer participant until the transaction is accepted by the buyer participant and / or until the transaction is fulfilled.

  In some embodiments, rebates and fees may be granted as described above. In some embodiments, such rebates and / or fees may depend on the participant's category. For example, in some implementations, an investor may be given a rebate for submitting a firm order. In other embodiments, rebates may be granted to anyone who submits a firm order. In some embodiments, a broker may be charged each time an OMS order matches a firm order inquiry. In some implementations, brokers may stop from matching their firm orders against other brokers' firm orders by pricing rebates that the broker can pay to submit firm orders.

  In some embodiments, participant size and other characteristics may affect participant options. Some implementations may limit, for example, large participants and other implementations to small participants, and other embodiments may allow participants of all sizes.

Possible Negotiations Some embodiments described above perform a transaction without negotiation between participants in the transaction (eg, a buy-only or reject / ignore option presented to the participant with a matching OMS order) Such embodiments may include negotiation. Such negotiations may be restricted in some embodiments to retain anonymity, facilitate entry of OMS orders, and / or limit the likelihood of market operations.

  For example, in some embodiments where there are multiple matching orders, a negotiation may be performed to determine the counterparty willing to adjust the offer.

  In some embodiments, if a user accepts a matching firm order found from a query, the user and / or purchaser of the firm order may be presented with an option to trade more securities. By selecting a controller in the interface that activates such an option, a negotiation can be initiated between the two participants. Such negotiations may involve asking whether the other party agrees on more transactions, terms of such transactions, etc. Such negotiations may limit the potential for market manipulation because participants can already recognize each other from previous transactions.

Rebates Some embodiments may include providing a rebate or fee for a participant's transaction. Such fees and / or rebates may be configured to stimulate participation in certain aspects of the trading system. For example, in some embodiments, if an order is fulfilled based on a firm order that matches the OMS order, the participant who submitted the firm order receives a rebate and charges the participant associated with the OMS order. Can be imposed.

Transaction types Some embodiments may support various types of transactions. Such transactions may include buying securities, selling securities, short-term selling of securities, and / or any other desired type of transaction. In some embodiments where a short-term sale of a security is performed, a place to buy / borrow the security may be required before the short-term selling order can be completed.

User Tracking Some embodiments may include tracking information about one or more participants. For example, the transaction history, number of transactions, transaction type, transaction characteristics, etc. of the buying and / or selling participants may be tracked. In some implementations, participants may view some or all of such information about themselves and / or other participants. In some embodiments, such information may be used to generate a participant rating. Such a rating may be used, for example, as a filter for participants who query the participant server.

  The embodiments described herein generally include computer-human interaction (eg, through an interface), but other embodiments may be fully executed through the computer (eg, the computer responds to firm order queries, etc.). I can accept that.

  Although the embodiments described herein generally include a variety of securities transactions, it should be appreciated that other embodiments may be used to trade any desired goods or services.

Some Information Revealed In some embodiments, one or more participants may be given some, but not all, information about pending orders. Such information may be provided as a way to stimulate, for example, the submission of orders by participants and / or taking some action. In some implementations, the pending order may include a firm order and the participant may include a participant with an order at the OMS. In other embodiments, the pending order may include an order at OMS and the participant may include any participant (e.g., a participant examining the current order, a participant with an OMS order, a firm order) Etc.) In some implementations, participants to whom such information is told may include buyer participants. In such an embodiment, the buyer participant, for example, submitted an OMS order associated with the pending order and then submitted a firm order associated with the pending order without having to submit their own order. Information may be provided at a later time and / or after any other desired event.

  In some implementations, some information may include information about one or more pending orders that do not include all information about the pending orders. For example, the information may include that one or more orders for the financial instrument are pending. The information can be, for example, which side is holding the order, who was the order submitted, the quantity of the order, the price of the order, and / or any other information. In other embodiments, some or all of such information may be provided and other information may be reserved. In some implementations, the information is sufficient to invite a participant who may be interested in a transaction involving a pending order to perform one or more actions, but other participants The impact on the behavior of the person may be limited to limit legitimate trading behavior (eg, limit market operations).

  In some implementations, if a participant whose information is shown takes one or more specific actions, additional information about the pending order may be provided to that participant. For example, if an order for a financial instrument is submitted, an OMS order is converted to a firm order, a positive response to an OMS query is guaranteed, etc., the remaining information about the pending order is provided. obtain. Using such a method that provides some but not all of the information before the action is taken, it can stimulate participants to take certain actions and obtain the rest of the information (eg, initial information If acquired). In some implementations, tracking OMS orders, order history, and / or any other information about the participant, and whether providing some information may facilitate one or more actions Can be used to determine In some embodiments, market conditions can be tracked and one or more actions can provide the necessary liquidity for the market (eg, can facilitate the submission of a firm order if there are no firm orders) It can be determined whether or not.

Non-Confirmed Order FIG. 11 shows another embodiment. In some embodiments, an indication of a non-confirmed order may be received from the first participant indicated by block 1101 (eg, via a communication network or the like). Non-confirmed orders may define one side of a transaction (eg, want to buy, sell). Such instructions may be received from an order submitter (eg, a selling trader). In some embodiments, receiving such an indication may be similar to receiving an order (eg, as described with respect to process 300. In some embodiments, non-confirmed orders are described above with respect to process 300. In some embodiments, a process similar to process 300 adds the action of confirming the transaction to the submitter of the non-firm order before facilitating the performance of the transaction. In some embodiments, such a process may differ from the process 300 in any number of ways, In some embodiments, non-firm orders are facilitated to trade to fulfill the order. Confirmation before purchase may include orders to buy or sell financial instruments that are uncertain.

  In some embodiments, an indication of a non-confirmed order may be received and in response to receiving a search for a matching order. If a matching order is found, instead of facilitating fulfillment in response to finding a matching order, the non-confirmed order may be confirmed before performing such promotion. If such confirmation is received, the performance of the transaction may be facilitated.

  Some embodiments may determine whether orders that match non-firm orders are stored in the order management system and whether to accept an offer that enters a transaction that satisfies at least a portion of each of the non-firm orders and the matching orders. May be included. As described below, such a determination may include, for example, sending one or more queries, receiving a response, and any other action. In other implementations, such determinations may include other operations such as searching one or more databases.

  In some embodiments, after receiving an indication of a non-firm order, one or more queries may be sent (e.g., if a matching firm order is not found using the query process as described above, Etc. in parallel with the search for matching firm orders). The query may include whether an order matching the non-firm order is stored in the order management system, as shown in block 1103 and / or each non-firm order and matching order, as shown in block 1105. One may ask whether an offer to enter a transaction that satisfies at least a portion is received (eg, as in process 500). In some implementations, a single query is accepted, for example, whether a matching order is stored in the order management system, whether a matching order is stored in the order management system, and the offer is accepted. May be sent to a computer system configured to interpret a single query asking whether or not (eg, by a trader associated with an order management system). In some implementations, sending the query determines whether a matching order is stored in the order management system and determines whether an offer to enter a transaction associated with the order is accepted. Sending a query to a system configured to respond to the query (eg, the participant system described above) only if a matching order is stored in the order management system and the offer is accepted .

  In some embodiments, such inquiries identify that the order is a non-confirmed order (e.g., a text description is included in the instructions provided to the trader due to the color scheme of the instructions provided to the trader). (E.g., by including an icon in the instructions provided to the trader, including a flag or other indicator in the transmitted data, etc.). In other embodiments, such inquiries treat non-confirmed orders as if they were firm orders (eg, do not identify non-firm orders as firm orders; For example, by not providing any distinction between firm and non-firm orders).

  In some implementations, as shown in block 1107, an instruction to accept a non-confirmed order may be received (eg, from the queried participant). Acceptance of the non-firm order may identify that the trader agrees to enter a transaction that satisfies at least some of the firm orders stored in the order management system and at least some of the matching orders. Acceptance may indicate that the trader agrees to enter the transaction (eg, without any further negotiation).

  In response to receiving an acceptance indication or other determination, a request to confirm the non-confirmed order may be sent to the submitter of the non-confirmed order, as shown in block 1109. The confirmation request may include a response request, a request not to respond, a request for information identifying whether the submitter has an obligation to confirm, a request for information identifying a situation that invalidates the confirmation obligation, and the like. In some implementations, the confirmation request may be similar to a request to accept a firm order that includes an order that matches the firm order.

  In some embodiments, an indication of confirmation of a non-confirmed order may be received, as indicated at block 1111. The instructions may include, for example, an instruction to conduct a transaction, an instruction that a non-confirmed order is still available, an instruction that the submitter of the non-confirmed order agrees to finalize the non-confirmed order, It may include an indication that one or more events have occurred or have not occurred, an instruction to accept a matching order, and / or any other instruction. In some implementations, confirmation may be similar to accepting a firm order that includes an order that matches a firm order. It should be appreciated that in some implementations, if an indication not to confirm a non-confirmed order is not received, the non-confirmed order may be considered confirmed. Confirmation may include an agreement to enter a transaction associated with the non-firm order.

  In some embodiments, if such confirmation is received, as shown in block 1113, the fulfillment of the transaction may be facilitated. If such confirmation is received, the participant may be notified that the transaction will be fulfilled.

  In some embodiments, the queried participant may have a non-confirmed order inquiry due to the possibility that the submitter of the non-confirmed order may reject the transaction and the participant may use the information about acceptance to influence the market. You may not want to respond to In some embodiments, not all traders can submit non-firm orders. For example, in some embodiments, a non-firm order that meets one or more desired characteristics may be submitted. Such features may reflect the probability that the submitter will manipulate the market and / or confirm the accepted matching information. Examples of such features may include the submitter transacting on behalf of another person, the submitter not transacting on their own account, or the trader agreeing to one or more restrictions. . In some embodiments, all traders may be able to submit non-firm orders, and participants may block inquiries from some types of non-final order submitters and / or It may be possible to establish a filter that only allows inquiries from non-confirmed order submitters.

  In some embodiments, submitters of non-confirmed orders may be asked / requested to agree to one or more restrictions associated with non-confirmed orders. For example, such restrictions may affect the circumstances when the non-firm order submitter confirms and / or does not confirm the non-firm order and / or any other aspect of the confirmation process. In some implementations, the submitter of a non-confirmed order is matched at least one of the orders is canceled, at least a portion of the order is satisfied, and at least one of sending or receiving a confirmation request. You may ask and / or request to agree to confirm the order unless the order you want (or part of the matching order accepted in response to the inquiry) is no longer available. Some embodiments may include receiving an indication of such agreement from the submitter of the non-confirmed order before allowing the submitter to submit the non-confirmed order. In other embodiments, other restrictions may be established regarding when a non-confirmed order submitter does not need to confirm a non-confirmed order. In some implementations, such limitations may be limited only for a limited time after submission and / or receipt of non-confirmed orders. For example, in some embodiments, such a limitation may only apply for the first 30 seconds. In some implementations, the time may be similar to the shot clock time, as described below. In other embodiments, there may be no such time limit.

  Some implementations may include determining whether one or more restrictions are met. Such a determination may include receiving information identifying a situation that satisfies such a restriction, or information identifying that such a restriction is satisfied. For example, in some implementations, a determination of whether an unconfirmed order has been canceled may be made based on information received about canceling the non-confirmed order. For example, if the submitter of a non-confirmed order receives at least one request for canceling the non-confirmed order from the purchaser of the non-confirmed order, the non-confirmed order is not requested. If processed by the submitter of a firm order, it can be canceled if the scheduled time has elapsed to keep the non-firm order active. As another example, a determination of whether at least a portion of an unconfirmed order has been satisfied. A non-confirmed order if a transaction that fulfills at least part of a non-firm order is fulfilled, if at least one of the agreements to fulfill a trade that fulfills at least part of the non-confirmed order and another order is entered A portion of the non-confirmed order may be satisfied, such as when an action occurs where the submitter enters a transaction that satisfies at least a portion of another order.

  In some implementations, a firm order submitter may be prevented from making changes to prices and / or quantities associated with a transaction. In some implementations, the transaction may be facilitated without negotiation related to price and / or quantity. In some implementations, the price and / or quantity may be determined based at least in part on information in the non-confirmed order instructions, market, matching orders, inquiries, and / or any other information.

  In some implementations, submitters of non-confirmed orders may be asked / requested to respond to a confirmation request within a limited amount of time. Such time may include, for example, 5 seconds, 1/2 second, 50 milliseconds, etc. In some implementations, such a time may be too short for a human to actually confirm an order. In such an implementation, the confirmation process may be computerized (eg, the computer determines whether the order has been canceled by the orderer, or has been filled in other ways, and if not canceled or If not, you can confirm the order). In some implementations, the time may start when a confirmation request is sent, received, and / or at any other time. In some implementations, the time can include about 10 milliseconds and about 1 second. The time can include a time having a start point and an end point. In some implementations, the confirmation may be received in time, transmitted in time, etc.

  In some implementations, non-confirmed order submitters may be asked / required to follow a set of procedures for processing non-confirmed order confirmation requests. For example, a privacy policy may be applied to a confirmation request sent to a non-confirmed order submitter and / or a confirmation request received by a non-confirmed order submitter. For example, in some implementations, the process of responding to a confirmation request may be computerized, rather than allowing such confirmation to be viewed by a human. Some implementations may include receiving an indication of agreement to prevent humans from obtaining information related to confirmation of non-confirmed orders, except when non-confirmed orders are confirmed. In some implementations, restrictions may be imposed on the storage of confirmation requests. For example, in some embodiments, a computer system that responds to confirmation requests and / or otherwise processes portions of such requests may store information about the request, display information about the request, request It can be limited from the transmission of information about.

  In some implementations, the non-confirmed order submitter may provide information related to the rejection of the confirmation request. Such information may include, for example, a written proof that one or more circumstances in which refusal is permitted (eg, a document indicating that the order was canceled at a particular time, Document indicating that the time has been satisfied, etc.). Such information, in some implementations, may be used for auditing purposes to ensure that non-firm order submitters comply with established limits regarding non-firm order submission. In some embodiments, if a submitter of a non-confirmed order violates such a restriction multiple times, the fine is assessed, the submitter of the non-confirmed order is restricted from submitting the non-confirmed order, and / or Any other penalty may be offered. In some implementations, a privacy policy may be applied to such information. Such a policy prevents humans from browsing information, prevents stored information from being deleted from one or more computer systems, and information is not stored on one or more computer systems. And so on.

  In some embodiments, if an inquiry is made to a participant to determine whether there is a matching order (eg, stored in the OMS), the inquiry is for the quantity of non-confirmed orders. Only a part can be presented. For example, there may be an opportunity to fill a portion of a non-firm order in other ways (eg, through another exchange, etc.) so that the quantity associated with the firm order is filled in other ways within the desired time May be reduced to reflect less likely quantities. Thus, an offer that enters a transaction represented by a query may include an offer that enters a transaction that satisfies only a portion of a non-firm order. Some implementations may include determining that portion to present. As a specific example, in one embodiment, if an unconfirmed order for 100 X stocks is received, the order submitter determines that there is a 99% chance that he will still be looking for 90 X stocks in 30 seconds. Thus, one or more inquiries for 90 X stocks may be sent to one or more participants. In various embodiments, certainty, amount of time, and other characteristics may be varied. In some implementations, such a determination may be made based on historical data related to financial instrument liquidity, current market conditions, open orders on other exchanges, and the like. In some implementations, when a confirmation request is sent to a non-confirmed order submitter, if the remaining portion of the non-confirmed order is left unsatisfied, one or more counterparties to the transaction will receive the remaining An option may be given to present partial trading offers to the other party. In some implementations, one or more algorithms, including any number of variable inputs, some of which are described above, may be used to determine the portion to be presented. In some implementations, the presented portion may include a portion that is expected to be confirmed by the submitter of the non-confirmed order. The portion that is expected to be verified may include a portion that is likely to be available at a future time (eg, based on algorithms, past information, guesses, etc.).

  Some embodiments may include one or more systems that interact with systems configured to perform the methods as described above. Such implementations may include, for example, sending instructions for non-confirmed orders (eg, after entering an interface, after receiving from an orderer, etc.). Some implementations may include receiving an instruction defining a firm order that matches a non-firm order. This indication may be received from a system configured to find matching orders in the contents of a plurality of order management systems, as described above. Some implementations may determine whether a non-firm order is available for a transaction involving a matching firm order (eg, whether it has not been canceled or otherwise filled) May be included. If an order is available, some implementations may include sending a confirmation (eg, within a certain time, in accordance with various agreed restrictions, etc.). Confirmation may include an indication that the transaction should be fulfilled without negotiation for price and / or quantity. In some implementations, the interface or system may prevent negotiations from taking place, for example, by blocking one or more communication media during the time.

Trading System Interactions Some embodiments may include interacting with one or more trading systems. In some implementations, such a trading system may include an alternative trading system. Alternative trading systems may include non-exchange trading venues. Non-exchange trading venues may include, for example, trading venues where only secondary trading of financial products takes place. The ATS may maintain an order book, determine the matching of orders in the book, and fulfill the transaction. In some embodiments, the ATS may include a system that operates in accordance with the Securities and Exchange Commission Rules ATS and / or Federal Regulations Chapter 242, 300-303. FIG. 12 illustrates an example embodiment that may include interaction with one or more ATSs. While the examples are described in connection with alternative trading systems, it should be appreciated that other embodiments may include any trading system, including exchanges. In exchange, primary and secondary transactions of financial instruments may be possible. Similar to ATS, an exchange may hold any number of financial instruments and / or any number of order books associated with an order. As shown in FIG. 11, a trading system 1201 (eg, an alternative trading system) may couple to one or more participants 1203 through one or more communication networks 1205. Such bonding has been described above. The operations of the example participants and the example trading system are also described above. In some embodiments, as shown, the trading system may be coupled to one or more alternative trading systems 1207 through one or more communication networks 1209. Each alternative trading system 1207 may store information about the order book 1211 associated with the alternative trading system 1207. The order book may include a collection of pending orders for one or more financial instruments. The order book is a queue of orders ordered based on any priority, a database of orders keyed based on any priority, and / or any other order or unordered order May include any other collection. Each of the alternative trading systems may couple to one or more customers 1213 through one or more communication networks 1215. The customer may submit information about the order and / or store information about the order in order book 1211 and / or receive from an alternative trading system 1207 associated with the stored order. A customer may include computer systems, people, and / or any other entity that may participate in a transaction. Communication networks 1205, 1209, and / or 1215 may include the same or different communication networks. The order book includes at least one of a database, a queue, a list, and a collection.

  FIG. 13 illustrates an example method 1300 that may be performed in some embodiments. Method 1300 may be performed on one or more computers, such as a computer of trading system 1201.

  As indicated at block 1301, the method 1300 may include receiving an indication of a pending order in an order book (eg, 1211) of an alternative trading system (eg, 1207). This indication may be received from an alternative trading system (eg, 1207) through a communication network (eg, 1209). An order may define a financial instrument, one side of a transaction, quantity, price, and / or any other desired information. In some implementations, if an order is stored in the order book, it may be pending in the order book of the alternative trading system. In some embodiments, an order is pending in the order book of an alternative trading system if it has not been canceled after being received by the alternative trading system, or if it is not filled in any other manner obtain.

  In some implementations, the order indication may include an indication that the order is pending in the order book of an alternative trading system. In some embodiments, such instructions can be handled in the same way as non-firm orders as described above. For example, in some implementations, if the trading system identifies a matching order, the instruction may fill the matching order when the order has not been canceled or otherwise fulfilled by another order Can be an indication of that. In other implementations, the indication may include an indication that the order is a firm order with respect to a trading system (eg, 1201). For example, in such an embodiment, if a matching order is identified by the trading system, the trading that satisfies the order and the matching order may be facilitated regardless of the matching order that is pending in the alternative trading system.

  As shown in block 1303, the method 1300 determines whether orders matching the order are stored in the order management system and whether an offer entering a transaction that satisfies at least a portion of each of the orders or matching orders is accepted. Judging may be included. Matching orders may define the opposite side of trading financial instruments. Such a determination may be similar to such a determination described above (eg, in connection with a non-confirmed order).

  In some embodiments, making such a determination includes sending a first query asking whether an order matching system is stored in the order management system, and the order and matching order. May include sending a second query asking whether to accept an offer to enter a transaction that satisfies at least a portion of each. Such an inquiry may be similar to the inquiry described above for non-confirmed orders. Such a query may include sending a single query as described above. In some implementations, such an inquiry may include identifying that the order can be fulfilled by a trading system. In some implementations, such an inquiry may include identifying that the order is associated with an alternative trading system. In some implementations, such an inquiry may include identifying that the order is not a firm order. In some implementations, such an inquiry may include treating the order as if the order were a firm order received from a participant (eg, without any other identification).

  In some embodiments, making such a determination may include receiving an offer acceptance instruction from the participant. The reception of such an instruction may be similar to the reception of the instruction described above with respect to non-confirmed orders.

  In some embodiments, the order instructions may identify the quantity of financial instrument to trade. Determining can include determining whether a smaller matching order is available. Similar to the non-confirmed orders described above, determining the availability of an order that is only part of the quantity may result in fewer instances of the offer being accepted, but the transaction may not be fulfilled. In some embodiments, a partial determination may be made. Such a determination may be made based on the probability that the quantity of financial instrument associated with the order is available, as described above in connection with the non-confirmed order. In some implementations, the portion may be based on an expected amount of time for communication with an alternative trading system. For example, if the time is long, the portion may be smaller because there may be more opportunities for the order to be canceled or otherwise fulfilled during transmission. If the time is short, the part can be large because the order can be canceled during transmission or the chances of fulfilling in other ways may be small. The time may be based on the speed of the communication network, the number of hops between the source and destination of the transmission, the protocol verification requirements, and / or any other information. Because alternative trading systems generally operate at a much faster rate and much wider bandwidth than typical computer systems, that portion can be larger than some non-firm order embodiments described above. Other features may be used to determine that portion, and some implementations may include the full amount.

  As shown at block 1305, the method 1300 may include sending an indication that the transaction should be fulfilled to an alternative trading system. Such an indication may be sent to an alternative trading system through a communication network. Such an indication may identify that a transaction should be fulfilled that satisfies at least some of the pending orders in the order book and at least some of the matching orders. In some implementations, such an indication may be sent in response to receiving an acceptance indication, as described above.

  In some implementations, an alternative trading system may fulfill the trade if the order is still in place (eg, if the order has not been canceled or otherwise filled), or other It can facilitate the performance of transactions in a form. In some implementations, the alternative trading system may provide information about the performance of the trade to the trading system and / or participants participating in the trade. Such information may identify whether the transaction has been fulfilled.

  Some embodiments may include receiving orders from a plurality of different alternative trading systems. Some embodiments may include determining whether each matching order is stored in each order management system and whether an offer that enters each trade in the order is accepted. Some embodiments may include sending each indication that each trade should be fulfilled to each of the alternative trading systems. Such a transmission may be made in response to a decision associated with each matching order.

  FIG. 14 illustrates an example method 1400 that may be performed by one or more alternative trading systems in some embodiments. Such a method may be performed, for example, by an alternative trading system that interacts with a trading system that performs a method similar to method 1300 or any other desired method or system.

  As indicated at block 1401, the method 1400 may include receiving an indication of one or more orders. An order may define one side of a financial instrument transaction. The instructions may be received, for example, from an alternative trading system customer 1213. Such customers may include seller traders, any other person or system that wants to trade financial instruments using an alternative trading system, and / or any other entity. The indication may be received through a communication network (eg, 1215).

  As indicated at block 1403, the method 1400 may include storing information about one or more orders in an order book of an alternative trading system. Storing such information may include placing the information in a database, list, queue, and / or any other structure that can store order information. In some implementations, storing such information may include placing the information in an order queue for the financial instrument. In some implementations, if an alternate trading system receives a matching order, the next order in the order queue may be used to trade with the matching order. Such an order book may be associated with a matching engine that determines whether matching orders are pending and facilitates the fulfillment of such orders. The matching engine may include software and / or hardware that facilitates the determination of matching financial product orders.

  As shown in block 1405, the method 1400 may include sending an order indication to a trading system (eg, 1201). Such an indication may be transmitted through a communication network (eg, 1209). The indication may be similar to the indication received at block 1301 described above.

  As shown in block 1407, the method 1400 may include receiving an offer acceptance instruction that enters a transaction that fulfills at least a portion of the order. This indication may be received from the trading system. Such an indication may be similar to the indication sent in block 1305 described above. The indication may identify information about the matching order sufficient to allow the alternative trading system to fulfill the order and the transaction involving the matching order. The instructions may indicate that the transaction should be fulfilled. The indication may indicate that the transaction should be fulfilled if one or more conditions are met. In such an embodiment, such conditions may include that an order is available. In some implementations, such conditions may include that the order has not been canceled and / or that the order has not yet been fulfilled. In some implementations, matching orders can fill only part of the order. In other implementations, matching orders may fill the entire order.

  As shown in block 1409, the method 1400 may include determining whether an order is available. In some implementations, determining whether an order is available may include determining whether the order is in the order book (eg, by searching the order book). . In some implementations, determining whether an order is available may include determining whether the order has been canceled. In some embodiments, determining whether an order is available is whether the order has been fulfilled in another manner (eg, by a previous order identified by an alternative trading system). May be included. An order may be fulfilled in other manners, for example, if another matching order was previously submitted to the alternative trading system before the matching order was identified by the trading system.

  Some embodiments may include determining whether an acceptance has been identified by a trading system before a matching order is identified by an alternative trading system. Such an embodiment may include determining whether an acceptance is identified by an alternative trading system before a matching order is identified by the trading system. Identifying an order or acceptance may include an act of fulfilling or accepting the resulting order. For example, if an instruction for a matching order is received by the first alternative trading system, if a matching order is stored in the order book, the matching engine of the first alternative trading system causes the matching order and the first If one order is identified, if the first order is received from the order book, if the matching order has been processed by the first alternative trading system, and / or any other desired If an action is taken, matching orders may be identified. As another example, when an acceptance instruction is received by the second alternative trading system, three acceptances when the acceptance instruction is sent from the second alternative trading system to the first alternative trading system Accept if the instruction is received by the first alternative trading system, if the acceptance instruction is processed by the first alternative trading system, and / or if any other desired action is taken Can be identified.

  In some embodiments, if an acceptance of an offer that enters a transaction that fulfills at least a portion of the order is identified by the trading system before an order that matches the order is identified by the alternative trading system, the transaction is Can be fulfilled. In some embodiments, if an order that matches an order is identified by an alternative trading system before an acceptance is identified by the trading system, the matching order and a trade that satisfies at least a portion of the order may be fulfilled. . In some embodiments, no transaction may be fulfilled if a cancellation is identified before an accepted or matching order.

  As indicated at block 1411, the method 1400 may include facilitating fulfillment of a transaction that satisfies at least a portion of the order if it is determined that the order is available. Various examples that facilitate implementation are discussed herein. In some implementations, an alternative trading system may fulfill the trade.

  Some embodiments may include providing information about performance to one or more customers, participants, trading systems, and / or any other entity.

  Some embodiments of a trading system (eg, 1201) require an operator of an alternative trading system to accept certain restrictions before participating in a method, such as method 1300 and / or method 1400, and / Or ask. In some such implementations, the restriction may be, for example, if acceptance of a transaction associated with the order is identified through the trading system before the order is canceled or otherwise fulfilled. It may include fulfilling the transaction. The restrictions may include that an alternative trading system is used for non-owner trading (eg, at least some, primarily, to some extent, exclusively, etc.). Some implementations may be limited to alternative trading systems that meet some or all such requirements. Some implementations of alternative trading systems may include providing an indication of agreement for such restrictions. Some implementations of the trading system may include receiving such an indication. Similar instructions have been described above in connection with non-confirmed orders.

  In some embodiments, an alternative trading system sends information about all orders to the trading system, sends information about some orders to the trading system, and orders that meet certain characteristics to the trading system. Any other set or subset of orders sent and / or associated with an alternative trading system may be sent to the trading system. For example, in some implementations, an alternative trading system may send information to the trading system about orders for financial instruments that are not frequently traded through the alternative trading system. In other implementations, the alternative trading system may send instructions to the trading system for orders that exceed a certain size. In yet other implementations, the alternative trading system may send instructions to the trading system for orders for financial instruments that are orders that exceed a certain number of pending orders within the alternative trading system. In other implementations, any feature set may be used to determine which, all, and / or which orders should be sent to the trading system. In some implementations, an operator of an alternative trading system may establish such characteristics and control the alternative trading system to provide only such desired information.

  In some implementations, the trading system may have direct and / or semi-direct access to an alternative trading system's order book. Such access may include, for example, access to a copy of the order book, access to a database or other representation of the order book, and / or any other access to the order book and / or copy of the order book. . The trading system may use such access to obtain information about orders in the order book. In such an embodiment, the trading system may proactively search the order book for order information without waiting for instructions from an alternative trading system. Such a search may be performed, for example, by querying a database, querying a copy of an order book, sending a query to an alternative trading system, and / or performing any other operation. In some implementations, an alternative trading system may receive and process the query. The processing of the query can be part of the process of responding to the query. In some implementations, an operator of an alternative trading system may establish features related to orders that the trading system may obtain from an order book, similar to the features described above. The trading system may follow such characteristics in determining which order in the order book to obtain.

  In some implementations, access to the order book may be provided through an SSL link. In some implementations, access to the order book may include authentication to a trading system that maintains the order book. Such authentication may include authentication using a password, IP address, username, and / or any other information.

  In some embodiments, the trading system may be coupled to multiple other trading systems. The trading system may allow other trading systems to access the orders received by the trading system (eg, access the order book and send information about the orders in the order book, etc.). In some implementations, such a trading system may determine which of a plurality of trading systems identifies an order that matches the order (eg, from one or more of the trading systems). Based on the information received). Based on such a determination, the trading system may fulfill a transaction that satisfies at least a portion of the order. The trade may satisfy at least a portion of the matching order initially identified by the trading system (eg, one of the plurality of trading systems and / or the trading system).

  It should be appreciated that FIGS. 12, 13, and 14 are provided as examples only, and that other embodiments may include different methods and / or systems.

Shot Clock In some embodiments, a limit may be imposed on the action of a firm order submitter for a period of time after such order is sent and / or received. For example, the cancellation of a firm order by a firm order submitter during a first time may be limited for a period of time after receiving a firm order instruction that defines one side of the transaction. The amount of time may include an amount of time that allows the participant to query and respond. In some embodiments, such time can be, for example, from about 20 seconds to about 1 minute, about 5 seconds, and the like.

  In some embodiments, if a firm order is accepted during the first time period, it satisfies at least a portion of the order, even when a request to cancel the order has been received prior to acceptance. Can promote transactions. If the inquiry is rejected during that time, the firm order cannot be canceled yet until the time expires.

  In some embodiments, after a first time, if a matching order is not determined to be stored in the order management system, and / or before the first time elapses (ie, ends), If the person does not decide to accept the order, cancellation of the firm order may be permitted.

  In some implementations, limiting may include limiting the ability to perform a cancel operation. For example, limiting can include preventing an action from taking place during a time period (eg, preventing the action from being performed). Restricting may include imposing a penalty on taking action. Some implementations may, for example, impose a fine on participants for cancellation during the first time. Some implementations may completely prevent cancellation during the first time. Some implementations impose a limit on cancellations during the first time and no restrictions after the first time. In some implementations, for example, if a cancellation request is received during the first time, the cancellation request may be ignored. In some implementations, if a cancellation request is received during a first time, the request may be queued and processed at the end of the first time until the first time ends (eg, If the order is not accepted before the end of the first time, the order may be canceled). In some implementations, cancellation may include order cancellation, order cancellation, order invalidation, and the like. In some implementations, allowing may include generating an action with or without a penalty.

  In some implementations, limiting the cancellation of firm orders during time may prevent information leaks about orders pending at the OMS. For example, in other embodiments, firm orders are either (a) determined that there is no matching order with any participant, or (b) all sent to participants with matching orders. The query may be canceled if it receives a negative response or if time has elapsed. In some embodiments, option (a) takes a short amount of time (eg, less than 1 second) and option (b) takes a variable amount of time depending on how quickly the participant answers the query. obtain. Thus, if option (a) occurs, the firm order submitter can cancel the order quickly, but if option (b) occurs, the firm order submitter will have passed some somewhat longer amount of time. Until you can't cancel the order. By taking such time, the firm order submitter may be able to understand whether there is a pending matching order based on the amount of time to wait for cancellation. By requesting a standard level (e.g., 20 seconds, 1 minute, etc.) before cancellation is allowed, the firm order submitter will not understand the difference between these different situations and may leak to the firm order submitter. Less information about the contents of the OMS. An indication of the remaining period of time may be displayed to the submitter (eg, through the interface). An end of time indication may be displayed to the submitter (eg, through the interface). In some implementations, a standard amount of time determined before receiving an order instruction may be used as the first time.

  In some embodiments, the time that cancellation is limited may be determined randomly for one or more firm orders. Such random time may mimic the time the participant responds. In some implementations, the time may be randomly determined between a shortest time and a longest time (eg, 5 seconds to 20 seconds, 5 seconds to 1 minute, etc.). In some implementations, such time may be displayed to the submitter of the firm order (eg, as a countdown clock, etc. through the interface). In some embodiments, an indication that the end of the period has been reached may be sent to the submitter (e.g., by playing a tone by changing the color instead of the time in addition to the time, the interface Etc.).

  In some embodiments, the remaining amount of time for the first time and / or an indication of whether the first time has passed may be sent to one or more participants. In some embodiments, the remaining amount of time for the first time before an order can be canceled may be displayed to the query recipient (eg, a clock is displayed in the interface window and the query is displayed). May include instructions). In some implementations, an indication that the time has expired may be displayed to the recipient of the query (eg, the window color may be changed, the icon displayed, the remaining amount of time displayed, etc.) ). In some implementations, after the time expires, the query indication may be deleted from the interface (eg, the window may be closed or deleted from the interface). In some implementations, the recipient may respond to the query after time, but the firm order may be canceled before processing such a response. In some implementations, if the firm order is canceled, the inquiry instructions may be deleted (eg, deleted from the interface, window closed, etc.).

  In some embodiments, an indication of whether the first time has passed may be provided to a firm order submitter. Such an indication may include an amount of time until the time expires, an indication that the time has not yet passed, an indication that the time has changed, and so on.

  Some implementations may include a system configured to interact with a system as described above. In some implementations, for example, information about firm orders may be accepted (eg, through an interface). In some implementations, instructions for firm orders may be sent (eg, to a system configured to find orders that match firm orders in multiple order management systems). Some implementations may include providing an indication of when a firm order cannot be canceled (eg, to a trader who submitted information about a firm order through an interface, etc.). Some implementations may include receiving an indication of time (eg, from the system that submitted the order, etc.). In some implementations, the indication may include an interface color scheme, an indication of the remaining amount of time for the first time, and the like.

  In some embodiments, order cancellation may be limited as described above and / or in any other manner. When an order is submitted, some embodiments may determine whether cancellation for that order should be restricted. Determining whether cancellation should be restricted may include determining whether several orders have been submitted prior to the order. Some orders may include orders that meet certain criteria, some of which are described below. In other embodiments, the decision about the restriction of cancellation may be made randomly. For example, each order may have a 10% opportunity with limited cancellation. A random number generator or other method of random selection may determine whether order cancellation should be limited. It should be appreciated that any method of making such a determination can be used and the examples are non-limiting.

  After submitting several orders, some implementations that limit order cancellation may maintain a count of submitted orders. For example, such an embodiment may limit cancellation for every 20th order submitted. In some implementations, cancellation of other orders (eg, not the 20th order) may not be restricted. In some implementations, cancellation of other orders may not be constrained unless an order that matches the other order is identified (eg, within an order management system). Such constraints on other orders may be during certain times that give participants associated with the order management system the opportunity to accept or reject the order. Even if no matching order is identified, the cancellation of the order (eg, the 20th order) may be limited. Thus, the submitter of the order may not know whether a match has been found based on whether cancellation is restricted.

  In some implementations, several other orders may be submitted. Other orders may be handled as described elsewhere herein. In some implementations, the number can be any desired number. For example, the number can be 20 orders. In some implementations, the number can be a random number. The number can be determined periodically. The number can be determined randomly. The number can be determined by simulating random market behavior.

  In some implementations, all other orders may be submitted from the same submitter (eg, the same submitter as the order (eg, 20th order)). Each submitter may be tracked to determine whether that number of orders has been submitted by the submitter. In other embodiments, that number of orders may be submitted from different submitters.

  In some implementations, other orders may include all submitted orders (eg, by one participant, by many submitters). In other implementations, other orders may include orders that meet one or more criteria. For example, in some implementations, other orders may include only orders that are not fulfilled (eg, within a certain time after submission). In some embodiments, the other orders include at least one of (i) an order for which no matching order was found in the order management system and (ii) an order for which an offer to enter the order transaction was not accepted. May be included.

  Some embodiments determine that no matching order is stored in an order management system associated with any of a plurality of participants in one or more of the other orders. Can include. In such an embodiment, the cancellation of each such other order may not be limited. In some such implementations, the cancellation of each such other order may be limited only until the determination is made, but not beyond that point. Such a determination can be made in about 100 milliseconds or less.

  In some implementations, a determination may be made whether a matching order is stored in the order management system. In some implementations, an order database may be searched to make such a determination. In some implementations, such a determination may be made, for example, based on whether an indication that a matching order is stored in the order management system is received. In some implementations, participants can be queried as discussed elsewhere herein. In some implementations, the participant may be configured to send an indication that a matching order is stored in the order management system. Such an indication may be sent regardless of whether the offer has been accepted, unlike some embodiments discussed herein.

  In some embodiments, cancellation of all orders may be limited to make an initial decision. The time to make a decision can be minimal (eg, less than about 100 ms). In some implementations, participants can be queried to make a decision. Each participant may respond with an indication of whether matching orders are stored in the order management system associated with each participant. In some implementations, no response may be an indication of a default value (eg, no response before the end of an initial period means that no matching order has been stored). In some implementations, if any participant is determined to have a matching order stored in the order management system, the cancellation during a period of time may be limited so that if the participant desires, May be able to accept orders. If it is determined that a matching order is not stored, execution of cancellation may be permitted after the determination. In some implementations, depending on the situation (eg, if such a restriction decision was made as described above, or if some orders were submitted earlier), the matching orders are stored. Cancellation can be limited as if it were determined to have been. Such restrictions can make it difficult for the submitter to determine whether a matching order has been found.

  As described above, in some embodiments, if it is determined that an order is stored in the participant's order management system, the cancellation during a period of time is limited, thereby allowing the participant to respond to the offer. You can do so. The time can be about 5 seconds. In some embodiments, if it is determined that such an order is not stored in the order management system, cancellation may not be restricted except in certain circumstances, as described herein.

  Some embodiments may include determining that any of the plurality of participants does not accept an offer that enters each of the first transactions defined by one or more of several orders. Such a determination may be made based on whether an instruction to accept such an offer has been received (eg, from a participant as described above).

  In some embodiments, other orders may be limited to orders with one criteria set or any combination of two or more criteria sets. For example, in some embodiments, the number may be an accepted order, an order with no matching order, and an order with a matching order that was not accepted. In other implementations, the order can be any subset or other set of such orders. Orders that do not meet such criteria may not be included in the order count in some implementations to determine whether order cancellation should be restricted.

  As described above, when it is determined that the cancellation should be restricted, the cancellation can be restricted during the first time, and the cancellation can be permitted after the first time. As described above, this time can be a random time. In other embodiments, the time can be a fixed time (eg, about 5 seconds).

  In some implementations, before the end of the first time, it may be determined that an order that matches the order is not stored in an order management system associated with the plurality of participants. Such a determination may have no effect on the end of time. Rather, in some implementations, the restriction may continue despite no orders matching the order.

  It should be appreciated that the various examples above are non-limiting and other methods of restricting orders may be used. Such a restriction may limit the ability of an order submitter to determine whether a matching order exists based on the ability to cancel their order.

Alternative to opportunity loss (Miss Alternatives)
In some embodiments, it may occur that one party (eg, a buying participant) loses the opportunity to trade on an order from another party (eg, a firm order from a selling participant). For example, depending on the situation, the buyer participant may be busy with other things or away from the desk when order instructions from the order submitter are provided to the buyer participant (eg, through a computer interface). Sometimes. In such situations, the firm order may be canceled, fulfilled, or otherwise deactivated before the buyer participant has the opportunity to respond to the instructions. In some embodiments, a party, a buyer participant in this example, etc., may be provided with an opportunity to submit information related to the trading intent for the financial instrument after such a lost opportunity. In some embodiments, submitting such information may allow a party to use information obtained by receiving an order instruction. In some embodiments, submitting such information may limit opportunities for information leakage about the interests of the parties.

  In some embodiments, for example, a party who has lost the opportunity to participate in a transaction related to an order for a financial instrument may become a financial instrument and / or an alternative financial instrument as described elsewhere herein. Submit requests to participate in related transactions. In some implementations, the request may identify one or more financial instruments, order submitter, financial instrument quantity, time, price, and / or any other order characteristics. In some implementations, an interface may be provided to the party so that the party can identify any desired transaction characteristics. In various embodiments, some additional examples of such features include whether the order must be from the same submitter as the original order, whether the order must be a firm order, request May be the time at which the transaction should be valid, the highest and / or highest price of the transaction, the pricing method of the transaction, and / or any other desired information. In some embodiments, the trading system may receive such a request from the participant system. In some embodiments, if an order that meets the order characteristics is received in time, a transaction to fulfill the order may be fulfilled on behalf of the party that submitted the request without confirming the request with the party.

  Various embodiments may include a system configured to grant such an opportunity to a party, a method of granting such an opportunity, an instruction set that, when executed, causes the system to perform such a method, etc. . In some embodiments, such a system or method may allow a party who has lost the opportunity to participate in an order transaction to still make some information available without the risk of large information leaks. For example, depending on the situation, there may be a correlation between an initial order for an active financial instrument and a later order for the same financial instrument that is active within a certain amount of time. In some embodiments, a party may use the information that the original order was active at one time to participate in the transaction if it becomes active again during another order or the same order. You can submit a request to

  In some embodiments, if multiple parties wish to take advantage of such trading opportunities, various methods may be used to determine which party may be preferred. For example, some methods may use FIFO methods, LIFO methods, order size based methods, price based methods, and / or any other method. Various priority determination methods are described elsewhere herein.

  In one example, an initial order may be submitted. The order can be displayed to the participants. Presenting may include presenting a time when the initial order cannot be canceled. The order may be canceled before this time has elapsed and the party has the opportunity to respond to the instructions. In this case, this party may be provided with an indication that the order is no longer available and another possible opportunity to participate in the transaction of the financial instrument. This party may submit a request to fulfill an order transaction with a desired feature set that has been active for some time. The original order submitter may resubmit the order and facilitate fulfillment of the order if the order becomes active again during that time. In some implementations, other orders of the same or different price, quantity, orderer, and / or other characteristics may be used. The parties may be notified of order fulfillment.

  Although some of the above embodiments may be considered with respect to human traders involved in trading, various embodiments may not include such human traders and may be performed by a computer system. I want to admit that. For example, in some embodiments, a computer system may be configured to perform algorithmic trading and respond to various order instructions and trading opportunities. In another example, some computer systems may be configured to automatically send a request to participate in a specific trading opportunity as a default. In another example, some computer systems may be configured to provide a single click interface that allows a human trader to indicate that the computer system should participate in a trading opportunity. As yet another example, in some embodiments, a computer system may allow a trader to establish default values for order features and / or to change or enter features through an interface.

  Some embodiments may include receiving an order instruction. Various examples of such receipts, instructions, and order types (eg, firm orders, non-firm orders, etc.) are described elsewhere in this specification. In some embodiments, such an order may be received from an order submitter (eg, a selling participant, a buying participant, etc.). In some embodiments, an order may define one side of a financial instrument transaction. In some embodiments, the indication may indicate that the order is an active order. Active orders may include orders that have not been canceled or otherwise fulfilled. In some implementations, the indication may identify the quantity of the financial instrument. In some embodiments, the instructions may be received by a trading system from a computer system (eg, a seller participant system).

  Some embodiments may include determining whether an order that matches the order is stored in an order management system associated with the participant. Examples of order management systems and examples of how such orders can be determined to match other orders are described elsewhere herein. In some embodiments, such a determination may be made by a trading system and / or a participant system.

  Some embodiments may include limiting order cancellation. Various examples of such limitations are given elsewhere in this specification. In some embodiments, such a restriction can be made over a period of time. Some embodiments may include determining such a time. In some embodiments, such a determination may include randomizing such a determination. Various examples of determining time are given elsewhere in this specification. In some embodiments, such a restriction may be placed on orders that did not receive an indication. In some embodiments, the restriction may be performed by a trading system.

  Some embodiments may include providing order instructions to participants. This instruction may be provided to the buyer participant, for example. In some implementations, the indication may identify a time when cancellation is limited. Various examples of providing participants, instructions, and order instructions to participants are given elsewhere in this specification. In some embodiments, the instructions may be provided by a trading system and / or a participant system.

  Some embodiments may include determining that the order is no longer an active order. In some implementations, determining that the order is no longer an active order is determining that the order has been canceled, determining that the order has been at least partially fulfilled, and / or other It may include making any desired judgment. In some embodiments, the determination can be made by a trading system.

  Some embodiments may include determining that a firm order has been canceled (eg, by the submitter of the order). Determining that an order has been canceled may include determining whether a cancellation request has been received. In some embodiments, order cancellation may be performed after a certain amount of time. Various examples of cancellation and cancellation timing are given elsewhere in this specification.

  Some embodiments may include providing an indication that the order is no longer active. Some embodiments, providing such an indication may include providing an indication that the order has been canceled. Such instructions may be provided to participants who are provided with order instructions. In some implementations, such an instruction may be provided in response to determining that the order has been canceled and / or is no longer available. In some embodiments, such instructions may be provided by a trading system and / or a participant system.

  Some embodiments may include receiving an instruction to fulfill the transaction. The transactions may include the same and / or similar transactions as indicated by the orders provided to the participant, as described above. In some embodiments, the indication may identify the time at which such performance is required. Some embodiments may receive such an indication after a determination is made that the order is no longer active. Some embodiments may receive such an indication after an indication that the order has been canceled is provided. Some embodiments may receive such instructions from participants. In some embodiments, such instructions may be received by a trading system from a participant system. In some embodiments, such an indication may include a quantity of financial instruments and / or an indication of alternative financial instruments. In some implementations, the quantity may be at least a portion of the quantity defined by the order described above. In various embodiments, the instructions may define various characteristics of the order.

  Some embodiments may include receiving an order instruction. The order instructions may include the same order instructions as previously received, as described above. In some implementations, the orders may be different orders. In some implementations, the order may be an order for the same or different quantities of the same or different financial products (eg, alternative financial products to financial products). As described elsewhere, in some implementations, one financial instrument may be replaced with another financial instrument. In some implementations, the indication may identify that the order is active. In some embodiments, the orders may be the same order as described above, another order, an order from the same order submitter as the other orders, an order from a different order submitter, an order of the same quantity, a different quantity of It can be an order or the like. In some implementations, the instructions may be received during the time identified by the submitted order, as described above. In some embodiments, the indication may identify the quantity of financial instruments and / or financial instruments that can be replaced with financial instruments. In some implementations, the quantity may include at least the same quantity as at least a portion of the quantity that fulfills the transaction, as identified above, as identified by the instructions. In some embodiments, the order may include various other features that may or may not match the characteristics of the instructions to fulfill the transaction described above. In some embodiments, the instructions may be received by a trading system and / or a participant system.

  In some embodiments, a determination may be made whether the characteristics of the order match the characteristics indicated by the instructions to fulfill the transaction. In some embodiments, such features may include price or other price mechanisms, quantities, financial instruments, etc. Various price mechanisms have been described above. In some embodiments, such a determination may include a determination that the order and the request match. In some embodiments, such a determination may be made by a trading system and / or a participant system. Various examples for making matching decisions are described elsewhere.

  Some embodiments may include facilitating the fulfillment of a transaction. Implementation may be facilitated without confirmation from the participant who submitted the instructions to perform the transaction described above. In some embodiments, the promotion may be performed in response to receiving an order instruction. Promotion may be performed in response to determining that the order is met. Various examples of facilitating implementation are described elsewhere herein. In some embodiments, such promotion may be performed by a trading system and / or a participant system.

  Some embodiments may include providing an indication that the transaction has been fulfilled. For example, such instructions may be provided to each party involved in the transaction. Various examples of providing such instructions are given elsewhere herein.

  The various operations described may be performed by one or more trading systems, participant systems, and / or any other computing system.

  Some embodiments may include receiving an order instruction. In some embodiments, the instructions may be received by a participant system (eg, from a trading system). In some embodiments, the order may be an order in which a matching order exists in an order management system associated with the participant system.

  Some embodiments may include providing order instructions. In some embodiments, such an offer may include an indication to a trader (eg, a buying trader). Such provision may be performed by a participant system.

  Some embodiments may include receiving an indication that the order is no longer active. Such an indication may be received by a participant system (eg, from a trading system).

  Some embodiments may include providing an indication that the order is no longer an active order. In some embodiments, such provisioning may include an indication to a trader. Such provision may be performed by a participant system.

  As described elsewhere herein, the participant system may display various information to the trader as desired. Such information may include the status of the transaction, a clock to inform the time, etc.

  Some embodiments may include receiving an instruction to fulfill the transaction. Such an indication may be received by the participant system. In some implementations, a trader may enter such instructions through an interface. Such instructions can include various characteristics of the transaction. In some embodiments, such features may be input by a trader through an interface.

  Some embodiments may include sending an instruction to fulfill a transaction when an order for a financial instrument becomes active. In some embodiments, such instructions may be sent from the participant system to the trading system.

  Some embodiments may include receiving an indication that an order for a financial instrument has become active and has been executed in response. In some embodiments, such instructions may be received by a participant system from a trading system.

  Some embodiments may include providing an indication that the transaction has been fulfilled. Such provision may include an indication to a trader. In some embodiments, a participant system may perform such provisioning.

  Although the above description may include an example of providing information to and / or receiving information from a human trader, it will be appreciated that various other embodiments may not include any trader at all. I want to be. For example, various embodiments include various algorithmic trading systems. Accordingly, various information may be received from and / or provided to a computer system that implements a trading algorithm and / or any other computer system. In various implementations, such a system may perform any desired operation.

Fund Participants In some embodiments, one or more funds (eg, mutual funds, bond funds, stock funds, index funds, active funds, commodity funds, listed investment funds, etc.) may participate.

  Some such funds may use the OMS system and participate in the same way as other participants in the OMS system, as described above (eg, a buyer participant). Other fund participants may not use such an OMS system and / or may not want to provide access to such an OMS system. In some embodiments, fund composition publications may be used to determine the type and / or information of queries to send to fund participants.

  In some embodiments, an indication of the fund's composition may be received (eg, as a publication printed on the fund's guide over a communications network, etc.). The composition of a fund may include multiple financial products owned by the fund (eg, a stock list owned by a mutual fund, etc.). The composition may include the amount of each financial instrument that is owned or desired to be owned by the fund. The composition may include a target percentage of funds comprised of each financial instrument. The composition may include a snapshot view of the fund at a specific point in time, a desired future point in time, etc.

  Composition instructions can include any information from which at least a portion of the fund composition can be determined. For example, the fund's composition may include written text about the desired components of the fund's target composition, as can be found in published guides. In some embodiments, the composition instructions may be obtained from a third party or the like, directly from the fund manager, from a website that tracks fund information. The instructions may include information from multiple sources that are interpreted together to identify the composition.

  Interest in transactions associated with a particular financial instrument may be approximated / identified based on the fund's composition and / or any other information (eg, price changes). For example, in some implementations, one or more orders for buying or selling financial instruments may be received. For one or more such orders, it may be determined whether the financial instrument defined by the order is part of the fund's composition. Such a determination may include comparing the financial product with the composition (eg, searching for the composition of the financial product, searching the database, etc.). If the financial instrument is part of the fund's origination, the fund manager (for example, something or someone who has the ability to enter a transaction on behalf of the fund) will be able to enter into the transaction to fulfill the financial instrument order and the matching order. An inquiry may be sent asking if you want to enter. Sending the inquiry, in some embodiments, as discussed above, inquiring the fund's order management system, sending the inquiry to the trader or machine operated by the trader, and / or in any other manner May include requesting acceptance.

  In some implementations, an inquiry may be sent to the fund only if the composition indicates that the fund has a certain amount of financial instrument. For example, an inquiry can be sent to a fund asking if the fund is interested in a transaction to sell financial instruments only if the composition indicates that the fund has enough financial instruments to fulfill the order . In some embodiments, the fund holds some minimum threshold percentage of the product (eg, fund structure) only if the fund holds any other threshold amount of financial products (eg, 1 million shares). The financial product is one of the top of the financial products that make up the fund (for example, one of the top 10 components of the fund) Only and / or any other set of filters may be used to send the query.

  In some implementations, price changes of one or more financial instruments within the fund's composition may be used to determine whether to query the fund for transactions. For example, in some embodiments, a price change for a financial instrument defined by an order may be determined. Such price changes may be based on the time the composition is received, the time that the composition identifies, etc. Such changes may be determined based on past and current information about the price of the financial instrument (eg, such information may be received from third parties such as stock trackers, markets, etc.).

  In some embodiments, based on the determined price change, it may be determined whether the fund operator is likely to be interested in a transaction that matches the transaction defined by the received order. If the current situation is that the operator has a high chance to accept the offer for trading, the operator will likely be interested. The manager may try to keep the fund close to, or at that level, based on the value of each financial instrument's holdings in the composition, so if the price increases or decreases, the relative value of the financial instrument's holdings Will change and the composition will return to the target level. Determining whether an operator is likely to be interested in the other side of a financial instrument transaction means determining whether a price change involves an increase in price or a decrease in price. Including. For example, if the price change includes an increase in price, it may be determined that the operator is likely to be interested when the order includes the sale of financial instruments. If the price change includes a price reduction, it may be determined that the operator is likely to be interested when the order includes a purchase of a financial instrument. Some embodiments may take into account price changes of other financial instruments within the composition for that financial instrument. Such an embodiment may take into account the relative change in the price of the financial instrument relative to the change in the price of other financial instruments in the composition (e.g., buying is necessary to bring the composition back to the target level). When deciding whether to get or sell).

  If the fund manager accepts the order, an acceptance instruction may be sent from the fund. The acceptance may be received according to some embodiments. As described above, the transaction may be facilitated in response to receipt of the acceptance.

Risk Pools Some embodiments may perform / enable participant filtering based on a participant's past behavior. For example, in some embodiments, participant responses may be tracked when inquiring participants about an order. Participants may be arranged into groups based on the frequency of positive responses to queries. For example, participants may be arranged into the following groups: participants with an acknowledgment rate of 100% to 75%, participants with an acknowledgment of 75% to 50%, and participants with an acknowledgment of less than 50% . It should be appreciated that these groups are given as examples only, and that other embodiments may include any number of groups and any arrangement of groups. Such a group can be called a risk pool. Order submitters should send inquiries about orders to one or more participants in the group and / or should not be sent to one or more participants in the group You can show that. Since sending a query to a participant reveals some information about the order, the submitter of the order uses the response rate to see from the history that it may respond positively to the exposure of that information. Can be limited to high participants.

  In some embodiments, multiple query sets may be sent to multiple participants. Each query set may ask multiple participants for each order. Each query in each query set includes whether each order matching each order is stored in each order management system associated with each participant, and whether each participant has an order and matching order. Each participant may be asked whether to accept each offer that enters each transaction that fulfills at least a portion of each. If the participant accepts the offer, a positive response / acceptance indication may be received. In some implementations, if a matching order is stored in the order management system, an indication of that storage may be received. Thus, in some embodiments, this information identifies whether a matching order is stored in the order management system and, if so, whether it has been rejected or accepted. Can do. If the order is accepted, some implementations may include facilitating the fulfillment of the transaction. In other embodiments, as described above, queries to the order management system are not used, but rather a database may be searched or any other method may be used.

  In some embodiments, multiple participants may be assigned to one or more risk pools based on the results of the query. Each risk pool may correspond to at least one acknowledgment rate for offers entering the deal. Acknowledgment rates can include, for example, a comparison of the number of acknowledgments (eg, ratios, percentages, etc.) with the number of offers (eg, offers with certain characteristics, offers associated with the submitter, etc.). Such a ratio may be used, for example, when a matching order is stored in the order management system for all queries sent to the participant and / or queries / orders having one or more characteristics. It can correspond to offers made against it. In some implementations, the acknowledgment rate includes a ratio of acknowledgments to offers that enter the transaction when matching orders are stored in the order management system. In some implementations, the acknowledgment rate includes a ratio of an acknowledgment rate to an offer that enters a transaction when a matching order is stored in the order management system and an inquiry is associated with the submitter. In some embodiments, the acknowledgment rate is an acknowledgment for an offer that enters a transaction when a matching order is stored in the order management system and associated with an order having at least one characteristic similar to the order. Includes rate ratio. In some implementations, such features may include financial instruments, quantity ranges, price ranges, market share totals, industries, types of financial instruments.

  In some embodiments, an order submitter can identify one or more risk pools that should send inquiries about the order and / or one or more risk pools that should not send such inquiries It can be. For example, a submitter may use an interface to identify such information, send an electronic message identifying such information, establish a default risk pool identifying such information, and / or Such information can be identified in any other way. Some implementations may include providing an interface that may select one or more risk pools. Subsequently, an inquiry regarding the order may be made to the participant according to such information.

  Some embodiments may include submitting instructions identifying one or more orders and / or risk pools. Some embodiments may include receiving an indication of multiple risk pools. Such instructions may be presented to the person through an interface that allows selection from among multiple risk pools. Some implementations may include receiving a selection of at least one risk pool (eg, through an interface, electronic message, etc.). Some embodiments include sending (eg, through an electronic message) an indication that an order should be queried to participants associated with the at least one selected risk pool. obtain. Some implementations may include receiving an indication that fulfillment of a transaction that satisfies the order has been facilitated. Some implementations may include providing instructions for such promotion (eg, as a display on an interface to a person, as an electronic message, etc.).

  It should be appreciated that the risk pool can be combined with any other embodiments and / or concepts described herein, and that any method and / or apparatus can be used in various embodiments.

Replaceability In some embodiments, one financial instrument may be replaced with another financial instrument. A replaceable financial product can be replaced with another product (eg, satisfying the same reason for existence, having similar characteristics, etc.). For example, if the order is for a first financial instrument, the second financial instrument may be used instead of the first financial quotient to fill the order. The order can be a pending order in the order management system, an order submitted by a selling participant, and / or any other type of order. For example, a participant who wants to buy a stock of a carbonated beverage company may enter an order to Coca-Cola, but that order will satisfy a desire to buy a stock of a carbonated beverage company, a PepsiCo stock, Coca-Cola's It can be filled with bonds, derivatives related to Coca-Cola, future contracts for carbonated beverages, etc. Various criteria / tests may be used to establish whether one financial instrument can be replaced with another financial instrument. Participants can identify which financial instruments can be substituted for each other. Exchange rates for financial instruments may be established based on prices and / or various participant wishes.

  As described above, some embodiments may include receiving order instructions. The order may define one side of the first financial instrument transaction. The indication may include an indication of one or more other financial instruments that can be replaced with the first financial instrument to satisfy the order. The instructions may identify characteristics of such other financial products (eg, market capitalization, industry, product type, etc.), specifically list other financial products, and / or such other financial products. May include any other information that may identify In some implementations, such features may include industry, financial instrument type, market book, enterprise, and / or any other feature.

  As described above, some embodiments may include determining whether matching orders are stored in an order management system associated with the participant. As described above, such a determination may include sending one or more queries. The matching order may be for the first financial instrument or for another financial instrument. For example, in some implementations, the matching order may be for a different financial instrument that can be replaced with the first financial instrument. The order management system may identify which financial product can replace the financial product for the matching order. For example, the first financial instrument may be a Coca-Cola stock and the matching order may be for a PepsiCo stock. The order management system may identify that Coca-Cola can be replaced with PepsiCo. Such identification may be made directly through the list of replaceable products, may be made through assets with features that identify replaceable products, and / or may be done in any other manner.

  In some implementations, if the order is for a quantity of a first financial instrument and the transaction that satisfies the order is for a replaceable financial instrument, the quantity of the traded product and / or the product is a transaction. The price made may not be the same as that identified by the order for the first financial instrument. For example, an order for Coca-Cola 100 stock may be filled with a PepsiCo 50 stock trade. The quantity and / or price at which the trade was made may be identified by the order management system (eg, the OMS may identify a set of exchange rates between financial instruments). The quantity and / or price at which the transaction took place can be identified from the market price (eg, using the market price of these two financial instruments, the recent transaction price, the current bid and / or offer, the intermediate price, etc. , Can determine the exchange rate of those financial products). The price and / or quantity may be determined in any other way.

  As described above, the trader may be presented with an offer to enter the transaction. The transaction may include a transaction for the first financial product, even if the matching order is for a different financial product. In other embodiments, the transaction may include other financial products even if the order is for the first financial product. A trader may accept or decline such a transaction.

  In some embodiments, an order acceptance may be received (eg, when a trader accepts an offer). Acceptance may indicate that a transaction that satisfies the order should be fulfilled. Responsive to receipt of the acceptance may facilitate fulfillment of a transaction that satisfies the order.

  From the perspective of a participant having an order in the order management system, an order instruction for the first financial instrument may be received. It may be determined whether an order that matches a second financial product that can be replaced with the first financial product is stored in the order management system. Traders may be required to have a legally binding acceptance of entering a transaction that fulfills an order and a matching order. Some embodiments provide an interface that may require legally binding acceptance, send a request for legally binding acceptance (eg, through an electronic message and / or legal And any other method of requesting a binding contract, which may be a transaction of the first financial instrument even though the matching order is for a different financial instrument. In this embodiment, the transaction can be a transaction of another financial instrument, even though the order is for the first financial instrument, only when an acceptance is received (eg, from a trader, etc. through an interface). ) May facilitate the performance of the transaction.

  It should be appreciated that substitutability can be combined with any other embodiments and / or concepts described herein, and that any method and / or apparatus can be used in various embodiments.

Order Grouping In some embodiments, a trading system (eg, an alternative trading system) may receive an indication of a first order. The first order may be received, for example, from a participant (eg, a buyer participant, a seller participant, a proprietary trading system, etc.). Participants may include any system that submits order information to and / or receives order information from the trading system. In some implementations, the first order may define a desire by the participant, trader, and / or another person or program (eg, customer, algorithm, etc.) associated with the participant.

  In some embodiments, the trading system may receive instructions for one or more second orders. Each of the second orders may define each such transaction that the participant is willing to enter if it can result in fulfillment of the first transaction by entering one or more transactions.

  In one example, a participant may wish to buy a stock of company X. The first order may include, for example, an order to buy a certain number of shares of company X brand. The participant is willing to buy Company Y or Company Z stocks as well, but only if the purchase of Company Y stock or Company Z stock results in the purchase of Company X stock. The second order may include, for example, an order to buy a certain number of shares of company Y or a certain number of shares of company Z. It should be appreciated that in some implementations, two or more of the second orders can enter a transaction (eg, company Y and / or company Z, not company Y or company Z).

  The indication of the first order may be anything that can derive the first order (eg, electronic message, multiple packets, message identifying the first order characteristics, directly identifying the first order Message etc.)

  The indication of the second order may be anything that can derive one or more second orders (eg, identifying an electronic message, multiple packets, one or more second order features) Message, one or more messages directly identifying the second order, etc.). In some implementations, a separate message may be received that identifies one or more second orders of the larger plurality of second orders. In some implementations, a single message that identifies multiple second orders may be received.

  In some implementations, the second order may be identified by the characteristics of the financial instrument. For example, a plurality of second order instructions may include one or more types of instructions for financial products (eg, claims, shares, etc.), one or more industry instructions (eg, financial services, manufacturing, etc.) One or more domain instructions (eg, US companies, European companies, etc.), one or more market share totals instructions (eg, small capital, large capital, etc.), and / or any other Any other indication of the feature may be included.

  In some embodiments, the trading system may determine one or more second orders based on the indicated characteristics. For example, the transaction system may determine that the receivable of company Y and the receivable of company Z satisfy the characteristics. Thus, in such an example, orders for company Y and company Z may be determined.

  In some embodiments, an indication of a second order relationship may be received. For example, the relationship may include exclusive OR, inclusive OR, and AND and / or any other kind of regular expression is applied to the second order so that any second order is for the participant. It should be judged whether it can be satisfactory.

  In some embodiments, the quantity of financial instruments associated with the first order and the one or more second orders may be related. For example, in some implementations, quantities can be related to a common cash value. For example, in some implementations, the first order and the second order may be orders for a quantity of financial instruments having a substantially similar amount of value. Such a valuation can be based, for example, on the market value when the order is placed. In one implementation, for example, the first order may have an associated quantity, and the quantity of the second order may be the same dollar value as the second order (eg, the same dollar value, the second order May be set based on the dollar value of the first order so that the order is a dollar value that is closest to the dollar value of the first order, but the transaction size.

  In some implementations, the order instruction may include a dollar amount. For example, in some implementations, the second order includes a dollar amount indication. In some implementations, the dollar amount includes the dollar amount associated with the first order and the present value of the financial instrument associated with the second order.

  In some implementations, the processor may be configured to limit cancellation of the first order and the second order over a period of time. The processor may be configured to determine that time. As described above, the period may be determined so as to obscure the situation, or may be determined randomly or the like.

  In some embodiments, the trading system may determine whether one or more other participants want to execute a trade that matches the first order. Judgments may include retrieving submitted firm order sets, querying one or more participants, and the like.

  In some embodiments, the trading system may determine whether the participant wants to enter a trade that matches one or more second orders. The example given here is for a second order with an OR relationship, but it should be appreciated that other relationships may be used in other embodiments. In this example embodiment, such a determination may be performed concurrently with such a determination, etc., if it is determined that no participant wants to execute a transaction that matches the first order. Such a determination may include, for example, searching a firm order set, querying one or more participants, and the like.

  In some embodiments, if one or more participants are determined to enter a transaction that matches one or more second orders, each such participant may receive one or more An offer to enter a transaction that satisfies one or more of the second order and the first order may be presented. In other embodiments, the determination may include making such an offer.

  For example, in some implementations, a firm order set may be received from various participants. A firm order may be searched for an order that matches one or more orders. If a match is found, an acceptance request to enter a transaction that satisfies the first order may be sent to each participant associated with the matched firm order. In some implementations, the request may include one or more second orders.

  As another example, in some implementations, a query set is sent to the participant, whether the order is stored in the OMS associated with the participant, and whether the participant wants to enter the transaction. Can be judged. The inquiry may include an inquiry about entering a combined transaction that satisfies a first order and one or more second orders. Multiple such queries may be sent to each participant depending on the number of second orders.

  As yet another example, in some implementations, information about the contents of the OMS can be known without remote query (eg, from a database). In such an implementation, such a database may be searched for orders that match one or more second orders. Inquiries about the first order to be fulfilled in combination with the matching order may be sent to participants who have a matching order.

  In some embodiments, the trading system may receive an instruction to accept a first order from a participant, and the instruction may include an instruction to accept one or more second orders. In some implementations, in response to receiving the indication, the trading system may facilitate fulfillment of a transaction that satisfies a first order and a transaction that satisfies one or more second orders.

  Some embodiments may include systems that use program-to-program communications. The system may comprise a first processor configured to execute a first program, the first program placing a first order that defines one side of a first transaction for the first financial instrument. Receiving a first message indicating, receiving a second message indicating a second order defining one side of a second transaction relating to the second financial instrument, the participant order management system receiving a second message A first message requesting acceptance of entering the first transaction and entering the second transaction is determined to include a third order that defines the opposite side of the second transaction with respect to It may be configured to perform sending to the program, facilitating fulfillment of the first transaction and the second transaction. The system may include a second processor configured to execute the second program. The second program receives the first message from the first program, provides an acceptance request to the computer operator in response to receiving the first message, and indicates an affirmative response from the operator. And in response to receiving a positive response, the second message may be sent to the first program.

Automatic Execution In some embodiments, participants may be configured to perform automatic acceptance of transactions. Automatic acceptance may include accepting without human confirmation. Confirmation may include a separate indication that the transaction should be entered.

  In some implementations, a participant (eg, a computer processor, etc.) may receive an instruction to accept an order without confirmation. An order may define each side of a financial instrument transaction. A participant may receive any number of such instructions for each order. The indication may include a request to perform an action or a request not to perform an action. Execution may be conditioned on the occurrence of one or more events and / or satisfying one or more parameters.

  In some implementations, the participant may store information identifying the side of the transaction on a machine readable medium. Such storage may include storing information in a database, such as may be accessed later.

  Information may include data that is meaningful to a machine configured to interpret the data.

  In some implementations, participants may receive order instructions from a trading system (eg, an alternative trading system). An order may define the trading side of a financial instrument. In some implementations, the indication may include an inquiry from a trading system.

  In some implementations, the participant may determine whether the information is stored on a machine-readable medium and whether the order instructions are relevant to that side of the transaction for the financial instrument. It should be appreciated that this is given as an example only. In other examples, the stored information may include the reverse side, or may identify any aspect of the order in any manner in any manner. A match between the stored information and the received order can be determined in any manner. The order and information identify the opposite side, identify the same side, or identify any other desired combination of information in any way the participant is configured to determine a match Can match. Such a determination may include comparing at least a portion of the information and the side of the transaction.

  In some implementations, if it is determined that the information matches the order, in response to the determination, a request to facilitate the performance of the transaction may be sent to the trading system. In some implementations, the request may include an acceptance instruction in response to the query.

  In some implementations, sending the request may include sending the request after a waiting period. The processor may determine a waiting period between the shortest time and the longest time. As described above, the waiting period may be determined so as to obscure the situation, or may be determined randomly or the like.

  In some implementations, if no matching information is stored at the determined location, some implementations determine whether the matching order is stored in an order management system associated with the participant. Can be judged. If such a matching order is not stored in the order management system, a request for legally binding acceptance may be presented to the user, as described in detail elsewhere.

  In some embodiments, operations may be performed in a trading system rather than performing some operations at a participant. For example, the trading system may receive instructions from a first participant (e.g., an order management system) that enter the trading side of the financial instrument. Information identifying the side of the transaction and the first participant may be stored in a data structure such that the participant cannot obtain that information. Such information can be subjected to, for example, encryption and access restriction. The trading system may receive order instructions from the second participant. An order may define the opposite side of a transaction for a financial instrument.

  In some implementations, the processor of the trading system may determine that the information and order are involved in the reverse side of trading the financial instrument. In response to this determination, the trading system may facilitate the performance of the transaction. Such implementation may be performed without inquiring the participant. The trading system may send a notification identifying the performance of the transaction to the first participant and the second participant. Such a notification may be sent in response to the determination.

  Such embodiments include multiple computer systems for distributed processing. A first computer receiving an instruction to accept without confirmation an order defining a trading side of a financial instrument; receiving an order instruction defining a trading side of a financial instrument from a second computer; To determine whether the order is involved in the financial instrument trading side, and if it is determined that the information and order are involved in the financial instrument trading side, in response to the determination, Sending a request to facilitate fulfillment to the second computer may be performed. The second computer receives information defining the order, sends an order instruction to the first computer, receives a request to facilitate fulfillment, processes the request and uses the order to fulfill Determining whether or not it is possible, and if it is determined that the order is available for fulfillment, may be configured to perform in response to the determination to facilitate fulfillment of the order.

Order Part fulfillment In some embodiments, a trading system (eg, an alternative trading system) may split an order into multiple parts. The trading system may receive order instructions. An order may define the trading side of a quantity of financial instrument. It should be appreciated that in such a system, information about the complete order size by a participant can be limited to dissemination to other participants. As will become apparent from the description below, in some implementations such information may be limited to participants who have established automatic acceptance of orders for financial instruments.

  In some embodiments, the trading system may send each indication of each part of the order to each of the plurality of participants. The transmission may include a query as described elsewhere herein. In some embodiments, the sum of the parts can be the above quantity. In some embodiments, the sum of the portions may be less than the quantity (eg, 10% of the quantity, 50% of the quantity, 1% of the quantity, etc.).

  In some embodiments, one or more of the participants may accept an offer to enter a transaction that satisfies each part of the order in response to the transmission. An acceptance instruction may be received by the trading system.

  In some embodiments, in response to receiving such an acceptance, the remaining instructions for the order may be sent to the participant. The remainder may include, for example, the amount of orders that were not accepted by other participants, the amount of orders that were not sent to other participants, and / or any other amount.

  In some embodiments, sending the remaining instructions may include sending the remaining instructions after a waiting period. The processor may determine a waiting period between the shortest time and the longest time. As described above, the waiting period may be determined so as to obscure the situation, or may be determined randomly or the like.

  Some embodiments may include determining whether a certain amount of time has passed after sending the partial instructions and before sending the remaining instructions. In some such embodiments, the offer that enters each part of the transaction may only be valid during that time. In some implementations, the time may include 1 second, 10 seconds, 10 milliseconds, 50 milliseconds, and / or any other amount of time. In some implementations, the time may be configured such that if the participant is configured to automatically accept a partial order, an automatic acceptance may be received within that time. In some implementations, the time may be configured such that if a participant is configured not to automatically accept a partial order, the likelihood that an acceptance will be received within that time.

  In some embodiments, one or more acceptances of each portion may be received in time. In some implementations, a transaction that fills each portion may be facilitated in response to receipt of the acceptance. In some implementations, the remaining instructions for the order may be sent to each participant who received the receipt of each part in time, at the end of time, and after the end of time. The remainder may include the quantity of financial instruments that were not satisfied by the accepted portion.

  It should be appreciated that sending the indication may include sending any information. For example, transmission of the part / remaining instructions may include querying the participant as described elsewhere herein.

  In some implementations, a participant (eg, a computer system) may be configured to interact with such a trading system. For example, the participant may receive an indication of trading intent. Such a transaction intent may identify that if one receives an offer to enter a transaction for one or more financial instruments, he wishes to enter such a transaction automatically (ie, without human confirmation).

  In some implementations, the participant may receive an indication of an order part. The indication may be received from a remote processor through a communication network. The remote processor can be part of a trading system. The order part indication may include a request to enter a transaction that satisfies the order part. The part of the order may be the part of the order for the trade that matches the trade intention.

  In some implementations, the participant may determine that the order is for the other side of the transaction. In response to the determination, the participant may send an acceptance of the part of the order. Participants may be configured to transmit within a specific time. The time can be determined by the remote processor. The time can be, for example, 1 second, 10 seconds, 10 milliseconds, 50 milliseconds. The time may start when a partial instruction is sent to the participant, received by the participant, processed by the participant, and / or any other time determined. The time may end when the acceptance instruction is received by the trading system, when the acceptance instruction is sent by the participant, and / or at any other time determined.

  In some implementations, the participant may receive instructions for the rest of the order. In some implementations, the participant may provide an interface through which a trader can accept the rest of the order. In some implementations, the participant may automatically accept the rest of the order.

Intentional Delay In some embodiments, a trading system (eg, an alternative trading system) may intentionally delay operations related to orders. For example, in some embodiments, an order submitter may use an order to identify interest about or potential information about a potential counterparty. Delays in taking action in such cases can reduce information leakage about potential opponents. As another example, in some embodiments, a participant is involved in a non-confirmed order if the non-confirmed order is canceled or otherwise fulfilled and does not lead to fulfillment of the transaction with the participant. Can react adversely to order inquiries. In such cases, delaying in taking action may reduce the adverse reaction of the participant.

  As described above, some embodiments may include receiving order instructions from a source. The order may include a firm order. The order can include non-confirmed orders. Sources can include participants. Sources can include brokers.

  Some embodiments may include determining an intentional delay time. This delay may include a delay between a first time associated with the order and a second time associated with identifying a matching order. For example, the delay may include a delay from receiving an order instruction until identifying an order that matches the order. As another example, the delay may include a delay between submitting an order and sending an order inquiry.

  This time may be specifically determined for each source. The time can be specifically determined for each risk pool. The time can be specifically determined for each type of source. The time can be a universal time for all sources. Time may be specifically determined for each financial instrument. Time can be specifically determined for each type of financial instrument. The time can be determined for each range of queries. In various embodiments, any combination of source, financial instrument type, and / or quantity may be used. Some embodiments may exclude specific orders and / or sources.

  In some embodiments, the time may be determined such that an intentional delay in time may avoid information leaks regarding existing orders. Existing orders may include pending orders within one or more OMSs associated with one or more participants. For example, in some embodiments, it may be determined that an order canceled within 10 seconds of receipt has the potential to cause a much greater information leak. In some embodiments, the identification of matching orders may be delayed for such 10 seconds, thereby canceling such orders without causing information leakage. In other embodiments, any other time may be used, such as 10 milliseconds.

  Some embodiments may include determining a time based on historical information. For example, such historical information may include information about canceled orders. In some embodiments, the time may be determined such that some portion of previously canceled orders have been canceled within that time. In some embodiments, such portions may include a majority of canceled orders. In some embodiments, such portions may include a desired percentage of canceled orders. For example, the first order is canceled 5 ms after receipt, the second order is canceled 8 ms after receipt, and the third order is canceled 1 second after receipt In some implementations, the time may be determined to be about 9 milliseconds. In some embodiments, such canceled orders may include orders with certain characteristics.

  Some embodiments may include intentionally delaying over time. Intentional delay may include intentionally not acting to find an order that matches the order. Intentional delay may include intentionally not querying one or more OMSs and / or participants. Intentional delays may include delays that exceed the delays introduced by transmission and / or machine processing.

  Some embodiments may include determining that time has elapsed. Such a determination may be made at the end of time. Such a determination may be based on a clock, such as a processor clock and / or several clock cycles. Such a determination may include determining that time has elapsed since the first time associated with the order.

  Some embodiments may include identifying matching orders in response to determining that time has elapsed. As described above, in some embodiments, identifying matching orders may include querying one or more remote systems. In some embodiments, identifying a matching order sends an order query identifying the order to each of the plurality of systems and provides an indication of the matching order from a first system of the plurality of systems. Receiving. Each of the plurality of systems may include a participant system. Each order management system may be associated with each of a plurality of systems. In some embodiments, such an inquiry may indicate that the transaction is fulfilled without negotiation (eg, negotiation involving price and / or quantity).

  Some embodiments may include facilitating the fulfillment of a transaction in response to identifying matching orders. In some embodiments, facilitating fulfillment may include confirming the non-confirmed order with a source associated with the non-confirmed order, as described above. Some embodiments include receiving an indication of an agreement that the source confirms the non-confirmed order except when at least one of the non-confirmed orders is canceled and when the non-confirmed order is satisfied. obtain. In some embodiments, facilitating performance may include facilitating performance without negotiating price and quantity.

  It will be appreciated that the above description of operations is given by way of example only, and that other embodiments may include any desired sequence of operations, additional operations, and / or alternative operations as desired. I want.

Trading System Cooperation Some embodiments may include two or more trading systems (e.g., an electronic marketplace such as an alternative trading system) that cooperate with each other to fulfill one or more trades. In such collaboration, for example, one electronic market can be used by one or more other electronic markets.

  FIG. 15 shows an example of two electronic markets 1501 and 1503 that can cooperate with each other. The first market 1501 may include a trading system as described herein, and the electronic market 1501 may query one or more participants to identify matching orders. Second electronic market 1503 may include any desired market in any configuration capable of performing primary and / or secondary transactions in any desired manner. In some embodiments, the first electronic market and the second electronic market may communicate with each other through one or more communication networks. Such networks may include facilities and / or dedicated networks. Such networks can include public networks such as the Internet.

  In some embodiments, financial information exchange (FIX) messages may be used to send information from one electronic market to another.

  As shown in FIG. 15, order source 1505 may be coupled to first market 1501. For example, order source 1505 may communicate with first electronic market 1501 through one or more communication networks. In some embodiments, order source 1505 may include participants and / or order submitters. In some embodiments, the order source may include a firm order submitter. In some embodiments, the order source may include a broker (eg, a computer system associated with the broker).

  FIG. 16 illustrates an example method 1600 that may be performed in some embodiments (eg, to facilitate cooperation of two or more trading systems as shown in FIG. 15). Method 1600 may include a method by which an electronic market interacts to facilitate the performance of a transaction. The method 1600 may be performed by the first electronic trading system of FIG. As shown, the method 1600 may begin at block 1601.

  As shown at block 1603, the method 1600 may include receiving a first indication of a firm order from a source. The indication may be received by the first electronic market. Various examples of receiving order instructions have been described above. As mentioned above, the source may include a broker.

  As shown at block 1605, the method 1600 may include sending a second indication of the firm order to the electronic market without attempting to fulfill the firm order. Transmitting may be performed by the first electronic market to the second electronic market. A fulfillment attempt may include any typical operation of an electronic marketplace that fulfills an order in the electronic marketplace. In some embodiments, for example, the firm order may not be placed in the active order book of the first electronic market order. In some embodiments, for example, an order inquiry regarding a firm order may not be sent to one or more participants.

  In some embodiments, the second electronic market may receive the second indication (eg, through a communication network).

  In some embodiments, in response to receiving the second indication, the second electronic market may attempt to identify an order that matches the firm order.

  In some embodiments, the second electronic market may send a third indication of non-firm orders to the first electronic market in response to receiving the second indication. Non-confirmed orders can be defined by firm orders. In some embodiments, the firm order remains a firm order in the second electronic market and may be submitted to the first electronic market and / or any other desired market as a non-firm order.

  As shown in block 1607, some embodiments may include receiving a third indication of a non-firm order defined by a firm order from the electronic market. The indication may be received by the first electronic market from the second electronic market. Non-confirmed orders can include orders defined by firm orders. The two orders may be orders for the same order received with respect to the source, and both the first electronic market and the second electronic market may attempt to satisfy the same order.

  In some embodiments, the third indication of a non-firm order may include a FIX message. In some embodiments, the FIX message may include a portion that identifies a firm order. In some embodiments, such portion may include a tag in the body of the FIX message that identifies the order number of the firm order received in the second indication by the second financial market. Such information may indicate where the first financial market finds an order that matches the firm order (eg, in the second electronic market in the form of firm orders, in the first electronic market in the form of non-firm orders). In). For example, the first electronic market may have a firm order with information about non-firm orders so that if a matching order is found, the first financial market may determine that the matching order can satisfy the firm order. Identification information may be recorded.

  As shown in block 1609, some embodiments may include identifying an order that matches the non-firm order in response to receiving the third indication. The identification can be done by the first electronic market. In some embodiments, such identification may be performed by sending one or more order queries identifying non-confirmed orders to each of the plurality of systems. In some embodiments, one or more of such order inquiries may identify a non-firm order as a firm order. In some embodiments, one or more such order inquiries may identify that a transaction can be fulfilled without negotiation (eg, negotiations involving price and / or quantity). In some embodiments, each order management system may be associated with each system. Each system may include a participant system. In some embodiments, such identification may include receiving matching order instructions from a first of the plurality of systems. In some embodiments, such instructions may include identifying information that the transaction should be fulfilled without negotiation (eg, negotiations involving price and / or quantity). Various examples of identifying matching orders are described elsewhere in this specification.

  As shown in block 1611, some embodiments may include confirming an unconfirmed order in the electronic market in response to identifying a matching order. Confirmation may include the first electronic market confirming an unconfirmed order in the second electronic market. In some embodiments, confirmation of a non-firm order may include sending a request to confirm transaction performance from a first electronic market to a second electronic market. In some embodiments, the confirmation may include receiving an indication that the transaction should be fulfilled from the second electronic market. In some embodiments, an indication must be received within a certain amount of time in order to confirm an unconfirmed order. In some embodiments, if the indication is not received in time, the fulfillment of the transaction may not be performed, the non-confirmed order may be canceled, a second confirmation request may be sent, and / or any other optional A desired operation can be performed. In some embodiments, the time can include a period of about 10 milliseconds to 1 second. Some embodiments receive an indication of an agreement that the second electronic market confirms a non-firm order except when at least one of the firm orders is canceled and when the firm order is satisfied Can include. Various examples of confirming non-confirmed orders are described elsewhere herein.

  As shown in block 1613, some embodiments may include facilitating the fulfillment of the transaction. Trades may include trades defined by one or more of non-firm orders and matching orders. The fulfillment transaction may be executed by the first electronic market. Promotion of fulfillment may be performed in response to identifying matching orders in the first electronic market. In some embodiments, facilitating fulfillment may include at least one of fulfilling the transaction and sending an indication to the remote destination indicating that the transaction should be fulfilled. In some embodiments, facilitating performance may include facilitating performance without negotiating price and quantity. Various examples of facilitating transaction fulfillment are described elsewhere herein.

  In some embodiments, a second electronic market may decide to facilitate implementation. For example, in some embodiments, an indication that an unconfirmed order has been satisfied may be sent from a first electronic market to a second electronic market. Such an indication may be received by the second electronic market. In some embodiments, the second electronic marketplace may know that a non-confirmed order has been fulfilled based on confirmation of the non-confirmed order as an alternative or addition to a separate instruction. It should be appreciated that in various embodiments, any method of determining such promotion and / or performance can be used. In some embodiments, in response to such a determination, the second electronic market may cancel the firm order, mark the firm order as fulfilled, and / or take any desired action .

  In some embodiments, in response to such a determination, a fourth indication that a firm order has been fulfilled may be transmitted from the second electronic market to the first electronic market. In some embodiments, such an indication may be sent in response to receiving an indication that an unconfirmed order has been satisfied.

  As indicated at block 1615, some embodiments may include receiving a fourth indication that the firm order has been fulfilled. In some embodiments, the fourth indication may be received by the first market from the second market. In some embodiments, the fourth indication may be received in response to promoting a transaction. For example, the second electronic market may determine that the fulfillment of the transaction should occur as described above, and may send a fourth instruction in response. In some embodiments, the fourth indication may identify that the firm order has been filled in the form of a non-firm order by the first electronic market.

  In some embodiments, the fourth indication may include a FIX message. The FIX message may include a portion that identifies a non-firm order. In some embodiments, such portion may include a tag in the body of the FIX message that identifies the order number of the non-firm order received by the first financial market in the third indication. Such information may indicate where the first financial market has found an order that matches the firm order (eg, in the second electronic market in the form of firm orders, in the first electronic market in the form of non-firm orders). Etc.) can be specified. For example, the first electronic market may have a firm order with information about non-firm orders so that if a matching order is found, the first financial market may determine that the matching order can satisfy the firm order. Identification information may be recorded.

  As shown in block 1617, some embodiments may include sending a fifth indication that the firm order has been fulfilled. The fifth instruction may be sent from the first electronic market to the source. The transmission may be performed in response to receiving the fourth instruction.

  Some embodiments may include identifying which electronic market has fulfilled the firm order. Some embodiments may determine whether a firm order is filled in the first electronic market in the form of a non-firm order or in the second electronic market (eg, in the form of a firm order). May be included. Such a determination may be performed by the first electronic market. In some embodiments, such a determination may be based on information from one or more instructions, such as a portion of a FIX message that identifies one or more of a firm order or a non-firm order, as described above. Can be based. For example, in some embodiments, the first electronic marketplace may record an order number or tag associated with the firm order after receiving the firm order from the source. Subsequent communications regarding firm and non-firm orders may include such numbers or tags (eg, in FIX messages). In that case, such information may be referenced to specify that the non-confirmed order corresponds to a confirmed order.

  Some embodiments may include determining a fee to be charged to the broker based on which electronic market has fulfilled the firm order. For example, in some embodiments, if a firm order is filled in the form of a non-firm order in the first electronic market, a first fee is charged and the firm order is filled by the second electronic market. In some cases (eg, in the form of a firm order), a second fee may be charged. In some embodiments, the first fee may be higher than the second fee. In some embodiments, the second fee may be higher than the first fee. In some embodiments, there may be no charge for performance by some electronic markets. For example, a fee may be charged if a firm order is filled by a first electronic market, but no fee may be charged if a firm order is filled by a second electronic market. Such a fee may be determined based on a FIX message portion that may identify one or more of firm and non-firm orders, as described above.

  The method 1600 may end at block 1619. It should be appreciated that the method 1600 may include any desired steps in any desired order. It should be appreciated that the method 1600 is provided as an example only and that various embodiments may include any desired alternative and / or additional operations as desired. In some embodiments, the first electronic market may utilize the second electronic market algorithms and / or capacities without developing them within the first electronic market.

  While the above example refers to the entire order being filled with a single exchange, it should be appreciated that in some embodiments various portions of the order may be fulfilled with different exchanges and / or different matching orders. For example, in some embodiments, a first portion of a firm order may be utilized in a first electronic market and a second portion of a firm order may be fulfilled in a second electronic market. The fee may be determined based on the portion, for example, in proportion to the portion.

  In the above example, the order can be filled in the first electronic market, but it should be appreciated that in some embodiments the order can be filled in the second electronic market. In some embodiments, the second electronic market may attempt to find a matching order in response to receiving a firm order indication. If the second electronic market finds a matching order (eg, before the first electronic market finds an order that matches the corresponding non-confirmed order), the second electronic market fulfills the corresponding transaction. Can be promoted. The second market may cancel the non-firm order, notify the first electronic market of fulfillment, and / or take any other desired action. In response, the first electronic market may source information. As mentioned above, the fee charged for a source may depend on the location of the implementation.

XII. Various information 1
The element numbering in the following chapters may not match the element numbering in the above chapter. This section provides further disclosure of related material and should not be construed as a limitation to any previous disclosure. For example, unless defined otherwise, the following definitions should not apply to the above disclosure, nor does the preferred description apply to the above disclosed embodiments.

  Computers are heavily used to facilitate the trading of securities, but manual intervention may still be required at certain steps of the trading process. For example, most traders in organized investment management firms record orders to buy or sell securities in a computerized order management system (OMS). However, one or more traders at each farm may attempt to fill the order by manually reviewing the order in the OMS and contacting one or more market intermediaries. Typically, a trader transmits in OMS to a registered securities broker-dealer, an electronic market for trading securities, or other market intermediaries through a telephone line or a separate data entry link. Therefore, manual work is often required to actually fulfill the order in OMS.

  One problem arising from this manual work is that it may be impossible for an organization's traders to perform a transaction involving a large quantity of securities without adversely affecting the market price of the securities. For example, organizational traders often need to trade large quantities of securities due to the constant need of investment managers to respond to changes in market conditions by changing the content of the investment portfolio. As the size of these portfolios increases due to increased investor behavior, the quantity of securities to be traded correspondingly increases to achieve a similar portfolio balance. Market impact costs and adverse costs due to the behavior of an organization's traders increase in such situations as it becomes more difficult for market intermediaries to find counterparties to trade such large quantities of securities.

  Furthermore, if a market intermediary realizes that an organized farm wants to sell a particular block of equity securities, for example, this notice is the selling price that the organized farm can get through the normal supply and demand process. Tend to lower. This impact is likely to be exacerbated by speculation from others who have knowledge of the order why a particular investor wants to sell such a large quantity of securities. Similarly, if a market intermediary notices that an organized farm wants to buy a large block of specific equity securities, this awareness tends to increase the purchase price that the organized farm needs to pay. obtain. This negative impact on prices is exacerbated by the fact that traditional market intermediaries do proprietary trading.

  One strategy commonly used by organized traders to offset market impact costs is to spread large quantities of securities into small orders, each handled by different market intermediaries, possibly over several days of a trading day. It is to let you. Of course, this strategy creates its own problems in that market prices can change significantly during this lengthy trading period due to the unpredictable behavior of others.

  Another strategy that may be utilized is to spread securities orders to one or more electronic markets. However, traders may need to manually send each order to the electronic market using a telephone line or a separate data entry link. Many traders are less likely to use these electronic markets as traders may need to perform these additional steps, including double entry of basic order data already recorded in the OMS. Thus, supply to the market can be a negligible subset of the overall order. As a result, these electronic markets often lack the liquidity necessary for traders to fulfill their orders in a timely manner.

  The lack of integration between OMS and the electronic market also poses a problem if an organized trader wants to trade a particular security within the electronic market simultaneously, for example via a telephone with a traditional broker. For example, some electronic markets try to find matches only at specific time intervals. If a trader wants to buy 100,000 shares of IBM stock and puts half of that quantity on the electronic market, the trader was bought until the next scheduled matching attempt when IBM shares were bought. Never know the number of shares. Meanwhile, traders could potentially buy more than 500,000 stocks at a better price from the broker via phone.

  Therefore, there is a need in the art for an electronic trading market that does not require a large amount of manual intervention by traders or other parties, provides anonymity and provides high liquidity.

  Some embodiments provide automated (ie, manually) ordering from various order management systems (OMS) used by investment management firms or other entities that have trading systems to an electronic trading market (ETM). The above needs are met by providing transmission (without trader intervention). A farm with a trading system manages order flow and stores information about orders in the OMS for order monitoring, order placement, and order fulfillment monitoring, and for related purposes. Software that provides OMS functionality is well known in the art.

  The OMS interface module (OIM) at the farm automatically sends the order from the OMS to the ETM and preferably may update the OMS in response to fulfilling the order at the ETM. Traders can communicate with ETMs to negotiate securities transactions anonymously. The term “securities” used in this specification refers to contracts or transactions such as stock certificates, claims, or any other financial product, etc. Or any securities currency contract. In this description, the term “securities” is used for convenience, but it should be understood that this term encompasses all financial instruments. It should also be understood that other embodiments may be used for trading other goods and / or services.

  The ETM may include an OMS data integration module (ODIM) for receiving and processing data representing orders received from the OIM. In a preferred embodiment, data from OIM is provided to ETM in a standard format that requires little processing by ODIM. Data processed by ODIM may be stored in an ETM database.

  A negotiation module within the ETM may support negotiation between traders. In one embodiment, the instruction module transmits orders received by the ETM to the trader based on the filtering criteria established by the trader and / or ETM. These orders are sent to the trader in the form of legally binding instructions. Based on those instructions, traders in one organization can enter into negotiations with traders in other organizations through the ETM negotiation module. In one embodiment, at least a portion of the negotiation is performed anonymously.

  The trader authentication module may authorize and / or authenticate traders who have logged into the ETM to perform transaction negotiations and / or other functions. A transaction history module may record transactions executed by the ETM in the ETM database. The transaction history module preferably also records other data processed by the ETM, including, for example, orders sent and received from trading systems and negotiations made.

  A typical trading system at an investment management farm or other entity where trading is performed includes a number of workstations coupled to an OMS server via a network, each with a trader. Each workstation preferably executes a trader's OMS interaction module (TOIM) to facilitate interaction between the trader's workstation and the OMS server. In one embodiment of the present invention, TOIM allows traders to add, delete, or modify open or scheduled orders stored in the OMS database. An OMS includes an OMS server, an OMS database, and a TOIM, usually provided by an OMS vendor, but several farms have developed their own OMS.

  In conjunction with the present invention, each workstation also preferably executes an ETM interaction module (EIM) to facilitate interaction with the ETM. The EIM allows a trader to send information to the ETM, view information received from the ETM, and respond to that information. This information typically includes information about trader instructions, information about other trader instructions, and orders sent and received by traders during negotiations.

  The OMS database maintains data representing open orders, scheduled orders, and / or completed orders where traders buy and / or sell securities using a trading system. The OIM communicates with the OMS database and ETM. An OMS database integration module in the OIM reads the data recorded in the OMS database and, in the preferred embodiment, receives the fulfillment of the transaction through the ETM and creates and stores the data in the OMS database. Also perform data changes. In one embodiment, the OMS database integration module accesses the OMS database directly, and in another embodiment, sends a command to access the database to an application programming interface (API) within the OMS.

  The OIM may include an ETM communication module to communicate with the ETM. In one embodiment, the ETM communication module provides selected data recorded in the OMS database to the ETM, and in a preferred embodiment, data and / or instructions regarding changes to the OMS database are received from the ETM. In addition, the OIM preferably includes a data record conversion module that changes the format of data records sent to and / or received from the ETM. The OIM preferably filters a specific order by security type, security name, order type, order price, order quantity, or other category and removes the order from being sent to the ETM Including.

  In some embodiments, the OIM or any other component may include an inference module. Such an inference module may identify the reason why a particular order exists in the OMS database (eg, by receiving such information from the trader by asking the trader who entered the order, (E.g. by receiving information from the risk model associated with the trader, by analyzing the behavior of the trader by searching for strategy information that can be stored). In some embodiments, the reasoning module may be used to suggest and / or enter securities that satisfy the reason that other orders exist. Such a function can be useful if an order is not inferred and a reasonable alternative security is available.

  Preferably, the OIM sends an ETM data record in the OMS database related to the trader's order to the ETM when the trader logs on to the ETM. Once the OIM determines that the trader has logged on to the ETM, the OIM retrieves a data record for that trader's order suitable for transmission from the OMS database to the ETM. In one embodiment, the OIM converts data records retrieved from the OMS database into a standard format understood by ETM. In another embodiment, this function is part of the ETM.

  After the trader logs on to the ETM, the OIM may determine whether the contents of the OMS database have changed. If the OMS database has changed, the OIM determines whether the change should be sent to the ETM. In one embodiment, the OIM continues to determine whether the contents of the OMS database have changed during the time from when the trader logs on to the ETM until the ETM begins trading. In another embodiment, the OIM does not initiate this determination until the ETM initiates a transaction.

  Because typical OMS is complex and multifunctional, and types of securities that are not handled by ETM may be handled using OMS, some changes to the OMS database send update data to ETM Some things are not necessary. The OIM preferably sends changes to the database to the ETM if the change represents a new or changed order.

  The OIM preferably updates the database in response to information received from the ETM indicating fulfilled transactions or other information. In a preferred embodiment, when fulfillment is performed at the ETM for an order in the OMS associated with the OIM, the OIM receives information describing the fulfillment from the ETM. This information includes, for example, information identifying the original order in the OMS database on which the type, quantity, and price of the traded securities, fulfillment time, and / or fulfillment are based. The OIM converts the information received about fulfillment into the format used by the OMS and updates the OMS database accordingly. As a result of these steps, the OMS is automatically updated to transparently reflect the implementation performed at the ETM. Since fulfillment appears to the OMS as a typical transaction that takes place at another broker, no special functionality needs to be added to the OMS beyond what is described here to interact with the ETM.

  While some embodiments may be described as including “traders”, it is recognized that other embodiments may or may not include traders exactly as described. I want to be. Some embodiments may be automated through trading algorithms without including traders in negotiations, entering trades into OMS, and / or other actions. Such trading algorithms may control trader admission, trading negotiations, and / or any other action conventionally controlled by one or more traders in a trading organization.

  US Pat. No. 7,136,834 (hereinafter “Merrin”), issued to Merrin et al., Describes Merrin's specification, Merrin's filing history, and others that provide meaning to any part of the patent. Incorporated herein by reference, including any material. Accordingly, terms that have meaning in Merrin (eg, based on the specification, history of applications, other materials that provide meaning to any part of a patent, etc.) are intended to have the same meaning herein. The Accordingly, one of ordinary skill in the art will understand that Merrin and the terms used herein have the same meaning.

  FIG. 17 is a high-level block diagram illustrating an electronic trading market (ETM) environment according to an embodiment of the present invention. ETM 110 communicates with three trading systems 112A, 112B, 112C. Although only three trading systems 112 are shown, embodiments of the present invention may have much more (or fewer) trading systems 112 that communicate with the ETM 110. FIG. 17 shows only three trading systems 112 in order to enhance the clarity of this description.

  In some embodiments, the ETM may be configured to couple to other ETMs and / or other markets. For example, a particular ETM may be configured to facilitate transactions between traders coupled to that particular ETM. That particular ETM may, in some circumstances (for example, if a particular order partner is not in that particular ETM), send information about the order to another ETM and attempt to find the counterpart through other ETMs. . Thus, one ETM may be able to use orders / transactions associated with other ETMs. Sending order information to other ETMs is established after asking traders associated with a particular order whether they can accept such transmissions and / or ahead of a particular trader. Can be executed according to the trading preferences. In some embodiments, different ETMs may be configured to trade different things. For example, one ETM may be configured to trade stocks and another ETM may be configured to trade derivatives. Combining such ETMs configured to trade different things provides traders with additional products and / or services based on knowledge about orders submitted by traders, as described in more detail below. May be particularly useful in embodiments configured as such.

  Trading systems 112A, 112B, 112C are used by an investment management farm or other entity that has established a relationship with ETM 110. Trading system 112 communicates with ETM 110 to facilitate securities trading. The term “securities” used in this specification refers to contracts or transactions such as stock certificates, claims, or any other financial product, etc. Or any securities currency contract. This definition includes, for example, any note, stock, bond, bond, voluntary profit sharing agreement or any oil, gas, or other mineral resource loyalty or lease deed showing the right or participation, optional trust collateral Discretionary certificates, investment contracts, voting rights trust certificates, securities depository, securities, certificates of deposit, any of the above, securities group, or securities index (including rights to them, including rights based on their values) Includes puts, calls, straddles, options, or privileges. This list is not all-inclusive. For clarity, this discussion describes stock trading.

  Within each trading system 112 is a database 114A, 114B, 114C associated with an order management system (OMS). Each OMS database 141 uses the trading system 112 to trade open orders, scheduled orders, and / or completed orders that traders buy and / or sell securities (collectively, “orders of securities” Data) is stored. For example, database 114A of trading system 112A has an order to sell 50,000 DELL stocks, an order to sell 75,000 MSFT stocks, an order to buy 25,000 CPQ stocks, and an order to buy 100,000 stocks of IBM stocks Is assumed to be included. It is also assumed that database 114B of trading system 112B includes an order to sell 30,000 CPQ stocks and an order to buy 62,000 T stocks.

  Orders in the OMS database 114 may be automatically sent to the ETM 110. Similarly, any changes to the order, such as changes and / or withdrawals, can be automatically sent to the ETM 110. As used herein, the term “automatically” means that the associated action is performed without any human or manual intervention. Thus, the trader need not specifically request that individual orders in the OMS database 114 be sent to the ETM 110, and the orders in the database are sent to the ETM 110 without any trader input (subject to filtering criteria). .

  In some embodiments, orders in the OMS database may not be automatically sent to the ETM 110. Rather, the trader may individually select orders from the OMS database to send to the ETM 110. Depending on the trading farm, information about some of the orders stored in the OMS database may be misused if exposed, so such selective rather than automatic transmission By using secure transmissions, it may be possible for a trading farm to prevent transmission of particularly sensitive order information while allowing transmission of less sensitive order information.

  Preferably, the ETM 110 sends information about the trader's order anonymously to other traders using the ETM, subject to filtering according to the filtering established by the trader and / or ETM. In addition, the ETM 110 preferably manages anonymous negotiations between traders using the trading system 112 for order fulfillment and sends data about completed trades to the trader's OMS involved in the transaction. To do.

  Thus, one embodiment of the present invention selectively broadcasts information about orders received by ETM 110 from database 114A of trading system 112A to other trading systems 112B, 112C. Similarly, ETM 110 selectively broadcasts information about orders received from database 114B of trading system 112B to other trading systems 112A, 112C. If a trader wishes to trade such, ETM 110 facilitates anonymous negotiation and sale of 25,000 shares of CPQ from traders using trading system 112B to traders using trading system 112A.

  In some embodiments, orders from the first trader may be narrowcast to potential opponents. In order to identify which other traders are potential counterparties, the ETM can match orders from the first trader with orders received from other traders (eg, the name, type, Depending on order size, price etc.). If matching orders are provided by other traders, they can be identified as potential opponents and send information about orders from the first trader to those traders.

  Data may be communicated between trading system 112 and ETM 110 using interface links 116A, 116B, 116C. Use any known interface technology including, but not limited to, Transmission Control Protocol / Internet Protocol (TCP / IP), satellite, cellular, radio frequency (RF) link, and / or any combination thereof. These links can be implemented. The link may pass through one or more intermediate data processing systems, such as a telephone switch or an internet server, before reaching ETM 110 or trading system 112. In embodiments where data travels over a shared link, such as embodiments where data travels over the public Internet, the data is preferably encrypted using a secure protocol such as Secure Sockets Layer (SSL). .

  FIG. 18 is a high level block diagram showing more details of the ETM 110. Those skilled in the art will appreciate that FIG. 18 is only one of the possible embodiments of ETM 110. Obviously, different combinations of hardware and software can be used to provide the functionality of the ETM 110 described herein.

  Data received by the ETM 110 from the trading system 112 via the interface link 116 may be received by the firewall 210. As is known in the art, the firewall 210 preferably prevents unauthorized users from accessing the rest of the ETM 110 and monitors the transfer of data to and from the network.

  Data that passes through the firewall 210 may be received by one or more modules that perform the functions of the ETM 110. The term “module” as used herein refers to machine-executable code and / or data, but may also include associated circuitry such as processing circuitry and data storage and / or any other software or hardware. . Thus, it will be appreciated that each module shown in FIG. 18 may be implemented in one or a combination of hardware and software, such as a computer system executing software that performs the functions of the modules. It will also be appreciated by those skilled in the art that ETM 110 may include one or more other types of modules, circuits, etc. not shown in FIG. 18 to avoid unnecessarily obscuring the understanding of the present invention. It will be understood. For example, ETM 110 may include one or more microprocessors, network connection circuitry, and / or read only memory (ROM), random access memory (RAM), CDROM, DVD, tape drive, hard disk (HD), and / or others. Data storage areas such as different types of storage areas. It will also be appreciated that the functionality of multiple modules described herein may be combined into a single module, and the functionality of a single module may be divided or shared among multiple modules. Further, alternative embodiments of the invention may not have one or more of the modules described herein and / or may have modules not described herein. Good.

  The ETM 110 preferably includes an OMS data integration module (ODIM) 212. ODIM 212 receives and processes data representing orders received from OMS database 114 in trading system 112. In the preferred embodiment, data from the OMS database 114 is provided to the ETM 110 in a standardized format with little processing required by the ODIM 212. In an alternative embodiment, the data from the OMS database 114 may depend on factors such as the type of OMS used by the trading system 112, the type of interface link that supplies the data to the ETM, the type of security or order with which the data is associated. Provided to ETM 110 in one or more different formats. In this latter embodiment, the ODIM 212 preferably converts the data into a standardized format for use by other modules within the ETM 110.

  Orders processed by ODIM 212 may be stored in ETM database 214. The data in database 214 is preferably accessible by other modules in ETM 110. In addition, other modules within the ETM 110 may store other data in the illustrated database 214 or other database as may be required during normal operation.

  In a preferred embodiment, the instruction module 216 sends information about orders received by the ETM 110 to various traders based on the filtering criteria established by the trader and / or ETM. This information is transmitted to the trader in the form of a legally unbinding instruction.

  Based on the instructions, the trader may be able to enter negotiations with other traders through negotiation module 218. Negotiation module 218 may use a trading system to facilitate negotiations between traders with opposite interests. In one embodiment, at least a portion of the negotiation is performed anonymously to limit the spread of information about the trader's behavior.

  Market data module 220 may receive real-time and / or other market data from input 222. Market data module 220 may provide market data to negotiation module 218 and / or a trader. The trader preferably uses market data during negotiation to determine the market price of the security.

  Transaction history module 224 may record transactions executed by ETM 110 in database 214. The transaction history module 224 preferably includes other information processed by the ETM 110, including, for example, information about orders received from the trading system 112 and information about orders sent to the trading system 112 and negotiations performed (whether successful). The data is also recorded. This module 224 is preferably used for auditing transactions performed in the ETM 110.

  In some embodiments, the transaction history module may record transaction information as well as information about orders that have been placed but not fulfilled. Such information can be used to provide products and / or services to traders. For example, record information about the frequency of orders placed for a particular security, based on past transactions, how much market liquidity has been in the past for that security, and / or before the order is satisfied Can be used to inform traders about the time it can take. As another example, information about a particular trader's satisfied transactions may be used to hedge other purchases or other goods or services that the trader may desire, such as hedging opportunities for trading (eg, equity purchases). Information about available futures transactions on the same or different ETMs, etc.). As yet another example, some embodiments use recorded information to identify that a major change has occurred in a security's trading pattern (eg, large price drop, large liquidity change, etc.). , Using such information, performance (eg, preparation for a large increase in trading behavior, offloading orders to different markets, temporary suspension of order acceptance until trading stabilizes, etc.), Coordinate securities transactions (eg, relating to accounts / funds associated with ETM operators) and / or provide such information to traders.

  Trader authentication module 226 may verify and / or authenticate a trader who has logged into ETM 110 to perform transaction negotiation and / or other functions. In one embodiment, the trader authentication module 226 stores authentication information such as a login ID / password pair in the database 214. Trader recognition module 226 preferably also stores registered trader profiles.

  Other modules that may exist in the ETM 110 include a load monitoring module that monitors the load of various servers including the ETM, a fault tolerant module that provides fault tolerance to the ETM, a security breach to the ETM, and prevents such violations. Security modules to detect, and back office modules that provide back office functions. These modules are not shown in FIG. 18 so as not to unnecessarily complicate the figure.

  FIG. 19 is a low level block diagram illustrating a trading system 112 as shown in FIG. Those skilled in the art will recognize that FIG. 19 is just one of the possible embodiments of the trading system 12 and that there are alternative embodiments of the trading system. FIG. 19 shows three workstations 310A, 310B, 310C coupled to OMS server 312 via network 314. The workstation 310 is preferably a general purpose or dedicated computer system that executes dedicated software that facilitates the trading of securities. Although only three workstations 310 are shown, trading system 112 can have any practical number of workstations.

  In a typical trading system that interacts with the ETM 110, each workstation 310 executes a trader OMS interaction module 316 (TOIM) that facilitates interaction with the OMS server 312. In this exemplary trading system, TOIM 316 allows traders to add, delete, or modify open or scheduled orders stored in the OMS database. For example, because a trader has the intent to execute a particular transaction in stages, or a scheduled transaction is desirable only if the market price of the security to be traded is within a certain range (eg, limit order), Scheduled orders may be stored in the OMS database 114. Thus, such orders serve as placeholders that indicate the total amount of securities the trader wishes to trade and the conditions under which other orders are traded, and other data in the database 114 indicates the quantity of securities traded up to that date. Show.

  Each workstation 310 executes an ETM interaction module 318 (EIM) that facilitates interaction with the ETM 110. In an alternative embodiment of the invention, EIM 318 is integrated into TOIM 316 or other modules within workstation 310. The EIM 318 allows a trader to send information to the ETM 110 and view and respond to information received from the ETM 110. Typically, the information received includes information about the order (through instruction module 216) and orders (through negotiation module 218) that ETM 110 receives from other traders or trading organizations. Traders use EIM 318 to buy and / or sell securities through ETM 110 and trade negotiations.

  The network 314 connects the workstation 310 to an OMS 312 and an external network such as a network that communicates with the ETM 110. The network 314 may utilize any networking technology that supports bidirectional transmission of data between the OMS 312, the workstation 310, and the external network. In the exemplary embodiment, network 314 is a private local area network (LAN) that is installed in a financial organization and interfaces with one or more external gateways. In alternative embodiments, the network may be wireless, may connect devices over a wide area, and / or may carry data at least partially over a public network (such as the Internet). There may be other network components such as a firewall. Those skilled in the art will recognize that many different types of networks can perform the functions described herein.

  The OMS 312 is preferably composed of one or more computer systems that execute and maintain an order management system. OMS 312 receives instructions from the workstation to create, modify, and / or delete orders and updates database 114 accordingly. Software that provides the functionality of the OMS 312 is well known in the art. Commercial OMS software packages are commercially available from MacGregor Group, Eze Castle Software, Advanced Software, and Decalog, to name a few. In addition, some trading organizations use custom OMS software.

  As described above, the database 114 may maintain data representing open orders that are to buy and / or sell securities, planned orders, and / or completed orders. FIG. 20 is a diagram illustrating a data record 400 stored in the database 114 for identifying orders, according to one embodiment of the invention. It should be understood that because different OMS systems utilize different order data records, FIG. 20 shows only one of the possible data records. However, many OMS systems store the same general information, and the order data record 400 shown is intended to represent a typical order data record for an OMS system.

  The order data record 400 has a plurality of fields that each hold different information about the order. The order ID field 410 preferably holds a value that uniquely identifies the order associated with the data record 400. Similarly, trader ID field 412 preferably holds a value that uniquely identifies the trader or other person who placed the order. The order status field 414 identifies whether the order is open, scheduled, completed, canceled, or in any other possible state. The next field, Order Latest Update Time 416, preferably holds a time stamp that identifies the latest time that the data record 400 was modified in any manner. This field 416 is useful for determining whether the latest version of the data record 400 has been considered.

  The transaction type field 418 preferably identifies whether the data record 400 will buy or sell a security in response to the order. The stock symbol field 420 preferably uniquely identifies the security to be traded. The stock symbol field 420 may hold, for example, a Unified Securities Identification Procedure Committee (CUSIP) number, a ticker symbol, or any other identifier of a security. The security type field 422 is preferably used to interpret other data in the data record 400 according to a given security type. For example, Treasury bills are priced for discounts from face value and the pricing formula inherently includes the yield that is obtained when the securities are held to maturity. Conversely, equity securities are priced at actual stock value. The information in the security type field 422 can also be used to filter out certain types of securities.

  The order type field 424 preferably identifies whether the order is a market order or a limit order, but this field may indicate other order types. If the order is a limit order, limit price field 426 preferably identifies the price set by the trader.

  The total order size field 428 preferably identifies the actual number of shares that the trader wishes to trade. The other ordered quantity field 430 is a value less than or equal to the value in the total order size field 428. In an embodiment of the present invention, ETM 110 uses the values of these two fields 428, 430 to identify the quantity, if any, of the securities available for trading by ETM.

  Preferably, the OMS 312 allows the possibility of trading large quantities of a given security at several different venues. For example, to satisfy an order to buy 1,000,000 shares of an IBM stock, a trader places an order of 300,000 shares with a broker, and until all of the 300,000 shares issued to that broker have been purchased. It may be necessary to record the performance of many parts. If the broker is unable to provide additional shares at a suitable price, the trader may order additional quantities up to 700,000 shares to be purchased through another broker, electronic market, or other venue . Preferably, the broker enters an order record in the OMS database 114 to indicate that the trader expects fulfillment of the portion of the order through the second venue. This second venue may also meet the requested quantity with some fulfillment. As such, an order can have one or more orders, and each order can have one or more fulfillments associated with it.

  FIG. 21 is a diagram illustrating an order record 500 showing an order to a particular venue, preferably stored in the OMS database 114. The order ID field 510 preferably holds a value that uniquely identifies the order associated with the order. The order ID field 510 links ordering information to the entire order. Thus, all orders of the same order preferably have the same value in this field 510. Broker field 512 preferably includes an alphanumeric value that identifies the venue with which the order record is associated. Finally, broker order quantity field 514 preferably lists the portion of the total order size that has been ordered for fulfillment through the venue.

  When a transaction is fulfilled at a designated venue, such as ETM 110, a corresponding fulfillment record is preferably stored in the OMS database 114. FIG. 22 is a diagram illustrating a fulfillment record 600 according to an embodiment of the present invention. A fulfillment ID field 608 preferably holds a value that identifies a particular fulfillment. As before, order ID field 610 preferably holds a value that uniquely identifies the order associated with the fulfillment, and all fulfillments for the same order preferably have the same value in this field 610. Broker field 612 preferably includes an alphanumeric value that identifies the venue that performed the fulfillment. The fulfillment quantity field 614 preferably identifies the number of securities traded in this fulfillment, and the price field 616 identifies the price at which the security was fulfilled. Timestamp field 618 preferably records the time at which fulfillment was performed.

  The OMS interface module (OIM) 320 may communicate with the OMS database 114 via a network 314 or dedicated connection. In an alternative embodiment, OIM 320 communicates with OMS 312 and / or workstation 310. OIM 320 may communicate with ETM 110 via an external gateway or some other form of network connection. In another alternative embodiment, the OIM 320 is integrated into the ETM 110 and remote from the OMS 312 but some functionality is present in the OMS to provide OMS data to the OIM.

  In a preferred embodiment, OIM 320 includes computer software that stores and executes software that performs the functions described herein. In an alternative embodiment, OIM 320 runs on the same computer system as OMS 312. In one embodiment, OIM 320 includes an OMS database interaction module 322 for interacting with OMS database 114. The OMS database interaction module 322 reads records stored in the OMS database 114 and, in a preferred embodiment, creates and modifies data records stored in the OMS database 114. In one embodiment, the OMS database interaction module 322 accesses the OMS database 114 directly, and in another embodiment, sends a command to access the database to an application programming interface (API) within the OMS 312.

  OIM 320 preferably also includes an ETM communication module 324 for communicating with ETM 110. In one embodiment, the ETM communication module 324 automatically provides the selected data record in the OMS database 114 to the ETM 110 and, in a preferred embodiment, receives data and / or instructions from the ETM. In addition, the OIM 320 preferably has a data record conversion module 326 that changes the format of data records sent to and / or received from the ETM 110, and the security records so that filtered orders are not sent to the ETM. Also included is a filtering module 238 that filters out specified orders by type, security name, order type, order quantity, order price, or some other factor or category.

  FIG. 23 is a flow diagram illustrating operations performed by an embodiment of the present invention when a trader logs on to the ETM 110. The operations of FIG. 23 and the subsequent figures are now attributed to the OIM 320, but those skilled in the art will appreciate that all or some of the operations may be performed by other entities.

  Preferably, OIM 320 waits until the trader logs on to OMS 312 (710) before sending the trader's data record to ETM 110. In one embodiment, the ETM 110 sends a message to the OIM 320 when a trader in the organization where the OIM 320 resides logs on to the ETM. OIM 320 interprets this message as a sign to start receiving orders. In other embodiments of the present invention, the OIM 320 queries the OMS database 114 for specific entries, listens to interprocess messages sent by the OMS 312, polls individual trader workstations 310, or timer-based algorithms. Other techniques, such as implementing, are used to identify that the trader has logged on to the OMS 312.

  Once identified (710) that the trader has logged on to OMS 312, OIM 320 may take a data record (712) from OMS database 114 for an order suitable for transmission to the ETM. In one embodiment of the invention, all open orders are suitable for transmission to ETM 110. In other embodiments of the present invention, the OIM 320 may, through the filtering module 328, pass a security type (eg, stock or bond), security name (eg, IBM or T), order type (eg, market order or limit order). ), A suitable order may be identified based on criteria such as order quantity and / or order price. In yet other embodiments, only orders selected by a trading firm (eg, a trader) associated with the OMS may be suitable for transmission.

  If necessary, the data record conversion module 326 in the OIM 320 preferably converts the data record received from the OMS database 114 into a standardized format understood by the ETM 110 (714). As described above, the function of the data record conversion module 326 can also be executed by the ODIM 212 in the ETM 110. Alternative embodiments of the invention may send data records individually or in multiple batches. The data sent to the ETM 110 depends on factors such as the type of security being traded and / or the fields required to trade such a security correctly.

  FIG. 24 is a flow diagram illustrating operations performed by an embodiment of the present invention after a trader logs on to the OMS during a trading day. The operation of FIG. 24 is preferably performed automatically a plurality of times during the trading day. First, the OIM 320 determines whether the contents of the OMS database 114 have been changed (810). The OIM 320 may, for example, periodically poll the database 114 at approximately real-time intervals, query the database for the contents of specified fields such as time stamps, and / or network or specific interprocess communication messages. This step can be performed by listening for traffic.

  If the database has changed, the OIM 320 preferably determines whether the change should be sent to the ETM 110. Because typical OMS is complex and multifunctional, and types of securities not handled by ETM 110 can be traded using OMS 312, some changes to OMS database 114 may require that update data be sent to ETM 110. There are some that are not. Accordingly, OIM 320 reflects a new order of the type that changes to database 114 were traded in ETM 110 (in some embodiments, in addition to ETM 110, other ETMs and / or markets coupled to ETM 110). (812). If so, OIM 320 retrieves related data about the order from database 114 (816). If the change does not reflect the new order, the OIM 320 preferably determines whether the database change is related to an existing order change that has already been sent to the ETM 110 (814). If so, the OIM 320 retrieves the data record corresponding to the modified order from the database 114 (818). If there is an appropriate data record, once the data record is retrieved from the database, OIM 320 preferably converts the data record to an appropriate format (820) and sends the record to ETM 110 as described above with respect to FIG. .

  FIG. 25 is a flow diagram illustrating operations performed by an embodiment of the present invention when the OMS database 114 is updated in response to fulfillment of a transaction by the ETM 110. The illustrated steps can be performed each time a transaction is executed or in batch. However, the steps are preferably performed with sufficient frequency so that the OMS database 114 is updated in near real time.

  The OIM 320 may first determine whether the fulfillment generated by the ETM 110 relates to an order in the OMS 312 associated with the OIM (910). This step looks for fulfillment listed in the OMS 312 and filters the list of all fulfillments or other data from the ETM, for example by receiving a message from the ETM 110 that identifies the fulfillment that occurred in the ETM. Or by periodically polling the ETM for fulfilled performance.

  If the fulfillment that occurred at ETM 110 involves an order in OMS 312 associated with OIM 320, OIM receives information describing the fulfillment from ETM (912). This information includes, for example, information identifying the type, quantity, and price of the traded securities, the fulfillment time, and / or the original order in the OMS database 114 on which the fulfillment is based. The OIM 320 may convert the received information about the implementation into a format used by the OMS 312 (914). OIM 320 may then update OMS database 114 with the converted fulfillment data (916). As a result of these steps, OMS 312 may be updated automatically and transparently to reflect the performance performed at ETM 110. The fulfillment appears to OMS 312 as a typical transaction performed at another broker.

  In some embodiments, information about orders in the OMS database and / or any other information about the trading organization is used to provide additional (eg, complementary, alternative) products and / or services. Can be offered to traders. Information about the order includes the presence of the order, the presence of the counterparty order, the absence of the counterparty, past data for the same order, past data about the counterparty order, information that the order has been fulfilled (eg, non-performance during a certain period of time) Information on the existence of a specific order because it wants to trade in a specific industry, total market share, etc. ), Information that the order has been fulfilled, information that the order is currently inactive (eg, fulfilled, expired, non-performing, etc.), information about the risk model, and / or other optional Information may be included. In some embodiments, such features may be provided to premium users of ETM (eg, users who are willing to pay a fee). Additional products and / or services may be provided through a single ETM and / or additional ETM.

  In some embodiments, ETM, OIM, OMS, and / or other components may track non-performing orders (eg, identify when an order becomes inactive and store information about it) (E.g., expired orders and / or removed orders (e.g. removal from OMS, removed from consideration by ETM, etc.)). Information that an order has been placed but was non-performing may reveal that a trader associated with that order may wish to trade a security associated with the order in the future. When a new order is received, there may be no other party currently trading with the security identified by the order. The presence of the other party is determined by searching for matching orders received from multiple other traders using the ETM (eg, a list maintained in the ETM database). In some implementations, if there is no such party, the default order may be used to find such a party. Such use of a non-performing order is made after a new order becomes active (eg, when an order is about to expire, after receiving an indication that the order is being removed from the system in another manner, etc.) obtain.

  Use of such a default order may include querying a party associated with the default order (or any other inactive order). Such an inquiry may ask whether the parties are still interested in trading for securities and / or identify that matching counterparty orders are currently available. The party can then reorder the order, enter into negotiations with the party associated with the new order, ignore the request, and / or take any other desired action.

  In some embodiments, before such a default order is used, the party associated with the new order may be asked if such usage is desired. In order to facilitate the use of such orders for matching, the parties associated with the new order may be provided with statistics regarding the usefulness of such orders. This statistic may be collected by the ETM transaction history module, and may include, for example, the percentage of times such an order has successfully fulfilled an order and / or any other desired information. Information may be selected at the most convincing level of abstraction (e.g., overall securities, securities in related industries, specific securities, specific counterparties, etc.).

  In some embodiments where there are multiple default orders, priority may be granted according to any desired priority mechanism. For example, the other party candidate associated with a large order may be initially queried, the other party candidate associated with a recently expired order may be queried first, and so on.

  In some embodiments, the identity of the counterparty may be kept anonymous throughout part or all of the inquiry process associated with the use of the default order. The size of the order and / or any other information related to new and / or inactive default orders may also be kept confidential during the process until the other party chooses to expose such information.

  Any number of default orders may be tracked over any desired time. For example, in some embodiments, a number of recently expired orders may be tracked. In some embodiments, all default orders may be tracked over a desired period of time. In some embodiments, the tracking may be related to a security feature. For example, an order associated with a less liquid security may be tracked for a longer time than an order associated with a higher liquidity security.

  The fulfilled order may be tracked for use in fulfilling future orders in a manner substantially similar to the method of tracking non-performance orders described above. This is useful because a trader who previously traded a security is likely to trade again with that security. The fulfilled order may be fulfilled through ETM and / or some other method (eg, different markets).

  In some embodiments, it has been determined that there is no matching counterparty (eg, a counterparty that has an order that matches the order in the OMS) (eg, the counterparty of the order was not found (eg, after some time) If the order is about to expire, etc.), alternative products and / or services may be provided to the trader. Alternative products and / or services may be based, at least in part, on the characteristics of the order entered by the trader. Desired features include, for example, total market share, geographic area, industry, risk level, profit / loss ratio, transaction volume, revenue level, sales level, cash on hand, analyst recommendations, and / or any other information Can be included. For example, derivatives based on securities may be offered (eg, from other orders offered to ETM, from another market, etc.), or other securities may be offered (eg, similar stock, industry, etc. profiles) Securities bought by other traders who have also placed similar orders (for example, after a similar order has failed), the desires associated with the order (for example, portfolio to include a specific industry) Securities that meet) etc.). In some embodiments, information about the time it takes for an order to be fulfilled may be provided based on past trading trends. Such information may facilitate traders to take alternative actions for orders if the time to fulfill is too long and to wait for the order to be fulfilled if the time to fulfill is short.

  In some embodiments, alternative products and / or services may include transactions based on order reasons in a trader's OMS database. For example, the ETM receives information about why an order was presented to the OMS (eg, wants to own a specific industry security) and based on that reason, an alternative order candidate can satisfy the same reason And the order may be provided as an alternative. In some embodiments, the reason may be part of a broader trading strategy and / or risk model that can be shared with the ETM so that the ETM better meets the reason embodied by the order and is wider Alternatives that are better suited to trading strategies and / or risk models may be provided.

  In some embodiments, additional (eg, complementary) products and / or services may be provided if an order that matches the order is found. For example, the order may be identified as at least partially fulfilled and in response, additional products and / or services may be provided. The order may be fulfilled through the ETM and / or fulfilled through any other method and identified by the ETM as fulfilled (eg, through a status change in the OMS). Products and / or services may be provided from market operators, market participants, and / or any other source. For example, a trader may be offered a hedging opportunity after a security order is fulfilled. Such hedging opportunities may include futures associated with the security. Hedging opportunities may be provided through different counterparties on the same ETM (eg, may be found in a manner similar to finding the original counterparty) and / or through another market.

  In some embodiments, historical data about previous orders may be used to recommend additional products and / or services. For example, if a trader has a transaction that defaults, the trader may be presented with available orders that are often entered by a trader who has a similar default order.

  In some embodiments, historical information may be used to coordinate the handling of new orders. For example, if an order for a historically illiquid security is entered, additional techniques such as a trader, other market, etc. prior to entering the security order may be used to find a matching order. In some embodiments, other traders may be notified of the presence of orders for illiquid securities. Through any desired incentive method, the trader may be prompted to enter a counterparty order for the illiquid securities. For example, if a trader enters an order for a illiquid security, it may provide priority to the liquidity security, provide a rebate for entering such an order for the trader, and / or Any desired incentive may be provided for such order entry.

  In various embodiments, the transaction may be associated with any desired currency or country (eg, US company shares, Chinese company shares, UK savings receivables, etc.). In some embodiments, a trader in one country may enter into a transaction involving another country and / or another country's currency (eg, a US trader may buy a Japanese corporate bond).

  In some such embodiments, additional products or services may be provided based on currency information associated with the transaction. For example, one or more currency trading contracts may be provided to traders involved in such trading. Currency trading contracts can function as hedging instruments against currency market volatility. In such a contract, a trader may allow the contract to be exchanged for some cash value if the value of the currency associated with the transaction changes compared to the trader's national currency. In some embodiments, the availability of such a contract may be included as a negotiation option between traders when negotiating a transaction. In some embodiments, traders may trade on such contracts with each other independently of any other trade (eg, through ETM and / or some other market). In some embodiments, a trader may be provided with such a contract as a service from the market (eg, an ETM operator may collect such a fee and provide it as a service to an ETM user) ).

  Some embodiments may include participants from different time zones. Such participants are not always active at the same time, due in part to different time zones. Thus, one or more mechanisms may be used to address these time zone differences.

  For example, in some embodiments, a participant can use an automated transaction that can be used to automatically negotiate, accept, and / or reject the transaction automatically if the participant is not active (eg, at night, vacation, etc.). It may be possible to establish a profile. Such a profile may indicate, for example, that securities orders for a particular price range should always be accepted and / or that any other desired action should be taken.

  In some embodiments, active trading hours may be tied to a particular market (eg, the New York Stock Exchange). By limiting the transaction to a time similar to that of a particular market, the participant may ensure that they can participate in the transaction by being present during that time.

  In some embodiments, a market (eg, ETM) determines whether a participant is active and may include participants active in a potential transaction with a certain level of priority. Such a determination may include monitoring an activity level at the computer terminal, presenting a query through the computer interface, and / or any other desired action. In some embodiments, if a participant is not active (eg, has gone home that day), the participant will not be eligible to participate in the transaction until it becomes active again. In other embodiments, active participants may be given higher priority than inactive participants, but may still provide inactive participants with opportunities to engage in transactions.

  In some embodiments, negotiations may be initiated between these two traders if the matching order includes active and inactive traders. An active trader may be notified that an inactive trader is inactive. An active trader may be given an estimate (eg, time zone difference, historical data indication, etc.) when an inactive trader may become active. While an inactive trader becomes active and waits for negotiations, orders associated with the active trader are still used for searching for other matches (eg, with other active traders). obtain. When an inactive trader returns to the active state, a previously inactive trader can enter into negotiations with a previously active trader. A previously active trader may be inactive by the time a previously inactive trader becomes active. Since such problems can occur due to time differences, negotiations can take a long time to complete. In some embodiments, one or more sides of the negotiation may enter information (eg, preferences, limit prices, etc.) that automates the negotiation, thereby completing the negotiation in less time.

  Some embodiments may be restricted to buyer trading participants (ie, investment organizations that tend to buy a majority of securities for money management). Other embodiments may include buyer participants and seller participants (eg, brokers, retail analysts, etc.). Buyer participants are usually more aware of protection from exposure to trading intent because they fear malicious market manipulation and fear exposure of their own trading strategies. Some embodiments in which a selling participant is authorized may include a mechanism that addresses such fears of the buying participant.

  For example, in some embodiments, a buyer participant may be able to withdraw from a transaction with a seller participant. In some embodiments, a buyer participant may be able to establish a filter that only places some seller participant orders into seller participant orders that can be traded with buyer participants. For example, a filter may be a seller-participant order for a sufficient amount of securities, if the seller agrees to perform without order negotiation (eg, according to a standard price such as a recently traded price), and / or It may be allowed if the seller participant's order meets any other desired criteria of the buyer participant.

  In some embodiments, an indication of one or more criteria used for order filtering may be received. The criteria can be used to establish an appropriate filter so that orders that do not meet the criteria are filtered. If the order does not meet the criteria, the order may be presented to the market participant who established the criteria. In some embodiments, the criteria are time-related criteria (eg, when an order is received, when an order is presented to a market participant (eg, an XXX Securities order may be presented only between noon and 2 pm, etc.) ) Etc.). In some embodiments, the criteria may include a quantity-related criterion, an identification criterion, a price-related criterion, a type-related criterion, an industry-related criterion, and / or any other criterion.

  Some embodiments may limit the options provided to the selling participant. For example, a selling participant can only enter legally binding orders. If the selling participant's order finds the other party to the buying participant, the selling participant may be legally bound to fulfilling the order. In some embodiments, if the selling participant is legally bound to fulfilling the order, price and / or quantity negotiations will still take place between the buying and selling participants. obtain. In other embodiments, the negotiation is not initiated, but rather may be executed without negotiation (e.g., if the buyer accepts the offer, according to the standard pricing mechanism, the quantity of the security identified in the selling order). Etc., the transaction can be automatically executed).

  In some embodiments, an order acceptance request may be sent to one or more market participants (eg, buying participants). In some embodiments, such participants may receive an order acceptance request. In some embodiments, market participants may be able to respond to acceptance requests within a limited amount of time. If the participant responds positively to the acceptance request within a limited time, an acceptance instruction may be sent and / or the fulfillment of a transaction that fulfills at least a portion of the order may be facilitated.

  In some embodiments, the selling participant may be required to enter the quantity of securities to trade at the time of order entry. The selling participant may be legally bound to the quantity if the order from the buying participant matches the selling order. In some embodiments, the selling participant may negotiate an increase in quantity, but may limit that quantity as a minimum quantity. In some embodiments, the selling participant can only enter orders that exceed the minimum threshold quantity.

  In some embodiments, in order to avoid negotiation between the selling and buying participants, the selling participant is legally bound to have the order fulfilled according to a standard pricing mechanism. obtain. Such a pricing mechanism may include fulfilling an order based on well-known midpoint pricing policies and / or any other desired mechanism.

  In some embodiments, when two selling participants are counterparties to a transaction, there is no limitation as if one selling participant is a counterparty to a buying participant. May be. For example, if two selling participants enter the negotiation, such negotiation is restricted or not allowed at all if one selling and buying participant is the other party. Even so, both can negotiate for price and / or quantity.

  In some embodiments, parties with matching orders can enter into restricted negotiations. For example, fulfillment of a transaction that fulfills a matching order may include negotiations that do not include price negotiations and / or quantity negotiations. For example, the price may be determined using VWAP, midpoint, and / or any other desired pricing policy. The quantity can be determined based on the quantity defined by the matching order. If there are any other issues to negotiate, some embodiments may allow negotiations on those issues (eg, fulfillment time, platform used for fulfillment, etc.).

  In some embodiments, evidence of action / things may be hidden from one or more parties. For example, in some embodiments, if it is determined that one order matches another order, any evidence of that determination is given to one or more parties associated with the order and / or any other party. If the criteria for the filter are established, the criteria and / or evidence for the establishment of the filter can be hidden, and if an order is made whether the order meets the criteria for the filter, the evidence for that decision is hidden. obtain. Such concealment of evidence may occur until some action is taken and / or over a period of time. For example, in some embodiments, until the second party decides to proceed with the order and / or fulfillment of the order, evidence that the order of the first party matches the order of the second party. It can be hidden from the first party until promoted.

  In some embodiments, concealing event evidence may include performing any action or not performing any action to cause the observer to believe that the event did not occur. For example, concealment of evidence may be performed by one or more actions that would have been performed if an event did not occur (eg, sending a request, sending an indication that an event did not occur, etc.) Executing, sending information misleading about the event (for example, sending an indication that no event has occurred, sending an indication that another event has occurred, information that obscures the occurrence of an event (eg, (Indication that the event has occurred early and / or late, such that the actual occurrence of the event is ambiguous), transmission before and / or after the event)), do not send information that the event has occurred To mislead the observer, send imitation information, encrypt information transmission, use onion routing techniques That, to obscure the transmission source, to obscure the destination of transmission, it may include to obscure the timing of events, and / or any other operation.

  In some embodiments, the order may include an order to buy or sell a quantity of financial instrument. The order side may refer to whether the order is a buy order for a financial instrument or a sell order. Two orders may be matched if they are orders for the same financial instrument and orders on each side of the transaction for that financial instrument. Other criteria such as quantity, price, etc. can also be used to determine whether orders match each other.

  In some implementations, the order may indicate a price range that is agreed to fulfill a transaction that satisfies at least a portion of the order. In such an embodiment, if two orders are on each side of a single financial instrument transaction and the two orders have at least partially overlapping price ranges, the first order is the second order. Can be met. In some implementations, the actual price of the transaction may be determined according to VWAP and / or midpoint pricing models.

  In some embodiments, facilitating transaction fulfillment may include taking any action that helps to fulfill the transaction. In some embodiments, facilitating fulfillment includes, for example, fulfilling a transaction, not including the price of the transaction between the first market participant and the second market participant, and the financial in the transaction. It may include initiating a negotiation that does not include the quantity of goods, sending information about the transaction to a third party, and / or any other action to fulfill the transaction. Such operations can include centralized operations and / or distributed operations.

  In some embodiments, one or more market participants may be charged a usage fee for the trading system. For example, if a matching order is found and / or an order fulfillment promotion is performed, a fee may be charged to the party associated with the matching order. In some embodiments, some parties may stimulate the use of trading systems by providing financial incentives for such charges. For example, in some embodiments, some participants are not charged, orders that meet certain criteria are not charged, and some participants may be paid for order submission. Etc. Such stimuli can help increase liquidity in markets where certain participants may be reluctant to provide liquidity in the absence of stimulation.

  In some implementations, for example, a portion of the fee charged to the first participant may be provided to the second participant. In some implementations, providing the portion of the fee to the second participant pays the second participant at least a portion of the second fee (eg, only that portion of the second participation) Discounting a person's fee). In some implementations, providing the portion may include depositing into the second participant's account (eg, providing payment to a financial account). In some implementations, the buying participant may discount and / or pay a usage fee and charge the selling participant. The fee that can be charged to the selling participant can be used to pay a discount or payment given to the buying participant. In some implementations, no discounts, fees, and / or payments are made to either party when two buyer participants interact. In some implementations, discounts and / or payments may be granted to the first party submitting the order.

  In some embodiments, various actions taken by the trader and / or information presented to the trader may be obtained / presented through one or more user interfaces of the computing device. For example, ordering, negotiation, etc. can be facilitated by a user interface through which traders can interact. The trader may enter order information, accept order requests, establish filter criteria, etc. through a suitable user interface of the computing device. In other embodiments, such a user interface may not be used and / or may not need to perform all or some of such operations (eg, the computer may Such operations can be performed without an interface).

  In summary, the present invention includes, at least in part, an electronic trading market that creates liquidity by receiving order information directly from a database of OMS systems at a trading organization. Because orders are automatically extracted from the OMS database and information about fulfilled orders is automatically inserted into the database, the OMS database “sees” the market as “just another market broker”. In addition, traders can trade in the electronic market without any redundant manual work.

  The above description is included to illustrate the operation of the preferred embodiment and is in no way meant to limit the scope of the invention. The scope of the present invention should be limited only by the following claims. Many variations will become apparent to those skilled in the art from the foregoing discussion, and such variations are still encompassed by the spirit and scope of the present invention.

XIII. Various information 2
The element numbering in the following chapters may not match the element numbering in the above chapter. This section provides further disclosure of related material and should not be construed as a limitation to any previous disclosure. For example, unless defined otherwise, the following definitions should not apply to the above disclosure, nor does the preferred description apply to the above disclosed embodiments.

  The present invention relates to a method for managing authorized transaction information for inducing and executing a confidential transaction desire through a computer network such as the Internet.

  The term “trading interest” is used herein to describe any expressed willingness to trade a given security or securities, and the term “certified willingness”. "trading interest)" is used herein to describe a willingness to authenticate and authenticate a transaction by a trusted third party. An example of genuine trading willingness is an order placed on a securities market automatic matching system. A second example of authentic trading motivation is the trading motivation expressed by a party with a documented history of ambitious trading. An example of a non-authorized transaction motivation is an undocumented instruction of motivation (known in the art as an IOI).

  In public securities markets, market mechanisms and trading psychology create barriers to efficient information dissemination and price discovery. A market participant's decision to reveal information about a willingness to trade is usually a trade-off between confidentiality and liquidity. By exposing the details of large and ambitious purchasing intent to the public, for example, market participants assume the risk of moving adverse values. Other participants and market makers with genuine selling willingness can “fade” their offer (becoming a much less motivating seller). There is also an empirically demonstrable risk of unfavorable price movements due to “front running” (buying behavior by market participants in anticipation of price movements due to exposure of large orders). Confidentiality can be maintained by splitting a large order into many smaller orders to avoid motivation, but this is inefficient and draws the natural contra-interests of most natural opponents. Will not be able to attract. Therefore, the transaction cost associated with the dissemination of information is too high, preventing economic efficient transactions. The practice of splitting big will into smaller orders affects all price discovery. When faced with each order, market participants must incorporate that the order may only be a small part of a much greater willingness. The reason is that it is often impossible for market participants to verify that many such orders are not sent simultaneously.

  Another serious obstacle to the efficient dissemination of trading motivation and price discovery is the lack of verified information about trading motivation. Validated transaction willing information that exists (e.g., fulfillable orders displayed) often has little evidence. The displayed order is very small compared to the will not be disclosed, and usually the distribution stock in the US market is equal to 1 or 2 minutes. Thus, the displayed order can be easily manipulated to indicate excessive purchase incentives, for example, if the seller is actually rich. In addition, unverified error information is often created and disseminated by non-conscientious market participants to manipulate market prices. If the voluntary dissemination of the willingness to trade is not verified by a proof of a canceled order that could be fulfilled in an order that is currently fulfillable, an actual trade fulfilled, or at some point in the market, May be false or misleading. There is often no way for market participants to verify the indicated willingness to trade, or to know which other market participants have a history of non-conscientious trading behavior, so all prices are Inevitably, there is a risk of such behavior.

  One known method for voluntarily and selectively disseminating willingness and behavior not verified in the public equity market is AutoEx +. RTM. Used by the system. This is an electronic database and online network that provides users with the ability to voluntarily publish and show their willingness and fulfilled transactions. AutoEx +. RTM. The user can limit the receipt of messages regarding the willingness to trade by inclusion (list defined by the user) or exclusion (blocking market participants of certain names). Users can also be restricted by the name of the security that receives the information and the names of other users who receive the information.

  AutoEx +. RTM. In the system, the indicated willingness and reported transactions are not confidential and create opportunities for unjustified dissemination. In addition, users of the system are not required to report every transaction, which provides an additional opportunity to generate a false impression of a willingness to trade. Significantly, this approach cannot use certified trading motivation (CTI) analysis to limit the dissemination of information to market participants who are likely to have counterparty motivation. Such a CTI analysis cannot also be used to limit the transaction motivation instructions that market participants receive. Based on the disseminated CTI analysis information, the ability to initiate an auction is also not provided. Nor can user trading behavior be monitored to generate a correlation accuracy rating or disclosure behavior correlation for inappropriate trading practices.

  One known technique for matching the willingness of transactions and executing transactions while limiting the dissemination of information is POSIT. RTM. Used by the matching system. POSIT. RTM. The system accumulates the willingness to trade and allows the matching sequence to be started at set intervals. Market participants place sensitive orders in the system and are unaware of the volume or aggressiveness of other orders on the same side or the other side until the match is released. This approach does not allow for targeted communication based on an analysis of certified fulfillable willingness and trading behavior and does not provide the ability to initiate a private auction based on this analysis. It is impossible for the auction initiator to grant any exclusivity to the counterparty order entered in response to the targeted distribution.

  In this environment, there is a significant need to efficiently disseminate confidential information about the willingness to trade. Market participants with a large confidential trade willingness want to notify only other market participants who are likely to have a large counterparty willingness. Other market participants would like to be notified of confidential certification transaction motivations that are likely to be motivated by the other party. Both groups would like to have a place to trade after being linked through an analysis of certified trading willingness. Market participants also want a means to certify qualification information about other market participants' trading behavior and the indicated trading information.

  Preferred embodiments of the present invention allow (1) a market participant to limit the dissemination of willingness to trade to other market participants who are likely to have a large counterparty motivation, and (2) By ensuring that other market participants with whom the willingness to circulate are legitimate can be assured, and (3) the auction between the willingness to trade can be targeted and verified in this way, Eliminate restrictions on motivation and fulfillment systems. The software of the preferred embodiment identifies potential counterparty wills by analyzing information from various sources regarding authorized trading wills.

  Preferred embodiments include a method for managing market information, the method comprising: electronically receiving data including confidential information regarding market participants; and electronically storing the received data regarding market participants. Electronically receiving information from the first market participant's computer, electronically storing the information received from the first market participant's computer, and the storage relating to the market participant Generating a targeted distribution list of market participants based on the data and the information received from the first market participant computer; and the information received from the first market participant computer. And electronically transmitting to market participants on the targeted distribution list.

  Advantageously, this is done without exposing the sensitive information of the market participant to the first market participant. In one embodiment, the identity of the first market participant is not exposed to other participants.

  Further embodiments are described below.

  FIG. 26 shows the system configuration of a preferred embodiment of the present invention with a certified transaction motivation (CTI) manager 10 connected to various users 20 via a communication network 30. The CTI manager 10 is a computer having a processor, a memory, and input / output including a communication interface. The computer program stored in the memory operates the CTI manager according to the present invention. In the preferred embodiment, the communication network 30 is the Internet, but alternative embodiments may utilize a dedicated communication network, as is well known in the art. In the preferred embodiment, communication between the user and the CTI manager is secured by the confidentiality of the information communicated. CTI manager 10 is also connected to various external data sources 40, CTI user database 50, and auction server 60.

  The external data source 40 provides information regarding the positions held by the user 20, fulfilled transactions, and active orders. This allows the CTI manager to identify and verify the user's history and current transaction motivation. In an alternative embodiment, the CTI manager does not receive external data and uses only data generated within the system. In the preferred embodiment applied to the US equity market, the external data source 40 is Instine. TM. Various electronic communication networks (ECN), NASDAQ. TM. Such as public markets, stock exchanges, POSIT. RTM. Including publicly available data such as matching networks and published holdings of various organizational investors. In a preferred embodiment, the data regarding market participants used by the CTI manager includes sensitive information. For example, identification information for an order that can be fulfilled on an ECN is typically not provided. Since the confidential information is not disclosed, the CTI system must obtain permission from the user 20 to use the confidential information. In the preferred embodiment, the user 20 agrees to release this confidential information to the CTI, understanding that the secure CTI system will only use this information to provide the user with another person's valuable confidential transaction motivation. To do. In other words, the confidential information that the user 20 manages with the CTI manager 10 allows the user to access more information (especially confidential transaction willingness), but the confidential information provided by the user 20 It does not leak to the three parties.

  In the preferred embodiment, the CTI manager 10 communicates with the external data source 40 in real time via the Internet. Alternative embodiments utilize a dedicated communication network, as is well known in the art. An alternative embodiment stores information from the external data source 40 in a database and also updates the information periodically rather than in real time. For example, an alternative embodiment receives information about the public holdings of various organizational investors, stores that information in a database, and only from the news service source as often as new information is published. Update the information. As will be apparent to those skilled in the art, the present invention is used to manage sensitive information in markets other than US equity because nearly all markets for substitutable value products exhibit the same information inefficiency. You can also.

  In a preferred embodiment, the CTI user database 50 includes user data such as security information and contact information, CTI notification parameters, and behavior history. The preferred embodiment is the auction that has been initiated and its consequences (eg, whether the auction has been canceled, whether it has failed to find the opponent's willingness, or whether it has been partially or fully fulfilled). The action history of each user including The behavior history includes the received CTI notification, the orders placed in response, and the order results (whether the responding order has been canceled, failed, or the responding order is partially or fully fulfilled) Or not). In an alternative preferred embodiment, the CTI user database 50 simply maintains overall statistics regarding this behavior history for each user.

  CTI notification parameters specify the circumstances under which CTI information is to be received and may be different for different securities and different users. For example, some users may limit CTI notifications to a willingness to start over 100,000 shares for certain securities, and a willingness to start over 500,000 shares for other securities. In a preferred embodiment, the notification parameters can be changed at any time by the user and may be changed based on statistics regarding order size, securities, the identity of the initiating user, or the behavior history of the initiating user.

  In an alternative preferred embodiment, the CTI user database 50 also includes information regarding inappropriate transaction behavior such as peg operations and front running. A peg operation occurs when an auction sets the fulfillment price at a midpoint of the market at a particular time. Auction participants with large buy orders can actively sell in the market and reduce midpoint prices. Front running occurs in this context, for example, when a recipient of a large buy order notification starts to actively buy CTI trades before an auction in anticipation of price behavior due to a large CTI. The CTI manager in this embodiment may monitor the trading behavior of all auction participants and mark suspected peg operations or front running as raw data or trading behavior ratings in the CTI user database. An alternative embodiment is AutoEx +. RTM. Similar data and / or ratings are maintained in the CTI user database 50 regarding the accuracy of unauthorized disclosure of market participants in external systems such as. Further embodiments maintain similar data and / or ratings in the CTI user database 50 regarding market participant compliance with the transaction limits imposed on them set during negotiation. This list is not intended to be exhaustive and other embodiments will be apparent to those skilled in the art.

  The auction server 60 accumulates market participant (MP) counterparty orders in response to CTI notifications and manages the process of performing matching auctions. In an alternative embodiment, there is no auction server and the CTI system functions as a targeted information dissemination mechanism. FIG. 27 shows the information management function of the preferred embodiment of the present invention. The initiating user 210 communicates to the CTI manager parameters that limit the willingness to trade and the dissemination of information. The CTI manager uses these parameters and CTI information 230 to identify which market participant 240 should receive the information. Each MP also communicates its own parameters describing the transaction motivation information that the MP wants to receive to the CTI manager. Thus, the CTI manager functions as the bidirectional CTI information filter 220. This restricts the dissemination of confidential information of the initiating user to the MP 240 where (1) the MP matches the dissemination parameter of the initiating user, and (2) the incentive of initiating matches the notification parameter of the MP. In an alternative embodiment, the CTI manager is a unidirectional information filter that targets the MPs that the system notifies but does not allow similar notification filtering by the MPs. Compared to FIGS. 24 and 27, in the preferred embodiment, both the initiating user 210 and the market participant 240 are the users 20 of the system, the bi-directional CTI information filter 220 is the CTI manager 10, and the CTI information 230. Are supplied by the external data source 40 and the CTI user database.

  FIG. 28 is a flowchart of the operation of the information management function of the preferred embodiment. In step 310, the user communicates an incentive to start to the CTI manager. In a preferred embodiment, the willingness to start is a live fulfillable order submitted to the CTI system to start an auction, but in an alternative embodiment, the willingness to start is the other that the CTI system must certify Information. For example, the user may use ECN or POSIT. RTM. You may want to selectively disseminate the presence of large fulfillable orders placed on other markets or auction systems such as. The user submits information about the order and the CTI system then verifies the existence of the ordered order so that all market participants subsequently notified of the order trust the authenticity of the distribution. be able to. Similarly, the user can submit motivation instructions and the system can then execute the currently fulfillable order, recent transaction history, and / or canceled order that was once fulfilled but not fulfilled. Authorize from verified information on. Again, all market participants who are subsequently informed of this willingness can rely on the truthfulness of dissemination. In an alternative embodiment, the user can submit a non-certified transaction motivation, but this lack of certification is indicated to all market participants subsequently notified.

  In a preferred embodiment, the willingness to start may be a par value (eg, $ 1121/2) or, if a price is set, to a market price (eg, a market midpoint set at the end of the auction). Includes price limits that may be fixed. An alternative embodiment allows the initiating user to lock the price limit to a market value or index that has not yet been determined. For example, in an alternative embodiment, the user can lock the price limit to the daily volume weighted average price (VWAP) calculated at the end of the trading session. In a preferred embodiment, the willingness to start includes auction parameters such as the length of the accumulation period.

  In step 320, the user communicates the desired distribution parameters. In the preferred embodiment, there are many dissemination parameters available to the user, with the most important parameters being various measures of certified counterparty motivation. In a preferred embodiment, the user is authorized from (1) a live fulfillable order, (2) a previously fulfilled transaction, or (3) a cancel order that was once fulfillable but not fulfilled. You can specify the opponent's willingness. Examples of filtering based on the CTI for the distribution of willingness to buy 500,000 shares of a particular brand include: (1) MP or other systems currently offering more than 10,000 shares of that brand in the market A user, (2) an MP or other system user who sold more than 25,000 shares in the current trading session, and (3) an MP that offered the brand in units of more than 10,000 shares in the current trading session. Or restrict to other system users, or (4) MPs or other system users who bought above the best bid in the current trading session. All of these parameter quantities and time periods can be selected by the user.

  In the preferred embodiment, many other parameters are provided to the user to utilize market information from the external data source 40 and the CTI user database 50 to more accurately target distribution to the desired market participants. The For example, the user can choose to notify only market participants with specific responses or start statistics. (For example, the CTI manager may be instructed to notify only market participants who responded to a 10% of the received CTI notifications within a specific time frame or responded to a specific total number of CTI notifications) . Furthermore, the preferred embodiment allows the user to focus on MPs that have a known holding specific to the security of interest. The preferred embodiment also allows the user to exclude MPs from notifications based on the history of breaking transactions (eg, CTI information may break any number of transactions in a certain amount of time). Not to reach MP). The preferred embodiment also allows the user to include or exclude specific MPs in the notification by name or identification number.

  In an alternative preferred embodiment, the user can perform a more advanced analysis performed by the CTI manager on various user trading patterns to identify specific correlations or pattern recognition (eg, technology stock buyers, sectors The target of MP can also be narrowed down based on rotation etc.). In another preferred embodiment, the user can exclude MPs based on any identified inappropriate transaction behavior such as front running and peg operations stored in CTI user database 50. In another alternative embodiment, the distribution parameters are defined by the system and cannot be selected by the user. In yet another alternative embodiment, the user can choose to define some or all of the distribution parameters or use the default parameters defined by the system.

  Referring again to FIG. 28, in step 330, the CTI manager accesses the necessary CTI information from the external data source 40 and the CTI user database 50 to perform CTI filtering analysis. In step 340, the CTI manager uses the flow parameters to parse the CTI information and generate a notification MP list. In step 350, the CTI manager further reduces the size of the MP notification list using the MP notification parameters stored in the CTI user database 50. In step 360, the CTI manager sends a confidential start CTI notification to the MP that (1) matches the initiating user's dissemination parameters and (2) the starting motivation matches the MP notification parameters. In an alternative embodiment, the notification includes statistics about the initiating user's past auctions (eg, percentage filled, cancellation rate, transaction break frequency, etc.).

  In an alternative preferred embodiment, after step 350, a summary of the analysis results is presented to the initiating user and the distribution parameters provided in step 320 are modified to more accurately adjust / limit the distribution of confidential CTI. Options are given. For example, a user may be too inclusive (eg, too many MPs that sold 10,000 or more of that security today) or too exclusive (eg, currently selling more than 50,000 shares). The distribution parameters can be changed. The generation of the MP notification list is an iterative process in this embodiment because the embodiment repeats steps 330-350 until the user is satisfied with the output of the distribution analysis. User interaction in this iterative process is performed through interface means well known in the art.

  FIG. 29 is a flowchart of the operation of the CTI management system when performing an auction based on the disseminated willingness to start. In step 405, CTI-initiated auction notifications are disseminated to the MPs targeted in the process shown in FIG. In step 410, the notified MP has an option to respond to the notification. In the preferred embodiment, this response is a fulfillable price-limited counterparty order sent to the auction server. Similar to the willingness to start, in a preferred embodiment, the price limit may be a face value or may be fixed at the market price. An alternative embodiment allows the responding MP to lock the price limit to a market price or index that has not yet been determined. For example, in an alternative embodiment, the MP can lock the price limit to the closing VWAP.

  In an alternative embodiment, the notified MP can send a message to the initiating user to simultaneously submit a willingness to trade and negotiate the deal directly. In another alternative embodiment, the notified MP can respond via a private chat session and negotiate the transaction directly. In an alternative preferred embodiment, the MP may respond with a semi-private negotiation chat session with some or all of the initiating user and other notified MPs. The system provides chat and messaging functions using interactive communication techniques well known in the art. In an alternative preferred embodiment, the notified MP may be provided with the initiating user's phone number and / or email address to provide other direct communication channels.

  In step 420, the auction server 60 stores orders from the notified MP. In a preferred embodiment, the length of the accumulation period is set by the initiating user in the auction parameters communicated in step 310 and is subject to the shortest and longest restrictions defined by the system. This allows the user of the CTI system to start an auction from time to time, and the user must wait for a regular matching session that is completely unfocused. RTM. Very different from the system, the auction can be limited to MPs with verified opponent motivation. In an alternative embodiment, there is a fixed accumulation period defined by the system. In another preferred embodiment, the system sets the end of the accumulation period, which is subject to the shortest and longest restrictions. If possible, the system can set the end of the accumulation period to match the end of the accumulation period of any other pending auctions, thereby combining the auctions to increase overall liquidity . In the preferred embodiment, during the accumulation period, the initiating user and the notified MP can change or cancel their order placed on the auction server. Alternative embodiments impose restrictions on this capability. For example, an alternative embodiment does not allow the initiating user to cancel the auction after the notified MP responds with the counterparty order, and the initiator will not accept the MP after trusting the order and responding with the counterparty order. , Bound to order.

  In step 430, the preferred embodiment auction server 60 prioritizes the counterparty order sent by the notified MP. Preferred embodiments prioritize fulfillment according to the following continuation rules: 1) Matching total size--the combination of counterparty orders that maximizes the total size fulfilled is selected; 2) price limit--competing MP If the counterparty order match quantity is equal, the auction server first fulfills the MP counterparty order with a more aggressive price limit; 3) size limit--the competing MP counterparty order has the same price limit (or price limit) The auction server first fulfills an order with a more aggressive size limit; 4) input time--if the competing MP counterparty order has the same size limit, the auction server will first Fulfill the order entered in.

  Alternative embodiments utilizing different fulfillment priority rules will be apparent to those skilled in the art. For example, one alternative embodiment ignores the size limit of the counterparty order, there is no price limit, and in another alternative embodiment where the actual performance is the market midpoint at the moment of matching, the fulfillment priority is the input time Is due to.

  In the above description, it is assumed that the motivation to start is an order on only one side, and all orders sent by the notified MP to the auction server are on the other side. It may happen that the notified MP responds with an order on the same side as the willingness to start, and that side's fulfillment priority is also required. In the preferred embodiment, the willingness to start has absolute fulfillment priority for subsequent MP orders. This is a further benefit of the CTI system from the perspective of the initiating user. The system allows the initiating user to prioritize the dissemination of confidential trading motivation to target MPs that have a willingness to qualify opponents, affect auction timing, and prioritize matching opponent orders placed in response. it can. All orders on the same side as the starting motivation issued by the notified MP are fulfilled according to the fulfillment priority described above only after the starting motivation is met. Again, alternative embodiments utilizing different fulfillment priority rules will be apparent to those skilled in the art. Furthermore, in an alternative embodiment, the willingness to start must be complied according to normal fulfillment priorities without being granted absolute priority over competing orders subsequently issued by the notified MP.

  In another embodiment, two or more auctions can be combined to pool liquidity. In the combination auction, each motivation for starting is given exclusivity with respect to the opponent order issued from the MP notified in response to each starting order. “Exclusiveness” means that the counterpart order placed in response to the starting order cannot be matched to any other order until the starting order is filled or canceled. In an alternative preferred embodiment, priority or exclusivity is not granted to the starting order in the combination auction, and all orders compete according to the same fulfillment priority. Alternative embodiments utilizing other means of combining auctions will be apparent to those skilled in the art.

  In step 440, the auction server fulfills the order at a price set according to the type of auction used according to the execution priority set in step 430. If there is no MP response, or if there is no transaction that can be given a limit price, the auction fails and ends. In a preferred embodiment, the auction server utilizes a midpoint cross auction in which all orders are fulfilled at a market midpoint at a specific time. In order to avoid pegging, in a preferred embodiment, the fulfillment price is fixed to the market at a random time within a 10 minute “fuzz period” after the end of the accumulation period. In an alternative embodiment, there is no ambiguous period and the auction fulfillment price is determined at a known time after the end of the accumulation period.

  Alternative embodiments utilize a variety of other auction types. For example, an alternative embodiment utilizes a “sealed envelope” auction where the limit price of all orders is kept confidential and a single price is selected that maximizes the size of the matching fulfillment. Another embodiment allows the initiating user and all notified MPs to see all orders and the limit price of orders as orders are accumulated, and between responding MPs to trade with incentives to initiate Use a “private auction” auction with price competition. The example given assumes that all orders are fulfilled at the same price, and another alternative embodiment is the differential pricing where all orders from the responding MP are traded at their respective limit prices. Is used. This list is not intended to be exhaustive, as alternative embodiments utilizing different types of auctions will be apparent to those skilled in the art. Alternative embodiments allow the initiating user to select from more than one auction type as described above.

  In step 450, the auction server notifies the initiating user and all responding users of their order status (ie, “Fulfilled”, “Partially fulfilled”, “Cancel”, “Open”, “Expired”). To do. In step 460, the auction server of the preferred embodiment enables auction participants to communicate with each other and the system administrator to resolve any perceived errors. In the preferred embodiment, this communication is via semi-private chat messaging, although alternative embodiments provide telephone contact information. The user can negotiate to break or modify the transaction over time, after which time the transaction is settled. The use of this period represents a trade-off between interest in instantaneous closing of trades and interest in minimizing costs and confusion due to errors. Alternative preferred embodiments do not provide time to negotiate changes to fulfilled auctions. In step 470, the CTI manager 10 processes the auction behavior and updates the CTI user information database to reflect the start, response, fulfillment, and deal break behaviors that have taken place.

  In an alternative preferred embodiment, the auction server 60 also includes an order repository that is not associated with an active auction. In this embodiment, any user can place an order in the repository without starting an auction or calling a CTI targeted notification. These orders sleep until the auction on the stock is started, and are treated as responses received from the MP notified in step 410 by the auction server when the auction is started. In an alternative embodiment, the auction server performs matching periodically without any CTI opening to empty the dormant order repository. Alternative embodiments perform these auction functions only when sufficient dormant willingness is accumulated, not at defined intervals. In yet another embodiment, these orders do not sleep and can always be fulfilled, subject to price limits, like ECN. In another embodiment, live fulfillment is possible, but price limits are defined relative to the outside, such as a market spread or a specific spread to end-of-day VWAP.

  In an alternative preferred embodiment, there is no auction server or fulfillment function, and the CTI system functions as the targeted information dissemination mechanism shown in FIG. In this alternative embodiment, after the notification process shown in FIG. 28, the CTI system does not perform the auction process shown in FIG. 29, but rather, as described above, the notified MP is in private or semi-private negotiation. Be able to respond to the initiating user via a chat session. An alternative preferred embodiment also provides the informed MP with the initiating user's phone number and / or email address to provide other direct communication channels. After the start motivation expires or the start motivation is canceled, the preferred embodiment updates the CTI user database to reflect the start behavior and response behavior.

  In an alternative embodiment, a third-party matching facility such as Optimark uses a CTI system to advertise matching fluidity and perform matching. For example, the MP may send an order to Optimark and request to send a notification with an announcement that “There is an order to DELL in the next round of Optimark: join.” In this embodiment, there is no chat and there is an address of the site (in this example, the Optimark address) where matching should be performed.

  In a further preferred embodiment, the CTI system functions in a manner generally similar to a rating service. In this embodiment, the system compares the unauthorized distribution of trading behavior (such as disclosure to AutoEx + .RTM.) With the actual certified information and compares the overall accuracy of the market participant's disclosure. Generate a measure of. This accuracy rating can be used by other market participants to distinguish disclosures based on proven reliability. In another embodiment, the CTI system ranks the adherence to the trading limits set by the market participant's MP itself. For example, to receive a better price when the MP negotiates a deal, the MP agrees that it will be legally bound by the trading cap, and this order is not part of a much larger trading will Can demonstrate that they are not negotiating similar deals with other MPs at the same time. The CTI system compares the MP's defined trading limits with actual certified information to generate a proven reliability measure for the MP. This assignment can be used by other MPs to accurately quote the probability that the order being negotiated is part of a much larger order.

  In a further embodiment, the CTI system monitors trading behavior that correlates with the inappropriate trading behavior of the MP and generates a behavior rating. In this embodiment, the CTI system monitors MP behavior suspected of being front running. If the system notices that the MP has been informed of a large deal (eg, from an auction notification in the system or through CTI distribution through the system), the system monitors the trading behavior of the notified MP. Then, the correlation between the trading behavior and the revealed CTI is analyzed. In another embodiment, the CTI system monitors MP behavior that is suspected of pegging. The system monitors the trading behavior of MPs participating in an auction (on the CTI system or another system such as POSIT.RTM.) Where the price is set relative to the market price such as the midpoint. This trading behavior is monitored looking for a negative correlation to the indicated auction order (eg, MP gained while the buy order is shown in the auction), indicating the likelihood of trying to manipulate the fulfillment price of the auction. The In another embodiment, the behavior rating also incorporates information about the MP's transaction break history.

  In all of these “rating service” embodiments, the MP being rated is used by the CTI system using confidential information to receive better prices in future transactions or to increase order flow. Allows past behavior (eg, disclosure, breakage, inappropriate trading behavior) to be rated. This rating information is stored in the CTI user database 50 and can take many forms, as will be apparent to those skilled in the art. Examples of rating forms include numerical data (percentage of disclosed trading behavior versus actual trading behavior or percentage of opening between a defined trading cap and actual trading behavior), Boolean indicator (not including market participants) 1 to n ratings that incorporate information about various trading behaviors scaled according to the novelty and frequency of a particular behavior Correlation degree of inappropriate behavior, etc.). These examples are not exhaustive and many representations of rating data will be apparent to those skilled in the art. In an alternative embodiment, the MP may require a rating “certificate” to be provided to the prospective counterpart to demonstrate the authenticity of the MP to the counterpart. A certificate is a report that is certified based on the MP market behavior history.

  These embodiments provide the described “rating service” function in addition to the auction / fulfill function shown in FIG. 29, and the rating can also be used as a distribution parameter in these embodiments. An alternative embodiment that provides a rating function does not provide a fulfillment function and operates as the targeted information dissemination mechanism shown in FIG. 27, and the rating is used as a dissemination parameter in these embodiments as well. be able to. Further embodiments do not provide a fulfillment function or targeted dissemination function, but simply operate as a certification and rating system.

  While the embodiments shown in the figures and described herein are capable of fully achieving the objectives of the present invention, many alternatives, modifications, and variations will become apparent to those skilled in the art in view of the above description. It is clear. It should be understood that these alternatives, modifications, and variations are within the scope of the invention, and that the embodiments described herein are shown by way of illustration only and not limitation.

XIV. Further embodiments The following should be construed as embodiments rather than claims.

A. A method of dialogue between electronic markets to facilitate the fulfillment of transactions,
The first electronic market receives from the broker a first indication of a firm order defining one side of the transaction of the financial instrument;
Transmitting a second indication of the firm order from the first electronic market to the second electronic market without attempting to fulfill the firm order in the first electronic market;
The second market receives the second indication;
In response to receiving the second indication by the second electronic market, the second electronic market sends a third indication of a non-firm order defined by the firm order to the first electronic market. Sending,
The first electronic market receives the third instruction;
In response to receiving the third indication by the first electronic market, identifying an order in the first electronic market that matches the non-confirmed order, wherein the matching order is the Defining and identifying the opposite side of the transaction of the financial instrument;
In response to identifying the matching order in the first electronic market, the first electronic market confirms the second electronic market and the non-confirmed order and facilitates fulfillment of the transaction. ,
Sending a fourth indication from the first electronic market that the non-confirmed order has been fulfilled to the second electronic market;
The second electronic market receives the fourth instruction;
Responsive to receiving the fourth instruction, transmitting a fifth instruction that the firm order has been fulfilled from the second electronic market to the first electronic market;
The first electronic market receives the fifth instruction, and in response to receiving the fifth instruction, the firm order is satisfied from the first electronic market to the broker; Sending a sixth indication.

  A. 1. The fifth indication identifies that the firm order has been fulfilled in the first electronic market in the form of a non-firm order, and the method is based on in which electronic market the firm order has been fulfilled The method of claim A, further comprising: determining a fee charged to the broker.

B. At least one processor configured to execute a plurality of instructions;
An apparatus comprising: at least one machine-readable medium on which the plurality of instructions are stored, wherein the plurality of instructions are executed by the at least one processor;
Receiving from a broker a first indication of a firm order that defines one side of a transaction for a financial instrument;
Sending a second indication of the firm order to the electronic market without attempting to fulfill the firm order;
Receiving from the electronic market a third indication of a non-firm order defined by the firm order;
In response to receiving the third indication, identifying an order that matches the non-confirmed order, wherein the matching order defines an opposite side of the transaction of the financial instrument;
Confirming the electronic market and the non-confirmed order in response to identifying the matching order;
Facilitating the performance of the transaction in response to confirmation of the non-firm order;
Receiving a fourth indication from the electronic market that the firm order has been fulfilled in response to facilitating fulfillment of the transaction, and in response to receiving the fourth instruction, the firm order An apparatus for performing a method comprising: transmitting to the broker a fifth indication that is satisfied.

  B. 1. The apparatus of claim B, further comprising: transmitting a sixth indication to the electronic market that the non-firmed order has been satisfied in response to facilitating fulfillment of the transaction.

  B. 2. The apparatus of claim B, wherein facilitating fulfillment includes at least one of fulfilling the transaction and sending an indication to the remote destination indicating that the transaction should be fulfilled.

B. 3. Confirming the non-confirmed order is
Sending a request to the electronic market to confirm the performance of the transaction;
The apparatus of claim B, comprising receiving a sixth indication that the transaction should be fulfilled.

  B. 3.1. Claim B. In order to confirm the non-confirmed order, the sixth indication must be received within a certain amount of time. 3. The apparatus according to 3.

  B3.1.1. The time includes a time of about 10 milliseconds to about 1 second. The method according to 1.

B. 4). The method
The method further comprises receiving an indication that the electronic market agrees to confirm the non-firm order except when at least one of the firm orders is canceled and the firm order is satisfied. The apparatus according to B.

B. 5. Identifying the matching order is
Sending an order inquiry identifying the non-confirmed order to each of a plurality of systems, wherein each order management system is associated with each of the plurality of systems; and The apparatus of claim B, comprising receiving a sixth indication of the matching order from a first system.

  B. 5.1. The order inquiry identifies the non-confirmed order as a confirmed order. 5. The apparatus according to 5.

  B. 5.2. Claim B. wherein the sixth instruction identifies that the transaction should be fulfilled without negotiation. 5. The apparatus according to 5.

  B. 5.3. Claim B. The order inquiry indicates that the transaction can be fulfilled without negotiation. 5. The apparatus according to 5.

  B. 6). The apparatus of claim B, wherein facilitating fulfillment includes facilitating fulfillment without negotiation involving price and quantity.

  B. 7). The fourth indication identifies that the firm order has been fulfilled in the form of the non-firm order, and the method determines a fee to be charged to the broker based on where the firm order has been fulfilled. The device of claim B further comprising:

  B. 7.1. The apparatus includes a second electronic market, and determining the fee comprises determining whether the firm order has been filled in the electronic market or in the second electronic market. Claim B. 8. The apparatus according to 7.

  B. 8). The apparatus of claim B, wherein the fourth indication includes a FIX message that includes a portion identifying the non-confirmed order.

  B. 8.1. The method further comprises determining a fee to be charged to the broker based on the portion of the FIX message. 9. The apparatus according to 8.

  B. 9. The apparatus of claim B, wherein the third indication includes a FIX message that includes a portion identifying the firm order.

  B. 9.1. The method further comprises determining a fee to be charged to the broker based on the portion of the FIX message. 9. The apparatus according to 9.

C. A method of trading financial instruments using an alternative trading system,
Receiving order instructions from the source that define one side of the transaction for the financial instrument;
Determining an intentional delay time from receipt of the order indication to identifying an order that matches the order, wherein the matching order defines the opposite side of the transaction about,
Deliberately delaying over said time,
Determining that the time has elapsed;
Responsive to determining that the time has elapsed, identifying an order that matches the order, and responsive to identifying the matching order to facilitate fulfillment of the transaction.

C. 1. Identifying the matching order is
Sending an order inquiry identifying the order to each of a plurality of systems, each order management system associated with each of the plurality of systems, and a first of the plurality of systems The method of claim C, comprising receiving instructions for the matching order from one system.

  C. 1.1. Claim C. The order inquiry indicates that the transaction can be fulfilled without negotiation. The method according to 1.

  C. 2. The apparatus of claim C, wherein the order comprises a non-confirmed order.

  C. 2.1. Facilitating the fulfillment of the transaction includes confirming the non-firmed order with the source, and the method includes when at least one of the non-firmed orders is canceled and the non-firmed order is satisfied Otherwise, the source further comprises receiving an indication of an agreement to confirm the non-confirmed order. The method according to 1.

  C. 3. The method of claim C, wherein facilitating fulfillment includes facilitating fulfillment without negotiation involving price and quantity.

  C. 4). The method of claim C, wherein the time includes time to avoid information leakage regarding an existing order.

  C. 5. The method of claim C, wherein determining the time includes determining the time based on historical information of canceled orders.

  C. 5.1. The historical information about the canceled order includes information specific to the source. 5. The method according to 5.

  C. 5.2. The time is determined such that a portion of the canceled order has been canceled within the time. 5. The method according to 5.

  C5.2.1. The method of claim C5.2, wherein the portion comprises a majority.

Claims (11)

An alternative trading system is a method of trading financial instruments by performing the following steps :
Receiving an order instruction from the source that defines one side of the transaction of the financial instrument;
Determining an intentional delay time between receiving the order indication and identifying an order that matches the order, the matching order Define and deliberate delays reduce information leakage about potential counterparties by not acting to find an order that matches the order or by not querying the trading system or participants in the trading system Determining the time of the intentional delay based on historical information about the canceled order stored in the storage means of the alternative trading system
Intentionally delaying over said time;
Determining that the time has elapsed;
In response to determining that the time has elapsed, identifying an order that matches the order;
Responsive to identifying the matching order, facilitating fulfillment of the transaction.
Method. Identifying the matching order comprises:
Sending an order inquiry identifying the order to each of a plurality of systems, each order management system being associated with each of the plurality of systems;
Receiving instructions for the matching order from a first system of the plurality of systems.
The method of claim 1.   The method of claim 2, wherein the order inquiry indicates performing the transaction without negotiation.   The method of claim 1, wherein the order comprises a non-confirmed order.   Facilitating fulfillment of the transaction includes confirming the non-firm order with the source, the method wherein at least one of the non-firm orders is canceled and the non-firm order is fulfilled. 5. The method of claim 4, further comprising: determining whether or not and if the result of the determination is negative, the source receives an indication of an agreement to confirm the non-confirmed order.   The method of claim 1, wherein promoting performance includes promoting performance without negotiation involving price and quantity.   The method of claim 1, wherein the time includes time for avoiding information leakage regarding an existing order.   The method of claim 1, wherein determining the time comprises determining the time based on historical information about canceled orders.   The method of claim 8, wherein historical information about the canceled order includes information specific to the source.   9. The method of claim 8, wherein the time is determined to include a portion of the canceled orders that are canceled within the time.   The method of claim 10, wherein a portion of the canceled orders is a majority of the canceled orders.

Images