Systems for switch auctions utilizing risk position portfolios of a plurality of traders6996540Abstract A switch engine module receive interest rate risk portfolios from a plurality of traders, and for each prospective trader, provides available switches based on positions in other counterparty portfolios that offset the viewing traders' positions. The offsetting positions are encoded with credit preference information in order to identify eligible trades based on both counterparties credit preferences. In particular, an embodiment provides for a switch auction whereby users can use an auction process to trade for forward rate agreement switches with other counterparties. In the switch auction, the price is predetermined by the system prior to the auction so that parties can opt out of the transaction if desired. The credit preferences of the participating traders are taken in consideration in making matches. Claims That which is claimed is: Description FIELD OF THE INVENTION
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 create 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/switch 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 a relational database 66 resides on the hard disk 64 for maintaining information such as current state information for each trade workstation 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 20 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® (Netscape Communication Company) or Microsoft® 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 10 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™ (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:
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., lyrswap) 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:
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=Put. 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:
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. INDEX 1/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, 0.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 1 below provides a list of parameters that maybe negotiated, that is, the non-commercial terms:
Because the above symbols that comprise the subject-based addressing may be complex, users may occasionally desire a simpler naming convention to reference the more commonly traded derivative instruments. To facilitate more rapid referencing of an instrument by a user, the symbology of the present invention provides aliases. An alias is merely an abbreviated version of the subject-based address for the more commonly used terms for an instrument. The database 66 (FIG. 2) maintains a unique security identifier (such as a numeric code, e.g., 111222) for each symbol which can be used in the system 10. Thus, the symbology of the present invention enable traders and other users of the system 10 to quickly reference a particular derivative instrument in the system 10 in three ways: the full symbol, the alias, and the identifier. The currency field of the symbology contains the code that defines the currency of the instrument represented. In a preferred embodiment, the currency code is represented by the standard ISO currency codes, i.e., USD, DEM, JPY, GBP, FRF, NLG, BEF, AUD, CAD, ITL, ESP, DKK, SEK, EUR, etc. The default currency will be set by each user in each user's preferences interface 143 (see FIG. 6B). This will allow the currency code field of the symbology to be omitted much of the time. However, foreign exchange trades (FXS) preferably include the currency code. Further, the currency code represents the currency which will be indexed in equal amounts for both the spot and forward coupons. The credit preference feature of the present invention provides for the bilateral credit status between two entities to be captured, structured and used anonymously for the trading of a wide range of financial contracts. In prior art systems, credit information was primarily used to deal with settlement risk in trading spot foreign currency. In such prior art systems, the credit line or limit is usually expressed in amounts of currency which equates with the quantity or volume of a particular trade. As trades are executed between counterparties, the amount of the limit is decreased in a corresponding amount to the trade executed until there is little or no remaining credit, and then further trading is prevented until the trades settle or the credit limit amount is re-set. In foreign currency trading, the settlement process is completed in only a few days, after which both counterparties have exchanged the currencies, and then there is no further credit risk between them (i.e., the trades have settled). This is vastly different from derivatives trading, where the amount at risk is normally not equal to the principal or quantity of the transaction and the obligations under the contract may continue into the future. Derivative trades can be anything from spot (the normal settlement of a foreign exchange contract) to thirty years into the future. Therefore, the resulting credit exposure (i.e., the value of a contract at a future time) is over the life of a contract of an unknown amount. The credit preference feature of the present invention is configured to handle the significant long-term credit problems inherent in over-the-counter (OTC) derivatives transactions. These long-term credit problems are further compounded by the fact that there is no standard method for banks to internally monitor and manage their credit risks. Most banks have developed their own, often proprietary, methods of monitoring and measuring the credit risk embedded in large portfolios of derivatives. Furthermore, banks also have different methods for dealing with the many different financial instruments that exist in every market. The credit preference feature of the present invention addresses these problems and provides a viable solution. The credit preference feature of the present invention achieves this, at least in part, by introducing a measurement unit of credit risk referred to as risk equivalent (RQ) which allows for different instruments to be compared on a like basis using a standardized measuring methodology, which together with the concepts of contract maturity, credit groups, classes, credit preferences, legal entities and business units allow the system 10 to offer a solution to the credit risks embedded in bilateral, term derivatives contracts. The present invention also provides for the designation of credit groups. A credit group is a grouping of classes of financial contracts that a business unit wishes to be treated in a like manner for credit purposes. In a preferred embodiment, three default credit groups will be available: (1) Derivatives—SWP, IBS, CAP, SOP, FRA; CBS (2) Switches —SWT, SWF; and (3) foreign exchange. Any other combination may be set up by the business unit, as desired. Credit preferences are the methods or rules selected by a business unit within a credit group for the system 10 to use to screen prices (bids or offers) and trades against all other legal entities. In a preferred embodiment, the following three credit preferences are provided, though it will be appreciated by those of ordinary skill in the art that other credit preferences may be utilized in accordance with the present invention:
In the binary method, a business unit makes a yes or no determination as to whether or not they will deal with a particular counterparty for a particular credit group. In this credit preference, the decision is binary; there is no maximum maturity limit (i.e., time limit) or quantity limit (i.e., amount) in the binary method. The binary method is the broadest of the three credit preference definitions provided for herein. Typically, the binary method will be used to refuse credit, where MTM agreements exist or where the credit exposure is small (for example, in switches). In the line binary method, it is assumed that the business unit will deal with a particular counterparty for a particular credit group. However, the line binary method adds a further restriction of a maximum maturity of any contract tradable. The added restriction is preferably expressed by the number of months into the future. The binary method is particularly well suited for used by institutions that are not yet using RQ units, but which desire a method to limit potential exposure to longer dated contracts (for example, a temporary step). The complex method allows each business unit to exactly stipulate the amount of new risk that they are prepared to enter into with any other legal entity for each credit group by maturity band. The complex method enables a business unit to specify not only a particular maturity, but also a particular quantity or amount based on a measure of RQ. Further, the complex method enables the business unit to specify this for more than one period in time. For example, a business unit can specify that for Bank A, they will do up to $100 million out for 5 years, and then only $50 million from thereafter out to 10 years, and nothing thereafter. Risk is generally defined herein as the degree of uncertainty of future net returns. Credit risk is further defined as an estimate of the potential loss due to the inability of a counterparty to meet its obligations. Thus, while the risk in a particular transaction depends not only on the changes in market rates and credit standing of the counterparty to the transaction, the credit risk or exposure is the nominal amount that can be lost when a counterparty defaults on its obligation. As previously mentioned, the credit risk in a derivatives transaction is relatively complex. For instance, though derivative contracts come in many forms, the majority have a fair credit value of zero at the time the transaction is initially entered into. That is, no funds are transferred between the parties at the time the contract is created. Rather, the contract places an obligation on both over the term of the contract. Further, both parties are entering into a contract which requires them to accept a certain amount of risk. The RQ is a unit of credit risk which allows all contracts to be compared on a like basis, at virtually any point in time. The RQ is the credit exposure in terms of a percentage of the principal. The calculation of RQ is based on the potential exposure averaged over a series of time points, weighed by an appropriate discount factor. There are several methods of calculating the exposure of a transaction, though the RQ is calculated herein using an option pricing approach, as described below. For a certain party, a transaction can be viewed as two opposite cash flows. Inflows are assets, denoted by A(t), and outflows are liabilities, denoted by L(t). Therefore, the current exposure may be expressed as follows: E(t)=max(A(t)-L(t),0) This formula is similar to the intrinsic value of a call option. The key difference is that both A(t) and L(t) can be random. Thus, following the same structure by the Black-Scholes, then: EE(t)=Aφ(d1)-L(t)φ(d2),
Thus, the RQ can be expressed as: ##EQU3## where ##EQU4## where ##EQU5## where δ(t) is the discount factor at future time t. For FRA's, the following equations apply: A(t)=*discountFactor(t,s)*x+(1+floatingCoupon)*discountfactor(t,e) where floatCoupon=1*(e-s)/floatBasis*floatRate, and L(t)=1*discountFactor(t,s)*x+(1+fixCoupon)*discountfactor(t, e) where fixCoupon=1*(e-s)/fixBasis*fixRate, Then we can apply the above formula for RQ to get the expected exposure at time t. By choosing the time partition t0,t1,t2 . . . ., tn and calculate the expected exposure at each point and use the formulae of RQ, the RQ of this FRA can be calculated. For SWAP's, the following equations apply for any time (ti<t<=ti+1): ##EQU6## and ##EQU7## where floatingCoupon(tj) is the floating coupon at time tj, and fixedCoupon(tj) is the fixed coupon at time tj. Then apply the formulae of option pricing approach, we can get the expected exposure at time t, by averaging the expected exposure with the discount factor, the RQ can be calculated. At this point it may be worthwhile to distinguish the credit preference feature of the present invention from other known systems. The credit preference of the present invention does much more than merely monitor the amount transacted between two counterparties and then reduce the amount available accordingly. The prescreening performed by the credit preference of the present invention is used to prescreen possible trades based on each counterparty's credit preferences. The present invention does not control a user trading and does not directly limit the user's future trading based upon the user's past trading. In fact, it is quite possible that a new transaction may reduce the exposure between two legal entities. A user's business unit is responsible for monitoring the credit exposure of the business unit with respect to all legal entity counterparties, and for adjusting the credit preferences in the system 10 accordingly. This is a significant difference from prior art systems that automatically decrease the amount available to trade with respective counterparty as transactions are executed. The credit preference of the present invention represents an improvement over such systems because the balance of risk is based on the total portfolio between the two parties and not merely the new transactions, and the balance of risk will be affected by market movements, deals executed outside the system 10, and internal changes to the ratings. Credit decisions for OTC derivatives are considered different from many other financial instruments. In general, a credit decision for an OTC derivative is a function of, among other things, the composition of the user's current derivatives portfolio, the current level or prices of the financial markets, new financial transactions, and the rating or level of credit worthiness of each legal entity. Therefore, more sophisticated means such as the credit preference prescreening of the present invention is needed to adequately measure and manage credit exposure in the OTC derivatives market, as well as with other financial markets. The present invention enables the user to set desired credit preferences for each legal entity via the credit preference interface 170, as illustrated in FIG. 7. A user can navigate to the credit preference interface 170 by selecting the credit settings button in the tool bar 132 of the command center interface 130 (FIG. 5). The credit preference interface 170 enables the users to view and/or update credit preference settings in a clear, simple, comprehensive and intuitive manner. The credit preference interface 170 may be used to view or input/amend the business unit's credit preferences. The credit preference settings are preferably only viewable by users within a business unit, and amendable by users with the correct permissions, both of which may be designated by the financial institution or the business unit. A business unit may also select to inherit credit preferences from another business unit within its family hierarchy. In a preferred embodiment, the credit preference interface 170 includes a display window 172 that displays various information including an alphabetical listing of all other legal entities (i.e., financial institutions) that have access to the system 10. Each legal entity can be expanded via an expand button 174 to list the settings for all the credit groups that the user has selected to trade within that legal entity, as shown for the Merrill Lynch entry. For those legal entities that are not expanded in window 172, the settings displayed are for a designated default credit group The user can modify the displayed credit groups by selecting the Modify Credit Groups button 178 which launches the modify credit group interface 180, as illustrated in FIGS. 8A and 8B. The modify credit group interface 180 enables the user to customize his/her class groups by providing functionality to perform such operations as adding and removing instruments from a class group, as illustrated in FIG. 8A. For instance, for a selected credit group 182, a list 183 of instruments in that credit group is provided. Unassigned instruments can be added and member instruments can be removed. Further, credit groups 182 can be added and deleted via buttons 182, 185, respectively. In FIG. 8B, each credit group 182 may have bands of maturity 186 defined (i.e., added or deleted). Each class group preferably includes instruments that are closely related because the instruments in each class group are given the same credit preference setting, and therefore, the credit preference setting process may be simplified. Referring back to the credit preference interface 170 of FIG. 7, a preference setting column 187 provides the credit preference setting designated for the corresponding legal entity 183. The credit preference settings for any legal entity can be modified or selected via a drop-down dialog box 188. From the drop-down dialog box 188, the user can select from a list of predefined credit preference option. For a new line binary, the user is prompted with a new line binary interface 189 in which the user can enter a maturity. For complex, the user is prompted with a complex preference interface 190 (FIG. 9B) in which the user can enter the exposure for each maturity band. With reference back to FIG. 7, the complex credit preference settings and the RQ may be provided for each instruments designated as such by selecting an appropriate legal entity and then selecting the Complex Bands button 194. If the user does not set a particular preference for a particular counterparty, then the credit preference will be assumed to be a simple binary (no). If after initially setting these preferences a new counterparty is added to the system, the preference for the new counterparty will be binary (no) for all users until they have specifically set a credit preference for the new counterparty. The level column 196 displays the business unit's designation for each legal entity as to the levels A, B or C. The level set for each legal entity may be provided by the system 10 via various interfaces such as a market detail interface (described below with reference to FIG. 15) to provide the trader with information with regard to the creditworthiness of the counterparty. Thus, a business unit may assign one of the levels A, B or C against each legal entity. This is essentially a quick reference of credit worthiness for the user. The columns 198 labeled S&P and Moody are industry credit ratings that are integrated into the credit preference interface 170. The industry credit ratings may be downloaded on a subscription basis via external communication interface link interface 62 (FIG. 2). Lastly, the last modified column and the modified by column identify the time and person that last modified that credit setting. As mentioned before, access to modify any of the credit preferences should be limited to a finance officer or credit officer of the legal entity. It should be noted that the credit preference settings may be transferred via electron file transfer or inputted manually on-line at anytime, and as often as the user desires. Further, updates may be made for all credit groups and legal entities, or alternatively, updates can be just for individual settings. In addition, the credit preferences interface 172 includes a BU Info button 202 which, if selected, brings up a business unit data interface 204, as illustrated in FIG. 10. The business unit data interface 204 enables the users to view helpful internal information about other legal entities. The respective business units define what information is included in the business unit data interface. For example, the business unit data interface 204 of FIG. 10 provides the internal facility number, telephone number, internal reference number, internal net MTM, internal gross MTM, and internal number deals of a business unit. Alternatively, a business unit may include a contact name or other business unit specific data. Accordingly, the credit preference logic of the present invention can be illustrated graphically as shown in FIG. 11. For purposes of FIG. 11, it is assumed that business unit (i) belongs to legal entity (i) where i=1, 2, and 3, and business unit (j) belongs to LE (j) where j=1, 2, and 3. Accordingly, FIG. 11 illustrates a portion of the credit data which is stored by the system 10 in order to implement the credit preference feature of the present invention. Each column represents the credit preference (i.e., binary, line binary, or complex) which is stored anonymously for each business unit against each legal entity across all credit groups. The vertical and horizontal bars 210 represent the information which business unit (3) requires to determine the credit preference status of an order. The information in columns 210 provides the credit preferences which business unit (3) has set against all other legal entity, and row 211 provides the credit preferences which all other business unit s have set against business unit (3)'s legal entity, that is, legal entity (3). The depth 216 of the graph is divided into the different credit groups such as switch, derivative, and foreign exchange. The triangles 212, 214 mark the cells that include the information which is used by business unit (3) to encode a specific order from business unit (5) of legal entity (5) with credit status information for presentation to the user via one or more of the interfaces described herein. In a preferred embodiment, the credit preference feature of the present invention color codes the credit preference status of each order from the perspective of the viewing business unit. Alternatively, another method of encoding the credit preference status of an order may include adding a character notation such as an asterisk or star to an order, as may be desired if the user is color blind. Each order is color coded according to the credit preferences marked by the triangle 212, which corresponds to what the order placer's business unit has set against business unit (3)'s legal entity, and the triangle 214, which corresponds to what business unit (3) has set against the order placer's legal entity. The order is evaluated according to the credit preference defined in the cells marked by the triangles 212, 214, and the results can be displayed to the user via the color coding scheme set forth below where true means that the order passes the credit preference of the setting party and false means that the order does not pass the credit preference of the setting party:
Thus, each order is color coded to communicate to the user the tradability of the bids and offers in the market based on the preferences of both users. The color coding methodology described herein is used in both the market entry interface (described below with reference to FIG. 12) and the market detail interface (described below with reference to FIG. 15). For the present embodiment of the invention, the following meanings are associated with the cited colors: GREEN: The price passes the credit preferences of both parties, and the counterparties are free to trade. Any trade that is shown in green can be freely traded by the trader, and credit approval is assumed to be in place. YELLOW: The price posted is free to trade by the viewer, but the poster of the price has excluded the viewer from his/her credit preferences. If the price is colored yellow, a deal may be allowed provided that the party who placed the passive order allows mutual puts, and the credit over-ride process which is described below is completed. The viewer can attempt to trade by sending a message (thereby initiating the credit over-ride process) to the poster of the price which discloses the name and/or identity of the viewer, along with a mutual put maturity entered by the viewer. The poster then has the opportunity to accept, accept subject to credit (in either case, the poster may also reduce the maturity of the mutual put), or decline. The poster's name will not be released to the viewer until a trade is executed. The posted price will remain available to all other traders on the system 10 until a trade is completed. If the order trades to another viewer, then the credit over-ride process will be terminated. RED: The price posted is excluded by the viewer's own preferences even though the poster is (may be) clear to trade. In this situation, the viewer is not free to trade since it is the viewer's own credit preference that the viewer set which is preventing the trade. BLUE: The price is the viewer's own order. WHITE: Only used in the market entry interface 250 (FIG. 12) to display prices where there are multiple orders at the best price with differing codes. Thus, the viewer is notified to view the market details interface for more information. In the over-ride process mentioned above, if the viewer sees a price coded yellow that he/she wishes to trade, then the viewer may activate the over-ride process. The over-ride process begins by prompting the posting party with a request for an order quantity. The message sent to the poster essentially states that the viewer, which is identified by name in the message, wishes to trade a stated quantity and that the receiving party has a stated period of time to respond, for instance, 15 seconds. The viewer will then see a copy of his/her message and a clock which displays the countdown of the stated time to the poster. The poster receives the message and can decline or accept. If the poster declines, then the viewer is informed accordingly. If the poster accepts, then the poster has the option to add a mutual put maturity, which will be stated in a specified number of months. The viewer cannot back out of the trade while the clock is running. Further, at no time is the poster in a trade until all steps are complete. The process by which passive orders are color coded is described at this point. Regardless of the credit preference type, the trader workstation 20 generates a maximum maturity value that determines how an order will be color coded. The maximum maturity value is in the form of an integer n digits in length, with the right-most two digits representing days, and the left (n-2) digits representing months. Therefore 12000 represents 10 years, 3600 represents 36 months, and 114 represents 1 month, 14 days. The method by which credit preferences are converted to a maximum maturity value is represented by Table 2 below.
Every instrument in the system 10 possesses a maximum maturity value. To determine whether a particular order can be traded, the maximum maturity for the order's instrument is compared to the maximum maturity of the credit preference. If the instrument's maximum maturity is greater than that of the credit preference, then the order may be traded, otherwise it cannot be traded. Note that the maximum maturity assigned to a Binary-No preference will be lower than that of any instrument, effectively making all instruments untradeable. Likewise, the maximum maturity of a Binary-Yes preference will exceed that of any instrument. In order to determine the appropriate color code, the trade workstation 20 maintains two lists for each instrument class. One list includes the credit preferences that the viewer has set against all other legal entities for that instrument class. This list may be referred to as MY—PREFS. The other list includes the credit preferences that all other business units have set against the viewing legal entity for that instrument class. This list may be referred to as OTHER—PREFS. Each of these lists contains the following data:
Consider, for instance, an order for an arbitrary FRA instrument placed by business unit (1) of legal entity (1). When the order is broadcast out to a plurality of traders 20 (i.e., viewers), the order will include the following information:
Also, note that the MY PREFS list may contain a credit level (e.g., which may be associated with the order and presented to the viewer. Accordingly, when the user logs into the system 10, the user populates the MY—PREFS and OTHBR—PREFS lists for the instrument classes for use by the credit preference module 76 (FIG. 3). This is achieved by the central processing center 12 sending to A trader workstations 20 that is logging-on one or more messages including the MY—PREFS and OTHER—PREFS lists from the database 66 on the hard disk 64 (FIG. 2). When a user changes a credit preference assigned to a legal entity for a particular credit group in a way which causes the maximum maturity of the credit preference to change, the user will receive updates to MY—PREFS from the central processing center 12. Also, any user within the affected legal entity who is logged on to system 10 will receive an update to OTHER—PREFS. Changes to complex preferences do not require such an update unless the zero band is changed (thus modifying the maximum maturity). If the user changes the credit level associated with a legal entity, the user will receive an update to MY—PREFS. However, these two updates should not be performed at the time the changes are made, as doing so could allow a user to determine the legal entity that placed an order by methodically changing his/her credit preferences against each legal entity from a green state to a red state until the order changed color. Instead, the required updates will be collected and sent out on an periodic basis. Also, to discourage discovery of a counterparty's identity by assigning a unique credit level to a single legal entity, each credit level should be assigned to either no legal entity, or to more than one legal entity. From the command center interface 130, a user may enter the market entry interface 250, as illustrated in FIG. 12. At the market entry interface 250, the user can simultaneously monitor numerous markets and place orders, including bids and offers. The market entry interface 250 also allows the trader to select any instrument(s) to be displayed, and multiple market entry interfaces 250 with various trading functions (e.g., common FRA on one interface, SWAP on another interface, and Switches on yet another interface) may be opened on the trader's desktop simultaneously. The market entry interface 250 is designed to present the sum of the best bid and ask, and the act of trading by any two parties by a flashing volume indicator in the top right-hand corner. Thus, the market entry interface 250 enables a trader to easily monitor many different markets with relative ease and utility. It should be noted that the system 10 does not perform auto-matching of orders, but allows the user to maintain control of the trading process at all times. The system 10 does this by introducing the concepts of active and passive orders. A passive order is an order placed in the system 10 for a particular instrument, for a particular quantity, at a specific price, for a particular time period (see order types below). An active order is when a user decides to trade a passive order displayed in the system 10, and is usually only required to provide the quantity. Thus, there can be active or passive bids and offers. The user may customize the market entry interface 250 by adding and removing instruments (i.e., markets) displayed in the instrument display window 252. The user may add new markets by entering an instrument symbol (according to the symbology of the present invention) into instrument identifier field 254. The user may also want to define groups of instruments which can be saved as profiles and viewed together. Profiles allows the user to organize multiple markets by like attributes. The profile being viewed is displayed in the profile display field 256. The profile display field 256 is a pull down menu that lists the other profiles defined by the user. Until the user defines a first profile, the profile display field 256 is set to default. Individual markets displayed in the instrument display window 252 are divided into four columns: instrument, best bid, best ask, and info. The instrument column displays the instrument name (i.e., the symbol, alias or a security identifier). The best bid column displays the best bid information, defined herein as the orders that are at the best price. The best bid information includes a relatively large central number that displays the least two significant digits of the price, a bottom left number that displays all but the least two significant digits of the price, a bottom right number that displays any volume or quantity currently trading, and a top right number that displays the quantity of currency units in millions. Depending on the precision desired, a greater or lesser number of digits can be displayed as the larger central number. The precision of the displayed central numbers is defined for each instrument, and may, for example, include 2, 3, 4, or more digits. The best ask column is substantially identical in format to the best bid column, but displays the best asking price rather than the best bid price. The info column provides space for data items that the user may select to view, as defined in an info window 258. In the present embodiment, three items are defined in the info window 258, and thus, the corresponding information for the instrument will be listed in the info column. The system 10 provides users with a symbol construction interface 270, as illustrated in FIG. 13, that can be accessed via a Lookup button 272 from the market entry screen 250. The symbol construction interface 270 functions to aid the user in selecting instrument for display in the instrument display window 252. From the symbol construction interface 270, the user can view available aliases in window 273, explode a symbol (i.e., view a list of underlying parameters associated with the symbol, for example, payment date) via the Explode Symbol button 274, select symbols to be added to a profile via the Add to Profile button 276, and construct new symbols or aliases via the Build Symbol button 278. The symbol construction interface 270 also provides error checking such that only valid symbols can be selected. An instrument should exist in the database to be valid, and not all combinations will exist. For additional verification, the symbol explode function of the Explode Symbol button 274 enables essentially all aspects of the instrument to be displayed in detail. Thus, the explode symbol feature provides a complete detailed description of the instrument in Symbol window 280. The symbol construction interface 270 screen also enables the user to search for groups of symbols by at least partially filling out the input parameters 282 located above a Search Options button 284, and then selecting the Search Options button 284. The input parameters 282 include various non-commercial terms of an instrument that can be negotiated following a transaction. For instance, as shown in FIG. 13, the input parameters 282 include class of instrument, currency, start month, end month, over, FLOPT, and special rules. By at least partially filling in these parameters, the user can search for similar instruments which are displayed in window 280. Referring back to market entry interface of FIG. 12, it is noted that the prices displayed in the best bid and best ask columns are encoded with credit information using the color scheme described above. As previously mentioned, color-blind users can have the color coding scheme replaced by a symbol scheme in which different symbols are positioned next to the respective prices to indicate the credit status of the order. The symbol scheme may be chosen by the user under the Environment tab of the preference interface 148 (see FIG. 6B). It should also be noted that the inventors of the present invention are not presently aware of any electronic trading system that offers color-based credit preference pre-screening such as that disclosed herein. The present invention provides color-based credit preference pre-screening because, unlike the prior art systems which only show the best dealable price or the best minimum quantity, the present invention shows all prices (bids and offers), irrespective of their credit preferences. Thus, the user can be provided with as wide of a view of the markets as the user desires. Advantageously, the color coding enables the user to visually determine virtually instantaneously what bids and offers are tradable based on the credit preferences of the trader and the counterparty. Once the user has entered the desired financial instruments in the market entry interface 250 via the symbology, the best bid and offers for each of the desired instruments will be displayed in the instrument display window 252. The best bid and best offer prices display in window 252 are different from many prior art systems because they are the absolute best bid and best offer at the stated quantity. Because of the unique color coding scheme, the user is able to quickly tell whether or not the bid or offer is tradable by him/her. If the user so desires, the user can select a financial instrument with the pointing device 86 (FIG. 3), such as a mouse, so as to highlight the row in the instrument display window 252 for that instrument. Once the financial instrument is highlighted, the user may perform one of several functions provided for by the function bar 290, each of which is described below: EXPL Function: This explodes the instrument symbol into a full description of the contract, and mirrors the confirmation. HIT, LIFT, ORD Functions: These three buttons allow a user to select an instrument and then place a new order, or execute an active order, by hitting or lifting the desired respective bid or offer. The HIT, LIFT, ORD functions can also be carried out by double clicking the mouse in the screen itself. RFP Function: request-for-price messages are an important tool to allow the market to communicate. If a trader wishes to see a market, a broker will be contacted via the telephone, and the broker will in turn phone other traders to drum up interest. Using the system 10 of the present invention, the same result can be achieved instantaneously by sending an RFP to all registered users. This message may be displayed in the command center interface 130 of other users, informing them of a RFP in the named instrument. In addition, because derivatives traders are often trading more than one financial instrument, and sometimes in more than one currency, derivatives traders will often have multiple passive orders. The present invention provides at least three order management functions to facilitate the canceling or temporarily suspending the order. This may be an important functionality when the market is moving quickly, or if the position of a trader suddenly changes. XLST Function: This function cancels the last passive order placed by the trader. Therefore, if a user submits an order and immediately changes his or her mind, the order can be canceled without the need to select the order individually. XALL Function: This function allows the user to cancel all his or her outstanding passive orders in one key stroke. REF Function: This function allows the user to suspend or place all orders under reference. This is an alternative to canceling orders one by one. For instance, if a user is expecting news that may affect only a few outstanding orders, it may be safer to place all orders under reference, and individually re-release the orders the trader expects not to be affected back into the market. DEL Function: This function allows the user to delete a market from the profile. In specific regard to the ORD button in the function bar 290, a user can submit a passive order by selecting the ORD button. If the ORD button is selected, a passive order interface 294 is provided to the user, as illustrated in FIG. 14A. From the passive order interface 294, the user can place a passive order such as a bid (i.e., buy) or an ask (i.e., sell). The user enters a price, quantity, and selects how long the order will be good. The price will default to current market level so the user may only need to enter the last two digits of the price. For quantity, the system 10 recognizes m, mm and b for thousands, millions and billions, respectively. The system 10 allows the following order types to be entered under the good until option: good until logout (default)—Requires the user to be logged on and to monitor the orders status. good until time—The user will be prompted to enter a time (in his or her own time zone). This order does not require the user to be logged on and will be canceled automatically by the | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||