Systems, methods and computer program products for monitoring credit risks in electronic trading systems

Abstract

A credit monitoring system in an electronic trading system forms a complex check to determine if two particular counterparties will except each other for a particular trade based upon their respective predefined credit preferences. In accordance with an embodiment, credit preferences imputed by each counterparty with regard to the other counterparty are referenced to determine the trade eligibility of either party with respect to the other for a particular financial transaction instrument. Indication of whether a counterparty can enter into the proposed trade is conveyed to the respective trader, preferably using a color coding scheme in which various colors represent the relevant credit status with regard to the viewing trader. The complex check performed by the system may be embodied in a simple yes/no statement, in terms of maturity of a particular financial instrument, or in terms of a risk quotient (i.e., risk equivalent or RQ) initially determined by the system, though modifiable by the trader.

Claims

Wherefore, the following is claimed:

1. A system for credit screening a proposed electronic trade of a derivative between a first trader and a second trader, comprising:

means for receiving first credit preference information of said first trader with respect to said second trader, wherein said first credit preference information relates to at least one derivative, and wherein said first credit preference information is comprised of at least one of contract maturity and formulated risk equivalent;

means for receiving second credit preference information of said second trader with respect to said first trader, wherein said second credit preference information relates to at least one derivative, and wherein said second credit preference information is comprised of at least one of contract maturity and formulated risk equivalent;

means for evaluating said first and second credit preferences with respect to the trade of a first derivative to determine respective trade eligibility of said first and second traders to trade with each other; and

means for reporting said respective trade eligibility of said proposed electronic trade to said first trader and said second trader.

2. The system of claim 1, wherein said means for reporting includes a first indication representing that said first and second traders will trade with each other, a second indication representing that said first trader will trade with said second trader but said second trader will not trade with said first trader, and a third indication representing that said second trader will trade with said first trader but said first trader will not trade with said second trader.

3. The system of claim 2, wherein said means for reporting includes a color coding scheme for presenting said first, second and third indications respectively to said fast and second traders.

4. The system of claim 3, wherein said color coding scheme includes a first color associated with said first indication, a second color associated with said second indication, and a third color associated with said third indication.

5. The system of claim 2, further comprising a credit override mechanism to enable trading between said first trader and said second trader when one of said second indication and said third indication is reported to said first trader and said second trader.

6. The system of claim 1, wherein said first credit preference information is defined in terms of a yes/no statement.

7. The system of claim 1, wherein said formulated risk equivalent is automatically determined by said system.

8. The system of claim 1, wherein said first and second credit preference information is maintained in anonymity.

9. The system of claim 1, wherein said first and second credit preference information can be updated in essentially real-time by said first and second traders, respectively.

10. The system of claim 1, wherein said first credit preference information is that of said first trader in respect to a second legal entity of said second trader.

11. The system of claim 1, wherein said second credit preference information is that of said second trader in respect to a first legal entity of said first trader.

12. The system of claim 1, further comprising means for enabling said first trader to define a shared credit preference for plurality of derivatives in a credit group.

13. A method for screening order information proposing a trade of a derivative via an electronic trading system, comprising the steps of:

receiving first credit preference information defined by a first trader with respect to a second trader, wherein said first credit preference information is comprised of at least one of contract maturity and formulated risk equivalent;

receiving second credit preference information defined by the second trader with respect to the first trader, wherein said second credit preference information is comprised of at least one of contract maturity and formulated risk equivalent; and

encoding the order information that is presented to the first and second traders proposing the trade to provide respective trade eligibility utilizing the first and second credit preference information.

14. The method of claim 13, further comprising the step of modifying the first credit preference information by the first trader.

15. The method of claim 13, wherein said step of encoding includes a first indication representing that the first and second traders will trade with each other, a second indication representing that the first trader will trade with the second trader but the second trader will not trade with the first trader, and a third indication representing that the second trader will trade with the first trader but the first trader will not trade with the second trader.

16. The method of claim 15, further comprising executing an override process to enable trading between said first trader and said second trader when one of said second indication and said third indication are encoded and presented to one of said first trader and said second trader.

17. The method of claim 13, wherein the first credit preference information and the second credit preference information are defined as preferences with regard to at least one derivative.

18. The method of claim 13, further comprising the step of maintaining the first and second credit preference information in anonymity.

19. The method of claim 13, wherein said step of receiving the first credit preference information includes the step of receiving first credit preference information that is defined in terms of a yes/no statement.

20. The method of claim 13, further comprising the step of determining the formulated risk equivalent automatically by the electronic trading system.

21. The method of claim 13, wherein said step of encoding includes an indication presented to the first trader representing that the first trader will trade with the second trader but the second trader will not trade with the first trader, further comprising the step of providing a credit over-ride process that allows the first trader to deal with the second trader directly if the second trader agrees.

22. The method of claim 13, wherein the step of receiving first credit preference information comprises receiving first credit preference information defining a credit preference of said first trader in respect to a second legal entity of said second trader.

23. The method of claim 13, wherein the step of receiving second credit preference information comprises receiving second credit preference information defining a credit preference of said second trader in respect to a first legal entity of said first trader.

24. The method of claim 13, further comprising defining a credit preference for a credit group having a plurality of derivatives.

25. The system of claim 24, wherein said first trader can modify the derivatives in said credit group.

26. The method of claim 25, wherein said first trader posts a price and said second trader is provided said third indication, wherein said step of executing said override process comprises:

requesting an order quantity from said first trader by said second trader, wherein said step of requesting includes providing an identity of said second trader to said first trader; and

responding to said request to said second trader by said first trader with a response consisting of an accept message, a decline message or a modified order quantity.

27. A computer program product for use with a data processing system for credit screening of order information proposing a trade of a derivative via an electronic trading system, said computer program product comprising:

a computer usable medium having computer-readable code means embodied in said medium, said computer-readable code means comprising:

computer readable program code, means for receiving first credit preference information of said first trader with respect to said second trader, wherein said first credit preference information is comprised of at least one of contract maturity and formulated risk equivalent;

computer readable program code means for receiving second credit preference information of said second trader with respect to said first trader, wherein said second credit preference information is comprised of at least one of contract maturity and formulated risk equivalent;

computer readable program code means for evaluating said first and second credit preferences with respect to the trade of a first derivative to determine respective trade eligibility of said first and second traders to trade with each other; and

computer readable program code means for reporting said respective trade eligibility of said proposed trade to said first trader and said second trader.

28. The computer product of claim 27, wherein said computer readable program code means for reporting includes a first indication representing that said first and second traders will trade with each other, a second indication representing that said first trader will trade with second trader but said second trader will not trade with said first trader, and a third indication representing that said second trader will trade with said first trader but said first trader will not trade with said second trader.

29. The computer program product of claim 27, wherein said first credit preference information defines preferences with regard to a single derivative.

30. The computer program product of claim 27, wherein said first credit preference information is defined in terms of a yes/no statement.

31. The computer program product of claim 27, wherein said formulated risk equivalent is automatically defined by said system.

32. The computer program product of claim 27, wherein said first and second credit preference information is maintained in anonymity.

Description

FIELD OF THE INVENTION

The present invention generally relates to brokerage systems and methods, and more particularly, to credit risk screening of potential counterparties before conducting trades via an electronic trading system.

BACKGROUND OF THE INVENTION

In recent years, commodity exchanges have become more and more dependent upon electronic trading systems. The older manual methods by which trades were conducted have given way to advanced computer systems that have generally mimicked the manual methods of old. These relatively new electronic trading systems have many advantages over the manual systems, including the ability to provide such features as greater accuracy, reduced labor cost, real time market information, more efficient communications over greater distances, and automated record keeping. However, because the markets in which these commodities are being traded are so vastly different from the descriptions of the instruments to transaction methodologies, electronic trading systems are generally limited to a specific market such as futures, cash, oil, stock, securities, etc., and sometimes even to a specific commodity within a single market.

