US20090076943A1 - Systems and Methods for an Online Credit Derivative Trading System - Google Patents

Abstract

A credit derivative trading system comprises a credit derivative authority configured to receive defined positions for credit derivatives and update a plurality of trade clients in real-time whenever there is movement in the market for a particular credit derivative.

Description

RELATED APPLICATIONS INFORMATION
• This application claims priority under 35 U.S.C. §120 as a continuation-in-part to U.S. patent application Ser. No. 10/316,167, entitled, “SYSTEMS AND METHODS FOR AN ONLINE CREDIT DERIVATIVE TRADING SYSTEM,” filed Dec. 9, 2002, which is incorporated herein by reference in its entirety.
BACKGROUND OF INVENTION
• 1. Field of the Invention
• The field of the invention relates generally to credit derivatives and more particularly to the transacting in credit derivatives in an online environment.
• 2. Background
• Currently, conventional credit derivative markets comprise a user base of larger institutions. These large institutions use the credit derivative markets for a variety of reasons. For example, commercial banks, both domestic and foreign, can obtain significant economic, regulatory, and capital relief from selling credit risk in a credit derivative market. Commercial banks can also use the credit derivative markets to add credit risk to their portfolios as an alternative to the lending market. Insurers, which typically posses excellent credit evaluation skills, primarily use the credit derivative markets to take on credit risk for a premium. Investment management companies and Hedge Funds, or other investors, use the credit derivative markets to both take on and shed risk.
• The dealer community represents some of the largest financial intermediaries in the world. The dealers tend to be large, multi-national institutions that make markets in credit derivatives. The scale and scope of each dealer's credit derivative business varies widely, with some dealers having extensive credit derivative operations, and other being occasional market participants. Thus, in conventional credit derivative markets, information flow is concentrated in a few dealers. Generally, the end users, such as those described above, transact through the dealers and not directly with each other. Often, information is scarce and incomplete as it relates to the buyers and dealers participating in the market, as is information concerning price and the risk associated with particular derivatives.
• Dealers transact with other dealers via a broker market. A broker is an intermediary that transacts business between dealers. The brokers do not principal risk. Generally, information dissemination from the brokers is very inefficient. Further, the brokers business is limited to the dealers, because there is no meaningful contact between the brokers and end users.
• There are other drawbacks to conventional credit derivative markets. One such draw back is that conventional credit derivative markets tend to be regionalized, e.g., with individual markets being localized by continent and/or time zones. For example, the U.S. credit derivative market tends to trade strictly in U.S. credit risk, while the European credit derivative market usually trades in European credit risk. Due to the manual and labor intensive nature of conventional credit derivative markets, it is very difficult for dealers to break down the localized nature of conventional credit derivative markets.
• Another drawback is the high cost to transact in a conventional credit derivative market. Each dealer in a conventional credit derivative market tends to employ large intermediary infrastructure to facilitate the transactions. The size of the infrastructure leads to large transaction costs, which will remain as long as conventional credit derivative markets remain regionalized and controlled by just a few dealers. Further, because information is concentrated in the hands of a few large participants, conventional credit derivative markets are inefficient and illiquid. The illiquidity persists because for many of the largest participants, their only transactional outlet is through the dealers. Traditionally, another drawback is operational inefficiency that results from a lack of standardized documentation. The operational inefficiency is made worse by the fact that the documentation processes involved tend to be manual processes, which is also in part due top the lack of standardization.
• Another drawback that will be mentioned here is the inefficient, fragmented, and disjointed distribution mechanisms of conventional credit derivative markets. When a market participant wants to transact, they will call one of a few dealers to ask for a price. Dealers usually will go through a broker at this point. Alternatively, the dealer will often call a limited number of other possible participants to determine if they are willing to transact. If the dealer determines that they are likely to find a willing participant at an acceptable spread, then the dealer will likely try to consummate the transaction, e.g., using a broker. Frequently, however, multiple dealers are calling the same potential participants trying to determine a willingness to transact. As a result, potential transactions are often selected out of the market because participants have few outlets, the dealer feels that the fee to consummate the transaction is too low, and/or the dealer will not principal the risk because they fear they will not be able to find a willing participant on the other side of the transaction. Consequently, while a few participants benefit from the economic inefficiencies of conventional credit derivative markets, many do not.
• Another difficulty in trading credit derivatives occurs when a dealer or buyer desires to trade significant notional of credit derivatives. A desire for a large transaction can influence the market in a manner adverse to the trader.
SUMMARY OF THE INVENTION
• A credit derivative trading system comprises a credit derivative authority configured to receive defined positions for credit derivatives and update a plurality of trade clients in real-time whenever there is movement in the market for a particular credit derivative.
• In another aspect of the invention, the credit derivative trading system comprises a standardized interface that allows trade clients to view information on credit derivatives in a compact and uniform format. The standardized interface also allows the trader clients to interface with the credit derivative authority in quick and efficient manner.
• In another aspect of the invention, the credit derivative trading system is configured to allow trade clients who have already agreed on a trade to increase the notional amount of the trade anonymously.
• In another aspect of the invention, the credit derivative trading system is configured to allow invited participants to trade a credit derivative at a fixed price once that credit derivative has been traded in a related transaction.
• These and other features, aspects, and embodiments of the invention are described below in the section entitled “Detailed Description of the Preferred Embodiments.”
BRIEF DESCRIPTION OF THE DRAWINGS
• Features, aspects, and embodiments of the inventions are described in conjunction with the attached drawings, in which:
• FIG. 1 is a diagram illustrating an example credit derivative trading system in accordance with one embodiment of the invention;
• FIG. 2 is a flow chart illustrating an example method for transacting in a credit derivative in the system ofFIG. 1 in accordance with one embodiment of the invention;
• FIG. 3 is a flow chart illustrating an example method of receiving a responsive position within the system ofFIG. 1 in accordance with one embodiment of the invention;
• FIG. 4A is a flow chart illustrating an example method of receiving an indication of a willingness to transact within the system ofFIG. 1 in accordance with one embodiment of the invention;
• FIG. 4B is a flow chart illustrating an example method of receiving an indication of a willingness to transact within the system ofFIG. 1 with an option to upsize an accepted transaction in accordance with one embodiment of the invention;
• FIG. 5A is a screen shot illustrating a display of credit derivative information within on a terminal included in the system ofFIG. 1 in accordance with one embodiment of the invention;
• FIG. 5B is a screen shot illustrating a display of credit derivative information within on a terminal included in the system ofFIG. 1 in accordance with another embodiment of the invention;
• FIG. 6 is a screen shot illustrating the display of historical credit derivative information on a terminal included in the system ofFIG. 1 in accordance with one embodiment of the invention;
• FIG. 7 is a logical block diagram illustrating an exemplary computer system that can be included in the system ofFIG. 1
• FIG. 8 is a screen shot illustrating an example method of displaying a request to upsize a trade;
• FIG. 9 is a screenshot illustrating an example method for displaying trade information that includes an option for volume upsizing in accordance with one embodiment;
• FIG. 10 is an example screen shot of a display that can be used to implement volume upsizing;
• FIG. 11 is a chart that illustrates an example of volume upsizing.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
• FIG. 1 is a diagram illustrating an example creditderivative trading system100 in accordance with one embodiment of the systems and methods described herein.System100 comprises a creditderivative authority102 interfaced with adatabase104.Database104 can, as illustrated, actually comprise a plurality of databases depending on the embodiment. Creditderivative authority102 is interfaced with a plurality of trader clients viaterminals108 throughnetwork106.
• In one embodiment,network106 is the Internet; however,network106 can be any type of wired or wireless Wide Area Network, wired or wireless Local Area Network, or even a wired or wireless Personal Area Network, or some combination thereof. Further, in certain embodiments creditderivative authority102 and/orterminals108 can be interfaced withnetwork106 via wired and/or wireless communication links, while in another embodiment, creditderivative authority102 and/orterminals108 are interfaced withnetwork106 via wired communication links.
• In one embodiment,terminals108 are computer terminals, such as desktop or laptop computers. In other embodiments,terminals108 are handheld devices, such as handheld computers or personal digital assistants. It will be apparent, however, thatterminals108 can be any type of terminal configured to include the functionality required by the systems and methods described herein.
• The term “authority” used to identify creditderivative authority102 is intended to indicate thatterminals108 communicate with creditderivative authority102 through the computing systems, hardware and software, associated with creditderivative authority102. Thus, depending on the embodiment the term authority can refer to one or more servers, such as Internet or web servers, file servers, and/or database servers, one or more routers, one or more databases, one or more software applications, one or more Application Program Interfaces (APIs), or some combination thereof. Further, the computing system associated with creditderivative authority102 can include one or more computers or computer terminals. To that extent, some of the same components that comprise the computer system associated with creditderivative authority102 can also compriseterminals108. An exemplary embodiment of a computer system that can comprise creditderivative authority102 is described in more detail with respect toFIG. 7.
• System100 includes a standardize interface that allows the trader clients to define positions with creditderivative authority102 for any of a plurality of credit derivatives regardless of the region, industry, etc. Creditderivative authority102 is configured to then store the positions indatabase104. Using the standardized interface, creditderivative authority102 displays information related to the positions stored indatabase104 to the trader clients viaterminals108. The trader clients are then able to define responsive positions, indicate a willingness to transact, and/or complete a transaction using the standardized interface. Thus, creditderivative authority102 can replace the dealer-broker paradigm of conventional credit derivative markets and provides the trader clients with more outlets, greater liquidity, and more efficiency, all of which can help to lower transactional costs.
• The standardized interface can comprise software components configured to run on creditderivative authority102 as well as client software components configured to run onterminals108. Thus, creditderivative authority102 can work in conjunction with the client software running onterminals108 to format and display information to the trader clients in a uniform manner and to receive input from the trader clients throughterminals108 in a manner that allows quick, easy, and efficient transactions. Certain features and aspects of the standardized interface are discussed more fully below.
• FIG. 2 is a flow chart illustrating an example method of transacting in creditderivatives using system100 in accordance with the systems and methods described herein. First, instep202, creditderivative authority102 receives information related to a reference entity's credit risk that is available for transaction. In other words, when a trader client wants to move credit risk in a certain reference entity, the trader client can accesscredit derivative authority102 and make the information available along with an ask price.
• Instep204, credit derivative authority saves the information indatabase104 and instep206, creditderivative authority102 causes the information to be displayed to the rest of the plurality of trader clients via theirterminals108. Because the trader clients can accesscredit derivative authority102 from anywhere in the world, the credit derivatives made available by creditderivative authority102 are not limited by region or industry. Thus, the previously fragmented nature of credit derivative markets can be addressed. Moreover, creditderivative authority102 is preferably configured to cause the information to be displayed in a compact and uniform manner to all of the trader clients regardless of the type of credit derivative. Moreover, credit derivative authority is preferably configured to update trader clients in real-time as new credit derivatives are defined withinsystem100.
• As an example of the compact and uniform display of information, creditderivative authority102 is configured in certain embodiments, to display the following for each credit derivative defined in system100: a reference entity name, scheduled termination of the credit derivative, a debt level, a bid price, an ask price, a reference obligation, and a restructuring level. In other embodiments, credit derivative authority can also be configured to display the associated currency, a debt rating, and a debt type for each of the positions defined insystem100. Creditderivative authority102 is configured, for example, to display the information using the standardized interface described above. Thus, creditderivative authority102 retrieves the relevant information fromdatabase104 and transmits it to a client application, or applications, running onterminals108. The client applications then display the information in accordance with the systems and methods described herein.
• FIG. 5A is a screen shot illustrating one example method of displaying the information onterminals108 using a compact and uniform format. Thus, thedisplay screen500 includes a plurality of columns502-518. As can be seen,column502 comprises the names of various reference entities for which credit derivatives have been made available insystem100.Column504 comprises the debt type associated with each reference entity incolumn502.Column506 comprises a debt rating associated with each reference entity incolumn502. Although, as mentioned above, this column may or may not be included depending on the embodiment.Column508 comprises the scheduled termination associated with the credit derivative for the reference entity incolumn502.Column512 includes the associated ask prices, whilecolumn510 includes responsive bids. Thus, once bids are received, the information can be displayed incolumn510.Columns514 and516, included in certain embodiments, comprise the bid and or ask prices associated with the particular trader client on whose terminal108display500 is being displayed. Finally,column518 comprises the associated currency.
• FIG. 5B is a diagram illustrating another example method of displaying the information onterminals108 using a compact and uniform format. As can be seen, the screen shot ofFIG. 5B includesseveral columns504 that include information about credit derivatives that can be traded. In addition to the names and other information related to the credit derivatives, eachcolumn504 include acolumn508 that includes market information. In this example, the market information simply includes abid column510 and anoffer column512. The display can also include awindow514 that includes information related to recent trades.
• Once the information for a new credit derivative displayed instep206, then bids can start to be received by creditderivative authority102. This process is described below in relation toFIG. 3. Since the credit derivative market is a bilateral market, however, certain trader clients may not wish to deal with certain other trader clients in all, or certain, situations. Thus, in certain embodiments, creditderivative authority102 is configured to receive information identifying trader clients with whom the trader client defining the new position is willing to transact, i.e., the trader client uses the standardized interface to provide identifying information to creditderivative authority102 that identifies other trader clients with whom the trader client is willing to transact. Depending on the embodiment, the information includes the names of certain trader clients or defining characteristics of acceptable trader clients. Creditderivative authority102 stores the identifying information indatabase104 instep210. The information is then used, as described below, in certain embodiments, by creditderivative authority102 to help facilitate transaction between trader clients.
• It should be noted that in certain embodiments, trader clients do not need to provide, or review, credit risk information related to the various trader clients. For example, in some embodiments, use ofsystem100 can be restricted to larger clients, or clients that are prescreened for credit risk.
• In certain embodiments, the trader clients can customize their view of the information displayed. Thus, for example, instep212 creditderivative authority102 receives, from a trader client, information defining the customized view requirements of a trader client, i.e., using the standardized interface, a trader client inputs information defining a customized view. For example, in one embodiment, a trader client specifies certain regions of interest instep212. Then, instep214, creditderivative authority102 retrieves fromdatabase104 credit derivatives only for the indicated regions. These credit derivatives are then displayed, instep216, on the trader client'sterminal108. Alternatively, a trader client can customize the trader client's view by specifying, instep212, certain industries, certain reference entity names, certain credit duration, certain debt levels, certain spreads, i.e., the difference between the ask and bid prices, certain restructuring levels, etc., that the trader client is interested in. In an alternative embodiments, the credit derivatives can be sorted by geographic areas and/or sectors. Thus, a trader client can, in such embodiments, specify the area and/or sector of interest instep212. Instep214 creditderivative authority102 retrieves information for credit derivatives that meet the criteria input by the trader client.
• In a process similar to view customization, trader clients can also preferably indicate certain alternative views that they are interested in. For example, in one embodiment, instead of indicating factors that define credit derivatives of interest, the trader client indicates, instep212, an interest in certain historical information. Examples of historical information indicated instep212 include, the historical spread information for a certain credit derivative, historical trades for the trader client, and historical transactions for a certain credit derivative. In certain embodiments, a relevant time period of interest is also indicated instep212. Historical information conforming to the input criteria is then retrieved instep214 and displayed instep216.
• For example,FIG. 6 is a screen shot illustrating adisplay600 of historical transactions for a certain credit derivatives. As can be seen, display600 includes columns602-614.Column602 comprises the date of the associated transaction,column604 comprises the name of the reference entity involved,column606 comprises the type of debt,column608 comprises the scheduled termination of the credit derivative,column610 comprises the identity of the buyer,column612 comprises the price,column614 comprises the name of the seller,column616 comprises the notional amount of the transaction,column618 comprises the associated currency,column620 comprise the reference obligation, andcolumn622 comprise the status of the transaction. Of course, depending on the embodiment, some of the columns illustrated inFIG. 6 are not included indisplay600.
• FIG. 3 is a flow chart illustrating an example process by which a responsive position is received and handled in real-time bysystem100. The example processes ofFIG. 3 assume that the original position defined was an ask and, therefore, the responsive position is a bid. But the process is largely the same for the reverse situation as well. It should be noted that in certain embodiments, the time a bid or offer remains valid should be specified when the bid or offer is made. Additionally, in certain embodiments, the notional of the price should be specified.
• The process begins instep302, when a trader client inputs a bid, e.g., through their standardized interface, in response to a recent ask. Instep304, creditderivative authority102 validates the bid, e.g., checks to ensure that the bid specifies a valid credit derivative. If the bid is not valid, then creditderivative authority102 causes an error message to be displayed on the trader client's terminal108 and allows the trader client to input another bid (step302). If the bid is valid, then creditderivative authority102 stores, instep308, the bid information.
• In one embodiment, creditcreative authority102 then checks the bid against information stored indatabase104 to determine if the bid is the best bid. In other words, creditderivative authority102 checks bid information stored indatabase104 to determine if the bid is the highest bid for the associated credit derivative. If the bid is the best bid, then instep312, creditderivative authority102 updates all the trader clients with the new bid information. The update that occurs instep312 is essentially in real-time. Thus, the trader clients are receiving updated information as the credit derivative market moves. Conversely, if the position defined instep302 is an ask, then creditderivative authority102 determines, instep310, whether the ask is lower than the previous ask and updates the trader clients, instep312, when it is determined that the ask is the lowest ask.
• In certain embodiments, the latest ask or bid is broadcast to all trader clients regardless of whether it is the best, as indicated by the dashed line inFIG. 3. This allows the trader clients to see depth in the market.
• FIG. 4A is a flow chart illustrating an example process for engaging in a transaction withinsystem100. The process begins instep402 with a trader client indicating a desire to transact in response to a received updated position (step312). For example, the trader client uses their standardized interface to indicate a desire to transact. In one embodiment, when creditderivative authority102 receives the indication, it determines the ability of the trader client to transact on the associated credit derivative. This is where the information provided instep208 can come into play if required. Thus, instep404, creditderivative authority102 determines, based on information stored indatabase104, whether the trader client indicating a desire to transact is acceptable to the other party.
• In one embodiment, if credit derivative authority determines that the trader client is not acceptable, then instep406 creditderivative authority102 presents the other party with the option to proceed. If the other party declines, then the transaction is not consummated. If, on the other hand, the other party is willing to continue, or if it is determined instep404 that the trader client is able to transact, then the transaction proceeds. In other embodiments, as mentioned above, a determination as to whether a trader client is acceptable is not necessary.
• The trader client can indicate a willingness to transact instep402, by indicating a willingness to accept the terms associated with the new position or by indicating a willingness to negotiate with the other party. If the indication instep402 is an acceptance, then the other party is notified of the acceptance instep408 by creditderivative authority102. If the indication ofstep402 is of a willingness to negotiate, then the parties negotiate with each other instep410. As will be described in more detail below, the parties can negotiate aided by the standardized interface and creditderivative authority102. In an alternative embodiment, once the trader client indicates a willingness to transact instep402, they call, or are contacted by, a broker associated with creditderivative authority102 to negotiate and settle the transaction. In certain embodiments, direct negotiation as just described is not supported.
• Once the transaction settles, all of the information associated with the transaction is stored by creditderivative authority102 intodatabase104 in real-time, i.e., the information is stored as it passes back and forth between the parties and between the parties and creditderivative authority102. Creditderivative authority102 then updates the information displayed to the trader clients, again in real-time, instep414, based on the transaction information.
• In another embodiment, upon the settlement of the transaction, the trader can be prompted as to whether the trader desires to upsize the trade, that is increase the notional amount of the trade, that is the volume of the trade. At this point both parties are given a chance to request a trade of a larger notional amount, before knowing who their trading partner is. Upon determination of the largest notional amount agreed upon by both parties, the trade is completed at this notional amount.
• FIG. 4B is a flow chart illustrating an example process for engaging in a transaction withinsystem100 where the trader is given the option to upsize the trade. The processing of the transaction described byFIG. 4B is similar to that ofFIG. 4A except that upon notification of the acceptance instep408 by creditderivative authority102, the traders are given the opportunity to upsize the trade. If an upsize is agreed upon, the notional amount is increased instep416 prior tocredit authority102 storing the transaction instep412.
• This can be beneficial when a trader desires to trade a notional amount that is greater than the standard or default amount. Generally, traders are hesitant to make an intention to trade more than the standard or default amount known, because this can result in a lower price for the credit derivative. Thus, if a default trade amount is 10 million dollars and a trader desires to trade 30 million dollars, the trader will often simply attempt to make three trades. With the volume upsizing process described above, and in more detail below, a trader desiring to trade a large notional amount of a credit derivative can trade that notional amount without making the market aware of his intention, thereby maintaining the value of his credit derivative.
• FIG. 8 is a screen shot illustrating an example method of displaying a request to upsize a trade.Field802 indicates that the original trade is completed in the notional amount shown atfield806. In this particular embodiment, the trader is given a predetermined interval of time to respond to the upsize prompt, which in this case is 20 seconds as shown atfield804. The trader can then elect to increase the trade to a higher notional amount by activatingbuttons810,812, or814 depending on the size of the increase desired, or the trader can indicate no desired to increase by activatingbutton808. If both parties agree, the trade is upsized to that notional amount. In another embodiment, the prompting to upsize can repeat until one of the two trading parties no longer wishes to upsize at which point the largest amount agreed upon by both parties can be traded. In another embodiment, if the two parties both upsize but not to the same notional amount, the smaller of the two amounts can be taken as the agreed notional amount.
• As mentioned above,system100 comprises a standardized interface configured to make transacting insystem100 quick and efficient. Thus, the standardized interface allows each of the trader clients to interface with creditderivative authority102 and view information on a plurality of credit derivatives that is displayed in a compact and uniform format. Example formats were described above, e.g., in relation toFIG. 5. As was also described, the standardized interface allows each of the trader clients to customize the trader client's view of the information displayed for the plurality of credit derivatives. This was explained, e.g., in relation toFIG. 6. Thus, the display of information can be customized using the standardized interfaced based any of the following: region, industry, a reference entity name, a credit duration, a debt level, a spread, a restructuring level, an ask price, reference obligation, and a credit rating.
• In another embodiment, when there is sufficient activity in a particular credit derivative as determined either by the system or by the participants, the system can facilitate volume clearing of credit derivatives based on the most recently traded price. In overview, once the credit derivative has been traded, invited participants are invited to trade their credit derivatives during a set time interval. Those who desire to participate indicate the notional amount they desire to buy or sell. Once the time limit expires, the system determines which participants can trade and which buyers actually trade with which sellers, by matching similar trade amounts.
• More specifically, when a trade is completed the price can be offered to invited participants by listing the trade in a “Volume Matching” display.FIG. 9 is a screen shot of an example of a Volume Matching display showing credit derivatives that the participant can trade.Column902 represents the credit derivative to be traded and the price.Column904 shows the time remaining to trade that credit derivative at that price. For example, in the first row, the credit derivative Commerzbank (CMZB) is available for trading at a price of 19 basis points (bps) for the next 18 seconds. Participants are invited based on criteria which is indicative of their desire to trade that credit derivative, such as placement of a bid in the trade current session or placement of a bid in a recent trade session involving the trade derivative.
• FIG. 10 is a screen shot of an example of a method by which an interested participant can participate in volume clearing.Field1002 shows the credit derivative and the price it is being traded at. The participant can selectbutton1004 and enter a notional amount intofield1006 that he desires to buy the credit derivative or alternatively the participant can selectbutton1008 and enter a notional amount intofield1010 that he desires to sell. The order is then placed by clicking onfield1012.
• After the set time interval has expired, the orders can be filled according to the priority of the participant. The participant can be assigned a priority in the following order: the highest priority goes to current participants in the trade, the next highest priority goes to participants which are in the buyer or seller priority queues at the time of the trade, and finally, the remaining participants are prioritized on a first come first serve basis.
• The orders are then matched to optimize as much as possible orders of the same size of the counterparties. By doing so, the number of trade tickets generated is minimized. Once the matching is completed a trade ticket is generated and each transaction can be completed similar to the manner described above for a single trade.
• FIG. 11 is a table showing an example of how the trade matching works. In table1102, there are four buyers and three sellers with their respective orders listed in the order of their priority. In matching table1104,buyer1 is matched withseller3 because their notional amounts match. Furthermore,buyer2 is matched withseller1 because their notional amounts match. Since the remaining orders no longer match, the orders can be split.Buyer3 having priority overbuyer4 is matched withseller2. Sinceseller2's order is larger thanbuyer3's order, the remaining notional amount ofseller2 is available tobuyer4.
• The standardized interface is further configured to allow each of trader clients to define credit derivative positions online and to update them quickly and efficiently. For example, in one embodiment, a trader client simply inputs the information that defines the credit derivative and their position, e.g., bid or ask price, and then updates the position with creditderivative authority102 with a single “click”. The term “click” is intended to indicate that the user simply needs to use an input device, such as a mouse, to select text, a button, or an icon. Moreover, the trader can use this simple process to update a position anytime, and all of the other trader clients will be updated automatically in real-time.
• The standardized interface, in certain embodiments, is also configured to allow the trader clients to, at anytime, render inactive all or some of the trader clients defined positions with a single click. Trader clients can also reactivate some or all of their inactive positions using a single click, whenever they decide to do so. Trader clients can also increase the time for which a price remains tradable. The other trader clients are then automatically updated, based on the deactivation and reactivation of positions, in real-time.
• In certain embodiments, creditderivative authority102 is configured to facilitate communication with trader clients via theirterminals108. This communication can be between trader clients, i.e., betweenterminals108, and/or between trader clients and creditderivative authority102, i.e., betweenterminals108 and creditderivative authority102. Thus, the standardized interface includes an electronic messaging tool, such as email or instant messaging. The trade clients input and send messages using the electronic messaging tool. The messages are received by creditderivative authority102 and forwarded to thecorrect terminal108, when required. The messaging capability is used for example, to facilitate negotiations and/or settlement of transactions between trader clients. Thus, in some instances the messages are betweenterminals108 and include negotiation information. In other instances, the messages are between creditderivative authority102 and a terminal108 and include settlement information.
• FIG. 7 is a logical block diagram illustrating an example embodiment of acomputer system700 that is, for example, included in the computer system that comprises creditderivative authority102. As will be understood, some type of processing system is always at the heart of any computer system, whether the processing system includes one or several processors included in one or several devices. Thus,computer system700 ofFIG. 7 is presented as a simple example of a processing system. In the example ofFIG. 7,computer system700 comprises aprocessor710 configured to control the operation ofcomputer system700,memory704,storage706, anetwork interface708, adisplay output712, auser interface714, and abus702 configured to interface the various components comprisingcomputer system700.
• Processor710, in one embodiment, comprises a plurality of processing circuits, such as math coprocessor, network processors, digital signal processors, audio processors, etc. These various circuits can, depending on the embodiment, be included in a single device or multiple devices.Processor710 also comprise an execution area into which instructions stored inmemory704 are loaded and executed byprocessor710 in order to control the operation ofcomputer system700. Thus, for example, by executing instructions stored inmemory704,processor710 causescredit derivative authority102 to execute the steps described above.
• Memory704 comprises a main memory configured to store the instructions just referred to. In one embodiment,memory704 also comprise secondary memory used to temporarily store instructions or to store information input intocomputer system700, i.e.,memory704 acts as scratch memory also.Memory704 can comprises, depending on the embodiment, a plurality of memory circuits, which can be included as a single device, or as a plurality of devices.
• Storage706 includes, in certain embodiments, a plurality of drives configured to receive various electronic media. For example, in one embodiment,storage706 includes a floppy drive configured to receive a floppy disk, a compact disk drive configured to receive a compact disk, and/or a digital video disk drive configured to receive a digital video disk. IN another embodiment,storage706 also includes disk drives, which can include removable disk drives. The drives included instorage706 are used to receive electronic media that has stored thereon instructions to be loaded intomemory704 and used byprocessor710 to control the operation ofcomputer system700.
• Network interface708 is configured to allowcomputer system700 to interface with, and communicate over,network106. Thus, using a network interface, such asnetwork interface708, creditderivative authority102 is able to communicate withterminals108. Depending on the embodiment, creditderivative authority102 includes one or multiple network interfaces708.
• Display interface712 can be configured to allowcomputer system700 to interface with a display. Thus, in certain embodiments,computer system700 displays information to a user viadisplay interface712.
• User interface714 is configured to allow a user to interface withcomputer system700. Thus, depending on the embodiment,user interface714 can include a mouse interface, a keyboard interface, an audio interface, etc.
• It should be clear that the general description of a computer system provided above is by way of example only and should not be seen to limit implementation of creditderivative authority102 to any particular computer architecture or implementation. Rather any architecture or implementation capable of implementing the processes and functionality described above can be used to implement the systems and methods described herein.
• While certain embodiments of the inventions have been described above, it will be understood that the embodiments described are by way of example only. Accordingly, the inventions should not be limited based on the described embodiments. Rather, the scope of the inventions described herein should only be limited in light of the claims that follow when taken in conjunction with the above description and accompanying drawings.

