Abstract:
A computer-implemented method and apparatus for managing market orders which, upon receiving a set of customer requirements, will automatically identify and select a winning provider from a multiplicity of provider candidates and, at the appropriate time, execute trades to fill the set of requirements. The identification, selection and execution steps are initiated automatically in response to receiving the requirements without further participation from the customer. Moreover, the invention is designed to operate according to a variety of non-proprietary messaging and communication standards, including, for example, the Financial Information eXchange (FIX) and Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standards.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application is related and claims priority under 35 U.S.C. §119 to provisional application No. 60/509,251, filed on Oct. 8, 2003, which is incorporated herein in its entirety by this reference. 
     
    
     FIELD OF ART  
       [0002]     The present invention relates generally to computerized asset trading execution systems, and more particularly to order management systems and order management functions associated with asset trading execution systems.  
       RELATED ART  
       [0003]     In the asset trading business, including for example the foreign exchange (“FX”) and money markets, customers execute trades through asset dealers, who are referred to as “liquidity providers,” or simply “providers.” In a typical scenario, a customer wishing to buy, sell, lend or borrow some quantity of assets proposes a trading transaction by sending a set of requirements (sometimes through an intermediary party, such as a broker) to one or more of the providers. The providers respond by returning price quotes for the proposed transaction indicating at what prices the providers are willing to buy (or borrow) the assets, as well as what prices they are willing to sell (or lend) the assets. The buying or borrowing price is known as the “bid,” and the selling or lending price is known as the “offer.” The difference between the bid price and offer price is known as the “bid-offer spread,” and it is this spread which generates profits for the liquidity providers, since they are always buying and borrowing slightly more cheaply than they are selling and lending.  
         [0004]     Automated asset trading systems have been introduced to facilitate faster, more efficient and, for auditing purposes, more traceable, trading transactions between customers and providers. Typically, these systems comprise a customer trading program (or, in some instances, a suite of trading programs) running on a customer&#39;s computer system (or network), which accepts requirements from the customer and sends a request for quotes (“RFQ”) to one or more trading programs running on the providers&#39; computer systems (or networks). The provider&#39;s computer systems usually respond to the RFQ in real time by returning price quotes for the specified requirements. In some cases, however, the providers&#39; computer systems are configured to supply price quotes for to the customer&#39;s computer system in a continuous or substantially continuous stream without receiving a specific RFQ for a specific requirement. In a price quote stream, the providers&#39; rates for filling certain kinds of requirements are being updated almost constantly and the customer may, more or less, monitor the movement of the market and select a desired price quote or provider at any time. The providers&#39; price quotes are usually displayed on the customer&#39;s computer system. When the customer selects a quote or provider, an instruction is sent to the provider to go ahead and execute the appropriate trades to fill the requirement.  
         [0005]     The customer&#39;s computer system and the providers&#39; computer systems talk to each other by exchanging a series of messages via one or more data communication channels established within an interconnected computer network, such as the Internet, a dedicated wide area network (WAN), or a corporate intranet. The messages carrying the providers&#39; quotes and customers trading instructions may be channeled through an intermediate or centralized asset trading execution system (or “trading portal”) connected to the interconnected computer network. Typically, the intermediate asset trading execution system is configured to coordinate, compare, match, error-check and/or log the messages on behalf of the customers and liquidity providers. In some cases, the trading server is managed and operated by a third party. FX Alliance, LLC of New York, N.Y. (FXall) is one example of a third party operator of an automated asset trading execution system for the FX market.  
         [0006]     Often customers who use conventional automated asset trading systems have many requirements that they would like to have filled within a specified timeframe without having to go through all of the trouble and effort of receiving, reviewing, selecting and confirming provider price quotes and then deciding if and when to actually execute the trades in the market. These customers do not want to be involved in managing all of the minute details associated with filling the requirements. They simply want to send requirements out to be filled and be told when and at what price the trade was completed. What these customers need, in effect, are “agents” who will act on their behalf in executing trades to fill these requirements. This process is known as placing a “market order.” 
         [0007]     On the other hand, these customers also want to have assurances that agents filling market orders on their behalves utilize objective price-selection and execution processes that ensure that the trades will be executed at rates that are at least competitive, if not the best, rates available in the market. These customers do not want their agents to rely, for example, on only one or perhaps two providers who have no real incentive to offer fair and competitive execution rates. Thus, the customers and their agents have developed certain practices, known in the industry as “best execution” practices, for making sure they are obtaining competitive rates. Best execution practices usually involve tactics such as accepting bids from a multiplicity of providers who are in competition with each other to execute trades, and selecting providers using objective selection criteria, such as a comparison of providers&#39; bids to a neutral daily reference rate, a provider&#39;s bidding history in terms of an average rate or average spread produced by that provider, etc.  
         [0008]     However, the conventional automated asset trading systems typically do not obtain price quotes from a multitude of providers. A principle reason for this is that they use proprietary and non-standard data communication protocols to talk to the provider trading systems to which they are connected. Thus, adding an additional provider connection to one of the conventional automated asset trading systems usually requires a separate and expensive communication protocol upgrade. Owing to the time and expense required to make these upgrades, most conventional asset trading systems are connected to only one provider. In some cases, the conventional asset trading systems are proprietary, not because of communications protocol issues, but as a result of partnership contracts and other agreements between the trading system operators and certain providers. Either way, the limited access to providers results in a compromise in terms of meeting the customer&#39;s best execution concerns.  
         [0009]     Since the previous automated systems for market orders have been proprietary—i.e., using proprietary communications protocols and/or providing limited access to providers—customers who need or want to place market orders with multiple providers have had to resort to using manual, non-automated tools and devices, such as spreadsheets, telephones and fax machines. But the manual tools and devices are too slow, cumbersome and error-prone to be really productive. For example, customers or customer agents wishing to compare bids from a multiplicity of providers must send the requirements to each provider separately by telephone, fax machine (or, more recently, by email), wait to receive bids from each provider, manually compare the bids to each other and/or to a neutral daily execution rate, select a winning provider and, finally, telephone, fax or email an offer to deal to the selected winning provider. Obviously, this is a very time consuming, manually intensive and costly process, which is made worse by the fact that the customer typically already owns an asset trading computer system which performs a variety of other asset trading functions unrelated to processing market orders.  
         [0010]     Therefore, there is a need in the trading industry for an automated system capable of executing market orders and providing best execution by obtaining prices from multiple providers and applying objective criteria for selecting a winning provider. There is also a need for this automated system to function using standard and well-supported communication protocols so that it can be used with a multiplicity of conventional customer and provider trading systems without requiring costly communications protocol upgrades, thereby protecting customers&#39; and providers&#39; prior investments in asset trading technology.  
       SUMMARY OF THE INVENTION  
       [0011]     The present invention addresses the above-described problems and concerns by providing a computer-implemented method and apparatus for managing market orders which, upon receiving a set of customer requirements, will automatically identify and select a winning provider from a multiplicity of provider candidates and, at the appropriate time, execute trades to fill the set of requirements. These steps are initiated automatically in response to receiving the requirements without further participation from the customer. Moreover, the invention functions according to a variety of non-proprietary messaging and communication standards, including, for example, the Financial Information eXchange (FIX) and Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standards.  
         [0012]     In general, the invention comprises a computer-implemented method for executing trades. The method comprises the steps of: (1) providing a first data communications link for communication with a customer and a second data communications link for communication with a multiplicity of providers; (2) receiving a requirement from the customer via the first data communications link; and (3) in response to receiving the requirement, automatically (i) identifying a set of provider candidates in the multiplicity of providers who will be considered to fill the requirement, (ii) receiving the set of price quotes from the set of provider candidates, (iii) selecting a winning provider from the set of provider candidates, (iv) sending, via the second data communications link, a firm order to the winning provider to fill the requirement, and (v) recording said requirement as filled. Optionally, the method further includes the steps of: (vi) receiving from the winning provider, via the second data communications link, an execution detail, and (vii) transmitting the execution detail (perhaps along with other information in the form of a report) to the customer via the first data communications link.  
         [0013]     The requirement may comprise, for example, a request to enter into an agreement with a provider to buy a currency, to sell a currency, or both. Thus, the requirement may include, for example, the customer&#39;s request to enter into a transaction with a provider in which the customer trades $10 mio for an appropriate amount of Euros at the market rate. In preferred embodiments, the steps of receiving the requirement and transmitting the execution detail include, respectively, deciphering and formatting electronic messages that meet the financial information exchange (FIX) communications standard. The FIX messaging protocol standard, which can found on the Internet at www.fixprotocol.org, is a series of messaging specifications developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. In alternative preferred embodiments, the steps of receiving the requirement and transmitting the execution detail include, respectively, deciphering and formatting electronic messages that meet the Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standard.  
         [0014]     Preferably, the set of provider candidates is identified based on or in accordance with a customer preference, which may be retrieved from a customer preferences database or received through the first data communications link along with the requirement. The customer preference may comprise, for example, one or more of the following: a preferred provider candidate&#39;s name or account, a maximum price for the requirement, a minimum order size, a settlement date restriction, a currency designation associated with the requirement, a provider candidate&#39;s location, a funding amount associated with the requirement, a provider candidate&#39;s transaction history, a service level agreement with a provider candidate, a business volume target associated with a provider candidate, or a performance record for a provider candidate.  
         [0015]     The price quotes received from the provider candidates may be received in response to a specific RFQ or, alternatively, as part of a continuous or substantially continuous stream of data produced by the provider candidates. The stream of data is considered “substantially continuous” because it may be started and stopped at predetermined times, may be temporarily interrupted and restarted, and/or may be slowed down or speeded up, for example, due to operator preference, anomalies in network throughput performance, scheduled maintenance, etc.  
         [0016]     Winning providers may be selected from the set of provider candidates based on predefined price selection criteria, which may, or may not, be very similar to the customer preferences. In preferred embodiments, for example, the predefined price selection criteria may comprise at least one (and preferably more than one) criterion, such as the relative value of the winning price quote, an average of price quotes received from all providers, a currency designation associated with the requirement, the customer&#39;s location, the winning provider&#39;s location, a market risk associated with the requirement, a funding amount associated with the requirement, a response time in which the winning price quote was received, a total number of price quotes received, a provider&#39;s preference for executing trades for a certain type of requirement, a provider candidate&#39;s transaction history, a service level agreement with a provider, a business volume target associated with a provider, or a performance record for a certain provider.  
         [0017]     In another aspect of the invention, there is provided an order management system for executing trades, comprising a first data communications link for receiving a requirement from a customer, a second data communications link for communication with a multiplicity of providers, an order generator, an order executor and an order completer. The order generator, which is coupled to the first data communications link, identifies within the multiplicity of providers a set of provider candidates who will be considered for filling the requirement. The system may be configured, for example, to only receive price quotes (or to only entertain price quotes) from the set of provider candidates, thereby ignoring price quotes received from other providers in the multiplicity of providers, or never requesting them. The order generator also selects the winning provider from the set of provider candidates based on a set of price quotes received from the provider candidates, and generates a firm order for the winning provider to fill the requirement. The order generator receives the set of price quotes from the order executor, which receives them from the set of provider candidates via the second data communications link. The order executor also receives the firm order from the order generator and sends it to the winning provider for execution. The order completer records the requirement as being filled and, optionally, receives an execution detail for the execution via the second data communications link and transmits the execution detail to the customer via the first data communications link.  
         [0018]     The invention provides significant advantages over existing manual and automated systems in that it provides fully-automated execution of market order asset trading transactions and ensures that these market orders are executed at competitive rates. Another significant advantage is that it may be used in conjunction with conventional customer trading systems. While the invention is particularly advantageous (in terms of time and effort saved) for customers who may have a large number of small market orders to execute, there is also no reason why larger orders could not be filled using the invention.  
         [0000]     Definition of Terms  
         [0019]     As used in this description, except to the extent that the context indicates otherwise, the following terms may be understood with reference to the definitions provided below.  
         [0020]     FX Terms  
         [0021]     A “foreign exchange” or “FX” transaction (or “deal”) is a contract to exchange one currency for another at an agreed rate on a specified delivery date, also called a “value date” or “settlement date.” 
         [0022]     A “value date” or “settlement date” is the date on which the actual exchange of currencies will take place.  
         [0023]     Parties  
         [0024]     The term “Provider” is typically a shorthand reference to a “Liquidity Provider.” A “Liquidity Provider” is typically a financial institution, such as a bank, that serves as a market maker in a trading system. Liquidity Providers quote prices in response to requests from “Customers.” 
         [0025]     The term “bank,” as used herein, is typically interchangeable with the term “Provider.” 
         [0026]     The terms “dealer,” “trader” and “treasurer” typically refer to employees of the bank or Liquidity Provider who monitor the Liquidity Provider&#39;s trading system and respond to requests for price quotes and offers to make deals as they are received from Customers.  
         [0027]     The term “Customer” typically refers to the party in a trading transaction who wishes to buy or sell assets and who is not a Provider or employee of a Provider. Customers initiate the dealing process by asking one or more Providers for a price on a particular FX instrument, such as a swap, forward or spot agreement. The term “Customer” may also refer to an aggregation of users, as, for example, in a company. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0028]     The present invention and various aspects, features and advantages thereof are explained in detail below with reference to exemplary and therefore non-limiting embodiments and with the aid of the drawings, which constitute a part of this specification and include exemplary embodiments of some of the various forms of the invention. In these drawings:  
         [0029]      FIG. 1  contains a high-level block diagram illustrating an order management system configured to operate according to one embodiment of the present invention.  
         [0030]      FIG. 2  contains a high-level flow diagram illustrating the overall algorithm that may be performed by embodiments of the present invention, such as the order management system shown in  FIG. 1 , to implement the invention.  
     
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0031]      FIG. 1  shows a high-level block diagram of the major functional components of an order management system configured to operate according to an illustrative embodiment of the present invention. As shown  FIG. 1 , order management system  100  comprises order generator  120 , customer session manager  122 , customer preferences database  124 , order completer  126 , order executor  128  and price selection criteria database  130 . Preferably, order management system  100  is coupled to a customer trading system  105  via a data communications link or interface (shown in FIG. I as link  180 ). The invention also may be coupled to an asset trading execution system  110  by another data communications link or interface (shown in  FIG. 1  as link  182 ). For simplicity,  FIG. 1  shows asset trading execution system  110  as being connected to single provider system, provider trading system  115 , via a third data communications link or interface (shown in  FIG. 1  as link  184 ). Typically, however, asset trading execution system  110  is connected to a multiplicity of provider trading systems (not shown in  FIG. 1 ), some or all of which are configured to stream price quotes (or otherwise provide price quotes in response to specific RFQs) to asset trading execution system  110 , which makes them available to order management system  100 . Preferably, each one of the provider trading systems connected to asset trading execution system  110  comprises a rate engine  138  to generate quotes or quote streams, and a provider session manager  140  configured to handle communications (e.g., message timing, handshaking, data integrity checking and encryption) with a corresponding provider session manager  136  running on asset trading execution  110 . Asset trading execution system  110  usually contains, among other things, a quoting engine  132  to process quotes received from the provider trading systems and a deal database  134  to record pending and executed trades.  
         [0032]     In preferred embodiments, the customer session manager  122  is configured to manage data communications over an interconnected computer network, such as the Internet, with a corresponding customer session manager  142  running on customer trading system  105 . These corresponding session managers, which are programmed to operate according to methods and protocols well known in the data communications industry, allow the customer to successfully use a variety of customer order management systems  144 , which may be proprietary, supplied by the manufacturer of order management system  100 , custom-built or available as a commercial off-the-shelf product.  
         [0033]     Preferably, customer session managers  122  and  142  are FIX-enabled communications engines. That is, they are configured to communicate with each other by using the FIX (Financial Information eXchange) protocol to exchange electronic messages formatted according to the FIX communications standard. These session managers also take care of and ensure the messages exchanged between order management system  100  and customer trading system  105  are secure and reach their destinations with integrity. Although FIX is a preferred standard for these communications, it should be apparent to those skilled in the art, upon reading this disclosure, that various other protocols and standards (e.g., SWIFT) may be employed to handle data communications between order management system  100 , customer trading system  105  and provider trading system  115 . The data transmitted over interface link  180  also may be encrypted for security purposes.  
         [0034]     When the customer enters one or more trading requirements into customer order management system  144 , customer session manager  142  converts the data into FIX formatted electronic messages, encrypts the data, if necessary, and transmits it over the network via data communications link  180  to customer session manager  122 . Customer session manager  122  will then reverse the process, thereby decrypting the data and deciphering (i.e., parsing) the FIX formatted message to generate a copy of the requirement, which is then passed along to order generator  120 . The customer session manager  122 , order generator  120 , or some other component of order management system  100 , may also be configured to send an acknowledgement message back to the customer to confirm receipt of the requirement. But sending such an acknowledgement is optional.  
         [0035]     As stated above, order management system  100  is connected, via data communications link  182 , to asset trading execution system  110 , which in turn is connected to a multiplicity of providers. Order generator  120  identifies within the multiplicity of providers a set of provider candidates who will be considered for filling the requirement. The identification may be accomplished by retrieving a set of customer preferences from an optional customer preferences database  124  and examining the preferences to determine potential decision-making factors such as whether the customer has specified a preferred provider, where the customer is located, whether the customer has a service level agreement to provide a certain number of trades or volume of business to a provider in the multiplicity of providers, a settlement data restriction, etc.  
         [0036]     Order executor  128  is configured to retrieve quotes from the set of provider candidates through asset trading execution system  110 . This may entail retrieving price quotes that are already flowing into asset trading execution system  110  as part of one or more substantially continuous streams. But it may also be accomplished by sending specific requests for the provider candidates to provide price quotes for this particular requirement. In preferred embodiments, order executor  128  is determines whether the provider candidates are already providing quotes in sufficient sizes to satisfy the requirement, and, if necessary, issues a request to receive a new price quote or a new price quote stream.  
         [0037]     Relying on the price quotes received by order executor  128 , order generator  120  examines the set of price quotes and selects a winning price quote, and therefore a winning provider, based at least in part on a set of price selection criteria, which may be retrieved from optional price selection criteria database  130 . Such performance criteria may include, for example, factors such as an average response time, an average price differential, an average price stability rating, or average bid-offer spread associated with a provider candidate, or the number of orders previously executed by the provider candidate. Preferably, the system is configured, through methods well-understood in the computer industry, to track this kind of information concerning the multiplicity of providers, and to store it in the price selection criteria database  130 .  
         [0038]     Order generator  120  generates a firm order for the winning provider to fill the requirement, and then passes the firm order back to the order executor  128 , which, through communication with asset trading execution system  110 , sends the firm order to the winning provider for execution. In preferred embodiments, the requirement received from customer trading system  105  comprises a preferred execution time or timeframe, which may be used by order executor  128  to determine exactly when to send the firm order to the winning provider for execution.  
         [0039]     After the trade is executed on asset trading execution system  110 , an execution report may be generated and returned to order management system  100  via data communications link  182 . The execution report contains execution details such as the executing provider, the execution rate, the settlement data, the time of execution, etc. Upon receiving this execution report, order completer  126  records the requirement as being filled and typically downloads the report to customer trading system  105  via customer session manager  122  and data communications link  180 .  
         [0040]     Flow diagram  200 , shown in  FIG. 2 , is a high-level flow diagram illustrating the overall algorithm that may be performed by embodiments of the present invention, such as the order management system shown in  FIG. 1  and discussed above, to implement the invention. As shown in  FIG. 2 , the first step, step  205 , is to receive requirements from the customer. In preferred embodiments, the system sends an acknowledgement back to the customer confirming that the requirements have been received (step  210 ). Next, at step  215 , a set of provider candidates are identified, preferably according to a set of customer preferences, as described above. The requirement may specify, for example, that if the customer wishes to sell $ 25 mio or under against Euros, then the system should receive price quotes from provider candidates BANK 1 , BANK 2 , BANK 3  and BANK 4 , and should accept the provider with the best price as soon as three or more prices are available.  
         [0041]     At step  220 , the system determines whether the providers identified as candidates are already streaming price quotes of sufficient size to meet the requirement. If not, the system sends the provider candidates a request to start submitting quotes in sizes that are sufficient to satisfy the executable order (step  230 ). If the provider candidates are already streaming price quotes of sufficient size, then, at step  225 , the system selects a winning provider (based, preferably on a predefined set of price selection criteria), generates a firm order for the winning provider to execute a trade to satisfy the requirements, and schedules an execution time according to the requirement, a customer preference, or both. As shown in step  235 , the next step is to actually send the firm order to the winning provider.  
         [0042]     Subsequently, the system checks to see if the firm order has been executed (step  240 ). If the order has been executed, an execution report containing execution details is sent to the customer (step  245 ) and processing ends. If not, the system checks, at step  250 , to see if the order was supposed to be executed immediately. If immediate execution was not requested, then processing continues at step  260 , where the system schedules another execution attempt, and then at step  215 , where a suitable set of provider candidates are identified. If, on the other hand, it is determined at step  250  that immediate execution was requested, then the system sends a message to the customer indicating that the order expired (step  255 ) and processing ends.  
         [0043]     The present invention has been disclosed and described herein in what is considered to be its most preferred embodiments. It should be noted that variations and equivalents may occur to those skilled in the art upon reading the present disclosure and that such variations and equivalents are intended to come within the scope of the invention and the appended claims. Therefore, for example, it should be understood by one skilled in the art that the present invention is not limited to foreign exchange transactions, and may be beneficially applied to other types of transactions as described above.