An example of one such automated trading system designed for the anonymous trading of foreign currencies is described in U.S. Pat. Nos. 5,077,665 and 5,136,501, both issued to Silverman et al. and assigned to Reuters Limited of London. In the Silverman et al. system, a single central host computer maintains a central data base that may consist of the trading instruments available for trade, credit information, and various bids and offers that are present throughout the system. The host computer may then use this information to match active bids and offers based on matching criteria which may include the gross counterparty credit limit between counterparties to a potential matching transaction, price, and available quantity. To that end, each client site may establish, and may subsequently vary or reset, a credit limit for each possible counterparty. The credit limits may be used by the host computer to establish the gross counterparty credit limit for each possible pair of parties and which may be equal to the minimum of the remaining credit (i.e., initial credit limit less any applicable transactions that have already been executed) from a first party to a second party and from the second party to the first party. The host computer may block completion of an otherwise eligible matching transaction between a given pair of potential counterparties when the transaction has an associated value in excess of the applicable gross credit limit. In the Silverman et al. system, the various client site computers (also referred to as keystations) merely maintain and display a restricted subset of the information available at the host computer such as a predetermined number of the best bids and offers, and communicate credit and other transaction orientated information to the host computer for execution. However, in an attempt to preserve the anonymity of the parties, the client sites may not have access to the credit limits set by their possible counterparties, or even to the identification of any other party to a particular transaction until after a transaction has been completed.

Thus, in the Silverman et al. system, confidential counterparty credit limit data is apparently maintained and utilized as part of the trade matching process by the central host computer. As a consequence, each client site may not have the ability to determine, prior to committing to buy or sell at a displayed price from one or more anonymous counterparties, whether it is in fact eligible to respond to any of the bids or offers currently being displayed. Further, the credit limit appears to be merely a cap value (or credit line) on the amount of trading one party will enter into with another party. It has little to no relationship to the credit risk the other party represents since the financial commitment associated with the financial instruments traded with this system ends at the consummation of the underlying contract,. Thus, a cap value may be sufficient in this particular circumstance. The central host computer may not utilize the credit information until after a match has been found between counterparties to determine if the counterparties have sufficient credit with one another to execute the trade.

Consequently, unless a trader attempts to execute a trade at the best price currently displayed on the trader's screen, the trader using one of the anonymous matching systems may not know whether the trader has credit with, and is willing to extend credit to, the anonymous counterparty offering (i.e., bidding) the best price currently displayed on the trader's screen. Thus, the trader does not know whether any attempt to buy or sell at the displayed price may be subsequently invalidated by the system for lack of such credit. The Silverman et al. system also fails to provide for dialogue between the parties, much less anonymous dialogue which may facilitate the execution of a trade that might otherwise not occur.

Another automated trading system is disclosed in U.S. Pat. No. 5,375,055 issued to Togher et al. and assigned to Foreign Exchange Transaction Services, Inc. The Togher et al. system is an anonymous trading system which may identify the best bids and offers from those counterparties with which each client site is currently eligible to deal, while maintaining the anonymity of the potential counterparty and the confidentiality of any specific credit limitations imposed by the anonymous potential counterparty. This system is apparently designed to run as a closed system, with dedicated desk top terminals connected to various local computer centers which are in turn connected to regional computers.

In the Togher et al. system, each client site may only be able to view one foreign currency at a time per screen. The Togher et al. system is further limited by the fact that each client site may provide the system with only limited credit information for each potential counterparty (for example, a one bit flag indicating whether a predetermined limit has already been exceeded), and by the fact that each bid or offer for a particular type of financial instrument is apparently prescreened by the system for compatibility with that limited credit information before calculating an anonymous dealable price for presentation to the traders dealing with that particular financial instrument. The prescreening in Togher et al. is a simple check to determine whether any credit remains between the two counterparties to the potential transaction, and thus may be performed using a simple yes/no preauthorization.

The preauthorization matrixes may be maintained at each of the several regional nodes (also referred to as distributed nodes) of a distributed processing communication network, with each such regional node being connected by corresponding individual links of the communications network to the respective client sites ("access nodes") for which it is responsible for distributing market information including customized dealable bid and offer prices and global best prices.

The sensitive credit limit data indicating how much credit a particular client site is willing to extend to each possible counterparty is preferably maintained at an access node associated with that particular client, and a simple yes/no indication of whether the entity (for example, a trader, a trading floor, or a bank) associated with that particular client site is willing to transact business with a particular counterparty is transmitted to the other nodes of the communications network.

To further limit the data received and processed by each of the relevant regional node computers, (i.e., the regional nodes closest to the particular site and/or closest to the particular counterparty), merely the changes in the credit state between a particular client site and a particular counterparty (i.e., that credit is no longer available or credit is now available) may be transmitted to the distribution nodes, and any credit state information relevant to transactions between two client sites both associated with other distribution nodes may be altogether ignored.

In the Togher et al. system, if either of the two applicable credit limits has not previously been exceeded between a particular pair of counterparties, then the system displays the entire bid or offer as a dealable transaction, but apparently permits each client site to block any above-limit portion of any resultant buy or sell transaction during a subsequent deal execution/verification process. This may, however, add additional time consuming steps for the users of the Togher et al. system. Alternatively, possibly at the option of the party by or for whom the low limit has been set, the entire transaction may be blocked. As a second alternative, a preauthorization matrix may indicate whether sufficient credit remains to execute a predetermined standard deal amount in addition to, or instead of, a mere indication as to whether any credit from a particular potential counterparty had already been used up. In such an alternate embodiment of the Togher et al system, it might also be possible to display to each trader two dealable prices: one at which at least the predetermined standard amount is available, and a second one at which only a small amount may be available. Thus, individual orders are not independently treated, and the user may not have the ability to look through the bids and offers and deal at a worst price, if the user so chooses because of a difference in counterparties credit qualities.

In accordance with another aspect of the Togher et al. system, at least a first trader having an open quote that is displayable as the best dealable or regular dealable quote at any of the other trading floors is automatically alerted that their bid (offer) quotation is the best price available to at least one potential counterparty with whom mutual credit exists, and thus could be hit (taken) at any time. Similarly, at least if the quoter's bid (offer) quote is not currently the best with at least one trading floor but is thus subject to immediately being hit (taken) by a trader at that trading floor, then the quoter is preferably also alerted if his/her quote is joined (i.e., equal to in price, but later in time) to such a best dealable or regular dealable price from another trading floor. In other words, in the Togher et al. system, the auto-matching process does not enable the active trader to select a price other than the best price to trade. This may force the trader to accept what the system offers, even if the trader would prefer a different counterparty for credit reasons. In addition, the Togher et al. system does not show the trader the total depth of the market, only those prices which are dealable, and thus, may fail to give the trader complete picture of the market. The is also limited to the quantity stated. No provision is made for the modification or negotiation of the quantity or other terms of the trade.

The systems described above are such that they focus on overnight settlement risk.

These systems are apparently incapable of dealing with the actual credit requirements of a variety of different individual financial instruments simultaneously and the counterpart's long-term ability to meet these requirements. As a result, these systems generally have only been deployed in the markets where settlement takes place in a few days and there are no continuous or ongoing credit requirements between the counterparties. Specifically, as a result of these limitations, these designs may not be able to handle the anonymous trading of financial instruments such as interest rate swaps, caps and many other financial products. They may be unable to accommodate these more complex financial instruments because, among other things, these systems apparently treat all financial instruments alike, and therefore, may be incapable of handling more complex financial instruments which require a judgment about the financial strength of the opposing counterparties. Trades conducted with some financial instruments such as derivatives create multi-year financial commitments, and therefore, mere credit limit or credit cap systems are insufficient means for measuring and managing an institution's credit risk.