Claims (34)

1. A credit derivative authority, comprising:

a database configured to store credit derivative information for certain reference entities;

memory configured to store execution instructions; and

a processor coupled with the database and the memory, the processor configured to execute the instructions, the instructions configured to cause the processor to

receive a position having a volume from a trader client,

receive an acceptance of the position from one of a plurality of other trader clients,

send an option to a trading party to increase the volume associated with the position, wherein the trading party is either the trader client or the other trader client that accepted the position,

receive a first increased volume selection,

offer the increase volume to a trading counterparty, wherein the trading counterparty is either the trader client or the other trader client that accepted the position, and

when agreement on the increased volume is made, finalize a transaction for the increased volume.

2. The credit derivative authority ofclaim 1, wherein the instructions are configured to cause the processor to repeat sending an option to increase the volume to the trading party, receiving an increased volume from the trading party, and offering the increased volume to the trading counterparty until no increased volume selection is received from the trading party.

3. The credit derivative authority ofclaim 1, wherein the instructions are configured to cause the processor to repeat sending an option to increase the volume to the trading party, receiving an increased volume from the trading party, and offering the increased volume to the trading counterparty until the trading counterparty declines the offer to increase the volume.

4. The credit derivative authority ofclaim 1, wherein the trading party can elect, in response to the option to increase the volume, one of a plurality of fixed volumes or no increase.

