Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
  • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

• This invention relates to the field of foreign exchange of currencies.
• the invention relates to systems, methods and apparatuses for providing improved workflow and multi-bid foreign exchange using networked computers. Description of the Related Art
• the foreign exchange market is considered to be the largest and most liquid market in the world.
• the Federal Reserve Bank of New York estimated, in 1998, that the daily turnover was around $1.5 trillion a day. See, The Foreign Exchange Market in the United States, Sam Y. Cross, Federal Reserve Bank of New York, available at ⁇ http://www.ny.frb.org/pihome/addpub/usfxm/>, p. 15, hereinafter Cross.
• the term "foreign exchange” refers to money denominated in the currency of another nation, or group of nations. See Cross, p. 9. As such, a person who exchanges money denominated in her/his own nation's currency for money denominated in another nation's currency acquires foreign exchange. Id. This is true irrespective of the size of the transaction; the person performing the transaction; or the form of money being acquired, e.g. notes, bank deposits denominated in another currency, claims denominated in another currency, etc. The term will sometimes be referred to by the commonly used abbreviation "FX".
• a "foreign exchange transaction” is a shift of funds, or short-term financial claims, from one country and currency to another. Id.
• the "foreign exchange market” refers to the global network of dealers engaged in trading around the world. C.f. Cross, p. 9.
• exchange rate sometimes referred to as a "price quote” or “rate” is the number of units of one nation's currency that must be surrendered in order to acquire one unit of another nation's currency. Id. However, at any given time there are multiple exchange rates for a given currency, e.g. for different buyers or dealers and different types of foreign exchange transactions.
• the term "payment” refers to the transmission of an instruction to transfer value that results from a transaction.
• the term “settlement” refers to the final transfer of the value specified in the payment instructions.
• WidgetCo buys JPY 100,000,000 for USD 1,000,000, spot
• the traders have agreed to the terms of the transaction.
• Payment occurs when settlement instructions are transmitted. Settlement, or execution, of that transaction does not occur until later. In most transactions, there are two transfers of money value in opposite directions.
• the term "foreign exchange need” refers to a need for an amount of foreign exchange at a particular time.
• WidgetCo had a foreign exchange need for JPY 100,000,000 two days hence — since spot trades settle at T+2 in the United States at present.
• a "program” is a sequence of instructions that can be executed on a computer.
• the program may comprise source code, object code, byte code, and/or any other sequence of instructions that can be executed on a computer.
• a "computer”, or computer system, refers to a computer, a group of computers coupled in communication, and/or some other type of computing device.
• a “module” is a logical entity comprised of one or more programs related to one another for providing a function. Additionally, a module can be comprised of one or more modules. A single module may be implemented across a number of computers. For example, in a client-server architecture, a module might be comprised of client side programs for execution on a client computer as well as server side programs for execution on a server computer. Trading Modalities
• third party brokers act on behalf of clients in the over-the-counter market for foreign exchange in return for a fee or commission. This is different from dealers, who will sometimes act as principals in a transaction, e.g. take one side of the deal. Brokers are estimated to handle about one fourth of the foreign exchange transactions in the United States. See Cross, p. 27.
• CreditCardCo a credit card company that accepts transactions overseas for dollar-denominated credit card accounts
• WidgetCo a company that has overseas operations and transactions
• InvestCo an investment company that trades assets overseas.
• CreditCardCo is concerned about getting good exchange rates. For this purpose, they have several employees who place simultaneous phone calls to different dealers with whom CreditCardCo has relationships. The dealers give an immediate price and the employees call those prices out to another employee who writes the prices on a board. That employee selects the best price and instructs one of the employees on the phone to complete the transaction with the appropriate dealer.
• WidgetCo regularly needs to perform foreign exchange transactions to pay for operations overseas. WidgetCo had in the past gone through a telephone to the trading desk at their bank MegaBank. Recently, WidgetCo has begun using MegaBank's dedicated system. This allows WidgetCo to place its transactions at the rate MegaBank is quoting at a given time. These systems are not providing "real time" quotes in the way that the telephone dealers were, but rather are providing a quote based on a ratio off a quote in a pre-loaded table. In this approach, the quote given is only as good as the table and the ratio specifying the extent to which the rate is to be adjusted. This system is desirable to MegaBank because it reduces their costs for "small,” e.g. less than USD 5 million transactions. In some instances, the system may allow for transfer to a live dealer, either by phone or chat, if the transaction size is sufficiently large. This system is also desirable to MegaBank because the quote is more competitive and it locks the client into using the bank for its foreign exchange. InvestCo
• InvestCo has several mutual funds for which it trades equities for its clients. For example, InvestCo might have an international stock fund with holdings in Japan, Europe, and China. As InvestCo's managers perform trades in those stocks, foreign exchange needs will arise.
• InvestCo may have a number of employees who review equity transactions to identify foreign exchange needs. For example, a buy on Hitachi in Japan today will require settlement, e.g. Japanese Yen, to be paid three days hence, e.g. T+3. The employees can review these equity transactions and place orders the following day, as most currencies trade at T+2.
• Waldron Management Services, Inc. developed FX Fox for foreign exchange execution that provides for multiple bids.
• the system was implemented using a character terminal based program on a Digital Equipment Corporation (DEC) system running the Virtual Memory System (VMS) operating system.
• DEC Digital Equipment Corporation
• VMS Virtual Memory System
• the system currently has approximately ten customers signed up and approximately twenty banks signed up. The system has been available since 1996 and several dozen trades a day are handled. The system is focused on transaction execution using a multi-bid framework.
• the multi-bid framework works as follows:
• the system sorts bids by rate competitiveness for the customer.
• Customer has a short time period to accept bids, e.g. less than 10 seconds.
• Dealers do not know whether other dealers are bidding — or even logged in — in order to encourage competitive quotes at all times. However, at any time prior to when the customer accepts a bid, a dealer can pull the quote.
• the customer can further restrict the list of banks to which a given request is presented. This can be important when large requests are made. If multiple participants in the market know that a large request is coming, they may give a much less competitive bid because of their perception of risk. This risk arises from the practice of "front running" where participants may make trades in advance of a customer knowing that the subsequent trade will move prices in a particular direction. When fewer institutions see a request, they can break it into smaller, less visible pieces to reduce the effect of the trade on the market price.
• Customers can either provide settlement instructions at the end of their trading session, or the customer can memorize certain types of transactions, e.g. sell Euro, and provide settlement instructions that are associated with that transaction.
• Prior approaches to supporting foreign exchange transactions have used proprietary systems and approaches that tend to favor established dealers over smaller dealers and customers.
• Prior approaches have not provided workflow features.
• Prior approaches have not provided for interoperability as a component of a larger system in which foreign exchange order execution is a component. Accordingly, what is needed is a system for multi-bid foreign exchange workflow automation.
• Embodiments of the invention allow customers to receive competitive price quotes to meet foreign exchange needs from dealers through a multi-bid foreign exchange execution process.
• the multi-bid foreign exchange execution process encourages dealers to place more competitive price quotes. However, it simultaneously increases the number of price quote requests that dealers receive from their customers.
• Some embodiments of the invention support dealer computers communicating via a network with customer computers.
• the dealer computers respond to requests for bids, e.g. price quotes, for foreign exchange needs from customers with price quotes.
• the customer computers place requests for bids for foreign exchange needs and respond to price quotes received from dealer computers.
• a transaction server enforces time limits associated with multi-bid foreign exchange execution between customer computers and dealer computers. Additionally, the transaction server monitors latency across the network.
• the dealer computers may be operated by dealers, e.g. traders operating on behalf of banks or other institutions bidding to meet customer foreign exchange needs. However, the dealers may program the dealer computers with one or more rules to automatically respond to one or more requests.
• the customer computers may be operated by customers, e.g. traders operating on behalf of a management or other institution with foreign exchange needs. However, the customers may program the customer computers with one or more rules to automatically place requests and/or respond to price quotes.
• the dealer computers may correspond to two or more different legal entities.
• the customer computers are able to receive price quotes from different banks or other institutions at a single time.
• the customer computers may correspond to two or more different legal entities. Accordingly, dealers are able to receive requests from different customers on a single network.
• the network may be a public network, e.g. the Internet, a private network, and/or a combination of different networks.
• the network may have a number of network devices, e.g. routers, switches, etc., that control the flow of data across the network.
• the transaction server sends instructions to the network devices in response to the latency information.
• the transaction server could instruct a router to send packets from the dealer computer Dl to the transaction server over a different path or to instruct the application on the dealer computer to connect to an address of a nearer proxy for the transaction server.
• Some embodiments of the invention may be deployed across a network having a mixture of guaranteed quality of server (QoS) and non-guaranteed QoS connections. Further, such embodiments may be deployed using points of presence coupled to the transaction server by guaranteed QoS connections while the dealer computers and customer computers are coupled to the points of presence by non-guaranteed QoS connections.
• QoS quality of server
• non-guaranteed QoS connections may be deployed using points of presence coupled to the transaction server by guaranteed QoS connections while the dealer computers and customer computers are coupled to the points of presence by non-guaranteed QoS connections.
• This network topology significantly reduces the costs normally associated with using guaranteed QoS links as there are fewer long distance links.
• it can ensure that overall network performance meets service preferences, e.g. a predetermined latency threshold.
• embodiments of the invention may make use of encryption at the transport layer of the network protocol, e.g. using the transport layer security (TLS) protocol — formerly known as the secure sockets layer (SSL) protocol. Additionally, embodiments of the invention may use additional authentication methods to allow specific customers and dealers to identify themselves to the transaction server via their respective customer and dealer computers.
• TLS transport layer security
• SSL secure sockets layer
• Embodiments of the invention may extend the time limits for multi-bid execution according to latency characteristics for the network. For example, if from monitoring the latency, the transaction server identifies an average latency of 200 ms, then responses received within the appropriate time limit plus 200 ms could be accepted.
• the customer and dealer computers may take a number of forms. For example, handheld computers with wireless networking could serve as customer — or dealer — computers. Further, some embodiments of the invention support as customer and dealer computers, computers providing a standard web browser with support for Java(TM) and/or Javascript(TM), an Internet kiosk, a personal computer with Microsoft(TM)
• the transaction server supports automatic transfer of settlement information between counter parties to a transaction, e.g. a customer and the dealer who's offer that customer accepted. This may occur automatically, e.g. after the customer accepts a dealer's offer, the settlement information could be transmitted.
• Embodiments of the invention can support a broad range of standard — as well as non-standard — foreign exchange transaction types. Some embodiments of the invention support one or more of the following transaction types: spot transactions, outright forward transactions, spot-next transactions, tom-next transactions, spot-a-week transactions, spot-two-weeks transactions, spot-forward transactions, odd-date transactions, forward-forward transactions, long date transactions, and/or currency swap transactions. Uses of embodiments of the invention for reducing currency risk in electronic commerce will now be considered.
• Some embodiments of the invention support integration with electronic commerce to reduce currency risk. Accordingly, when a party (e.g. a buyer) conducts a transaction with another party (e.g. the seller) using a commerce site, the system can identify foreign exchange needs arising from the transaction.
• a party e.g. a buyer
• another party e.g. the seller
• the system can identify foreign exchange needs arising from the transaction.
• a message can be sent to an appropriate party, e.g. the buyer, offering to provide foreign exchange execution.
• an appropriate party e.g. the buyer
• an area could indicate that "EUR 5,000,000 will be needed Friday" together with a button to allow the buyer to respond signaling her/his interest in having that foreign exchange need met with competitive price quotes.
• the commerce site could then submit the foreign exchange need for multi-bid execution and present received price quotes to the buyer.
• the buyer in turn could accept — or decline — the presented offers.
• the effect of this is to eliminate currency risk from transactions as the foreign exchange needs can be met in conjunction with transaction completion.
• Additional embodiments of the invention may support real-time presentation of the best price quote for completing a transaction. Accordingly, a buyer would see the seller's price for a transaction in her/his preferred currency prior to transaction completion, e.g. prices for items Euros. As the multi-bid execution process time limit for responding to a quote expires, new quotes could automatically be requested. This approach allows buyers to view the commerce site in their preferred currency and conduct transactions in real-time without currency risk.
• Embodiments of the invention may deployed for business-to-business commerce as well as business-to-consumer commerce.
• Embodiments of the invention may use the credit relationship between the commerce site and dealers to determine distribution of requests to dealers participating in the multi-bid foreign exchange execution process.
• Other embodiments may use the credit relationship between the purchaser, e.g. the buyer, and the dealers to determine distribution of requests.
• the first approach has the advantage of allowing smaller companies to use the credit relationship of the commerce site to gain wider distribution of the requests.
• Some embodiments of the invention automatically transmit settlement information from the buyer to the dealer and vice versa.
• Embodiments of the invention use a graphical user interface to allow customers and dealers for foreign exchange execution.
• Embodiments of the invention may be provided as a single set of one or more programs for both customers and dealers, thus enabling customers to act as dealers and vice versa.
• the interface for customers supports a graphical tasks list.
• the tasks list contains foreign exchange needs that the customer has to execute.
• a second visual indication can be provide to allow requests for multi-bid foreign exchange execution of tasks can be provided. For example, when a customer clicks on a task in the tasks list, the second visual indication could allow the customer options relating to submitting a request for the foreign exchange need corresponding to the task. Thus, if the task was to buy EUR 5,000,000, spot, the second visual indication might include options to customize the request for price quotes, e.g. bid the request as a two-way quote, hedge currency risk by requesting the transaction as part of a currency swap, etc.
• the tasks list is updated. For example, completed tasks may be removed from the tasks list. Similarly, completed tasks could be sorted to the bottom of the tasks list, have their coloring changed, have an icon assigned, etc. This assists customers in fulfilling all of the foreign exchange needs she/he has been assigned to complete in a given period in an integrated fashion relative to the execution.
• the tasks list may be imported from an outside data source, e.g. an enterprise resource planning
• embodiments of the invention may support a graphical user interface to price quote selection. This can be provided with a third visual indication for displaying received price quotes.
• Conventions such as sorting the price quotes in order of cost, e.g. with the least cost price quote at the top, showing the dollar cost of each quote relative to the least cost price quote, and/or assigning a default keyboard shortcut to select the least cost price quote can be used.
• Still more options can be provided to adjust the shading, coloring, and/or icons associated with price quotes.
• Some of these settings may be defined from customer defined rules, e.g. "Display all price quotes more than USD 1,000 from the least cost quote in gray.” These rules may reflect customer preferences, e.g. "I like my best quotes in bright red”, as well as customer requirements, e.g. "I am supposed to buy from MegaBank if their quote is within 3% of the best quote.”
• FIG. 1 may depict a diagrammatic representation of a quote.
• FIG. 1 may depict a diagrammatic representation of a quote.
• FIG. 1 may depict a diagrammatic representation of a quote.
• FIG. 1 may depict a diagrammatic representation of a quote.
• FIG. 1 may depict a diagrammatic representation of a quote.
• FIG. 1 may depict a diagrammatic representation of a quote.
• Embodiments of the invention support a graphical user interface for dealers designed to allow for a high volume of executions. As such, a number of visual indications can be provided on the display area. Each of them for receiving requests from customers and allowing the dealer to respond to that request with price quotes.
• the visual indications can be distributed over the display area so as not to overlap one another. This prevents the need to toggle, or switch, between different views, screens, monitors, etc., to handle several transactions at once. For example, some embodiments of the invention provide three simultaneous visual indications.
• Each of the visual indications may also be assigned a keyboard shortcut to permit rapid selection of a visual indication. This reduces the amount of mouse movement needed to switch the keyboard input focus among the visual indications. Thus if the dealer is working in a first visual indication and a second request comes in on a second visual indication, the dealer can easily switch the keyboard focus to allow her/him to provide a quote for the second request without needing to use the mouse.
• embodiments of the invention automatically assign incoming requests to visual indications in the plurality of visual indications. For example, if a particular visual indication is in use, it will not be assigned a new request until the earlier request is finished, e.g. the customer accepts the offer, time runs out, or the customer accepts a different dealer's offer.
• embodiments of the invention may supply the most recent quote given by the dealer along with the age of the quote, e.g. BUY EUR 0.9950 (31 seconds ago).
• Some embodiments of the invention may allow the dealer to develop one or more rules for implementing preferences and practices as well as for automatically responding to quotes. For example, the dealer could develop one or more rules to highlight her/his preferred customers' bid requests with an icon. Similarly, the dealer could program automatic price quote responses for small dollar volume transactions, e.g. automatically use my last quote — if less than sixty seconds old — times 0.0005 on transactions with a total value less than USD 100,000, etc. This allows the system to allow dealers to respond most competitively on quotes that are most relevant for them. Embodiments of the invention supporting workflow automation of foreign exchange will now be considered.
• Embodiments of the invention support identification of foreign exchange needs from the transaction information in those systems for workflow completion of the foreign exchange execution. Accordingly, embodiments of the invention can receive tasks from a computer system, e.g. the company's ERP system. These tasks each correspond to a foreign exchange need generated from the transactions recorded in the computer system. This task list can be generated by a single action, e.g. a button click in the customer user interface described above, or from an automatic process that periodically causes transmission of tasks.
• ERP enterprise resource planning
• a user interface supporting tasks presentation can be used to allow customers trading on behalf of the company to bid out the foreign exchange needs for competitive execution through a multi-bid process.
• the information about all executed transactions — including settlement information — can be provided to another computer system, e.g. back into the ERP system or into a foreign exchange settlement system.
• the process may include the aggregation of foreign exchange needs across multiple entities within the company while preserving cost allocation for execution. This tends to increase the total value of each foreign exchange transaction because it will correspond to several smaller transactions; and that in turn leads to more competitive price quotes. Further, because cost allocation information can be preserved, the aggregation can occur across distinct entities within the company.
• the flow of settlement information through the process also simplifies the workflow. That is because, after execution of the transaction, the customer's counter party can be sent the settlement information associated with a task and receive the counter party's settlement information. Thus, any settlement module processing the executed transaction will have all of the information needed to settle the transaction without the need for external matching of information between the customer's settlement system and the dealer's settlement system.
• Fig. 1 illustrates a multi-bid workflow automation environment and the flow of work according to one embodiment of the invention.
• Fig. 2 is a process flow diagram for the flow of work according to one embodiment of the invention.
• Fig. 3 shows the functional components of the foreign exchange execution module according to one embodiment of the invention.
• Fig. 4 illustrates a user interface provided to customers according to one embodiment of the invention.
• Fig. 5 is a process flow diagram illustrating the multi-bid execution process used by embodiments of the invention.
• Fig. 6 illustrates a user interface provided to dealers according to one embodiment of the invention.
• a system for multi-bid foreign exchange workflow automation is described. The description is organized as follows. An overview of the foreign-exchange workflow is provided together with a discussion of the component processes.
• Figure 1 illustrates the multi-bid workflow automation environment and the flow of work.
• Figure 2 is a process flow diagram for the flow of work.
• the environment and workflow described can significantly lower the costs associated with satisfying foreign exchange needs for a company.
• the starting point is a management 100 that may include one or more logical entities, e.g. entity 102 and entity 104.
• the management 100 may represent a corporation, an individual, and/or some other type of management structure.
• the entities within the management, e.g. entity 102 and entity 104, may be divisions, accounts, departments, clients, and/or some other component on behalf of which the management 100 is acting.
• the management 100 represents InvestCo, a hypothetical mutual fund company, the entities may correspond to distinct funds managed by InvestCo. Similarly, if the management 100 represents WidgetCo, a hypothetical company with international operations, the entities may correspond to divisions within the company.
• the management 100 executes one or more transactions on behalf of the entities 102-104.
• the transactions for the entity 102 are shown as transactions 106A-C.
• the transactions for the entity 104 are shown as transactions 106D- E.
• the transactions 106A-E represent transactions made for the respective entities in a given time period, e.g. today, this morning, yesterday, etc. Examples of transactions include purchases and sales of assets, purchases and sales of equity instruments, expenses due, payments received, and/or other types of non-foreign exchange transactions.
• the transaction 106A may represent a sale of a Japanese stock.
• the transaction 106D may represent a lease payment.
• step 202 the foreign exchange needs are ascertained and aggregated — or netted out — additionally, settlement instructions can be associated with the foreign exchange needs. This is shown by the arrows 107 in Figure 1.
• the process of step 202 leads to the identification of foreign exchange needs 108A-C. The automation of this process simplifies the identification of needs and can significantly reduce trading costs by allowing aggregation of needs across multiple entities.
• step 202 can be repeated hierarchically to aggregate needs across the entities. This can also ensure proper allocation of trading costs across entities.
• Table 1 shows example transactions that might correspond to the transactions 106A-E.
• Table 2 shows the foreign exchange needs for each entity as generated according to the process of step 202.
• step 202 aggregation can be performed across entities to net out the transactions in
• the costs can be allocated among entities as appropriate to meet the fiduciary duties of those entities.
• One approach is to look at the magnitude of each entities contribution relative to the sum of the magnitudes. For example, if entity A had to BUY 1,000,000 EUR and entity B had to SELL 500,000 EUR, even though the net transaction amount is BUY 500,000 EUR, the cost allocation could be 2/3 entity A and 1/3 entity B.
• the settlement information can be taken from lookup tables and/or databases established by the management 100 with information on a per entity basis if needed.
• the settlement information can be extracted from a settlement module (e.g. the settlement module 116) which is used by the management to handle settlement of foreign exchange transactions.
• a settlement module e.g. the settlement module 116 which is used by the management to handle settlement of foreign exchange transactions.
• a single click can cause the foreign exchange needs, together with any associated settlement information and/or cost allocation information, to be transferred to the foreign exchange execution module 112 as tasks.
• the tasks together with settlement information and cost allocation information are transmitted in an extensible markup language (XML), a comma separated value (CSV) format, a database format, a remote invocation, and/or some other format.
• the transmission may occur over a network, e.g. using a hypertext transfer protocol (HTTP) with, or without, transport layer security (TLS) protocol — formerly known as secure sockets layer (SSL) protocol — to the foreign exchange execution module.
• HTTP hypertext transfer protocol
• TLS transport layer security
• SSL secure sockets layer
• the information may be transmitted via file transfer protocol (FTP), electronic mail, and/or some other format.
• FTP file transfer protocol
• electronic mail and/or some other format.
• the single click is initiated on one or more computer systems at the management 100, e.g. to "push” to foreign exchange module 112. In some embodiments, the single click is initiated from within the foreign exchange module, e.g. from a user interface to "pull" from the management 100. In some embodiments, the step 202 and the step 204 can both occur in response to the single click.
• the exports could also be automated by configuring one or more computer systems at the management 100 to cause the generation of foreign exchange needs (e.g. the foreign exchange needs 108C) via step 202 and the export via step 204 on an automated basis, e.g. hourly, at the end of trading, daily, once a week, etc.
• the timing can be selected based on the business needs of the management 100. Factors the management 100 can consider include, for example, the level of currency risk the management 100 wishes to take versus the advantage to the management 100 of lower costs through netting out transactions for execution at lower cost.
• the module handles task presentation 120 and multi-bid execution 122.
• a task is complete, e.g. the foreign exchange transaction has been executed to meet a particular foreign exchange need, there is a visual indication of task completion at step 208; see below for more details.
• the foreign exchange execution module 112 presents a graphical user interface (GUI) on a computer system to a person working on behalf of the management 100 to execute tasks, e.g. a customer.
• GUI graphical user interface
• dealers e.g. persons operating on behalf of banks, may have a GUI to allow bidding for requests from the foreign exchange execution module 112.
• the foreign exchange execution module 112 can operate both for customers and dealers.
• the foreign exchange execution module 112 After a single click is received in the foreign exchange execution module 112, the executed transaction information for completed tasks is transmitted to the settlement module 116. This is shown by the arrow 114 in Figure 1.
• the foreign exchange execution module is programmed to automatically transmit information about completed tasks to the settlement module. The specific configuration will depend on the business needs of the management 100.
• the information is transmitted using a format similar to those used at step 204.
• the information now includes information received when the transaction was executed.
• the information could include the other party's settlement information, the agreed upon price, comments from the trader, performance evaluation of the execution by the trader relative to the offered prices, and/or other relevant information for completed foreign exchange transactions.
• the relative performance information can provide the management 100 a valuable tool to measure the quality with which their agents are executing foreign exchange transactions using the foreign exchange execution module 112. For example, if the bids received for a transaction were (1) EUR 1.0500 / USD 1.00 and (2) EUR 1.0490
• the cost of the user's selection versus the lowest cost option could be shown, e.g. USD 1,000.
• the relative performance information may be aggregated to include overall performance for the user over a given time period.
• other computer programs and computer systems can be used to assess overall performance using the relative performance information transmitted from the foreign exchange execution module 112. Examples of other metrics that may be available include quotes from third party price feeds and other quotes being offered in the system for similar transactions.
• embodiments of the invention may be designed to distribute tasks across multiple users acting on behalf of the management 100.
• the management 100 will have multiple agents acting on their behalf, possibly simultaneously, via access to the foreign exchange execution module 112.
• the tasks can be distributed across the various agents for the management 100. The distribution can occur either based on one or more rules implemented in the computer systems of the management 100, or based one or more rules established by the management 100 in the foreign exchange execution module 112.
• the settlement module 116 can be provided by companies other than the provider of the foreign exchange execution module 112.
• the settlement module may be a portion of existing back office systems available at the management 100. Examples of software products that could be used as the settlement module 116 might include Swift and DTC. Once the settlement module 116 completes processing, update information can be sent back to the management 100 as shown by arrow 118.
• the foreign exchange execution module 112 can provide a graphical user interface (GUI) to allow users to interact with the system.
• GUI graphical user interface
• customers e.g. traders acting on behalf of the management 100 according to the scheme shown in Figure 1
• dealers e.g. traders acting on behalf of banks or other institutions bidding to meet customer foreign exchange needs.
• users can act both as customers and dealers. This can allow for inter-corporate or inter-dealer trading.
• the system architecture for foreign exchange execution module will be considered.
• the customer user interface will be considered.
• the multi-bid process will then be considered.
• the dealer user interface will be considered.
• FIG 3 shows the functional components of the foreign exchange execution module according to one embodiment of the invention. This could be used to provide the foreign exchange execution module 112 and implement the features described below.
• Figure 3 includes a display logic 300, a client network logic 302, a network 304, a server network logic 306, a presentation logic 308, a business logic 310, and a database 312.
• the display logic 300 is coupled to the client network logic 302.
• the network 304 is coupled in communication with the client network logic 302 and the server network logic 304.
• the server network logic 306, the presentation logic 308, the business logic 310, and the database 312 are coupled one to another in the order listed.
• the foreign exchange execution module is designed according to the client-server model in the configuration shown. Different embodiments of the invention may include different distributions of components between the client side and the server side.
• the client side includes the display logic 300 together with the client network logic 302.
• the display logic can be implemented with a mixture of extensible markup language (XML); Java(TM) applets; Javascript(TM); as a client- side application, e.g. native Windows(TM) programs; using static or dynamically linked libraries; and/or as a combination of the above approaches.
• XML extensible markup language
• Java(TM) applets Javascript(TM)
• client- side application e.g. native Windows(TM) programs
• static or dynamically linked libraries e.g. native Windows(TM) programs
• static or dynamically linked libraries e.g. native Windows(TM) programs
• static or dynamically linked libraries e.g. native Windows(TM) programs
• static or dynamically linked libraries e.g. native Windows(TM) programs
• static or dynamically linked libraries e.g. native Windows(TM) programs
• static or dynamically linked libraries e.g. native Windows(TM) programs
• static or dynamically linked libraries
• the client network logic 302 can be implemented in a similar fashion to the display logic 300.
• the client network logic 302 provides communication access between the client-side and the server-side over the network 304.
• the client network logic 302 and the display logic 300 are implemented in a single program, applet, library, and/or other implementation.
• the client network logic 302 may support a Transport Layer Security (TLS) protocol (formerly known as the Secure Sockets Layer (SSL) protocol) for secure, authenticated communications across the network 304 using an application protocol such as hypertext transfer protocol (HTTP), other well-known protocols, and/or a proprietary application protocol.
• TLS Transport Layer Security
• SSL Secure Sockets Layer
• the display logic 300 can be implemented using one or more Java(TM) applets.
• the remote method invocation (RMI) might be used across a TLS protocol link for communication.
• the network 304 may be a public network such as the Internet; a guaranteed quality of service (QoS) network, e.g. a private packet switched network; a virtual private network implemented on a public network; a wireless network, and/or some other type of data network. Additionally, the network 304 may connect to load balancing devices to allow the elements 306-312 to be distributed across multiple computer systems.
• QoS quality of service
• Some of the network and security issues relating to the foreign exchange execution module 112 are described in greater detail in the section "Network and Back End Environment," below.
• the server network logic 306 provides the counterpart to the client network logic 302 and should support protocols used by the client network logic 302, including the TLS protocol when used to secure the communication channel.
• the server network logic 306 provides the counterpart to the client network logic 302 and should support protocols used by the client network logic 302, including the TLS protocol when used to secure the communication channel.
• 306 may be implemented as one or more programs.
• the presentation logic 308 and the business logic 310 are separate components for design purposes.
• the presentation logic 308 controls the presentation of information to customers and dealers accessing the foreign exchange execution module through the display logic 300.
• the business logic 310 enforces the business rules for the system, e.g. the system behavior, the multi-bid execution process, the handling of requests, etc.
• the two components allow for a clean distinction between the business rules implemented in the business logic 310 that is separate from design choices for presenting that information in the presentation logic 308.
• the two components may be combined in some embodiments of the invention.
• the presentation logic 308 and the business logic 310 may be implemented as one or more programs.
• the database 312 can provide persistent storage for the presentation logic 308, the business logic 310, and, if appropriate, the display logic 300. Additionally, in some embodiments of the invention, transaction boundaries where atomicity of access to the database 312 should be enforced are kept in stored programs — also called procedures in database terminology — in the database 312. Some embodiments of the invention use databases from Oracle Corporation, of Redwood City, California, to provide the database 312. Some of the business rules that may be enforced by the business logic 310 include rules limiting distribution of requests according to credit availability between trading parties, rules to enforce time limits associated with the multi-bid process, rules limiting distribution of requests to appropriate counter-parties based on the currency involved, and/or additional rules. Different business rules enforced by the system will be discussed throughout the remainder of the document.
• Figure 4 illustrates a user interface provided to customers, e.g. traders acting on behalf of the management 100, according to one embodiment of the invention. This interface allows for rapid multi-bid execution to satisfy foreign exchange needs as part of a foreign exchange workflow.
• the graphical user interface can be provided by the display logic 300 in conjunction with the presentation logic 308 and the business logic 310.
• the interface is shown in Figure 4.
• the display 400 may comprise a physical display or a region on a physical display such as a window.
• the display 400 is shown with various interface components. There are four main components according to some embodiments of the invention: the tasks list 402, the task detail 404, the request choices 406, and the bids 408. Each could be displayed as separate windows or as part of a larger single window. In some embodiments, the position of the user interface elements can be changed and, where appropriate, saved for use in later sessions.
• Several other interface components may be present on the display 400; these include menus; button bars; pricing information, e.g.
• a button in a button bar to produce a report showing executed trades and confirmation information.
• Another button might cause the one-click transmission of transaction information of step 212.
• the usage flow is from task presentation 120 to multi-bid execution 122 for each task.
• Tasks can be selected one at a time from the task list 402, e.g. the task 410 could be selected.
• the task 410 is then displayed in greater detail in the task detail 404.
• Embodiments of the invention can use coloring, shading, and/or icons to distinguish task status, e.g. executed, important, handle tomorrow, etc. See “Tasks List Details," below, for more detail.
• One or more options may be available in the GUI to further customize the tasks list 402, e.g. what is shown in the list view.
• the system default setting may be to list the currency and the type of transaction in the list, e.g. EUR BUY, JPY SELL, etc.
• the customer may further refine the display to include additional information.
• the task detail 404 can appear in the tasks list 402 when the user clicks an expand, or a disclosure, icon next to a task summary.
• a disclosure triangle icon could be used to allow a user to scan details in place instead of using a separate region such as the task detail 404.
• the customer may make decisions about whether or not she/he wants to complete the task at the present time. For example, the customer may be aware of a trend in the Euro that would make it advisable to wait until after a crucial announcement before making a trade. In that case, the customer can simply select another task from the list. Similarly, the customer may wish to restructure the task into multiple foreign exchange transactions to hedge currency risk.
• the customer uses the request choices 406 component to specify her/his request.
• the foreign exchange execution module 112 can pre-fill options into the request choices 406 based on the task. For example, a task to BUY JPY 10,000,000, spot, could be pre-entered into the request choices 406 in suitable user interface elements. The customer could then modify those values as needed.
• the customer might place the request as a two-way bid request so that bidding dealers would not know whether the customer was a buyer or seller of, in this example, Yen, but would have to give the customer two price quotes, one for buying and one for selling Yen.
• the multi-bid process as implemented by embodiments of the invention is described in greater detail below.
• the bids 408 component can display received bids in a table, scrolling list, or other formatted visual indication.
• the bids 408 shows two bids, the bid 414 and the bid 416.
• the source of the bids, the exchange rate, a dollar amount cost comparison to the best bid, and an accept button are shown for each bid.
• the source may be omitted, e.g. if counter party information is being kept confidential until after transaction acceptance.
• the best rate quote is presented at the top of the list and a short-cut key, e.g.
• each bid is assigned a letter or number that is shown in the screen next to the bid. To select a bid, the customer can press the corresponding letter or number.
• the display of a dollar amount cost compared to the best bid is useful for allowing customers performing trades to quickly evaluate the difference between rate quotes. For example, rate quotes of 1.4004 and 1.4005 for buying EUR 1,000,000, spot, are very similar. However, it is virtually impossible for a human to compute the dollar difference for taking the slightly higher quote in just a few seconds. Accordingly, embodiments of the invention could show that the 1.4005 rate would cost USD 1 ,000 extra, etc.
• some embodiments of the invention make use of colors, or shading, to identify bids in different tiers relative to the best rate. For example, darker colors could be used for bids with rates that are more than N%, either in the quote or the dollar difference, from the best rate. The exact percentage could be set by the customer, the management 100, and/or through system default rules. For example, the management 100 might configure the system to color bids 10-20% out yellow and 20%+- out red. This would help management 100 direct its trading employees, e.g. the customer, to select better bids. Some embodiments of the invention display a timer 418 to allow the customer to be shown how much time remains to accept a bid.
• Some embodiments of the invention allow the customer to change the sort order, e.g. sort by preferred source list. Additionally, if more complicated rates are being presented in a single bids 408 component, the sort order options may allow the user to quickly sort to the top the most favorable rate quotes for each category of rates presented. In some embodiments, if coloring, or shading, is used, each quote is separately colored, or shaded, according to the rules.
• More complicated bids can also be presented using multiple bids 408 components. For example, in a two-way bid request, where the user wants both buying and selling prices, two bids 408 components could be shown on the display 400.
• the tasks list 402 status for a task e.g. the task 410
• the tasks list 402 status for a task can be updated to reflect execution. This is desirable for ensuring that the tasks list 402 shows the most relevant information to the customer in an easily accessible form. Accordingly, one or more of the use of colors, shading, icons, sorting and/or filtering of the display of the tasks list 402 can be used to reduce clutter and improve workflow.
• executed tasks are shaded a different color from non-executed tasks, e.g. gray.
• the task 410 upon execution, the task 410 would be shaded gray.
• additional shading colors are used to indicate whether or not counter party settlement information has been received, e.g. light gray for executed but awaiting settlement information and gray for executed and settlement information received.
• Still more shading variations can be used for different status conditions as well as different shades, e.g. customer selected colors. Colors and icons can be used to provide a similar effect to shading in some embodiments of the invention.
• automatic sorting or filtering of the tasks list 402 can occur.
• completed tasks are automatically sorted to the bottom of the tasks list 402. This keeps tasks that remain to be completed near the top. Thus, after the task 410 is executed, it would sort to the bottom of the list, and the task 412 would be at the top.
• the task 410 would no longer appear in the tasks list 402 unless the customer selected controls in the user interface to see all tasks, e.g. in a menu option or button control.
• Some embodiments of the invention use combinations of these approaches, e.g. shading and sorting. This allows the customer to quickly scroll the list and easily see completed tasks; however, at the same time the tasks at the top of the list will be those most important to the customer — the non-executed tasks.
• the task information imported into the foreign exchange execution module 112 may include status information, e.g. important, execute tomorrow, etc.
• the specific status information can also be derived from one or more system, customer, and/or management, defined rules in the business logic 310.
• embodiments of the invention may support rules to associate an icon with forward tasks and to sort them to below spot tasks.
• the rules can be adjusted by the management 100, and/or its customers. This allows the system to be flexibly programmed to meet business needs and stylistic preferences of individual companies and traders.
• the participants are the customer 502, the transaction center 504, and one or more dealers, represented by a single dealer 506.
• the participants communicate across the network 304, shown with dashed and dotted lines.
• the process starts after a customer completes her/his request in the request choices 406 component. She/he can click on a button, or other user interface element, to submit the request for bids at step 508.
• the server side components of the foreign exchange execution module 112 reside.
• the transaction center 504 may be distributed geographically across the globe among many computer systems.
• the transaction center 504 provides the elements 306-312 of Figure 3, e.g. the server side elements of the foreign exchange execution module 112, either entirely or across multiple, geographically distributed computer systems.
• the request from the customer is distributed to all currently active dealers with whom an appropriate relationship exists. See the section "Third Party Surety,” below, for more detail on appropriate relationships.
• the business rules are designed to ensure that the dealers that will receive quotes at step 512 meet one or more of the following requirements: (1) online and ready to trade, (2) trading in bid currency; (3) credit relationship with customer; (4) latency and QoS guarantees being met; and/or (5) follow supplied rules for customer and dealer, e.g. dealer is limited to USD Z in trades per day, etc.
• the request is sent to all of the appropriate dealers and an X second limit begins to countdown.
• the X second limit defaults to thirty seconds in some embodiments of the invention. In other embodiments of the invention, longer periods of time are provided when dealers are asked to give more complicated quotes, e.g. packaged deals, different time horizons, etc.; see below for more details.
• the bids are returned, e.g. the dealer 506 returns her/his bid at step
• the transaction center 504 enforces the X second limit by aggregating only bids received in the time window at step 514 from all dealers. Where appropriate, a small latency tolerance may be added to the limit by the transaction center 504 to account for the current characteristics of the network; see below for more details.
• the X second limit and the tolerance can be implemented using one or more business rules in the business logic 310. For example, one embodiment might use a thirty second limit with a maximum 250 ms latency tolerance. Also, see below for further discussion of timing related issues on the network.
• the customer 502 is given a Y second limit to select a bid. If she/he does not select a bid in that time period, she he would have to re-bid the transaction at step 508 to obtain the needed foreign exchange. Additionally, from the time when a dealer, e.g. the dealer 506, places a bid at step 512, up until the user selects a bid, at step 522, a dealer may pull her/his bid, e.g. step 518. If the pull request is made before the customer selects the bid, the pull will be effective and will also be transmitted to the customer 502 at step
• the Y second time limit defaults to five seconds. The amount may be adjusted up, or down, for more complex transactions.
• step 522 when the customer 502 selects a bid, the banks are informed at step 522.
• the bank may be requested to acknowledge completed trades, at step
• a confirmation can be sent by the transaction center 504 with counter-party settlement information at step 528.
• the X second and Y second time limits serve several purposes for both dealers and customers. They limit exchange risk for dealers, e.g. the dealer 506, because as noted, quotes may change as often as twenty times a minute. Thus, it is important dealers not commit to a price for an extended period. However, this has a beneficial effect for customers, e.g. the customer 502, as the dealers know the quote will have an extremely limited life and can make their best offer.
• the time limits also ensure fairness. Because all dealer offers are aggregated and presented to the user en masse, the customer, e.g. the customer 502, gets the full benefit of the multi-bid system and can evaluate all of the offers they receive. Also, dealers cannot gain an advantage based on their computer systems, e.g. better/closer network connection, over other dealers.
• the specific time limits, and latency tolerances can be adjusted. For example, if the thirty second default for the X second time period is considered too long a time to have offers outstanding, the amount can be scaled back. Similarly, some embodiments of the invention allow customers and dealers to enter certain more complicated trades, or request more complicated bids. The X second limit and the Y second limit can be adjusted in response to these trades. Lastly, on the latency front: Unlike dedicated connections, where the issue is one of physical connectivity, in packet-switched networks, there may always be some latency. The system can be adjusted to accommodate different latency characteristics. In some embodiments of the invention, the transaction center 504 is managed by an entity that contracts to provide at least portions of the carriage for the network 304. The entity controlling the transaction center 504 can adjust latency tolerances in accordance with the characteristics of the network 304 at any given time.
• real time monitoring of packets reaching the transaction center 504 is used to measure the quality of service (QoS) and adjust latency tolerances up, or down, in accordance with the network's real time performance.
• the adjustments are limited by a predetermined limit — a maximum latency budget — of for example, 250 ms.
• Table 3 sets forth the time limits used by some embodiments of the invention for various purposes.
• the table is broken down along categories of currency with major currencies having generally shorter time limits than secondary and exotic currencies, e.g. less common currencies. Numbers in parenthesis indicate the default time according to some embodiments of the invention.
• Embodiments of the invention may allow additional time to allow for bidding and accepting more complex transactions as described below. Additionally, the exact timings can be adjusted due to market conditions and the ability of participants to respond, for example as dealers become more accustomed to the system, the basic X second limit for a major currency might even be dropped below five seconds.
• the identities of counter-parties to a transaction are concealed from the parties until a trade is accepted.
• only customer identities are kept confidential, while dealer identities are provided with the bids sent to customers.
• a customer or dealer — can select whether to reveal her/his identity.
• MegaBank might elect to reveal its identity despite the fact that counter-party information might normally be kept secret. This may be desirable for MegaBank if they believe it will improve the odds of their bid being selected. Similarly, a company could reveal its identity, again hoping that it may cause the dealers to quote better prices.
• settlement information can be held until after a trade is completed.
• the selection of a bid at step 522 includes transmission of the customer's settlement information for the trade.
• the dealer's acknowledgment of the trade at step 526 can include dealer settlement information for the trade.
• the transaction center 504 generates one or more error messages if a dealer, e.g. the dealer 506, does not provide settlement information by a predetermined period, e.g. 1700 hours local time, four hours after a trade, etc. Similar errors can be generated for customers, e.g. the customer 522, if they did not provide sufficient settlement information.
• the errors may cause electronic mail, facsimiles, pager notifications, telephone calls, and/or some other contact to be placed or sent to the respective dealer or customer for failing to provide settlement instructions.
• an additional service fee may be assessed for failure to provide settlement instructions in a timely fashion, and/or for contacting the dealer, or customer.
• the settlement information received from the counter-party can be paired with the task information and sent out as part of the one-click transaction reporting process of step 114.
• the task is automatically held until the settlement information is available. It can then be transmitted immediately upon receipt without further user intervention, or with the next requested transmission of completed transaction information.
• the user interface from the dealer perspective will be considered.
• Figure 6 illustrates a user interface provided to dealers, e.g. traders acting on behalf of banks or other institutions bidding to meet customer foreign exchange needs, according to one embodiment of the invention. This interface allows for rapid multi-bid execution.
• the graphical user interface can be provided by the display logic 300 in conjunction with the presentation logic 308 and the business logic 310.
• the interface is shown in Figure 6 with the display 600, e.g. a physical display or a region on a physical display such as a window, occupied with various interface components.
• the display 600 e.g. a physical display or a region on a physical display such as a window, occupied with various interface components.
• Each place bid area e.g. the place bid areas 602A-B
• the position of the user interface elements can be changed and, where appropriate, saved for use in later sessions.
• Several other interface components may be present on the display 600; these include menus; button bars; pricing information, e.g.
• the dealer might select a button in a button bar to produce a report showing executed trades and confirmation information.
• Another button might allow the dealer to download trade and settlement information to her/his back office systems.
• the basic interface provided affords several place bids components allowing a dealer to respond to multiple bid requests simultaneously.
• the number of place bid components is limited by the display space available, the capacity of the dealer to handle multiple requests, as well as the policies of the dealer's management, e.g. the bank.
• Each place bid area e.g. the place bid area 602A, affords a timer, e.g. the timer
• the dealer's most recent quote for a currency is shown together with the aging history of that quote, e.g. "Your previous quote: 1.4005 (60 seconds ago)".
• the bid entry area is pre-filled with the most recent quote. In other embodiments, shown in Figure 6, the bid entry area is pre-filled with all but the last digit of the previous quote.
• some embodiments of the invention pre-enter the handle, but leave the big figure and little figure for the dealer to enter.
• Others include the handle and big figure, but leave the little figure for the dealer to enter.
• Still other systems support the use of graphical and/or keyboard approaches to adjusting the quote quickly.
• the "+" and "-" keys as well as up and down arrow buttons on the screen could be used to easily adjust the little figure up or down by a pip.
• Other controls might cause the big figure to move, e.g. shift key plus +/- or a mouse click on the arrow buttons.
• Still others might cause half-pip movements, e.g. option key plus +/- or a mouse click on the arrow buttons.
• the particular interface for quote entry is thus highly customizable to the needs of a particular dealer and/or her his business.
• the capability for half-pip movement might only be enabled at businesses that provide quotes on the half-pip.
• a submit button e.g. the submit button 606, is provided to allow the user to submit a quote.
• the quote is automatically submitted.
• the timer 604A shows a countdown of the time remaining to submit a bid. Additional user interface features may allow dealers to selectively reveal, or conceal, their identities on a per quote basis.
• dealers may desire to wait until close to the end of the period afforded before placing and submitting their bid.
• the dealer may enter her/his quote at the start of the time period, but delay submission until, for example, two seconds remain. This allows the dealer to further minimize their exchange risks.
• business rules may be defined to inform the dealer 506 when a quote she/he is entering deviates more than a predetermined amount from the most recent quote she/he entered.
• the amount can either be defined in absolute terms, e.g. ⁇ 0.0010, or in percentage terms, e.g. ⁇ 3%.
• the display After submitting a bid, the display might look like the bottom half of Figure 6 as shown in the place bid 602B component where a placed bid is shown together with a button 608 to allow the dealer to pull her/his bid; a keyboard shortcut may also be provided.
• the timer 604B can display the amount of time the customer has remaining to accept the bid. If the customer accepts the bid, the display can change again to reflect that and request confirmation — and settlement information, if not already provided.
• a keyboard shortcut is assigned to each of the place bid components, e.g. A, B, C, etc. Pressing that keyboard shortcut shifts the cursor focus to the corresponding enter bid area;
• the system can place new requests for bids in open place bid components, e.g. ones not currently occupied by other requests/offers.
• a signal is provided if there are insufficient open place bid components.
• a new place bid component is opened so as not to overlap the others on the display 600.
• the dealer can dynamically select the currencies she/he is currently trading in from a pull down menu or dialog activated on the display 600. In some embodiments, the dealer can generate a variety of reports for her/his management, e.g. the bank.
• the place bids components and the customer components of Figure 4 can be displayed simultaneously to support customers to act as dealers and vice versa.
• a large multinational company might wish to allow its customers serve as dealer to meet its foreign exchange needs.
• the customer could define filters to further limit which bids are presented to it, e.g. according to the tasks on the customer's tasks list 402.
• embodiments of the invention can support customers acting as dealers and vice versa, e.g. for inter-corporate trading. Accordingly, when appropriate, a single display, e.g. the display 400, might include a place bid area, e.g. the place bid area 602A.
• Some embodiments of the invention are designed to interoperate with public packet-switched networks, e.g. the Internet.
• public packet-switched networks e.g. the Internet.
• time sensitivity of the information, as well as security concerns, should be accounted for.
• a secure transport protocol such as TLS version 1.0, can be used for communications across the network.
• the TLS protocol was formerly known as secure sockets layer (SSL) protocol.
• SSL secure sockets layer
• the TLS protocol is further defined by the Internet Engineering Task Force, Request For Comment number 2246, January 1999.
• the TLS protocol is limited to providing encryption (privacy), party identification
• a user password can be used to authenticate users within the foreign exchange execution module 112, e.g. at the application layer.
• users have a password and a Secure ⁇ D(TM) card.
• TM Secure ⁇ D(TM) card
• Embodiments of the invention may make use of specific network configurations and topologies to reduce the effects of latency.
• embodiments of the invention may position equipment in areas with major use to allow traffic to be quickly routed to guaranteed QoS network connections, e.g. by establishing points of presence. For example, there might be points of presence in New York, Tokyo, Hong Kong, Singapore, London, Frankfurt, and San Francisco with guaranteed QoS connections to one another and/or the transaction center.
• This configuration provides reduced costs, e.g. no need for end-to-end QoS connection and increases the range of equipment usable for client terminals, e.g. wireless computers, dial-up connections, public Internet kiosks, is increased.
• Hot potato, or cold potato, routing approaches can be used to cause the data to leave the "public" segments of the Internet for the points of presence as rapidly as possible.
• Hot potato routing also known as closest exit routing
• Cold potato routing also known as furthest exit routing
• Both approaches may be desirable depending on whether or not traffic is symmetrically routed.
• this approach has applicability outside the Internet, but more generally for any type of packet-switched network over which embodiments of the invention may operate. This is because this approach helps minimize the high cost associated with having a large number of guaranteed QoS links.
• a private — or virtual private — acket-switched network without guaranteed QoS could be used in conjunction with a relatively small number of QoS links between selected points of presence.
• the time-sensitive nature of the data makes it desirable to measure latency — and the variance in the latencies — to ensure that customers and dealers are receiving information in a timely fashion.
• the foreign exchange execution module 112 can then respond to the detected latencies by one or more of:
• Latency can be measured both at the application layer, e.g. Open Systems Interconnect (OSI) layer 7, and at lower layers, e.g. OSI layers 1-6.
• OSI Open Systems Interconnect
• some embodiments of the invention may make use of timestamps appended by network devices that support the Internet Protocol (IP) timestamp option to measure latency, and its variance.
• IP Internet Protocol
• some embodiments may implement packet re-routing at the application layer, e.g. OSI layer 7, e.g. with the business logic 310 instructing network devices to re-route packets if it is determined that the QoS terms are not being met.
• the re-routing can be done from application layer on the sever to the application layer on the customer or dealer computer, e.g.
• Latency variance is also important because if the latency is 150 ms, but the variance is 100 ms, e.g. some packets are taking as much as 250 ms, that may exceed the latency tolerances — or the maximum latency — allowed. Accordingly, it may be appropriate to handle the situation as described above for high latency connections.
• embodiments of the invention may support application level load balancing, e.g. OSI layer 7. Unlike most load balancing approaches currently available which operate at lower layers, e.g. OSI layers 1-6, this approach involves analyzing load within the application and then sending one or more messages to network devices to reroute the traffic for load balance.
• OSI layer 7 Unlike most load balancing approaches currently available which operate at lower layers, e.g. OSI layers 1-6, this approach involves analyzing load within the application and then sending one or more messages to network devices to reroute the traffic for load balance.
• embodiments of the invention primarily use application level, e.g. OSI layer 7, criteria to balance traffic.
• application level e.g. OSI layer 7, criteria to balance traffic.
• the application level is directing network traffic, e.g. to avoid latency and to ensure processing resource availability. This approach may, when appropriate, be synergistically combined with products such as the Global Director.
• transport layer security e.g. via the TLS protocol
• network configurations that are responsive of the time-sensitive nature of the data can be used to implement embodiments of the invention over a variety of packet-switched networks at low cost, while ensuring high reliability and strong security.
• CreditCardCo the fictional credit card company
• CreditCardCo has the process 202 performed for transactions in its transaction processing system according to the business rules for when foreign exchange is needed. This results in the automatic identification of foreign exchange needs from credit card holders' transactions. This information is automatically aggregated for CreditCardCo, and is transmitted automatically to the foreign exchange execution module 112 at 0855 EST each morning for use by CreditCardCo 's traders.
• CreditCardCo can have rules established to divide the trading among its traders, e.g. by currency. There is no need for an employee to record quotes received over the phone to provide comparisons. Instead, each trader acting for CreditCardCo sees her/his tasks list when she/he start trading in the morning. The traders can then complete the tasks with competitive execution through the multi-bid execution process.
• CreditCardCo can get more bids — and, hopefully, more competitive rates — for each foreign exchange transaction. That is because each trader's request will reach suitable counter-parties, e.g. from among the banks CreditCardCo convinced to sign up as dealers. For example, CreditCardCo may have convinced twenty-three of its banks to use the system as dealers.
• Traders press a single button on their user interface to transmit settlement information when they end their trading day. This causes the settlement information for counter-parties, as well as transaction details, to be transmitted from the foreign exchange execution module 112 to CreditCardCo 's settlement systems. Additionally, the foreign exchange execution module 112 provides reports to the traders' managers to allow them to assess whether the traders are selecting competitive bids.
• embodiments of the invention can be integrated with enterprise resource planning (ERP) systems for integration with transaction information and other enterprise.
• ERP enterprise resource planning
• Companies find a significantly more level playing field, e.g. in terms of access to competitive rates. Similarly, banks find that they have greater access to company's full transaction load.
• the implementation in a client- server architecture across packet-switched networks increases the level of access while permitting broad integration with other company systems.
• the availability of quality metrics may also make it viable for companies with relatively small foreign exchange needs to farm out the execution to a third party to act as the customer on their behalf. For example, now a third party executing trades for the management 100 can be evaluated quantitatively by the management. Also, in some embodiments, the foreign exchange execution module 112 will aggregate foreign exchange needs from multiple companies.
• each bid can have an associated time to live (TTL) that may be independent of the basic Y second limit for the customer to respond to bids.
• TTL time to live
• the dealer may have options to set a TTL in seconds for each quote and enter multiple quotes via the dealer user interface. For example, the dealer could bid 0.9905 with a TTL of 3 seconds and 0.9910 with a TTL of 10 seconds.
• both quotes could be presented to the customer and sorted separately. As appropriate quotes could become greyed out, or removed from the customer's list, as their TTL expires.
• Figure 5 can be extended to allow dealers to pull individual quotes (e.g. I want to pull my 10 second quote). Suitable adaptations can be made to the user interface of Figure 6 to support a selective pull functionality as well as entry of multiple quotes .
• some embodiments of the invention support third party surety.
• This third party may be a selected outsider, e.g. a Lloyd's of London, an insurer, etc., who acts as a third party credit guarantor, or may be another system participant, e.g. a web of trust model. Customer participants and dealer participants can then gain greater access by forming credit relationships with appropriate third parties.
• third party surety When third party surety is used in connection with the foreign exchange execution module 112, customer bids will be presented to dealers according to both the customer to dealer credit relations and third party surety credit relations. Additionally, an appropriate user interface can be provided to third parties providing surety to inform the foreign exchange execution module 112 of credit relationships, monitor credit available, and/or perform other tasks relating to providing surety services.
• the third party may receive a fee from the customer, the dealer, or both, for its role in the transaction. This can be automatically deducted by the foreign exchange execution module 112. Additionally, the third parties may charge other fees, e.g. credit line fees, require deposits, etc., to obtain their participation.
• an icon, or other visual indication may be used to notify the customer that a third party surety relationship was used to obtain the transaction. This may also serve as a signal to the customer that an additional transaction fee may apply.
• additional transaction fees from third parties can be included in cost differentials shown to the customer. Thus, two quotes for 1.4005 on a transaction may be different in the sense that one will cost an additional amount due to the use of one or more third party insurers.
• insurance reduces settlement risk and accordingly move the transaction model from a one-to-many based on credit relations to many-to-many based on participation in the market.
• Another variant form of multi-bid foreign exchange execution supported by embodiments of the invention is the packaged trade. This is useful if customers want to try to obtain a lower overall costs by bundling two or more foreign exchange needs, e.g. tasks, into a single request for bid.
• a customer could bundle four small transactions, e.g. whose USD equivalent value is approximately USD 1,000,000 each, into a single request. This may make it more desirable to dealers to place competitive bids so as to receive the overall deal flow, e.g. USD 4,000,000, whereas taken individually the quotes might have been less competitive.
• some embodiments of the invention allow a customer to select multiple tasks from the tasks list 402 for packaged execution.
• the task detail 404 component can show the information for the selected tasks.
• the request choices 406 component can allow further input before requesting bids. From the dealer side, the user interface will allow her/him to easily enter multiple quotes in the place bid 602 A component.
• the X second limit is extended beyond the system default for packaged trades, e.g. 40 seconds instead of a 30 second default.
• the packaged quote is shown as a series of line items with disclosure icons to allow expansion of the detailed quotes and costs of each transaction within the package.
• some embodiments of the invention extend the Y second limit beyond the system default, e.g. 10 seconds instead of a 5 second default.
• the specific pricing model used by the provider of the foreign exchange execution module 112 can vary greatly. For example, licensing fees for software and support may be assessed against customers and dealers. However, this approach may be sub-optimal for the provider, e.g. if the provider can make more money by giving away the needed client side software while charging for transaction execution.
• One embodiment of the invention charges usage fees to customers and dealers. For customers, these embodiments of the invention charge a modest usage fee relative to the size of the trade in millions of dollars. This is because the savings for larger trades, e.g. the spread between buy and sell quotes, tends to drop as volume increases in the foreign exchange market. (Note, however, that studies have observed a point of inflection where the spread goes back up at a certain point, e.g. for ultra-large transactions.) Therefore, assessing customers based on the trade size fairly charges them for the increased value they receive for larger transactions — smaller spreads. For example, some embodiments of the invention charge between USD 5 and USD 50 per million dollars involved in the transaction. In contrast, banks, e.g. dealers, are attempting to generate revenue.
• USD 5-100 per transaction For example, a flat fee of USD 20 for each executed trade could be assessed. Since this is a flat fee for execution services, it is not tied to the trade and will not discourage dealers from participating in larger transactions where they can make the most revenue. However, a variety of other pricing models may also be usable. For example, customers could be charged a flat fee plus a volume related commission. Similarly, dealers could be assessed a flat monthly cost on a per seat basis, e.g. USD 1,000 per month per seat, as opposed to per transaction charges to encourage dealer participation.
• Some embodiments of the invention may allow customers (e.g. the customer 502) to define one or more rules for automatically selecting from among received bids.
• the rules can be defined using a variety of approaches, e.g. expert system, small programmatic logic statements, visual programming, selection from system provided rules, and/or other approaches. This may simplify the execution process for customers by removing the need to make a decision in the Y second time limit provided by the multi-bid execution process of Figure 5.
• a simple rule that a-customer might define is: "Take the bid from MegaBank if its cost is within 3% of the best bid, otherwise take the lowest cost bid.” This rule defines a preference for using MegaBank over other banks, but only when MegaBank's quote is sufficiently low in cost as to be comparable to the lowest cost bid.
• the multi-bid execution process can also be viewed as a form of price discovery. This can be contrasted to the price discovery, or matching, of orders at the New York Stock Exchange, or other similar exchanges. However, it serves a similar purpose by allowing customers and dealers to match
• Some embodiments of the invention may allow customers to place limit orders. This may serve to filter incoming quotes and/or allow customers to automate foreign exchange execution.
• a customer Cl could review several tasks for the day and for one, e.g. BUY EUR 50,000, spot, select automatic execution with a limit price of 0.9950.
• the system could monitor various market data about the price, e.g. from public data feeds and/or quotes being given to other customers, and send out a bid for this foreign exchange need at a suitable time. Further, the system could automatically select the best bid under the limit price.
• embodiments of the invention could prompt the user to select bids when they are received — pre-filtering bids over the limit bid. In this configuration, the system could select the appropriate time to bid the task, and then present the resulting price quotes to the customer. This allows customers with a large number of tasks to devote their time to price sensitive transactions, while knowing that other tasks are being executed in accordance with their general instructions, e.g. a ceiling on rates.
• Appropriate colors, shading, and/or icons can be used in the tasks list 402 to signify tasks being handled in an automated, or semi-automated, fashion.
• a computer icon might be placed to the right of a task description to indicate it is being handled by the foreign exchange execution module 112.
• the task could be automatically removed from the tasks list 402, when completed; see above for more discussion of the tasks list user interface.
• limit orders and automated execution can support rules based bid selection.
• a customer could supply one or more rules to apply in selecting bids.
• rules based bid selection and limit orders have been described primarily from the customer perspective, similar approaches can be employed by dealers.
• embodiments of the invention might permit dealers to establish rules for transactions (e.g. "If total transaction size is less than USD 1,000,000, use most recent price quote if quote is less than 60 seconds old").
• dealers could request special treatment for certain conditions (e.g. "If customer is from my preferred customer list, flag with star icon").
• Such a rule would help give the dealer a better visual indication of when its preferred customers — from a list it has established — are requesting bids.
• Embodiments of the invention can be configured to interoperate with electronic commerce, or e-commerce, sites. Two embodiments of the invention incorporating this will be considered, a transaction service variant and a real-time pricing variant. The two may both be used simultaneously, if appropriate.
• Transaction Service Variant
• a site such as Business2Business.com, a fictional business to business transaction site, could, upon completion of a transaction between business Bl and business B2: (1) identify needed foreign exchange for a party, e.g. Bl
• this service is charged for separately by the provider from any service charges, fees, and commissions that are charged for using the foreign exchange execution module 112.
• Embodiments of the invention can allow Business2Business.com to automatically request price quotes in the correct currency and allow the two businesses to eliminate exchange risk.
• B2 reviews Bl 's proposal as stored at Business2Business.com, a request for bids can go out, and the price shown to B2 will be in Euros based on the best price quote received.
• Business B2 then has the capability to accept the offer at that exchange rate and limit its currency exposure.
• the Y second time limit typically used in the multi-bid execution process might be lengthened to allow B2 a slightly longer decision period. If desired, as quotes time out, new bids can be solicited.
• Some embodiments of the invention automatically identify the date when payment is expected, e.g. the date the foreign exchange is needed, so that the request for bids is sent out as an appropriate forward request. As appropriate, this identification can be assisted by the commerce vendor, e.g. Business2Business.com in this example.
• Some embodiments of the invention show both the foreign currency amount and the best bid, e.g. "USD 1,000,000 [Best Bid Now EUR 1,005,000]", etc. Some embodiments of the invention use automatically obtained quotes as described more fully below to provide pricing.
• the dealer can maintain a table using the dealer interface of quotes for various transactions together with spreads for different classes of customers, e.g. based on their credit worthiness with the dealer.
• the customer can still benefit from the multi-bid process because that quote may go up against quotes from live dealers or from dealers who have narrower adjustments and more frequently updated tables.
• Some embodiments of the invention do not indicate to customers whether or not a quote is from a "live" dealer or is an automated quote of some sort.
• Still more sophisticated automatic quoting mechanisms can be integrated, e.g. through the use of client side scripting, hosted pricing agents for dealers, and/or an application programmers' interface (API) for coupling a dealers' pricing agent with the system.
• API application programmers' interface

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Finance (AREA)
• Engineering & Computer Science (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Marketing (AREA)
• Strategic Management (AREA)
• Technology Law (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Detergent Compositions (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (1)

Family

ID=24163284

Family Applications (1)

Country Status (3)

Cited By (14)

Families Citing this family (2)

• 2001
  • 2001-02-26 AU AU2001241785A patent/AU2001241785A1/en not_active Abandoned
  • 2001-02-26 GB GB0224527A patent/GB2377303A/en not_active Withdrawn
  • 2001-02-26 WO PCT/US2001/006188 patent/WO2001075752A2/fr active Application Filing

Also Published As

Similar Documents

Legal Events