Accordingly, it is noted that no known system is designed to operate with derivative products such as interest rate swaps, caps, floors, forward rate agreements (FRA), interest rate basis swaps, interest rate options, switches, or other over the counter derivative instruments. Derivatives are considered by many to be too complex to be efficiently handled within an electronic trading system. Particularly, derivative products are typically define by certain terms and conditions, and each of the different types of derivatives products are defined by a different set of terms and conditions. For example, an FRA is defined by a start time, an end time, an over date, and a floating rate option, while an interest rate swap is defined by a start time, an end time, an over date, a floating rate option, a frequency of the fixed coupons, a basis, and a special rule(s) as applicable with some currencies. Accordingly, the variances in the specific information necessary to adequately define the different derivative products has apparently been a deterrence to the development of an electronic derivatives trading system.

Yet another deficiency of the prior art systems is the inability to automatically determine one's position (i.e., credit risk position), and the inability to identify possible counterparties with offsetting positions for initiating a transaction. No know electronic trading system has been able to provide this information on a real-time basis. This strikes to the essence of the derivatives market which is based upon large financial institutions to being able to manage their credit risk on a daily basis.

A further limitation of the known electronic trading systems which has contributed as a deterrence to their application to the derivatives market is the absence of an acceptable credit screening process of potential counterparties in a manner which accommodates the nuances of the derivatives market. While many of the prior art electronic trading systems such as the ones described above provide a credit screening feature, they typically only track the amount transacted between two parties, and upon each transaction between the two parties, reduces the available amount according to the amount of the transaction. Thus, the credit risk measured by these systems is based on the principle or quantity of the transaction. No consideration is given to the future obligations under the contract.

In the derivative market, a counterparty's credit position may vary with each new transaction conducted with other parties. The prior art systems do not account for such changes in a counterparty's position. Further, the credit qualities associated with derivative products are generally more complex than most other financial instruments. For example, a particular trader may be willing to trade with a particular counterparty on one type of financial instrument but not another. Further, a trader may accept that one type of financial instrument but only for a certain length of time (i.e., maturity).

Thus, a heretofore unresolved need exist in the industry for a system and method for anonymous credit screening of potential counterparties before conducting trades via an electronic trading system wherein the credit risk preferences of the trader take into account the complexity of the different types derivatives instruments.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide improved credit screening for electronic trading systems.

It is another object of the present invention to provide anonymous bi-lateral credit screening which determines trade eligibility based on both trader's credit preferences.

It is another object of the present invention to provide credit preference screening which considers the amount and maturity of each financial instrument being traded.

These and other objects of the present invention are provided for a credit monitoring system that forms a complex check to determine if two particular counterparties will accept each other for a particular trade based upon their respective predefined credit preferences. In accordance with an embodiment of the present invention, credit preferences inputed by each counterparty with regard to the other counterparty are referenced to determine the trade eligibility of either party with respect to the other for a particular financial transaction instrument. Indication of whether a counterparty can enter into the proposed trade is conveyed to the respective trader, preferably using a color coding scheme in which various colors represent the relevant credit status with regard to the viewing trader. The complex check performed by the system may be embodied in a simple yes/no statement, in terms of maturity of a particular financial instrument, or in terms of a risk quotient (i.e., risk equivalent or RQ) initially determined by the system, though modifiable by the trader. Accordingly, financial institutions which trade complex financial instruments such as derivatives which create obligations which extend into the future may better monitor their credit risk by the bilateral credit screening of the present invention. Particularly, the multilevel credit preferences which each trader may utilize in establishing credit preferences with regard to other counterparties enables greater control and flexibility in the trading of complex financial instruments. It is further noted that the credit check process is performed anonymously so as not to identify potential counterparties to a deal until after the trade is agreed to by both parties.

In accordance with an aspect of the present invention, a system for credit screening an electronic trade of a financial instrument between a first trader and a second trader comprises means for receiving first credit preference information of the first trader with respect to the second trader, wherein the first credit preference information relates to at least one financial instrument. The system further comprises means for receiving second credit preference information of the second trader with respect to the first trader, wherein the second credit preference information relates to at least one financial instrument, and means for evaluating the first and second credit preferences with respect to a trade of a first financial instrument to determine respective trade eligibility of the first and second traders to trade with each other. The system further comprises means for reporting the respective trade eligibility to the first trader and the second trader.

The means for reporting may include a first indication representing that the first and second traders will trade with each other, a second indication representing that the first trader will trade with the second trader but the second trader will not trade with the first trader, and a third indication representing that the second trader will trade with the first trader but the first trader will not trade with the second trader. In addition, the means for reporting may include a color coding scheme for presenting the first, second and third indications respectively to the first and second traders. The color coding scheme may include a first color associated with the first indication, a second color associated with the second indication, and a third color associated with the third indication.

The credit preference information may defined in terms of a yes/no statement, a maturity of a financial instrument, or a risk equivalent. The risk equivalent is preferably automatically determined by said system. In accordance with a feature of the present invention, the first and second credit preference information is maintained in anonymity. The first and second credit preference information may be updated in essentially real-time by the first and second traders, respectively.

In accordance with another aspect of the present invention, a method for credit screening order information proposing a trade of a financial instrument via an electronic trading system comprises receiving first credit preference information defined by a first trader with respect to a second trader, receiving second credit preference information defined by the second trader with respect to the first trader, and encoding the order information presented to the first and second traders utilizing the first and second credit preference information.

The method may further comprise modifying the first credit preference information by the first trader. The step of encoding includes a first indication representing that the first and second traders will trade with each other, a second indication representing that the first trader will trade with the second trader but the second trader will not trade with the first trader, and a third indication representing that the second trader will trade with the first trader but the first trader will not trade with the second trader.

The first credit preference information and the second credit preference information may be defined as preferences with regard to at least one financial instrument. In accordance with a feature of the present invention, the method may further include maintaining the first and second credit preference information in anonymity.

In accordance with yet another aspect of the present invention, a computer program product for use with a data processing system for credit screening order information proposing a trade of a financial instrument via an electronic trading system comprises a computer usable medium having computer-readable code means embodied in said medium, wherein the computer-readable code means comprises computer readable program code means for receiving first credit preference information of the first trader with respect to the second trader. The computer program product further comprises computer readable program code means for receiving second credit preference information of the second trader with respect to the first trader, computer readable program code means for evaluating the first and second credit preferences with respect to a trade of a first financial instrument to determine respective trade eligibility of the first and second traders to trade with each other, and computer readable program code means for reporting the respective trade eligibility to the first trader and the second trader.

BRIEF DESCRIPTION OF THE DRAWINGS

The file of this patent contains at least one drawing executed in color. Copies of this patent with color drawings will be provided by the Patent and Trademark Office upon request and payment of the necessary fee.

FIG. 1 is a schematic diagram of a computer network implementing an electronic trading system in accordance with an embodiment of the present invention.

FIG. 2 is a block diagram illustrating the architecture and functionality of a central processing center in accordance with an embodiment of the present invention.

FIG. 3 is a block diagram illustrating the architecture and functionality of a trader system in accordance with an embodiment of the present invention.

FIG. 4 is a block diagram illustrating the architecture and functionality of a business unit proxy in accordance with an embodiment of the present invention.

FIG. 5 is an example of a command center interface.

FIGS. 6A-6B are examples of different tabbed partitions of a user preference interface.