5. The credit derivative authority ofclaim 1, wherein the trading party can elect, in response to the option to increase the volume, one of a plurality of fixed volume increases or no increase.

6. The credit derivative authority ofclaim 1, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to receive an increased volume selection from the trading party, and if the period of time expires before receiving the increased volume selection, finalize a transaction for the volume.

7. The credit derivative authority ofclaim 1, wherein the volume associated with the position is a standard or default volume.

8. The credit derivative authority ofclaim 1, wherein the instructions are further configured to cause the processor to receive an acceptance of the increased volume from the counterparty and to then finalize the transaction for the increased volume.

9. The credit derivative authority ofclaim 1, wherein the instructions are further configured to cause the processor to receive a rejection of the increased volume from the counterparty and to then finalize the transaction for the Withdrawn volume.

10. A credit derivative authority, comprising:

a database configured to store credit derivative information for certain reference entities;

memory configured to store execution instructions; and

a processor coupled with the database and the memory, the processor configured to execute the instructions, the instructions configured to cause the processor to

receive a position having a volume from a trader client,

receive an acceptance of the position from one of a plurality of other trader clients,

send a first option to the trader client to increase the volume,

send a second option to the one of the plurality of other trader clients to increase the volume,

receive a first increased volume selection having a first increased volume from the trader client,

