US20050114258A1

US20050114258A1 - Fix-enabled order management method and apparatus

Info

Publication number: US20050114258A1
Application number: US10/959,406
Authority: US
Inventors: Neill Penney
Original assignee: Individual
Current assignee: FX Alliance LLC
Priority date: 2003-10-08
Filing date: 2004-10-07
Publication date: 2005-05-26
Also published as: US7761363B2; US20050114257A1; WO2005036354A3; WO2005036354A2

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

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

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

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.
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'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' computer systems (or networks). The provider'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' computer systems are configured to supply price quotes for to the customer'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' 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' price quotes are usually displayed on the customer'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.
The customer's computer system and the providers' 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' 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.
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.”
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' bids to a neutral daily reference rate, a provider's bidding history in terms of an average rate or average spread produced by that provider, etc.
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's best execution concerns.
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.
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' and providers' prior investments in asset trading technology.

SUMMARY OF THE INVENTION

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.
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.
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'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.
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'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's location, a funding amount associated with the requirement, a provider candidate'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.
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.
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's location, the winning provider'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's preference for executing trades for a certain type of requirement, a provider candidate'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.
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.
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.
Definition of Terms
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.
FX Terms
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.”
A “value date” or “settlement date” is the date on which the actual exchange of currencies will take place.
Parties
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.”
The term “bank,” as used herein, is typically interchangeable with the term “Provider.”
The terms “dealer,” “trader” and “treasurer” typically refer to employees of the bank or Liquidity Provider who monitor the Liquidity Provider's trading system and respond to requests for price quotes and offers to make deals as they are received from Customers.
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

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:
FIG. 1 contains a high-level block diagram illustrating an order management system configured to operate according to one embodiment of the present invention.
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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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 $25mio or under against Euros, then the system should receive price quotes from provider candidates BANK1, BANK2, BANK3 and BANK4, and should accept the provider with the best price as soon as three or more prices are available.
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.
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.
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.

Claims

1. A computer-implemented method for executing trades, comprising:

providing a first data communications link for communication with a customer and a second data communications link for communication with a multiplicity of providers;

receiving a requirement from said customer via said first data communications link; and

in response to receiving said requirement, automatically

identifying a set of provider candidates in said multiplicity of providers who will be considered to fill said requirement,

receiving a set of price quotes from said set of provider candidates,

selecting a winning provider from said set of provider candidates,

sending, via said second data communications link, a firm order to said winning provider to fill said requirement, and

recording said requirement as filled.

2. The method of claim 1, further comprising:

receiving from said winning provider, via said second data communications link, an execution detail, and

transmitting said execution detail to said customer via said first data communications link.

3. The method of claim 1, wherein said step of receiving said requirement comprises deciphering an electronic message formatted according to the financial information exchange (FIX) communications standard.

4. The method of claim 2, wherein said step of transmitting said execution detail comprises formatting a second electronic message according to the financial information exchange (FIX) communications standard.

5. The method of claim 1, wherein said step of receiving said requirement comprises deciphering an electronic message formatted according to the Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standard.

6. The method of claim 2, wherein said step of transmitting said execution detail comprises formatting a second electronic message according to the Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standard.

7. The method of claim 1, wherein said step of identifying a set of provider candidates comprises considering a customer preference.

8. The method of claim 7, further comprising:

providing a customer preferences database; and

retrieving said customer preference from said customer preferences database.

9. The method of claim 7, wherein said customer preference comprises at least one of:

a preferred provider candidate,

a maximum price,

a minimum order size,

a settlement date restriction,

a currency designation associated with said requirement,

a provider candidate's location,

a funding amount associated with said requirement,

a provider candidate's transaction history,

a service level agreement with a provider candidate,

a business volume target associated with a provider candidate, and

a performance record for a provider candidate.

10. The method of claim 1, further comprising sending a request for said set of price quotes to said set of provider candidates via said second data communications link.

11. The method of claim 1, wherein said set of price quotes comprises a substantially continuous stream of data.

12. The method of claim 1, wherein said step of selecting said winning provider comprises selecting a winning price quote received from said winning provider.

13. The method of claim 12, wherein said step of selecting said winning price quote comprises considering price selection criteria.