FIG. 7 is an example of a credit preference setting interface.

FIGS. 8A and 8B are examples of different tabbed partitions of a modify credit groups interface.

FIGS. 9A and 9B are examples of the new binary interface and complex preference interface respectively, which are accessible from the credit preference setting interface.

FIG. 10 is an example of a business unit information interface.

FIG. 11 is an illustration of the credit preference logic of an embodiment of the present invention.

FIG. 12 is an example of a market entry interface.

FIG. 13 is an example of a symbol definition interface,

FIG. 14A is an example of an passive order interface.

FIG. 14B is an example of an hit order interface.

FIG. 15 is an example of a market detail interface.

FIG. 16 is an example of an outstanding order blotter interface.

FIG. 17 is an example of a client monitor interface.

FIG. 18 is an example of a execution notification and quantity negotiation interface.

FIG. 19 is an example of a term negotiation interface.

FIG. 20 is an example of a user position portfolio interface.

FIG. 21 is an example of a switch interface.

FIGS. 22A and 22B are examples of an auction interface and a switch auction interface, respectively.

FIG. 23 is an example of a main screen interface in accordance with an embodiment of the present invention.

FIG. 24 is a flowchart of the credit preference feature in accordance with an embodiment of the present invention.

FIG. 25 is a flowchart of the subject based addressing feature in accordance with an embodiment of the present invention.

FIG. 26 is a flowchart of the execution of a trade in accordance with the embodiment of the present invention.

FIGS. 27A and 27B are flowcharts of a trade execution from the perspective of the user posting the order and the user acting on the order, respectively, and in accordance with an embodiment of the present invention.

FIG. 28 is a flowchart of the position discovery feature in accordance with an embodiment of the present invention.

FIG. 29 is a flowchart of the auction feature in accordance with an embodiment of the present invention.

FIG. 30 is a detailed flowchart of the auction feature in accordance with an embodiment of the present invention.

FIG. 31 is a flowchart of the calculation of the average auction price in accordance with an embodiment of the present invention.

FIG. 32 is a flowchart of the matching performed in an auction in accordance with an embodiment of the present invention.

FIG. 33 is a flowchart of the validation of a resulting order in an auction in accordance with an embodiment of the present invention.

FIG. 34 is a process flow diagram illustrating operations and functionality of the central processing center in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

I. Introduction

The following description is of a best-contemplated mode of carrying out the present invention. The systems, methods, and computer program products of the present invention have practical application in anonymously trading a very broad cross-section of credit-sensitive, bilateral financial instruments. However, a particular application of the present invention described hereinafter is directed to the use of the present invention for trading financial instruments in the derivatives market. The scope of the present invention should not be limited to that described hereinafter, but should be determined by referencing the appended claims.

The present invention provides for a standardized contract definition, and means for matching complex credit preferences of each counterparty before a trade is executed. Therefore, potential counterparty users are able to identify bids and offers that they are eligible to trade based on credit preference information provided before initiating a trade. The present invention also permits users to place passive orders (bids or offers on the various financial products for other counterparties to actively choose from to hit (bids) or lift (offers), without the posting user doing anything further) or active orders (where the viewing user actively initiates the trade by selecting passive bids or offers which are already in the system). This gives a user maximum control over the order flow process. For instance, there may be a situation whereby the bids in a particular market are higher than the offers, but no trading is taking place. This situation may occur when the credit quality of the best offer (which in this case would be below the bid) would not be good enough for a bidder to be willing to enter into a transaction with that counterparty. This is a significant difference from the prior art systems in which orders are automatically matched if the prices are equal because such prior art systems typically limited the user's control over the order flow.

The present invention also provides financial markets with electronic trading systems and methods for identifying possible counterparties and executing trades for forward rate agreement (FRA) switches and other financial products. The present invention further provides the ability for the users to place orders for various financial instruments via an auction process that can be one-to-many or many-to-many, whereby the system automatically matches all orders and determines the prices and quantities executed on the basis of several guidelines or parameters. A further feature of the present invention is an auction trading that is available to users, whereby users can use an auction process to trade FRA switches with the other counterparties. This form of auction is referred to hereinafter as a switch auction. In the auctions, the price is preferably pre-determined by the system prior to the auction taking place. The prices determined by the system are referred to hereafter as the fair price.

The systems and methods of the present invention are designed to reflect the fact that financial institutions operate under many different structures. In order to accomplish this, the following concepts/definitions are provided:

Legal Entity (LE):

This is the incorporated entity in which contracts are negotiated on behalf of by users (traders) of the system.

Business Unit (BU):

This is a grouping of individual users within a Legal Entity that act together and share attributes such as LE, manager, address, settlement information, credit preferences (see below), etc.

Risk Equivalent (RQ):

This is the unique measure of Risk associated with financial contracts such that contracts with different attributes can be compared on a like basis for credit risk purposes.

Credit Preferences (CP):

This is the model which allows the system to handle different measures of risk equivalent used by different institutions and different financial contracts, all with different internal structures.

Classes of Financial Instruments (CL):

These are collections of financial contracts which share similar attributes.

Credit Groups (CG):

A method to allocate credit preferences across classes of financial contracts.

User Preferences (UP):

A method to allow institutions or users to control or manage access to the functions within the system.

Filters (FI):