receive a second increased volume selection having a second increased volume from the one of the plurality of trader clients,

if the first increased volume and the second increased volume are the same, finalize a transaction for the increased volume.

11. The credit derivative authority ofclaim 10, wherein the first option comprises a plurality of fixed volumes and a no increase selection.

12. The credit derivative authority ofclaim 10, wherein the first option comprises a plurality of fixed volume increases and a no increase selection.

13. The credit derivative authority ofclaim 10, wherein the second option comprises a plurality of fixed volumes and a no increase selection.

14. The credit derivative authority ofclaim 10, wherein the second option comprises a plurality of fixed volume increases and a no increase selection.

15. The credit derivative authority ofclaim 10, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to receive a first increased volume selection, and if the period of time expires before receiving a first increased volume selection, finalize a transaction for the volume.

16. The credit derivative authority ofclaim 10, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to receive a second increased volume selection, and if the period of time expires before receiving a second increased volume selection, finalize a transaction for the volume.

17. The credit derivative authority ofclaim 10, wherein the instructions are further configured to cause the processor to finalize a transaction for a volume which is the lesser of the first increased volume and the second increased volume if the first increased volume and second increased volume are unequal.

18. A method for online trading of credit derivatives, comprising:

receiving a position having a volume from a trader client;

receiving an acceptance of the position from one of a plurality of other trader clients;