14. The method of claim 13, further comprising:

providing a price selection criteria database; and

retrieving said price selection criteria from said price selection criteria database.

15. The method of claim 13, wherein said price selection criteria comprises at least one of:

a relative value of said winning price quote,

an average price quote received from all provider candidates,

a currency designation associated with said requirement,

said customer's location,

a location for said winning provider,

a market risk associated with said requirement,

a funding amount associated with said requirement,

a response time for said winning price quote,

a total number of price quotes in said set of price quotes,

a preference of said winning provider to provide a type of requirement,

a provider candidate's transaction history,

a service level agreement with said winning provider,

a business volume target associated with said winning provider, and

a performance record for said winning provider.

16. The method of claim 15, wherein said performance record comprises at least one of:

an average response time,

an average price differential,

an average price stability rating,

an average bid-offer spread, and

a number of orders previously executed.

17. The method of claim 1, wherein said step of selecting said winning provider comprises determining whether said winning provider has submitted a price quote comprising a sufficient size to satisfy said requirement.

18. The method of claim 17, further comprising requesting a new price quote from said set of provider candidates.

19. The method of claim 1, further comprising receiving from said customer a time constraint for filling said requirement.

20. The method of claim 1, further comprising transmitting to said customer an acknowledgement that said requirement was received.

21. The method of claim 1, wherein said requirement comprises an agreement to buy a currency, sell a currency, or both.

22. 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, coupled to said first data communications link, that

identifies within said multiplicity of providers a set of provider candidates who will be considered for filling said requirement,

selects a winning provider from said set of provider candidates based on a set of price quotes, and

generates a firm order for said winning provider to fill said requirement;

an order executor that receives said set of price quotes from said set of provider candidates via said second data communications link, and sends said firm order to said winning provider for execution; and

an order completer that records said requirement as being filled.

23. The order management system of claim 22, wherein said order completer is further configured:

to receive, via said second data communications link, an execution detail for said execution; and

transmit said execution detail to said customer via said first data communications link.

24. The order management system of claim 22, wherein said first data communications link comprises a session manager configured to decipher an electronic message formatted according to the financial information exchange (FIX) communications standard.

25. The order management system of claim 23, wherein said session manager is further configured to format and transmit a second electronic message according to the financial information exchange (FIX) communications standard.

26. The order management system of claim 22, wherein said session manager is further configured to decipher an electronic message formatted according to the Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standard.

27. The order management system of claim 23, wherein said session manager is further configured to format a second electronic message according to the Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standard.

28. The order management system of claim 22, wherein said order generator identifies said set of provider candidates based at least in part on a customer preference.

29. The order management system of claim 28, further comprising:

a customer preferences database; and

wherein said order generator retrieves said customer preference from said customer preferences database.

30. The order management system of claim 28, wherein said customer preference comprises at least one of:

a preferred provider candidate,

a maximum price,

a minimum order size,

a settlement date restriction,

a currency designation associated with said requirement,

a provider candidate's location,

a funding amount associated with said requirement,

a provider candidate's transaction history,

a service level agreement with a provider candidate,

a business volume target associated with a provider candidate, and

a performance record for a provider candidate.

31. The order management system of claim 22, wherein said second data communications link comprises an asset trading execution system.

32. The order management system of claim 31, wherein said order executor sends a request for said set of price quotes to said set of provider candidates via said second data communications link.

33. The order management system of claim 22, wherein said order executor receives said set of price quotes within a substantially continuous stream of data produced by said provider candidates.

34. The order management system of claim 22, wherein said order executer selects said wining provider by selecting a winning price quote received from said winning provider.

35. The order management system of claim 34, wherein said order generator selects said winning price quote based on price selection criteria.

36. The order management system of claim 35, further comprising:

a price selection criteria database; and

wherein said order executor retrieves said price selection criteria from said price selection criteria database.

37. The order management system of claim 35, wherein said price selection criteria comprises at least one of:

a relative value of said winning price quote,

a price quote received from a non-winning provider,

a currency designation associated with said requirement,

said customer's location,

a location for said winning provider,

a market risk associated with said requirement,

a funding amount associated with said requirement,

a response time for said winning price quote,

a total number of price quotes in said set of price quotes,