These allow users to limit the messages (i.e., request for price or request for switch they receive or view.

Symbology (SY):

This enables users to quickly and easily reference financial contracts within the system in a systematic manner.

Term Negotiation (TN):

This is a method which allows users to negotiate non-commercial terms of contract subsequently to a trade. For example, the exchange of bonds relating to a spread trade.

Credit Over-Ride Process:

This process enables a user to disclose his/her identity to a counterparty to see if they will accept a trade with him/her even though they initially refused him due to credit issues.

Comprehensive Confirmations:

This is a confirmation lay-out in order to fully define bilateral contracts across any classes of financial instruments.

Request For (RF)

This is a method to broadcast to the other users (subject to their FI) an interest in a price or market.

II. System Architecture

As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, a data processing system, or a computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program code means embodied in the storage medium. Any suitable computer readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

The present invention is described below with reference to block diagrams and flowchart illustrations of methods, apparatus (i.e., systems) and computer program products according to an embodiment of the invention. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

A trading system in accordance with the present invention is an electronic brokerage system which may use Internet protocol-based communications networks for facilitating the trading (i.e., buying and selling) of financial derivatives by users, each of which is associated with the user's own desktop computer system (trader system) located on the trading floor of a financial institution (client site), as described below. At the user's desktop computer system, the present invention is preferably implemented by a Java-based software program, though other suitable program languages can be utilized such as dynamic hypertext markup language (DHTML), C+ or C++.

As shown in FIG. 1, a trading system 10 in accordance with the present invention comprises a central processing center 12 which is in communication with the client sites 14 via one or more of a variety of Internet protocol based networks 16. By way of illustration, a private extranet, a public Internet, and a third party extranet are show, though it will be recognized by those skilled in the art that other networks such as the Public Switch Telephone Network (PSTN) may be implemented as a network 16. Further, by having multiple networks 16 available, the user is provided redundancy in case one network experiences a service interruption, and the user is able to choose between the several networks 16 for primary access based on factors such as toll charges or bandwidth.

Each client site 14 includes one or more business unit servers 18 which, among other things, can store copies of the Java applets which can be utilized to implement the present invention. The business unit servers 18 may also perform encryption/decryption functions for messages that are received and sent over the networks 16. The business unit servers 18 are preferably connected to the client sites 14 internal data network. Thus, one or more trader workstations 20 may be connected to a business unit server 18 of a client site 14.

Accordingly, a user's own desktop computer which is connected to the client's internal data network may function as a trader workstation 20 and run the Java-based software of the present invention to enable interaction with other trader workstations 20 via the central processing center 12.

With reference to FIG. 2, illustrated is the central processing center 12 which includes a trade mechanism 30, a group server mechanism 32, auction mechanism 34, and a switch mechanism 35, all in accordance with the present invention. The trade mechanism 30 includes several modules including a market inventory module 38, an execution module 40, and a settlement module 42. The market inventory module 38 holds the passive orders for each market and broadcast the same to the trader workstations 20 when new orders are received, validates any proposed trade, performs a second and final credit preference check that cannot be performed at the trader workstation 20, validates that both traders are still on-line (i.e., active), executes the trade, and sends out a status update to the traders. The execution module 40 receives the executed trade and proposes a trade for a greater quantity if applicable (referred to as the will-do-more feature), and processes term negotiation if applicable. The settlement module 42 calculates the appropriate commission, generates the confirmation, and sends the confirmation to the two parties.

The group server mechanism 32 interfaces the trader module 30 with the trader workstations 20. The central processing center 12 may include a plurality of group server mechanisms 32, each of which preferably serves a subset of the users (i.e., trader workstation) of system 10, though the system 10 may be implemented with only one group server mechanism 32. The group server mechanism 32 monitors the connection of each trader workstation 20 so that log-in and log-out times and usage can be monitored. The group server mechanism 32 also caches market information being viewed at each trader workstation 20 and creates an order identification code that uniquely identifies that order. The credit preference information of all users is cached in by the group server mechanism 32 for delivery to each trader workstations 20 when the associated user logs in. Any changes in the credit preference setting by a trader are detected and forwarded to the trader workstations 20 of the other users.

The switch mechanism 35 is configured to receive a portfolio of interest reset risk for a plurality of users and provide the users with an anonymous view at their relative position to other possible counterparties and available trades that may offset the user's interest rate reset risk. The auction mechanism 34 performs a switch auction function whereby orders or FRA's are received from the users and anonymously matched based on an algorithm that takes user credit preferences into consideration.

The trader mechanism 30, group server mechanism 32, auction mechanism 34, and switch mechanism 35 may be collectively implemented as market module 44.

The central processing center 12 includes a processor 50 that communicates with the other elements within the central processing center 12 via a system interface 52. An input devise 54, for example a keyboard or a pointing device, is used to input data from a user, and a screen display device 56, for example, a monitor, is used to output data to the user. A memory 58 within a central processing center 12 includes the market module 44 and a conventional operating system 60 which communicates with the market module 44 and enables execution of the market module 44 (including the trade mechanism 30, group server mechanism 32, and auction mechanism 34) by processor 50. An external communication line 62 is provided to interface the central processing center 12 with other computer systems or computer-based devices such as networks 16. Lastly, a hard disk 64 may be provided as a persistence memory device, as well known to the industry. Preferably, a relational database 66 resides on the hard disk 64 for maintaining information such as current state information for each trader workstations 20, user and business unit data, financial instrument definitions, order states, transaction states, confirmation states, historical confirmation and transaction data, credit preferences of all business units, and historical market data. Preferably, the relational database 66 is based on structured query language (SQL) management system, as well known in the industry.

With reference now to FIG. 3, illustrated is an embodiment of the trader workstations which includes a trader module 70 in accordance with the present invention. The trader module 70 may be implemented as a component of a Java-capable Internet browser program 72, such as Netscape Communicator.RTM. (Netscape Communication Company) or Microsoft.RTM. Internet Explorer (Microsoft Corporation) version 3.0 or higher. Thus, in a preferred embodiment, the trader module 70 is a Java-based program that is downloaded as Java applets for each session and implemented by a Java virtual machine (JVM) 73 within the Internet browser 72. The JVM 73 of the Internet browser program 72 may be a stand alone software application, a plug-in application, or a helper application, all of which is well known in the art. The trader module 70 includes a market interface module 74, a credit preference module 76, a symbol module 78, switch module 80, and an auction module 81. The market interface module 74 comprises one or more user interfaces for presenting information to the user. In the context of the present embodiment, a user interface is provided as a window within the context of the Internet browser program 72. However, a user interface in accordance with the present invention may take many forms such as a three dimensional virtual reality world based on virtual reality modeling language (VRML), an audio receiver/transmitter, or any other suitable form of interface between the user and trader workstations 20. In a preferred embodiment, the market interface module 74 comprises a control center interface, market entry interface, market detail interface, switch interface, and auction interface, all of which are described in more detail hereinafter.

The credit preference module 76 receives the stored credit preferences inputted by the user and stored at group server mechanism 32. The stored credit preferences include preferences directed to the other business unit's legal entities, and the preferences inputted by the other users directed toward the business unit's legal entity of the subject user. As mentioned above, the credit preference information is preferably stored in the database 66 (FIG. 2). The credit preference module 76 may encode the order information being presented to the user with the credit preferences of the user and the credit preferences of counterparty that posted the order. The credit preference module 76 also performs a credit preference check for each order when a trade is initiated. Because of the potential complexity associated with the different types of credit methods offered by the present invention, portions of the credit check process may be performed by the market inventory module 38 of the central processing center 12. The credit preference module 76 at each trader workstation 20 comprises a simplified matrix of yes's and no's, and associated maturities. If the business unit has selected an even more complex method (i.e., complex), a unit (such as a risk quotient, i.e., RQ) by maturity is also required. The trader workstation 20 will therefore not be able to determine whether the full quantity can be traded. Thus, the market inventory module 38 repeats the credit check to ensure the very latest credit preferences are used (in case of any latency in updating the credit preferences at the trader workstations 20) and to complete any complex credit preference check for quantity.

The symbol module 78 stores the symbol definitions utilized for the subject-based addressing of the different financial instruments traded in the system 10. The symbol module 78 also provides means for defining new symbols for use with the system 10. The switch module 80 is configured to receive interest rate reset risk portfolios from the user which are sent to the switch mechanism 35 at the central processing center 12. The relative position information generated by the switch mechanism 35 is returned to the switch module 80 which presents the position information to the user via the market interface module 74. The auction module 81 is configured to receive multiple or batch orders on a single instrument at different price levels, and in case of a switch auction, to receive a interest rate reset risk portfolio from the user. The inputted orders or portfolio is sent to the auction server 34 at the central processing center 12 where the auction or switch auction, respectively, is performed. The resulting matches are returned to the auction module 81 which presents the results to the user via the market interface module 74.

The trader workstations 20 includes a processor 82 that communicates with other elements within the trader via a system interface 84. An input device 86, for example, a keyboard or pointing device, is used to input data from the user, and a screen display device 88, for example, a monitor is used to output data to the user. A memory 90 within the trader workstations 20 includes the Internet browser program 72 (and thus, the trader module 70) and a conventional operating system 94 which communicates with the Internet browser program 72 and enables execution of the Internet browser program 72 (and thus, the trader module 70) by processor 82. It is noted, however, that the trader module is preferably implemented as a Java-based program that is downloaded into memory 90 for the execution during a single session, and the trader workstations 20 will not persistently store the trader module 70. Further, as a Java-based program, the trader module 70 will be executed on a JVM 73 which is a component of the Internet browser program 72.

An external communication link 96 is provided to interface the trader workstations 20 with other computer systems or computer-based devices such as respective business unit servers 18. Lastly, a hard disk 98 may be provided as a persistent memory device, as well known in the industry. It is noted that the trader workstation 20 may comprise a desktop computer system as previously mentioned, or alternatively, the trader workstation 20 may comprise a portable computing device such as a notebook computer, handheld PC, personal digital assistant (PDA) or any other suitable device capable of running an Internet browser program and creating a communication link for interfacing with a network.

Therefore, a user of the system 10 is not necessarily tied to a specific hardwired terminal, but has a virtual terminal that goes with the user wherever the user has access to a Java capable browser and Internet access. The trader module 70 may be implemented as an independent program capable of establishing a communication link to the central processing center 12 via the Internet, a local area network (LAN), or a wide area network (WAN). Thus, the user can even have access to the system 10 via direct modem dial-in to the central processing center 12 over the public switched telephone network (PSTN) or Internet.

With reference now to FIG. 4, illustrated is an embodiment of a business unit server 18 which includes a proxy agent 110 in accordance with the present invention. The proxy agent 110 may perform numerous functions including decoding and encoding encrypted messages sent and received over networks 16. The proxy agent 110 manages traffic to and from the trader workstations 20, and may provide other features such as document caching and network access control. The proxy agent 110 may improve performance by storing and supplying frequently requested data to the trader workstations 20, or by filtering and/or discarding information from the networks 16. Preferably, proxy agent 110 resides on a business unit server 18 which is part of the respective client sites 14 internal data networks. However, the system 10 of the present invention may be implemented without business unit servers 18, whereby the functionality of the proxy agent 110 may be incorporated into the trader module 70 of the respective trader workstation 20; such functionality including decoding and encoding encrypted messages, and network management.

The business unit server 18 includes a processor 112 that communicates with the other elements within the business unit server 18 via a system interface 114. An input device 116, for example, a keyboard or pointing device, is used to input data from a user, and a screen display device 118, for example, a monitor, is used to output data to the user. A memory 120 within the business unit server 18 includes the proxy agent 110 and a conventional operating systems 122 which communicates with the proxy agent 110 and enables execution of the proxy agent 110 by processor 112. An external communication link 124 is provided to interface the business unit server 18 with other computer systems or computer/based machines such as networks 16 and trader workstations 20. Lastly, a hard disk 126 may be provided as a persistence memory device, as is well known in the industry. Particularly, the hard disk 126 may include trader data profiles 128 for each of the different trader workstations 20 associated with the business unit server 18. Alternatively, the trader data may be stored at the central processing center 12 so that the trader does not need to re-build his/her screens each time he/she longs onto the system 10.

Thus, each trader workstations 20 at a client site 14 is able to access the system 10 through the Internet browser program 72 operating on the user's desktop computer. In order to access the system 10, the user may run Java-based applets on the desktop computer in the Internet browser program 72 which may be up-loaded to the desktop computer system by one of three means: 1) accessing them from the hard disk of the desktop computer 2) downloading them across the network from a server on the internal data network of the client site, or 3) by downloading them directly from the central processing center. Once the applets are loaded and running in the desktop computer of the user, the user is then able to access the system 10 and interact with other trader workstations 20 and engage in trading activities. In addition to traders at the client sites, a preferred embodiment of the present invention also enables non-trader users at the client sites 14, such as credit officers and other interested/relevant staff, to have access to the invention in the same manner as the users in order to monitor the trading activities, perform credit control or any other functions.

III. System Features

The following are features of the present invention which provide particular functionalities and utilities. These features include interfaces such as a command center interface, a market entry interface, a market details interface, an outstanding order interface, an historical order interface, and functions such as symbology, credit preference checking, term negotiation, automatic notification, interest rate reset risk switches, and order auction.

When beginning a session on the system 10, a user at a trader workstation 20 launches the Internet browser program 72 and goes to a particular address that connects the trader workstation 20 to the central processing center 12. This is preferably achieved by typing a known URL (Universal Resource Locator) in an address field of the Internet browser program 72. At the URL entered, the user will be presented with a log-on screen which preferably requires the user to input a user name and password for identification, verification and security reasons. After the user logs on, the user will download (preferably from proxy agent 110) the Java applets which will run locally on the desktop computer comprising the trader workstation 20. Alternatively, the user may launch a local or network application that runs locally or on an attached server. The application will enable a connection to system 10 over network 16, much the same as numerous dial-up services such as AOL. In addition, other information such as user defined preferences which are based on the trader's profile will be downloaded to the trader workstation 20. This may include information on what the user is allowed to trade, what markets the user is interested in monitoring, and other user specific information that was previously been defined by the user or another individual such a credit officer or the like.

After the user has successfully logged on and the requisite Java applets have been downloaded and are running on the JVM 73, the user is presented with a command center interface 130, as illustrated in FIG. 5, via the screen display device 88 (FIG. 3). The command center interface 130 is the front end of the user interface which provides access to all other features of the present invention, as described below. In an embodiment of the command center interface 130, the command center interface 130 is a pop-up window rendered on the screen display device 88. Note, however, when the command center interface is running, the user may be able to iconize (i.e., minimize) the Internet browser program 72 window, as may be desirable when the user no longer needs to view the Internet browser program 72.

From the command center interface 130, a user can access the features of the system which enable the user to monitor and control their trading in the system 10. Specifically, from the command center interface 130 the user can access the following areas of functionality as menu options on the tool bar 132: a market entry interface (described below with reference to FIG. 12), a credit settings interface (described below with reference to FIG. 10), a switch engine interface (described below with reference to FIG. 22), auction interface (See FIG. 13), tools, a user preference interface (described below with reference to FIGS. 6A and 6B), an historical order blotter interface (described below with reference to FIG. 17), an outstanding order blotter interface (described below with reference to FIG. 16), links to external applications such as MarketSheet.TM. (a trademark of TIBCO, Inc.) (referred to herein as the quote screen and graph screen for illustrative purposes), a logout interface (provides secure exit from the system 10), and a help interface where detailed on-line help is provided. The menu options that appear in the tool bar 132 are preferably customizable to a user, and those described are merely illustrative.

In addition, the command center interface 130 provides a message display window 134 for displaying real-time messages. These messages include system information, market information, requests-for-prices (RFPs), requests-for-switch (RFS) or online chat sessions with the users of the system 10. Below the message display window 134, the command center interface 130 displays the user's name 136, the user's default currency 138, the user's business unit 140, and other relevant information. The background color of the message display window preferably changes if the connection to the central processing center 12 is lost for any reason.

A user preferences interface 148, which is accessible from the command center interface 130 via the tool bar 132, provides a user with user preference features, such as those illustrated in FIGS. 6A and 6B. In FIG. 6A, a Derv Filters tab enables a user to set request-for-price (RFP) filters for viewing different derivative instruments based on the type (i.e., class) of derivative instruments and the currency. The user may also select the manner of presentation (i.e., highlighted or not). From the Derv Filters tab, the user is able to add and remove the derivative instruments from the user's viewing list, that is, the list of instrument that will appear on the message display window 134 of the command center interface 130. In FIG. 6B, an Environment tab enables a user to select viewing options to change the appearance of the display. In regard to the color coding display option, it is noted that the user can select not to have order information color coded by selecting color blind user. In such a case, other means of notation are utilized such as markings or symbols, as may be desirable if the user is color blind or using a monochrome screen display device 88. User defaults for Credit Group, Instrument Class and SWF Currency may also be selected via the environment tab.

At this point, it is worth noting several functionalities that are integral to the operation of the present invention. In particular, it was recognized that in order to achieve an electronic trading system for a wide range of financial contracts, a solution had to be developed to solve two very critical problems: (1) how to identify financial contracts, and (2) how to allow institutions to describe their credit preferences or relationships for these instruments. As solutions to these problems, the present invention provides the symbology and credit preference features described below.

The symbology of the present invention was developed because, unlike foreign currency trading, where the financial instruments are simple, verbally explaining all the terms and conditions of a derivative transactions can be a laboriously complex process which can take a relatively long period of time to explain. Furthermore, most derivative transactions are specifically customized to fit a particular need. With derivatives, as compared to stocks, bonds or other financial instruments, there are typically many more parameters, such as the maturity, fixed interest rate, floating interest rate, currency, floating rate index, and calculation rates, which are important and are preferably defined. This complexity has allegedly been one of major inhibitors to the development and implementation of an efficient inter-dealer electronic trading system for over-the-counter (OTC) derivatives.

The symbology will, among other things, ensure that the symbols are intuitive to the trading community, allow new symbols to be system generated when new instruments are introduced, and enable detailed confirmations to be prepared. These goals are generally accomplished by systematically dividing the parameters, terms, and conditions defining these derivatives instruments into a four-part subject code. This four-part subject code enables the users to reference these instruments via a form known as subject-based addressing. The four-part subject code is divided as follows: SOURCE.CLASS.SYMBOL.CURRENCY. Each field of the four-part subject code is defined below.

The source field of the symbology identifies the source of the information. In most cases, this will be the code DNI (i.e., Derivatives Net, Inc.), the assignee of the present invention. If the symbol is used within the system 10, then the source field of the symbology will be assumed to be DNI, and will be omitted. If the symbol is used in a larger context, then the source will be identified. If, for example trade data were to be distributed and accessed via a third-party data distribution system such as the type operated by Reuters, Inc., then the source field of the subject code would be used.

The class field identifies the principal product class into which the financial instrument falls. The class parameter is designed to group financial contracts together which share similar attributes. For purposes of the present disclosure, eleven classes of instruments, each with distinct characteristics covering forward rate agreements, interest rate swaps, interest rate basis swaps, interest rate options, foreign exchange and switches, will be covered. It is noted that a switch is the simultaneous purchase and sale of two instruments within the same class. The following is a listing of the eleven classes and the associated abbreviation for each:

FRA - forward rate agreement

SWP - interest rate swap

CAP - interest rate option (cap or floor)

SOP - interest rate option (swaption)

IBS - interest rate basis swap (floating vs. floating swap)

SPT - foreign exchange spot

FWD - foreign exchange outright forward

FXS - foreign exchange swap

SWF - FRA switch

SWT - switch any other pair of instruments in the same class

CBS - currenby basis swap

The symbol field is the principal code used to define each instrument. The symbol field is the most explicit field of the subject code. This component of the naming convention enables the underlying structure of the derivative instrument to be defined. A simple description (e.g., 1yrswap) could be used, but this does not allow new derivative instruments to be easily added. The legend below defines the parameters for defining each of the different instruments or classes. The symbol relies on the definitions of the underlying parameters, which will allow further break down or definition. For example, FLOPT is a two letter code which describes the variable rate index to be used, and will include: the designated maturity, index name, source, non-business day convention and calculation description. The symbols of the present embodiment are as follows:

FRA: [START, END, OVER, FLOPT]

SWP: [START, END, OVER, FXDBASIS, FLOPT, SPECIAL RULE]

CAP: [START, END, OVER, FLOPT, TYPE, STRIKE]

SOP: [START, OVER, UNDERLYING SWAP, SOPTYPE, STRIKE, OPTTYPE]

IBS: [START, END, OVER, INDEX1, INDEX2, ARREAR]

SPT: [CCY1(terms), CCY2 (base)]

FD: [CCY(terms), CCY2 (base), START, END, OVER]

FXS: [CCY(terms), CCY2 (base), START, END, OVER]

SWF: [FLOPT, DAY1, DAY2]

SWT: [ASSET1, ASSET 2, CLASS]

CBS: [START, END, OVER, INDEX1/CCY1, INDEX2/CCY2]

The symbol fields set forth above include the following parameters:

START: The START parameter is the month the contract commences offset from value date, i.e., 1,2,3, . . . ,13, . . . ,360. The default setting for the START is (0) which represents that a contract starting with the current month. Also, see OVER below.

END: The END parameter is the final maturity from value date in months adjusted for the OVER, and represents the term, i.e., 1,2,3, . . . ,13, . . . ,360. If the value date is 28th of November, then a contract defined as [1,4 over the 12th] translates into a deal starting on the 12th of January and maturing on 12th of April.

OVER: The OVER parameter represents a specific date in the appropriate month. For example, if today is the 3rd December (value date is the 5th of December), then a 1*4 over the 12th would start the 12th of January, the first date over one month but less than two months beyond the spot date. This allows a contract to be defined with any start date between days 1-31. Note that this represents the actual date and not the number of days forward. The default setting for the OVER is (0), which represents spot starting. Two other parameters are allowable: (I) which represents IMM (International Monetary Exchange) rolls (the system 10 covers the different IMM conventions defined by the currency market, that is, the third Wednesday or second Thursday) and (E) which represents rolls over the month-end.

FXD BASIS: The FXD BASIS parameter is a two-part code covering the frequency and the basis of the fixed coupons. Examples are FREQ: M=Monthly, Q=Quarterly, S=Semi-annually, A=Annually, Z=Zero Coupon plus BASIS F=A/365 Fixed, B=30/360, M=A/360, I=A/365 ISDA, etc. For instance, SM is semi-annual A/360 or semi-money].

