EP1810240A4 - Systems and methods for an online credit derivative trading system - Google Patents

Systems and methods for an online credit derivative trading system

Info

Publication number
EP1810240A4
EP1810240A4 EP05803637A EP05803637A EP1810240A4 EP 1810240 A4 EP1810240 A4 EP 1810240A4 EP 05803637 A EP05803637 A EP 05803637A EP 05803637 A EP05803637 A EP 05803637A EP 1810240 A4 EP1810240 A4 EP 1810240A4
Authority
EP
European Patent Office
Prior art keywords
price
trader
volume
offer
trader clients
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP05803637A
Other languages
German (de)
French (fr)
Other versions
EP1810240A2 (en
Inventor
Sunil Gordhan Hiirani
Dar Mazyar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Creditex Group Inc
Original Assignee
Creditex Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/954,629 external-priority patent/US7698208B2/en
Priority claimed from US10/957,217 external-priority patent/US7716114B2/en
Application filed by Creditex Inc filed Critical Creditex Inc
Publication of EP1810240A2 publication Critical patent/EP1810240A2/en
Publication of EP1810240A4 publication Critical patent/EP1810240A4/en
Ceased legal-status Critical Current

Links

Classifications

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

Definitions

  • the field of the invention relates generally to credit derivatives and more particularly to the transacting in credit derivatives in an online environment.
  • 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.
  • information flow is concentrated in a few dealers.
  • the end users such as those described above, transact through' the dealers and not directly with each other.
  • 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.
  • 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.
  • 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.
  • 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 difficulty in trading credit derivatives occurs when a dealer or buyer desires to trade a large number of credit derivatives. A desire for a large transaction can influence the market in a manner adverse to the trader.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 1 is a diagram illustrating an example credit derivative trading system in accordance with one embodiment of the invention
  • Figure 2 is a flow chart illustrating an example method for transacting in a credit derivative in the system of figure 1 in accordance with one embodiment of the invention
  • Figure 3 is a flow chart illustrating an example method of receiving a responsive position within the system of figure 1 in accordance with one embodiment of the invention
  • Figure 4 is a flow chart illustrating an example method of receiving an indication of a willingness to transact within the system of figure 1 in accordance with one embodiment of the invention
  • Figure 5 A is a screen shot illustrating a display of credit derivative information within on a terminal included in the system of figure 1 in accordance with one embodiment of the invention
  • Figure 5B is a screen shot illustrating a display of credit derivative information within on a terminal included in the system of figure 1 in accordance with another embodiment of the invention.
  • Figure 6 is a screen shot illustrating the display of historical credit derivative information on a terminal included in the system of figure 1 in accordance with one embodiment of the invention
  • Figure 7 is a logical block diagram illustrating an exemplary computer system that can be included in the system of figure 1
  • Figure 8 is a screen shot illustrating an example method of displaying a request to upsize a trade
  • Figure 9 is a screenshot illustrating an example method for displaying trade information that includes an option for volume upsizing in accordance with one embodiment
  • Figure 10 is an example screen shot of a display that can be used to implement volume upsizing
  • Figure 11 is a chart that illustrates an example of volume upsizing
  • Figure 12A is a screen shot of an example of how a participant can be solicited for bids and offers;
  • Figure 12B is a screen shot of an example of how a participant can perform volume matching;
  • Figure 12C is a screen shot illustrating the results of the volume matching session
  • Figure 13 is a flow chart depicting a method of determining the fixed price based on the bids and offers by the participants;
  • Figure 14 are two tables illustrating the method described above.
  • Figures 15 A, 15B, 15C, and 15D are printouts of actual results of a fixed price trading session related to each of the three credits.
  • FIG. 1 is a diagram illustrating an example credit derivative trading system 100 in accordance with one embodiment of the systems and methods described herein.
  • System 100 comprises a credit derivative authority 102 interfaced with a database 104.
  • Database 104 can, as illustrated, actually comprise a plurality of databases depending on the embodiment.
  • Credit derivative authority 102 is interfaced with a plurality of trader clients via terminals 108 through network 106.
  • network 106 is the Internet; however, network 106 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.
  • credit derivative authority 102 and/or terminals 108 can be interfaced with network 106 via wired and/or wireless communication links, while in another embodiment, credit derivative authority 102 and/or terminals 108 are interfaced with network 106 via wired communication links.
  • terminals 108 are computer terminals, such as desktop or laptop computers. In other embodiments, terminals 108 are handheld devices, such as handheld computers or personal digital assistants. It will be apparent, however, that terminals 108 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 credit derivative authority 102 is intended to indicate that terminals 108 communicate with credit derivative authority 102 through the computing systems, hardware and software, associated with credit derivative authority 102.
  • 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.
  • the computing system associated with credit derivative authority 102 can include one or more computers or computer terminals. To that extent, some of the same components that comprise the computer system associated with credit derivative authority 102 can also comprise terminals 108.
  • An exemplary embodiment of a computer system that can comprise credit derivative authority 102 is described in more detail with respect to figure 7.
  • System 100 includes a standardize interface that allows the trader clients to define positions with credit derivative authority 102 for any of a plurality of credit derivatives regardless of the region, industry, etc.
  • Credit derivative authority 102 is configured to then store the positions in database 104.
  • credit derivative authority 102 displays information related to the positions stored in database 104 to the trader clients via terminals 108.
  • the trader clients are then able to define responsive positions, indicate a willingness to transact, and/or complete a transaction using the standardized interface.
  • credit derivative authority 102 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 credit derivative authority 102 as well as client software components configured to run on terminals 108.
  • credit derivative authority 102 can work in conjunction with the client software running on terminals 108 to format and display information to the trader clients in a uniform manner and to receive input from the trader clients through terminals 108 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 credit derivatives using system 100 in accordance with the systems and methods described herein.
  • credit derivative authority 102 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 access credit derivative authority 102 and make the information available along with an ask price.
  • credit derivative authority saves the information in database 104 and in step 206, credit derivative authority 102 causes the information to be displayed to the rest of the plurality of trader clients via their terminals 108. Because the trader clients can access credit derivative authority 102 from anywhere in the world, the credit derivatives made available by credit derivative authority 102 are not limited by region or industry. Thus, the previously fragmented nature of credit derivative markets can be addressed. Moreover, credit derivative authority 102 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 within system 100.
  • credit derivative authority 102 is configured in certain embodiments, to display the following for each credit derivative defined in system 100: 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.
  • 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 in system 100.
  • Credit derivative authority 102 is configured, for example, to display the information using the standardized interface described above.
  • credit derivative authority 102 retrieves the relevant information from database 104 and transmits it to a client application, or applications, running on te ⁇ ninals 108. The client applications then display the information in accordance with the systems and methods described herein.
  • Figure 5 A is a screen shot illustrating one example method of displaying the information on terminals 108 using a compact and uniform format.
  • the display screen 500 includes a plurality of columns 502-518.
  • column 502 comprises the names of various reference entities for which credit derivatives have been made available in system 100.
  • Column 504 comprises the debt type associated with each reference entity in column 502.
  • Column 506 comprises a debt rating associated with each reference entity in column 502. Although, as mentioned above, this column may or may not be included depending on the embodiment.
  • Column 508 comprises the scheduled termination associated with the credit derivative for the reference entity in column 502.
  • Column 512 includes the associated ask prices, while column 510 includes responsive bids.
  • Columns 514 and 516 included in certain embodiments, comprise the bid and or ask prices associated with the particular trader client on whose terminal 108 display 500 is being displayed.
  • column 518 comprises the associated currency.
  • Figure 5B is a diagram illustrating another example method of displaying the information on terminals 108 using a compact and uniform format.
  • the screen shot of figure 5B includes several columns 504 that include information about credit derivatives that can be traded.
  • each column 504 include a column 508 that includes market information.
  • the market information simply includes a bid column 510 and an offer column 512.
  • the display can also include a window 514 that includes information related to recent trades.
  • credit derivative authority 102 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 credit derivative authority 102 that identifies other trader clients with whom the trader client is willing to transact.
  • the information includes the names of certain trader clients or defining characteristics of acceptable trader clients.
  • Credit derivative authority 102 stores the identifying information in database 104 in step 210. The information is then used, as described below, in certain embodiments, by credit derivative authority 102 to help facilitate transaction between trader clients.
  • trader clients do not need to provide, or review, credit risk information related to the various trader clients.
  • use of system 100 can be restricted to larger clients, or clients that are prescreened for credit risk.
  • the trader clients can customize their view of the information displayed.
  • credit derivative authority 102 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.
  • a trader client specifies certain regions of interest in step 212.
  • credit derivative authority 102 retrieves from database 104 credit derivatives only for the indicated regions. These credit derivatives are then displayed, in step 216, on the trader client's terminal 108.
  • a trader client can customize the trader client's view by specifying, in step 212, 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.
  • the credit derivatives can be sorted by geographic areas and/or sectors.
  • a trader client can, in such embodiments, specify the area and/or sector of interest in step 212.
  • credit derivative authority 102 retrieves information for credit derivatives that meet the criteria input by the trader client.
  • 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, in step 212, an interest in certain historical information. Examples of historical information indicated in step 212 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 in step 212. Historical information conforming to the input criteria is then retrieved in step 214 and displayed in step 216.
  • figure 6 is a screen shot illustrating a display 600 of historical transactions for a certain credit derivatives.
  • display 600 includes columns 602-614.
  • Column 602 comprises the date of the associated transaction
  • column 604 comprises the name of the reference entity involved
  • column 606 comprises the type of debt
  • column 608 comprises the scheduled termination of the credit derivative
  • column 610 comprises the identity of the buyer
  • column 612 comprises the price
  • column 614 comprises the name of the seller
  • column 616 comprises the notional amount of the transaction
  • column 618 comprises the associated currency
  • column 620 comprise the reference obligation
  • column 622 comprise the status of the transaction.
  • some of the columns illustrated in figure 6 are not included in display 600.
  • Figure 3 is a flow chart illustrating an example process by which a responsive position is received and handled in real-time by system 100.
  • the example processes of figure 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, a notional of the price should be specified.
  • the process begins in step 302, when a trader client inputs a bid, e.g., through their standardized interface, in response to a recent ask.
  • step 304 credit derivative authority 102 validates the bid, e.g., checks to ensure that the bid specifies a valid credit derivative. If the bid is not valid, then credit derivative authority 102 causes an error message to be displayed on the trader client's terminal 108 and allows the trader client to input another bid (step 302). If the bid is valid, then credit derivative authority 102 stores, in step 308, the bid information.
  • credit creative authority 102 then checks the bid against information stored in database 104 to determine if the bid is the best bid. In other words, credit derivative authority 102 checks bid information stored in database 104 to determine if the bid is the highest bid for the associated credit derivative. If the bid is the best bid, then in step 312, credit derivative authority 102 updates all the trader clients with the new bid information. The update that occurs in step 312 is essentially in real-time. Thus, the trader clients are receiving updated information as the credit derivative market moves. Conversely, if the position defined in step 302 is an ask, then credit derivative authority 102 determines, in step 310, whether the ask is lower than the previous ask and updates the trader clients, in step 312, when it is determined that the ask is the lowest ask.
  • the latest ask or bid is broadcast to all trader clients regardless of whether it is the best. This allows the trader clients to see depth in the market.
  • Figure 4 is a flow chart illustrating an example process for engaging in a transaction within system 100.
  • the process begins in step 402 with a trader client indicating a desire to transact in response to a received updated position (step 312).
  • the trader client uses their standardized interface to indicate a desire to transact.
  • credit derivative authority 102 determines the ability of the trader client to transact on the associated credit derivative. This is where the information provided in step 208 can come into play if required.
  • credit derivative authority 102 determines, based on information stored in database 104, whether the trader client indicating a desire to transact is acceptable to the other party.
  • step 406 credit derivative authority 102 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 in step 404 that the trader client is able to transact, then the transaction proceeds.
  • the trader client can indicate a willingness to transact in step 402, 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 in step 402 is an acceptance, then the other party is notified of the acceptance in step 408 by credit derivative authority 102. If the indication of step 402 is of a willingness to negotiate, then the parties negotiate with each other in step 410. As will be described in more detail below, the parties can negotiate aided by the standardized interface and credit derivative authority 102. In an alternative embodiment, once the trader client indicates a willingness to transact in step 402, they call, or are contacted by, a broker associated with credit derivative authority 102 to negotiate and settle the transaction. In certain embodiments, direct negotiation as just described is not supported.
  • the trader upon the settlement of the transaction, can be prompted as to whether the trader desires to upsize the trade, that is increase the notional amount 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.
  • Figure 8 is a screen shot illustrating an example method of displaying a request to upsize a trade.
  • Field 802 indicates that the original trade is completed in the notional amount shown at field 806.
  • the trader is given a predetermined interval of time to respond to the upsize prompt, which in this case is 20 seconds as shown at field 804.
  • the trader can then elect to increase the trade to a higher notional amount by activating buttons 810, 812, or 814 depending on the size of the increase desired, or the trader can indicate no desired to increase by activating button 808.
  • 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.
  • 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.
  • a price can be fixed by the system and invited participants are can place orders to buy or sell the credit derivative at the fixed price in a manner similar to the volume matching described above.
  • the system can fix a price.
  • the system can solicit and accept a number of bids and offers from its participants. These bids and offers in addition to the asking and selling price can also include a volume to be traded.
  • the bids and offers can be made binding to prevent participants from entering false bids in order to influence the market.
  • a participant whose bid price is met that is the bid price is at least that of the fixed price can be prohibited from selling during the volume matching.
  • a participant whose offer price is met that is the offer price is at most that of the fixed price can be prohibited from buying during the volume matching. Based on these bids and offers the system can select a fixed price.
  • Figure 12A is a screen shot of an example of how a participant can be solicited for bids and offers.
  • a predetermined time limit is imposed after which bids and offers are no longer accepted.
  • the amount of time remaining to enter a bit is shown in field 1202.
  • the notional amount of the bid/offer is shown.
  • the volume is fixed for all participants, in other embodiments, this amount can be entered by the participant.
  • the bid prices are entered by the participant for each credit derivative and in column 1208, the offer prices are entered by the participant.
  • the system can also safeguard against choice prices, that is a bid equal to an offer, and inverted prices, that is a bid greater than an offer. Once the time limit has expired, all valid submissions by the participants are collected by the system and a fixed price is determined.
  • Figure 12B is a screen shot of an example of how a participant can perform volume matching.
  • Column 1210 shows the fixed price for each of the credit derivatives. If the participant's bid price is greater than or equal to the fixed price the participant is required to buy at the fixed price. In this case, the participant can specify an additional amount to buy at the fixed price by entering it into the appropriate field of column 1212. If the participant's offer price is lower than the fixed price, the participant is required to sell at the fixed price. In this case, the participant can specify an additional amount to sell at the fixed price, by entering it into the appropriate field of column 1214.
  • the participant can elect to either sell or buy an amount of credit derivative at the fixed price, but not both.
  • the time limit has expired, all additional orders are processed by the system.
  • the method of filling the orders is similar to that described in the volume matching described above, except that a priority is assigned to those participants whose bids are closes to the fixed price.
  • Figure 12C is a screen shot illustrating the results of the volume matching session.
  • Columns 1216 and 1218 show the notional amount actually traded as a result of the trading activity described above.
  • the participant's bid exceeded the fixed price so was obligated to buy 25MM units of Europe, but also requested to buy an additional 50MM units and successfully bought 75MM units.
  • the participant was not obligated to buy or sell HiVoI, but request to by 75MM units of HiVoI. However, this order was not matched.
  • the participant's offer was lower than the fixed price for Crossover, so the participant was obligated to sell IOMM units of Crossover.
  • the participant '''' also requested to sell another 40MM units of Crossover, however, only a partial order of 20MM units of Crossover was available leading to a total sale of 30MM units.
  • Figure 13 is a flow chart depicting a method of determining the fixed price based on the bids and offers by the participants.
  • the system solicits bids and offers from the participants.
  • the system waits a predetermined period of time.
  • the system collects all valid bids and offers from the participants.
  • the bids are sorted into a sequence with the highest bids first and the offers are sorted into a sequence with the lowest offers first.
  • all bids except for a predetermined number of the highest bids and all offers except for a predetermined number of the lowest offers are discarded. For example, the highest half of the bids and the lowest half of the offers are kept.
  • the average is computed by averaging all the bid prices and offer prices. In other embodiments where the volume can be specified along with the bid and offer prices, the average can be computed by a simple average where each bid price and offer price is accounted for once or by a weighted average where each bid price and offer price is averaged in based on the volume specified by the participant. This average is called the mid fixing.
  • a sequence of markets is created by pairing the sequence of bids with their counterparts in the sequence of offers, so that the highest bid and the lowest offer comprise the first market in the sequence, where a market comprises a bid and an offer.
  • a determination is made as to whether the highest bid exceeds the lowest offer.
  • the price is fixed at the average in step 1318. If so, at step 1320, the market with the lowest bid and the highest offer where the bid is at least the offer is determined. This market is referred to as the last tradeable market.
  • a determination is made as to whether the average is below the bid of the last tradeable market, above the offer of the last tradeable market or between the bid and the offer. If the average is between the offer and the bid. Then the price is fixed at the average in step 1318. If the average is below the bid, then the price is fixed at the bid of the last tradeable market at step 1324. If the average is above the offer, then the price is fixed at the offer of the last tradeable market at step 1326. Steps 1324 and 1326 are used to insure that a participant is not obligated to purchase at a price above his bid or to sell at a price below his offer.
  • bid fixing and offer fixing can be used in determining the fixed price.
  • the basic bid fixing calculation is to take the average of all bids which remain after step 1310.
  • the basic offer fixing calculation is to take the average of all offers which remain after step 1310.
  • the basic method can be adjusted so that if the bid fixing calculation exceeds the mid fixing the bid fixing is set to the mid fixing. Likewise, if the offer fixing calculation is below the mid fixing, the offer fixing is set to the mid fixing.
  • Other methods can be used to calculate the bid fixing.
  • the trades capped method takes all bids remaining after step 1310 and sets all bids greater than the mid fixing calculated in step 1312 to the mid fixing. After this all bids are averaged to generate the bid fixing.
  • all offers remaining after step 1310 are taken and all offers less than the mid fixing calculated in step 1312 are set to the mid fixing. After this, all offers are averaged to generate the offer fixing.
  • the trades excluded method averages all bids remaining after step 1310 that are less than the mid fixing to generate the bid fixing. If no bids are below the mid fixing, the highest bid is taken as the bid fixing.
  • all offers remaining after step 1310 that are greater than the mid fixing are averaged to generated the offer fixing. If no offers are greater than the mid fixing, the lowest offer is taken as the offer fixing.
  • the mid fixing is used as the fixed price for the volume matching, however, the bid fixing iaiid ' offef'fif Mg' can be used as a reference in future contracts as well as incorporated into the calculation of the fixed price in this or future sessions.
  • Figure 14 are two tables illustrating the method described above.
  • table 1402 the contributed bids and offers of eight participants are shown, hi table 1404, the bids and offers are sorted with highest bids and lowest offers first.
  • step 1310 only the top four pairs are kept so, only rows 1410, 1412, 1414, and 1416 are kept in the mid fixing calculation.
  • rows 1410, 1412, and 1414 show bids that are greater than or equal to the offers. Row 1414 having the lowest bid and highest offer among this group making row 1414 the last tradeable market.
  • Figure 15 A is a summary print out of an actual fixed price trading session.
  • the table on the left shows the bid, mid and offer fixing for three credit derivatives involved.
  • On the right are three tables showing the bid prices and the offer prices for the three credit derivatives sorted by highest bid and lowest offer. In this example in calculating the bid, mid, and offer fixings the first half of the offers and bids are retained.
  • Figure 15B is a print out of detailed results of the Europe credit index, showing the same bids and offers as the right side of Figure 15A,but also with statistical quantities such as the mean, standard deviations, and kurtosis, and a graph of the markets, graphed in the order displayed in the table.
  • Figure 15C is a print out of detailed results of the HiVoI credit derivative, showing similar categories of results as in Figure 15B.
  • Figure 15D is a print out of detailed results of the Crossover credit derivative, showing similar categories of results as in Figure 15B.
  • system 100 comprises a standardized interface configured to make transacting in system 100 quick and efficient.
  • the standardized interface allows each of the trader clients to interface with credit derivative authority 102 and view information on a plurality of credit derivative ' s that is displayed '' in a compact and uniform format.
  • Example formats were described above, e.g., in relation to figure 5.
  • 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 to figure 6.
  • 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, and a credit rating.
  • the system 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 matching of credit derivatives based on the most recently traded price.
  • 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.
  • FIG. 9 is a screen shot of an example of a Volume Matching display showing credit derivatives that the participant can trade.
  • Column 902 represents the credit derivative to be traded and the price.
  • Column 904 shows the time remaining to trade that credit derivative at that price.
  • 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.
  • Figure 10 is a ' screen ' sh ⁇ f ⁇ Fan " example of a method by which an interested participant can participated in volume matching.
  • Field 1002 shows the credit derivative and the price it is being traded at.
  • the participant can select button 1004 and enter a notional amount into field 1006 that he desires to buy the credit derivative or alternatively the participant can select button 1008 and enter a notional amount into field 1010 that he desires to sell.
  • the order is then placed by clicking on field 1012.
  • 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.
  • Figure 11 is a table showing an example of how the trade matching works, hi table 1102, there are four buyers and three sellers with their respective orders listed in the order of their priority.
  • matching table 1104 buyer 1 is matched with seller 3 because their notional amounts match.
  • buyer 2 is matched with seller 1 because their notional amounts match. Since the remaining orders no longer match, the orders can be split.
  • Buyer 3 having priority over buyer 4 is matched with seller 2. Since seller 2's order is larger than buyer 3's order, the remaining notional amount of seller 2 is available to buyer 4.
  • 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 credit derivative authority 102 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.
  • 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.
  • the other trader clients are then automatically updated, based on the deactivation and reactivation of positions, in real-time.
  • credit derivative authority 102 is configured to facilitate communication with trader clients via their terminals 108. This communication can be between trader clients, i.e., between terminals 108, and/or between trader clients and credit derivative authority 102, i.e., between terminals 108 and credit derivative authority 102.
  • 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 credit derivative authority 102 and forwarded to the correct terminal 108, when required.
  • the messaging capability is used for example, to facilitate negotiations and/or settlement of transactions between trader clients.
  • the messages are between terminals ' i ⁇ ' 8 " and include" negotiation information.
  • the messages are between credit derivative authority 102 and a terminal 108 and include settlement information.
  • FIG. 7 is a logical block diagram illustrating an example embodiment of a computer system 700 that is, for example, included in the computer system that comprises credit derivative authority 102.
  • 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.
  • computer system 700 of figure 7 is presented as a simple example of a processing system.
  • computer system 700 comprises a processor 710 configured to control the operation of computer system 700, memory 704, storage 706, a network interface 708, a display output 712, a user interface 714, and a bus 702 configured to interface the various components comprising computer system 700.
  • Processor 710 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. Processor 710 also comprise an execution area into which instructions stored in memory 704 are loaded and executed by processor 710 in order to control the operation of computer system 700. Thus, for example, by executing instructions stored in memory 704, processor 710 causes credit derivative authority 102 to execute the steps described above.
  • 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. Processor 710 also comprise an execution area into which instructions stored in memory 704 are loaded and executed by processor 710 in order to control the operation of computer system 700. Thus, for example, by executing instructions stored in memory 704, processor 710 causes credit derivative authority 102 to execute the steps described above.
  • Memory 704 comprises a main memory configured to store the instructions just referred to.
  • memory 704 also comprise secondary memory used to temporarily store instructions or to store information input into computer system 700, i.e., memory 704 acts as scratch memory also.
  • Memory 704 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.
  • Storage 706 includes, in certain embodiments, a plurality of drives configured to receive various electronic media.
  • storage 706 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.
  • storage 706 also includes disk drives, which can include removable disk drives. The drives included in storage 706 are used to receive electronic media that has stored thereon instructions to be loaded into memory 704 and used by processor 710 to control the operation of computer system 700.
  • Network interface 708 is configured to allow computer system 700 to interface with, and communicate over, network 106.
  • a network interface such as network interface 708
  • credit derivative authority 102 is able to communicate with terminals 108.
  • credit derivative authority 102 includes one or multiple network interfaces 708.
  • Display interface 712 can be configured to allow computer system 700 to interface with a display. Thus, in certain embodiments, computer system 700 displays information to a user via display interface 712.
  • User interface 714 is configured to allow a user to interface with computer system 700.
  • user interface 714 can include a mouse interface, a keyboard interface, an audio interface, etc.

Landscapes

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

Abstract

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

Description

SYSTEMS AND METHODS FOR AN ONLINE CREDIT DERIVATIVE TRADING SYSTEM
BACKGROUND
1. Field of the Inventions
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 Information
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 a large number 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:
Figure 1 is a diagram illustrating an example credit derivative trading system in accordance with one embodiment of the invention;
Figure 2 is a flow chart illustrating an example method for transacting in a credit derivative in the system of figure 1 in accordance with one embodiment of the invention;
Figure 3 is a flow chart illustrating an example method of receiving a responsive position within the system of figure 1 in accordance with one embodiment of the invention; Figure 4 is a flow chart illustrating an example method of receiving an indication of a willingness to transact within the system of figure 1 in accordance with one embodiment of the invention;
Figure 5 A is a screen shot illustrating a display of credit derivative information within on a terminal included in the system of figure 1 in accordance with one embodiment of the invention;
Figure 5B is a screen shot illustrating a display of credit derivative information within on a terminal included in the system of figure 1 in accordance with another embodiment of the invention;
Figure 6 is a screen shot illustrating the display of historical credit derivative information on a terminal included in the system of figure 1 in accordance with one embodiment of the invention;
Figure 7 is a logical block diagram illustrating an exemplary computer system that can be included in the system of figure 1
Figure 8 is a screen shot illustrating an example method of displaying a request to upsize a trade;
Figure 9 is a screenshot illustrating an example method for displaying trade information that includes an option for volume upsizing in accordance with one embodiment;
Figure 10 is an example screen shot of a display that can be used to implement volume upsizing;
Figure 11 is a chart that illustrates an example of volume upsizing;
Figure 12A is a screen shot of an example of how a participant can be solicited for bids and offers; Figure 12B is a screen shot of an example of how a participant can perform volume matching;
Figure 12C is a screen shot illustrating the results of the volume matching session;
Figure 13 is a flow chart depicting a method of determining the fixed price based on the bids and offers by the participants;
Figure 14 are two tables illustrating the method described above;
Figures 15 A, 15B, 15C, and 15D are printouts of actual results of a fixed price trading session related to each of the three credits.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Figure 1 is a diagram illustrating an example credit derivative trading system 100 in accordance with one embodiment of the systems and methods described herein. System 100 comprises a credit derivative authority 102 interfaced with a database 104. Database 104 can, as illustrated, actually comprise a plurality of databases depending on the embodiment. Credit derivative authority 102 is interfaced with a plurality of trader clients via terminals 108 through network 106.
In one embodiment, network 106 is the Internet; however, network 106 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 credit derivative authority 102 and/or terminals 108 can be interfaced with network 106 via wired and/or wireless communication links, while in another embodiment, credit derivative authority 102 and/or terminals 108 are interfaced with network 106 via wired communication links. In one embodiment, terminals 108 are computer terminals, such as desktop or laptop computers. In other embodiments, terminals 108 are handheld devices, such as handheld computers or personal digital assistants. It will be apparent, however, that terminals 108 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 credit derivative authority 102 is intended to indicate that terminals 108 communicate with credit derivative authority 102 through the computing systems, hardware and software, associated with credit derivative authority 102. 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 credit derivative authority 102 can include one or more computers or computer terminals. To that extent, some of the same components that comprise the computer system associated with credit derivative authority 102 can also comprise terminals 108. An exemplary embodiment of a computer system that can comprise credit derivative authority 102 is described in more detail with respect to figure 7.
System 100 includes a standardize interface that allows the trader clients to define positions with credit derivative authority 102 for any of a plurality of credit derivatives regardless of the region, industry, etc. Credit derivative authority 102 is configured to then store the positions in database 104. Using the standardized interface, credit derivative authority 102 displays information related to the positions stored in database 104 to the trader clients via terminals 108. 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, credit derivative authority 102 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 credit derivative authority 102 as well as client software components configured to run on terminals 108. Thus, credit derivative authority 102 can work in conjunction with the client software running on terminals 108 to format and display information to the trader clients in a uniform manner and to receive input from the trader clients through terminals 108 in a manner that allows quick, easy, and efficient transactions. Certain features and aspects of the standardized interface are discussed more fully below.
Figure 2 is a flow chart illustrating an example method of transacting in credit derivatives using system 100 in accordance with the systems and methods described herein. First, in step 202, credit derivative authority 102 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 access credit derivative authority 102 and make the information available along with an ask price.
In step 204, credit derivative authority saves the information in database 104 and in step 206, credit derivative authority 102 causes the information to be displayed to the rest of the plurality of trader clients via their terminals 108. Because the trader clients can access credit derivative authority 102 from anywhere in the world, the credit derivatives made available by credit derivative authority 102 are not limited by region or industry. Thus, the previously fragmented nature of credit derivative markets can be addressed. Moreover, credit derivative authority 102 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 within system 100.
As an example of the compact and uniform display of information, credit derivative authority 102 is configured in certain embodiments, to display the following for each credit derivative defined in system 100: 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 in system 100. Credit derivative authority 102 is configured, for example, to display the information using the standardized interface described above. Thus, credit derivative authority 102 retrieves the relevant information from database 104 and transmits it to a client application, or applications, running on teπninals 108. The client applications then display the information in accordance with the systems and methods described herein.
Figure 5 A is a screen shot illustrating one example method of displaying the information on terminals 108 using a compact and uniform format. Thus, the display screen 500 includes a plurality of columns 502-518. As can be seen, column 502 comprises the names of various reference entities for which credit derivatives have been made available in system 100. Column 504 comprises the debt type associated with each reference entity in column 502. Column 506 comprises a debt rating associated with each reference entity in column 502. Although, as mentioned above, this column may or may not be included depending on the embodiment. Column 508 comprises the scheduled termination associated with the credit derivative for the reference entity in column 502. Column 512 includes the associated ask prices, while column 510 includes responsive bids. Thus, once bids are received, the information can be displayed in column 510. Columns 514 and 516, included in certain embodiments, comprise the bid and or ask prices associated with the particular trader client on whose terminal 108 display 500 is being displayed. Finally, column 518 comprises the associated currency.
Figure 5B is a diagram illustrating another example method of displaying the information on terminals 108 using a compact and uniform format. As can be seen, the screen shot of figure 5B includes several columns 504 that include information about credit derivatives that can be traded. In addition to the names and other information related to the credit derivatives, each column 504 include a column 508 that includes market information. In this example, the market information simply includes a bid column 510 and an offer column 512. The display can also include a window 514 that includes information related to recent trades.
Once the information for a new credit derivative displayed in step 206, then bids can start to be received by credit derivative authority 102. This process is described below in relation to figure 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, credit derivative authority 102 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 credit derivative authority 102 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. Credit derivative authority 102 stores the identifying information in database 104 in step 210. The information is then used, as described below, in certain embodiments, by credit derivative authority 102 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 of system 100 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, in step 212 credit derivative authority 102 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 in step 212. Then, in step 214, credit derivative authority 102 retrieves from database 104 credit derivatives only for the indicated regions. These credit derivatives are then displayed, in step 216, on the trader client's terminal 108. Alternatively, a trader client can customize the trader client's view by specifying, in step 212, 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 in step 212. In step 214 credit derivative authority 102 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, in step 212, an interest in certain historical information. Examples of historical information indicated in step 212 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 in step 212. Historical information conforming to the input criteria is then retrieved in step 214 and displayed in step 216.
For example, figure 6 is a screen shot illustrating a display 600 of historical transactions for a certain credit derivatives. As can be seen, display 600 includes columns 602-614. Column 602 comprises the date of the associated transaction, column 604 comprises the name of the reference entity involved, column 606 comprises the type of debt, column 608 comprises the scheduled termination of the credit derivative, column 610 comprises the identity of the buyer, column 612 comprises the price, column 614 comprises the name of the seller, column 616 comprises the notional amount of the transaction, column 618 comprises the associated currency, column 620 comprise the reference obligation, and column 622 comprise the status of the transaction. Of course, depending on the embodiment, some of the columns illustrated in figure 6 are not included in display 600.
Figure 3 is a flow chart illustrating an example process by which a responsive position is received and handled in real-time by system 100. The example processes of figure 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, a notional of the price should be specified. The process begins in step 302, when a trader client inputs a bid, e.g., through their standardized interface, in response to a recent ask. In step 304, credit derivative authority 102 validates the bid, e.g., checks to ensure that the bid specifies a valid credit derivative. If the bid is not valid, then credit derivative authority 102 causes an error message to be displayed on the trader client's terminal 108 and allows the trader client to input another bid (step 302). If the bid is valid, then credit derivative authority 102 stores, in step 308, the bid information.
In one embodiment, credit creative authority 102 then checks the bid against information stored in database 104 to determine if the bid is the best bid. In other words, credit derivative authority 102 checks bid information stored in database 104 to determine if the bid is the highest bid for the associated credit derivative. If the bid is the best bid, then in step 312, credit derivative authority 102 updates all the trader clients with the new bid information. The update that occurs in step 312 is essentially in real-time. Thus, the trader clients are receiving updated information as the credit derivative market moves. Conversely, if the position defined in step 302 is an ask, then credit derivative authority 102 determines, in step 310, whether the ask is lower than the previous ask and updates the trader clients, in step 312, 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. This allows the trader clients to see depth in the market.
Figure 4 is a flow chart illustrating an example process for engaging in a transaction within system 100. The process begins in step 402 with a trader client indicating a desire to transact in response to a received updated position (step 312). For example, the trader client uses their standardized interface to indicate a desire to transact. In one embodiment, when credit derivative authority 102 receives the indication, it determines the ability of the trader client to transact on the associated credit derivative. This is where the information provided in step 208 can come into play if required. Thus, in step 404, credit derivative authority 102 determines, based on information stored in database 104, 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 in step 406 credit derivative authority 102 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 in step 404 that the trader client is able to transact, then the transaction proceeds.
The trader client can indicate a willingness to transact in step 402, 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 in step 402 is an acceptance, then the other party is notified of the acceptance in step 408 by credit derivative authority 102. If the indication of step 402 is of a willingness to negotiate, then the parties negotiate with each other in step 410. As will be described in more detail below, the parties can negotiate aided by the standardized interface and credit derivative authority 102. In an alternative embodiment, once the trader client indicates a willingness to transact in step 402, they call, or are contacted by, a broker associated with credit derivative authority 102 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 credit derivative authority 102 into database 104 in real-time, i.e., the information is stored as it passes back and forth between the parties and between the parties and credit derivative authority 102. Credit derivative authority 102 then updates the information displayed to the trader clients, again in real-time, in step 414, 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. 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.
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 shares and a trader desires to trade 30 million shares, 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.
Figure 8 is a screen shot illustrating an example method of displaying a request to upsize a trade. Field 802 indicates that the original trade is completed in the notional amount shown at field 806. 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 at field 804. The trader can then elect to increase the trade to a higher notional amount by activating buttons 810, 812, or 814 depending on the size of the increase desired, or the trader can indicate no desired to increase by activating button 808. If both parties agree, the trade is upsized to that notional amount, hi 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.
In another embodiment, a price can be fixed by the system and invited participants are can place orders to buy or sell the credit derivative at the fixed price in a manner similar to the volume matching described above. There are many methods by which the system can fix a price. For example, the system can solicit and accept a number of bids and offers from its participants. These bids and offers in addition to the asking and selling price can also include a volume to be traded. In one embodiment, the bids and offers can be made binding to prevent participants from entering false bids in order to influence the market. Furthermore, to prevent participants from unduly influencing the market, a participant whose bid price is met, that is the bid price is at least that of the fixed price can be prohibited from selling during the volume matching. Likewise, a participant whose offer price is met, that is the offer price is at most that of the fixed price can be prohibited from buying during the volume matching. Based on these bids and offers the system can select a fixed price.
Figure 12A is a screen shot of an example of how a participant can be solicited for bids and offers. In the depicted example, when the system solicits bids and offers, a predetermined time limit is imposed after which bids and offers are no longer accepted. The amount of time remaining to enter a bit is shown in field 1202. In column 1204, the notional amount of the bid/offer is shown. In this example, the volume is fixed for all participants, in other embodiments, this amount can be entered by the participant. In column, 1206, the bid prices are entered by the participant for each credit derivative and in column 1208, the offer prices are entered by the participant. The system can also safeguard against choice prices, that is a bid equal to an offer, and inverted prices, that is a bid greater than an offer. Once the time limit has expired, all valid submissions by the participants are collected by the system and a fixed price is determined.
Figure 12B is a screen shot of an example of how a participant can perform volume matching. Once again the amount of time remaining to change the order is shown in field 1202. Column 1210 shows the fixed price for each of the credit derivatives. If the participant's bid price is greater than or equal to the fixed price the participant is required to buy at the fixed price. In this case, the participant can specify an additional amount to buy at the fixed price by entering it into the appropriate field of column 1212. If the participant's offer price is lower than the fixed price, the participant is required to sell at the fixed price. In this case, the participant can specify an additional amount to sell at the fixed price, by entering it into the appropriate field of column 1214. If the fixed price is between the participant's offer price and bid price, the participant can elect to either sell or buy an amount of credit derivative at the fixed price, but not both. Once the time limit has expired, all additional orders are processed by the system. The method of filling the orders is similar to that described in the volume matching described above, except that a priority is assigned to those participants whose bids are closes to the fixed price.
Figure 12C is a screen shot illustrating the results of the volume matching session. Columns 1216 and 1218 show the notional amount actually traded as a result of the trading activity described above. In this example, the participant's bid exceeded the fixed price so was obligated to buy 25MM units of Europe, but also requested to buy an additional 50MM units and successfully bought 75MM units. The participant was not obligated to buy or sell HiVoI, but request to by 75MM units of HiVoI. However, this order was not matched. The participant's offer was lower than the fixed price for Crossover, so the participant was obligated to sell IOMM units of Crossover. The participant''' also requested to sell another 40MM units of Crossover, however, only a partial order of 20MM units of Crossover was available leading to a total sale of 30MM units.
Figure 13 is a flow chart depicting a method of determining the fixed price based on the bids and offers by the participants. At step 1302, the system solicits bids and offers from the participants. At step 1304, the system waits a predetermined period of time. At step 1306, the system collects all valid bids and offers from the participants. At step 1308, the bids are sorted into a sequence with the highest bids first and the offers are sorted into a sequence with the lowest offers first. At step 1310, all bids except for a predetermined number of the highest bids and all offers except for a predetermined number of the lowest offers are discarded. For example, the highest half of the bids and the lowest half of the offers are kept. At step 1312, the average is computed by averaging all the bid prices and offer prices. In other embodiments where the volume can be specified along with the bid and offer prices, the average can be computed by a simple average where each bid price and offer price is accounted for once or by a weighted average where each bid price and offer price is averaged in based on the volume specified by the participant. This average is called the mid fixing At step 1314, a sequence of markets is created by pairing the sequence of bids with their counterparts in the sequence of offers, so that the highest bid and the lowest offer comprise the first market in the sequence, where a market comprises a bid and an offer. At step 1316, a determination is made as to whether the highest bid exceeds the lowest offer. If not, the price is fixed at the average in step 1318. If so, at step 1320, the market with the lowest bid and the highest offer where the bid is at least the offer is determined. This market is referred to as the last tradeable market. At step 1322, a determination is made as to whether the average is below the bid of the last tradeable market, above the offer of the last tradeable market or between the bid and the offer. If the average is between the offer and the bid. Then the price is fixed at the average in step 1318. If the average is below the bid, then the price is fixed at the bid of the last tradeable market at step 1324. If the average is above the offer, then the price is fixed at the offer of the last tradeable market at step 1326. Steps 1324 and 1326 are used to insure that a participant is not obligated to purchase at a price above his bid or to sell at a price below his offer.
Additionally, bid fixing and offer fixing can be used in determining the fixed price. The basic bid fixing calculation is to take the average of all bids which remain after step 1310. The basic offer fixing calculation is to take the average of all offers which remain after step 1310. The basic method can be adjusted so that if the bid fixing calculation exceeds the mid fixing the bid fixing is set to the mid fixing. Likewise, if the offer fixing calculation is below the mid fixing, the offer fixing is set to the mid fixing. Other methods can be used to calculate the bid fixing. The trades capped method takes all bids remaining after step 1310 and sets all bids greater than the mid fixing calculated in step 1312 to the mid fixing. After this all bids are averaged to generate the bid fixing. Similarly, all offers remaining after step 1310 are taken and all offers less than the mid fixing calculated in step 1312 are set to the mid fixing. After this, all offers are averaged to generate the offer fixing. The trades excluded method averages all bids remaining after step 1310 that are less than the mid fixing to generate the bid fixing. If no bids are below the mid fixing, the highest bid is taken as the bid fixing. Likewise, all offers remaining after step 1310 that are greater than the mid fixing are averaged to generated the offer fixing. If no offers are greater than the mid fixing, the lowest offer is taken as the offer fixing. In the examples shown, the mid fixing is used as the fixed price for the volume matching, however, the bid fixing iaiid'offef'fif Mg' can be used as a reference in future contracts as well as incorporated into the calculation of the fixed price in this or future sessions.
Figure 14 are two tables illustrating the method described above. In table 1402, the contributed bids and offers of eight participants are shown, hi table 1404, the bids and offers are sorted with highest bids and lowest offers first. In accordance with step 1310, only the top four pairs are kept so, only rows 1410, 1412, 1414, and 1416 are kept in the mid fixing calculation. Finally, rows 1410, 1412, and 1414 show bids that are greater than or equal to the offers. Row 1414 having the lowest bid and highest offer among this group making row 1414 the last tradeable market.
Figure 15 A is a summary print out of an actual fixed price trading session. The table on the left shows the bid, mid and offer fixing for three credit derivatives involved. On the right are three tables showing the bid prices and the offer prices for the three credit derivatives sorted by highest bid and lowest offer. In this example in calculating the bid, mid, and offer fixings the first half of the offers and bids are retained. Figure 15B is a print out of detailed results of the Europe credit index, showing the same bids and offers as the right side of Figure 15A,but also with statistical quantities such as the mean, standard deviations, and kurtosis, and a graph of the markets, graphed in the order displayed in the table. Figure 15C is a print out of detailed results of the HiVoI credit derivative, showing similar categories of results as in Figure 15B. Figure 15D is a print out of detailed results of the Crossover credit derivative, showing similar categories of results as in Figure 15B.
As mentioned above, system 100 comprises a standardized interface configured to make transacting in system 100 quick and efficient. Thus, the standardized interface allows each of the trader clients to interface with credit derivative authority 102 and view information on a plurality of credit derivative's that is displayed'' in a compact and uniform format. Example formats were described above, e.g., in relation to figure 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 to figure 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, 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 matching 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. Figure 9 is a screen shot of an example of a Volume Matching display showing credit derivatives that the participant can trade. Column 902 represents the credit derivative to be traded and the price. Column 904 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. i
Figure 10 is a ' screen 'shόfδFan "example of a method by which an interested participant can participated in volume matching. Field 1002 shows the credit derivative and the price it is being traded at. The participant can select button 1004 and enter a notional amount into field 1006 that he desires to buy the credit derivative or alternatively the participant can select button 1008 and enter a notional amount into field 1010 that he desires to sell. The order is then placed by clicking on field 1012.
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.
Figure 11 is a table showing an example of how the trade matching works, hi table 1102, there are four buyers and three sellers with their respective orders listed in the order of their priority. In matching table 1104, buyer 1 is matched with seller 3 because their notional amounts match. Furthermore, buyer 2 is matched with seller 1 because their notional amounts match. Since the remaining orders no longer match, the orders can be split. Buyer 3 having priority over buyer 4 is matched with seller 2. Since seller 2's order is larger than buyer 3's order, the remaining notional amount of seller 2 is available to buyer 4. fn'e''sfan'(ϊaSϊzeBllhter!fkce'y'1'iturtlier 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 credit derivative authority 102 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. The other trader clients are then automatically updated, based on the deactivation and reactivation of positions, in real-time.
In certain embodiments, credit derivative authority 102 is configured to facilitate communication with trader clients via their terminals 108. This communication can be between trader clients, i.e., between terminals 108, and/or between trader clients and credit derivative authority 102, i.e., between terminals 108 and credit derivative authority 102. 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 credit derivative authority 102 and forwarded to the correct terminal 108, 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 between terminals''8 "and include" negotiation information. In other instances, the messages are between credit derivative authority 102 and a terminal 108 and include settlement information.
Figure 7 is a logical block diagram illustrating an example embodiment of a computer system 700 that is, for example, included in the computer system that comprises credit derivative authority 102. 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 system 700 of figure 7 is presented as a simple example of a processing system. In the example of figure 7, computer system 700 comprises a processor 710 configured to control the operation of computer system 700, memory 704, storage 706, a network interface 708, a display output 712, a user interface 714, and a bus 702 configured to interface the various components comprising computer system 700.
Processor 710, 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. Processor 710 also comprise an execution area into which instructions stored in memory 704 are loaded and executed by processor 710 in order to control the operation of computer system 700. Thus, for example, by executing instructions stored in memory 704, processor 710 causes credit derivative authority 102 to execute the steps described above.
Memory 704 comprises a main memory configured to store the instructions just referred to. In one embodiment, memory 704 also comprise secondary memory used to temporarily store instructions or to store information input into computer system 700, i.e., memory 704 acts as scratch memory also. Memory 704 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. Storage 706 includes, in certain embodiments, a plurality of drives configured to receive various electronic media. For example, in one embodiment, storage 706 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, storage 706 also includes disk drives, which can include removable disk drives. The drives included in storage 706 are used to receive electronic media that has stored thereon instructions to be loaded into memory 704 and used by processor 710 to control the operation of computer system 700.
Network interface 708 is configured to allow computer system 700 to interface with, and communicate over, network 106. Thus, using a network interface, such as network interface 708, credit derivative authority 102 is able to communicate with terminals 108. Depending on the embodiment, credit derivative authority 102 includes one or multiple network interfaces 708.
Display interface 712 can be configured to allow computer system 700 to interface with a display. Thus, in certain embodiments, computer system 700 displays information to a user via display interface 712.
User interface 714 is configured to allow a user to interface with computer system 700. Thus, depending on the embodiment, user interface 714 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 credit derivative authority 102 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

What is claimed:
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 from each of a plurality of trader clients a position having a bid price, an offer price or both; determine a fixed price by determining the mid fixing point by averaging a collection of bid prices and offer prices from he positions of the plurality of the trader clients, determining the a tradeable market having a bid price and an offer price, assigning the mid fixing point to the fixed price if there is no last tradeable market found or if the mid fixing point lies between the bid price and offer price, assigning the bid price of the last tradeable market to the fixed price if the mid fixing point is less than the bid price; and assigning the offer price of the last tradeable market to the fixed price if the mid fixing point is greater than the offer price; finalize the sale at the fixed price of all positions which have an offer price lower than the fixed price; and finalize the purchase at the fixed price of all positions which have a bid price greater than or equal to the fixed price.
2. The credit authority of claim 1, wherein the position further comprises a volume and wherein the averaging a collection of bid prices and offer prices is performing an average weighted by the volume.
3. The credit authority of claim 1, wherein the collection of bid prices and offer prices is formed by selecting the highest N bid prices and lowest N offer prices from the positions of the plurality of the trader clients.
4. The credit authority of claim 3, wherein N is equal to about half the number of positions received.
5. The credit authority of claim 1, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to accept positions from the plurality of trader clients; and discard all positions received after the predetermined period of time has expired.
6. The credit authority of claim 1, wherein the instructions are further configured to cause the processor to offer each of the plurality of trader clients whose position's bid price is less than the fixed price and offer price is greater than the fixed price, the option to place a transaction request at the fixed price; receive a plurality of transaction requests from the plurality of trader clients match the transaction requests of the plurality of trader clients to each
other; and finalize the transactions of all positions which are matched at the fixed price.
7. The credit authority of claim 6, wherein the instructions are further configured to cause the processor to offer each of the plurality of trader clients whose position's bid price is greater than or equal the fixed price the option to place a transaction request at the fixed price for buying only.
8. The credit authority of claim 1, wherein the instructions are further configured to cause the processor to offer each of the plurality of trader clients whose position's bid price is greater than the fixed price, a purchasing option to purchase a greater volume at the fixed price; offer each of the plurality of trader clients whose position's offer price is less than the fixed price, a selling option to sell a greater volume at the fixed price; receive at least one purchasing requests from the plurality of trader clients; receive at least one selling request from the plurality of trader clients; match the at least one purchasing request and the at least one selling request to each other; and finalize the transactions of all positions which are matched at the fixed price. 97 The credit authority 'of claim 8, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to accept purchasing and selling requests from the plurality of trader clients; and discard all purchasing and selling requests received after the predetermined period of time has expired.
10. A method for online trading of credit derivatives, comprising: receiving from each of a plurality of trader clients a position having a bid price, an offer price or both; determining a fixed price comprising: determining the mid fixing point by averaging a collection of bid prices and offer prices from the positions of the plurality of the trader clients, determining the a tradeable market having a bid price and an offer price; assigning the mid fixing point to the fixed price if there is no last tradeable market found or if the mid fixing point lies between the bid price and offer price; assigning the bid price of the last tradeable market to the fixed price if the mid fixing point is less than the bid price; and assigning the offer price of the last tradeable market to the fixed price if the mid fixing point is greater than the offer price; finalizing the sale at the fixed price of all positions which have an offer price lower than the fixed price; and finalizing the purchase at the fixed price of all positions which have a bid price greater than the fixed price. 11. The method of claim 10, wherein the position further comprises a volume and wherein the determining the mid fixing point by averaging a collection of bid prices and offer prices is performing an average weighted by the volume.
12. The method of claim 10, wherein the collection of bid prices and offer prices is formed by selecting the highest N bid prices and lowest N offer prices from the positions of the plurality of the trader clients.
13. The method of claim 12, wherein N is equal to about half the number of positions received.
14. The method of claim 10, further comprising: waiting a predetermined period of time to accept positions from the plurality of trader clients; and discarding all positions received after the predetermined period of time has expired.
15. The method of claim 10, further comprising: offering each of the plurality of trader clients whose position's bid price is less than the fixed price and offer price is greater than the fixed price, the option to place a transaction request at the fixed price; receiving a plurality of transaction requests from the plurality of trader clients matching the transaction requests of the plurality of trader clients to each other; and finalizing the transactions of all positions which are matched at the fixed price. 16. The method of claim 15, further comprising: waiting a predetermined period of time to accept transaction requests from the plurality of trader clients; and discarding all transaction requests received after the predetermined period of time has expired.
17. The method of claim 10, further comprising: offering each of the plurality of trader clients whose position's bid price is greater than the fixed price, a purchasing option to purchase a greater volume at the fixed price; offering each of the plurality of trader clients whose position's offer price is less than the fixed price, a selling option to sell a greater volume at the fixed price; receiving at least one purchasing requests from the plurality of trader clients; receiving at least one selling request from the plurality of trader clients; matching the at least one purchasing request and the at least one selling request to each other; and finalizing the transactions of all positions which are matched at the fixed price.
18. The method of claim 17, further comprising: waiting a predetermined period of time to accept purchasing and selling requests from the plurality of trader clients; and discarding all purchasing and selling requests received after the predetermined period of time has expired. 19. 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 from each of a plurality of trader clients a position having a bid price, an offer price or both; determine a fixed price based on the bid prices and the offer prices of all received position from the plurality of trader clients; finalize the sale at the fixed price of all positions which have an offer price lower than the fixed price; and finalize the purchase at the fixed price of all positions which have a bid price greater than the fixed price.
20. The credit authority of claim 19, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to accept positions from the plurality of trader clients; and discard all positions received after the predetermined period of time has expired.
21. The credit authority of claim 19, wherein the instructions are further configured to cause the processor to offer each of the plurality of trader clients whose position's bid price is less than the fixed price and offer price is greater than the fixed price, the option to place a transaction request at the fixed price; receive a plurality of transaction requests from the plurality of trader clients match the transaction requests of the plurality of trader clients to each other; and finalize the transactions of all positions which are matched at the fixed, price.
22. The credit authority of claim 21, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to accept transaction requests from the plurality of trader clients; and discard all transaction requests received after the predetermined period of time has expired.
23. The credit authority of claim 19, wherein the instructions are further configured to cause the processor to offer each of the plurality of trader clients whose position's bid price is greater than the fixed price, a purchasing option to purchase a greater volume at the fixed price; offer each of the plurality of trader clients whose position's offer price is less than the fixed price, a selling option to sell a greater volume at the fixed price; receive at least one purchasing requests from the plurality of trader clients; receive at least one selling request from the plurality of trader clients; match the at least one purchasing request and the at least one selling request to each other; and finalize the transactions of all positions which are matched at the fixed price.
24. The credit authority of claim 23, wherein the instructions are further configured to cause the processor to wait a predetermined period of time to accept purchasing requests and selling requests from the plurality of trader clients; and discard all purchasing requests and selling requests received after the predetermined period of time has expired.
25. The credit authority of claim 19, wherein the fixed price is determined by averaging a collection of bid prices and offer prices from the positions of the plurality of the trader clients.
26. The credit authority of claim 25, wherein the position further comprises a volume and the fixed price is determined by performing a weighted average of a collection of bid prices and offer prices from the positions of the plurality of the trader clients using the volume as a weight.
27. The credit authority of claim 25, wherein the collection of bid prices and offer prices is formed by selecting the highest N bid prices and lowest N offer prices from the positions of the plurality of the trader clients.
28. The credit authority of claim 27, wherein N is equal to about half the number of positions received. 29. The credit authority of claim 19, wherein the fixed price is determined by determining the mid fixing point by averaging a collection of bid prices and offer prices from he positions of the plurality of the trader clients, determining the last tradeable market having a bid price and an offer price, assigning the mid fixing point to the fixed price if there is no last tradeable market found or if the mid fixing point lies between the bid price and offer price, assigning the bid price of the last tradeable market to the fixed price if the mid fixing point is less than the bid price; assigning the offer price of the last tradeable market to the fixed price if the mid fixing point is greater than the offer price.
30. The credit authority of claim 29, wherein the position further comprises a volume and the fixed price is determined by performing a weighted average of a collection of bid prices and offer prices from the positions of the plurality of the trader clients using the volume as a weight.
31. The credit authority of claim 29, wherein the collection of bid prices and offer prices is formed by selecting the highest N bid prices and lowest N offer prices from the positions of the plurality of the trader clients.
32. The credit authority of claim 31, wherein N is equal to about half the number of positions received.
33. A method for online trading of credit derivatives, comprising: receiving from each of a plurality of trader clients a position having a bid price, an offer price or both; determining a fixed price based on the bid prices and the offer prices of all received position from the plurality of trader clients; finalizing the sale at the fixed price of all positions which have an offer price lower than the fixed price; and finalizing the purchase at the fixed price of all positions which have a bid price greater than the fixed price.
34. The method of claim 33, further comprising: waiting a predetermined period of time to accept positions from the plurality of trader clients; and discarding all positions received after the predetermined period of time has expired.
35. The method of claim 33 , further comprising: offering each of the plurality of trader clients whose position's bid price is less than the fixed price and offer price is greater than the fixed price, the option to place a transaction request at the fixed price; receiving a plurality of transaction requests from the plurality of trader clients matching the transaction requests of the plurality of trader clients to each other; and finalizing the transactions of all positions which are matched at the fixed price.
36. The method of claim 35, further comprising: waiting a predetermined period of time to accept transaction requests from the plurality of trader clients; and discarding all transaction requests received after the predetermined period of time has expired.
37. The method of claim 33, further comprising: offering each of the plurality of trader clients whose position's bid price is greater than the fixed price, a purchasing option to purchase a greater volume at the fixed price; offering each of the plurality of trader clients whose position's offer price is less than the fixed price, a selling, option to sell a greater volume at the fixed price; receiving at least one purchasing requests from the plurality of trader clients; receiving at least one selling request from the plurality of trader clients; matching the at least one purchasing request and the at least one selling request to each other; and finalizing the transactions of all positions which are matched at the fixed price.
38. The method of claim 37, further comprising: waiting a predetermined period of time to accept purchasing requests and selling requests from the plurality of trader clients; and discarding all purchasing requests and selling requests received after the predetermined period of time has expired.
39. The method of claim 33, wherein deteπnining the fixed price comprises assigning the average of a collection of bid prices and offer prices from the positions of the plurality of the trader clients. 40. The method of claim 39, wherein the collection of bid prices and offer prices is formed by selecting the highest N bid prices and lowest N offer prices from the positions of the plurality of the trader clients.
41. The method of claim 40, wherein N is equal to about half the number of positions received.
42. The credit authority of claim 33, wherein the position further comprises a volume and determining the fixed price comprises assigning the weighted average of a collection of bid prices and offer prices from the positions of the plurality of the trader clients using the volume as a weight.
43. The method of claim 43, wherein the collection of bid prices and offer prices is formed by selecting the highest N bid prices and lowest N offer prices from the positions of the plurality of the trader clients.
44. The method of claim 44, wherein N is equal to about half the number of positions received.
45. The method of claim 33, wherein determining the fixed price comprises: determining the mid fixing point by averaging a collection of bid prices and offer prices from the positions of the plurality of the trader clients, determining the last tradeable market having a bid price and an offer price, assigning the mid fixing point to the fixed price if there is no last tradeable market found or if the mid fixing point lies between the bid price and offer price, assigning the bid price of the last tradeable market to the fixed price if the mid fixing point is less than the bid price; assigning the offer price of the last tradeable market to the fixed price if the mid fixing point is greater than the offer price.
46. The method of claim 45, wherein the position further comprises a volume and determining the mid fixing point by averaging a collection of bid prices is determining the mid fixing point by a weighted average of a collection of bid prices weighted by volume.
47. The method of claim 46, wherein the collection of bid prices and offer prices is formed by selecting the highest N bid prices and lowest N offer prices from the positions of the plurality of the trader clients.
48. The method of claim 47, wherein N is equal to about half the number of positions received.
49. 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.
50. The credit derivative authority of claim 49, 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.
51. The credit derivative authority of claim 49, 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.
52. The credit derivative authority of claim 49, 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.
53. The credit derivative authority of claim 49, 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. 54. The credit derivative authority of claim 49, 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.
55. The credit derivative authority of claim 49, wherein the volume associated with the position is a standard or default volume.
56. The credit derivative authority of claim 49, 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.
57. The credit derivative authority of claim 49, 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 original volume.
58. 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.
59. The credit derivative authority of claim 58, wherein the first option comprises a plurality of fixed volumes and a no increase selection.
60. The credit derivative authority of claim 58, wherein the first option comprises a plurality of fixed volume increases and a no increase selection.
61. The credit derivative authority of claim 58, wherein the second option comprises a plurality of fixed volumes and a no increase selection.
62. The credit derivative authority of claim 58, wherein the second option comprises a plurality of fixed volume increases and a no increase selection.
63. The credit derivative authority of claim 58, 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.
64. The credit derivative authority of claim 58, 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.
65. The credit derivative authority of claim 58, 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.
66. 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 of 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.
67. The method claim of 66, 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. 68. The method claim of 66, wherein the first option comprises a plurality of fixed volumes and a no increase selection.
69. The method claim of 66, wherein the first option comprises a plurality of fixed volume increases and a no increase selection.
70. The method claim of 66, 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.
71. The method claim of 70, 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.
72. The method claim of 70, wherein the second option comprises a plurality of fixed volumes and a no increase selection.
73. The method claim of 70, wherein the second option comprises a plurality of fixed volume increases and a no increase selection.
74. 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.
75. The method of claim 74, wherein the first option comprises a plurality of fixed volumes and a no increase selection.
76. The method of claim 74, wherein the first option comprises a plurality of fixed volume increases and a no increase selection.
77. The method of claim 74, wherein the second option comprises a plurality of fixed volumes and a no increase selection.
78. The method of claim 74, wherein the second option comprises a plurality of fixed volume increases and a no increase selection.
79. The method of claim 74, 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. 80. The method of claim 74, 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.
81. The method of claim 74, 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.
82. 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 from each of a plurality of trader clients a position having a price and a notional; receive an acceptance from a client trader to the position of one of the plurality of trader clients; match the positions of the plurality of trader clients to each other based on the notional; and finalize the transactions of all positions which are matched at the price of the accepted position.
83. The credit authority of claim 82, wherein the instructions are further configured to cause the processor to offer each of the plurality of trader clients to participate in the transaction at the price of the accepted position, and receive a transaction request with a desired notional from one of the plurality of trader clients.
84. The credit authority of claim 82, wherein the instructions are further configured to cause the processor to offer each of the plurality of trader clients a new notional for trading at a specific price, and receive a confirmation from one of the plurality of trader clients.
85. The credit authority of claim 82, wherein the instructions are further configured to cause the processor to invite a plurality of other trader clients to participate in the transaction at the price of the accepted position and receive a position from one of the plurality of other trader clients.
86. The credit authority of claim 82, wherein the processor is caused to match the positions of the plurality of trader clients by assigning to each trader client a priority and by matching the highest priority trader client with a counterparty with a notional equal to the position of the highest priority trader client.
87. The credit authority of claim 83, wherein the processor is caused to match the positions of the plurality of trader clients by further matching each of the plurality of trader clients with a counterparty based on the priority and the notional.
88. A method for online trading of credit derivatives, comprising: receiving from each of a plurality of trader clients a position having a price and a notional; receiving an acceptance from a client trader to the position of one of the plurality of trader clients; matching the positions of the plurality of trader clients to each other based on the notional; and finalizing the transactions of all positions which are matched at the price of the accepted position.
89. The method of claim 88, further comprising: offering each of the plurality of trader clients a new notional for trading at a specific price; and receiving a confirmation from one of the plurality of trader clients.
90. The method of claim 88, further comprising: offering each of the plurality of trader clients a change in the notional of the position and receiving a new notional request from one of the plurality of trader clients.
91. The method of claim 88, further comprising: inviting a plurality of other trader clients to participate in the transaction at the price of the accepted position; and receiving a position from one of the plurality of other trader clients.
92. The method of claim 88, wherein the matching the positions of the plurality of trader clients comprises: assigning to each trader client a priority; and matching the highest priority trader client with a counterparty with a notional equal to the position of the highest priority trader client. 93. The method of claim 92, wherein the matching the positions of the plurality of trader clients further comprises matching each of the plurality of trader clients with a counterparty based on the priority and the notional.
EP05803637A 2004-09-29 2005-09-29 Systems and methods for an online credit derivative trading system Ceased EP1810240A4 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/954,629 US7698208B2 (en) 2002-12-09 2004-09-29 Systems and methods for an online credit derivative trading system
US10/957,217 US7716114B2 (en) 2002-12-09 2004-10-01 Systems and methods for an online credit derivative trading system
PCT/US2005/034832 WO2006039340A2 (en) 2004-09-29 2005-09-29 Systems and methods for an online credit derivative trading system

Publications (2)

Publication Number Publication Date
EP1810240A2 EP1810240A2 (en) 2007-07-25
EP1810240A4 true EP1810240A4 (en) 2008-12-24

Family

ID=36143019

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05803637A Ceased EP1810240A4 (en) 2004-09-29 2005-09-29 Systems and methods for an online credit derivative trading system

Country Status (4)

Country Link
EP (1) EP1810240A4 (en)
JP (1) JP2008515104A (en)
AU (1) AU2005292054A1 (en)
WO (1) WO2006039340A2 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0705827D0 (en) * 2007-03-26 2007-05-02 Univ Southampton Exchanges for creating and trading derivavtive securites

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6421653B1 (en) * 1997-10-14 2002-07-16 Blackbird Holdings, Inc. Systems, methods and computer program products for electronic trading of financial instruments
US6304858B1 (en) * 1998-02-13 2001-10-16 Adams, Viner And Mosler, Ltd. Method, system, and computer program product for trading interest rate swaps
US6363360B1 (en) * 1999-09-27 2002-03-26 Martin P. Madden System and method for analyzing and originating a contractual option arrangement for a bank deposits liabilities base
US20040024692A1 (en) * 2001-02-27 2004-02-05 Turbeville Wallace C. Counterparty credit risk system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Also Published As

Publication number Publication date
WO2006039340A3 (en) 2006-06-29
WO2006039340A2 (en) 2006-04-13
EP1810240A2 (en) 2007-07-25
JP2008515104A (en) 2008-05-08
AU2005292054A1 (en) 2006-04-13

Similar Documents

Publication Publication Date Title
US7801805B2 (en) Systems and methods for an online credit derivative trading system
US7698208B2 (en) Systems and methods for an online credit derivative trading system
US20080033867A1 (en) Centralized process for determining deltas for index tranches
US20070198391A1 (en) Method and system for conducting a block auction
US8645260B2 (en) Systems and methods for market order volume clearing in online trading of credit derivatives
US20070055607A1 (en) Midpoint matching system
US20060293996A1 (en) Systems and methods for vending and acquiring order priority
US11310168B2 (en) Activity based electrical computer system request processing architecture
US20040111355A1 (en) Systems and methods for tracking price information in an online credit derivative trading system
US7587355B2 (en) Systems and methods for an online credit derivative trading system
US20090055306A1 (en) Systems and Methods for Limit Order Volume Clearing in Online Trading of Credit Derivatives
US20240104585A1 (en) Systems and methods for dynamic formation of anonymous market for over-the-counter trading
US8838497B2 (en) Systems and methods for an online credit derivative trading system
WO2006039340A2 (en) Systems and methods for an online credit derivative trading system
EP4193325A1 (en) Systems and methods for list trading of asset-backed securities
CA2693150A1 (en) Systems and methods for volume clearing in online trading of credit derivatives

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070419

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1107860

Country of ref document: HK

A4 Supplementary search report drawn up and despatched

Effective date: 20081121

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CREDITEX GROUP, INC.

17Q First examination report despatched

Effective date: 20090210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20101203

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1107860

Country of ref document: HK