a preference of said winning provider to provide a type of requirement,

a provider candidate's transaction history,

a service level agreement with said winning provider,

a business volume target associated with said winning provider, and

a performance record for said winning provider.

38. The order management system of claim 37, wherein said performance record comprises at least one of:

an average response time,

an average price differential,

an average price stability rating,

an average bid-offer spread, and

a number of orders previously executed.

39. The order management system of claim 22, wherein said order generator determines whether said winning provider has submitted a price quote comprising a sufficient size to satisfy said requirement.

40. The order management system of claim 22, wherein said order executor is configured to request a new price quote from said set of provider candidates.

41. The order management system of claim 22, wherein said order executor is configured to request a stream of price quotes from said set of provider candidates.

42. The order management system of claim 22, wherein said order generator receives from said customer a time constraint for filling said requirement.

43. The order management system of claim 22, wherein said order generator is further configured to transmit to said customer an acknowledgement that said requirement was received.

44. The order management system of claim 22, wherein said requirement comprises an agreement to buy a currency, sell a currency, or both.

45. The order management system of claim 22, wherein said first data communications link is coupled to a customer trading system.

46. A computer-implemented method for executing trades, comprising:

receiving a set of requirements from a customer; and

in response to receiving said set of requirements, automatically

identifying a set of provider candidates in a multiplicity of providers from which a set of price quotes will be accepted to fill said requirement,

selecting a winning provider from said set of provider candidates to fill said requirement, and

sending said requirement to said winning provider to be filled.

47. An order management system for executing trades, comprising:

customer interface means for exchanging trade-related electronic messages with a customer;

provider interface means for exchanging trade-related electronic messages with a multiplicity of providers;

requirement receiving means, coupled to said customer interface means, for receiving a requirement from said customer;

candidate identification means for identifying within said multiplicity of providers a set of provider candidates who will be considered for filling said requirement;

price selection means for selecting on behalf of said customer a winning provider to fill said requirement;

order generating means for generating a firm order for said winning provider to fill said requirement;

order execution means, coupled to said provider interface means, for receiving a set of price quotes from said set of provider candidates and for transmitting said firm order to said winning provider for execution, and for receiving from said winning provider an execution detail; and

order completion means for recording said requirement as being filled and for transmitting said execution detail to said customer via said customer interface means;

wherein said candidate identification means, said price selection means, said order generating means, said order execution means and said order completion means are configured to operate automatically responsive to said requirements receiving means.

48. The order management system of claim 47, further comprising session management means, coupled to said customer interface means, for deciphering an electronic message formatted according to the financial information exchange (FIX) communications standard.

49. The order management system of claim 48, wherein said session management means is configured to format said execution detail according to the financial information exchange (FIX) communications standard.

50. The order management system of claim 48, wherein said session management means is configured to format said execution detail according to the Society for the Worldwide Interbank Financial Telecommunication (SWIFT) communications standard.

51. The order management system of claim 47, wherein said candidate identification means comprises a customer preference.

52. The order management system of claim 51, wherein said candidate identification means further comprises:

a customer preferences database; and

means for retrieving said customer preference from said customer preferences database.

53. The order management system of claim 51, wherein said customer preference comprises at least one of:

a preferred provider candidate,

a maximum price,

a minimum order size,

a settlement date restriction,

a currency designation associated with said requirement,

a provider candidate's location,

a funding amount associated with said requirement,

a provider candidate's transaction history,

a service level agreement with a provider candidate,

a business volume target associated with a provider candidate, and

a performance record for a provider candidate.

54. The order management system of claim 47, wherein said order execution means comprises means for sending a request for said set of price quotes to said set of provider candidates via said provider interface means.

55. The order management system of claim 47, wherein said order execution means comprises means for receiving from said set of provider candidates via said provider interface a substantially continuous stream of data comprising said set of price quotes.

56. The order management system of claim 47, wherein said requirement comprises an agreement to buy a currency, sell a currency, or both.

57. The order management system of claim 47, wherein said provider interface means comprises an asset trading execution system.

58. The order management system of claim 47, wherein said requirement receiving means is further configured to receive a time constraint.

59. The order management system of claim 47, wherein said price selection means comprises a database configured to store price selection criteria.