FLOPT: The FLOPT parameter is a two-part code covering the frequency and the index type of the floating coupons, and represents the floating rate option as defined by ISDA. The FLOPT parameter covers frequency, basis and source. Although each currency may have a default, most indices will be available. FLOPT examples are L=Libor (TELERATE 3740/50), P=Pibor (TELERATE 20071), T=Tibor, C=CDOR, B=AUS Bills (REUTERS BBSW), FF=Fed Funds (HI5), TB=T-bills (H15), PR=Prime (H15), CP=30 day Commercial Paper, BE=BELO, S=STIBOR, TA=TAM, A=AIBOR, D=CIBOR (REUTERS DKNK), RL=Libor from Reuters LIBO, and IL=Libor from Reuters ISDA.

CAPTYPE: The CAPTYPE parameter includes definitions for cap (C) and the floor (F). Thus, in a preferred embodiment, the following code is utilized: C=Cap, F=Floor.

SOPTYPE: The SOPTYPE parameter includes definitions for payers (P) and receivers (R). Thus, in a preferred embodiment, the following code is utilized: P=Payers, R=Receivers, X=Call, Y=Pat.

OPTYPE: The OPTYPE parameter is the option type: (E)uropean, (A)merican or (M)ultiple European.

STRIKE: The STRIKE parameter indicates the cap or swaption's exercise rate or price set on the option. Any strike defined in the symbol as ATM (at-the-money) will be shown as such in this parameter. In such a case, the percentage or strike will be agreed through the term negotiated process discussed below.