sending a first option to a trading party, wherein the trading party is either the trader client or the one of the plurality or other trader clients;

receiving a first increased volume selection having a first increased volume;

offering the first increase volume to a trading counterparty, wherein the trading counterparty is either the trader client or the one of the plurality of other clients which was not sent the option; and

when agreement on the increased volume is made, finalizing a transaction for the increased volume.

19. The method claim of18, further comprising repeating the sending a first option, the receiving a first increased volume, the offering the first increased volume to a trading counterparty until no increased volume selection is received from the trading party and while agreement between the trading party and the trading counterparty is maintained.

20. The method claim of18, wherein the first option comprises a plurality of fixed volumes and a no increase selection.

21. The method claim of18, wherein the first option comprises a plurality of fixed volume increases and a no increase selection.

22. The method claim of18, further comprising

sending a second option to the trading counterparty;

receiving a second increased volume selection having a second increased volume, and

offering the second increased volume to the trading party.

23. The method claim of22, further comprising repeat the sending a second option, the receiving a second increased volume, the offering the second increased volume to a trading counterparty until no increased volume selection is received from the trading counterparty and while agreement between the trading party and the trading counterparty is maintained.

24. The method claim of22, wherein the second option comprises a plurality of fixed volumes and a no increase selection.

25. The method claim of22, wherein the second option comprises a plurality of fixed volume increases and a no increase selection.