SPECIAL RULE: The SPECIAL RULE parameter is designed for currencies such as USD and CAD which are in particular markets that use few special conventions for trading. For example, semi-bond for spread trades and annual money for out-right swaps are widely used in these markets. The SPECIAL RULE parameter allows the system 10 to set more than one set of defaults for any currency. This will allow the system 10 to know when the exchange of bonds is required following a transaction. The follow are the rules for the present embodiment:

A-Default in all currencies

S-USD spread trades. The default in USD is annual money versus 3 month LIBOR. This rule defines semi-bond spread trades where bonds are exchanged in the terms negotiation function described below.

2-CAD spread trades. The default in CAD is annual money (A/365 fixed) versus 3 month CDOR paid semi-annually. This rule defines semi-annual A/365 fixed versus 3 month CDOR paid semi-annually where bonds are exchanged in the terms negotiation function described below.

3-AUD long trades. The default for AUD is a quarterly/quarterly structure. This applies for trades up to and including three years. In trades over three years, the convention switches to a semi/semi structure. This rule supports a semi/semi structure.

4-AUD spread trades. Its is conventional to trade swaps in the AUD market against the bond futures contracts with an agreement for an exchange for physical.

5-GBP spread trades. The default in GBP is annual money (A/365 fixed) versus 6 month LIBOR. This rule defines semi-annual A/365 fixed versus 6 month LIBOR where bonds are exchanged in the terms negotiation function described below.

ARREAR: The ARREAR parameter defines when the coupon(s) on a swap is both set and paid. Most interest rate swaps set their floating rate coupons at the beginning of the period and pay them at the end of a coupon period. In an ARREAR swap, however, the coupon is set and paid at the end of the period. This is commonly referred to as an arrears swap. The system 10 allows for this in the form of a basis swap.

DAY 1/2: The DAY 1/2 parameter is the number of calendar days offset from today to the start of each FRA in an FRA switch (class SWF). Thus, the DAY1/2 parameter represents the setting day or date.

CCY1/2: The CCY1/2 parameter is the currency code and is defined by the ISO codes for foreign exchange instruments.

UNDERLYING SWAP: The UNDERLYING SWAP parameter is the full symbol, alais or security ID of the interest rate swap that underlies an option.

INDEX1/2: Basis Swaps are when both sides are a floating rate, and the index represents the FLOPT plus the currency code of each index. The first listed index (INDEX1) is paid by the buyer. Examples include 1L-USD, 3L-GBP, PR-USD, etc. The second index (INDEX2) is received by the buyer. These are substantially identical to the codes used in the switch mechanism 35 (FIG. 2). For currency basis swaps, it is assumed that an exchange of principals takes place at the start and end on the contract.

ASSET1/2: The class SWT is provided to allow for the trading of switches in other classes other than FRAs. ASSET1 and ASSET2 represent the symbol, alias or security I.D. of each underlying contract. Note that both should be provided from the same class of contracts.

SETTLE: The SETTLE parameter is a flag indicating whether a swaption is cash or physical settlement. The default is cash (C).

An example of an order in accordance with the symbology of the present invention is DNI.FRA. 1,4.0,3L.USD, where DNI is the source, FRA is the class, .1,4.0,3L is the symbol and USD is the currency. In particular, the symbol field defines a 1 by 4 (i.e., 3 month starting in 1 month) FRA on a 3 month LIBOR spot starting. Note that a comma (,) is used in the symbol fields as a delimiter. Another example of an order in accordance with the symbology of the present invention is DNI.SWP.0,60,0,AB,6LA.DEM, where DNI is the source, SWP is the class, 0,60,0,AB,6LA is the symbol and DEM is the currency. In particular, the symbol field defines a five year (60 month) annual bond (AB) versus a 6 month LIBOR swap.

Accordingly, the Symbology described above is designed to capture the parameters or commercial terms of a derivatives instrument which affect the instrument's valuation. The present invention provides a number of default values which are assumed at all times. For example, the following is an exemplary list of system default values.

ROUNDING: The rates observed on the source page or document will be used unless otherwise agreed. Rates should be rounded to 5 decimal places after any operation of averaging.

RESET DATES: This will be defined with reference to payment dates. The reset dates should be offset by the standard number of days for the currency, for example, two business days for USD.

BUSINESS CENTERS TO APPLY TO RESET DAYS: The business days used to define the current offset for reset dates is defined by the source and not the payments under the transaction. For example, London will always be used for LIBOR (the exception is for USD LIBOR which uses both London and New York City) and New York City for H.15 rates.

INTERPOLATION: Where interpolation is required, a straight-line method using the reference rates on either side of the desired date should be used.

CALCULATION PERIODS: First and not last convention. Therefore, the calculation period includes the first payment date but excludes the next payment date.

TERMINATION DATE: All termination dates will be subject to adjustment if they fall on a non-business day.

ADJUST CALCULATION PERIOD: The number of days is assumed to adjust if the payment days are adjusted for non-business days.

TRADE DAY: The trade day is defined relative to the instrument and currency by the system 10, and not by the location of either of the parties to the transaction.

NET PAYMENTS: Net payments will be assumed for all transactions completed through the system 10.

CANADIAN DOLLAR SWAPS: The convention is to set quarterly and pay semi-annually using weighted averaging and compounding at the first rate.

DATES: All dates are listed unadjusted for non-business days.

Users may also want to be able to negotiate other parameters which do not affect the valuation of the derivative instrument, but are still very important. These parameters are referred to hereinafter as non-commercial terms. The difference between commercial and non-commercial terms can be vary ambiguous, and therefore, some of the terms designated as commercial below may be designated as non-commercial and become default settings so as to be part of the symbology parameter. For purposes of illustrating the present invention, non-commercial terms have been given default values which the users can change by negotiating new values for these terms between themselves via the system 10. However, both counterparties (users) must agree on the new value to over-ride the system defaults. Table I below provides a list of parameters that maybe negotiated, that is, the non-commercial terms:

    TABLE 1
    PARAMETER     DESCRIPTION                  SETTING
    Legal         The format of the legal agreement ISDA, BBA, FX
                  used
    Month-        Whether coupon payment dates YES, NO
    end           roll on month-end dates or not
    Settle        For swaptions whether the contract CASH, PHYSICAL
                  is cash or physically settled
    First         For swaps the first variable rate is SETTING
    Setting       normally known for spot starting displayed on
                  instruments. The current setting market entry
                  can quickly become off market on interface.
                  days where the market moves
                  substantially. The system will
                  display the default at all time.
    ATM           For options, symbols will be set up The system forward
                  where the strike is defined as at- rate will
                  the-money (note: pre-defined be available
                  strikes will also be available). The
                  actual strike will be negotiated
                  immediately following the
                  transaction by the two parties.
    Spot          For foreign exchange swaps (class The system mid
                  FXS only) where the price is spot price will
                  transacted in the form of points, be available
                  the spot level to be used will be
                  negotiated immediately following
                  a transaction.
    Base          Switches will be transacted in the The system mid
                  form of the relative price between price will
                  the two instruments being    be available
                  switched. The base rate maybe
                  negotiated immediately following
                  a transaction.
    Bond          For USD, CAD and GBP interest The system will
    Exchange      rate swaps transacted as a spread, list the benchmark
                  the price and number of bonds will bonds to be used
                  be negotiated immediately    and will calculate a
                  following the transaction    default price and
                                               number according to
                                               market convention.

            Triangle 212      Triangle 214      Color
            False             False             RED
            False             True              YELLOW
            True              False             RED
            True              True              GREEN

    TABLE 2
    Preference
    Type        Maximum Maturity
    Binary No   -2.sup.31, the smallest possible integer value
    Binary Yes  2.sup.32 - 1, the largest possible integer value
    Line Binary The maximum maturity associated with the preference
                (e.g., Line Binary/12 has a max maturity of 1200)
    Complex     The maturity of the highest band with an exposure amount
                greater than zero.
                (e.g., The following complex preference would have a max
                maturity of 6000)
                Mat Band    Exposure
                 100        10,000,000
                 600         5,000,000
                1200         3,000,000
                3600         1,000,000
                6000          500,000
                2000              0

        Business unit of trader placing order: business unit (1)
        Legal entity of trader placing order: legal entity (1)
        Maximum Maturity of order:         3600 (for example)

    TABLE 3
    MY_PREFS               OTHER_PREFS
    PREFERENCE             PREFERENCE
    max maturity >= 3600 max maturity >= 3600 Color of Order
    false                  false                red
    false                  true                 red
    true                   false                yellow
    true                   true                 green