26. A method for online trading of credit derivatives, comprising:

receiving a position having a volume from a trader client;

receiving an acceptance of the position from one of a plurality of other trader clients;

receiving an acceptance of the position from one of a plurality of other trader clients,

sending a first option to the trader client to increase the volume,

sending a second option to the one of the plurality of other trader clients to increase the volume,

receiving a first increased volume selection having a first increased volume from the trader client,

receiving a second increased volume selection having a second increased volume from the one of the plurality of trader clients,

if the first increased volume and the second increased volume are the same, finalizing a transaction for the increased volume.

27. The method ofclaim 26, wherein the first option comprises a plurality of fixed volumes and a no increase selection.

28. The method ofclaim 26, wherein the first option comprises a plurality of fixed volume increases and a no increase selection.

29. The method ofclaim 26, wherein the second option comprises a plurality of fixed volumes and a no increase selection.

30. The method ofclaim 26, wherein the second option comprises a plurality of fixed volume increases and a no increase selection.

31. The method ofclaim 26, further comprising waiting a predetermined period of time to receive a first increased volume selection, and if the period of time expires before receiving a first increased volume selection, finalize a transaction for the volume.

32. The method ofclaim 26, further comprising waiting a predetermined period of time to receive a second increased volume selection, and if the period of time expires before receiving a second increased volume selection, finalize a transaction for the volume.

33. The method ofclaim 26, further comprising finalizing a transaction for a volume which is the lesser of the first increased volume and the second increased volume if the first increased volume and second increased volume are unequal.

34-45. (canceled)

Images