US20030093360A1 - Systems, methods and computer program products for electronic trading of financial instruments - Google Patents

Systems, methods and computer program products for electronic trading of financial instruments Download PDF

Info

Publication number
US20030093360A1
US20030093360A1 US10/166,565 US16656502A US2003093360A1 US 20030093360 A1 US20030093360 A1 US 20030093360A1 US 16656502 A US16656502 A US 16656502A US 2003093360 A1 US2003093360 A1 US 2003093360A1
Authority
US
United States
Prior art keywords
trader
credit
order
trade
traders
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.)
Abandoned
Application number
US10/166,565
Inventor
R. May
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.)
GFInet Inc
Original Assignee
Blackbird Holdings 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
Application filed by Blackbird Holdings Inc filed Critical Blackbird Holdings Inc
Priority to US10/166,565 priority Critical patent/US20030093360A1/en
Publication of US20030093360A1 publication Critical patent/US20030093360A1/en
Priority to US11/541,515 priority patent/US20070219882A1/en
Assigned to BLACKBIRD HOLDINGS, INC. reassignment BLACKBIRD HOLDINGS, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: GFINET, INC.
Assigned to GFINET, INC. reassignment GFINET, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BLACKBIRD HOLDINGS, INC.
Abandoned legal-status Critical Current

Links

Images

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/08Insurance
    • 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
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/08Auctions
    • 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
    • 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/03Credit; Loans; Processing thereof
    • 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
    • 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/06Asset management; Financial planning or analysis

Definitions

  • the present invention generally relates to brokerage systems and methods, and more particularly, to the electronic trading of financial instruments such as derivatives.
  • the credit limits may be used by the host computer to establish the gross counterparty credit limit for each possible pair of parties and which may be equal to the minimum of the remaining credit (i.e., initial credit limit less any applicable transactions that have already been executed) from a first party to a second party and from the second party to the first party.
  • the host computer may block completion of an otherwise eligible matching transaction between a given pair of potential counterparties when the transaction has an associated value in excess of the applicable gross credit limit.
  • the various client site computers also referred to as keystations
  • the client sites may not have access to the credit limits set by their possible counterparties, or even to the identification of any other party to a particular transaction until after a transaction has been completed.
  • each client site may not have the ability to determine, prior to committing to buy or sell at a displayed price from one or more anonymous counterparties, whether it is in fact eligible to respond to any of the bids or offers currently being displayed.
  • the credit limit appears to be merely a cap value (or credit line) on the amount of trading one party will enter into with another party. It has little to no relationship to the credit risk the other party represents since the financial commitment associated with the financial instruments traded with this system ends at the consummation of the underlying contract. Thus, a cap value may be sufficient in this particular circumstance.
  • the central host computer may not utilize the credit information until after a match has been found between counterparties to determine if the counterparties have sufficient credit with one another to execute the trade.
  • Reuters Limited has apparently expanded the system described in Silverman et al. to include Forward Foreign Exchange contracts which are derivative instruments.
  • the Reuters Limited system introduces the concept of soft matching which makes trades on the basis of credit risk rather than settlement risk.
  • a trade is not confirmed until both parties obtain subsequent credit approval.
  • Either party can cancel the transaction under the guise of no credit available to the counterparty once they know who is the counterparty.
  • the Reuters Limited system is reportedly an unpopular solution to derivative trading via an electronic trading system.
  • Another automated trading system is disclosed in U.S. Pat. No. 5,375,055 issued to Togher et al. and assigned to Foreign Exchange Transaction Services, Inc.
  • the Togher et al. system is an anonymous trading system which may identify the best bids and offers from those counterparties with which each client site is currently eligible to deal, while maintaining the anonymity of the potential counterpart and the confidentiality of any specific credit limitations imposed by the anonymous potential counterparty.
  • This system is apparently designed to run as a closed system, with dedicated desktop terminals connected to various local computer centers, which are in turn connected to regional computers.
  • each client site may only be able to view one foreign currency at a time per screen.
  • the Togher et al. system is further limited by the fact that each client site may provide the system with only limited credit information for each potential counterparty (for example, a one bit flag indicating whether a predetermined limit has already been exceeded), and by the fact that each bid or offer for a particular type of financial instrument is apparently prescreened by the system for compatibility with that limited credit information before calculating an anonymous dealable price for presentation to the traders dealing with that particular financial instrument.
  • the prescreening in Togher et al. is a simple check to determine whether any credit remains between the two counterparties to the potential transaction, and thus may be performed using a simple yes/no preauthorization matrix.
  • the preauthorization matrixes may be maintained at each of the several regional nodes (also referred to as distributed nodes) of a distributed processing communication network, with each such regional node being connected by corresponding individual links of the communications network to the respective client sites for which it is responsible for distributing market information including customized dealable bid and offer prices, and global best prices.
  • the sensitive credit limit data indicating how much credit a particular client site is willing to extend to each possible counterparty is preferably maintained at an access node associated with that particular client, and a simple yes/no indication of whether the entity (for example, a trader, a trading floor, or a bank) associated with that particular client site is willing to transact business with a particular counterparty is transmitted to the other nodes of the communications network.
  • entity for example, a trader, a trading floor, or a bank
  • each of the relevant regional node computers i.e., the regional nodes closest to the particular client site and/or closest to the particular counterparty
  • changes in the credit state between a particular client site and a particular counterparty i.e., that credit is no longer available or credit is now available
  • any credit state information relevant to transactions between two client sites both associated with other distribution nodes may be altogether ignored.
  • the system displays the entire bid or offer as a dealable transaction, but apparently permits each client site to block any above-limit portion of any resultant buy or sell transaction during a subsequent deal execution/verification process. This may, however, add additional time consuming steps for the users of the Togher et al. system. Alternatively, possibly at the option of the party by or for whom the low limit has been set, the entire transaction may be blocked.
  • a preauthorization matrix may indicate whether sufficient credit remains to execute a predetermined standard deal amount in addition to, or instead of, a mere indication as to whether any credit from a particular potential counterparty had already been used up.
  • individual orders are not independently treated, and the user may not have the ability to look through the bids and offers and deal at a worst price, if the user so chooses because of a difference in counterparties credit qualities.
  • At least a first trader having an open quote that is displayable as the best dealable or regular dealable quote at any of the other trading floors is automatically alerted that their bid (offer) quotation is the best price available to at least one potential counterparty with whom mutual credit exists, and thus could be hit (taken) at any time.
  • the quoter is preferably also alerted if his/her quote is joined (i.e., equal to in price, but later in time) to such a best dealable or regular dealable price from another trading floor.
  • the auto-matching process does not enable the active trader to select a price other than the best price to trade. This may force the trader to accept what the system offers, even if the trader would prefer a different counterparty for credit reasons.
  • derivative products such as interest rate swaps, caps, floors, forward rate agreements (FRA), interest rate basis swaps, interest rate options, foreign exchange, switches, or any other over the counter derivative instruments.
  • derivative products are considered by many to be too complex to be efficiently handled within an electronic trading system.
  • derivative products are typically define by certain terms and conditions, and the different types of derivatives products are defined by different sets of terms and conditions.
  • an FRA is generally defined by a start time, an end time, an over date, and a floating rate option
  • an interest rate swap is generally defined by a start time, an end time, an over date, a floating rate option, a frequency of the fixed coupons, a basis, and a special rule(s) as applicable with some currencies.
  • the market information provided to the user is coded with credit preference data generated by referencing the complex credit preferences inputted by each user regarding all possible counterparties. Thus, potential counterparties are then able to identify which orders they are eligible to trade based upon the coded credit preference data.
  • the user is also provided with a feature whereby the user can input an interest reset risks portfolio into the system and then view his/her interest rate reset risk position relative to other counterparties that have inputted their respective interest rate reset risks portfolios in order to determine possible offsetting positions.
  • the user is also provided with a facility for placing orders for various financial instruments via an auction process whereby the system automatically matches all orders and determines the prices and quantities executed based on several guidelines including user credit preferences.
  • the user is provided with a switch auction facility whereby the user can use the auction process to trade forward rate agreement (FRA) switches with other counterparties utilizing the same credit preference screening.
  • FSA forward rate agreement
  • the central processing center multiple server modules operate simultaneously to perform various functions such as delivery of market information to the user, credit preference verification of a requested trade, execution of trades, term negotiation, acknowledgments, position discovery, and auction execution.
  • the central processing center also includes a database which provides persistent storage of information such as historical data, instrument definitions, user credit preferences, user and business unit data, and historical market data.
  • multiple software modules operate simultaneously to perform various functions at the front end of the system such as providing user interfaces, performing credit preference verification, and receiving inputted user data such as trade data and credit preferences.
  • the trader workstations are preferably implemented on desktop computers of the users via an Internet browser program, and therefore, do not require dedicated terminals on the users' desktops.
  • the communication between the trader workstations and the central processing center is preferably based on Internet Protocol (IP), and operates over the Internet in a secure mode.
  • IP Internet Protocol
  • a system for facilitating derivative trading comprises a communication network interconnecting a first user and a second user to a central processing center, and a market inventory module associated with the central processing center that provides the first and second users with essentially real-time order information regarding more than one financial instrument, wherein the order information includes requests to buy financial instruments and requests to sell financial instruments.
  • the system may include a trader module associated with each of the first and second users for receiving the real-time order information from the central processing center and for presenting the real-time order information to the first or second users according to respective user customized profiles.
  • the system may further include a credit preference module associated with each of the first or second users, wherein the credit preference modules indicate the trade eligibility of the respective first and second users for each request to buy or sell.
  • the system may comprise an execution module associated with the central processing center that processes a trade initiated by one of either the first or second users which desires to trade on an order posted in the order information by the other of the first and second users. In essence, the execution module processes the term negotiations and will-do-more services.
  • the system may comprise a settlement module associated with the central processing center for processing transactions and generating confirmation notices, which are submitted to both parties. The settlement module also calculates the commission fees.
  • the credit preference module described above may determine the trade eligibility based on credit preferences of both the first and second users.
  • This system may further include a switch module that receives interest rate swap positions from the first and second users, and determines relative position information for the first and second users.
  • a system for facilitating derivative trading wherein the system includes a plurality of interconnected user nodes configured to exchange order information via a central processing center.
  • the central processing center may comprise a first user node including a trader module that receives real-time order information and presents the real-time order information to a user according to the customized profiles defined by a first user, a credit preference module that includes credit preference data inputted by the first user for use in determining trade eligibility of trades proposed in the real-time order information with a second user, and an interface to a communications network that interconnects the plurality of user nodes.
  • Each user node may further include a switch module that receives interest rate swap positions from the first user and the second user, and that determines relative position information for the first user.
  • a system for facilitating derivative trading wherein such system includes a plurality of interconnected first and second users that exchange order information, and wherein each of the first and second users are connected to a central processing center.
  • the central processing center may comprise a group server that provides the first and second users with essentially real-time order information regarding more than one financial instrument.
  • the order information preferably includes requests to buy financial instruments and requests to sell financial instruments.
  • the central processing center may further comprise an execution module that can process a trade initiated by one of either the first and second users which desires to trade on an order proposed in the order information by the other of the first and second users.
  • This central processing center may further include an interface to a communications network that interconnects the plurality of first and second users to the central processing center.
  • FIG. 1 is a schematic diagram of a computer network implementing an electronic trading system in accordance with an embodiment of the present invention.
  • FIG. 2 is a block diagram illustrating the architecture and functionality of a central processing center in accordance with an embodiment of the present invention.
  • FIG. 3 is a block diagram illustrating the architecture and functionality of a trader system in accordance with an embodiment of the present invention.
  • FIG. 4 is a block diagram illustrating the architecture and functionality of a business unit proxy in accordance with an embodiment of the present invention.
  • FIG. 5 is an example of a command center interface.
  • FIGS. 6 A- 6 B are examples of different tabbed partitions of a user preference interface.
  • FIG. 7 is an example of a credit preference setting interface.
  • FIGS. 8A and 8B are examples of different tabbed partitions of a modify credit groups interface.
  • FIGS. 9A and 9B are examples of the new binary interface and complex preference interface respectively, which are accessible from the credit preference setting interface.
  • FIG. 10 is an example of a business unit information interface.
  • FIG. 11 is an illustration of the credit preference logic of an embodiment of the present invention.
  • FIG. 12 is an example of a market entry interface.
  • FIG. 13 is an example of a symbol definition interface.
  • FIG. 14A is an example of an passive order interface.
  • FIG. 14B is an example of an hit order interface.
  • FIG. 15 is an example of a market detail interface.
  • FIG. 16 is an example of an outstanding order blotter interface.
  • FIG. 17 is an example of a client monitor interface.
  • FIG. 18 is an example of a execution notification and quantity negotiation interface.
  • FIG. 19 is an example of a term negotiation interface.
  • FIG. 20 is an example of a user position portfolio interface.
  • FIG. 21 is an example of a switch interface.
  • FIGS. 22A and 22B are examples of an auction interface and a switch auction interface, respectively.
  • FIG. 23 is an example of a main screen interface in accordance with an embodiment of the present invention.
  • FIG. 24 is a flowchart of the credit preference feature in accordance with an embodiment of the present invention.
  • FIG. 25 is a flowchart of the subject based addressing feature in accordance with an embodiment of the present invention.
  • FIG. 26 is a flowchart of the execution of a trade in accordance with the embodiment of the present invention.
  • FIGS. 27A and 27B are flowcharts of a trade execution from the perspective of the user posting the order and the user acting on the order, respectively, and in accordance with an embodiment of the present invention.
  • FIG. 28 is a flowchart of the position discovery feature in accordance with an embodiment of the present invention.
  • FIG. 29 is a flowchart of the auction feature in accordance with an embodiment of the present invention.
  • FIG. 30 is a detailed flowchart of the auction feature in accordance with an embodiment of the present invention.
  • FIG. 31 is a flowchart of the calculation of the average auction price in accordance with an embodiment of the present invention.
  • FIG. 32 is a flowchart of the matching performed in an auction in accordance with an embodiment of the present invention.
  • FIG. 33 is a flowchart of the validation of a resulting order in an auction in accordance with an embodiment of the present invention.
  • FIG. 34 is a process flow diagram illustrating operations and functionality of the central processing center in accordance with an embodiment of the present invention.
  • the present invention provides for a standardized contract definition, and means for matching complex credit preferences of each counterparty before a trade is executed. Therefore, potential counterparty users are able to identify bids and offers that they are eligible to trade based on credit preference information provided before initiating a trade.
  • the present invention also permits users to place passive orders (bids or offers on the various financial products for other counterparties to actively choose from to hit (bids) or lift (offers), without the posting user doing anything further) or active orders (where the viewing user actively initiates the trade by selecting passive bids or offers which are already in the system). This gives a user maximum control over the order flow process. For instance, there may be a situation whereby the bids in a particular market are higher than the offers, but no trading is taking place.
  • the present invention also provides financial markets with electronic trading systems and methods for identifying possible counterparties and executing trades for forward rate agreement (FRA) switches and other financial products.
  • the present invention further provides the ability for the users to place orders for various financial instruments via an auction process that can be one-to-many or many-to-many, whereby the system automatically matches all orders and determines the prices and quantities executed on the basis of several guidelines or parameters.
  • a further feature of the present invention is an auction trading that is available to users, whereby users can use an auction process to trade FRA switches with the other counterparties. This form of auction is referred to hereinafter as a switch auction.
  • the price is preferably predetermined by the system prior to the auction taking place.
  • the prices determined by the system are referred to hereafter as the fair price.
  • the present invention may be embodied as a method, a data processing system, or a computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program code means embodied in the storage medium. Any suitable computer readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.
  • These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks.
  • the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
  • blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
  • a trading system in accordance with the present invention is an electronic brokerage system which may use Internet protocol-based communications networks for facilitating the trading (i.e., buying and selling) of financial derivatives by users, each of which is associated with the user's own desktop computer system (trader system) located on the trading floor of a financial institution (client site), as described below.
  • the present invention is preferably implemented by a Java-based software program, though other suitable program languages can be utilized such as dynamic hypertext markup language (DHTML), C+ or C+.
  • DHTML dynamic hypertext markup language
  • a trading system 10 in accordance with the present invention comprises a central processing center 12 which is in communication with the client sites 14 via one or more of a variety of Internet protocol based networks 16 .
  • a private extranet, a public Internet, and a third party extranet are show, though it will be recognized by those skilled in the art that other networks such as the Public Switch Telephone Network (PSTN) may be implemented as a network 16 .
  • PSTN Public Switch Telephone Network
  • the user is provided redundancy in case one network experiences a service interruption, and the user is able to choose between the several networks 16 for primary access based on factors such as toll charges or bandwidth.
  • Each client site 14 includes one or more business unit servers 18 which, among other things, can store copies of the Java applets which can be utilized to implement the present invention.
  • the business unit servers 18 may also perform encryption/decryption functions for messages that are received and sent over the networks 16 .
  • the business unit servers 18 are preferably connected to the client sites 14 internal data network.
  • one or more trader workstations 20 may be connected to a business unit server 18 of a client site 14 .
  • a user's own desktop computer which is connected to the client's internal data network may function as a trader workstation 20 and run the Java-based software of the present invention to enable interaction with other trader workstations 20 via the central processing center 12 .
  • the central processing center 12 which includes a trade mechanism 30 , a group server mechanism 32 , auction mechanism 34 , and a switch mechanism 35 , all in accordance with the present invention.
  • the trade mechanism includes several modules including a market inventory module 38 , an execution module 40 , and a settlement module 42 .
  • the market inventory module 38 holds the passive orders for each market and broadcast the same to the trader workstations 20 when new orders are received, validates any proposed trade, performs a second and final credit preference check that cannot be performed at the trader workstation 20 , validates that both traders are still on-line (i.e., active), executes the trade, and sends out a status update to the traders.
  • the execution module 40 receives the executed trade and proposes a trade for a greater quantity if applicable (referred to as the will-do-more feature), and processes term negotiation if applicable.
  • the settlement module 42 calculates the appropriate commission, generates the confirmation, and sends the confirmation to the two parties.
  • the group server mechanism 32 interfaces the trader module 30 with the trader workstations 20 .
  • the central processing center 12 may include a plurality of group server mechanisms 32 , each of which preferably serves a subset of the users (i.e., trader workstation) of system 10 , though the system 10 may be implemented with only one group server mechanism 32 .
  • the group server mechanism 32 monitors the connection of each trader workstation 20 so that log-in and log-out times and usage can be monitored.
  • the group server mechanism 32 also caches market information being viewed at each trader workstation 20 and create an order identification code that uniquely identifies that order.
  • the credit preference information of all users is cached in by the group server mechanism 32 for delivery to each trader workstations 20 when the associated user logs in. Any changes in the credit preference setting by a trader are detected and forwarded to the trader workstations 20 of the other users.
  • the switch mechanism 35 is configured to receive a portfolio of interest reset risk for a plurality of users and provide the users with an anonymous view at their relative position to other possible counterparties and available trades that may offset the user's interest rate reset risk.
  • the auction mechanism 34 performs a switch auction function whereby orders or FRA's are received from the users and anonymously matched based on an algorithm that takes user credit preferences into consideration.
  • the trader mechanism 30 , group server mechanism 32 , auction/switch auction mechanism 34 , and switch mechanism 35 may be collectively implemented as market module 44 .
  • the central processing center 12 includes a processor 50 that communicates with the other elements within the central processing center 12 via a system interface 52 .
  • An input devise 54 for example a keyboard or a pointing device, is used to input data from a user, and a screen display device 56 , for example, a monitor, is used to output data to the user.
  • a memory 58 within a central processing center 12 includes the market module 44 and a conventional operating system 60 which communicates with the market module 44 and enables execution of the market module 44 (including the trade mechanism 30 , group server mechanism 32 , and auction mechanism 34 ) by processor 50 .
  • An external communication line 62 is provided to interface the central processing center 12 with other computer systems or computer-based devices such as networks 16 .
  • a hard disk 64 may be provided as a persistence memory device, as well known to the industry.
  • a relational database 66 resides on the hard disk 64 for maintaining information such as current state information for each trader workstations 20 , user and business unit data, financial instrument definitions, order states, transaction states, confirmation states, historical confirmation and transaction data, credit preferences of all business units, and historical market data.
  • a relational database 66 resides on the hard disk 64 for maintaining information such as current state information for each trade workstation 20 , user and business unit data, financial instrument definitions, order states, transaction states, confirmation states, historical confirmation and transaction data, credit preferences of all business units, and historical market data.
  • the relational database 66 is based on structured query language (SQL) management system, as well known in the industry.
  • the trader module 70 may be implemented as a component of a Java-capable Internet browser program 72 , such as Netscape Communicator® (Netscape Communication Company) or Microsoft® Internet Explorer (Microsoft Corporation) version 3.0 or higher.
  • the trader module 70 is a Java-based program that is downloaded as Java applets for each session and implemented by a Java virtual machine (JVM) 73 within the Internet browser 72 .
  • the JVM 73 of the Internet browser program 72 may be a stand alone software application, a plug-in application, or a helper application, all of which is well known in the art.
  • the trader module 70 includes a market interface module 74 , a credit preference module 76 , a symbol module 78 , switch module 80 , and an auction module 81 .
  • the market interface module 74 comprises one or more user interfaces for presenting information to the user.
  • a user interface is provided as a window within the context of the Internet browser program 72 .
  • a user interface in accordance with the present invention may take many forms such as a three dimensional virtual reality world based on virtual reality modeling language (VRML), an audio receiver/transmitter, or any other suitable form of interface between the user and trader workstations 20 .
  • the market interface module 74 comprises a control center interface, market entry interface, market detail interface, switch interface, and auction interface, all of which are described in more detail hereinafter.
  • the credit preference module 76 receives the stored credit preferences inputted by the user and stored at group server mechanism 32 .
  • the stored credit preferences include preferences directed to the other business unit's legal entities, and the preferences inputted by the other users directed toward the business unit's legal entity of the subject user.
  • the credit preference information is preferably stored in the database 66 (FIG. 2).
  • the credit preference module 76 may encode the order information being presented to the user with the credit preferences of the user and the credit preferences of counterparty that posted the order.
  • the credit preference module 76 also performs a credit preference check for each order when a trade is initiated.
  • portions of the credit check process may be performed by the market inventory module 38 of the central processing center 12 .
  • the credit preference module 76 at each trader workstation 20 comprises a simplified matrix of yes's and no's, and associated maturities. If the business unit has selected an even more complex method (i.e., complex), a unit (such as a risk quotient, i.e., RQ) by maturity is also required. The trader workstation 20 will therefore not be able to determine whether the full quantity can be traded. Thus, the market inventory module 38 repeats the credit check to ensure the very latest credit preferences are used (in case of any latency in updating the credit preferences at the trader workstations 20 ) and to complete any complex credit preference check for quantity.
  • the symbol module 78 stores the symbol definitions utilized for the subject-based addressing of the different financial instruments traded in the system 10 .
  • the symbol module 78 also provides means for defining new symbols for use with the system 10 .
  • the switch module 80 is configured to receive interest rate reset risk portfolios from the user which are sent to the switch mechanism 35 at the central processing center 12 .
  • the relative position information generated by the switch mechanism 35 is returned to the switch module 80 which presents the position information to the user via the market interface module 74 .
  • the auction module 81 is configured to receive multiple or batch orders on a single instrument at different price levels, and in case of a switch auction, to receive a interest rate reset risk portfolio from the user.
  • the inputted orders or portfolio is sent to the auction server 34 at the central processing center 12 where the auction or switch auction, respectively, is performed.
  • the resulting matches are returned to the auction module 81 which presents the results to the user via the market interface module 74 .
  • the trader workstations 20 includes a processor 82 that communicates with other elements within the trader via a system interface 84 .
  • An input device 86 for example, a keyboard or pointing device, is used to input data from the user, and a screen display device 88 , for example, a monitor is used to output data to the user.
  • a memory 90 within the trader workstations 20 includes the Internet browser program 72 (and thus, the trader module 70 ) and a conventional operating system 94 which communicates with the Internet browser program 72 and enables execution of the Internet browser program 72 (and thus, the trader module 70 ) by processor 82 .
  • the trader module is preferably implemented as a Java-based program that is downloaded into memory 90 for the execution during a single session, and the trader workstations 20 will not persistently store the trader module 70 . Further, as a Java-based program, the trader module 70 will be executed on a JVM 73 which is a component of the Internet browser program 72 .
  • An external communication link 96 is provided to interface the trader workstations 20 with other computer systems or computer-based devices such as respective business unit servers 18 .
  • a hard disk 98 may be provided as a persistent memory device, as well known in the industry.
  • the trader workstation 20 may comprise a desktop computer system as previously mentioned, or alternatively, the trader workstation may comprise a portable computing device such as a notebook computer, handheld PC, personal digital assistant (PDA) or any other suitable device capable of running an Internet browser program and creating a communication link for interfacing with a network.
  • PDA personal digital assistant
  • a user of the system 10 is not necessarily tied to a specific hardwired terminal, but has a virtual terminal that goes with the user wherever the user has access to a Java capable browser and Internet access.
  • the trader module 70 may be implemented as an independent program capable of establishing a communication link to the central processing center 12 via the Internet, a local area network (LAN), or a wide area network (WAN).
  • LAN local area network
  • WAN wide area network
  • the user can even have access to the system 10 via direct modem dial-in to the central processing center 12 over the public switched telephone network (PSTN) or Internet.
  • PSTN public switched telephone network
  • proxy agent 110 may perform numerous functions including decoding and encoding encrypted messages sent and received over networks 16 .
  • the proxy agent 110 manages traffic to and from the trader workstations 20 , and may provide other features such as document caching and network access control.
  • the proxy agent 110 may improve performance by storing and supplying frequently requested data to the trader workstations 20 , or by filtering and/or discarding information from the networks 16 .
  • proxy agent 110 resides on a business unit server 18 which is part of the respective client sites 14 internal data networks.
  • system 10 of the present invention may be implemented without business unit servers 18 , whereby the functionality of the proxy agent 110 may be incorporated into the trader module 70 of the respective trader workstation 20 ; such functionality including decoding and encoding encrypted messages, and network management.
  • the business unit server 18 includes a processor 112 that communicates with the other elements within the business unit server 18 via a system interface 114 .
  • An input device 116 for example, a keyboard or pointing device, is used to input data from a user, and a screen display device 118 , for example, a monitor, is used to output data to the user.
  • a memory 120 within the business unit server 18 includes the proxy agent 110 and a conventional operating systems 122 which communicates with the proxy agent 110 and enables execution of the proxy agent 110 by processor 112 .
  • An external communication link 124 is provided to interface the business unit server 18 with other computer systems or computer/based machines such as networks 16 and trader workstations 20 .
  • a hard disk 126 may be provided as a persistence memory device, as is well known in the industry.
  • the hard disk 126 may include trader data profiles 128 for each of the different trader workstations 20 associated with the business unit server 18 .
  • the trader data may be stored at the central processing center 12 so that the trader does not need to re-build his/her screens each time he/she longs onto the system 10 .
  • each trader workstations 20 at a client site 14 is able to access the system through the Internet browser program 72 operating on the user's desktop computer.
  • the user may run Java-based applets on the desktop computer in the Internet browser program 72 which may be up-loaded to the desktop computer system by one of three means: 1) accessing them from the hard disk of the desktop computer 2) downloading them across the network from a server on the internal data network of the client site, or 3) by downloading them directly from the central processing center.
  • the applets are loaded and running in the desktop computer of the user, the user is then able to access the system 10 and interact with other trader workstations 20 and engage in trading activities.
  • a preferred embodiment of the present invention also enables non-trader users at the client sites 14 , such as credit officers and other interested/relevant staff, to have access to the invention in the same manner as the users in order to monitor the trading activities, perform credit control or any other functions.
  • interfaces such as a command center interface, a market entry interface, a market details interface, an outstanding order interface, an historical order interface, and functions such as symbology, credit preference checking, term negotiation, automatic notification, interest rate reset risk switches, and order auction.
  • a user at a trader workstation 20 launches the Internet browser program 72 and goes to a particular address that connects the trader workstation 20 to the central processing center 12 .
  • This is preferably achieved by typing a known URL (Universal Resource Locator) in an address field of the Internet browser program 72 .
  • the user will be presented with a log-on screen which preferably requires the user to input a user name and password for identification, verification and security reasons.
  • the user will download (preferably from proxy agent 110 ) the Java applets which will run locally on the desktop computer comprising the trader workstation 20 .
  • the user may launch a local or network application that runs locally or on an attached server.
  • the application will enable a connection to system 10 over network 16 , much the same as numerous dial-up services such as AOL.
  • other information such as user defined preferences which are based on the trader's profile will be downloaded to the trader workstation 20 . This may include information on what the user is allowed to trade, what markets the user is interested in monitoring, and other user specific information that was previously been defined by the user or another individual such a credit officer or the like.
  • the command center interface 130 is the front end of the user interface which provides access to all other features of the present invention, as described below.
  • the command center interface 130 is a pop-up window rendered on the screen display device 88 . Note, however, when the command center interface is running, the user may be able to iconize (i.e., minimize) the Internet browser program 72 window, as may be desirable when the user no longer needs to view the Internet browser program 72 .
  • a user can access the features of the system 10 which enable the user to monitor and control their trading in the system 10 .
  • the user can access the following areas of functionality as menu options on the tool bar 132 : a market entry interface (described below with reference to FIG. 12), a credit settings interface (described below with reference to FIG. 10), a switch engine interface (described below with reference to FIG. 22), auction interface (See FIG. 13), tools, a user preference interface (described below with reference to FIGS. 6A and 6B), an historical order blotter interface (described below with reference to FIG. 17), an outstanding order blotter interface (described below with reference to FIG.
  • links to external applications such as MarketSheetTM (a trademark of TIBCO, Inc.) (referred to herein as the quote screen and graph screen for illustrative purposes), a logout interface (provides secure exit from the system 10 ), and a help interface where detailed on-line help is provided.
  • MarketSheetTM a trademark of TIBCO, Inc.
  • logout interface provide secure exit from the system 10
  • help interface where detailed on-line help is provided.
  • the menu options that appear in the tool bar 132 are preferably customizable to a user, and those described are merely illustrative.
  • the command center interface 130 provides a message display window 134 for displaying real-time messages. These messages include system information, market information, requests-for-prices (RFPs), requests-for-switch (RFS) or online chat sessions with the users of the system 10 . Below the message display window 134 , the command center interface 130 displays the user's name 136 , the user's default currency 138 , the user's business unit 140 , and other relevant information. The background color of the message display window preferably changes if the connection to the central processing center 12 is lost for any reason.
  • a user preferences interface 148 which is accessible from the command center interface 130 via the tool bar 132 , provides a user with user preference features, such as those illustrated in FIGS. 6A and 6B.
  • a Derv Filters tab enables a user to set request-for-price (RFP) filters for viewing different derivative instruments based on the type (i.e., class) of derivative instruments and the currency. The user may also select the manner of presentation (ie., highlighted or not).
  • RFP request-for-price
  • an Environment tab enables a user to select viewing options to change the appearance of the display.
  • the color coding display option it is noted that the user can select not to have order information color coded by selecting color blind user. In such a case, other means of notation are utilized such as markings or symbols, as may be desirable if the user is color blind or using a monochrome screen display device 88 .
  • User defaults for Credit Group, Instrument Class and SWF Currency may also be selected via the environment tab.
  • the symbology will, among other things, ensure that the symbols are intuitive to the trading community, allow new symbols to be system generated when new instruments are introduced, and enable detailed confirmations to be prepared. These goals are generally accomplished by systematically dividing the parameters, terms, and conditions defining these derivatives instruments into a four-part subject code.
  • This four-part subject code enables the users to reference these instruments via a form known as subject-based addressing.
  • the four-part subject code is divided as follows: SOURCE.CLASS.SYMBOL.CURRENCY. Each field of the four-part subject code is defined below.
  • the source field of the symbology identifies the source of the information. In most cases, this will be the code DNI (i.e., Derivatives Net, Inc.), the assignee of the present invention. If the symbol is used within the system 10 , then the source field of the symbology will be assumed to be DNI, and will be omitted. If the symbol is used in a larger context, then the source will be identified. If, for example trade data were to be distributed and accessed via a third-party data distribution system such as the type operated by Reuters, Inc., then the source field of the subject code would be used.
  • DNI Derivatives Net, Inc.
  • the class field identifies the principal product class into which the financial instrument falls.
  • the class parameter is designed to group financial contracts together which share similar attributes.
  • eleven classes of instruments each with distinct characteristics covering forward rate agreements, interest rate swaps, interest rate basis swaps, interest rate options, foreign exchange and switches, will be covered. It is noted that a switch is the simultaneous purchase and sale of two instruments within the same class. The following is a listing of the eleven classes and the associated abbreviation for each:
  • SWP interest rate swap
  • CAP interest rate option (cap or floor)
  • IBS interest rate basis swap (floating vs. floating swap)
  • SWT switch any other pair of instruments in the same class
  • the symbol field is the principal code used to define each instrument.
  • the symbol field is the most explicit field of the subject code. This component of the naming convention enables the underlying structure of the derivative instrument to be defined. A simple description (e.g., 1yrswap) could be used, but this does not allow new derivative instruments to be easily added.
  • the legend below defines the parameters for defining each of the different instruments or classes. The symbol relies on the definitions of the underlying parameters, which will allow further break down or definition.
  • FLOPT is a two letter code which describes the variable rate index to be used, and will include: the designated maturity, index name, source, non-business day convention and calculation description.
  • the symbols of the present embodiment are as follows:
  • FRA [START, END, OVER, FLOPT]
  • SWP [START, END, OVER, FXDBASIS, FLOPT, SPECIAL RULE]
  • CAP [START, END, OVER, FLOPT, TYPE, STRIKE ]
  • IBS [START, END, OVER, INDEX 1 , INDEX 2 , ARREAR]
  • FWD [CCY 1 (terms), CCY 2 (base), START, END, OVER]
  • FXS [CCY 1 (terms), CCY 2 (base), START, END, OVER]
  • SWF [FLOPT, DAY 1 , DAY 2 ]
  • SWT [ASSET 1 , ASSET 2 , CLASS]
  • CBS [START, END, OVER, INDEX 1 /CCY 1 , INDEX 2 /CCY 2 ]
  • START The START parameter is the month the contract commences offset from value date, i.e., 1,2,3, . . . ,13, . . . ,360.
  • value date i.e. 1,2,3, . . . ,13, . . . ,360.
  • the default setting for the START is (0) which represents that a contract starting with the current month. Also, see OVER below.
  • END is the final maturity from value date in months adjusted for the OVER, and represents the term, i.e., 1,2,3, . . . ,13, . . . ,360. If the value date is 28th of November, then a contract defied as [1,4 over the 12th] translates into a deal starting on the 12th of January and maturing on 12th of April.
  • OVER The OVER parameter represents a specific date in the appropriate month. For example, if today is the 3rd December (value date is the 5th of December), then a 1*4 over the 12th would start the 12th of January, the first date over one month but less than two months beyond the spot date. This allows a contract to be defined with any start date between days 1-31. Note that this represents the actual date and not the number of days forward.
  • the default setting for the OVER is (0), which represents spot starting.
  • Two other parameters are allowable: (I) which represents IMM (International Monetary Exchange) rolls (the system 10 covers the different IMM conventions defined by the currency market, that is, the third Wednesday or second Thursday) and (E) which represents rolls over the month-end.
  • IMM International Monetary Exchange
  • FLOPT The FLOPT parameter is a two-part code covering the frequency and the index type of the floating coupons, and represents the floating rate option as defined by ISDA.
  • the FLOPT parameter covers frequency, basis and source. Although each currency may have a default, most indices will be available.
  • OPTYPE The OPTYPE parameter is the option type: (E)uropean, (A)merican or (M)ultiple European.
  • STRIKE The STRIKE parameter indicates the cap or swaption's exercise rate or price set on the option. Any strike defined in the symbol as ATM (at-the-money) will be shown as such in this parameter. In such a case, the percentage or strike will be agreed through the term negotiated process discussed below.
  • SPECIAL RULE The SPECIAL RULE parameter is designed for currencies such as USD and CAD which are in particular markets that use few special conventions for trading. For example, semi-bond for spread trades and annual money for out-right swaps are widely used in these markets.
  • the SPECIAL RULE parameter allows the system 10 to set more than one set of defaults for any currency. This will allow the system 10 to know when the exchange of bonds is required following a transaction. The follow are the rules for the present embodiment:
  • the default in USD is annual money versus 3 month LIBOR. This rule defines semi-bond spread trades where bonds are exchanged in the terms negotiation function described below.
  • CAD spread trades The default in CAD is annual money (A/365 fixed) versus 3 month CDOR paid semi-annually. This rule defines semi-annual A/365 fixed versus 3 month CDOR paid semi-annually where bonds are exchanged in the terms negotiation function described below.
  • GBP spread trades The default in GBP is annual money (A/365 fixed) versus 6 month LIBOR. This rule defines semi-annual A/365 fixed versus 6 month LIBOR where bonds are exchanged in the terms negotiation function described below.
  • ARREAR The ARREAR parameter defines when the coupon(s) on a swap is both set and paid. Most interest rate swaps set their floating rate coupons at the beginning of the period and pay them at the end of a coupon period. In an ARREAR swap, however, the coupon is set and paid at the end of the period. This is commonly referred to as an arrears swap. The system 10 allows for this in the form of a basis swap.
  • DAY 1 / 2 The DAY 1 / 2 parameter is the number of calendar days offset from today to the start of each FRA in an FRA switch (class SWF). Thus, the DAY 1 / 2 parameter represents the setting day or date.
  • CCY 1 / 2 The CCY 1 / 2 parameter is the currency code and is defined by the ISO codes for foreign exchange instruments.
  • UNDERLYING SWAP The UNDERLYING SWAP parameter is the full symbol, alais or security ID of the interest rate swap that underlies an option.
  • INDEX 1 / 2 Basis Swaps are when both sides are a floating rate, and the index represents the FLOPT plus the currency code of each index.
  • the first listed index (INDEX 1 ) is paid by the buyer. Examples include 1L-USD, 3L-GBP, PR-USD, etc.
  • the second index (INDEX 2 ) is received by the buyer. These are substantially identical to the codes used in the switch mechanism 35 (FIG. 2). For currency basis swaps, it is assumed that an exchange of principals takes place at the start and end on the contract.
  • ASSET 1 / 2 The class SWT is provided to allow for the trading of switches in other classes other than FRAs.
  • ASSET 1 and ASSET 2 represent the symbol, alias or security I.D. of each underlying contract. Note that both should be provided from the same class of contracts.
  • SETTLE The SETTLE parameter is a flag indicating whether a swaption is cash or physical settlement. The default is cash (C).
  • An example of an order in accordance with the symbology of the present invention is DNI.FRA.1,4.0,3L.USD, where DNI is the source, FRA is the class, .1,4.0,3L is the symbol and USD is the currency.
  • the symbol field defines a 1 by 4 (i.e., 3 month starting in 1 month) FRA on a 3 month LIBOR spot starting. Note that a comma (,) is used in the symbol fields as a delimiter.
  • DNI.SWP.0,60,0,AB,6LA.DEM Another example of an order in accordance with the symbology of the present invention is DNI.SWP.0,60,0,AB,6LA.DEM, where DNI is the source, SWP is the class, 0,60,0,AB,6LA is the symbol and DEM is the currency.
  • the symbol field defines a five year (60 month) annual bond (AB) versus a 6 month LIBOR swap.
  • the Symbology described above is designed to capture the parameters or commercial terms of a derivatives instrument which affect the instrument's valuation.
  • the present invention provides a number of default values which are assumed at all times. For example, the following is an exemplary list of system default values.
  • ROUNDING The rates observed on the source page or document will be used unless otherwise agreed. Rates should be rounded to 5 decimal places after any operation of averaging.
  • RESET DATES This will be defined with reference to payment dates.
  • the reset dates should be offset by the standard number of days for the currency, for example, two business days for USD.
  • BUSINESS CENTERS TO APPLY TO RESET DAYS The business days used to define the current offset for reset dates is defined by the source and not the payments under the transaction. For example, London will always be used for LIBOR (the exception is for USD LIBOR which uses both London and New York City) and New York City for H.15 rates.
  • CALCULATION PERIODS First and not last convention. Therefore, the calculation period includes the first payment date but excludes the next payment date.
  • TERMINATION DATE All termination dates will be subject to adjustment if they fall on a non-business day.
  • ADJUST CALCULATION PERIOD The number of days is assumed to adjust if the payment days are adjusted for non-business days.
  • TRADE DAY The trade day is defined relative to the instrument and currency by the system 10 , and not by the location of either of the parties to tile transaction.
  • CANADIAN DOLLAR SWAPS The convention is to set quarterly and pay semi-annually using weighted averaging and compounding at the first rate.
  • DATES All dates are listed unadjusted for non-business days.
  • non commercial terms The difference between commercial and non-commercial terms can be vary ambiguous, and therefore, some of the terms designated as commercial below may be designated as non-commercial and become default settings so as to be part of the symbology parameter.
  • non-commercial terms have been given default values which the users can change by negotiating new values for these terms between themselves via the system 10 .
  • both counterparties (users) must agree on the new value to over-ride the system defaults.
  • Table 1 below provides a list of parameters that maybe negotiated, that is, the non-commercial terms: TABLE 1 PARAMETER DESCRIPTION SETTING Legal The format of the legal agreement used ISDA, BBA, FX Month-end Whether coupon payment dates roll on YES, NO month-end dates or not Settle For swaptions whether the contract is CASH, cash or physically settled PHYSICAL First Setting For swaps the first variable rate is SETTING normally known for spot starting displayed on instruments. The current setting can market entry quickly become off market on days interface. where the market moves substantially. The system will display the default at all time. ATM For options, symbols will be set up The system where the strike is defined as at-the- forward rate money (note: pre-defined strikes will will be also be available).
  • the actual strike will available be negotiated immediately following the transaction by the two parties.
  • Spot For foreign exchange swaps class FXS The system only
  • Base Switches will be transacted in the form The system of the relative price between the two mid price instruments being switched.
  • the base will be rate maybe negotiated immediately available following a transaction.
  • Bond Exchange For USD, CAD and GBP interest rate The system swaps transacted as a spread, the price will list the and number of bonds will be negotiated benchmark immediately following the transaction bonds to be used and will calculate a default price and number according to market convention.
  • the symbology of the present invention provides aliases.
  • An alias is merely an abbreviated version of the subject-based address for the more commonly used terms for an instrument.
  • the database 66 (FIG. 2) maintains a unique security identifier (such as a numeric code, e.g., 111222) for each symbol which can be used in the system 10 .
  • a unique security identifier such as a numeric code, e.g., 111222
  • the currency field of the symbology contains the code that defines the currency of the instrument represented.
  • the currency code is represented by the standard ISO currency codes, i.e., USD, DEM, JPY, GBP, FRF, NLG, BEF, AUD, CAD, ITL, ESP, DKK, SEK, EUR, etc.
  • the default currency will be set by each user in each user's preferences interface 143 (see FIG. 6B). This will allow the currency code field of the symbology to be omitted much of the time.
  • foreign exchange trades FXS
  • the currency code represents the currency which will be indexed in equal amounts for both the spot and forward coupons.
  • the credit preference feature of the present invention provides for the bilateral credit status between two entities to be captured, structured and used anonymously for the trading of a wide range of financial contracts.
  • credit information was primarily used to deal with settlement risk in trading spot foreign currency.
  • the credit line or limit is usually expressed in amounts of currency which equates with the quantity or volume of a particular trade. As trades are executed between counterparties, the amount of the limit is decreased in a corresponding amount to the trade executed until there is little or no remaining credit, and then further trading is prevented until the trades settle or the credit limit amount is re-set.
  • the credit preference feature of the present invention is configured to handle the significant long-term credit problems inherent in over-the-counter (OTC) derivatives transactions. These long-term credit problems are further compounded by the fact that there is no standard method for banks to internally monitor and manage their credit risks. Most banks have developed their own, often proprietary, methods of monitoring and measuring the credit risk embedded in large portfolios of derivatives. Furthermore, banks also have different methods for dealing with the many different financial instruments that exist in every market.
  • OTC over-the-counter
  • the credit preference feature of the present invention addresses these problems and provides a viable solution.
  • the credit preference feature of the present invention achieves this, at least in part, by introducing a measurement unit of credit risk referred to as risk equivalent (RQ) which allows for different instruments to be compared on a like basis using a standardized measuring methodology, which together with the concepts of contract maturity, credit groups, classes, credit preferences, legal entities and business units allow the system 10 to offer a solution to the credit risks embedded in bilateral, term derivatives contracts.
  • RQ risk equivalent
  • the present invention also provides for the designation of credit groups.
  • a credit group is a grouping of classes of financial contracts that a business unit wishes to be treated in a like manner for credit purposes.
  • three default credit groups will be available: (1) Derivatives—SWP, IBS, CAP, SOP, FRA, CBS; (2) Switches—SWT, SWF; and (3) foreign exchange. Any other combination may be set up by the business unit, as desired.
  • Credit preferences are the methods or rules selected by a business unit within a credit group for the system 10 to use to screen prices (bids or offers) and trades against all other legal entities.
  • the following three credit preferences are provided, though it will be appreciated by those of ordinary skill in the art that other credit preferences may be utilized in accordance with the present invention:
  • Method 1 Binary (simple yes/no)—This is used where mark-to-market (MTM) agreements exist between the counterparties. MTM are bilateral, collateral agreements which are common and reduce the credit risk between two parties to almost zero by the posting of collateral against the value of a portfolio of derivatives covered by a single ISDA (International Swap and Derivatives Association) master agreement.
  • MTM mark-to-market
  • Method 2 Line Binary—takes into account the maturity (quoted in months from trade date) of the financial contract.
  • Method 3 Complex—This is based on the RQ of each contract within maturity bands. The system calculates a RQ for each instrument in the form of a constant currency unit expressed as a percentage. Each business unit has the choice of using the system generated RQ unit or to provide their own.
  • a business unit makes a yes or no determination as to whether or not they will deal with a particular counterparty for a particular credit group.
  • the decision is binary; there is no maximum maturity limit (i.e., time limit) or quantity limit (i.e., amount) in the binary method.
  • the binary method is the broadest of the three credit preference definitions provided for herein. Typically, the binary method win be used to refuse credit, where MTM agreements exist or where the credit exposure is small (for example, in switches).
  • the line binary method it is assumed that the business unit will deal with a particular counterparty for a particular credit group. However, the line binary method adds a further restriction of a maximum maturity of any contract tradable. The added restriction is preferably expressed by the number of months into the future. The binary method is particularly well suited for used by institutions that are not yet using RQ units, but which desire a method to limit potential exposure to longer dated contracts (for example, a temporary step).
  • the complex method allows each business unit to exactly stipulate the amount of new risk that they are prepared to enter into with any other legal entity for each credit group by maturity band.
  • the complex method enables a business unit to specify not only a particular maturity, but also a particular quantity or amount based on a measure of RQ. Further, the complex method enables the business unit to specify this for more than one period in time. For example, a business unit can specify that for Bank A, they will do up to $100 million out for 5 years, and then only $50 million from thereafter out to 10 years, and nothing thereafter.
  • Risk is generally defined herein as the degree of uncertainty of future net returns. Credit risk is further defined as an estimate of the potential loss due to the inability of a counterparty to meet its obligations. Thus, while the risk in a particular transaction depends not only on the changes in market rates and credit standing of the counterparty to the transaction, the credit risk or exposure is the nominal amount that can be lost when a counterparty defaults on its obligation. As previously mentioned, the credit risk in a derivatives transaction is relatively complex. For instance, though derivative contracts come in many forms, the majority have a fair credit value of zero at the time the transaction is initially entered into. That is, no funds are transferred between the parties at the time the contract is created. Rather, the contract places an obligation on both over the term of the contract.
  • the RQ is a unit of credit risk which allows all contracts to be compared on a like basis, at virtually any point in time.
  • the RQ is the credit exposure in terms of a percentage of the principal.
  • RQ The calculation of RQ is based on the potential exposure averaged over a series of time points, weighed by an appropriate discount factor. There are several methods of calculating the exposure of a transaction, though the RQ is calculated herein using an option pricing approach, as described below.
  • ⁇ (t) is the daily volatility (in percent) that takes into account that both A(t) and L(t) are random.
  • a ( t ) *discountFactor( t,s )* x+ (1+floatingCoupon)*discountfactor( t,e )
  • fixCoupon 1*( e ⁇ s )/fixBasis*fixRate,
  • the credit preference of the present invention does much more than merely monitor the amount transacted between two counterparties and then reduce the amount available accordingly.
  • the prescreening performed by the credit preference of the present invention is used to prescreen possible trades based on each counterparty's credit preferences.
  • the present invention does not control a user trading and does not directly limit the user's future trading based upon the user's past trading. In fact, it is quite possible that a new transaction may reduce the exposure between two legal entities.
  • a user's business unit is responsible for monitoring the credit exposure of the business unit with respect to all legal entity counterparties, and for adjusting the credit preferences in the system 10 accordingly.
  • a credit decision for an OTC derivative is a function of, among other things, the composition of the user's current derivatives portfolio, the current level or prices of the financial markets, new financial transactions, and the rating or level of credit worthiness of each legal entity. Therefore, more sophisticated means such as the credit preference prescreening of the present invention is needed to adequately measure and manage credit exposure in the OTC derivatives market, as well as with other financial markets.
  • the present invention enables the user to set desired credit preferences for each legal entity via the credit preference interface 170 , as illustrated in FIG. 7.
  • a user can navigate to the credit preference interface 170 by selecting the credit settings button in the tool bar 132 of the command center interface 130 (FIG. 5).
  • the credit preference interface 170 enables the users to view and/or update credit preference settings in a clear, simple, comprehensive and intuitive manner.
  • the credit preference interface 170 may be used to view or input/amend the business unit's credit preferences.
  • the credit preference settings are preferably only viewable by users within a business unit, and amendable by users with the correct permissions, both of which may be designated by the financial institution or the business unit.
  • a business unit may also select to inherit credit preferences from another business unit within its family hierarchy.
  • the credit preference interface 170 includes a display window 172 that displays various information including an alphabetical listing of all other legal entities (i.e., financial institutions) that have access to the system 10 .
  • Each legal entity can be expanded via an expand button 174 to list the settings for all the credit groups that the user has selected to trade within that legal entity, as shown for the Merrill Lynch entry.
  • the settings displayed are for a designated default credit group 176 .
  • the user can modify the displayed credit groups by selecting the Modify Credit Groups button 178 which launches the modify credit group interface 180 , as illustrated in FIGS. 8A and 8B.
  • the modify credit group interface 180 enables the user to customize his/her class groups by providing functionality to perform such operations as adding and removing instruments from a class group, as illustrated in FIG. 8A. For instance, for a selected credit group 182 , a list 183 of instruments in that credit group is provided. Unassigned instruments can be added and member instruments can be removed. Further, credit groups 182 can be added and deleted via buttons 182 , 185 , respectively. In FIG. 8B, each credit group 182 may have bands of maturity 186 defined (i.e., added or deleted). Each class group preferably includes instruments that are closely related because the instruments in each class group are given the same credit preference setting, and therefore, the credit preference setting process may be simplified.
  • a preference setting column 187 provides the credit preference setting designated for the corresponding legal entity 183 .
  • the credit preference settings for any legal entity can be modified or selected via a drop-down dialog box 188 .
  • the user can select from a list of predefined credit preference option.
  • For a new line binary the user is prompted with a new line binary interface 189 in which the user can enter a maturity.
  • For complex the user is prompted with a complex preference interface 190 (FIG. 9B) in which the user can enter the exposure for each maturity band.
  • the complex credit preference settings and the RQ may be provided for each instruments designated as such by selecting an appropriate legal entity and then selecting the Complex Bands button 194 .
  • the credit preference will be assumed to be a simple binary (no). If after initially setting these preferences a new counterparty is added to the system, the preference for the new counterparty will be binary (no) for all users until they have specifically set a credit preference for the new counterparty.
  • the level column 196 displays the business unit's designation for each legal entity as to the levels A, B or C.
  • the level set for each legal entity may be provided by the system 10 via various interfaces such as a market detail interface (described below with reference to FIG. 15) to provide the trader with information with regard to the creditworthiness of the counterparty.
  • a business unit may assign one of the levels A, B or C against each legal entity. This is essentially a quick reference of credit worthiness for the user.
  • the columns 198 labeled S&P and Moody are industry credit ratings that are integrated into the credit preference interface 170 .
  • the industry credit ratings may be downloaded on a subscription basis via external communication interface link interface 62 (FIG. 2).
  • the last modified column and the modified by column identify the time and person that last modified that credit setting. As mentioned before, access to modify any of the credit preferences should be limited to a finance officer or credit officer of the legal entity.
  • the credit preference settings may be transferred via electron file transfer or inputted manually on-line at anytime, and as often as the user desires. Further, updates may be made for all credit groups and legal entities, or alternatively, updates can be just for individual settings.
  • the credit preferences interface 172 includes a BU Info button 202 which, if selected, brings up a business unit data interface 204 , as illustrated in FIG. 10.
  • the business unit data interface 204 enables the users to view helpful internal information about other legal entities.
  • the respective business units define what information is included in the business unit data interface.
  • the business unit data interface 204 of FIG. 10 provides the internal facility number, telephone number, internal reference number, internal net MTM, internal gross MTM, and internal number deals of a business unit.
  • a business unit may include a contact name or other business unit specific data.
  • FIG. 11 illustrates a portion of the credit data which is stored by the system 10 in order to implement the credit preference feature of the present invention.
  • Each column represents the credit preference (i.e., binary, line binary, or complex) which is stored anonymously for each business unit against each legal entity across all credit groups.
  • the vertical and horizontal bars 210 represent the information which business unit ( 3 ) requires to determine the credit preference status of an order.
  • the information in columns 210 provides the credit preferences which business unit ( 3 ) has set against all other legal entity
  • row 211 provides the credit preferences which all other business unit s have set against business unit ( 3 )'s legal entity, that is, legal entity ( 3 ).
  • the depth 216 of the graph is divided into the different credit groups such as switch, derivative, and foreign exchange.
  • the triangles 212, 214 mark the cells that include the information which is used by business unit ( 3 ) to encode a specific order from business unit ( 5 ) of legal entity ( 5 ) with credit status information for presentation to the user via one or more of the interfaces described herein.
  • the credit preference feature of the present invention color codes the credit preference status of each order from the perspective of the viewing business unit.
  • another method of encoding the credit preference status of an order may include adding a character notation such as an asterisk or star to an order, as may be desired if the user is color blind.
  • Each order is color coded according to the credit preferences marked by the triangle 212, which corresponds to what the order placer's business unit has set against business unit ( 3 )'s legal entity, and the triangle 214, which corresponds to what business unit ( 3 ) has set against the order placer's legal entity.
  • the order is evaluated according to the credit preference defined in the cells marked by the triangles 212, 214, and the results can be displayed to the user via the color coding scheme set forth below where true means that the order passes the credit preference of the setting party and false means that the order does not pass the credit preference of the setting party:
  • Triangle 212 Triangle 214 Color False False RED False True YELLOW True False RED True True GREEN
  • each order is color coded to communicate to the user the tradability of the bids and offers in the market based on the preferences of both users.
  • the color coding methodology described herein is used in both the market entry interface (described below with reference to FIG. 12) and the market detail interface (described below with reference to FIG. 15).
  • the following meanings are associated with the cited colors:
  • GREEN The price passes the credit preferences of both parties, and the counterparties are free to trade. Any trade that is shown in green can be freely traded by the trader, and credit approval is assumed to be in place.
  • YELLOW The price posted is free to trade by the viewer, but the poster of the price has excluded the viewer from his/her credit preferences. If the price is colored yellow, a deal may be allowed provided that the party who placed the passive order allows mutual puts, and the credit over-ride process which is described below is completed.
  • the viewer can attempt to trade by sending a message (thereby initiating the credit over-ride process) to the poster of the price which discloses the name and/or identity of the viewer, along with a mutual put maturity entered by the viewer.
  • the poster then has the opportunity to accept, accept subject to credit (in either case, the poster may also reduce the maturity of the mutual put), or decline.
  • the poster's name will not be released to the viewer until a trade is executed.
  • the posted price will remain available to all other traders on the system 10 until a trade is completed. If the order trades to another viewer, then the credit over-ride process will be terminated.
  • RED The price posted is excluded by the viewer's own preferences even though the poster is (may be) clear to trade. In this situation, the viewer is not free to trade since it is the viewer's own credit preference that the viewer set which is preventing the trade.
  • BLUE The price is the viewer's own order.
  • WHITE Only used in the market entry interface 250 (FIG. 12) to display prices where there are multiple orders at the best price with differing codes. Thus, the viewer is notified to view the market details interface for more information.
  • the viewer may activate the over-ride process.
  • the over-ride process begins by prompting the posting party with a request for an order quantity.
  • the message sent to the poster essentially states that the viewer, which is identified by name in the message, wishes to trade a stated quantity and that the receiving party has a stated period of time to respond, for instance, 15 seconds.
  • the viewer will then see a copy of his/her message and a clock which displays the countdown of the stated time to the poster.
  • the poster receives the message and can decline or accept. If the poster declines, then the viewer is informed accordingly.
  • the poster accepts, then the poster has the option to add a mutual put maturity and request a small price adjustment, which will be stated in a specified number of months. The viewer cannot back out of the trade while the clock is running (unless a price adjustment is requested). Further, at no time is the poster in a trade until all steps are complete.
  • the trader workstation 20 generates a maximum maturity value that determines how an order will be color coded.
  • the maximum maturity value is in the form of an integer n digits in length, with the right-most two digits representing days, and the left (n ⁇ 2) digits representing months. Therefore 12000 represents 10 years, 3600 represents 36 months, and 114 represents 1 month, 14 days.
  • the method by which credit preferences are converted to a maximum maturity value is represented by Table 2 below.
  • Every instrument in the system 10 possesses a maximum maturity value. To determine whether a particular order can be traded, the maximum maturity for the order's instrument is compared to the maximum maturity of the credit preference. If the instrument's maximum maturity is greater than that of the credit preference, then the order may be traded, otherwise it cannot be traded.
  • the trade workstation 20 maintains two lists for each instrument class.
  • One list includes the credit preferences that the viewer has set against all other legal entities for that instrument class. This list may be referred to as MY_PREFS.
  • the other list includes the credit preferences that all other business units have set against the viewing legal entity for that instrument class. This list may be referred to as OTHER_PREFS.
  • Each of these lists contains the following data:
  • the MY_PREFS list may contain a credit level (e.g., which may be associated with the order and presented to the viewer.
  • a user may enter the market entry interface 250 , as illustrated in FIG. 12.
  • the user can simultaneously monitor numerous markets and place orders, including bids and offers.
  • the market entry interface 250 also allows the trader to select any instrument(s) to be displayed, and multiple market entry interfaces 250 with various trading functions (e.g., common FRA on one interface, SWAP on another interface, and Switches on yet another interface) may be opened on the trader's desktop simultaneously.
  • the market entry interface 250 is designed to present the sum of the best bid and ask, and the act of trading by any two parties by a flashing volume indicator in the top right-hand corner.
  • the market entry interface 250 enables a trader to easily monitor many different markets with relative ease and utility.
  • the system 10 does not perform auto-matching of orders, but allows the user to maintain control of the trading process at all times.
  • the system 10 does this by introducing the concepts of active and passive orders.
  • a passive order is an order placed in the system 10 for a particular instrument, for a particular quantity, at a specific price, for a particular time period (see order types below).
  • An active order is when a user decides to trade a passive order displayed in the system 10 , and is usually only required to provide the quantity. Thus, there can be active or passive bids and offers.
  • the user may customize the market entry interface 250 by adding and removing instruments (i.e., markets) displayed in the instrument display window 252 .
  • the user may add new markets by entering an instrument symbol (according to the symbology of the present invention) into instrument identifier field 254 .
  • the user may also want to define groups of instruments which can be saved as profiles and viewed together. Profiles allows the user to organize multiple markets by like attributes.
  • the profile being viewed is displayed in the profile display field 256 .
  • the profile display field 256 is a pull down menu that lists the other profiles defined by the user. Until the user defines a first profile, the profile display field 256 is set to default.
  • instrument Individual markets displayed in the instrument display window 252 are divided into four columns: instrument, best bid, best ask, and info.
  • the instrument column displays the instrument name (i.e., the symbol, alias or a security identifier).
  • the best bid column displays the best bid information, defined herein as the orders that are at the best price.
  • the best bid information includes a relatively large central number that displays the least two significant digits of the price, a bottom left number that displays all but the least two significant digits of the price, a bottom right number that displays any volume or quantity currently trading, and a top right number that displays the quantity of currency units in millions. Depending on the precision desired, a greater or lesser number of digits can be displayed as the larger central number.
  • the precision of the displayed central numbers is defined for each instrument, and may, for example, include 2, 3, 4, or more digits.
  • the best ask column is substantially identical in format to the best bid column, but displays the best asking price rather than the best bid price.
  • the info column provides space for data items that the user may select to view, as defined in an info window 258 . In the present embodiment, three items are defined in the info window 258 , and thus, the corresponding information for the instrument will be listed in the info column.
  • the system 10 provides users with a symbol construction interface 270 , as illustrated in FIG. 13, that can be accessed via a Lookup button 272 from the market entry screen 250 .
  • the symbol construction interface 270 functions to aid the user in selecting instrument for display in the instrument display window 252 .
  • the user can view available aliases in window 273 , explode a symbol (i.e., view a list of underlying parameters associated with the symbol, for example, payment date) via the Explode Symbol button 274 , select symbols to be added to a profile via the Add to Profile button 276 , and construct new symbols or aliases via the Build Symbol button 278 .
  • the symbol construction interface 270 also provides error checking such that only valid symbols can be selected.
  • the symbol construction interface 270 screen also enables the user to search for groups of symbols by at least partially fig out the input parameters 282 located above a Search Options button 284 , and then selecting the Search Options button 284 .
  • the input parameters 282 include various non-commercial terms of an instrument that can be negotiated following a transaction. For instance, as shown in FIG. 13, the input parameters 282 include class of instrument, currency, start month, end month, over, FLOPT, and special rules. By at least partially filling in these parameters, the user can search for similar instruments which are displayed in window 280 .
  • the prices displayed in the best bid and best ask columns are encoded with credit information using the color scheme described above.
  • color-blind users can have the color coding scheme replaced by a symbol scheme in which different symbols are positioned next to the respective prices to indicate the credit status of the order.
  • the symbol scheme may be chosen by the user under the Environment tab of the preference interface 148 (see FIG. 6B).
  • the inventors of the present invention are not presently aware of any electronic trading system that offers color-based credit preference pre-screening such as that disclosed herein.
  • the present invention provides color-based credit preference pre-screening because, unlike the prior art systems which only show the best dealable price or the best minimum quantity, the present invention shows all prices (bids and offers), irrespective of their credit preferences.
  • the user can be provided with as wide of a view of the markets as the user desires.
  • the color coding enables the user to visually determine virtually instantaneously what bids and offers are tradable based on the credit preferences of the trader and the counterparty.
  • the best bid and offers for each of the desired instruments will be displayed in the instrument display window 252 .
  • the best bid and best offer prices display in window 252 are different from many prior art systems because they are the absolute best bid and best offer at the stated quantity. Because of the unique color coding scheme, the user is able to quickly tell whether or not the bid or offer is tradable by him/her. If the user so desires, the user can select a financial instrument with the pointing device 86 (FIG. 3), such as a mouse, so as to highlight the row in the instrument display window 252 for that instrument. Once the financial instrument is highlighted, the user may perform one of several functions provided for by the function bar 290 , each of which is described below:
  • EXPL Function This explodes the instrument symbol into a full description of the contract, and mirrors the confirmation
  • HIT, LIFT, ORD Functions These three buttons allow a user to select an instrument and then place a new order, or execute an active order, by hitting or lifting the desired respective bid or offer.
  • the HIT, LIFT, ORD functions can also be carried out by double clicking the mouse in the screen itself.
  • RFP Function request-for-price messages are an important tool to allow the market to communicate. If a trader wishes to see a market, a broker will be contacted via the telephone, and the broker will in turn phone other traders to drum up interest. Using the system 10 of the present invention, the same result can be achieved instantaneously by sending an RFP to all registered users. This message may be displayed in the command center interface 130 of other users, informing them of a RFP in the named instrument.
  • derivatives traders are often trading more than one financial instrument, and sometimes in more than one currency, derivatives traders will often have multiple passive orders.
  • the present invention provides at least three order management functions to facilitate the canceling or temporarily suspending the order. This may be an important functionality when the market is moving quickly, or if the position of a trader suddenly changes.
  • XLST Function This function cancels the last passive order placed by the trader. Therefore, if a user submits an order and immediately changes his or her mind, the order can be canceled without the need to select the order individually.
  • XALL Function This function allows the user to cancel all his or her outstanding passive orders in one key stroke.
  • REF Function This function allows the user to suspend or place all orders under reference. This is an alternative to canceling orders one by one. For instance, if a user is expecting news that may affect only a few outstanding orders, it may be safer to place all orders under reference, and individually re-release the orders the trader expects not to be affected back into the market.
  • DEL Function This function allows the user to delete a market from the profile.
  • a user can submit a passive order by selecting the ORD button. If the ORD button is selected, a passive order interface 294 is provided to the user, as illustrated in FIG. 14A. From the passive order interface 294 , the user can place a passive order such as a bid (i.e., buy) or an ask (i.e., sell). The user enters a price, quantity, and selects how long the order will be good. The price will default to current market level so the user may only need to enter the last two digits of the price. For quantity, the system 10 recognizes m, mm and b for thousands, millions and billions, respectively. The system 10 allows the following order types to be entered under the good until option:
  • the system checks any new orders for reasonableness (or “framing”) as they are placed. For example, a bid cannot be higher than the existing offer without the user double checking.
  • the tab key, enter key, or the mouse can be used to navigate through the passive order interface 294 .
  • the OK button the order is submitted into the system 10 and the user is returned to the market entry interface 250 .
  • a user can initiate active orders by hitting a bid (i.e., sell) or lifting an ask (i.e., buy).
  • a hit order window or a lift order window is presented to the user.
  • a hit order window 296 is illustrated in FIG. 14B.
  • the hit order window 296 is substantially identical to the lift order window.
  • the hit order window 296 identifies the instrument and order price.
  • the user is presented with a transaction quantity which is initially set for the full amount being offered by the counterparty. The user is allowed to reduce the quantity figure. The user is not allowed at this point to increase the quantity figure because the counterparty has already indicated the quantity they are desiring to sell.
  • the OK button the order is executed by the system in the manner described below, and the user is returned to the market entry interface 250 .
  • the user can select (e.g., highlight) an instrument in the instrument display window 252 and then click on the MDS button 292 . This will launch the market detail interface 302 , as illustrated in FIG. 15 for the highlighted instrument.
  • the market detail interface 302 enables a trader to view essentially all the orders in the market for a particular instrument, both bids and offers.
  • the bid orders are listed in a bid window 304 where the credit levels (e.g., A, B or C), bid quantities and bid prices are provided.
  • the offer orders i.e., ask orders
  • ask window 306 where the ask prices, ask quantities and credit levels are provided.
  • the orders are color-coded with the appropriate credit preferences. This is a significant departure from many prior art systems which only show the best dealable price or blended prices.
  • buttons of the function bar 308 are substantially identically to those on the function bar 290 except that they only apply to a particular instrument while the buttons of the function bar 290 apply against multiple instruments.
  • a fair price indicator i.e., the LIBOR for that day
  • last traded price indicator are provided along the bottom of the bid window 304 and ask window 306 .
  • the last trade pricing may be replaced by volume, duration, RQ, last close price, etc.
  • An advantage of the market detail interface 302 is that the user is not restricted to trading only the best price or first order. At no point in the process will any orders be automatically matched against each other by the system 10 . The user is in complete control of the order flow process.
  • the user can execute both passive and active orders from either the market detail interface 302 or the market entry interface 250 .
  • the user if the user wants to execute a trade, then the user only need to highlight the desired bid or offer and select the corresponding function button from the respective function bar 290 , 308 to initiate the transaction.
  • the semantics of placing, changing, and canceling orders can be relatively complex, the user is shielded from this wherever possible by the system 10 .
  • Each order entered into the system 10 is placed into a queue based on price and time received.
  • a change to the order may or may not affect the order's place in the queue. Any change of price will move the order up or down in the queue depending on the price level. Any decrease in the volume of the order will not affect the order's place in the queue. Any increase in volume will result in the previous amount holding its place and a new order placed for the balance.
  • Effective electronic trading should be intuitive, fast and reliable.
  • the present invention is designed to maximize a user's efficiency.
  • the system 10 enables the user to place passive orders from either the market entry interface 250 or market details interface 302 using the input device 86 .
  • the user may double click on the instrument name or may select the ORD button of the function bar 290 , 308 in order to launch the passive order interface 294 .
  • the present invention For monitoring the status of a user's outstanding (or open) passive orders, and for making quick adjustments to those orders, the present invention has a facility known as an outstanding order blotter 320 , as illustrated in FIG. 16.
  • the outstanding order blotter 320 summarizes all outstanding passive orders and provides the user with the ability to confirm the terms of the trade, the symbol, and the type of order.
  • the outstanding order blotter 320 enables the user to quickly change the price, quantity, or good until status via drop-down menus that appear when an order is selected. From the outstanding order blotter 320 , the user may also place new orders and/or cancel a particular order in the market.
  • the outstanding order blotter 320 gives the user the ability to manage his/her current passive orders in the market from a single interface. As with the market entry interface 250 and market detail interface 302 , the user is provided with cancel all, cancel last, and refer-all functions via the outstanding order blotter 320 . This is a significant advancement over many prior art systems in that not only does the system 10 offer a facility to track all current passive orders, but the system 10 also enables the user to modify, add or delete passive orders from the outstanding order blotter 320 without returning to the market entry interface 250 or market detail interface 302 .
  • the user For executed or canceled orders, the user is provided a client monitor 330 , as illustrated in FIG. 17. From the client monitor 330 , the user has access to completed or canceled trades. Thus, the client monitor 330 enables the user to quickly see what orders have been executed or canceled, and to look back over time to see previous days trades. Preferably, historical transactions will be available for one month via the client monitor 330 .
  • the outstanding order blotter 320 and client monitor 330 enable a user to manage his/her diverse trading activities. From either blotter, the user can monitor the status of orders and executed or canceled trades. Both of the outstanding order blotter 320 and client monitor 330 can be accessed from the command center interface 130 . Further, the blotter 320 and monitor 330 are updated automatically if the user submits an order via one of the other interfaces.
  • the system 10 permits active orders (i.e., those where a trader hits or lifts a passive order) to be placed from either the market entry interface 250 or market detail interface 302 via the Fir and LIFT buttons on the function bars 290 , 308 .
  • active orders i.e., those where a trader hits or lifts a passive order
  • the system differs from many prior art systems in that two passive orders will not be executed against each other automatically. An active order from an active user is required for execution. Furthermore, there will be one active and one passive user for each trade. This means choice (where bid equals order) or even backwardation (where bid is higher than order) markets are possible. Accordingly, for a transaction to be completed in the system 10 , an action must be performed against a passive order.
  • An execution notification message 340 is sent to both counterparties, describing the transaction and disclosing the names of the counterparties. Note, this is the first point in the transaction that the counterparties are identified to one another.
  • the system 10 ensures that both users receive the message before the trade is finally completed. This does not require any form of action from either user, the market interface module 74 (FIG. 3) of each trader responds for the respective user. This validation ensures that, in the unlikely event that a connection is lost during this process, a user does not have a position of which he or she is unaware.
  • the system 10 is designed to ensure that a user cannot execute a passive order which has been canceled or is no longer available. This is done by checking to verify that the connection between all trading counterparties is live at all times. In the event that the connection is lost or broken, all orders from a user which loses connection to the system 10 are automatically suspended. Following the execution, the client monitor 330 is updated with the transaction.
  • the execution notification message 340 (FIG. 18) provides the users the opportunity to increase the quantity of a trade once an initial trade has been executed.
  • One of the users can insert a quantity in the will-do-more field 342 which represents an additional quantity to the original amount.
  • This feature is designed to enable a user who has a large quantity to trade to place a passive order for just a smaller portion initially. Users often want the ability to increase the quantity of an order when they have a large quantity to transact. This is because large orders in the market often tend to adversely move the price of the market as market participants back off such large size.
  • the ability for the passive trader to conduct an anonymous dialogue via the system 10 for increasing the size of a transaction after an initial transaction for a smaller size has been executed is an additional difference between the system 10 and many prior art systems.
  • the counterparty is provided with the request for more.
  • the counterparty is given a discrete period of time to respond to the request to do more, after which the request lapses. If the counterparty wants to trade more, then the counterparty can accept the amount requested, reject the amount by selecting the Reject button 346 , or the counterparty can request a different amount that is then present back to the user who then has a discrete period of time to respond.
  • the counterparties can exchange offers to increase the quantity as many times as they desire until an addition amount is agreed upon or a decision is made not to do more.
  • This function should preferably be made available only if the active order clears the full market size at the current best price. In that case, either party may ask to do more.
  • the will-do-more feature enables the counterparties to increase the size (amount of the trade), but not the price. The price is preferably not affected. This process can go back and forth for some time and can continue as long as the will-do-quantity is fully accepted (i.e. can occur more than once). Once completed by both parties, the system will combine all will-do-more quantities and generate only one transaction ticket for the total increased amount at the initial price.
  • the system 10 enables the parties to negotiate the non-commercial terms of the transaction.
  • This process is referred to as term negotiation, and is effectuated through the negotiation window 350 , as illustrated in FIG. 19.
  • the term negotiation process is a process where by both parties to a trade have the ability to negotiate non-commercial terms of a transaction.
  • derivative transactions also have non-commercial terms which do not affect the price of the trade. While there are defaults, the parties may want to negotiate these terms.
  • the system 10 will present the parties with the option to negotiate via interface 350 . The system does not force a party to complete this process immediately, however, as the party may have other more important tasks to complete elsewhere.
  • the negotiation should, however, be completed within a reasonable time.
  • the active party i.e., the trader that hit or lifted the order
  • the trader will be presented with the terms 352 to be negotiated, current values 354 which are editable (such as by a text field), and default values 356 which are predefined in the system.
  • the trader may accept the system defaults by selecting button 358 , or enter his/her own desired values and select the submit button 360 .
  • These values are sent to the passive trader (i.e., the trader that placed the order in the system originally) who may also accept or enter his/her desired values. if an agreement cannot be reached, then the defaults will be used.
  • the status of these negotiations will be displayed in the client monitor 330 of FIG. 17.
  • a trade confirmation is sent automatically to the settlement contact of both business units preferably via fax.
  • the system 10 can also send the confirmation via file transfers, e-mail, or any other suitable means of communication.
  • the trade confirmation includes the quantity or volume traded, identification of the financial instrument that was traded, price, date and time the execution is recorded, and a settlement ID that uniquely identifies the transaction.
  • various other parameters and transactional data can be included as appropriate for the nature, type and subject matter of the transaction.
  • the system also offers traders a trading methodology for dealing with risk management problems unique to interest rate swap dealers.
  • a new market has emerged as a result of interest rate swap dealers' need to better manage their risks associated with changes in interest rates on their growing interest rate swap portfolios.
  • bid-offer spreads are narrowing considerably.
  • This factor combined with the wide spreads of exchange traded Eurodollar futures, has contributed to the use of exchange traded contracts for hedging short-term risks being expensive and sub-optimal.
  • the switch was created. A switch is simply the simultaneous purchase and sale of a pair of similar forward rate agreements.
  • a dealer prepares a fax listing the days that the dealer needs to buy or sell, but not the amount or importance of any given date.
  • the dealer sends the listing to other risk managers at other firms, or to voice brokers. From this bit of incomplete information, transactions are eventually negotiated. While finding switches may be important, it is usually not urgent as compared to other more immediate tasks, such as new executions or the hedging of large outright market risks. As a result, the time is never quite right to focus on a position that may be heavily weighted on one side and matches another's position, but not perfectly. Voice brokers have tried to solve this by matching multiple faxes, but this does not appear to be the solution.
  • the present invention goes several steps beyond these efforts, and offers matching with the credit preferences of the traders taken into account.
  • the system 10 also demonstrates fairness in any matching process. When the portfolios are so large that each risk manager has a position on each day out over the life of his or her portfolio, the resulting combinations can be huge.
  • the rules, constraints and priorities are preferably structured in a way to demonstrate fairness of execution between users to the market participants.
  • the present invention offers traders a solution to the complexities of switch trading by creating an anonymous position discovery system called the switch engine.
  • the objective of the switch engine is to put a tool in the hands of risk managers that allows them to perform anonymous switch transactions fast and efficiently without losing control of the process.
  • the switch engine achieves this by having the trader manually input his/her position (i.e., interest rate risk portfolio) into the switch module 80 (FIG. 3) via a portfolio interface 380 using variable rate index and currency for up to 180 days or more into the future, as illustrated by FIG. 20.
  • the user must confirm its accuracy by selecting the Apply button 381 before the positions can be used in the switch mechanism 35 of the central processing center 12 (FIG. 2).
  • the system 10 can be configured to receive the position data via electronic transfer or some other suitable form of data transfer. This may include a transfer directly from the user's own risk management systems. Although some trader workstation 20 may need some customization to receive portfolios in this matter, the system 10 should support this capability. The nature of switch positions, particularly in the near term (defined as out to the maturity of each index), is relatively stable, and therefore, the on-line entry of portfolios by the user should be adequate for most traders. The inputted portfolio data is then sent from the trader 20 workstation to the switch mechanism 35 of the central processing center 12 .
  • an inputted column 382 represents the portfolio entered by the user
  • the traded column 384 is the cumulative amount traded by the user since the portfolio was entered in the inputted column 382
  • the net column 386 is the real-time position of the user given the portfolio inputted and the traded quantities in column 384 .
  • the user may restart at any time by rolling the net positions in net column 386 into the input column 382 by selecting the Roll button 388 , or by clearing all the positions by selecting the Clear button 389 .
  • a switch interface 400 is generated by the switch module 80 using his/her own position data from other traders entered on the respective trader workstations 20 and uploaded to the switch mechanism 35 .
  • the switch interface 400 enables the user to search through the market, and view possible trading combinations of his/her portfolio and combinations of his/her portfolio against positions from other counterparties which have been input into the system. This is referred to as position discovery.
  • the switch interface 400 can be reached by selecting the switch engine button in the tool bar 132 of the command center interface 130 (FIG. 5).
  • the switch engine interface 400 For a given floating rate index (for example, a one month LIBOR) 402 , the switch engine interface 400 lists the net positions 404 for each day 406 out 180 days. In addition, the possible switches 408 , available switches 410 , formulated forward rate 412 , and a fair price 414 are also listed for each day 406 . By selecting a day 406 , the switch interface 400 displays all possible switches against that day. Thus, the user can pick the days for which he/she is carrying the most risk.
  • An advantageous feature of the switch interface is that the user is provided with only combinations where he/she has a position and someone else has the opposite position, and both parties satisfy each other's credit preferences as described above.
  • the net position 404 is the position entered or modified by the user.
  • Possible switches 408 are those switches for any given day with respect to the trader's own position. Note, a switch typically makes sense only if the trader's position is long one day and short on another day.
  • the available switches 410 are positions in other counterparty portfolios that exactly offset the position of the user.
  • the switch interface is configured to displays available switches up to the size of the user's own position, and preferably does not disclose the name(s) of any counterparties until after a trade has been completed. This ensures the anonymity of the user, and does not disclose any material position data to other traders.
  • the forward rate 412 is the current market forward rate calculated by the system from other available market rates for the given date for the maturity of the underlying index maturity.
  • the fair price 414 represents the relative price between the two underlying FRAs, which is the basis upon which forward rate agreements are traded.
  • the fair price 414 is calculated from live market data taken from other financial instruments. While not designed to execute trades at the displayed fair price 414 , the fair prices are an aid to users in gauging the fair value of the market.
  • a trader viewing the switch interface 400 may select (i.e., highlight) the “Thurs., Aug. 21” position, and then select the RFS button 416 .
  • the passive order interface 294 (FIG. 14A) then prompts the trader with a quantity and price which the trader may modify.
  • the trader may then submit the request for the switch.
  • All anonymous counterparties that have an offsetting position then receive a message in command center interface 130 (FIG. 5) notifying the counterparty of the anonymous request for a switch. Any one of the counterparties may then select the request message which causes the request to be displayed in the market entry interface 250 (FIG. 12). From the market entry interface 250 , the counterparty can hit the request for switch or submit their own passive order.
  • the trader can update or modify his/her portfolio by selecting the Update button 418 , which launches portfolio interface 380 , as described above. The trader can then select an inputted amount 382 or a traded amount 384 to enter or edit the displayed values as desired.
  • a switch or swap may be a desirable means by which a risk or inventory short fall is off-set.
  • a security may be borrowed or an open derivative position hedged with another position.
  • U.S. Treasury bond market it is conventional for traders to buy and sell securities, and to hedge with the newest or benchmark issues.
  • the U.S. Treasury may issue new two year securities each month. For the first month, the new issue is the benchmark (or on-the-run) issue, and the other issues with a final maturity between one and two years are referred to as old issues.
  • the switch engine of the present invention is a solution.
  • the principals of the switch engine can be successfully applied to bond switches, as well as other financial instrument switches.
  • the switch engine interface 400 may need to be slightly modified wherein the instrument designation 402 is changed to reflect the new market, for instance, to Two Year U.S. Treasuries or 30 FHLMC TBA.
  • the setting column 406 may be changed to reflect the individual securities which may be switched, and the remaining columns should not need to be changed.
  • a new column representing the duration of each security displayed should be added so that the securities can be duration weighed to ensure fairness.
  • the system 10 provides trading methodologies referred to as the auction and switch auction. Although auctions are held in a variety of markets, some of which are electronic, the auction and switch auction have no known counterpart in the derivatives markets.
  • the auction and switch auction trading methodologies were developed in order to provide an auto matching process for switches. However, the system 10 can use these auction methodologies for auto matching for a wide variety of other financial products, not just switches.
  • the counterparties may end up with multi-year facial commitments to one another once a trade is executed.
  • the auction and switch auction take the credit preferences of the users into account.
  • the auction methodologies herein are referred to as a two way Dutch auction with credit.
  • users submit orders into the auction module 81 of the trader workstation 20 (FIG. 3) which communicates the information to the auction mechanism 34 of the central processing center 12 (FIG. 2).
  • the orders are submitted via an auction interface 430 , as illustrated in FIG. 22A, by price, quantity, and action.
  • the auction interface 430 includes a queued orders window 432 into which the user enters an order, and a submitted orders window 434 which shows the orders submitted to the auction mechanism 34 via the auction module 81 .
  • Orders can be added via the Add button 436 .
  • Orders are moved from the queued orders window 432 to the submitted orders window 434 by highlighting the order and then selecting the Submit button 438 .
  • All entered orders in the queued orders window 342 can be submitted at once by highlighting all the orders and then selecting the Submit All button 442 .
  • the orders in the queued orders window 432 can be edited via the Edit button 440 or canceled via the Cancel button 444
  • the orders are filled at their entered price or better, and between counterparties that satisfy the credit preferences of one another.
  • the auction mechanism 34 then conducts the auction, preferably utilizing the following constraints and priorities to ensure fairness.
  • the auction price is calculated by finding the price at which the most volume is traded. This condition is sufficient to generate a fair price, and all transactions should be completed at this price. It is noted that this price is generated without taking credit into account. The matching of orders is completed to ensure that credit preferences (including complex rules) are safe guarded and to ensure that the minimum number of tickets are generated. The better submitted prices will have priority, and all orders at the auction-price are filled in proportion to each other. Under these constraints, the auction mechanism 34 executes the auction, matching users and generating a settlement list. The settlement list comprises the trades resulting from the auction.
  • the confirmation process is substantially the same as that for interactive trades.
  • the system 10 notifies the users of their fills.
  • results will be made available to the user via a message to the command center interface 130 of each user.
  • the present invention also offers a dedicated limited auto-matching process for switches referred to as the switch auction.
  • the switch auction does not have to be a full auction, in that the price may be set by the system 10 .
  • the price will, however, be available before the commencement of the matching. This will allow all users to understand the levels that will be used before entering into the switch auction. This also allows the users to maintain control of their positions.
  • the switch auction interface 460 has two parts, an auction list 462 and an auction status 464 .
  • various auctions and their respective statuses are listed by FLOPT and currency.
  • the auction status 464 the auction selected in the auction list 462 is displayed and identified (including the open and close day/time).
  • the positions 466 for respective dates 468 are entered by a user, and do not need to add to zero, but should include positions of both signs (i.e., long and short).
  • the rate 470 is the price at which the auction is conducted.
  • the rate 470 is displayed a predetermined amount of time before the auction is conducted so that the participants have the opportunity to step out of the switch auction if they so desire.
  • the rate is preferably based on available market factors, and may be calculated by a calcserver (as described below).
  • the results column 472 is the total trade amounts resulting from the auction.
  • the amount displayed in the results column 472 for a given date may be the cumulative amount from multiple transactions with multiple parties.
  • Additional control buttons 474 enable the user to submit an order, cancel an order, cancel all orders, or change an order.
  • the switch auction will auto-match the position, talking credit preferences of the users into account so that (1) a maximum volume is executed and (2) a minimum number of tickets is generated.
  • the switch auction utilizes the above two rules to ensure fairness. No user will be given priority over any other user except as required to satisfy the respective credit preferences. Preferably, only two-way switches will be offered. Switches are a risk management tool, and switches generated between three counterparties introduces substantially more credit risk than a straight two-way switch.
  • the calcserver which calculates the auction rate and price information, and other relevant data for operation of the system 10 is described.
  • the calcserver provides the switch mechanism 35 with the forward rate for any given index for each day, the system price quoted in the market entry interface 250 , and OTC derivative prices derived from the yield curve.
  • the calcserver comprises a preprocessor, a zero curve server, a FRA server and a Swap server.
  • the preprocessor gathers real-time data from outside data vendors (such as Reuter or Telerate) and from internal system sources (such as data normally entered into system 10 ), and prepares the data for processing by the other components of the calcserver.
  • the zero curve server reads in the market rates (including price and yield for a variety of class instruments such as money market rates, swap rates, future prices, swap spread, bond yields and FRA's) as provided by the preprocessor, and generates therefrom the zeros and discount factors for each currency and level of credit.
  • a zero coupon yield curve i.e., zero curve
  • a zero curve comprises a set of points representing the calculated interest rate or discount fact from observable market rates across the term structure (e.g., 0 to 30 years) such that any cash flow can be discounted to today in one step without the consideration with decompounding.
  • there is a different zero curve for each index/currency pair there is a different zero curve for each index/currency pair.
  • the FRA and Swap servers are instrument specific servers that calculate forwards, RQ (as defined above), durations and fair prices.
  • RQ as defined above
  • the zero curve calculation starts from the instruments with the shortest term structure in the money market rates (MMs).
  • the analytics for finding points on the zero curve from MMs are as follow.
  • the processed price of the MMs, end date of the MMs and the basis of the MMs (number of days in a year that the MMs is based on) are needed. All of these are stored in a database 64 (FIG. 2).
  • the processed price is the only input that typically changes.
  • the calculation represented by the equation below will generate a new zero rate with the date of the end date of the MMs.
  • Rmms is the processed price of MMs
  • t is the time in days between the end date of the MMs and the current date.
  • the next instruments used according to term structure are either the futures or FRA's. Since the futures and FRA's have similar term structures, a choice will be made on which ones to use. Initially the futures will be used because they have high liquidity. However, it is believed that when FRA's traded on the system reach a high level of liquidity, they should be used instead.
  • futBasis is the number of days in a year that the future is based off
  • futRate is the processed price of the future
  • e is the end date minus current date
  • s is the start date minus the current date.
  • the rest of the zero curve will be derived from swap information.
  • the zero curve and the discount factor at each coupon date are used to calculate the zero rate and the end date in the swap using the equation below for Z(t n ).
  • gaps may exist in the zero curve.
  • Synthetic swap rates are calculated where gaps exist to improve accuracy. The calculation of a normal swap rate and a synthetic swap rate are the same.
  • Z(t i ) is the zero rate at the particular coupon date:
  • swapRate is tradePriceAdjust
  • t i represents a coupon date
  • Y(t n ⁇ 1 ,t n ) is the period in years between the two coupon dates.
  • Section 1 Summary of the transaction.
  • Section 2 Counterparty details and commission.
  • Section 3 Transaction details.
  • Section 4 Term negotiation
  • a tools area 432 provides the trader with a set of customized tools including graphs, market quotes, bond prices to yield converters, pricing tools, and MarketSheetTM applets.
  • a service area 484 provides various interfaces as described above on a temporary basis.
  • a message center 486 displays the most recent RFP, RFS, Chat and administrative messages, and is preferably configured as a drop-down window to display multiple current messages.
  • a status bar 488 displays user status information.
  • a workspace area 490 provides for the entering of data into dialog boxes in a non-intrusive manner, plus the execution of the data function.
  • a warehouse area 492 stores the most commonly used interfaces in a tabbed format, allowing the trader to retain their preferred set-up between sessions. Accordingly, the main screen 480 provides enhanced functionality by integrating multiple interfaces in a single window.
  • the system 10 comprises the central processing center 12 that may includes multiple servers connected via an Internet-protocol network to the individual counterparties trader workstation 20 which may be desktop computer workstations. Because of the open system architecture of the system 10 , the present invention may run within the context of the internet browser 72 on the user's existing desktop computer 20 .
  • the desktop computer 20 preferably includes an operating system platform for which a Java-enabled Internet browser is available.
  • the present invention is designed to be flexible enough to reflect several different measures of credit risk, as generally described below with reference to FIG. 24.
  • each business unit provides the group server 32 (FIG. 2) with detailed credit preferences for each potential counterparty business unit's legal entity.
  • the group server 32 then distributes the credit preference information in an anonymous format to the trade workstation 20 which uses the credit preferences of each active business unit (counterparty) in the system 10 to prescreen the user's market orders (bids and offers) against the other counterparties' market orders.
  • the credit preference module 76 (FIG. 3) of each trader receives the credit preference information defined by a first user with respect to a second user, as indicated by block 504 .
  • the credit preference module 76 receives the credit preference information from the second user with respect to the first user, as indicated in block 506 .
  • the credit preference module 76 determines which orders, on which financial instruments, and with which counterparties, the user can deal. This information is coding on the posted prices utilizing color or another notational method such as symbols, as indicated in block 508 .
  • the prescreening is a complex check to determine whether two particular counterparties will accept each other for a particular class of financial instrument, for a particular amount and for a particular maturity.
  • This is a risk equivalent measurement, and is more than a simple yes/no preauthorization matrix. More specifically, because each financial instrument has different credit qualities, it is possible for a particular counterparty to be willing to accept another particular counterparty for one type of financial instrument but not another. Furthermore, it is also possible that a particular counterparty may accept the other for a particular financial instrument, but only for a certain length of time (i.e., maturity).
  • the system 10 may also allow the user to accept counterparties for different amounts at different maturities.
  • the system 10 divides counterparties into legal entities. These legal entities may be further divided into individual business units. So, for example, Bank A may be a legal entity (counterparty) and Bank A might have a different business unit in three different cities (e.g., Tokyo, London, and New York).
  • the counterparty credit information is available at the legal entity level. So, for instance, if Bank A wishes to allow each of its business units to set their own credit preferences for other counterparties, then these credit preferences will be listed against the legal entity level of all the other business units. In other words, business unit A at Bank A can not say it will trade with desk A of Bank B but not desk B of Bank B.
  • the system 10 allows business units within a particular legal entity to inherit the credit preferences from other business units in the same legal entity family, if so desired.
  • this credit preference information is maintained locally at the inputting trader workstation 20 , and transmitted to the group server 32 of the central processing center 12 .
  • the central processing center then transmits a vector of encoded credit preference data to each user logged on, wherein the data represents that preferences of the user to the other legal entities and the preferences of other business units to that user's legal entity for the affected instrument classes.
  • the encoded vector of credit preference data is accessible to any of the trader workstations 20 in the system 10 ; however, the sensitive credit information of other counterparties is not available.
  • the user is then able to select or filter messages on which financial instruments and in which currencies the user wishes to receive updates, messages and prompts.
  • the filters can be selected via the user preference interface 148 to customize the order information presented by the command center interface 130 . This screening capability is provided to the user in order to prevent him from being overwhelmed by, and to sort through, the possibly thousands of different financial instruments in up to or more than 14 different currencies that the system 10 has the ability to handle.
  • the user is able to view trading information on the currencies and financial instruments that have been selected for the user. This means, for example, that if the user has selected US dollars only, then the user will preferably not see information on the Japanese Yen financial instruments which are in the system for trading.
  • the market entry interface 250 enables the user to input many different financial instruments which the user is interested in trading on one screen, and have any number of profiles wherein each profile is a collection of markets or a collection of financial contracts in the system 10 .
  • a preferred embodiment accomplishes the inputting and referencing of the various financial instruments through the use of a unique set of symbols referred to as symbology.
  • the symbology of the present invention is based on a concept of subject based addressing whereby the user creates a symbol to uniquely define any one of many complex financial instruments.
  • the symbol denotes the financial instrument's parameters and attributes.
  • the standardized symbology of the present invention is designed such that the users of the system 10 will recognize the meaning of the symbol when the users view the symbols.
  • a symbol may be identified by the full subject name, an alias (in the case of the most commonly traded instruments), or a unique identifier (e.g., such as a numeric code).
  • the system 10 allows the users to construct symbols utilizing the symbol construction interface 270 (FIG. 13).
  • the symbology of the present invention enables a user to input data including a proposed trade of a financial instrument, wherein the financial instrument is advantageously defined by symbology comprising a source field, a class field, a symbol field and a currency field, as indicated by block 512 .
  • This abbreviated format for identifying a financial instrument can then be easily transmitted to other users within the system 10 , as indicated by block 514 .
  • the proposed trade can be viewed by the traders utilizing the symbology, as indicated by block 516 .
  • the users can exchange a small amount of data that is translatable into a detail description of a financial instrument that is relatively complex. This reduces communication and processing overhead of the system 10 and simplifies the user's efforts.
  • the market entry interface 250 displays the best bid and best offer for each instrument, as well as the sum quantity available to trade at the best price and other relevant information.
  • the order information i.e., the bids and offers for each instrument
  • the system 10 presents the best price, irrespective of credit preferences or credit limits. From market entry interface 250 , it is possible for the user to execute a trade directly if the credit preferences of both parties permit. The user may also place a passive order from the market entry interface 250 .
  • the user also has the option of activating a market detail interface 302 which enables a user to see the complete picture (i.e., depth) of all the orders (e.g., bids and offers) available on a particular financial instrument, coded with credit preference information.
  • the market entry interface 250 and the market detail interface 302 not only display the best bid and offer, but each individual order in the system 10 individually.
  • the user is provided the ability to select not just the best bid or offer, but any bid and offer in the system 10 . This is important because for credit reasons, the viewing counterparty may not wish, or may not be allowed to, trade a particular bid or offer. This means that the best bid or offer in the system 10 is not necessarily the best bid or offer available to that counterparty.
  • the credit preference information entered in the system 10 by each user is used by both the central processing center 12 and the transmitting business unit servers 18 to prescreen the bids and offers, and to market orders in the system 10 before they are viewed at the trader workstations 20 of the respective client sites 14 .
  • the sensitive credit preference that indicates which counterparties are acceptable, and under what terms, is preferably maintained at the transmitting trader workstation 20 and the central processing center 12 .
  • the other viewing users do not receive or have access to the credit information of the other users.
  • a check is performed to determine whether the receiving client site 14 will accept the particular bid or offer from the transmitting legal entity.
  • the summary and relevant data is transferred in an encrypted form to trader workstations 20 .
  • the credit check may be re-performed at the time of a transaction by the central site 14 and/or the central processing center 12 .
  • the credit preference screening of the present invention enables the display of all passive orders in the system 10 and their relevant credit status with regard to the viewer on both the market entry interface 250 and the market detail interface 302 as follows: 1) green—this means that the viewer accepts the posting counterparty, and the posting counterparty accepts the viewing counterparty; 2) yellow—this means that the viewing counterparty will accept the posting counterparty but that the posting counterparty will not accept the viewer; 3) red—that the viewer will not accept the poster; 4) blue—that the bid or offer being looked at is the viewer's own; 5) white—used on the market entry interface 250 to denote when two or more orders are placed at the same price but with different credit preferences.
  • color coding enables the system 10 to preserve the anonymity of the users while still enabling the viewing business units to receive credit information about the bids and offers they are viewing.
  • the system 10 also includes the option to display small symbols next to each price to indicate the relevant credit status to the viewer.
  • This will-do-more feature is preferably restricted to a predetermined time-limit in which the receiver of the request must respond.
  • the receiver of the request may agree to accept the increased quantity (or part of the increased quantity) at the previously agreed to price or the request will lapse.
  • the will-do-more feature may be repeated as many times as the users desire. The will-do-more feature does not necessarily check credit preferences once this process has begun because both users know the identities of each other at this point. This forces the users to take responsibility for further credit approval beyond the point of the initial trade amount.
  • the system 10 enables the viewer to send a credit override message to the poster of the bid or offer whereby the sender of the credit override reveals his/her identity to the poster and asks the poster to reconsider whether or not the poster will do the requested trade with the viewer.
  • the user which sent the credit override will be identified to the poster, but at no time will the sender of the credit override find out who they revealed themselves to. If the poster chooses to accept the credit override, then the poster may also choose to impose additional credit requirements on the viewer in order to accept the transaction.
  • the credit override function does not in anyway change the credit preferences which each user previously input into the system 10 .
  • the credit override is preferably on a per-transaction basis.
  • the order is the poster's own order.
  • the system 10 does not prevent different users within the same client site 14 from trading with each other.
  • a flowchart 520 generally describes the steps of a trade. Initially, the first user and the second user are provided with essentially real-time order information regarding more than one financial instrument typically via the market entry interface 250 , as indicated by block 522 .
  • the order information preferably includes a request to buy or sell a financial instrument such as an OTC derivative.
  • one of the first or second users initiates the trading process on an order selected from the order information provided by the other of the first or second users.
  • the credit preference information of each user is then used to verify the trade eligibility of the first and second users with regard to one another based on the selected order, as indicated by block 526 .
  • One or both of the first and second users are then able to request an increase in the quantity of the order, as indicated by block 528 . If an increase is requested, the request is process at block 530 . Alternatively, if there is no request to increase the quantity at block 528 , it is then determined that block 532 if there is a request to negotiate terms of the order, and more particularly, the noncommercial terms of the financial instrument underlying the order. If there is a request to negotiate terms by one of the users, then the request is processed at block 534 . If there is not a request to negotiate terms, then an acknowledgment is sent to both users signifying the execution of the trade, as indicated by block 536 .
  • a flowchart 540 generally depicts the steps of a trade from the perspective of a passive user.
  • the credit preferences of the user are inputted and distributed to the other users for effectuating the credit preference screening.
  • the user sends an order to system 10 for distribution to the other users requesting a trade on a financial instrument.
  • the user that placed the order must then wait for another trader to hit or lift the passive order, thereby executing the trade.
  • Both parties to the trade will receive an execution notification which will allow one or both users to request an increase in quantity, as determined by block 548 .
  • the first user accepts, denies, or amends the requested increase, as indicated by block 550 . If there is no request to increase a quantity, then it is determined at block 552 whether there is a request to negotiate terms of the financial instrument. This feature allows the users to change the default values for the non-commercial terms of the facial contract, as indicated by block 554 . Next, the first user will receive an acknowledgment of the execution of the trade with the second trader, as indicated by block 556 .
  • a flowchart 560 generally illustrates the steps of a trade from the perspective of the active user that lifted or hit the passive order.
  • the second user receives an order from the first user requesting a trade on a financial instrument.
  • the order is then checked for trade eligibility based upon the credit preferences of the first and second users, as indicated by block 564 .
  • the order is coded with appropriate credit information based upon the credit check, as indicated by block 566 .
  • the coded order is then presented to the second user based upon a preference or filter set by the second user to view orders of the present instrument, as indicated by block 568 .
  • the second user then initiates a trade by lifting or hitting the order, as indicated by block 570 .
  • block 572 it is determined if there is a request to increase quantity. If there is not a request to increase quantity, then the request is processed at block 574 . If there is not a request to increase the quantity, then it is determined at block 576 whether there is a request to negotiate terms of the financial instrument. This feature allows the users to change the default values for the non-commercial terms of the financial contract, as indicated by block 577 . Next, an acknowledgment is received by the first and second users indicating that the trade has been executed, as indicated by block 578 .
  • Another feature of the present invention is the position discovery as illustrated by a flowchart 580 of FIG. 28.
  • risk position portfolios are received from the users of system 10 .
  • relative position information is calculated for each user so that each user may be presented with possible trading combinations for their portfolios, and combinations of their portfolios against positions from the other users.
  • the possible trading combinations are coded with credit preference information in accordance with the present invention. It is then determined at block 586 if a switch is requested. If a switch is not requested, then the process ends. However, if a switch is requested at block 586 , then a switch is executed at block 588 .
  • the execution of the switch is performed in substantially the same manner as any other trade, as described above.
  • the position information of each party to the switch is automatically updated to reflect the switch, as indicated by block 590 .
  • a blotter is provided to enable the user to keep track of all the orders he/she has inputted into the market.
  • the blotter is preferably a screen whereby once it is activated, it displays all the outstanding orders a user has in the system.
  • the blotter enables the user to monitor all his/her outstanding orders in many different instruments conveniently in one place.
  • the first is the outstanding order blotter 320 which offers several functions to the user for managing his/her orders, such as the ability to change the price, or size of an order. This is accomplished through the use of dials on the windows which enable the user to quickly dial up or down the price without needing to cancel and then re-submit the order.
  • This edit process shields the user from the complexity of order management regarding changed orders. This also prevents the user from accidentally having duplicate or no orders in the system 10 .
  • the outstanding order blotter 320 also enables the user to quickly suspend (or refer) all of his/her active orders in the system 10 , and then re-input them one by one or delete them as necessary. Yet further, the outstanding order blotter enables the trader to cancel one or all of his orders.
  • the second type of blotter is the historical order blotter 330 . From the historical order blotter, it is possible for the user to view all of his/her previously executed trades and the respective status, as well as those that have been canceled.
  • the system 10 may include a function known as the switch engine.
  • the switch engine is implemented by a switch interface 400 and enables the user to input an entire portfolio of interest rate reset risks into the system 10 , and then view out into the future for an unlimited time horizon on a daily basis.
  • the user inputs the size (in millions) and the direction (receiving or paying) of the reset risks portfolio into the system 10 on a wide range of the most common interest indices (i.e., 1 month US dollar libor, 3 month US dollar libor, 1 month DEM libor, etc.).
  • the portfolio can be input either directly through the portfolio interface 380 (FIG.
  • the system 10 further provides the functionality to permit the trading of various financial instruments via an auction function, as generally illustrated in a flowchart 600 of FIG. 29.
  • the system performs what is referred to herein as a two way Dutch auction with credit preferences.
  • users submit orders into the auction giving both the price and the quantity at which they wish to trade, as indicated by block 602 .
  • the auction process then begins by calculating the price at which the most volume is traded, as indicated by block 604 . This is called the auction-price.
  • the auction-price is a fair price at which all transactions will be completed. In this calculation, the credit preferences of the various counterparties are not yet taken into account.
  • the system matches up orders such that all credit preferences are taken into account such that the minimum number of tickets are generated.
  • the better submitted prices have priority, and all orders at the auction-price are preferably filled in proportion to each other.
  • the auction process could be conducted a few times a day in order to maximize liquidity.
  • the system also offers the functionality to enable the user to trade forward rate agreement switches and other switch products in an auction environment similar to that described previously.
  • the system then automatically generates a confirmation for each transaction and sends it electronically via email, fax, or another means to the counterparties of each executed transaction, as indicated by block 608 .
  • This unique confirmation process has been designed to use a standard and consistent format for all financial instruments.
  • the auction mechanism 34 initially receives an order list from those traders wishing to participate in an auction, as indicated by block 620 .
  • the orders within the order list are separated into a BuyList and SellList, as indicated by block 622 .
  • a price list is generated and sorted from highest price to lowest price. It is then determined at block 626 whether an auction will take place by determining if the price list is empty. If the price list is empty, then no auction takes place, as indicated by block 628 . If the price list is not empty, then the average auction price is calculated, as indicated by block 630 , and as described in greater detail with reference to FIG. 31.
  • the orders are matched such that the minimum number of tickets are generated, taking into account the credit preferences of all parties, as indicated by block 632 , and as described in greater detail with reference to FIGS. 32A and 32B.
  • a settlement list is generated, representing the execution of transactions via the option, as indicated by block 634 .
  • the average auction price is calculated.
  • the total amount in the BuyList is B i
  • the total amount in the SellList is S N ⁇ i+1 .
  • it is determined at block 642 whether k N+1. If so, then the average auction price is P I . If it does not, then it is determined at block 644 whether difference is greater than 0.
  • the parameter list 1 is set to equal SellList and the parameter list 2 is set to equal BuyList, as indicated by block 660 .
  • the order 1 parameter is set to equal to the first order in list 1 and order 1 is removed from list 1 , as indicated by block 662 .
  • the maximum/minimum and credit rules are then applied to search the BuyList for matching order 2 .
  • a matching order 2 is located and a trade is generated between order 1 and order 2 , as indicated by block 666 . If at block 668 it is determined that Ssum is not greater than Bsum, then parameter list 1 is set to equal BuyList and list 2 is set to equal SellList, as indicated by block 668 .
  • orderl is set to equal the first order in list 1 and order 1 is removed from List 1 , as indicated by block 670 .
  • list 2 is searched in order to find a match to order 1 using the maximum-minimum rule and the credit preferences associated with the orders, as indicated by block 672 and described in greater detail with reference to FIG. 33.
  • a trade is then generated between order 1 and order 2 , as indicated by block 674 .
  • the parameter volume is equal to the volume of an order, and more particularly, of order 1 .
  • the process begins again at block 680 . If the trade volume is not equal to 0, then a trade is generated and placed in the settlement list, as indicated by block 690 . In addition, at block 692 , order 2 is removed from list 2 . Next, the volume of order 1 and order 2 are updated by setting the respective volumes to the previous volumes minus the trade volume, as indicated by block 694 . It is then determined at block 696 if the volume of order 2 is equal to zero. If it is not, then order 2 is placed back in a temporary list and a credit of the parties placing order 1 and order 2 are updated, as indicated by block 698 . Once the volume of order 1 is determined to be zero, then it is determined at block 702 whether the temporary list is empty. If it is not, then the temporary list is merged with the BuyList, as indicated by block 704 . Subsequently, the process ends.
  • FIG. 34 functionally depicts the group server mechanism 32 , the auction mechanism 34 and switch mechanism 35 , the market inventory module 38 , the execution module 40 , and the settlement module 42 .
  • a legend 710 is provided to the denote the flow of the different orders, interactive and switch orders, auction orders, and switch auction orders, between the group server mechanism 32 , the auction mechanisms 34 , the market inventory module 38 , the execution module 40 , and the settlement module 42 .
  • the central processing center 12 initially receives the interactive/switch order 712 at the group server mechanism 32 .
  • an order record is created, the credit preferences of the users are checked to assure the trade conforms to the current credit preferences of the users, and a transaction order is created. If the order is passive, then it flows through to the market inventory module 38 where is it distributed to the trader workstations 20 for viewing via respective market detail interfaces 302 of the users logged on the system 10 . If the order is active, then it flows through to the market inventory module 38 where order matching occurs if the order is a part of an auction, and pre-execution of the order also occurs. Pre-execution may include, for instance, a back-end credit check to ensure up to date credit preferences and to accommodate complex checks.
  • the market inventory module 38 requires the trader workstations 20 of the respective users that are a party to the trade to respond with an acknowledgement to assure that there has been no loss of communication or that one of the users has not logged off. Upon receiving the acknowledgement, the market inventory module 38 executes the trade and then publishes the updated volume and status to the users logged on to the system 10 for viewing via respective command center interface 130 of the users.
  • the execution module 40 will, upon request of one of the users that were a party to the trade, enables the quantity of the trade to be increased via the will-do-more feature. This will typically be the case unless the full quantity of the instrument is transacted. Otherwise, the execution module will initiate the confirmation process which includes an opportunity for either of the users that were a party to the trade to enter into term negotiations.
  • the settlement module allows for symbol explosion by the users to view the exact terms of the contract. Further, a settlement module calculates the commission based upon the order which ends the process, thereby noting the end of the order execution process.
  • an auction order 714 received by the auction mechanism 34 receives the auction orders 714 a from a plurality of users during a countdown to the actual auction time. Once the auction time has arrived and the auction orders have been submitted, the auction mechanism 34 performs the auction matching with credit preferences of the users taken into account.
  • the auction matching performed by the auction mechanism 34 is in accordance with the present invention, that is, the auction is based on a fair price and executed for a maximum volume traded with a minimum number of tickets generated.
  • the market inventory server essentially treats the resulting auction orders as though it would an interactive/switch order 712 .
  • the market inventory module 38 perform order matching, pre-execution, acknowledgement, trade execution and volume/data publishing.
  • the auction order 712 is then delivered to the execution module 40 .
  • an auction order and a switch auction order are traded slightly different. For instance, an auction order may be increased in quantity by one of the users that is a party to the auction order via the will-do-more.
  • switch auction orders do not make use of this feature, but will go directly to the confirmation process.
  • auction orders may also have their non-commercial terms negotiated using the term negotiation feature, switch auction orders will flow to the settlement module 42 directly after confirmation. Both auction orders and switch auction order are then received by the settlement module 42 which performs essentially the same operations to the auction order as it does to an interactive/switch order 712 .
  • the settlement order 42 provides similar explosion and commissioned calculations which complete the order process.

Abstract

An internet-protocol based anonymous trading system which enables traders to identify bids and offers which they are eligible to trade based upon a color coded methodology which gives the trader credit preference information about the potential counterparty while still maintaining the anonymity of the potential counterparty. To that end, each bid or offer is prescreened against all possible counterparties' credit information in the system and each counterparty sees a unique color coded trading interface based upon their particular credit preference combinations and the others in the system. The system then shows all prices in the system, and the color-coding tells the trader which prices he is able to trade, and also shows him the full depth of the market, including those the trader is unable to trade.

Description

    CROSS-REFERENCE TO RELATED APPLICATION
  • This application claims benefit of co-pending U.S. Provisional Application No. 60/062,410, entitled “Systems and Methods for Electronic Trading of Financial Contracts,” and filed Oct. 14, 1997. In addition, the present application is related to the following co-pending, commonly assigned U.S. applications, each of which is incorporated by reference as if set forth in full: [0001]
  • “Systems, Methods And Computer Program Products For Subject-Based Addressing In An Electronic Trading System,” filed Oct. 12, 1998, and accorded Application No.:______; [0002]
  • “Systems, Methods And Computer Program Products For Monitoring Credit Risks In Electronic Trading Systems,” filed Oct. 12, 1998, and accorded Application No.:______ ; and [0003]
  • “Switch Engine For Risk Position Discovery In An Electronic Trading System,” filed Oct. 12, 1998, and accorded Application No.:______. [0004]
  • FIELD OF THE INVENTION
  • The present invention generally relates to brokerage systems and methods, and more particularly, to the electronic trading of financial instruments such as derivatives. [0005]
  • BACKGROUND OF THE INVENTION
  • In recent years, commodity exchanges have become more and more dependent upon electronic trading systems. The older manual methods by which trades were conducted have given way to advanced computer systems that have generally mimicked the manual methods of old. These relatively new electronic trading systems have many advantages over the manual systems, including the ability to provide such features as greater accuracy, reduced labor cost, real time market information, more efficient communications over greater distances, and automated record keeping. However, because the markets in which these commodities are being traded are so vastly different from the descriptions of the instruments to the transaction methodologies, electronic trading systems are generally limited to a specific market such as futures, cash, oil, stock, securities, etc., and sometimes even to a specific commodity within a single market. [0006]
  • An example of one such automated trading system designed for the anonymous trading of foreign currencies is described in U.S. Pat. Nos. 5,077,665 and 5,136,501, both issued to Silverman et al. and assigned to Reuters Limited of London. In the Silverman et al. system, a single central host computer maintains a central database that may consist of the trading instruments available for trade, credit information, and various bids and offers that are present throughout the system. The host computer may then use this information to match active bids and offers based on matching criteria which may include the gross counterparty credit limit between counterparties to a potential matching transaction, price, and available quantity. To that end, each client site may establish, and may subsequently vary or reset, a credit limit for each possible counterparty. The credit limits may be used by the host computer to establish the gross counterparty credit limit for each possible pair of parties and which may be equal to the minimum of the remaining credit (i.e., initial credit limit less any applicable transactions that have already been executed) from a first party to a second party and from the second party to the first party. The host computer may block completion of an otherwise eligible matching transaction between a given pair of potential counterparties when the transaction has an associated value in excess of the applicable gross credit limit. In the Silverman et al. system, the various client site computers (also referred to as keystations) merely maintain and display a restricted subset of the information available at the host computer such as a predetermined number of the best bids and offers, and communicate credit and other transaction orientated information to the host computer for execution. However, in an attempt to preserve the anonymity of the parties, the client sites may not have access to the credit limits set by their possible counterparties, or even to the identification of any other party to a particular transaction until after a transaction has been completed. [0007]
  • Thus, in the Silverman et al. system, confidential counterparty credit limit data is apparently maintained and utilized as part of the trade matching process by the central host computer. As a consequence, each client site may not have the ability to determine, prior to committing to buy or sell at a displayed price from one or more anonymous counterparties, whether it is in fact eligible to respond to any of the bids or offers currently being displayed. Further, the credit limit appears to be merely a cap value (or credit line) on the amount of trading one party will enter into with another party. It has little to no relationship to the credit risk the other party represents since the financial commitment associated with the financial instruments traded with this system ends at the consummation of the underlying contract. Thus, a cap value may be sufficient in this particular circumstance. The central host computer may not utilize the credit information until after a match has been found between counterparties to determine if the counterparties have sufficient credit with one another to execute the trade. [0008]
  • Consequently, unless a trader attempts to execute a trade at the best price currently displayed on the trader's screen, the trader using one of the anonymous matching systems may not know whether the trader has credit with, and is willing to extend credit to, the anonymous counterparty offering (i.e., bidding) the best price currently displayed on the trader's screen. Thus, the trader does not know whether any attempt to buy or sell at the displayed price may be subsequently invalidated by the system for lack of such credit. The Silverman et al. system also fails to provide for dialogue between the parties, much less anonymous dialogue which may facilitate the execution of a trade that might otherwise not occur. [0009]
  • Reuters Limited has apparently expanded the system described in Silverman et al. to include Forward Foreign Exchange contracts which are derivative instruments. However, as opposed to offering a settlement risk system that enables credit analysis prior to face-to-face settlement, the Reuters Limited system introduces the concept of soft matching which makes trades on the basis of credit risk rather than settlement risk. Thus, a trade is not confirmed until both parties obtain subsequent credit approval. Either party can cancel the transaction under the guise of no credit available to the counterparty once they know who is the counterparty. Accordingly, the Reuters Limited system is reportedly an unpopular solution to derivative trading via an electronic trading system. [0010]
  • Another automated trading system is disclosed in U.S. Pat. No. 5,375,055 issued to Togher et al. and assigned to Foreign Exchange Transaction Services, Inc. The Togher et al. system is an anonymous trading system which may identify the best bids and offers from those counterparties with which each client site is currently eligible to deal, while maintaining the anonymity of the potential counterpart and the confidentiality of any specific credit limitations imposed by the anonymous potential counterparty. This system is apparently designed to run as a closed system, with dedicated desktop terminals connected to various local computer centers, which are in turn connected to regional computers. [0011]
  • In the Togher et al. system, each client site may only be able to view one foreign currency at a time per screen. The Togher et al. system is further limited by the fact that each client site may provide the system with only limited credit information for each potential counterparty (for example, a one bit flag indicating whether a predetermined limit has already been exceeded), and by the fact that each bid or offer for a particular type of financial instrument is apparently prescreened by the system for compatibility with that limited credit information before calculating an anonymous dealable price for presentation to the traders dealing with that particular financial instrument. The prescreening in Togher et al. is a simple check to determine whether any credit remains between the two counterparties to the potential transaction, and thus may be performed using a simple yes/no preauthorization matrix. [0012]
  • The preauthorization matrixes may be maintained at each of the several regional nodes (also referred to as distributed nodes) of a distributed processing communication network, with each such regional node being connected by corresponding individual links of the communications network to the respective client sites for which it is responsible for distributing market information including customized dealable bid and offer prices, and global best prices. [0013]
  • The sensitive credit limit data indicating how much credit a particular client site is willing to extend to each possible counterparty is preferably maintained at an access node associated with that particular client, and a simple yes/no indication of whether the entity (for example, a trader, a trading floor, or a bank) associated with that particular client site is willing to transact business with a particular counterparty is transmitted to the other nodes of the communications network. [0014]
  • To further limit the data received and processed by each of the relevant regional node computers (i.e., the regional nodes closest to the particular client site and/or closest to the particular counterparty), merely the changes in the credit state between a particular client site and a particular counterparty (i.e., that credit is no longer available or credit is now available) may be transmitted to the distribution nodes, and any credit state information relevant to transactions between two client sites both associated with other distribution nodes may be altogether ignored. [0015]
  • In the Togher et al. system, if either of the two applicable credit limits has not previously been exceeded between a particular pair of counterparties, then the system displays the entire bid or offer as a dealable transaction, but apparently permits each client site to block any above-limit portion of any resultant buy or sell transaction during a subsequent deal execution/verification process. This may, however, add additional time consuming steps for the users of the Togher et al. system. Alternatively, possibly at the option of the party by or for whom the low limit has been set, the entire transaction may be blocked. As a second alternative, a preauthorization matrix may indicate whether sufficient credit remains to execute a predetermined standard deal amount in addition to, or instead of, a mere indication as to whether any credit from a particular potential counterparty had already been used up. In such an alternate embodiment of the Togher et al. system, it might also be possible to display to each trader two dealable prices: one at which at least the predetermined standard amount is available, and a second one at which only a small amount may be available. Thus, individual orders are not independently treated, and the user may not have the ability to look through the bids and offers and deal at a worst price, if the user so chooses because of a difference in counterparties credit qualities. [0016]
  • In accordance with another aspect of the Togher et al. system, at least a first trader having an open quote that is displayable as the best dealable or regular dealable quote at any of the other trading floors is automatically alerted that their bid (offer) quotation is the best price available to at least one potential counterparty with whom mutual credit exists, and thus could be hit (taken) at any time. Similarly, at least if the quoter's bid (offer) quote is not currently the best with at least one trading floor but is thus subject to immediately being hit (taken) by a trader at that trading floor, then the quoter is preferably also alerted if his/her quote is joined (i.e., equal to in price, but later in time) to such a best dealable or regular dealable price from another trading floor. In other words, in the Togher et al. system, the auto-matching process does not enable the active trader to select a price other than the best price to trade. This may force the trader to accept what the system offers, even if the trader would prefer a different counterparty for credit reasons. In addition, the Togher et al. system does not show the trader the total depth of the market, only those prices which are dealable, and thus, may fail to give the trader a complete picture of the market. The trader is also limited to the quantity stated. No provision is made for the modification or negotiation of the quantity or other terms of the trade. [0017]
  • The systems described above are such that they focus on overnight settlement risk. These systems are apparently incapable of dealing with the actual credit requirements of a variety of different individual financial instruments simultaneously, or a counterparty's long-term ability to meet these requirements. As a result, these systems generally have only been deployed in the markets where settlement takes place in a few days of the transaction, and there are no continuous and ongoing credit requirements or obligations between the counterparties. Specifically, as a result of these limitations, these designs may not be able to support the anonymous trading of financial instruments such as interest rate swaps, caps and many other financial products. They may be unable to accommodate these more complex financial instruments because, among other things, these systems apparently treat all financial instruments alike, and therefore, may be incapable of handling more complex financial instruments which require a determination about the financial strength of the opposing counterparties. Trades conducted with some financial instruments such as derivatives create multi-year financial commitments, and therefore, mere credit limit or credit cap systems are insufficient in measuring and managing an institution's credit risk. [0018]
  • Accordingly, it is noted that no known system is designed to operate with derivative products such as interest rate swaps, caps, floors, forward rate agreements (FRA), interest rate basis swaps, interest rate options, foreign exchange, switches, or any other over the counter derivative instruments. Derivatives are considered by many to be too complex to be efficiently handled within an electronic trading system. Specifically, derivative products are typically define by certain terms and conditions, and the different types of derivatives products are defined by different sets of terms and conditions. For example, an FRA is generally defined by a start time, an end time, an over date, and a floating rate option, while an interest rate swap is generally defined by a start time, an end time, an over date, a floating rate option, a frequency of the fixed coupons, a basis, and a special rule(s) as applicable with some currencies. Accordingly, the variances in the specific information necessary to adequately define the different derivative products has apparently been a deterrence to the development of an electronic derivatives trading system. [0019]
  • Yet another deficiency of the prior art systems is the inability to automatically determine one's position (i.e., credit risk position), and the inability to identify possible counterparties with offsetting positions for initiating a transaction. No know electronic trading system has been able to provide this information on a real-time basis. This strikes to the essence of the derivatives market which is based upon large financial institutions being able to manage their credit risk and market risk on a daily basis. [0020]
  • Thus, a heretofore unsatisfied need exist in the industry for an automated system for distributing anonymous price and position information via a customized financial instrument symbology that enables traders to effectuate credit-based trades of complex instruments such as those in the derivatives markets. [0021]
  • SUMMARY OF THE INVENTION
  • It is therefore an object of the present invention to provide an improved electronic trading system for trading derivative financial instruments. [0022]
  • It is another object to the present invention to provide anonymous credit-based trading of financial instruments. [0023]
  • It is another object to the present invention to provide substantially real-time status information for selectable markets. [0024]
  • It is another object to the present invention to provide flexible control of outstanding and executed orders within an electronic trading system. [0025]
  • It is an object of the present invention to allow users of an electronic trading system to place passive orders and active orders. [0026]
  • It is an object of the present invention to provide electronic means which enable traders to communicate or broadcast interest in a specific financial instrument anonymously to other traders who may respond with a request to trade. [0027]
  • These and other objects of the present invention are provided for by systems, methods, and computer program products that provide for electronic trading based on the client/server model, including a central processing center (i.e., server) having multiple server modules and a plurality of individual trader workstations (i.e., clients), all of which are operationally interconnected, preferably via an Internet-protocol network. Because of the open architecture of the system, it is possible that the system may run within the context of an Internet browser on a user's existing desktop computer. At the user's workstation, the user may select from a variety of different interfaces that enable the user to follow markets, enter and execute trades, and monitor outstanding and historical orders and executions. Thus, the user is provided an in-depth view of the market and essentially complete control over the order load process. [0028]
  • The market information provided to the user is coded with credit preference data generated by referencing the complex credit preferences inputted by each user regarding all possible counterparties. Thus, potential counterparties are then able to identify which orders they are eligible to trade based upon the coded credit preference data. The user is also provided with a feature whereby the user can input an interest reset risks portfolio into the system and then view his/her interest rate reset risk position relative to other counterparties that have inputted their respective interest rate reset risks portfolios in order to determine possible offsetting positions. The user is also provided with a facility for placing orders for various financial instruments via an auction process whereby the system automatically matches all orders and determines the prices and quantities executed based on several guidelines including user credit preferences. In addition, the user is provided with a switch auction facility whereby the user can use the auction process to trade forward rate agreement (FRA) switches with other counterparties utilizing the same credit preference screening. [0029]
  • At the central processing center, multiple server modules operate simultaneously to perform various functions such as delivery of market information to the user, credit preference verification of a requested trade, execution of trades, term negotiation, acknowledgments, position discovery, and auction execution. The central processing center also includes a database which provides persistent storage of information such as historical data, instrument definitions, user credit preferences, user and business unit data, and historical market data. [0030]
  • At the trader workstations, multiple software modules operate simultaneously to perform various functions at the front end of the system such as providing user interfaces, performing credit preference verification, and receiving inputted user data such as trade data and credit preferences. The trader workstations are preferably implemented on desktop computers of the users via an Internet browser program, and therefore, do not require dedicated terminals on the users' desktops. The communication between the trader workstations and the central processing center is preferably based on Internet Protocol (IP), and operates over the Internet in a secure mode. [0031]
  • In accordance with an embodiment of the present invention, a system for facilitating derivative trading comprises a communication network interconnecting a first user and a second user to a central processing center, and a market inventory module associated with the central processing center that provides the first and second users with essentially real-time order information regarding more than one financial instrument, wherein the order information includes requests to buy financial instruments and requests to sell financial instruments. In addition, the system may include a trader module associated with each of the first and second users for receiving the real-time order information from the central processing center and for presenting the real-time order information to the first or second users according to respective user customized profiles. The system may further include a credit preference module associated with each of the first or second users, wherein the credit preference modules indicate the trade eligibility of the respective first and second users for each request to buy or sell. In addition, the system may comprise an execution module associated with the central processing center that processes a trade initiated by one of either the first or second users which desires to trade on an order posted in the order information by the other of the first and second users. In essence, the execution module processes the term negotiations and will-do-more services. In addition, the system may comprise a settlement module associated with the central processing center for processing transactions and generating confirmation notices, which are submitted to both parties. The settlement module also calculates the commission fees. [0032]
  • The credit preference module described above may determine the trade eligibility based on credit preferences of both the first and second users. This system may further include a switch module that receives interest rate swap positions from the first and second users, and determines relative position information for the first and second users. [0033]
  • In accordance with another embodiment of the present invention, a system for facilitating derivative trading, wherein the system includes a plurality of interconnected user nodes configured to exchange order information via a central processing center. The central processing center may comprise a first user node including a trader module that receives real-time order information and presents the real-time order information to a user according to the customized profiles defined by a first user, a credit preference module that includes credit preference data inputted by the first user for use in determining trade eligibility of trades proposed in the real-time order information with a second user, and an interface to a communications network that interconnects the plurality of user nodes. Each user node may further include a switch module that receives interest rate swap positions from the first user and the second user, and that determines relative position information for the first user. [0034]
  • In accordance with yet another embodiment of the present invention, a system for facilitating derivative trading, wherein such system includes a plurality of interconnected first and second users that exchange order information, and wherein each of the first and second users are connected to a central processing center. The central processing center may comprise a group server that provides the first and second users with essentially real-time order information regarding more than one financial instrument. The order information preferably includes requests to buy financial instruments and requests to sell financial instruments. The central processing center may further comprise an execution module that can process a trade initiated by one of either the first and second users which desires to trade on an order proposed in the order information by the other of the first and second users. This central processing center may further include an interface to a communications network that interconnects the plurality of first and second users to the central processing center. [0035]
  • Other features and advantages of the present invention will become apparent to one that is skilled in the art upon examination of the following drawings and detailed description. It is intended that all such additional features and advantages be included herein within the scope of the present invention, as defined in the appended claims. Further, it will be appreciated by those of skill in the art that the above-described systems of the present invention may be provided as methods or computer readable program means.[0036]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The file of this patent contains at least one drawing executed in color. Copies of this patent with color drawings will be provided by the Patent and Trademark Office upon request and payment of the necessary fee. [0037]
  • FIG. 1 is a schematic diagram of a computer network implementing an electronic trading system in accordance with an embodiment of the present invention. [0038]
  • FIG. 2 is a block diagram illustrating the architecture and functionality of a central processing center in accordance with an embodiment of the present invention. [0039]
  • FIG. 3 is a block diagram illustrating the architecture and functionality of a trader system in accordance with an embodiment of the present invention. [0040]
  • FIG. 4 is a block diagram illustrating the architecture and functionality of a business unit proxy in accordance with an embodiment of the present invention. [0041]
  • FIG. 5 is an example of a command center interface. [0042]
  • FIGS. [0043] 6A-6B are examples of different tabbed partitions of a user preference interface.
  • FIG. 7 is an example of a credit preference setting interface. [0044]
  • FIGS. 8A and 8B are examples of different tabbed partitions of a modify credit groups interface. [0045]
  • FIGS. 9A and 9B are examples of the new binary interface and complex preference interface respectively, which are accessible from the credit preference setting interface. [0046]
  • FIG. 10 is an example of a business unit information interface. [0047]
  • FIG. 11 is an illustration of the credit preference logic of an embodiment of the present invention. [0048]
  • FIG. 12 is an example of a market entry interface. [0049]
  • FIG. 13 is an example of a symbol definition interface. [0050]
  • FIG. 14A is an example of an passive order interface. [0051]
  • FIG. 14B is an example of an hit order interface. [0052]
  • FIG. 15 is an example of a market detail interface. [0053]
  • FIG. 16 is an example of an outstanding order blotter interface. [0054]
  • FIG. 17 is an example of a client monitor interface. [0055]
  • FIG. 18 is an example of a execution notification and quantity negotiation interface. [0056]
  • FIG. 19 is an example of a term negotiation interface. [0057]
  • FIG. 20 is an example of a user position portfolio interface. [0058]
  • FIG. 21 is an example of a switch interface. [0059]
  • FIGS. 22A and 22B are examples of an auction interface and a switch auction interface, respectively. [0060]
  • FIG. 23 is an example of a main screen interface in accordance with an embodiment of the present invention. [0061]
  • FIG. 24 is a flowchart of the credit preference feature in accordance with an embodiment of the present invention. [0062]
  • FIG. 25 is a flowchart of the subject based addressing feature in accordance with an embodiment of the present invention. [0063]
  • FIG. 26 is a flowchart of the execution of a trade in accordance with the embodiment of the present invention. [0064]
  • FIGS. 27A and 27B are flowcharts of a trade execution from the perspective of the user posting the order and the user acting on the order, respectively, and in accordance with an embodiment of the present invention. [0065]
  • FIG. 28 is a flowchart of the position discovery feature in accordance with an embodiment of the present invention. [0066]
  • FIG. 29 is a flowchart of the auction feature in accordance with an embodiment of the present invention. [0067]
  • FIG. 30 is a detailed flowchart of the auction feature in accordance with an embodiment of the present invention. [0068]
  • FIG. 31 is a flowchart of the calculation of the average auction price in accordance with an embodiment of the present invention. [0069]
  • FIG. 32 is a flowchart of the matching performed in an auction in accordance with an embodiment of the present invention. [0070]
  • FIG. 33 is a flowchart of the validation of a resulting order in an auction in accordance with an embodiment of the present invention. [0071]
  • FIG. 34 is a process flow diagram illustrating operations and functionality of the central processing center in accordance with an embodiment of the present invention.[0072]
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. [0073]
  • I. Introduction [0074]
  • The following description is of a best-contemplated mode of carrying out the present invention. The systems, methods, and computer program products of the present invention have practical application in anonymously trading a very broad cross-section of credit-sensitive, bilateral financial instruments. However, a particular application of the present invention described hereinafter is directed to the use of the present invention for trading financial instruments in the derivatives market. The scope of the present invention should not be limited to that described hereinafter, but should be determined by referencing the appended claims. [0075]
  • The present invention provides for a standardized contract definition, and means for matching complex credit preferences of each counterparty before a trade is executed. Therefore, potential counterparty users are able to identify bids and offers that they are eligible to trade based on credit preference information provided before initiating a trade. The present invention also permits users to place passive orders (bids or offers on the various financial products for other counterparties to actively choose from to hit (bids) or lift (offers), without the posting user doing anything further) or active orders (where the viewing user actively initiates the trade by selecting passive bids or offers which are already in the system). This gives a user maximum control over the order flow process. For instance, there may be a situation whereby the bids in a particular market are higher than the offers, but no trading is taking place. This situation may occur when the credit quality of the best offer (which in this case would be below the bid) would not be good enough for a bidder to be willing to enter into a transaction with that counterparty. This is a significant difference from the prior art systems in which orders are automatically matched if the prices are equal because such prior art systems typically limited the user's control over the order flow. [0076]
  • The present invention also provides financial markets with electronic trading systems and methods for identifying possible counterparties and executing trades for forward rate agreement (FRA) switches and other financial products. The present invention further provides the ability for the users to place orders for various financial instruments via an auction process that can be one-to-many or many-to-many, whereby the system automatically matches all orders and determines the prices and quantities executed on the basis of several guidelines or parameters. A further feature of the present invention is an auction trading that is available to users, whereby users can use an auction process to trade FRA switches with the other counterparties. This form of auction is referred to hereinafter as a switch auction. In the auctions, the price is preferably predetermined by the system prior to the auction taking place. The prices determined by the system are referred to hereafter as the fair price. [0077]
  • The systems and methods of the present invention are designed to reflect the fact that financial institutions operate under many different structures. In order to accomplish this, the following concepts/definitions are provided: [0078]
  • Legal Entity (LE): [0079]
  • This is the incorporated entity in which contracts are negotiated on behalf of by users (traders) of the system. [0080]
  • Business Unit (BU): [0081]
  • This is a grouping of individual users within a Legal Entity that act together and share attributes such as LE, manager, address, settlement information, credit preferences (see below), etc. [0082]
  • Risk Equivalent (RQ): [0083]
  • This is the unique measure of Risk associated with financial contracts such that contracts with different attributes can be compared on a like basis for credit risk purposes. [0084]
  • Credit Preferences (CP): [0085]
  • This is the model which allows the system to handle different measures of risk equivalent used by different institutions and different financial contracts, all with different internal structures. [0086]
  • Classes of Financial Instruments (CL): [0087]
  • These are collections of financial contracts which share similar attributes. [0088]
  • Credit Groups (CG): [0089]
  • A method to allocate credit preferences across classes of financial contracts. [0090]
  • User Preferences (UP): [0091]
  • A method to allow institutions or users to control or manage access to the functions within the system. [0092]
  • Filters (FI): [0093]
  • These allow users to limit the messages (i.e., request for price or request for switch they receive or view. [0094]
  • Symbology (SY): [0095]
  • This enables users to quickly and easily reference financial contracts within the system in a systematic manner. [0096]
  • Term Negotiation (IN): [0097]
  • This is a method which allows users to negotiate non-commercial terms of contract subsequently to a trade. For example, the exchange of bonds relating to a spread trade. [0098]
  • Credit Over-Ride Process: [0099]
  • This process enables a user to disclose his/her identity to a counterparty to see if they will accept a trade with him/her even though they initially refused him due to credit issues. [0100]
  • Comprehensive Confirmations: [0101]
  • This is a confirmation lay-out in order to fully define bilateral contracts across any classes of financial instruments. [0102]
  • Request For (RF) [0103]
  • This is a method to broadcast to the other users (subject to their FI) an interest in a price or market. [0104]
  • II. System Architecture [0105]
  • As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, a data processing system, or a computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program code means embodied in the storage medium. Any suitable computer readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices. [0106]
  • The present invention is described below with reference to block diagrams and flowchart illustrations of methods, apparatus (i.e., systems) and computer program products according to an embodiment of the invention. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks. [0107]
  • These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. [0108]
  • Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions. [0109]
  • A trading system in accordance with the present invention is an electronic brokerage system which may use Internet protocol-based communications networks for facilitating the trading (i.e., buying and selling) of financial derivatives by users, each of which is associated with the user's own desktop computer system (trader system) located on the trading floor of a financial institution (client site), as described below. At the user's desktop computer system, the present invention is preferably implemented by a Java-based software program, though other suitable program languages can be utilized such as dynamic hypertext markup language (DHTML), C+ or C+. [0110]
  • As shown in FIG. 1, a [0111] trading system 10 in accordance with the present invention comprises a central processing center 12 which is in communication with the client sites 14 via one or more of a variety of Internet protocol based networks 16. By way of illustration, a private extranet, a public Internet, and a third party extranet are show, though it will be recognized by those skilled in the art that other networks such as the Public Switch Telephone Network (PSTN) may be implemented as a network 16. Further, by having multiple networks 16 available, the user is provided redundancy in case one network experiences a service interruption, and the user is able to choose between the several networks 16 for primary access based on factors such as toll charges or bandwidth.
  • Each [0112] client site 14 includes one or more business unit servers 18 which, among other things, can store copies of the Java applets which can be utilized to implement the present invention. The business unit servers 18 may also perform encryption/decryption functions for messages that are received and sent over the networks 16. The business unit servers 18 are preferably connected to the client sites 14 internal data network. Thus, one or more trader workstations 20 may be connected to a business unit server 18 of a client site 14. Accordingly, a user's own desktop computer which is connected to the client's internal data network may function as a trader workstation 20 and run the Java-based software of the present invention to enable interaction with other trader workstations 20 via the central processing center 12.
  • With reference to FIG. 2, illustrated is the [0113] central processing center 12 which includes a trade mechanism 30, a group server mechanism 32, auction mechanism 34, and a switch mechanism 35, all in accordance with the present invention. The trade mechanism includes several modules including a market inventory module 38, an execution module 40, and a settlement module 42. The market inventory module 38 holds the passive orders for each market and broadcast the same to the trader workstations 20 when new orders are received, validates any proposed trade, performs a second and final credit preference check that cannot be performed at the trader workstation 20, validates that both traders are still on-line (i.e., active), executes the trade, and sends out a status update to the traders. The execution module 40 receives the executed trade and proposes a trade for a greater quantity if applicable (referred to as the will-do-more feature), and processes term negotiation if applicable. The settlement module 42 calculates the appropriate commission, generates the confirmation, and sends the confirmation to the two parties.
  • The [0114] group server mechanism 32 interfaces the trader module 30 with the trader workstations 20. The central processing center 12 may include a plurality of group server mechanisms 32, each of which preferably serves a subset of the users (i.e., trader workstation) of system 10, though the system 10 may be implemented with only one group server mechanism 32. The group server mechanism 32 monitors the connection of each trader workstation 20 so that log-in and log-out times and usage can be monitored. The group server mechanism 32 also caches market information being viewed at each trader workstation 20 and create an order identification code that uniquely identifies that order. The credit preference information of all users is cached in by the group server mechanism 32 for delivery to each trader workstations 20 when the associated user logs in. Any changes in the credit preference setting by a trader are detected and forwarded to the trader workstations 20 of the other users.
  • The [0115] switch mechanism 35 is configured to receive a portfolio of interest reset risk for a plurality of users and provide the users with an anonymous view at their relative position to other possible counterparties and available trades that may offset the user's interest rate reset risk. The auction mechanism 34 performs a switch auction function whereby orders or FRA's are received from the users and anonymously matched based on an algorithm that takes user credit preferences into consideration.
  • The [0116] trader mechanism 30, group server mechanism 32, auction/switch auction mechanism 34, and switch mechanism 35 may be collectively implemented as market module 44.
  • The [0117] central processing center 12 includes a processor 50 that communicates with the other elements within the central processing center 12 via a system interface 52. An input devise 54, for example a keyboard or a pointing device, is used to input data from a user, and a screen display device 56, for example, a monitor, is used to output data to the user. A memory 58 within a central processing center 12 includes the market module 44 and a conventional operating system 60 which communicates with the market module 44 and enables execution of the market module 44 (including the trade mechanism 30, group server mechanism 32, and auction mechanism 34) by processor 50. An external communication line 62 is provided to interface the central processing center 12 with other computer systems or computer-based devices such as networks 16. Lastly, a hard disk 64 may be provided as a persistence memory device, as well known to the industry. Preferably, a relational database 66 resides on the hard disk 64 for maintaining information such as current state information for each trader workstations 20, user and business unit data, financial instrument definitions, order states, transaction states, confirmation states, historical confirmation and transaction data, credit preferences of all business units, and historical market data. Preferably a relational database 66 resides on the hard disk 64 for maintaining information such as current state information for each trade workstation 20, user and business unit data, financial instrument definitions, order states, transaction states, confirmation states, historical confirmation and transaction data, credit preferences of all business units, and historical market data. Preferably, the relational database 66 is based on structured query language (SQL) management system, as well known in the industry.
  • With reference now to FIG. 3, illustrated is an embodiment of the [0118] trader workstations 20 which includes a trader module 70 in accordance with the present invention. The trader module 70 may be implemented as a component of a Java-capable Internet browser program 72, such as Netscape Communicator® (Netscape Communication Company) or Microsoft® Internet Explorer (Microsoft Corporation) version 3.0 or higher. Thus, in a preferred embodiment, the trader module 70 is a Java-based program that is downloaded as Java applets for each session and implemented by a Java virtual machine (JVM) 73 within the Internet browser 72. The JVM 73 of the Internet browser program 72 may be a stand alone software application, a plug-in application, or a helper application, all of which is well known in the art. The trader module 70 includes a market interface module 74, a credit preference module 76, a symbol module 78, switch module 80, and an auction module 81. The market interface module 74 comprises one or more user interfaces for presenting information to the user. In the context of the present embodiment, a user interface is provided as a window within the context of the Internet browser program 72. However, a user interface in accordance with the present invention may take many forms such as a three dimensional virtual reality world based on virtual reality modeling language (VRML), an audio receiver/transmitter, or any other suitable form of interface between the user and trader workstations 20. In a preferred embodiment, the market interface module 74 comprises a control center interface, market entry interface, market detail interface, switch interface, and auction interface, all of which are described in more detail hereinafter.
  • The [0119] credit preference module 76 receives the stored credit preferences inputted by the user and stored at group server mechanism 32. The stored credit preferences include preferences directed to the other business unit's legal entities, and the preferences inputted by the other users directed toward the business unit's legal entity of the subject user. As mentioned above, the credit preference information is preferably stored in the database 66 (FIG. 2). The credit preference module 76 may encode the order information being presented to the user with the credit preferences of the user and the credit preferences of counterparty that posted the order. The credit preference module 76 also performs a credit preference check for each order when a trade is initiated. Because of the potential complexity associated with the different types of credit methods offered by the present invention, portions of the credit check process may be performed by the market inventory module 38 of the central processing center 12. The credit preference module 76 at each trader workstation 20 comprises a simplified matrix of yes's and no's, and associated maturities. If the business unit has selected an even more complex method (i.e., complex), a unit (such as a risk quotient, i.e., RQ) by maturity is also required. The trader workstation 20 will therefore not be able to determine whether the full quantity can be traded. Thus, the market inventory module 38 repeats the credit check to ensure the very latest credit preferences are used (in case of any latency in updating the credit preferences at the trader workstations 20) and to complete any complex credit preference check for quantity.
  • The [0120] symbol module 78 stores the symbol definitions utilized for the subject-based addressing of the different financial instruments traded in the system 10. The symbol module 78 also provides means for defining new symbols for use with the system 10. The switch module 80 is configured to receive interest rate reset risk portfolios from the user which are sent to the switch mechanism 35 at the central processing center 12. The relative position information generated by the switch mechanism 35 is returned to the switch module 80 which presents the position information to the user via the market interface module 74. The auction module 81 is configured to receive multiple or batch orders on a single instrument at different price levels, and in case of a switch auction, to receive a interest rate reset risk portfolio from the user. The inputted orders or portfolio is sent to the auction server 34 at the central processing center 12 where the auction or switch auction, respectively, is performed. The resulting matches are returned to the auction module 81 which presents the results to the user via the market interface module 74.
  • The [0121] trader workstations 20 includes a processor 82 that communicates with other elements within the trader via a system interface 84. An input device 86, for example, a keyboard or pointing device, is used to input data from the user, and a screen display device 88, for example, a monitor is used to output data to the user. A memory 90 within the trader workstations 20 includes the Internet browser program 72 (and thus, the trader module 70) and a conventional operating system 94 which communicates with the Internet browser program 72 and enables execution of the Internet browser program 72 (and thus, the trader module 70) by processor 82. It is noted, however, that the trader module is preferably implemented as a Java-based program that is downloaded into memory 90 for the execution during a single session, and the trader workstations 20 will not persistently store the trader module 70. Further, as a Java-based program, the trader module 70 will be executed on a JVM 73 which is a component of the Internet browser program 72.
  • An external communication link [0122] 96 is provided to interface the trader workstations 20 with other computer systems or computer-based devices such as respective business unit servers 18. Lastly, a hard disk 98 may be provided as a persistent memory device, as well known in the industry. It is noted that the trader workstation 20 may comprise a desktop computer system as previously mentioned, or alternatively, the trader workstation may comprise a portable computing device such as a notebook computer, handheld PC, personal digital assistant (PDA) or any other suitable device capable of running an Internet browser program and creating a communication link for interfacing with a network.
  • Therefore, a user of the [0123] system 10 is not necessarily tied to a specific hardwired terminal, but has a virtual terminal that goes with the user wherever the user has access to a Java capable browser and Internet access. The trader module 70 may be implemented as an independent program capable of establishing a communication link to the central processing center 12 via the Internet, a local area network (LAN), or a wide area network (WAN). Thus, the user can even have access to the system 10 via direct modem dial-in to the central processing center 12 over the public switched telephone network (PSTN) or Internet.
  • With reference now to FIG. 4, illustrated is an embodiment of a [0124] business unit server 18 which includes a proxy agent 110 in accordance with the present invention. The proxy agent 110 may perform numerous functions including decoding and encoding encrypted messages sent and received over networks 16. The proxy agent 110 manages traffic to and from the trader workstations 20, and may provide other features such as document caching and network access control. The proxy agent 110 may improve performance by storing and supplying frequently requested data to the trader workstations 20, or by filtering and/or discarding information from the networks 16. Preferably, proxy agent 110 resides on a business unit server 18 which is part of the respective client sites 14 internal data networks. However, the system 10 of the present invention may be implemented without business unit servers 18, whereby the functionality of the proxy agent 110 may be incorporated into the trader module 70 of the respective trader workstation 20; such functionality including decoding and encoding encrypted messages, and network management.
  • The [0125] business unit server 18 includes a processor 112 that communicates with the other elements within the business unit server 18 via a system interface 114. An input device 116, for example, a keyboard or pointing device, is used to input data from a user, and a screen display device 118, for example, a monitor, is used to output data to the user. A memory 120 within the business unit server 18 includes the proxy agent 110 and a conventional operating systems 122 which communicates with the proxy agent 110 and enables execution of the proxy agent 110 by processor 112. An external communication link 124 is provided to interface the business unit server 18 with other computer systems or computer/based machines such as networks 16 and trader workstations 20. Lastly, a hard disk 126 may be provided as a persistence memory device, as is well known in the industry. Particularly, the hard disk 126 may include trader data profiles 128 for each of the different trader workstations 20 associated with the business unit server 18. Alternatively, the trader data may be stored at the central processing center 12 so that the trader does not need to re-build his/her screens each time he/she longs onto the system 10.
  • Thus, each [0126] trader workstations 20 at a client site 14 is able to access the system through the Internet browser program 72 operating on the user's desktop computer. In order to access the system 10, the user may run Java-based applets on the desktop computer in the Internet browser program 72 which may be up-loaded to the desktop computer system by one of three means: 1) accessing them from the hard disk of the desktop computer 2) downloading them across the network from a server on the internal data network of the client site, or 3) by downloading them directly from the central processing center. Once the applets are loaded and running in the desktop computer of the user, the user is then able to access the system 10 and interact with other trader workstations 20 and engage in trading activities. In addition to traders at the client sites, a preferred embodiment of the present invention also enables non-trader users at the client sites 14, such as credit officers and other interested/relevant staff, to have access to the invention in the same manner as the users in order to monitor the trading activities, perform credit control or any other functions.
  • III. System Features [0127]
  • The following are features of the present invention which provide particular functionalities and utilities. These features include interfaces such as a command center interface, a market entry interface, a market details interface, an outstanding order interface, an historical order interface, and functions such as symbology, credit preference checking, term negotiation, automatic notification, interest rate reset risk switches, and order auction. [0128]
  • When beginning a session on the [0129] system 10, a user at a trader workstation 20 launches the Internet browser program 72 and goes to a particular address that connects the trader workstation 20 to the central processing center 12. This is preferably achieved by typing a known URL (Universal Resource Locator) in an address field of the Internet browser program 72. At the URL entered, the user will be presented with a log-on screen which preferably requires the user to input a user name and password for identification, verification and security reasons. After the user logs on, the user will download (preferably from proxy agent 110) the Java applets which will run locally on the desktop computer comprising the trader workstation 20. Alternatively, the user may launch a local or network application that runs locally or on an attached server. The application will enable a connection to system 10 over network 16, much the same as numerous dial-up services such as AOL. In addition, other information such as user defined preferences which are based on the trader's profile will be downloaded to the trader workstation 20. This may include information on what the user is allowed to trade, what markets the user is interested in monitoring, and other user specific information that was previously been defined by the user or another individual such a credit officer or the like.
  • After the user has successfully logged on and the requisite Java applets have been downloaded and are running on the [0130] JVM 73, the user is presented with a command center interface 130, as illustrated in FIG. 5, via the screen display device 88 (FIG. 3). The command center interface 130 is the front end of the user interface which provides access to all other features of the present invention, as described below. In an embodiment of the command center interface 130, the command center interface 130 is a pop-up window rendered on the screen display device 88. Note, however, when the command center interface is running, the user may be able to iconize (i.e., minimize) the Internet browser program 72 window, as may be desirable when the user no longer needs to view the Internet browser program 72.
  • From the [0131] command center interface 130, a user can access the features of the system 10 which enable the user to monitor and control their trading in the system 10. Specifically, from the command center interface 130 the user can access the following areas of functionality as menu options on the tool bar 132: a market entry interface (described below with reference to FIG. 12), a credit settings interface (described below with reference to FIG. 10), a switch engine interface (described below with reference to FIG. 22), auction interface (See FIG. 13), tools, a user preference interface (described below with reference to FIGS. 6A and 6B), an historical order blotter interface (described below with reference to FIG. 17), an outstanding order blotter interface (described below with reference to FIG. 16), links to external applications such as MarketSheet™ (a trademark of TIBCO, Inc.) (referred to herein as the quote screen and graph screen for illustrative purposes), a logout interface (provides secure exit from the system 10), and a help interface where detailed on-line help is provided. The menu options that appear in the tool bar 132 are preferably customizable to a user, and those described are merely illustrative.
  • In addition, the [0132] command center interface 130 provides a message display window 134 for displaying real-time messages. These messages include system information, market information, requests-for-prices (RFPs), requests-for-switch (RFS) or online chat sessions with the users of the system 10. Below the message display window 134, the command center interface 130 displays the user's name 136, the user's default currency 138, the user's business unit 140, and other relevant information. The background color of the message display window preferably changes if the connection to the central processing center 12 is lost for any reason.
  • A [0133] user preferences interface 148, which is accessible from the command center interface 130 via the tool bar 132, provides a user with user preference features, such as those illustrated in FIGS. 6A and 6B. In FIG. 6A, a Derv Filters tab enables a user to set request-for-price (RFP) filters for viewing different derivative instruments based on the type (i.e., class) of derivative instruments and the currency. The user may also select the manner of presentation (ie., highlighted or not). Prom the Derv Filters tab, the user is able to add and remove the derivative instruments from the user's viewing list, that is, the list of instrument that will appear on the message display window 134 of the command center interface 130. In FIG. 6B, an Environment tab enables a user to select viewing options to change the appearance of the display. In regard to the color coding display option, it is noted that the user can select not to have order information color coded by selecting color blind user. In such a case, other means of notation are utilized such as markings or symbols, as may be desirable if the user is color blind or using a monochrome screen display device 88. User defaults for Credit Group, Instrument Class and SWF Currency may also be selected via the environment tab.
  • At this point, it is worth noting several functionalities that are integral to the operation of the present invention. In particular, it was recognized that in order to achieve an electronic trading system for a wide range of financial contracts, a solution had to be developed to solve two very critical problems: (1) how to identify financial contracts, and (2) how to allow institutions to describe their credit preferences or relationships for these instruments. As solutions to these problems, the present invention provides the symbology and credit preference features described below. [0134]
  • The symbology of the present invention was developed because, unlike foreign currency trading, where the financial instruments are simple, verbally explaining all the terms and conditions of a derivative transactions can be a laboriously complex process which can take a relatively long period of time to explain. Furthermore, most derivative transactions are specifically customized to fit a particular need. With derivatives, as compared to stocks, bonds or other financial instruments, there are typically many more parameters, such as the maturity, fixed interest rate, floating interest rate, currency, floating rate index, and calculation rates, which are important and are preferably defined. This complexity has allegedly been one of major inhibitors to the development and implementation of an efficient inter-dealer electronic trading system for over-the-counter (OTC) derivatives. [0135]
  • The symbology will, among other things, ensure that the symbols are intuitive to the trading community, allow new symbols to be system generated when new instruments are introduced, and enable detailed confirmations to be prepared. These goals are generally accomplished by systematically dividing the parameters, terms, and conditions defining these derivatives instruments into a four-part subject code. This four-part subject code enables the users to reference these instruments via a form known as subject-based addressing. The four-part subject code is divided as follows: SOURCE.CLASS.SYMBOL.CURRENCY. Each field of the four-part subject code is defined below. [0136]
  • The source field of the symbology identifies the source of the information. In most cases, this will be the code DNI (i.e., Derivatives Net, Inc.), the assignee of the present invention. If the symbol is used within the [0137] system 10, then the source field of the symbology will be assumed to be DNI, and will be omitted. If the symbol is used in a larger context, then the source will be identified. If, for example trade data were to be distributed and accessed via a third-party data distribution system such as the type operated by Reuters, Inc., then the source field of the subject code would be used.
  • The class field identifies the principal product class into which the financial instrument falls. The class parameter is designed to group financial contracts together which share similar attributes. For purposes of the present disclosure, eleven classes of instruments, each with distinct characteristics covering forward rate agreements, interest rate swaps, interest rate basis swaps, interest rate options, foreign exchange and switches, will be covered. It is noted that a switch is the simultaneous purchase and sale of two instruments within the same class. The following is a listing of the eleven classes and the associated abbreviation for each: [0138]
  • FRA—forward rate agreement [0139]
  • SWP—interest rate swap [0140]
  • CAP—interest rate option (cap or floor) [0141]
  • SOP—interest rate option (swaption) [0142]
  • IBS—interest rate basis swap (floating vs. floating swap) [0143]
  • SPT—foreign exchange spot [0144]
  • FWD—foreign exchange outright forward [0145]
  • FXS—foreign exchange swap [0146]
  • SWF—FRA switch [0147]
  • SWT—switch any other pair of instruments in the same class [0148]
  • CBS—currency basis swap [0149]
  • The symbol field is the principal code used to define each instrument. The symbol field is the most explicit field of the subject code. This component of the naming convention enables the underlying structure of the derivative instrument to be defined. A simple description (e.g., 1yrswap) could be used, but this does not allow new derivative instruments to be easily added. The legend below defines the parameters for defining each of the different instruments or classes. The symbol relies on the definitions of the underlying parameters, which will allow further break down or definition. For example, FLOPT is a two letter code which describes the variable rate index to be used, and will include: the designated maturity, index name, source, non-business day convention and calculation description. The symbols of the present embodiment are as follows: [0150]
  • FRA: [START, END, OVER, FLOPT][0151]
  • SWP: [START, END, OVER, FXDBASIS, FLOPT, SPECIAL RULE][0152]
  • CAP: [START, END, OVER, FLOPT, TYPE, STRIKE ][0153]
  • SOP: [START, OVER, UNDERLYING SWAP, SOPTYPE, STRIKE, OPTYPE][0154]
  • IBS: [START, END, OVER, INDEX[0155] 1, INDEX2, ARREAR]
  • SPT: [CCY[0156] 1(terms), CCY2 (base)]
  • FWD: [CCY[0157] 1(terms), CCY2 (base), START, END, OVER]
  • FXS: [CCY[0158] 1(terms), CCY2 (base), START, END, OVER]
  • SWF: [FLOPT, DAY[0159] 1, DAY2]
  • SWT: [ASSET[0160] 1, ASSET 2, CLASS]
  • CBS: [START, END, OVER, INDEX[0161] 1/CCY1, INDEX2/CCY2]
  • The symbol fields set forth above include the following parameters: [0162]
  • START: The START parameter is the month the contract commences offset from value date, i.e., 1,2,3, . . . ,13, . . . ,360. The default setting for the START is (0) which represents that a contract starting with the current month. Also, see OVER below. [0163]
  • END: The END parameter is the final maturity from value date in months adjusted for the OVER, and represents the term, i.e., 1,2,3, . . . ,13, . . . ,360. If the value date is 28th of November, then a contract defied as [1,4 over the 12th] translates into a deal starting on the 12th of January and maturing on 12th of April. [0164]
  • OVER: The OVER parameter represents a specific date in the appropriate month. For example, if today is the 3rd December (value date is the 5th of December), then a 1*4 over the 12th would start the 12th of January, the first date over one month but less than two months beyond the spot date. This allows a contract to be defined with any start date between days 1-31. Note that this represents the actual date and not the number of days forward. The default setting for the OVER is (0), which represents spot starting. Two other parameters are allowable: (I) which represents IMM (International Monetary Exchange) rolls (the [0165] system 10 covers the different IMM conventions defined by the currency market, that is, the third Wednesday or second Thursday) and (E) which represents rolls over the month-end.
  • FXD BASIS: The FXD BASIS parameter is a two-part code covering the frequency and the basis of the fixed coupons. Examples are FREQ: M=Monthly, Q=Quarterly, S=Semi-annually, A=Annually, Z=Zero Coupon plus BASIS F=A/365 Fixed, B=30/360, M=A/360, I=A/365 ISDA, etc. For instance, SM is semi-annual A/360 or semi-money]. [0166]
  • FLOPT: The FLOPT parameter is a two-part code covering the frequency and the index type of the floating coupons, and represents the floating rate option as defined by ISDA. The FLOPT parameter covers frequency, basis and source. Although each currency may have a default, most indices will be available. FLOPT examples are L=Libor (TELERATE 3740/50), P=Pibor (TELERATE 20071), T=Tibor, C=CDOR, B=AUS Bills (REUTERS BBSW), FF=Fed Funds (HI5), TB=T-bills (H15), PR=Prime (H15), CP=30 day Commercial Paper, BE=BELO, S=STIBOR, TA=TAM, A=AIBOR, D=CIBOR (REUTERS DKNK), RL=Libor from Reuters LIBO, and IL=Libor from Reuters ISDA. [0167]
  • CAPTYPE: The CAPTYPE parameter includes definitions for cap (C) and the floor (F). Thus, in a preferred embodiment, the following code is utilized: C=Cap, F=Floor. [0168]
  • SOPTYPE. The SOPTYPE parameter includes definitions for payers (P) and receivers (R). Thus, in a preferred embodiment, the following code is utilized: P=Payers, R=Receivers, X=Call, Y=Put. [0169]
  • OPTYPE: The OPTYPE parameter is the option type: (E)uropean, (A)merican or (M)ultiple European. [0170]
  • STRIKE: The STRIKE parameter indicates the cap or swaption's exercise rate or price set on the option. Any strike defined in the symbol as ATM (at-the-money) will be shown as such in this parameter. In such a case, the percentage or strike will be agreed through the term negotiated process discussed below. [0171]
  • SPECIAL RULE: The SPECIAL RULE parameter is designed for currencies such as USD and CAD which are in particular markets that use few special conventions for trading. For example, semi-bond for spread trades and annual money for out-right swaps are widely used in these markets. The SPECIAL RULE parameter allows the [0172] system 10 to set more than one set of defaults for any currency. This will allow the system 10 to know when the exchange of bonds is required following a transaction. The follow are the rules for the present embodiment:
  • A—Default in all currencies [0173]
  • S—USD spread trades. The default in USD is annual money versus 3 month LIBOR. This rule defines semi-bond spread trades where bonds are exchanged in the terms negotiation function described below. [0174]
  • 2 —CAD spread trades. The default in CAD is annual money (A/365 fixed) versus 3 month CDOR paid semi-annually. This rule defines semi-annual A/365 fixed versus 3 month CDOR paid semi-annually where bonds are exchanged in the terms negotiation function described below. [0175]
  • 3 —AUD long trades. The default for AUD is a quarterly/quarterly structure. This applies for trades up to and including three years. In trades over three years, the convention switches to a semi/semi structure. This rule supports a semi/semi structure. [0176]
  • 4 —AUD spread trades. Its is conventional to trade swaps in the AUD market against the bond futures contracts with an agreement for an exchange for physical. [0177]
  • 5 —GBP spread trades. The default in GBP is annual money (A/365 fixed) versus 6 month LIBOR. This rule defines semi-annual A/365 fixed versus 6 month LIBOR where bonds are exchanged in the terms negotiation function described below. [0178]
  • ARREAR: The ARREAR parameter defines when the coupon(s) on a swap is both set and paid. Most interest rate swaps set their floating rate coupons at the beginning of the period and pay them at the end of a coupon period. In an ARREAR swap, however, the coupon is set and paid at the end of the period. This is commonly referred to as an arrears swap. The [0179] system 10 allows for this in the form of a basis swap.
  • DAY[0180] 1/2: The DAY1/2 parameter is the number of calendar days offset from today to the start of each FRA in an FRA switch (class SWF). Thus, the DAY1/2 parameter represents the setting day or date.
  • CCY[0181] 1/2: The CCY1/2 parameter is the currency code and is defined by the ISO codes for foreign exchange instruments.
  • UNDERLYING SWAP: The UNDERLYING SWAP parameter is the full symbol, alais or security ID of the interest rate swap that underlies an option. [0182]
  • INDEX[0183] 1/2: Basis Swaps are when both sides are a floating rate, and the index represents the FLOPT plus the currency code of each index. The first listed index (INDEX1) is paid by the buyer. Examples include 1L-USD, 3L-GBP, PR-USD, etc. The second index (INDEX2) is received by the buyer. These are substantially identical to the codes used in the switch mechanism 35 (FIG. 2). For currency basis swaps, it is assumed that an exchange of principals takes place at the start and end on the contract.
  • ASSET[0184] 1/2: The class SWT is provided to allow for the trading of switches in other classes other than FRAs. ASSET1 and ASSET2 represent the symbol, alias or security I.D. of each underlying contract. Note that both should be provided from the same class of contracts.
  • SETTLE: The SETTLE parameter is a flag indicating whether a swaption is cash or physical settlement. The default is cash (C). [0185]
  • An example of an order in accordance with the symbology of the present invention is DNI.FRA.1,4.0,3L.USD, where DNI is the source, FRA is the class, .1,4.0,3L is the symbol and USD is the currency. In particular, the symbol field defines a 1 by 4 (i.e., 3 month starting in 1 month) FRA on a 3 month LIBOR spot starting. Note that a comma (,) is used in the symbol fields as a delimiter. Another example of an order in accordance with the symbology of the present invention is DNI.SWP.0,60,0,AB,6LA.DEM, where DNI is the source, SWP is the class, 0,60,0,AB,6LA is the symbol and DEM is the currency. In particular, the symbol field defines a five year (60 month) annual bond (AB) versus a 6 month LIBOR swap. [0186]
  • Accordingly, the Symbology described above is designed to capture the parameters or commercial terms of a derivatives instrument which affect the instrument's valuation. The present invention provides a number of default values which are assumed at all times. For example, the following is an exemplary list of system default values. [0187]
  • ROUNDING: The rates observed on the source page or document will be used unless otherwise agreed. Rates should be rounded to 5 decimal places after any operation of averaging. [0188]
  • RESET DATES: This will be defined with reference to payment dates. The reset dates should be offset by the standard number of days for the currency, for example, two business days for USD. [0189]
  • BUSINESS CENTERS TO APPLY TO RESET DAYS: The business days used to define the current offset for reset dates is defined by the source and not the payments under the transaction. For example, London will always be used for LIBOR (the exception is for USD LIBOR which uses both London and New York City) and New York City for H.15 rates. [0190]
  • INTERPOLATION: Where interpolation is required, a straight-line method using the reference rates on either side of the desired date should be used. [0191]
  • CALCULATION PERIODS: First and not last convention. Therefore, the calculation period includes the first payment date but excludes the next payment date. [0192]
  • TERMINATION DATE: All termination dates will be subject to adjustment if they fall on a non-business day. [0193]
  • ADJUST CALCULATION PERIOD: The number of days is assumed to adjust if the payment days are adjusted for non-business days. [0194]
  • TRADE DAY: The trade day is defined relative to the instrument and currency by the [0195] system 10, and not by the location of either of the parties to tile transaction.
  • NET PAYMENTS: Net payments will be assumed for all transactions completed through the [0196] system 10.
  • CANADIAN DOLLAR SWAPS: The convention is to set quarterly and pay semi-annually using weighted averaging and compounding at the first rate. [0197]
  • DATES: All dates are listed unadjusted for non-business days. [0198]
  • Users may also want to be able to negotiate other parameters which do not affect the valuation of the derivative instrument, but are still very important. These parameters are referred to hereinafter as non commercial terms. The difference between commercial and non-commercial terms can be vary ambiguous, and therefore, some of the terms designated as commercial below may be designated as non-commercial and become default settings so as to be part of the symbology parameter. For purposes of illustrating the present invention, non-commercial terms have been given default values which the users can change by negotiating new values for these terms between themselves via the [0199] system 10. However, both counterparties (users) must agree on the new value to over-ride the system defaults. Table 1 below provides a list of parameters that maybe negotiated, that is, the non-commercial terms:
    TABLE 1
    PARAMETER DESCRIPTION SETTING
    Legal The format of the legal agreement used ISDA, BBA,
    FX
    Month-end Whether coupon payment dates roll on YES, NO
    month-end dates or not
    Settle For swaptions whether the contract is CASH,
    cash or physically settled PHYSICAL
    First Setting For swaps the first variable rate is SETTING
    normally known for spot starting displayed on
    instruments. The current setting can market entry
    quickly become off market on days interface.
    where the market moves substantially.
    The system will display the default at
    all time.
    ATM For options, symbols will be set up The system
    where the strike is defined as at-the- forward rate
    money (note: pre-defined strikes will will be
    also be available). The actual strike will available
    be negotiated immediately following the
    transaction by the two parties.
    Spot For foreign exchange swaps (class FXS The system
    only) where the price is transacted in mid spot price
    the form of points, the spot level to be will be
    used will be negotiated immediately available
    following a transaction.
    Base Switches will be transacted in the form The system
    of the relative price between the two mid price
    instruments being switched. The base will be
    rate maybe negotiated immediately available
    following a transaction.
    Bond Exchange For USD, CAD and GBP interest rate The system
    swaps transacted as a spread, the price will list the
    and number of bonds will be negotiated benchmark
    immediately following the transaction bonds to be
    used and will
    calculate a
    default price
    and number
    according to
    market
    convention.
  • Because the above symbols that comprise the subject-based addressing may be complex, users may occasionally desire a simpler naming convention to reference the more commonly traded derivative instruments. To facilitate more rapid referencing of an instrument by a user, the symbology of the present invention provides aliases. An alias is merely an abbreviated version of the subject-based address for the more commonly used terms for an instrument. The database [0200] 66 (FIG. 2) maintains a unique security identifier (such as a numeric code, e.g., 111222) for each symbol which can be used in the system 10. Thus, the symbology of the present invention enable traders and other users of the system 10 to quickly reference a particular derivative instrument in the system 10 in three ways: the full symbol, the alias, and the identifier.
  • The currency field of the symbology contains the code that defines the currency of the instrument represented. In a preferred embodiment, the currency code is represented by the standard ISO currency codes, i.e., USD, DEM, JPY, GBP, FRF, NLG, BEF, AUD, CAD, ITL, ESP, DKK, SEK, EUR, etc. The default currency will be set by each user in each user's preferences interface [0201] 143 (see FIG. 6B). This will allow the currency code field of the symbology to be omitted much of the time. However, foreign exchange trades (FXS) preferably include the currency code. Further, the currency code represents the currency which will be indexed in equal amounts for both the spot and forward coupons.
  • The credit preference feature of the present invention provides for the bilateral credit status between two entities to be captured, structured and used anonymously for the trading of a wide range of financial contracts. In prior art systems, credit information was primarily used to deal with settlement risk in trading spot foreign currency. In such prior art systems, the credit line or limit is usually expressed in amounts of currency which equates with the quantity or volume of a particular trade. As trades are executed between counterparties, the amount of the limit is decreased in a corresponding amount to the trade executed until there is little or no remaining credit, and then further trading is prevented until the trades settle or the credit limit amount is re-set. In foreign currency trading, the settlement process is completed in only a few days, after which both counterparties have exchanged the currencies, and then there is no further credit risk between them (i.e., the trades have settled). This is vastly different from derivatives trading, where the amount at risk is normally not equal to the principal or quantity of the transaction and the obligations under the contract may continue into the future. Derivative trades can be anything from spot (the normal settlement of a foreign exchange contract) to thirty years into the future. Therefore, the resulting credit exposure (i.e., the value of a contract at a future time) is over the life of a contract of an unknown amount. [0202]
  • The credit preference feature of the present invention is configured to handle the significant long-term credit problems inherent in over-the-counter (OTC) derivatives transactions. These long-term credit problems are further compounded by the fact that there is no standard method for banks to internally monitor and manage their credit risks. Most banks have developed their own, often proprietary, methods of monitoring and measuring the credit risk embedded in large portfolios of derivatives. Furthermore, banks also have different methods for dealing with the many different financial instruments that exist in every market. [0203]
  • The credit preference feature of the present invention addresses these problems and provides a viable solution. The credit preference feature of the present invention achieves this, at least in part, by introducing a measurement unit of credit risk referred to as risk equivalent (RQ) which allows for different instruments to be compared on a like basis using a standardized measuring methodology, which together with the concepts of contract maturity, credit groups, classes, credit preferences, legal entities and business units allow the [0204] system 10 to offer a solution to the credit risks embedded in bilateral, term derivatives contracts. The present invention also provides for the designation of credit groups. A credit group is a grouping of classes of financial contracts that a business unit wishes to be treated in a like manner for credit purposes. In a preferred embodiment, three default credit groups will be available: (1) Derivatives—SWP, IBS, CAP, SOP, FRA, CBS; (2) Switches—SWT, SWF; and (3) foreign exchange. Any other combination may be set up by the business unit, as desired.
  • Credit preferences are the methods or rules selected by a business unit within a credit group for the [0205] system 10 to use to screen prices (bids or offers) and trades against all other legal entities. In a preferred embodiment, the following three credit preferences are provided, though it will be appreciated by those of ordinary skill in the art that other credit preferences may be utilized in accordance with the present invention:
  • Method 1: Binary (simple yes/no)—This is used where mark-to-market (MTM) agreements exist between the counterparties. MTM are bilateral, collateral agreements which are common and reduce the credit risk between two parties to almost zero by the posting of collateral against the value of a portfolio of derivatives covered by a single ISDA (International Swap and Derivatives Association) master agreement. [0206]
  • Method 2: Line Binary—takes into account the maturity (quoted in months from trade date) of the financial contract. [0207]
  • Method 3: Complex—This is based on the RQ of each contract within maturity bands. The system calculates a RQ for each instrument in the form of a constant currency unit expressed as a percentage. Each business unit has the choice of using the system generated RQ unit or to provide their own. [0208]
  • In the binary method, a business unit makes a yes or no determination as to whether or not they will deal with a particular counterparty for a particular credit group. In this credit preference, the decision is binary; there is no maximum maturity limit (i.e., time limit) or quantity limit (i.e., amount) in the binary method. The binary method is the broadest of the three credit preference definitions provided for herein. Typically, the binary method win be used to refuse credit, where MTM agreements exist or where the credit exposure is small (for example, in switches). [0209]
  • In the line binary method, it is assumed that the business unit will deal with a particular counterparty for a particular credit group. However, the line binary method adds a further restriction of a maximum maturity of any contract tradable. The added restriction is preferably expressed by the number of months into the future. The binary method is particularly well suited for used by institutions that are not yet using RQ units, but which desire a method to limit potential exposure to longer dated contracts (for example, a temporary step). [0210]
  • The complex method allows each business unit to exactly stipulate the amount of new risk that they are prepared to enter into with any other legal entity for each credit group by maturity band. The complex method enables a business unit to specify not only a particular maturity, but also a particular quantity or amount based on a measure of RQ. Further, the complex method enables the business unit to specify this for more than one period in time. For example, a business unit can specify that for Bank A, they will do up to $100 million out for 5 years, and then only $50 million from thereafter out to 10 years, and nothing thereafter. [0211]
  • Risk is generally defined herein as the degree of uncertainty of future net returns. Credit risk is further defined as an estimate of the potential loss due to the inability of a counterparty to meet its obligations. Thus, while the risk in a particular transaction depends not only on the changes in market rates and credit standing of the counterparty to the transaction, the credit risk or exposure is the nominal amount that can be lost when a counterparty defaults on its obligation. As previously mentioned, the credit risk in a derivatives transaction is relatively complex. For instance, though derivative contracts come in many forms, the majority have a fair credit value of zero at the time the transaction is initially entered into. That is, no funds are transferred between the parties at the time the contract is created. Rather, the contract places an obligation on both over the term of the contract. Further, both parties are entering into a contract which requires them to accept a certain amount of risk. The RQ is a unit of credit risk which allows all contracts to be compared on a like basis, at virtually any point in time. The RQ is the credit exposure in terms of a percentage of the principal. [0212]
  • The calculation of RQ is based on the potential exposure averaged over a series of time points, weighed by an appropriate discount factor. There are several methods of calculating the exposure of a transaction, though the RQ is calculated herein using an option pricing approach, as described below. [0213]
  • For a certain party, a transaction can be viewed as two opposite cash flows. Inflows are assets, denoted by A(t), and outflows are liabilities, denoted by L(t). Therefore, the current exposure may be expressed as follows:[0214]
  • E(t)=max(A(t)−L(t),0)
  • This formula is similar to the intrinsic value of a call option. The key difference is that both A(t) and L(t) can be random. Thus, following the same structure by the Black-Scholes, then:[0215]
  • EE(t)=Aφ(d 1)−L(t)φ(d 2),
  • where
  • d 2 =d 1−σ(t){square root}{square root over (σ(t))} d 1 = log ( A ( t ) L ( t ) ) + σ 2 ( t ) 2 τ ( t ) σ ( t ) τ ( t )
    Figure US20030093360A1-20030515-M00001
  • where σ(t) is the daily volatility (in percent) that takes into account that both A(t) and L(t) are random. The maximum exposure estimate is based on the following equation: [0216] ME ( t ) = A ( t ) - L ( t ) + A ( t ) [ e 1.65 σ ( t ) τ ( t ) σ 2 ( t ) 2 τ ( t ) - 1 ]
    Figure US20030093360A1-20030515-M00002
  • Thus, the RQ can be expressed as: [0217] RQ = AEE ( t ) Principal * 100 % where AEE ( t ) = t = 0 N ω ( t ) E [ E ( t ) ] where ω ( t ) = δ ( t ) 0 N δ ( t )
    Figure US20030093360A1-20030515-M00003
  • where δ(t) is the discount factor at future time t. [0218]
  • For FRA's, the following equations apply:[0219]
  • A(t)=*discountFactor(t,s)*x+(1+floatingCoupon)*discountfactor(t,e)
  • where
  • floatCoupon=1*(e−s)/floatBasis*floatRate, and
  • L(t)=1*discountFactor(t,s)*x+(1+fixCoupon)*discountfactor(t,e)
  • where
  • fixCoupon=1*(e−s)/fixBasis*fixRate,
  • for t<s, x=1, and [0220]
  • for t>=s, x=0. [0221]
  • Then we can apply the above formula for RQ to get the expected exposure at time t. By choosing the time partition t[0222] 0,t1,t2 . . . , tn and calculate the expected exposure at each point and use the formulae of RQ, the RQ of this FRA can be calculated.
  • For SWAP's, the following equations apply for any time (t[0223] i<t<=ti+1): A ( t ) = j = i n floatingCoupon ( t j ) * discountFactor ( t , t j ) + 1 * discountFactor ( t , t n ) , and L ( t ) = j = i n fixedCoupon ( t j ) * discountFactor ( t , t j ) + 1 * discountFactor ( t , t n ) ,
    Figure US20030093360A1-20030515-M00004
  • where floatingCoupon(t[0224] j) is the floating coupon at time tj, and fixedCoupon(tj) is the fixed coupon at time tj. Then apply the formulae of option pricing approach, we can get the expected exposure at time t, by averaging the expected exposure with the discount factor, the RQ can be calculated.
  • At this point it may be worthwhile to distinguish the credit preference feature of the present invention from other known systems. The credit preference of the present invention does much more than merely monitor the amount transacted between two counterparties and then reduce the amount available accordingly. The prescreening performed by the credit preference of the present invention is used to prescreen possible trades based on each counterparty's credit preferences. The present invention does not control a user trading and does not directly limit the user's future trading based upon the user's past trading. In fact, it is quite possible that a new transaction may reduce the exposure between two legal entities. A user's business unit is responsible for monitoring the credit exposure of the business unit with respect to all legal entity counterparties, and for adjusting the credit preferences in the [0225] system 10 accordingly. This is a significant difference from prior art systems that automatically decrease the amount available to trade with respective counterparty as transactions are executed. The credit preference of the present invention represents an improvement over such systems because the balance of risk is based on the total portfolio between the two parties and not merely the new transactions, and the balance of risk will be affected by market movements, deals executed outside the system 10, and internal changes to the ratings.
  • Credit decisions for OTC derivatives are considered different from many other financial instruments. In general, a credit decision for an OTC derivative is a function of, among other things, the composition of the user's current derivatives portfolio, the current level or prices of the financial markets, new financial transactions, and the rating or level of credit worthiness of each legal entity. Therefore, more sophisticated means such as the credit preference prescreening of the present invention is needed to adequately measure and manage credit exposure in the OTC derivatives market, as well as with other financial markets. [0226]
  • The present invention enables the user to set desired credit preferences for each legal entity via the [0227] credit preference interface 170, as illustrated in FIG. 7. A user can navigate to the credit preference interface 170 by selecting the credit settings button in the tool bar 132 of the command center interface 130 (FIG. 5). The credit preference interface 170 enables the users to view and/or update credit preference settings in a clear, simple, comprehensive and intuitive manner. The credit preference interface 170 may be used to view or input/amend the business unit's credit preferences. The credit preference settings are preferably only viewable by users within a business unit, and amendable by users with the correct permissions, both of which may be designated by the financial institution or the business unit. A business unit may also select to inherit credit preferences from another business unit within its family hierarchy.
  • In a preferred embodiment, the [0228] credit preference interface 170 includes a display window 172 that displays various information including an alphabetical listing of all other legal entities (i.e., financial institutions) that have access to the system 10. Each legal entity can be expanded via an expand button 174 to list the settings for all the credit groups that the user has selected to trade within that legal entity, as shown for the Merrill Lynch entry. For those legal entities that are not expanded in window 172, the settings displayed are for a designated default credit group 176. The user can modify the displayed credit groups by selecting the Modify Credit Groups button 178 which launches the modify credit group interface 180, as illustrated in FIGS. 8A and 8B. The modify credit group interface 180 enables the user to customize his/her class groups by providing functionality to perform such operations as adding and removing instruments from a class group, as illustrated in FIG. 8A. For instance, for a selected credit group 182, a list183 of instruments in that credit group is provided. Unassigned instruments can be added and member instruments can be removed. Further, credit groups 182 can be added and deleted via buttons 182, 185, respectively. In FIG. 8B, each credit group 182 may have bands of maturity 186 defined (i.e., added or deleted). Each class group preferably includes instruments that are closely related because the instruments in each class group are given the same credit preference setting, and therefore, the credit preference setting process may be simplified.
  • Referring back to the [0229] credit preference interface 170 of FIG. 7, a preference setting column 187 provides the credit preference setting designated for the corresponding legal entity 183. The credit preference settings for any legal entity can be modified or selected via a drop-down dialog box 188. From the drop-down dialog box 188, the user can select from a list of predefined credit preference option. For a new line binary, the user is prompted with a new line binary interface 189 in which the user can enter a maturity. For complex, the user is prompted with a complex preference interface 190 (FIG. 9B) in which the user can enter the exposure for each maturity band.
  • With reference back to FIG. 7, the complex credit preference settings and the RQ may be provided for each instruments designated as such by selecting an appropriate legal entity and then selecting the [0230] Complex Bands button 194.
  • If the user does not set a particular preference for a particular counterparty, then the credit preference will be assumed to be a simple binary (no). If after initially setting these preferences a new counterparty is added to the system, the preference for the new counterparty will be binary (no) for all users until they have specifically set a credit preference for the new counterparty. [0231]
  • The [0232] level column 196 displays the business unit's designation for each legal entity as to the levels A, B or C. The level set for each legal entity may be provided by the system 10 via various interfaces such as a market detail interface (described below with reference to FIG. 15) to provide the trader with information with regard to the creditworthiness of the counterparty. Thus, a business unit may assign one of the levels A, B or C against each legal entity. This is essentially a quick reference of credit worthiness for the user.
  • The [0233] columns 198 labeled S&P and Moody are industry credit ratings that are integrated into the credit preference interface 170. The industry credit ratings may be downloaded on a subscription basis via external communication interface link interface 62 (FIG. 2). Lastly, the last modified column and the modified by column identify the time and person that last modified that credit setting. As mentioned before, access to modify any of the credit preferences should be limited to a finance officer or credit officer of the legal entity.
  • It should be noted that the credit preference settings may be transferred via electron file transfer or inputted manually on-line at anytime, and as often as the user desires. Further, updates may be made for all credit groups and legal entities, or alternatively, updates can be just for individual settings. [0234]
  • In addition, the credit preferences interface [0235] 172 includes a BU Info button 202 which, if selected, brings up a business unit data interface 204, as illustrated in FIG. 10. The business unit data interface 204 enables the users to view helpful internal information about other legal entities. The respective business units define what information is included in the business unit data interface. For example, the business unit data interface 204 of FIG. 10 provides the internal facility number, telephone number, internal reference number, internal net MTM, internal gross MTM, and internal number deals of a business unit. Alternatively, a business unit may include a contact name or other business unit specific data.
  • Accordingly, the credit preference logic of the present invention can be illustrated graphically as shown in FIG. 11. For purposes of FIG. 11, it is assumed that business unit (i) belongs to legal entity (i) where i=1, 2, and 3, and business unit (j) belongs to LE (j) where j=1, 2, and 3. Accordingly, FIG. 11 illustrates a portion of the credit data which is stored by the [0236] system 10 in order to implement the credit preference feature of the present invention. Each column represents the credit preference (i.e., binary, line binary, or complex) which is stored anonymously for each business unit against each legal entity across all credit groups. The vertical and horizontal bars 210 represent the information which business unit (3) requires to determine the credit preference status of an order. The information in columns 210 provides the credit preferences which business unit (3) has set against all other legal entity, and row 211 provides the credit preferences which all other business unit s have set against business unit (3)'s legal entity, that is, legal entity (3). The depth 216 of the graph is divided into the different credit groups such as switch, derivative, and foreign exchange.
  • The [0237] triangles 212, 214 mark the cells that include the information which is used by business unit (3) to encode a specific order from business unit (5) of legal entity (5) with credit status information for presentation to the user via one or more of the interfaces described herein. In a preferred embodiment, the credit preference feature of the present invention color codes the credit preference status of each order from the perspective of the viewing business unit. Alternatively, another method of encoding the credit preference status of an order may include adding a character notation such as an asterisk or star to an order, as may be desired if the user is color blind.
  • Each order is color coded according to the credit preferences marked by the [0238] triangle 212, which corresponds to what the order placer's business unit has set against business unit (3)'s legal entity, and the triangle 214, which corresponds to what business unit (3) has set against the order placer's legal entity. The order is evaluated according to the credit preference defined in the cells marked by the triangles 212, 214, and the results can be displayed to the user via the color coding scheme set forth below where true means that the order passes the credit preference of the setting party and false means that the order does not pass the credit preference of the setting party:
    Triangle 212 Triangle 214 Color
    False False RED
    False True YELLOW
    True False RED
    True True GREEN
  • Thus, each order is color coded to communicate to the user the tradability of the bids and offers in the market based on the preferences of both users. The color coding methodology described herein is used in both the market entry interface (described below with reference to FIG. 12) and the market detail interface (described below with reference to FIG. 15). For the present embodiment of the invention, the following meanings are associated with the cited colors: [0239]
  • GREEN: The price passes the credit preferences of both parties, and the counterparties are free to trade. Any trade that is shown in green can be freely traded by the trader, and credit approval is assumed to be in place. [0240]
  • YELLOW: The price posted is free to trade by the viewer, but the poster of the price has excluded the viewer from his/her credit preferences. If the price is colored yellow, a deal may be allowed provided that the party who placed the passive order allows mutual puts, and the credit over-ride process which is described below is completed. The viewer can attempt to trade by sending a message (thereby initiating the credit over-ride process) to the poster of the price which discloses the name and/or identity of the viewer, along with a mutual put maturity entered by the viewer. The poster then has the opportunity to accept, accept subject to credit (in either case, the poster may also reduce the maturity of the mutual put), or decline. The poster's name will not be released to the viewer until a trade is executed. The posted price will remain available to all other traders on the [0241] system 10 until a trade is completed. If the order trades to another viewer, then the credit over-ride process will be terminated.
  • RED: The price posted is excluded by the viewer's own preferences even though the poster is (may be) clear to trade. In this situation, the viewer is not free to trade since it is the viewer's own credit preference that the viewer set which is preventing the trade. [0242]
  • BLUE: The price is the viewer's own order. [0243]
  • WHITE: Only used in the market entry interface [0244] 250 (FIG. 12) to display prices where there are multiple orders at the best price with differing codes. Thus, the viewer is notified to view the market details interface for more information.
  • In the over-ride process mentioned above, if the viewer sees a price coded yellow that he/she wishes to trade, then the viewer may activate the over-ride process. The over-ride process begins by prompting the posting party with a request for an order quantity. The message sent to the poster essentially states that the viewer, which is identified by name in the message, wishes to trade a stated quantity and that the receiving party has a stated period of time to respond, for instance, 15 seconds. The viewer will then see a copy of his/her message and a clock which displays the countdown of the stated time to the poster. The poster receives the message and can decline or accept. If the poster declines, then the viewer is informed accordingly. If the poster accepts, then the poster has the option to add a mutual put maturity and request a small price adjustment, which will be stated in a specified number of months. The viewer cannot back out of the trade while the clock is running (unless a price adjustment is requested). Further, at no time is the poster in a trade until all steps are complete. [0245]
  • The process by which passive orders are color coded is described at this point. Regardless of the credit preference type, the [0246] trader workstation 20 generates a maximum maturity value that determines how an order will be color coded. The maximum maturity value is in the form of an integer n digits in length, with the right-most two digits representing days, and the left (n−2) digits representing months. Therefore 12000 represents 10 years, 3600 represents 36 months, and 114 represents 1 month, 14 days. The method by which credit preferences are converted to a maximum maturity value is represented by Table 2 below.
    TABLE 2
    Preference
    Type Maximum Maturity
    Binary No −231, the smallest possible integer value
    Binary Yes
    232 − 1, the largest possible integer value
    Line Binary The maximum maturity associated with the preference
    (e.g., Line Binary/12 has a max maturity of 1200)
    Complex The maturity of the highest band with an exposure amount
    greater than zero.
    (e.g., The following complex preference would have a max
    maturity of 6000)
    Mat Band Exposure
     100 10,000,000
     600  5,000,000
     1200  3,000,000
     3600  1,000,000
     6000   500,000
    12000       0
  • Every instrument in the [0247] system 10 possesses a maximum maturity value. To determine whether a particular order can be traded, the maximum maturity for the order's instrument is compared to the maximum maturity of the credit preference. If the instrument's maximum maturity is greater than that of the credit preference, then the order may be traded, otherwise it cannot be traded.
  • Note that the maximum maturity assigned to a Binary-No preference will be lower than that of any instrument, effectively making all instruments untradeable. Likewise, the maximum maturity of a Binary-Yes preference will exceed that of any instrument. [0248]
  • In order to determine the appropriate color code, the [0249] trade workstation 20 maintains two lists for each instrument class. One list includes the credit preferences that the viewer has set against all other legal entities for that instrument class. This list may be referred to as MY_PREFS. The other list includes the credit preferences that all other business units have set against the viewing legal entity for that instrument class. This list may be referred to as OTHER_PREFS. Each of these lists contains the following data:
  • Business Unit ID (Only used for OTHER_PREFS) [0250]
  • Legal Entity ID (Only used for MY_PREFS) [0251]
  • Maximum Maturity [0252]
  • Credit Level (Only used for MY_PREFS) [0253]
  • Consider, for instance, an order for an arbitrary FRA instrument placed by business unit (1) of legal entity (1). When the order is broadcast out to a plurality of traders [0254] 20 (i.e., viewers), the order will include the following information:
    Business unit of trader placing order: business unit (1)
    Legal entity of trader placing order: legal entity (1)
    Maximum Maturity of order: 3600 (for example)
  • In order to color code the order, the viewing party must extract and utilize his/her credit preference against legal entity (1) from the FRA MY_PREFS list, and business unit (1)'s preference against him/her from the FRA OTHER_PREFS list. From the credit preferences extracted, the color of the order as it will appear to the trader is as defined in Table 3 below. [0255]
    TABLE 3
    MY_PREFS OTHER_PREFS
    PREFERENCE PREFERENCE
    max maturity >= 3600 max maturity >= 3600 Color of Order
    false false red
    false true red
    true false yellow
    true true green
  • Also, note that the MY_PREFS list may contain a credit level (e.g., which may be associated with the order and presented to the viewer. [0256]
  • Accordingly, when the user logs into the [0257] system 10, the user populates the MY_PREFS and OTHER_PREFS lists for the instrument classes for use by the credit preference module 76 (FIG. 3). This is achieved by the central processing center 12 sending to A trader workstations 20 that is logging-on one or more messages including the MY_PREFS and OTHER_PREFS lists from the database 66 on the hard disk 64 (FIG. 2).
  • When a user changes a credit preference assigned to a legal entity for a particular credit group in a way which causes the maximum maturity of the credit preference to change, the user will receive updates to MY_PREFS from the [0258] central processing center 12. Also, any user within the affected legal entity who is logged on to system 10 will receive an update to OTHER_PREFS. Changes to complex preferences do not require such an update unless the zero band is changed (thus modifying the maximum maturity). If the user changes the credit level associated with a legal entity, the user will receive an update to MY_PREFS.
  • However, these two updates should not be performed at the time the changes are made, as doing so could allow a user to determine the legal entity that placed an order by methodically changing his/her credit preferences against each legal entity from a green state to a red state until the order changed color. Instead, the required updates will be collected and sent out on an periodic basis. Also, to discourage discovery of a counterparty's identity by assigning a unique credit level to a single legal entity, each credit level should be assigned to either no legal entity, or to more than one legal entity. [0259]
  • From the [0260] command center interface 130, a user may enter the market entry interface 250, as illustrated in FIG. 12. At the market entry interface 250, the user can simultaneously monitor numerous markets and place orders, including bids and offers. The market entry interface 250 also allows the trader to select any instrument(s) to be displayed, and multiple market entry interfaces 250 with various trading functions (e.g., common FRA on one interface, SWAP on another interface, and Switches on yet another interface) may be opened on the trader's desktop simultaneously. The market entry interface 250 is designed to present the sum of the best bid and ask, and the act of trading by any two parties by a flashing volume indicator in the top right-hand corner. Thus, the market entry interface 250 enables a trader to easily monitor many different markets with relative ease and utility. It should be noted that the system 10 does not perform auto-matching of orders, but allows the user to maintain control of the trading process at all times. The system 10 does this by introducing the concepts of active and passive orders. A passive order is an order placed in the system 10 for a particular instrument, for a particular quantity, at a specific price, for a particular time period (see order types below). An active order is when a user decides to trade a passive order displayed in the system 10, and is usually only required to provide the quantity. Thus, there can be active or passive bids and offers.
  • The user may customize the [0261] market entry interface 250 by adding and removing instruments (i.e., markets) displayed in the instrument display window 252. The user may add new markets by entering an instrument symbol (according to the symbology of the present invention) into instrument identifier field 254. The user may also want to define groups of instruments which can be saved as profiles and viewed together. Profiles allows the user to organize multiple markets by like attributes. The profile being viewed is displayed in the profile display field 256. The profile display field 256 is a pull down menu that lists the other profiles defined by the user. Until the user defines a first profile, the profile display field 256 is set to default.
  • Individual markets displayed in the [0262] instrument display window 252 are divided into four columns: instrument, best bid, best ask, and info. The instrument column displays the instrument name (i.e., the symbol, alias or a security identifier). The best bid column displays the best bid information, defined herein as the orders that are at the best price. The best bid information includes a relatively large central number that displays the least two significant digits of the price, a bottom left number that displays all but the least two significant digits of the price, a bottom right number that displays any volume or quantity currently trading, and a top right number that displays the quantity of currency units in millions. Depending on the precision desired, a greater or lesser number of digits can be displayed as the larger central number. The precision of the displayed central numbers is defined for each instrument, and may, for example, include 2, 3, 4, or more digits. The best ask column is substantially identical in format to the best bid column, but displays the best asking price rather than the best bid price. The info column provides space for data items that the user may select to view, as defined in an info window 258. In the present embodiment, three items are defined in the info window 258, and thus, the corresponding information for the instrument will be listed in the info column.
  • The [0263] system 10 provides users with a symbol construction interface 270, as illustrated in FIG. 13, that can be accessed via a Lookup button 272 from the market entry screen 250. The symbol construction interface 270 functions to aid the user in selecting instrument for display in the instrument display window 252. From the symbol construction interface 270, the user can view available aliases in window 273, explode a symbol (i.e., view a list of underlying parameters associated with the symbol, for example, payment date) via the Explode Symbol button 274, select symbols to be added to a profile via the Add to Profile button 276, and construct new symbols or aliases via the Build Symbol button 278. The symbol construction interface 270 also provides error checking such that only valid symbols can be selected. An instrument should exist in the database to be valid, and not all combinations will exist. For additional verification, the symbol explode function of the Explode Symbol button 274 enables essentially all aspects of the instrument to be displayed in detail. Thus, the explode symbol feature provides a complete detailed description of the instrument in Symbol window 280.
  • The [0264] symbol construction interface 270 screen also enables the user to search for groups of symbols by at least partially fig out the input parameters 282 located above a Search Options button 284, and then selecting the Search Options button 284. The input parameters 282 include various non-commercial terms of an instrument that can be negotiated following a transaction. For instance, as shown in FIG. 13, the input parameters 282 include class of instrument, currency, start month, end month, over, FLOPT, and special rules. By at least partially filling in these parameters, the user can search for similar instruments which are displayed in window 280.
  • Referring back to market entry interface of FIG. 12, it is noted that the prices displayed in the best bid and best ask columns are encoded with credit information using the color scheme described above. As previously mentioned, color-blind users can have the color coding scheme replaced by a symbol scheme in which different symbols are positioned next to the respective prices to indicate the credit status of the order. The symbol scheme may be chosen by the user under the Environment tab of the preference interface [0265] 148 (see FIG. 6B).
  • It should also be noted that the inventors of the present invention are not presently aware of any electronic trading system that offers color-based credit preference pre-screening such as that disclosed herein. The present invention provides color-based credit preference pre-screening because, unlike the prior art systems which only show the best dealable price or the best minimum quantity, the present invention shows all prices (bids and offers), irrespective of their credit preferences. Thus, the user can be provided with as wide of a view of the markets as the user desires. Advantageously, the color coding enables the user to visually determine virtually instantaneously what bids and offers are tradable based on the credit preferences of the trader and the counterparty. [0266]
  • Once the user has entered the desired financial instruments in the [0267] market entry interface 250 via the symbology, the best bid and offers for each of the desired instruments will be displayed in the instrument display window 252. The best bid and best offer prices display in window 252 are different from many prior art systems because they are the absolute best bid and best offer at the stated quantity. Because of the unique color coding scheme, the user is able to quickly tell whether or not the bid or offer is tradable by him/her. If the user so desires, the user can select a financial instrument with the pointing device 86 (FIG. 3), such as a mouse, so as to highlight the row in the instrument display window 252 for that instrument. Once the financial instrument is highlighted, the user may perform one of several functions provided for by the function bar 290, each of which is described below:
  • EXPL Function: This explodes the instrument symbol into a full description of the contract, and mirrors the confirmation [0268]
  • HIT, LIFT, ORD Functions: These three buttons allow a user to select an instrument and then place a new order, or execute an active order, by hitting or lifting the desired respective bid or offer. The HIT, LIFT, ORD functions can also be carried out by double clicking the mouse in the screen itself. [0269]
  • RFP Function: request-for-price messages are an important tool to allow the market to communicate. If a trader wishes to see a market, a broker will be contacted via the telephone, and the broker will in turn phone other traders to drum up interest. Using the [0270] system 10 of the present invention, the same result can be achieved instantaneously by sending an RFP to all registered users. This message may be displayed in the command center interface 130 of other users, informing them of a RFP in the named instrument. In addition, because derivatives traders are often trading more than one financial instrument, and sometimes in more than one currency, derivatives traders will often have multiple passive orders. The present invention provides at least three order management functions to facilitate the canceling or temporarily suspending the order. This may be an important functionality when the market is moving quickly, or if the position of a trader suddenly changes.
  • XLST Function: This function cancels the last passive order placed by the trader. Therefore, if a user submits an order and immediately changes his or her mind, the order can be canceled without the need to select the order individually. [0271]
  • XALL Function: This function allows the user to cancel all his or her outstanding passive orders in one key stroke. [0272]
  • REF Function: This function allows the user to suspend or place all orders under reference. This is an alternative to canceling orders one by one. For instance, if a user is expecting news that may affect only a few outstanding orders, it may be safer to place all orders under reference, and individually re-release the orders the trader expects not to be affected back into the market. [0273]
  • DEL Function: This function allows the user to delete a market from the profile. [0274]
  • In specific regard to the ORD button in the [0275] function bar 290, a user can submit a passive order by selecting the ORD button. If the ORD button is selected, a passive order interface 294 is provided to the user, as illustrated in FIG. 14A. From the passive order interface 294, the user can place a passive order such as a bid (i.e., buy) or an ask (i.e., sell). The user enters a price, quantity, and selects how long the order will be good. The price will default to current market level so the user may only need to enter the last two digits of the price. For quantity, the system 10 recognizes m, mm and b for thousands, millions and billions, respectively. The system 10 allows the following order types to be entered under the good until option:
  • good until logout (default)—Requires the user to be logged on and to monitor the orders status. [0276]
  • good until time—The user will be prompted to enter a time (in his or her own time zone). This order does not require the user to be logged on and will be canceled automatically by the [0277] system 10 at the appropriate time.
  • good until canceled—This order again does not require the user to be logged on, but must be canceled by the user. [0278]
  • The system checks any new orders for reasonableness (or “framing”) as they are placed. For example, a bid cannot be higher than the existing offer without the user double checking. The tab key, enter key, or the mouse can be used to navigate through the [0279] passive order interface 294. Upon selecting the OK button, the order is submitted into the system 10 and the user is returned to the market entry interface 250.
  • In specific regard to the HIT and LIFT buttons in the [0280] function bar 290, a user can initiate active orders by hitting a bid (i.e., sell) or lifting an ask (i.e., buy). By selecting either the HIT or LIFT button, a hit order window or a lift order window is presented to the user. For example, a hit order window 296 is illustrated in FIG. 14B. The hit order window 296 is substantially identical to the lift order window. As shown, the hit order window 296 identifies the instrument and order price. Further, the user is presented with a transaction quantity which is initially set for the full amount being offered by the counterparty. The user is allowed to reduce the quantity figure. The user is not allowed at this point to increase the quantity figure because the counterparty has already indicated the quantity they are desiring to sell. Upon selecting the OK button, the order is executed by the system in the manner described below, and the user is returned to the market entry interface 250.
  • In addition to the above functions provided by the [0281] function bar 290, if the user wants to see the full depth and breath of a particular market in a particular financial instrument, the user can select (e.g., highlight) an instrument in the instrument display window 252 and then click on the MDS button 292. This will launch the market detail interface 302, as illustrated in FIG. 15 for the highlighted instrument.
  • The [0282] market detail interface 302 enables a trader to view essentially all the orders in the market for a particular instrument, both bids and offers. The bid orders are listed in a bid window 304 where the credit levels (e.g., A, B or C), bid quantities and bid prices are provided. The offer orders (i.e., ask orders) are listed in ask window 306 where the ask prices, ask quantities and credit levels are provided. As with the market entry interface 250, the orders are color-coded with the appropriate credit preferences. This is a significant departure from many prior art systems which only show the best dealable price or blended prices.
  • In the [0283] market detail interface 302, orders are individually listed in the bid window 304 or the ask window 306 in order of price, and then according to the time the orders were entered into the market. The user has the ability to select any order on the screen and hit or lift the order, assuming of course that the respective credit preferences will permit a trade. The user is provided with a function bar 308, which is substantially the same as function bar 290. Particularly, the buttons of the function bar 308 are substantially identically to those on the function bar 290 except that they only apply to a particular instrument while the buttons of the function bar 290 apply against multiple instruments. Further, a fair price indicator, spot/setting indicator (i.e., the LIBOR for that day), and last traded price indicator are provided along the bottom of the bid window 304 and ask window 306. The last trade pricing may be replaced by volume, duration, RQ, last close price, etc.
  • An advantage of the [0284] market detail interface 302 is that the user is not restricted to trading only the best price or first order. At no point in the process will any orders be automatically matched against each other by the system 10. The user is in complete control of the order flow process.
  • Thus, the user can execute both passive and active orders from either the [0285] market detail interface 302 or the market entry interface 250. At either interface 250, 302, if the user wants to execute a trade, then the user only need to highlight the desired bid or offer and select the corresponding function button from the respective function bar 290, 308 to initiate the transaction. Although the semantics of placing, changing, and canceling orders can be relatively complex, the user is shielded from this wherever possible by the system 10.
  • Each order entered into the [0286] system 10 is placed into a queue based on price and time received. A change to the order may or may not affect the order's place in the queue. Any change of price will move the order up or down in the queue depending on the price level. Any decrease in the volume of the order will not affect the order's place in the queue. Any increase in volume will result in the previous amount holding its place and a new order placed for the balance.
  • Effective electronic trading should be intuitive, fast and reliable. In order to facilitate this, the present invention is designed to maximize a user's efficiency. The [0287] system 10 enables the user to place passive orders from either the market entry interface 250 or market details interface 302 using the input device 86. For instance, the user may double click on the instrument name or may select the ORD button of the function bar 290, 308 in order to launch the passive order interface 294.
  • Once an order has been submitted, it will immediately be updated to the market entry interfaces [0288] 250 and market details interfaces 302 of other users, providing the user has a current subscription (i.e., field setting) to the instrument.
  • For monitoring the status of a user's outstanding (or open) passive orders, and for making quick adjustments to those orders, the present invention has a facility known as an [0289] outstanding order blotter 320, as illustrated in FIG. 16. The outstanding order blotter 320 summarizes all outstanding passive orders and provides the user with the ability to confirm the terms of the trade, the symbol, and the type of order. In addition, the outstanding order blotter 320 enables the user to quickly change the price, quantity, or good until status via drop-down menus that appear when an order is selected. From the outstanding order blotter 320, the user may also place new orders and/or cancel a particular order in the market. Thus, the outstanding order blotter 320 gives the user the ability to manage his/her current passive orders in the market from a single interface. As with the market entry interface 250 and market detail interface 302, the user is provided with cancel all, cancel last, and refer-all functions via the outstanding order blotter 320. This is a significant advancement over many prior art systems in that not only does the system 10 offer a facility to track all current passive orders, but the system 10 also enables the user to modify, add or delete passive orders from the outstanding order blotter 320 without returning to the market entry interface 250 or market detail interface 302.
  • For executed or canceled orders, the user is provided a [0290] client monitor 330, as illustrated in FIG. 17. From the client monitor 330, the user has access to completed or canceled trades. Thus, the client monitor 330 enables the user to quickly see what orders have been executed or canceled, and to look back over time to see previous days trades. Preferably, historical transactions will be available for one month via the client monitor 330.
  • The [0291] outstanding order blotter 320 and client monitor 330 enable a user to manage his/her diverse trading activities. From either blotter, the user can monitor the status of orders and executed or canceled trades. Both of the outstanding order blotter 320 and client monitor 330 can be accessed from the command center interface 130. Further, the blotter 320 and monitor 330 are updated automatically if the user submits an order via one of the other interfaces.
  • The [0292] system 10 permits active orders (i.e., those where a trader hits or lifts a passive order) to be placed from either the market entry interface 250 or market detail interface 302 via the Fir and LIFT buttons on the function bars 290, 308. The system differs from many prior art systems in that two passive orders will not be executed against each other automatically. An active order from an active user is required for execution. Furthermore, there will be one active and one passive user for each trade. This means choice (where bid equals order) or even backwardation (where bid is higher than order) markets are possible. Accordingly, for a transaction to be completed in the system 10, an action must be performed against a passive order.
  • Once an active order has been placed in the [0293] system 10, the execution process is completed. An execution notification message 340, as illustrated in FIG. 18, is sent to both counterparties, describing the transaction and disclosing the names of the counterparties. Note, this is the first point in the transaction that the counterparties are identified to one another. The system 10 ensures that both users receive the message before the trade is finally completed. This does not require any form of action from either user, the market interface module 74 (FIG. 3) of each trader responds for the respective user. This validation ensures that, in the unlikely event that a connection is lost during this process, a user does not have a position of which he or she is unaware.
  • The [0294] system 10 is designed to ensure that a user cannot execute a passive order which has been canceled or is no longer available. This is done by checking to verify that the connection between all trading counterparties is live at all times. In the event that the connection is lost or broken, all orders from a user which loses connection to the system 10 are automatically suspended. Following the execution, the client monitor 330 is updated with the transaction.
  • The execution notification message [0295] 340 (FIG. 18) provides the users the opportunity to increase the quantity of a trade once an initial trade has been executed. One of the users can insert a quantity in the will-do-more field 342 which represents an additional quantity to the original amount. This feature is designed to enable a user who has a large quantity to trade to place a passive order for just a smaller portion initially. Users often want the ability to increase the quantity of an order when they have a large quantity to transact. This is because large orders in the market often tend to adversely move the price of the market as market participants back off such large size. The ability for the passive trader to conduct an anonymous dialogue via the system 10 for increasing the size of a transaction after an initial transaction for a smaller size has been executed is an additional difference between the system 10 and many prior art systems. In operation, once an amount has been entered into the will-do-more field 342 and the Submit button 344 selected, the counterparty is provided with the request for more. The counterparty is given a discrete period of time to respond to the request to do more, after which the request lapses. If the counterparty wants to trade more, then the counterparty can accept the amount requested, reject the amount by selecting the Reject button 346, or the counterparty can request a different amount that is then present back to the user who then has a discrete period of time to respond. The counterparties can exchange offers to increase the quantity as many times as they desire until an addition amount is agreed upon or a decision is made not to do more.
  • This function should preferably be made available only if the active order clears the full market size at the current best price. In that case, either party may ask to do more. The will-do-more feature enables the counterparties to increase the size (amount of the trade), but not the price. The price is preferably not affected. This process can go back and forth for some time and can continue as long as the will-do-quantity is fully accepted (i.e. can occur more than once). Once completed by both parties, the system will combine all will-do-more quantities and generate only one transaction ticket for the total increased amount at the initial price. [0296]
  • Following the execution of a trade, the [0297] system 10 enables the parties to negotiate the non-commercial terms of the transaction. This process is referred to as term negotiation, and is effectuated through the negotiation window 350, as illustrated in FIG. 19. The term negotiation process is a process where by both parties to a trade have the ability to negotiate non-commercial terms of a transaction. In addition to the commercial terms, such as price, quantity, etc., derivative transactions also have non-commercial terms which do not affect the price of the trade. While there are defaults, the parties may want to negotiate these terms. Once a trade has been executed, the system 10 will present the parties with the option to negotiate via interface 350. The system does not force a party to complete this process immediately, however, as the party may have other more important tasks to complete elsewhere. The negotiation should, however, be completed within a reasonable time. The active party (i.e., the trader that hit or lifted the order) will be presented with the terms 352 to be negotiated, current values 354 which are editable (such as by a text field), and default values 356 which are predefined in the system. The trader may accept the system defaults by selecting button 358, or enter his/her own desired values and select the submit button 360. These values are sent to the passive trader (i.e., the trader that placed the order in the system originally) who may also accept or enter his/her desired values. if an agreement cannot be reached, then the defaults will be used. The status of these negotiations will be displayed in the client monitor 330 of FIG. 17.
  • Once a trade has been executed and the non-commercial terms have been negotiated, a trade confirmation is sent automatically to the settlement contact of both business units preferably via fax. The [0298] system 10 can also send the confirmation via file transfers, e-mail, or any other suitable means of communication. Preferably, the trade confirmation includes the quantity or volume traded, identification of the financial instrument that was traded, price, date and time the execution is recorded, and a settlement ID that uniquely identifies the transaction. However, it is recognized that various other parameters and transactional data can be included as appropriate for the nature, type and subject matter of the transaction.
  • In addition to the interactive trading functionality described herein, the system also offers traders a trading methodology for dealing with risk management problems unique to interest rate swap dealers. In particular, over the last few years, a new market has emerged as a result of interest rate swap dealers' need to better manage their risks associated with changes in interest rates on their growing interest rate swap portfolios. With these markets becoming more competitive, bid-offer spreads are narrowing considerably. This factor, combined with the wide spreads of exchange traded Eurodollar futures, has contributed to the use of exchange traded contracts for hedging short-term risks being expensive and sub-optimal. As a result, the switch was created. A switch is simply the simultaneous purchase and sale of a pair of similar forward rate agreements. This instrument, and the mutually offsetting need of a pair of derivative portfolio risk managers, provide an improved risk management tool for a large portfolio of interest rate swaps. Despite the obvious advantages and demand from risk managers, as a result of the complexity and time-consuming nature of completing a transaction, the switch market has grown relatively slow. This may be because risk managers are very wary of disclosing the exact nature and size of their own portfolios. Therefore, finding the counterparty that has the opposite need is often difficult. [0299]
  • Typically, a dealer prepares a fax listing the days that the dealer needs to buy or sell, but not the amount or importance of any given date. The dealer sends the listing to other risk managers at other firms, or to voice brokers. From this bit of incomplete information, transactions are eventually negotiated. While finding switches may be important, it is usually not urgent as compared to other more immediate tasks, such as new executions or the hedging of large outright market risks. As a result, the time is never quite right to focus on a position that may be heavily weighted on one side and matches another's position, but not perfectly. Voice brokers have tried to solve this by matching multiple faxes, but this does not appear to be the solution. [0300]
  • The present invention goes several steps beyond these efforts, and offers matching with the credit preferences of the traders taken into account. The [0301] system 10 also demonstrates fairness in any matching process. When the portfolios are so large that each risk manager has a position on each day out over the life of his or her portfolio, the resulting combinations can be huge. The rules, constraints and priorities are preferably structured in a way to demonstrate fairness of execution between users to the market participants.
  • In a significant departure from known attempts by others, the present invention offers traders a solution to the complexities of switch trading by creating an anonymous position discovery system called the switch engine. The objective of the switch engine is to put a tool in the hands of risk managers that allows them to perform anonymous switch transactions fast and efficiently without losing control of the process. The switch engine achieves this by having the trader manually input his/her position (i.e., interest rate risk portfolio) into the switch module [0302] 80 (FIG. 3) via a portfolio interface 380 using variable rate index and currency for up to 180 days or more into the future, as illustrated by FIG. 20. Once a portfolio is inputted, the user must confirm its accuracy by selecting the Apply button 381 before the positions can be used in the switch mechanism 35 of the central processing center 12 (FIG. 2).
  • In addition, the [0303] system 10 can be configured to receive the position data via electronic transfer or some other suitable form of data transfer. This may include a transfer directly from the user's own risk management systems. Although some trader workstation 20 may need some customization to receive portfolios in this matter, the system 10 should support this capability. The nature of switch positions, particularly in the near term (defined as out to the maturity of each index), is relatively stable, and therefore, the on-line entry of portfolios by the user should be adequate for most traders. The inputted portfolio data is then sent from the trader 20 workstation to the switch mechanism 35 of the central processing center 12.
  • With reference to the [0304] portfolio interface 380 of FIG. 20, an inputted column 382 represents the portfolio entered by the user, the traded column 384 is the cumulative amount traded by the user since the portfolio was entered in the inputted column 382. The net column 386 is the real-time position of the user given the portfolio inputted and the traded quantities in column 384. The user may restart at any time by rolling the net positions in net column 386 into the input column 382 by selecting the Roll button 388, or by clearing all the positions by selecting the Clear button 389.
  • Once the position is inputted in the [0305] system 10, a switch interface 400, as illustrated in FIG. 21, is generated by the switch module 80 using his/her own position data from other traders entered on the respective trader workstations 20 and uploaded to the switch mechanism 35. The switch interface 400 enables the user to search through the market, and view possible trading combinations of his/her portfolio and combinations of his/her portfolio against positions from other counterparties which have been input into the system. This is referred to as position discovery. The switch interface 400 can be reached by selecting the switch engine button in the tool bar 132 of the command center interface 130 (FIG. 5). For a given floating rate index (for example, a one month LIBOR) 402, the switch engine interface 400 lists the net positions 404 for each day 406 out 180 days. In addition, the possible switches 408, available switches 410, formulated forward rate 412, and a fair price 414 are also listed for each day 406. By selecting a day 406, the switch interface 400 displays all possible switches against that day. Thus, the user can pick the days for which he/she is carrying the most risk. An advantageous feature of the switch interface is that the user is provided with only combinations where he/she has a position and someone else has the opposite position, and both parties satisfy each other's credit preferences as described above.
  • The [0306] net position 404 is the position entered or modified by the user. Possible switches 408 are those switches for any given day with respect to the trader's own position. Note, a switch typically makes sense only if the trader's position is long one day and short on another day.
  • The [0307] available switches 410 are positions in other counterparty portfolios that exactly offset the position of the user. Note that the switch interface is configured to displays available switches up to the size of the user's own position, and preferably does not disclose the name(s) of any counterparties until after a trade has been completed. This ensures the anonymity of the user, and does not disclose any material position data to other traders.
  • The [0308] forward rate 412 is the current market forward rate calculated by the system from other available market rates for the given date for the maturity of the underlying index maturity. The fair price 414 represents the relative price between the two underlying FRAs, which is the basis upon which forward rate agreements are traded. The fair price 414 is calculated from live market data taken from other financial instruments. While not designed to execute trades at the displayed fair price 414, the fair prices are an aid to users in gauging the fair value of the market.
  • Once a user has found a switch that matches the needs of the user, that is shown as an [0309] available switch 410, then the user may send a request for switch message by selecting the request for switch (RFS) button 416. In response thereto, an RFS message is sent anonymously to only the other counterparties of the selected offsetting positions. Anyone of the receiving counterparties may then add the symbol automatically into a market entry profile by selecting (i.e., clicking on) the message and completing the transaction utilizing the market entry interface 250, as described herein. Upon completion of a switch by the switch mechanism 35, the portfolio's of the counterparties are automatically updated to reflect the switch. In accordance with a feature of the switch engine, switch transactions can be accomplished in real-time.
  • As an example of a switch, a trader viewing the [0310] switch interface 400 may select (i.e., highlight) the “Thurs., Aug. 21” position, and then select the RFS button 416. The passive order interface 294 (FIG. 14A) then prompts the trader with a quantity and price which the trader may modify. The trader may then submit the request for the switch. All anonymous counterparties that have an offsetting position then receive a message in command center interface 130 (FIG. 5) notifying the counterparty of the anonymous request for a switch. Any one of the counterparties may then select the request message which causes the request to be displayed in the market entry interface 250 (FIG. 12). From the market entry interface 250, the counterparty can hit the request for switch or submit their own passive order.
  • The trader can update or modify his/her portfolio by selecting the [0311] Update button 418, which launches portfolio interface 380, as described above. The trader can then select an inputted amount 382 or a traded amount 384 to enter or edit the displayed values as desired.
  • It should be noted that the present invention has application in financial markets other than derivatives. For instance, in the inter-dealer market, a switch or swap may be a desirable means by which a risk or inventory short fall is off-set. In particular, a security may be borrowed or an open derivative position hedged with another position. For instance, in the U.S. Treasury bond market, it is conventional for traders to buy and sell securities, and to hedge with the newest or benchmark issues. The U.S. Treasury may issue new two year securities each month. For the first month, the new issue is the benchmark (or on-the-run) issue, and the other issues with a final maturity between one and two years are referred to as old issues. If a trader is asked to buy an old issue, then the trader will sell the on-the-run as a hedge since the on-the-run has the liquidity. Over time, the trader will most likely need to sell the old issue and buy back his/her hedge. A switch with another dealer that has an opposite position provides cost and risk effective method of effectuating such a trade. [0312]
  • However, the unwillingness of traders to disclose their position has made bond switches difficult. Thus, the switch engine of the present invention is a solution. The principals of the switch engine can be successfully applied to bond switches, as well as other financial instrument switches. The [0313] switch engine interface 400 may need to be slightly modified wherein the instrument designation 402 is changed to reflect the new market, for instance, to Two Year U.S. Treasuries or 30 FHLMC TBA. Further, the setting column 406 may be changed to reflect the individual securities which may be switched, and the remaining columns should not need to be changed. However, a new column representing the duration of each security displayed should be added so that the securities can be duration weighed to ensure fairness.
  • In addition to the switch engine, the [0314] system 10 provides trading methodologies referred to as the auction and switch auction. Although auctions are held in a variety of markets, some of which are electronic, the auction and switch auction have no known counterpart in the derivatives markets. The auction and switch auction trading methodologies were developed in order to provide an auto matching process for switches. However, the system 10 can use these auction methodologies for auto matching for a wide variety of other financial products, not just switches.
  • Unlike traditional auctions, where once a trade is completed the counterparties are free from future financial commitments, with derivatives trading, the counterparties may end up with multi-year facial commitments to one another once a trade is executed. In order to deal with this relatively unique problem, the auction and switch auction take the credit preferences of the users into account. The auction methodologies herein are referred to as a two way Dutch auction with credit. In conducting such an auction, users submit orders into the [0315] auction module 81 of the trader workstation 20 (FIG. 3) which communicates the information to the auction mechanism 34 of the central processing center 12 (FIG. 2). The orders are submitted via an auction interface 430, as illustrated in FIG. 22A, by price, quantity, and action.
  • With reference to FIG. 22A, the [0316] auction interface 430 includes a queued orders window 432 into which the user enters an order, and a submitted orders window 434 which shows the orders submitted to the auction mechanism 34 via the auction module 81. Orders can be added via the Add button 436. Orders are moved from the queued orders window 432 to the submitted orders window 434 by highlighting the order and then selecting the Submit button 438. All entered orders in the queued orders window 342 can be submitted at once by highlighting all the orders and then selecting the Submit All button 442. Prior to submitting an order, the orders in the queued orders window 432 can be edited via the Edit button 440 or canceled via the Cancel button 444
  • In accordance with the auction, the orders are filled at their entered price or better, and between counterparties that satisfy the credit preferences of one another. The [0317] auction mechanism 34 then conducts the auction, preferably utilizing the following constraints and priorities to ensure fairness.
  • The auction price is calculated by finding the price at which the most volume is traded. This condition is sufficient to generate a fair price, and all transactions should be completed at this price. It is noted that this price is generated without taking credit into account. The matching of orders is completed to ensure that credit preferences (including complex rules) are safe guarded and to ensure that the minimum number of tickets are generated. The better submitted prices will have priority, and all orders at the auction-price are filled in proportion to each other. Under these constraints, the [0318] auction mechanism 34 executes the auction, matching users and generating a settlement list. The settlement list comprises the trades resulting from the auction.
  • The confirmation process is substantially the same as that for interactive trades. The [0319] system 10 notifies the users of their fills. Finally, results will be made available to the user via a message to the command center interface 130 of each user.
  • In addition to the general auction facility described herein, the present invention also offers a dedicated limited auto-matching process for switches referred to as the switch auction. The switch auction does not have to be a full auction, in that the price may be set by the [0320] system 10. The price will, however, be available before the commencement of the matching. This will allow all users to understand the levels that will be used before entering into the switch auction. This also allows the users to maintain control of their positions.
  • As with the general auction, the positions of each trader are loaded into the [0321] system 10 utilizing a switch auction interface 460, as illustrated in FIG. 22B. The switch auction interface 460 has two parts, an auction list 462 and an auction status 464. In the auction list 462, various auctions and their respective statuses are listed by FLOPT and currency. In the auction status 464, the auction selected in the auction list 462 is displayed and identified (including the open and close day/time). The positions 466 for respective dates 468 are entered by a user, and do not need to add to zero, but should include positions of both signs (i.e., long and short). The rate 470 is the price at which the auction is conducted. The rate 470 is displayed a predetermined amount of time before the auction is conducted so that the participants have the opportunity to step out of the switch auction if they so desire. The rate is preferably based on available market factors, and may be calculated by a calcserver (as described below). The results column 472 is the total trade amounts resulting from the auction. The amount displayed in the results column 472 for a given date may be the cumulative amount from multiple transactions with multiple parties. Additional control buttons 474 enable the user to submit an order, cancel an order, cancel all orders, or change an order. The switch auction will auto-match the position, talking credit preferences of the users into account so that (1) a maximum volume is executed and (2) a minimum number of tickets is generated.
  • The switch auction utilizes the above two rules to ensure fairness. No user will be given priority over any other user except as required to satisfy the respective credit preferences. Preferably, only two-way switches will be offered. Switches are a risk management tool, and switches generated between three counterparties introduces substantially more credit risk than a straight two-way switch. [0322]
  • At this point, the calcserver which calculates the auction rate and price information, and other relevant data for operation of the [0323] system 10 is described. The calcserver provides the switch mechanism 35 with the forward rate for any given index for each day, the system price quoted in the market entry interface 250, and OTC derivative prices derived from the yield curve. The calcserver comprises a preprocessor, a zero curve server, a FRA server and a Swap server. The preprocessor gathers real-time data from outside data vendors (such as Reuter or Telerate) and from internal system sources (such as data normally entered into system 10), and prepares the data for processing by the other components of the calcserver. The zero curve server reads in the market rates (including price and yield for a variety of class instruments such as money market rates, swap rates, future prices, swap spread, bond yields and FRA's) as provided by the preprocessor, and generates therefrom the zeros and discount factors for each currency and level of credit. In particular, a zero coupon yield curve (i.e., zero curve) comprises a set of points representing the calculated interest rate or discount fact from observable market rates across the term structure (e.g., 0 to 30 years) such that any cash flow can be discounted to today in one step without the consideration with decompounding. Thus, there is a different zero curve for each index/currency pair. The FRA and Swap servers are instrument specific servers that calculate forwards, RQ (as defined above), durations and fair prices. By way of example, the zero curve calculation starts from the instruments with the shortest term structure in the money market rates (MMs). The analytics for finding points on the zero curve from MMs are as follow. The processed price of the MMs, end date of the MMs and the basis of the MMs (number of days in a year that the MMs is based on) are needed. All of these are stored in a database 64 (FIG. 2). The processed price is the only input that typically changes. The calculation represented by the equation below will generate a new zero rate with the date of the end date of the MMs. The result will be a new zero point which will be added to the rest of the generated zero points. The following equation for Z(t) is the zero rate at the end date of the MMs: z ( t ) = ( 1 + R mms * t mmsBasis ) 365 t - 1
    Figure US20030093360A1-20030515-M00005
  • where Rmms is the processed price of MMs, and t is the time in days between the end date of the MMs and the current date. [0324]
  • After the MMs, the next instruments used according to term structure are either the futures or FRA's. Since the futures and FRA's have similar term structures, a choice will be made on which ones to use. Initially the futures will be used because they have high liquidity. However, it is believed that when FRA's traded on the system reach a high level of liquidity, they should be used instead. [0325]
  • When calculating zero points from the futures, the processed price, the future basis (number of days in a year that the future is based on), the start date of the future, the end date of the future and the zero point of the start date are needed. This data about the future will come from the preprocessor which is used to represent the future. The zero point at the start date is found from previous zero points through interpolation. The following equation for z(e) is the zero rate at the end date of the future. [0326] z ( e ) = [ ( 1 + futRate * e - s futBasis ) ( 1 + z ( s ) ) s 365 ] 365 e - 1
    Figure US20030093360A1-20030515-M00006
  • where futBasis is the number of days in a year that the future is based off, futRate is the processed price of the future, e is the end date minus current date, and s is the start date minus the current date. [0327]
  • The calculation of the FRA zero points is the same as for the futures except that the processed price for the FRA and the FRAbasis are used instead of the processed price for the future and the futurebasis. The information about the FRA will come from the preprocessor. The following equation for z(e)[0328] fra is the zero rate at the end date of the FRA: z ( e ) fra = [ ( 1 + fraRate * e - s fraBasis ) ( 1 + z ( s ) ) s 365 ] 365 e - 1
    Figure US20030093360A1-20030515-M00007
  • The rest of the zero curve will be derived from swap information. For the first swap, the zero curve and the discount factor at each coupon date are used to calculate the zero rate and the end date in the swap using the equation below for Z(t[0329] n). When calculating other swap zero points, gaps may exist in the zero curve. Synthetic swap rates are calculated where gaps exist to improve accuracy. The calculation of a normal swap rate and a synthetic swap rate are the same. The following equation for Z(ti) is the zero rate at the particular coupon date: Z ( t n ) = [ 1 + swapRate * Y ( t n - 1 , t n 1 - swapRate * i = 1 n - 1 Y ( t i - 1 , t i ) ( 1 + Z ( t i ) ) t i 365 ] 365 / t n - 1.
    Figure US20030093360A1-20030515-M00008
  • where swapRate is tradePriceAdjust, t[0330] i represents a coupon date, and Y(tn−1,tn) is the period in years between the two coupon dates. Once the trades have been executed and the term negotiation process completed, the system will initiate an automatic confirmation process which, in an embodiment of the present invention, will follow existing market practices. Accordingly, the system 10 will automatically send a fax confirmation message to each counterparty detailing the transaction. The faxes should be sent immediately after a transaction is completed. The confirmations should follow a unique format, allowing the automatic transfer of these confirmations electronically.
  • This confirmation has been specially developed to allow for a standard format covering all classes of financial contracts. The standard confirmation follows the following format: [0331]
  • Section [0332] 1: Summary of the transaction.
  • Section [0333] 2: Counterparty details and commission.
  • Section [0334] 3: Transaction details.
  • Section [0335] 4: Term negotiation
  • This provides the users with adequate information to identify and/or record the transaction. The conformation, however, may be sent to the traders any number of ways such as via e-mail, voice-mail, United States Postal Service, or commercial carrier (e.g., FedEx, UPS, etc.). Further, it is noted that the information provided can take many other formats within the scope of the present invention. [0336]
  • While the various interfaces to [0337] system 10 have been described herein as individual windows, it is noted that multiple windows can be integrated to form a main screen 480 with multiple frames, as illustrated in FIG. 23. For instance, a tools area 432 provides the trader with a set of customized tools including graphs, market quotes, bond prices to yield converters, pricing tools, and MarketSheet™ applets. A service area 484 provides various interfaces as described above on a temporary basis. A message center 486 displays the most recent RFP, RFS, Chat and administrative messages, and is preferably configured as a drop-down window to display multiple current messages. A status bar 488 displays user status information. A workspace area 490 provides for the entering of data into dialog boxes in a non-intrusive manner, plus the execution of the data function. A warehouse area 492 stores the most commonly used interfaces in a tabbed format, allowing the trader to retain their preferred set-up between sessions. Accordingly, the main screen 480 provides enhanced functionality by integrating multiple interfaces in a single window.
  • IV. Operation [0338]
  • As described above, the [0339] system 10 comprises the central processing center 12 that may includes multiple servers connected via an Internet-protocol network to the individual counterparties trader workstation 20 which may be desktop computer workstations. Because of the open system architecture of the system 10, the present invention may run within the context of the internet browser 72 on the user's existing desktop computer 20. The desktop computer 20 preferably includes an operating system platform for which a Java-enabled Internet browser is available.
  • In order to provide the counterparties with anonymous credit preference based trading capability for a wide range of financial contracts where each side enters into a long-term contract with the others, the present invention is designed to be flexible enough to reflect several different measures of credit risk, as generally described below with reference to FIG. 24. [0340]
  • With reference to [0341] flowchart 502 of FIG. 24, each business unit (counterparty) provides the group server 32 (FIG. 2) with detailed credit preferences for each potential counterparty business unit's legal entity. The group server 32 then distributes the credit preference information in an anonymous format to the trade workstation 20 which uses the credit preferences of each active business unit (counterparty) in the system 10 to prescreen the user's market orders (bids and offers) against the other counterparties' market orders. Thus, the credit preference module 76 (FIG. 3) of each trader receives the credit preference information defined by a first user with respect to a second user, as indicated by block 504. The credit preference module 76 then receives the credit preference information from the second user with respect to the first user, as indicated in block 506. The credit preference module 76 then determines which orders, on which financial instruments, and with which counterparties, the user can deal. This information is coding on the posted prices utilizing color or another notational method such as symbols, as indicated in block 508.
  • In accordance with an aspect of the present invention, the prescreening is a complex check to determine whether two particular counterparties will accept each other for a particular class of financial instrument, for a particular amount and for a particular maturity. This is a risk equivalent measurement, and is more than a simple yes/no preauthorization matrix. More specifically, because each financial instrument has different credit qualities, it is possible for a particular counterparty to be willing to accept another particular counterparty for one type of financial instrument but not another. Furthermore, it is also possible that a particular counterparty may accept the other for a particular financial instrument, but only for a certain length of time (i.e., maturity). The [0342] system 10 may also allow the user to accept counterparties for different amounts at different maturities.
  • It is further noted that the [0343] system 10 divides counterparties into legal entities. These legal entities may be further divided into individual business units. So, for example, Bank A may be a legal entity (counterparty) and Bank A might have a different business unit in three different cities (e.g., Tokyo, London, and New York). In this example, the counterparty credit information is available at the legal entity level. So, for instance, if Bank A wishes to allow each of its business units to set their own credit preferences for other counterparties, then these credit preferences will be listed against the legal entity level of all the other business units. In other words, business unit A at Bank A can not say it will trade with desk A of Bank B but not desk B of Bank B. The system 10 allows business units within a particular legal entity to inherit the credit preferences from other business units in the same legal entity family, if so desired.
  • Once each business unit has inputted their individual credit preferences, this credit preference information is maintained locally at the [0344] inputting trader workstation 20, and transmitted to the group server 32 of the central processing center 12. The central processing center then transmits a vector of encoded credit preference data to each user logged on, wherein the data represents that preferences of the user to the other legal entities and the preferences of other business units to that user's legal entity for the affected instrument classes. The encoded vector of credit preference data is accessible to any of the trader workstations 20 in the system 10; however, the sensitive credit information of other counterparties is not available.
  • Once the user has inputted his/her business unit's credit preferences, the user is then able to select or filter messages on which financial instruments and in which currencies the user wishes to receive updates, messages and prompts. The filters can be selected via the [0345] user preference interface 148 to customize the order information presented by the command center interface 130. This screening capability is provided to the user in order to prevent him from being overwhelmed by, and to sort through, the possibly thousands of different financial instruments in up to or more than 14 different currencies that the system 10 has the ability to handle. Once these filters have been inputted into the system 10, the user is able to view trading information on the currencies and financial instruments that have been selected for the user. This means, for example, that if the user has selected US dollars only, then the user will preferably not see information on the Japanese Yen financial instruments which are in the system for trading.
  • Once the trading preferences of the user have been entered into the [0346] system 10, the user can proceed with trading. The user then activates the fully customizable, re-sizable market entry interface 250. The market entry interface 250 enables the user to input many different financial instruments which the user is interested in trading on one screen, and have any number of profiles wherein each profile is a collection of markets or a collection of financial contracts in the system 10.
  • A preferred embodiment accomplishes the inputting and referencing of the various financial instruments through the use of a unique set of symbols referred to as symbology. The symbology of the present invention is based on a concept of subject based addressing whereby the user creates a symbol to uniquely define any one of many complex financial instruments. The symbol denotes the financial instrument's parameters and attributes. The standardized symbology of the present invention is designed such that the users of the [0347] system 10 will recognize the meaning of the symbol when the users view the symbols. To further help the users understand which financial instrument they are trading, a symbol may be identified by the full subject name, an alias (in the case of the most commonly traded instruments), or a unique identifier (e.g., such as a numeric code). In order to help the users use the symbology to properly express the financial instruments they want to trade, the system 10 allows the users to construct symbols utilizing the symbol construction interface 270 (FIG. 13).
  • The symbology of the present invention, as described below and as illustrated [0348] flowchart 510 of FIG. 25, enables a user to input data including a proposed trade of a financial instrument, wherein the financial instrument is advantageously defined by symbology comprising a source field, a class field, a symbol field and a currency field, as indicated by block 512. This abbreviated format for identifying a financial instrument can then be easily transmitted to other users within the system 10, as indicated by block 514. At the receiving users trader workstation 20, the proposed trade can be viewed by the traders utilizing the symbology, as indicated by block 516. By defining the financial instrument using the symbology of the present invention, the users can exchange a small amount of data that is translatable into a detail description of a financial instrument that is relatively complex. This reduces communication and processing overhead of the system 10 and simplifies the user's efforts.
  • Once the orders have been inputted via the symbology, the [0349] market entry interface 250 displays the best bid and best offer for each instrument, as well as the sum quantity available to trade at the best price and other relevant information. The order information (i.e., the bids and offers for each instrument) is coded with the relevant credit preferences, unless several prices are currently posted at the same price but have different credit status, in which case the market detail interface 302 should be used. This is significantly different from some prior art systems which only show the best dealable price. The system 10 presents the best price, irrespective of credit preferences or credit limits. From market entry interface 250, it is possible for the user to execute a trade directly if the credit preferences of both parties permit. The user may also place a passive order from the market entry interface 250.
  • The user also has the option of activating a [0350] market detail interface 302 which enables a user to see the complete picture (i.e., depth) of all the orders (e.g., bids and offers) available on a particular financial instrument, coded with credit preference information. The market entry interface 250 and the market detail interface 302 not only display the best bid and offer, but each individual order in the system 10 individually. Through the market entry interface 250 and the market detail interface 302, the user is provided the ability to select not just the best bid or offer, but any bid and offer in the system 10. This is important because for credit reasons, the viewing counterparty may not wish, or may not be allowed to, trade a particular bid or offer. This means that the best bid or offer in the system 10 is not necessarily the best bid or offer available to that counterparty.
  • The credit preference information entered in the [0351] system 10 by each user, as described above, is used by both the central processing center 12 and the transmitting business unit servers 18 to prescreen the bids and offers, and to market orders in the system 10 before they are viewed at the trader workstations 20 of the respective client sites 14. The sensitive credit preference that indicates which counterparties are acceptable, and under what terms, is preferably maintained at the transmitting trader workstation 20 and the central processing center 12. The other viewing users do not receive or have access to the credit information of the other users. At the receiving business unit's server 18, a check is performed to determine whether the receiving client site 14 will accept the particular bid or offer from the transmitting legal entity. The summary and relevant data is transferred in an encrypted form to trader workstations 20. The credit check may be re-performed at the time of a transaction by the central site 14 and/or the central processing center 12.
  • The credit preference screening of the present invention enables the display of all passive orders in the [0352] system 10 and their relevant credit status with regard to the viewer on both the market entry interface 250 and the market detail interface 302 as follows: 1) green—this means that the viewer accepts the posting counterparty, and the posting counterparty accepts the viewing counterparty; 2) yellow—this means that the viewing counterparty will accept the posting counterparty but that the posting counterparty will not accept the viewer; 3) red—that the viewer will not accept the poster; 4) blue—that the bid or offer being looked at is the viewer's own; 5) white—used on the market entry interface 250 to denote when two or more orders are placed at the same price but with different credit preferences. The use of color coding enables the system 10 to preserve the anonymity of the users while still enabling the viewing business units to receive credit information about the bids and offers they are viewing. In the event the user is color blind, the system 10 also includes the option to display small symbols next to each price to indicate the relevant credit status to the viewer.
  • If the viewer wants to trade a green bid or offer, then the system will permit this to be executed right away. Further, if the active counterparty to the transaction, that is, the viewer who hit the bid or lied the offer, chooses to execute the full size of the amount on offer or bid and there are no more orders at the same price, the viewer will be prompted with the ability to ask the other counterparty to do more. This will-do-more feature is preferably restricted to a predetermined time-limit in which the receiver of the request must respond. The receiver of the request may agree to accept the increased quantity (or part of the increased quantity) at the previously agreed to price or the request will lapse. The will-do-more feature may be repeated as many times as the users desire. The will-do-more feature does not necessarily check credit preferences once this process has begun because both users know the identities of each other at this point. This forces the users to take responsibility for further credit approval beyond the point of the initial trade amount. [0353]
  • If the order being viewed by the user is yellow, then the viewer will accept the poster but the poster will not accept the viewer. In this case, the [0354] system 10 enables the viewer to send a credit override message to the poster of the bid or offer whereby the sender of the credit override reveals his/her identity to the poster and asks the poster to reconsider whether or not the poster will do the requested trade with the viewer. In this case, the user which sent the credit override will be identified to the poster, but at no time will the sender of the credit override find out who they revealed themselves to. If the poster chooses to accept the credit override, then the poster may also choose to impose additional credit requirements on the viewer in order to accept the transaction. These additional credit requirements would be in the form of a standard mutual put clause in the confirmation of the trade. The viewer will have the opportunity to either accept or decline the additional credit requirements. The credit override function does not in anyway change the credit preferences which each user previously input into the system 10. The credit override is preferably on a per-transaction basis.
  • If the bid or offer viewed by the viewing trader is in red, then the viewer will not accept the poster. Despite the fact that the viewer knows he/she will not accept the poster, the viewer does not know which among the counterparties he/she will not accept is the poster. The viewer is thus not able to identify the poster, preserving the anonymity of the [0355] system 10. If the poster does not activate the credit override, then no trade will be able to take place.
  • If the bid or offer displayed is in blue, then the order is the poster's own order. The [0356] system 10 does not prevent different users within the same client site 14 from trading with each other.
  • From both the [0357] market entry interface 250 and the market detail interface 302, it is also possible for the user to send a request-for-price message to the other counterparties that are interested in the requested financial instrument. The request-for-price enables a user to anonymously broadcast to other interested market participants.
  • With reference to FIG. 26, a [0358] flowchart 520 generally describes the steps of a trade. Initially, the first user and the second user are provided with essentially real-time order information regarding more than one financial instrument typically via the market entry interface 250, as indicated by block 522. The order information preferably includes a request to buy or sell a financial instrument such as an OTC derivative. At block 524, one of the first or second users initiates the trading process on an order selected from the order information provided by the other of the first or second users. The credit preference information of each user is then used to verify the trade eligibility of the first and second users with regard to one another based on the selected order, as indicated by block 526. One or both of the first and second users are then able to request an increase in the quantity of the order, as indicated by block 528. If an increase is requested, the request is process at block 530. Alternatively, if there is no request to increase the quantity at block 528, it is then determined that block 532 if there is a request to negotiate terms of the order, and more particularly, the noncommercial terms of the financial instrument underlying the order. If there is a request to negotiate terms by one of the users, then the request is processed at block 534. If there is not a request to negotiate terms, then an acknowledgment is sent to both users signifying the execution of the trade, as indicated by block 536.
  • The trade process as described above with reference to FIG. 26 can also be described from the perspective of the first and second users. For instance, with reference to FIG. 27A, a [0359] flowchart 540 generally depicts the steps of a trade from the perspective of a passive user. Initially, at block 542, the credit preferences of the user are inputted and distributed to the other users for effectuating the credit preference screening. At block 544, the user sends an order to system 10 for distribution to the other users requesting a trade on a financial instrument. The user that placed the order must then wait for another trader to hit or lift the passive order, thereby executing the trade. Both parties to the trade will receive an execution notification which will allow one or both users to request an increase in quantity, as determined by block 548. If this request is received from the party hitting or lifting the passive order, the first user accepts, denies, or amends the requested increase, as indicated by block 550. If there is no request to increase a quantity, then it is determined at block 552 whether there is a request to negotiate terms of the financial instrument. This feature allows the users to change the default values for the non-commercial terms of the facial contract, as indicated by block 554. Next, the first user will receive an acknowledgment of the execution of the trade with the second trader, as indicated by block 556.
  • With reference to FIG. 27B, a [0360] flowchart 560 generally illustrates the steps of a trade from the perspective of the active user that lifted or hit the passive order. At block 562, the second user receives an order from the first user requesting a trade on a financial instrument. The order is then checked for trade eligibility based upon the credit preferences of the first and second users, as indicated by block 564. The order is coded with appropriate credit information based upon the credit check, as indicated by block 566. The coded order is then presented to the second user based upon a preference or filter set by the second user to view orders of the present instrument, as indicated by block 568. The second user then initiates a trade by lifting or hitting the order, as indicated by block 570. In block 572, it is determined if there is a request to increase quantity. If there is not a request to increase quantity, then the request is processed at block 574. If there is not a request to increase the quantity, then it is determined at block 576 whether there is a request to negotiate terms of the financial instrument. This feature allows the users to change the default values for the non-commercial terms of the financial contract, as indicated by block 577. Next, an acknowledgment is received by the first and second users indicating that the trade has been executed, as indicated by block 578.
  • Another feature of the present invention is the position discovery as illustrated by a [0361] flowchart 580 of FIG. 28. At block 582, risk position portfolios are received from the users of system 10. At block 584, relative position information is calculated for each user so that each user may be presented with possible trading combinations for their portfolios, and combinations of their portfolios against positions from the other users. The possible trading combinations are coded with credit preference information in accordance with the present invention. It is then determined at block 586 if a switch is requested. If a switch is not requested, then the process ends. However, if a switch is requested at block 586, then a switch is executed at block 588. The execution of the switch is performed in substantially the same manner as any other trade, as described above. Upon execution of the switch, the position information of each party to the switch is automatically updated to reflect the switch, as indicated by block 590.
  • A blotter is provided to enable the user to keep track of all the orders he/she has inputted into the market. The blotter is preferably a screen whereby once it is activated, it displays all the outstanding orders a user has in the system. The blotter enables the user to monitor all his/her outstanding orders in many different instruments conveniently in one place. Preferably, there are two types of blotters. The first is the [0362] outstanding order blotter 320 which offers several functions to the user for managing his/her orders, such as the ability to change the price, or size of an order. This is accomplished through the use of dials on the windows which enable the user to quickly dial up or down the price without needing to cancel and then re-submit the order. This edit process shields the user from the complexity of order management regarding changed orders. This also prevents the user from accidentally having duplicate or no orders in the system 10. The outstanding order blotter 320 also enables the user to quickly suspend (or refer) all of his/her active orders in the system 10, and then re-input them one by one or delete them as necessary. Yet further, the outstanding order blotter enables the trader to cancel one or all of his orders. The second type of blotter is the historical order blotter 330. From the historical order blotter, it is possible for the user to view all of his/her previously executed trades and the respective status, as well as those that have been canceled.
  • In order to address the needs of interest rate swap traders and portfolio managers, the [0363] system 10 may include a function known as the switch engine. The switch engine is implemented by a switch interface 400 and enables the user to input an entire portfolio of interest rate reset risks into the system 10, and then view out into the future for an unlimited time horizon on a daily basis. In a preferred embodiment, the user inputs the size (in millions) and the direction (receiving or paying) of the reset risks portfolio into the system 10 on a wide range of the most common interest indices (i.e., 1 month US dollar libor, 3 month US dollar libor, 1 month DEM libor, etc.). The portfolio can be input either directly through the portfolio interface 380 (FIG. 21), or by uploading a file with the required information. Once the information has been input into the system 10, the user is then asked to confirm the input. Once this information has been confined, the user then has the ability to anonymously look at his/her interest rate reset risk position relative to all other counterparties who have inputted such information to determine based upon credit preferences, which trades are available to him/her in the system 10 to off-set his/her interest rate reset risks. Once the user has located these trades, the user can then anonymously send a request-for-switch to the other counterparties in an attempt to initiate a trade.
  • The [0364] system 10 further provides the functionality to permit the trading of various financial instruments via an auction function, as generally illustrated in a flowchart 600 of FIG. 29. The system performs what is referred to herein as a two way Dutch auction with credit preferences. In this auction methodology, users submit orders into the auction giving both the price and the quantity at which they wish to trade, as indicated by block 602. The auction process then begins by calculating the price at which the most volume is traded, as indicated by block 604. This is called the auction-price. The auction-price is a fair price at which all transactions will be completed. In this calculation, the credit preferences of the various counterparties are not yet taken into account. At block 606, the system matches up orders such that all credit preferences are taken into account such that the minimum number of tickets are generated. The better submitted prices have priority, and all orders at the auction-price are preferably filled in proportion to each other. In a preferred embodiment of the auction feature, the auction process could be conducted a few times a day in order to maximize liquidity. The system also offers the functionality to enable the user to trade forward rate agreement switches and other switch products in an auction environment similar to that described previously.
  • The system then automatically generates a confirmation for each transaction and sends it electronically via email, fax, or another means to the counterparties of each executed transaction, as indicated by [0365] block 608. This unique confirmation process has been designed to use a standard and consistent format for all financial instruments.
  • At this point, a more detailed description of the operation and functionality of the [0366] auction mechanism 34 is provided. With reference to FIG. 30, the auction mechanism 34 initially receives an order list from those traders wishing to participate in an auction, as indicated by block 620. The orders within the order list are separated into a BuyList and SellList, as indicated by block 622. At block 624, a price list is generated and sorted from highest price to lowest price. It is then determined at block 626 whether an auction will take place by determining if the price list is empty. If the price list is empty, then no auction takes place, as indicated by block 628. If the price list is not empty, then the average auction price is calculated, as indicated by block 630, and as described in greater detail with reference to FIG. 31. Next, the orders are matched such that the minimum number of tickets are generated, taking into account the credit preferences of all parties, as indicated by block 632, and as described in greater detail with reference to FIGS. 32A and 32B. Once the orders have been matched, a settlement list is generated, representing the execution of transactions via the option, as indicated by block 634.
  • With reference to FIG. 31, the average auction price is calculated. In particular, beginning at block [0367] 640, the initial parameters are established, such as i=1, j=1, difference equal s1−b1, k=2, and N=size of price list. In addition, the total amount in the BuyList is Bi, and the total amount in the SellList is SN−i+1. Next, it is determined at block 642 whether k=N+1. If so, then the average auction price is PI. If it does not, then it is determined at block 644 whether difference is greater than 0. if it is, then parameter j is set to j=j+1, the parameter difference is set to difference=difference+BJ, and the parameter k is set to k=k+1, as indicated by block 646. If not, then the parameter i is set to equal i=i+1, the parameter difference is set to difference=difference+Si, the parameter k is set to k=k+1, as indicated by block 646. The steps of block 642-648 are repeated until determination is made at block 642 that k=n+1.
  • With reference to FIG. 32, the step of matching orders in an auction is described in greater detail. In particular, items in the Buylist and SellList are eliminated according to the average auction price, as indicated by [0368] block 650. It is then determined at block 652 whether the size of BuyList is greater than zero and the size of SellList is greater than zero. If one or the other is not greater than zero, then the settlement list is generated, as indicated by block 654. If both the BuyList and SellList are greater than zero, then the parameter Bsum is set to equal the total volume in BuyList and Ssum is set to equal the total volume in SellList, as indicated by block 656. It is then determined at block 658 if Ssum is greater than the Bsum. If it is, then the parameter list1 is set to equal SellList and the parameter list2 is set to equal BuyList, as indicated by block 660. Next, the order1 parameter is set to equal to the first order in list1 and order1 is removed from list1, as indicated by block 662. The maximum/minimum and credit rules are then applied to search the BuyList for matching order2. A matching order2 is located and a trade is generated between order1 and order2, as indicated by block 666. If at block 668 it is determined that Ssum is not greater than Bsum, then parameter list1 is set to equal BuyList and list2 is set to equal SellList, as indicated by block 668. Next, orderl is set to equal the first order in list1 and order1 is removed from List1, as indicated by block 670. Next, list2 is searched in order to find a match to order1 using the maximum-minimum rule and the credit preferences associated with the orders, as indicated by block 672 and described in greater detail with reference to FIG. 33. A trade is then generated between order1 and order2, as indicated by block 674.
  • With reference to FIG. 33, the application of the maximum-minimum rule and credit rules satisfying an order are described in greater detail. Initially, it is noted that the parameter volume is equal to the volume of an order, and more particularly, of order[0369] 1. At block 680, it is initially determined whether the parameter volume equals 0 for order1. If it does not equal zero, then it is determined at block 682 whether list2 is empty. If list2 is not empty, then list2 is searched for the first matching order, as indicated by block 684. Once a matching order is located, then the volume traded will equal to the minimum as defined by the credit preferences of either party, the volume of order1, or the volume of order2, as indicated by block 686. It is then determined if the trade volume is 0, as indicated by block 688. If the trade volume is 0, then the process begins again at block 680. If the trade volume is not equal to 0, then a trade is generated and placed in the settlement list, as indicated by block 690. In addition, at block 692, order2 is removed from list2. Next, the volume of order1 and order2 are updated by setting the respective volumes to the previous volumes minus the trade volume, as indicated by block 694. It is then determined at block 696 if the volume of order2 is equal to zero. If it is not, then order2 is placed back in a temporary list and a credit of the parties placing order1 and order2 are updated, as indicated by block 698. Once the volume of order1 is determined to be zero, then it is determined at block 702 whether the temporary list is empty. If it is not, then the temporary list is merged with the BuyList, as indicated by block 704. Subsequently, the process ends.
  • The operation of the [0370] central processing center 12 is now generally described with reference to FIG. 34 which functionally depicts the group server mechanism 32, the auction mechanism 34 and switch mechanism 35, the market inventory module 38, the execution module 40, and the settlement module 42. A legend 710 is provided to the denote the flow of the different orders, interactive and switch orders, auction orders, and switch auction orders, between the group server mechanism 32, the auction mechanisms 34, the market inventory module 38, the execution module 40, and the settlement module 42. Beginning with the interactive/switch order generated by the user at one of the trader workstations 20, the central processing center 12 initially receives the interactive/switch order 712 at the group server mechanism 32. At the group server mechanism 32, an order record is created, the credit preferences of the users are checked to assure the trade conforms to the current credit preferences of the users, and a transaction order is created. If the order is passive, then it flows through to the market inventory module 38 where is it distributed to the trader workstations 20 for viewing via respective market detail interfaces 302 of the users logged on the system 10. If the order is active, then it flows through to the market inventory module 38 where order matching occurs if the order is a part of an auction, and pre-execution of the order also occurs. Pre-execution may include, for instance, a back-end credit check to ensure up to date credit preferences and to accommodate complex checks. Further, in a manner that is transparent to the users, the market inventory module 38 requires the trader workstations 20 of the respective users that are a party to the trade to respond with an acknowledgement to assure that there has been no loss of communication or that one of the users has not logged off. Upon receiving the acknowledgement, the market inventory module 38 executes the trade and then publishes the updated volume and status to the users logged on to the system 10 for viewing via respective command center interface 130 of the users.
  • Next, the [0371] execution module 40 will, upon request of one of the users that were a party to the trade, enables the quantity of the trade to be increased via the will-do-more feature. This will typically be the case unless the full quantity of the instrument is transacted. Otherwise, the execution module will initiate the confirmation process which includes an opportunity for either of the users that were a party to the trade to enter into term negotiations.
  • The order the flows through to the [0372] settlement module 42 which initiates the settlement process. The settlement module allows for symbol explosion by the users to view the exact terms of the contract. Further, a settlement module calculates the commission based upon the order which ends the process, thereby noting the end of the order execution process.
  • In the case of an auction, an [0373] auction order 714 received by the auction mechanism 34. The auction module 34 enables auction and switch auction functionality of the present invention. The auction module initially receives the auction orders 714 a from a plurality of users during a countdown to the actual auction time. Once the auction time has arrived and the auction orders have been submitted, the auction mechanism 34 performs the auction matching with credit preferences of the users taken into account. The auction matching performed by the auction mechanism 34 is in accordance with the present invention, that is, the auction is based on a fair price and executed for a maximum volume traded with a minimum number of tickets generated. From the auction mechanism 34, once the counterparties have been matched the market inventory server essentially treats the resulting auction orders as though it would an interactive/switch order 712. In particular, the market inventory module 38 perform order matching, pre-execution, acknowledgement, trade execution and volume/data publishing.
  • The [0374] auction order 712 is then delivered to the execution module 40. At the execution module 40, an auction order and a switch auction order are traded slightly different. For instance, an auction order may be increased in quantity by one of the users that is a party to the auction order via the will-do-more. On the other hand, switch auction orders do not make use of this feature, but will go directly to the confirmation process. Further, where auction orders may also have their non-commercial terms negotiated using the term negotiation feature, switch auction orders will flow to the settlement module 42 directly after confirmation. Both auction orders and switch auction order are then received by the settlement module 42 which performs essentially the same operations to the auction order as it does to an interactive/switch order 712. Specifically, the settlement order 42 provides similar explosion and commissioned calculations which complete the order process.
  • In the drawings and specification, there have been disclosed typical preferred embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims. [0375]

Claims (44)

Wherefore, the following is claimed:
1. A system for facilitating derivative trading, comprising:
a communications network operationally interconnecting a first trader and a second trader to a central processing center;
a market module associated with said central processing center that provides said first and second traders with essentially real-time order information regarding more than one financial instrument, said order information including requests to buy financial instruments and requests to sell financial instruments;
a trader module associated with each of said first and second traders for receiving said real-time order information from said central processing center and presenting said real-time order information to said first and second traders according to trader customized profiles;
a credit preference module associated with each of said first and second traders, said credit preference modules indicating trade eligibility of respective said first and second traders for each of said requests to buy and said requests to sell; and
an execution module associated with said central processing center that processes a trade initiated by one of said first and second traders which desires to trade on an order posted in said order information by the other of said first and second traders.
2. The system of claim 1, wherein said credit preference module determines trade eligibility based on credit preferences of both said first and second traders.
3. The system of claim 2, wherein each of said first and second traders provides said credit preference module with credit preference information regarding the other of the first and second traders.
4. The system of claim 3, wherein said credit preference information includes a multi-rule measurement of credit risk.
5. The system of claim 1, further including a switch module that receives interest rate swap positions from said first and second traders, and determines relative position information for said first and second traders.
6. The system of claim 5, wherein said switch module takes into consideration credit preference information provided by each of said first and second traders when determining said position information, whereby said position information includes potentially offsetting positions.
7. The system of claim 1, wherein said trader module presents said order information utilizing instrument symbology.
8. The system of claim 1, wherein said execution module generates an acknowledgment at completion of a trade between said first and second traders.
9. The system of claim 1, wherein said order information is available for a definable period set by one of said first and second traders which posted said order information.
10. The system of claim 1, wherein said execution module enables said first and second traders to negotiate non-commercial terms of a trade based on said order information.
11. The system of claim 1, wherein said execution module provides said one of said first and second traders that initiated a trade based on said order information an option to request a larger quantity order.
12. A system for facilitating derivative trading, said system having a plurality of interconnected trader nodes that exchange order information, each trader node comprising:
a trader module that receives real-time order information and presents said real-time order information to a trader according to customized profiles defined by said trader;
a credit preference module that includes credit preference data inputted by said trader for use in determining trade eligibility of trades proposed in said real-time order information with a second trader; and
an interface to a communications network that interconnects said plurality of trader nodes.
13. The system of claim 12, wherein said credit preference module includes a multi-rule measurement that enables credit rating based on instrument maturity.
14. The system of claim 12, wherein said trader module includes a plurality of selectable trader definable formats that said real-time order information can be presented.
15. The system of claim 14, wherein said trader definable formats include a market entry interface that provides trading information on a trader defined list of financial instruments, and a blotter interface that provides order information of said trader.
16. The system of claim 14, wherein said trader definable formats include a market detail interface that includes system wide orders on a specified financial instrument.
17. The system of claim 12, wherein said trader module presents said order information utilizing instrument symbology.
18. The system of claim 12, further including a switch module that receives interest rate swap positions from said trader and said second traders, and that determines relative position information for said trader.
19. A system for facilitating derivative trading, said system having a plurality of interconnected first and second traders that exchange order information, each of said first and second traders connected to a central processing center, said central processing center comprising:
a market module that provides said first and second traders with essentially real-time order information regarding more than one financial instrument, said order information including requests to buy financial instruments and requests to sell financial instruments;
an execution module associated with said central processing center that can process a trade initiated by one of said first and second traders which desires to trade on an order proposed in said order information by the other of said first and second traders; and
an interface to a communications network that interconnects said plurality of first and second traders to said central processing center.
20. A computer program product for use with a data processing system for facilitating derivative trading, said computer program product comprising:
a computer usable medium having computer-readable code means embodied in said medium, said computer-readable code means comprising:
a trader software module for receiving real-time order information and presenting said real-time order information to a trader according to profiles customized by said trader; and
a credit preference software module for determining trade eligibility of proposed trades between said trader and a second trader, wherein said credit preference software module includes credit preference data inputted by said trader.
21. A computer program product for use with a data processing system for facilitating derivative trading, said computer program product comprising:
a computer usable medium having computer-readable code means embodied in said medium, said computer-readable code means comprising:
a market module that provides said first and second traders with essentially real-time order information regarding more than one financial instrument, said order information including requests to buy financial instruments and requests to sell financial instruments; and
an execution module associated with said central processing center that can process a trade initiated by one of said first and second traders which desires to trade on an order proposed in said order information by the other of said first and second traders.
22. A method for facilitating derivative trading between a first party and a plurality of potential traders including a second party, all of which are interconnected by a computer network, said method comprising the steps of:
inputting credit preference data on the potential traders for distribution to the potential traders;
sending an order from the first party to the potential traders requesting a trade on an instrument; and
receiving an acknowledgment from the second trader initiating a trade with the first trader on the order.
23. The method of claim 22, further comprising the step of receiving a request from the second trader to increase a quantity of the order.
24. The method of claim 23, further comprising the step of responding to the request for an increased quantity.
25. The method of claim 22, wherein said step of inputting credit preference data includes the step of rating each of the potential traders by a multi-rule measurement of credit risk.
26. The method of claim 22, further comprising the step of canceling the order.
27. The method of claim 22, further comprising the step of canceling all outstanding orders.
28. The method of claim 22, further comprising the step of or suspending all outstanding orders.
29. The method of claim 22, further comprising the step of presenting a blotter interface to the first trader that presents active orders of the first trader.
30. The method of claim 22, further comprising the step of presenting a blotter interface to the first trader that presents executed orders of the first trader.
31. A method for facilitating derivative trading between a first party and a second party, comprising the steps of:
receiving an order from the first party to the second party requesting a trade on an instrument;
checking the order for trade eligibility based on credit preferences of the first and second parties;
encoding the order with the appropriate information based on said step of checking the order;
presenting the encoded order to the second party based on a preference of the second trader to receive orders on the instrument; and
initiating a trade between the first and second parties if the second party initiates a trade.
32. The method of claim 31, further including the step of presenting the second party with order information regarding outstanding orders of the second party.
33. The method of claim 31, further including the step of presenting detail market information to the second party regarding market activity in a single financial instrument.
34. The method of claim 32, wherein said detailed market information includes quantity, bid price, ask price, and encoded credit preference information.
35. The method of claim 31, further including the step of presenting market entry information to the second party regarding financial instruments selected by the second party.
36. The method of claim 35, wherein said market entry information includes best bids, best asking prices, and encoded credit preference information.
37. The method of claim 31, further including the step of receiving an acknowledgment to the first and second traders if a trade is executed.
38. The method of claim 31, further including the step of querying the second party to determine if the second party would like to increase the quantity traded.
39. The method of claim 31, further including the step of negotiating non-commercial terms of the financial instrument traded.
40. The method of claim 31, further including the steps of receiving interest rate swap positions from the first and second parties, and determining relative position information for the first and second parties.
41. The method of claim 31, wherein the financial instrument is defined by an instrument symbology.
42. The method of claim 31, wherein said step of checking the order for trade eligibility includes the step of screening the order by maturity date.
43. A computer program product for use with a data processing system for facilitating derivative trading, said computer program product comprising:
a computer usable medium having computer-readable code means embodied in said medium, said computer-readable code means comprising:
computer readable code means for receiving an order from the first party to the second party requesting a trade on an instrument;
computer readable code means for checking the order for trade eligibility based on credit preferences of the first and second parties;
computer readable code means for encoding the order with the appropriate information based on said step of checking the order;
computer readable code means for presenting the encoded order to the second party based on a preference of the second trader to receive orders on the instrument; and
computer readable code means for initiating a trade between the first and second parties if the second party initiates a trade.
44. A computer program product for use with a data processing system for facilitating derivative trading, said computer program product comprising:
a computer usable medium having computer-readable code means embodied in said medium for facilitating derivative trading between a first party and a plurality of potential traders including a second party, all of which are interconnected by a computer network, said computer-readable code means comprising:
computer readable code means for inputting credit preference data on the potential traders for distribution to the potential traders;
computer readable code means for sending an order from the first party to the potential traders requesting a trade on an instrument; and
computer readable code means for receiving an acknowledgment from the second trader initiating a trade with the first trader on the order.
US10/166,565 1997-10-14 2002-06-10 Systems, methods and computer program products for electronic trading of financial instruments Abandoned US20030093360A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/166,565 US20030093360A1 (en) 1997-10-14 2002-06-10 Systems, methods and computer program products for electronic trading of financial instruments
US11/541,515 US20070219882A1 (en) 1997-10-14 2005-12-07 Systems, methods and computer program products for electronic trading of financial instruments

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US6241097P 1997-10-14 1997-10-14
US09/169,906 US6421653B1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for electronic trading of financial instruments
US10/166,565 US20030093360A1 (en) 1997-10-14 2002-06-10 Systems, methods and computer program products for electronic trading of financial instruments

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/169,906 Continuation US6421653B1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for electronic trading of financial instruments

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/541,515 Continuation US20070219882A1 (en) 1997-10-14 2005-12-07 Systems, methods and computer program products for electronic trading of financial instruments

Publications (1)

Publication Number Publication Date
US20030093360A1 true US20030093360A1 (en) 2003-05-15

Family

ID=22042311

Family Applications (14)

Application Number Title Priority Date Filing Date
US09/169,767 Abandoned US20020138390A1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for subject-based addressing in an electronic trading system
US09/169,906 Expired - Lifetime US6421653B1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for electronic trading of financial instruments
US09/169,878 Expired - Lifetime US6317727B1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for monitoring credit risks in electronic trading systems
US10/006,151 Abandoned US20020099651A1 (en) 1997-10-14 2001-11-08 Systems, methods and computer program products for monitoring credit risks in electronic trading systems
US10/166,565 Abandoned US20030093360A1 (en) 1997-10-14 2002-06-10 Systems, methods and computer program products for electronic trading of financial instruments
US10/277,624 Abandoned US20030229571A1 (en) 1997-10-14 2002-10-22 Systems, methods and computer program products for subject-based addressing in an electronic trading system
US10/377,254 Expired - Lifetime US7689497B2 (en) 1997-10-14 2003-02-28 Switch engine for risk position discovery in an electronic trading system
US10/395,710 Abandoned US20040015431A1 (en) 1997-10-14 2003-03-24 Systems for risk portfolio management
US10/408,764 Abandoned US20030220868A1 (en) 1997-10-14 2003-04-07 Methods for risk portfolio management within an electronic trading system
US11/175,585 Abandoned US20060095363A1 (en) 1997-10-14 2005-07-06 Systems and methods for performing two-way one-to-many and many-to-many auctions for financial instruments
US11/541,515 Abandoned US20070219882A1 (en) 1997-10-14 2005-12-07 Systems, methods and computer program products for electronic trading of financial instruments
US11/326,931 Expired - Fee Related US7571136B2 (en) 1997-10-14 2006-01-06 Methods for risk portfolio management within an electronic trading system
US12/692,253 Abandoned US20100179902A1 (en) 1997-10-14 2010-01-22 Systems and methods for performing two-way one-to-many and many-to-many auctions for financial instruments
US12/692,302 Abandoned US20100185559A1 (en) 1997-10-14 2010-01-22 Systems, methods and computer program products for electronic trading of financial instruments

Family Applications Before (4)

Application Number Title Priority Date Filing Date
US09/169,767 Abandoned US20020138390A1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for subject-based addressing in an electronic trading system
US09/169,906 Expired - Lifetime US6421653B1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for electronic trading of financial instruments
US09/169,878 Expired - Lifetime US6317727B1 (en) 1997-10-14 1998-10-12 Systems, methods and computer program products for monitoring credit risks in electronic trading systems
US10/006,151 Abandoned US20020099651A1 (en) 1997-10-14 2001-11-08 Systems, methods and computer program products for monitoring credit risks in electronic trading systems

Family Applications After (9)

Application Number Title Priority Date Filing Date
US10/277,624 Abandoned US20030229571A1 (en) 1997-10-14 2002-10-22 Systems, methods and computer program products for subject-based addressing in an electronic trading system
US10/377,254 Expired - Lifetime US7689497B2 (en) 1997-10-14 2003-02-28 Switch engine for risk position discovery in an electronic trading system
US10/395,710 Abandoned US20040015431A1 (en) 1997-10-14 2003-03-24 Systems for risk portfolio management
US10/408,764 Abandoned US20030220868A1 (en) 1997-10-14 2003-04-07 Methods for risk portfolio management within an electronic trading system
US11/175,585 Abandoned US20060095363A1 (en) 1997-10-14 2005-07-06 Systems and methods for performing two-way one-to-many and many-to-many auctions for financial instruments
US11/541,515 Abandoned US20070219882A1 (en) 1997-10-14 2005-12-07 Systems, methods and computer program products for electronic trading of financial instruments
US11/326,931 Expired - Fee Related US7571136B2 (en) 1997-10-14 2006-01-06 Methods for risk portfolio management within an electronic trading system
US12/692,253 Abandoned US20100179902A1 (en) 1997-10-14 2010-01-22 Systems and methods for performing two-way one-to-many and many-to-many auctions for financial instruments
US12/692,302 Abandoned US20100185559A1 (en) 1997-10-14 2010-01-22 Systems, methods and computer program products for electronic trading of financial instruments

Country Status (6)

Country Link
US (14) US20020138390A1 (en)
EP (1) EP1023684A1 (en)
JP (1) JP2001520421A (en)
AU (1) AU762863B2 (en)
CA (1) CA2305736A1 (en)
WO (1) WO1999019821A1 (en)

Cited By (117)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020188553A1 (en) * 2001-04-16 2002-12-12 Blauvelt Joseph P. System and method for managing a series of overnight financing trades
US20020198833A1 (en) * 2001-05-03 2002-12-26 Jacob Wohlstadter Method and system of exchanging and deriving economic benefit from exchanging securities
US20030009415A1 (en) * 2001-05-14 2003-01-09 Lutnick Howard W. Methods and systems for trading futures contracts for intangible assets
US20030033212A1 (en) * 1999-06-14 2003-02-13 Sandhu Harpal S. System and method for conducting web-based financial transactions in capital markets
US20030088499A1 (en) * 2001-06-01 2003-05-08 Gilbert Andrew C. Systems and methods for electronic trading that permit principal/broker trading
US20040030632A1 (en) * 2002-03-22 2004-02-12 Andrew Hausman Variable pricing for and conditional availability of proposals for trading of financial interests
US20040111356A1 (en) * 2002-05-17 2004-06-10 Vikas Srivastava Method and system for executing foreign exchange transactions
US20040148247A1 (en) * 2003-01-24 2004-07-29 Lawrence Miller Network-based systems, methods, and software for initiating or executing financial transactions
US20040199450A1 (en) * 2003-03-10 2004-10-07 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price
US20040199459A1 (en) * 2003-03-10 2004-10-07 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price and a hedge transaction
US20040230507A1 (en) * 2003-05-13 2004-11-18 Jeffrey Davidovitch Diversified fixed income product and method for creating and marketing same
US20040236668A1 (en) * 2003-03-25 2004-11-25 Toffey James Warden Method and system for effecting straight-through-processing of trades of various financial instruments
US20050010481A1 (en) * 2003-07-08 2005-01-13 Lutnick Howard W. Systems and methods for improving the liquidity and distribution network for illiquid items
US20050015324A1 (en) * 2003-07-15 2005-01-20 Jacob Mathews Systems and methods for trading financial instruments across different types of trading platforms
US20050027658A1 (en) * 2003-07-29 2005-02-03 Moore Stephen G. Method for pricing a trade
US20050044033A1 (en) * 2003-01-10 2005-02-24 Gelson Andrew F. Like-kind exchange method
US20050060256A1 (en) * 2003-09-12 2005-03-17 Andrew Peterson Foreign exchange trading interface
US20050080734A1 (en) * 2003-08-06 2005-04-14 Deutsche Bank Ag Method, system, and computer program product for trading diversified credit risk derivatives
US20050097026A1 (en) * 2003-11-04 2005-05-05 Matt Morano Distributed trading bus architecture
US20050097029A1 (en) * 2003-09-02 2005-05-05 Steven Cooper Timing mechanism and direct messaging for electronic trading platform
US20050137955A1 (en) * 2003-12-17 2005-06-23 Downie Alan D. Systems and methods for using a dedicated controller to facilitate foreign exchange pricing
US20050188378A1 (en) * 2003-06-06 2005-08-25 Miller Lawrence R. Integrated trading platform architecture
US6950806B2 (en) * 2000-11-02 2005-09-27 Cargill, Inc. Sales transactions for transfer of commodities
US20050222938A1 (en) * 2004-03-31 2005-10-06 Treacy Paul A System and method for allocating nominal and cash amounts to trades in a netted trade
US20050222937A1 (en) * 2004-03-31 2005-10-06 Coad Edward J Automated customer exchange
US20050234807A1 (en) * 2003-03-25 2005-10-20 Toffey James W Method and system for effecting straight-through-processing of trades of various financial instruments
US20050240513A1 (en) * 2004-04-15 2005-10-27 Michael Merold Electronic trading systems
US20050251478A1 (en) * 2004-05-04 2005-11-10 Aura Yanavi Investment and method for hedging operational risk associated with business events of another
US20050283417A1 (en) * 2004-06-03 2005-12-22 Douglas Miles Integrated trading information processing and transmission system for exempt securities
US20060010066A1 (en) * 2004-07-12 2006-01-12 Rosenthal Collins Group, L.L.C. Method and system for providing a graphical user interface for electronic trading
US6988083B2 (en) * 2000-11-02 2006-01-17 Cargill, Inc. Sales transactions for transfer of agricultural products
US20060031247A1 (en) * 2004-08-03 2006-02-09 Dharmesh Shah System and method for the secure processing of securities transactions
US20060095363A1 (en) * 1997-10-14 2006-05-04 Blackbird Holdings, Inc. Systems and methods for performing two-way one-to-many and many-to-many auctions for financial instruments
US20060253373A1 (en) * 2004-11-01 2006-11-09 Rosenthal Collins Group, Llc. Method and system for providing multiple graphic user interfaces for electronic trading
US7197483B2 (en) 2002-10-15 2007-03-27 Chicago Mercantile Exchange Network and method for trading derivatives by providing enhanced RFQ visibility
US20070088658A1 (en) * 2005-09-30 2007-04-19 Rosenthal Collins Group, L.L.C. Method and system for providing accounting for electronic trading
US20070088648A1 (en) * 2005-10-17 2007-04-19 Cqg,Inc. System and Method for Determining Data Points for Financial Bar Charts and Their Presentation
US20070118452A1 (en) * 2005-10-17 2007-05-24 Cqgt, Inc. Financial Instrument Trading Interface with Dynamic Price Scale
US20070118459A1 (en) * 2005-11-18 2007-05-24 Bauerschmidt Paul A System and method for centralized clearing of over the counter foreign exchange instruments
US20070118453A1 (en) * 2005-11-18 2007-05-24 Bauerschmidt Paul A Multiple quote risk management
US20070118455A1 (en) * 2005-11-18 2007-05-24 Albert William J System and method for directed request for quote
US20070208650A1 (en) * 2005-12-12 2007-09-06 Mcgill Bradley J System and method for creating, listing, and clearing flexible short term interest rate derivative instruments
US20070239591A1 (en) * 2000-06-09 2007-10-11 Blackbird Holdings, Inc. Systems and methods for reverse auction of financial instruments
US20070255643A1 (en) * 2006-04-27 2007-11-01 John Capuano Systems and methods for maintaining anonymity in a gaming or other environment
US20070265954A1 (en) * 2006-03-10 2007-11-15 Mather Timothy S graphical user interface trading widget for trading financial instruments
US20070265953A1 (en) * 2006-05-09 2007-11-15 Cunningham William D Smooth scrolling for software application
US20070271169A1 (en) * 2006-05-16 2007-11-22 Automated Trading Desk, Llc System and method for implementing an anonymous trading method
US20070282733A1 (en) * 2000-05-16 2007-12-06 Blackbird Holdings, Inc. Systems and methods for conducting derivative trades electronically
US20070288346A1 (en) * 1997-10-14 2007-12-13 May R R Systems for risk portfolio management
US20080027851A1 (en) * 2000-10-30 2008-01-31 Chicago Mercantile Exchange Network and method for trading derivatives
US20080086408A1 (en) * 2003-03-10 2008-04-10 Chicago Mercantile Exchange, Inc. Order Risk Management for Derivative Products
US20080086401A1 (en) * 2006-07-25 2008-04-10 Cqgt, Llc Charting with depth of market volume flow
US20080162378A1 (en) * 2004-07-12 2008-07-03 Rosenthal Collins Group, L.L.C. Method and system for displaying a current market depth position of an electronic trade on a graphical user interface
US7409367B2 (en) 2001-05-04 2008-08-05 Delta Rangers Inc. Derivative securities and system for trading same
US7409366B1 (en) * 2000-08-22 2008-08-05 Etp Holdings, Inc. Apparatus and method for adding liquidity to an ECN and improving executions of orders for securities
US20080270290A1 (en) * 1997-05-29 2008-10-30 Muniauction, Inc. Process and apparatus for conducting auctions over electronic networks
US20080275807A1 (en) * 2007-05-04 2008-11-06 Icap Management Services Limited Method and System for Offset Matching
US20080281750A1 (en) * 2003-03-25 2008-11-13 James Worden Toffey Method and system for administering prime brokerage
US20080288391A1 (en) * 2005-05-31 2008-11-20 Rosenthal Collins Group, Llc. Method and system for automatically inputting, monitoring and trading spreads
US20080288419A1 (en) * 2007-05-18 2008-11-20 Globalprivatequity.Com, Inc. Integrated trading and information system for collection and dissemination of valuation data
US20080313027A1 (en) * 2007-06-12 2008-12-18 Microsoft Corporation Fair discounting auction
US20090055303A1 (en) * 2007-08-20 2009-02-26 Chicago Mercantile Exchange, Inc. Out of band credit control
US20090132402A1 (en) * 2007-11-20 2009-05-21 Chicago Mercantile Exchange, Inc. Settling Over-The-Counter Derivatives Using Synthetic Spot Benchmark Rates
US20090164384A1 (en) * 2005-02-09 2009-06-25 Hellen Patrick J Investment structure and method for reducing risk associated with withdrawals from an investment
US7555456B2 (en) 2004-06-08 2009-06-30 Rosenthal Collins Group, Llc Method and system for providing electronic information for multi-market electronic trading
US20090171832A1 (en) * 2007-12-28 2009-07-02 Cunningham Trading Systems, Llc Method for displaying multiple markets
US20090187512A1 (en) * 2005-05-31 2009-07-23 Jp Morgan Chase Bank Asset-backed investment instrument and related methods
US7567928B1 (en) 2005-09-12 2009-07-28 Jpmorgan Chase Bank, N.A. Total fair value swap
US7584140B2 (en) 2003-10-15 2009-09-01 Chicago Mercantille Exchange, Inc. Method and system for providing option spread indicative quotes
US20090276373A1 (en) * 2004-06-08 2009-11-05 Rosenthal Collins Group, L.L.C. Method and system for providing electronic information for risk assesement and management for multi-market electronic trading
US20090276348A1 (en) * 2005-10-03 2009-11-05 Deborah Kessler Multiple protocol trading system
US7620586B2 (en) 2004-09-08 2009-11-17 Rosenthal Collins Group, Llc Method and system for providing automatic execution of trading strategies for electronic trading
US7620578B1 (en) 2006-05-01 2009-11-17 Jpmorgan Chase Bank, N.A. Volatility derivative financial product
US7647268B1 (en) 2006-05-04 2010-01-12 Jpmorgan Chase Bank, N.A. System and method for implementing a recurrent bidding process
US20100010937A1 (en) * 2008-04-30 2010-01-14 Rosenthal Collins Group, L.L.C. Method and system for providing risk assessment management and reporting for multi-market electronic trading
US20100049666A1 (en) * 2007-03-15 2010-02-25 James Tyler Trading analysis tools
US7680731B1 (en) 2000-06-07 2010-03-16 Jpmorgan Chase Bank, N.A. System and method for executing deposit transactions over the internet
US20100094777A1 (en) * 2004-09-08 2010-04-15 Rosenthal Collins Group, Llc. Method and system for providing automatic execution of risk-controlled synthetic trading entities
US7716107B1 (en) 2006-02-03 2010-05-11 Jpmorgan Chase Bank, N.A. Earnings derivative financial product
US20100145844A1 (en) * 2007-01-17 2010-06-10 Steidlmayer Pete Method for scheduling future orders on an electronic commodity trading system
US20100174633A1 (en) * 2009-01-08 2010-07-08 New York Mercantile Exchange, Inc. Determination of Implied Orders in a Trade Matching System
US20100223201A1 (en) * 2007-08-20 2010-09-02 Chicago Mercantile Exchange, Inc. Out of Band Credit Control
US7801810B2 (en) 2005-11-18 2010-09-21 Chicago Mercantile Exchange Inc. Hybrid cross-margining
US7801801B2 (en) 2005-05-04 2010-09-21 Rosenthal Collins Group, Llc Method and system for providing automatic execution of black box strategies for electonic trading
US20100241588A1 (en) * 2009-03-17 2010-09-23 Andrew Busby System and method for determining confidence levels for a market depth in a commodities market
US7818238B1 (en) 2005-10-11 2010-10-19 Jpmorgan Chase Bank, N.A. Upside forward with early funding provision
US7822682B2 (en) 2005-06-08 2010-10-26 Jpmorgan Chase Bank, N.A. System and method for enhancing supply chain transactions
US7827096B1 (en) 2006-11-03 2010-11-02 Jp Morgan Chase Bank, N.A. Special maturity ASR recalculated timing
US7849000B2 (en) 2005-11-13 2010-12-07 Rosenthal Collins Group, Llc Method and system for electronic trading via a yield curve
US20110012357A1 (en) * 2009-07-15 2011-01-20 Hong Fu Jin Precision Industry(Shenzhen) Co., Ltd. Tidal power generator
US20110035306A1 (en) * 2005-06-20 2011-02-10 Jpmorgan Chase Bank, N.A. System and method for buying and selling securities
US7890407B2 (en) 2000-11-03 2011-02-15 Jpmorgan Chase Bank, N.A. System and method for estimating conduit liquidity requirements in asset backed commercial paper
US20110055067A1 (en) * 2009-09-03 2011-03-03 Chicago Mercantile Exchange, Inc. Utilizing a trigger order with multiple counterparties in implied market trading
US20110066536A1 (en) * 2009-09-15 2011-03-17 Andrew Milne Ratio spreads for contracts of different sizes in implied market trading
US20110066568A1 (en) * 2009-09-15 2011-03-17 Andrew Milne Transformation of a multi-leg security definition for calculation of implied orders in an electronic trading system
US20110066537A1 (en) * 2009-09-15 2011-03-17 Andrew Milne Implied volume analyzer
US7966234B1 (en) 1999-05-17 2011-06-21 Jpmorgan Chase Bank. N.A. Structured finance performance analytics system
US8090639B2 (en) 2004-08-06 2012-01-03 Jpmorgan Chase Bank, N.A. Method and system for creating and marketing employee stock option mirror image warrants
US8229838B2 (en) 2009-10-14 2012-07-24 Chicago Mercantile Exchange, Inc. Leg pricer
US8352354B2 (en) 2010-02-23 2013-01-08 Jpmorgan Chase Bank, N.A. System and method for optimizing order execution
US8364575B2 (en) 2005-05-04 2013-01-29 Rosenthal Collins Group, Llc Method and system for providing automatic execution of black box strategies for electronic trading
US8429059B2 (en) 2004-06-08 2013-04-23 Rosenthal Collins Group, Llc Method and system for providing electronic option trading bandwidth reduction and electronic option risk management and assessment for multi-market electronic trading
US8548886B1 (en) 2002-05-31 2013-10-01 Jpmorgan Chase Bank, N.A. Account opening system, method and computer program product
US8589280B2 (en) 2005-05-04 2013-11-19 Rosenthal Collins Group, Llc Method and system for providing automatic execution of gray box strategies for electronic trading
US8626637B1 (en) * 2006-09-28 2014-01-07 Gfi Group, Inc. Apparatus, method and system for providing an electronic marketplace to join a trade for credit default swaps and other financial interests, and to deal-by-volume for the interests
US8688569B1 (en) 2005-03-23 2014-04-01 Jpmorgan Chase Bank, N.A. System and method for post closing and custody services
US8738514B2 (en) 2010-02-18 2014-05-27 Jpmorgan Chase Bank, N.A. System and method for providing borrow coverage services to short sell securities
US8756146B2 (en) 2007-08-20 2014-06-17 Chicago Mercantile Exchange Inc. Out of band credit control
US8756136B2 (en) 2002-08-02 2014-06-17 Jpmorgan Chase Bank, N.A. Synthetic funds having structured notes
US8762252B2 (en) 2007-08-20 2014-06-24 Chicago Mercantile Exchange Inc. Out of band credit control
US8781952B1 (en) * 2007-10-02 2014-07-15 Lucio Biase Systems, methods and computer software related to pooled credit risk and financial instrument allocation
US9811868B1 (en) 2006-08-29 2017-11-07 Jpmorgan Chase Bank, N.A. Systems and methods for integrating a deal process
US10049405B2 (en) 2008-03-10 2018-08-14 Tradeweb Markets Llc System and method for specified pool trading
US10346912B2 (en) 2013-03-15 2019-07-09 Tradeweb Markets Llc System and method for financial matching
US10832321B2 (en) 2003-12-12 2020-11-10 Gfi Group, Inc. Apparatus, method and system for providing an electronic marketplace for trading credit default swaps and other financial instruments, including a trade management service system
US11288739B2 (en) 2015-10-12 2022-03-29 Chicago Mercantile Exchange Inc. Central limit order book automatic triangulation system
US11526940B2 (en) 2000-10-31 2022-12-13 Integral Development Corporation System and method for conducting web-based financial transactions in capital markets

Families Citing this family (786)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
PT847561E (en) * 1995-08-28 2004-03-31 Ebs Dealing Resources Inc ANONYMOUS BROKER SYSTEM WITH IMPROVED POSSIBILITIES OF INTRODUCTION OF COTACOES
US5924083A (en) * 1996-05-29 1999-07-13 Geneva Branch Of Reuters Transaction Services Limited Distributed matching system for displaying a book of credit filtered bids and offers
US6850907B2 (en) 1996-12-13 2005-02-01 Cantor Fitzgerald, L.P. Automated price improvement protocol processor
US7870010B2 (en) * 1997-07-31 2011-01-11 Raymond Anthony Joao Apparatus and method for processing lease insurance information
US6725201B2 (en) 1997-07-31 2004-04-20 Raymond Anthony Joao Apparatus and method for providing insurance products, services and/or coverage for leased entities.
US6594643B1 (en) * 1997-11-14 2003-07-15 Charles C. Freeny, Jr. Automatic stock trading system
US6366899B1 (en) * 1998-02-26 2002-04-02 James J. Kernz Apparatus and method for accessing a coin image compilation
US6643666B1 (en) * 1998-02-26 2003-11-04 James J. Kernz Apparatus and method for accessing a coin image compilation
ATE243869T1 (en) 1998-03-03 2003-07-15 Amazon Com Inc IDENTIFICATION OF THE MOST RELEVANT ANSWERS TO A CURRENT SEARCH QUERY BASED ON ANSWERS ALREADY SELECTED FOR SIMILAR QUERIES
US7124129B2 (en) * 1998-03-03 2006-10-17 A9.Com, Inc. Identifying the items most relevant to a current query based on items selected in connection with similar queries
EP1105824A1 (en) * 1998-08-21 2001-06-13 Marketxt, Inc. A real-time computerized stock trading system
EP1116144A1 (en) 1998-09-11 2001-07-18 Ebs Dealing Resources, Inc. Communication of credit filtered prices in an electronic brokerage system
US6618707B1 (en) 1998-11-03 2003-09-09 International Securities Exchange, Inc. Automated exchange for trading derivative securities
US6405180B2 (en) * 1998-11-05 2002-06-11 International Securities Exchange, Llc Automated exchange for matching bids between a party and a counterparty based on a relationship between the counterparty and the exchange
EP1129439A1 (en) * 1998-11-11 2001-09-05 NCR International, Inc. Digital data interchange devices and networks
AU763571B2 (en) 1998-12-23 2003-07-24 Chase Manhattan Bank, The System and method for integrating trading operations including the generation, processing and tracking of and trade documents
ID30018A (en) * 1999-02-24 2001-11-01 Cha Min Ho METHODS AND AUTOMATIC BOOKING SYSTEMS FOR TRADING ITEMS, ITEMS, EXCHANGE OF GOODS, ARTICLES, OTHER INDEXS THAT WILL COME, OPTIONS OF ITEMS, EXCHANGE OF GOODS, OTHER ARTICLES,
US20040039663A1 (en) * 1999-02-26 2004-02-26 Kernz James J. Integrated market exchange system, apparatus and method facilitating trade in graded encapsulated objects
US7720742B1 (en) * 1999-03-01 2010-05-18 Ubs Ag Computer trading system method and interface
JP3976963B2 (en) * 1999-03-03 2007-09-19 富士通株式会社 Transaction support apparatus and recording medium
US7212999B2 (en) * 1999-04-09 2007-05-01 Trading Technologies International, Inc. User interface for an electronic trading system
US6993504B1 (en) * 1999-04-09 2006-01-31 Trading Technologies International, Inc. User interface for semi-fungible trading
EP1049036A2 (en) * 1999-04-29 2000-11-02 Citibank, N.A. System and method for web trading
US7392214B1 (en) * 1999-04-30 2008-06-24 Bgc Partners, Inc. Systems and methods for trading
GB9910588D0 (en) * 1999-05-08 1999-07-07 Tullett Financial Information Automated trading system
US7882011B2 (en) 2000-10-31 2011-02-01 Integral Development Corp. Systems and methods of conducting financial transactions
CN1451121A (en) * 1999-06-15 2003-10-22 Cfph有限责任公司 System and methods for electronic trading that provide incentives and linked auctions
US6629082B1 (en) * 1999-06-15 2003-09-30 W.R. Hambrecht & Co. Auction system and method for pricing and allocation during capital formation
US6392666B1 (en) * 1999-07-21 2002-05-21 Avaya Technology Corp. Telephone call center monitoring system allowing real-time display of summary views and interactively defined detailed views
GB2352599A (en) * 1999-07-22 2001-01-31 Churchill Risk Man Systems Ltd Market trading data display
US7107286B2 (en) * 1999-07-26 2006-09-12 Geoqwest International Inc. Integrated information processing system for geospatial media
US6681231B1 (en) * 1999-07-26 2004-01-20 The Real Estate Cable Network, Inc. Integrated information processing system for geospatial media
US7155410B1 (en) 1999-08-03 2006-12-26 Woodmansey Robert J Systems and methods for linking orders in electronic trading systems
US7685048B1 (en) 1999-09-01 2010-03-23 Bloomberg L.P. Electronic trading system for forwards spread trades
US8249962B1 (en) * 1999-09-07 2012-08-21 Garland Temple Stephens Method and system for determining, contracting to exchange, and accounting for matched sets of offsetting cash flows
US8407116B1 (en) * 1999-09-23 2013-03-26 The Nasdaq Omx Group, Inc. Quote/order processing in electronic market system
US8239303B2 (en) * 1999-09-23 2012-08-07 The Nasdaq Omx Group, Inc. Match-off of order flow in electronic market system
US7475046B1 (en) * 1999-10-05 2009-01-06 Bloomberg L.P. Electronic trading system supporting anonymous negotiation and indications of interest
US7571131B1 (en) * 1999-11-05 2009-08-04 Ford Motor Company Method of conducting online competitive price quoting events
US6876991B1 (en) 1999-11-08 2005-04-05 Collaborative Decision Platforms, Llc. System, method and computer program product for a collaborative decision platform
US6557007B1 (en) * 1999-11-15 2003-04-29 Pekowski Enterprises, L.P. Automated convention processing system and method
US8170924B1 (en) * 1999-12-08 2012-05-01 Harris Technology, Llc Real time auction with end game
KR20020067047A (en) * 1999-12-22 2002-08-21 씨에프피에이치, 엘. 엘. 씨. Systems and methods for providing a trading interface
JP3732699B2 (en) * 1999-12-27 2006-01-05 富士通株式会社 Electronic purchasing system and method
US7356498B2 (en) 1999-12-30 2008-04-08 Chicago Board Options Exchange, Incorporated Automated trading exchange system having integrated quote risk monitoring and integrated quote modification services
US9727916B1 (en) 1999-12-30 2017-08-08 Chicago Board Options Exchange, Incorporated Automated trading exchange system having integrated quote risk monitoring and integrated quote modification services
US7536335B1 (en) * 1999-12-30 2009-05-19 Bloomberg L.P. System and method for implementing foreign exchange currency forwards
AU2764101A (en) 2000-01-06 2001-07-16 Espeed, Inc. Systems and methods for monitoring credit of trading counterparties
US7430533B1 (en) * 2000-01-11 2008-09-30 Itg Software Solutions, Inc. Automated batch auctions in conjunction with continuous financial markets
AU2001229422A1 (en) * 2000-01-12 2001-07-24 Market Data Corporation System and method for facilitating trades in a trading system
US7233923B1 (en) * 2000-01-14 2007-06-19 Espeed, Inc. Systems and methods for matching desired purchases and sales of mis-matched items
US20010039530A1 (en) * 2000-01-18 2001-11-08 Annunziata Vincent P. Trading simulation
US8554659B2 (en) * 2000-01-21 2013-10-08 Tradecapture Otc Corp. System for trading commodities and the like
US20080215477A1 (en) 2000-01-21 2008-09-04 Annunziata Vincent P System for trading commodities and the like
US7346568B1 (en) 2000-01-26 2008-03-18 Robert Cadoux Serially staged, initial public stock offering method
SG97839A1 (en) * 2000-01-28 2003-08-20 Pi Eta Consulting Company Pte Fully flexible financial instrument pricing system with intelligent user interfaces
US7024383B1 (en) * 2000-01-31 2006-04-04 Goldman, Sachs & Co. Online sales risk management system
US7835970B1 (en) * 2000-02-02 2010-11-16 Cmvt, Llc Method and system for automated auction and tender of complex multi-variable commodities
US7162447B1 (en) * 2000-02-02 2007-01-09 Itg Software Solutions, Inc. Method and system for obtaining a discovered price
US7822656B2 (en) 2000-02-15 2010-10-26 Jpmorgan Chase Bank, N.A. International banking system and method
US7765133B1 (en) * 2000-02-16 2010-07-27 Omgeo Llc System for facilitating trade processing and trade management
GB2366630A (en) * 2000-02-17 2002-03-13 Gold On Line Trading Ltd Internet Trading System
GB0004190D0 (en) * 2000-02-22 2000-04-12 Game James D Indexation system for electronic addresses
US7318045B2 (en) * 2000-02-29 2008-01-08 Accenture Llp Event-driven trade link between trading and clearing systems
EP1531414A1 (en) * 2000-03-02 2005-05-18 Trading Technologies International, Inc A method and device for facilitating trading
US7447655B2 (en) 2000-03-02 2008-11-04 Trading Technologies International, Inc. System and method for automatic scalping of a tradeable object in an electronic trading environment
US7127424B2 (en) 2000-03-02 2006-10-24 Trading Technologies International, Inc. Click based trading with intuitive grid display of market depth and price consolidation
US6772132B1 (en) * 2000-03-02 2004-08-03 Trading Technologies International, Inc. Click based trading with intuitive grid display of market depth
US6938011B1 (en) 2000-03-02 2005-08-30 Trading Technologies International, Inc. Click based trading with market depth display
US7389268B1 (en) 2000-03-02 2008-06-17 Trading Technologies International, Inc. Trading tools for electronic trading
US7228289B2 (en) 2000-03-02 2007-06-05 Trading Technologies International, Inc. System and method for trading and displaying market information in an electronic trading environment
US7415436B1 (en) * 2000-03-08 2008-08-19 W. R. Hambrecht + Co., Llc System and method for pricing and allocation of commodities or securities
US7647270B2 (en) * 2000-03-08 2010-01-12 W.R. Hambrecht + Co., Llc System and methods for pricing and allocation of commodities or securities
US6731308B1 (en) * 2000-03-09 2004-05-04 Sun Microsystems, Inc. Mechanism for reciprocal awareness of intent to initiate and end interaction among remote users
US7979347B1 (en) 2000-03-16 2011-07-12 Goldman Sachs & Co. Automated online sales risk management
JP2001338233A (en) * 2000-03-24 2001-12-07 Sony Corp Electronic equipment, system and method for charging based on hours used, charging processor, recording medium and prepaid card
US20010037284A1 (en) * 2000-03-27 2001-11-01 Finkelstein Ephraim Brian Negotiated right exchange system and method
US7206762B2 (en) * 2000-03-28 2007-04-17 Regent Markets Group Ltd. Betting system and method
US6970931B1 (en) * 2000-04-03 2005-11-29 International Business Machines Corporation Method for translucent online interaction
US7392220B1 (en) * 2000-04-04 2008-06-24 Goldman, Sachs & Co. Seller risk auction platform
US7263506B2 (en) * 2000-04-06 2007-08-28 Fair Isaac Corporation Identification and management of fraudulent credit/debit card purchases at merchant ecommerce sites
US7006992B1 (en) * 2000-04-06 2006-02-28 Union State Bank Risk assessment and management system
US8775294B1 (en) 2000-04-10 2014-07-08 Stikine Technology, Llc Automated linked order processing
US7398244B1 (en) 2000-04-10 2008-07-08 Stikine Technology, Llc Automated order book with crowd price improvement
US7496533B1 (en) 2000-04-10 2009-02-24 Stikine Technology, Llc Decision table for order handling
US7890410B1 (en) 2000-04-10 2011-02-15 Stikine Technology, Llc Automated trial order processing
US7908198B1 (en) 2000-04-10 2011-03-15 Stikine Technology, Llc Automated preferences for market participants
US7774246B1 (en) 2000-04-10 2010-08-10 Christopher Keith Automated price setting for paired orders
US7644027B2 (en) * 2000-04-10 2010-01-05 Christopher Keith Market program for interacting with trading programs on a platform
US7882007B2 (en) * 2000-04-10 2011-02-01 Christopher Keith Platform for market programs and trading programs
US7813991B1 (en) 2000-04-10 2010-10-12 Christopher Keith Automated trading negotiation protocols
US8249975B1 (en) 2000-04-10 2012-08-21 Stikine Technology, Llc Automated first look at market events
US7383220B1 (en) 2000-04-10 2008-06-03 Stikine Technology, Llc Automated short term option order processing
US7539638B1 (en) 2000-04-10 2009-05-26 Stikine Technology, Llc Representation of order in multiple markets
US7792733B1 (en) 2000-04-10 2010-09-07 Christopher Keith Automated synchronization of orders represented in multiple markets
US7472087B2 (en) * 2000-04-10 2008-12-30 Stikine Technology, Llc Trading program for interacting with market programs on a platform
US8799138B2 (en) * 2000-04-10 2014-08-05 Stikine Technology, Llc Routing control for orders eligible for multiple markets
US8296215B1 (en) * 2000-04-10 2012-10-23 Stikine Technology, Llc Trading system with elfs and umpires
US6795811B1 (en) * 2000-04-26 2004-09-21 Lee Epstein Method for investing working capital
DE10196146T1 (en) 2000-05-01 2003-07-03 Cfph Llc Interactive real-time betting on event results
US7747486B1 (en) * 2000-05-08 2010-06-29 James Kemp Smith Financial analysis system interface
JP2004521400A (en) * 2000-05-18 2004-07-15 トレジャリーコネクト エルエルシー Electronic commerce system and method
US7356500B1 (en) * 2000-06-01 2008-04-08 Pipeline Financial Group, Inc. Method for directing and executing certified trading interests
US7685052B2 (en) * 2000-06-01 2010-03-23 Pipeline Financial Group, Inc. Confidential block trading system and method
US7680715B2 (en) * 2000-06-01 2010-03-16 Pipeline Financial Group, Inc. Systems and methods for providing anonymous requests for quotes for financial instruments
US8010438B2 (en) 2000-06-01 2011-08-30 Pipeline Financial Group, Inc. Method for directing and executing certified trading interests
US8069106B2 (en) * 2000-06-01 2011-11-29 Pipeline Financial Group, Inc. Block trading system and method providing price improvement to aggressive orders
US7437325B2 (en) 2002-03-05 2008-10-14 Pablo Llc System and method for performing automatic spread trading
US7212997B1 (en) * 2000-06-09 2007-05-01 Ari Pine System and method for analyzing financial market data
DE10029066C2 (en) * 2000-06-13 2002-06-20 Siemens Ag Arrangement and method for handling a payment transaction in auction trading via a data network
GB2366023B (en) * 2000-06-23 2004-08-11 Ebs Nominees Ltd Credit limit storage in an anonymous trading system
US7333952B1 (en) * 2000-06-23 2008-02-19 Ebs Group Limited Compound order handling in an anonymous trading system
GB2364586B (en) 2000-06-23 2004-06-16 Ebs Nominees Ltd Deal matching in an anonymous trading system
US7184982B1 (en) 2000-06-23 2007-02-27 Ebs Group Limited Architecture for anonymous trading system
US7827085B1 (en) 2000-06-23 2010-11-02 Ebs Group Limited Conversational dealing in an anonymous trading system
US6983259B1 (en) 2000-06-23 2006-01-03 Ebs Group Limited Anonymous trading system
US7024386B1 (en) * 2000-06-23 2006-04-04 Ebs Group Limited Credit handling in an anonymous trading system
US7366690B1 (en) 2000-06-23 2008-04-29 Ebs Group Limited Architecture for anonymous trading system
US20030018561A1 (en) * 2000-06-30 2003-01-23 Kitchen Louise J. Single party buying and selling commodities with multiple counterparties
US8180698B2 (en) * 2000-07-18 2012-05-15 Lerner Julie A System for physicals commodity trading
US6873972B1 (en) 2000-08-01 2005-03-29 General Electric Company Systems and methods for credit line monitoring
US7516097B2 (en) * 2000-08-04 2009-04-07 Bgc Partners, Inc. Systems and methods for anonymous electronic trading
US7137102B2 (en) * 2000-08-09 2006-11-14 Fujitsu Limited Program development device utilizing component, program development method and medium
US20030220867A1 (en) * 2000-08-10 2003-11-27 Goodwin Thomas R. Systems and methods for trading and originating financial products using a computer network
US20020023056A1 (en) * 2000-08-17 2002-02-21 Udo Augustine F. System and method for creation of backed depositary receipts
US7689498B2 (en) * 2000-08-24 2010-03-30 Volbroker Limited System and method for trading options
US20050015321A1 (en) * 2000-08-30 2005-01-20 Susanne Vindekilde System and method for listing offerings of commercial paper and other interests
US8326730B2 (en) * 2000-09-14 2012-12-04 Latex System and method of clearing services for risk management trading
US7110972B1 (en) * 2000-09-19 2006-09-19 Icor Brokerage, Inc. Method and system of managing credit for the electronic trading of financial instruments
WO2002025535A1 (en) * 2000-09-22 2002-03-28 On Exchange, Inc. Multi-species matching in electronic-based market
US20020082977A1 (en) * 2000-09-25 2002-06-27 Hammond Mark S. Aggregation of on-line auction listing and market data for use to increase likely revenues from auction listings
US8301535B1 (en) 2000-09-29 2012-10-30 Power Financial Group, Inc. System and method for analyzing and searching financial instrument data
US7379909B1 (en) 2000-10-04 2008-05-27 Tradestation Technologies, Inc. System, method and apparatus for monitoring and execution of entry and exit orders
US7496535B2 (en) * 2000-10-14 2009-02-24 Goldman Sachs & Co. Computerized interface for constructing and executing computerized transaction processes and programs
US7305361B2 (en) * 2000-10-14 2007-12-04 Goldman Sachs & Co. Apparatus, methods and articles of manufacture for constructing and executing computerized transaction processes and programs
US7660740B2 (en) 2000-10-16 2010-02-09 Ebay Inc. Method and system for listing items globally and regionally, and customized listing according to currency or shipping area
US7136834B1 (en) * 2000-10-19 2006-11-14 Liquidnet, Inc. Electronic securities marketplace having integration with order management systems
US20070022375A1 (en) * 2000-10-19 2007-01-25 David Walker Apparatus, system, and method for an electronic payment system
US7627830B1 (en) * 2000-10-31 2009-12-01 Aol Llc, A Delaware Limited Liability Company Click-to-add, jot-it-down, and add banner
US20050131802A1 (en) * 2000-11-17 2005-06-16 Arman Glodjo Method and system for network-decentralized trading with optimal proximity measures
US7970689B2 (en) * 2000-11-17 2011-06-28 Scale Semiconductor Flg, L.L.C. Single-period auctions network decentralized trading system and method
US7184984B2 (en) * 2000-11-17 2007-02-27 Valaquenta Intellectual Properties Limited Global electronic trading system
US7840474B1 (en) 2000-12-11 2010-11-23 Icor Brokerage, Inc. Method and system for managing requests for proposals for electronic trading of financial instruments
US20020069152A1 (en) * 2000-12-14 2002-06-06 B.C Paul A.Adao E Silva Day trading system
US7212994B2 (en) * 2000-12-15 2007-05-01 Td Ameritrade Ip Company, Inc. System and methods for disseminating real time information
US7401039B1 (en) * 2000-12-15 2008-07-15 Ebay Inc. Analytical tools for a community of investors having investment portfolios
US7458080B2 (en) 2000-12-19 2008-11-25 Microsoft Corporation System and method for optimizing user notifications for small computer devices
US20040143525A1 (en) * 2000-12-28 2004-07-22 Masanobu Nishimaki Finantial instrument exchange transaction system
US8370231B2 (en) * 2000-12-28 2013-02-05 Ip Strategy Incorporated Method for supporting an exchange transaction
US20020087881A1 (en) * 2000-12-29 2002-07-04 Shlomi Harif System, method and program for identifying and binding a process in a heterogeneous network
US20020087483A1 (en) * 2000-12-29 2002-07-04 Shlomi Harif System, method and program for creating and distributing processes in a heterogeneous network
US7363269B2 (en) * 2001-01-03 2008-04-22 Ebs Group Limited Conversational dealing system
US7865417B2 (en) * 2001-01-25 2011-01-04 Jpmorgan Chase Bank, N.A. Method and system for administering a discounted security
US7451109B2 (en) * 2001-01-25 2008-11-11 Morgan Guarantee Trust Company Of New York Method and system for administering a discounted security
US8805739B2 (en) 2001-01-30 2014-08-12 Jpmorgan Chase Bank, National Association System and method for electronic bill pay and presentment
US7904358B2 (en) * 2001-02-28 2011-03-08 Goldman Sachs & Co. Computerized interface for monitoring financial information and executing financial transactions
US7007270B2 (en) * 2001-03-05 2006-02-28 Cadence Design Systems, Inc. Statistically based estimate of embedded software execution time
US6939137B1 (en) * 2001-12-12 2005-09-06 Cantor Fitzgerald, Lp Method and system for training traders
US7904361B2 (en) 2001-03-20 2011-03-08 Goldman Sachs & Co. Risk management customer registry
US8069105B2 (en) * 2001-03-20 2011-11-29 Goldman Sachs & Co. Hedge fund risk management
US7899722B1 (en) 2001-03-20 2011-03-01 Goldman Sachs & Co. Correspondent bank registry
US8527400B2 (en) * 2001-03-20 2013-09-03 Goldman, Sachs & Co. Automated account risk management
US20040143446A1 (en) * 2001-03-20 2004-07-22 David Lawrence Long term care risk management clearinghouse
US8140415B2 (en) 2001-03-20 2012-03-20 Goldman Sachs & Co. Automated global risk management
US7676426B2 (en) * 2001-03-20 2010-03-09 Goldman Sachs & Co. Biometric risk management
US8121937B2 (en) 2001-03-20 2012-02-21 Goldman Sachs & Co. Gaming industry risk management clearinghouse
US7548883B2 (en) * 2001-03-20 2009-06-16 Goldman Sachs & Co Construction industry risk management clearinghouse
US8209246B2 (en) * 2001-03-20 2012-06-26 Goldman, Sachs & Co. Proprietary risk management clearinghouse
US8285615B2 (en) 2001-03-20 2012-10-09 Goldman, Sachs & Co. Construction industry risk management clearinghouse
US7958027B2 (en) 2001-03-20 2011-06-07 Goldman, Sachs & Co. Systems and methods for managing risk associated with a geo-political area
US20020138417A1 (en) * 2001-03-20 2002-09-26 David Lawrence Risk management clearinghouse
WO2002082338A1 (en) * 2001-04-03 2002-10-17 Future System Consulting Corp. Dealing mediation system and method
US7370010B2 (en) * 2001-04-09 2008-05-06 Omx Technology Ab Automated semi-deterministic trading system
US20030163405A1 (en) * 2001-04-19 2003-08-28 Jason Wiener Electronic asset assignment and tracking
US7091952B2 (en) * 2001-05-03 2006-08-15 3M Innovative Properties Company Liquid proof switch array
US20040210541A1 (en) * 2001-05-04 2004-10-21 Jeremy Epstien User interface for a rules engine and methods therefor
US7392217B2 (en) 2001-05-09 2008-06-24 Bgc Partners, Inc. Systems and methods for controlling traders from manipulating electronic trading markets
GB2394094A (en) * 2001-05-14 2004-04-14 Espeed Inc Systems and methods for providing a trading interface with advanced features
US7702563B2 (en) * 2001-06-11 2010-04-20 Otc Online Partners Integrated electronic exchange of structured contracts with dynamic risk-based transaction permissioning
US7243083B2 (en) * 2001-06-14 2007-07-10 Trading Technologies International, Inc. Electronic spread trading tool
ITTO20010603A1 (en) * 2001-06-22 2002-12-22 Directa S I M P A SYSTEM AND METHOD OF SALES OF SECURITIES BY TELEMATIC WAY WITH FAST ORGANIZATION.
US7398242B2 (en) * 2001-06-25 2008-07-08 Ubs Ag Risk stripping system and method
US20030004853A1 (en) * 2001-06-28 2003-01-02 Pranil Ram Graphical front end system for real time security trading
US20030009411A1 (en) * 2001-07-03 2003-01-09 Pranil Ram Interactive grid-based graphical trading system for real time security trading
TW520478B (en) * 2001-06-29 2003-02-11 Inventec Corp System with automatic transmission and fax management and method therefor
US7653584B2 (en) * 2001-06-29 2010-01-26 Chicago Board Options Exchange, Incorporated Automated execution system having participation
US8296216B2 (en) * 2001-07-09 2012-10-23 The Nasdaq Omx Group, Inc. Directed order processing for automated market system
US8301539B2 (en) * 2001-07-09 2012-10-30 The Nasdaq Omx Group, Inc. Order processing for automated market system
US20030023539A1 (en) * 2001-07-27 2003-01-30 Wilce Scot D. Systems and methods for facilitating agreement definition via an agreement modeling system
GB2381885A (en) * 2001-08-22 2003-05-14 Centradia Ltd Data processing system for implementing a financial market
US7613640B2 (en) * 2001-08-29 2009-11-03 Ebs Group Limited Electronic trading system
WO2003023679A1 (en) * 2001-09-07 2003-03-20 Thomas Eugene Jester Method for automating price discovery
US7315839B2 (en) * 2001-09-20 2008-01-01 Ubs Ag Securities pricing system
US20030177126A1 (en) * 2001-09-21 2003-09-18 Weingard Fred S. Volume weighted average price system and method
US7603290B1 (en) * 2001-10-03 2009-10-13 I2 Technologies Us, Inc. System and computer implemented method for facilitating order entry
US7650305B1 (en) * 2001-10-03 2010-01-19 I2 Technologies Us, Inc. Displaying market data
GB2381339A (en) * 2001-10-05 2003-04-30 Inventec Corp Method and system for controlling production and exportation
US6975996B2 (en) 2001-10-09 2005-12-13 Goldman, Sachs & Co. Electronic subpoena service
US7752266B2 (en) 2001-10-11 2010-07-06 Ebay Inc. System and method to facilitate translation of communications between entities over a network
US10354322B2 (en) * 2001-10-18 2019-07-16 Bgc Partners, Inc. Two sided trading orders
US20030083974A1 (en) * 2001-10-26 2003-05-01 John Bunda Method and system for managing display of quotes for securities from multiple sources
US8005743B2 (en) 2001-11-13 2011-08-23 Intercontinentalexchange, Inc. Electronic trading confirmation system
EP1461754A4 (en) * 2001-11-28 2005-11-09 Goldman Sachs & Co Transaction surveillance
US7412415B2 (en) * 2001-11-29 2008-08-12 Morgan Stanley Pair trading system and method
WO2003048905A2 (en) * 2001-12-05 2003-06-12 E-Xchange Advantage, Inc. Method and system for managing distributed trading data
US20030139997A1 (en) * 2001-12-17 2003-07-24 Espeed, Inc. Systems and methods for automated commission processing
US20030126055A1 (en) * 2001-12-27 2003-07-03 Christophe Thal Method for describing financial instruments
US7587346B2 (en) * 2002-01-07 2009-09-08 The Nasdaq Omx Group, Inc. Automated market system with selectable match-off of order flow
US20030149654A1 (en) * 2002-01-16 2003-08-07 Harrington Kevin F. Interactive security brokerage system
US20030139990A1 (en) * 2002-01-22 2003-07-24 Big Finance And Insurance Services, Inc. Method, apparatus and system for control and assessment of risk in commercial transactions
US20080027769A1 (en) * 2002-09-09 2008-01-31 Jeff Scott Eder Knowledge based performance management system
US7827080B2 (en) * 2002-02-14 2010-11-02 Multiple-Markets Fixed income securities ratings visualization
US8548885B2 (en) * 2002-02-14 2013-10-01 Multiple-Markets Fixed income securities ratings visualization
US7672895B2 (en) 2002-02-19 2010-03-02 Trading Technologies International, Inc. System and method for simulating an electronic trading environment
US20030163404A1 (en) * 2002-02-22 2003-08-28 Kenneth Hu Method of evaluating security trading capacity
US7813995B2 (en) 2002-03-05 2010-10-12 Trading Technologies International, Inc. System and method for estimating a spread value
AU2003206570B2 (en) * 2002-03-13 2010-03-04 Nasdaq Technology Ab An automated semi-deterministic trading system
US20030187766A1 (en) * 2002-03-29 2003-10-02 Nissho Iwai American Corporation Automated risk management system and method
GB2403571B (en) * 2002-04-19 2005-11-23 Trading Technologies Int Inc Trading tools for electronic trading
US20030197723A1 (en) * 2002-04-19 2003-10-23 Young Brian R. Methods, apparatus and computer program products for providing network device status information
US7584138B2 (en) * 2002-04-23 2009-09-01 Blackrock Financial Management, Inc. System and method for providing automated trade confirmation
US20030220863A1 (en) 2002-05-24 2003-11-27 Don Holm System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US7324971B2 (en) * 2002-05-29 2008-01-29 Richard Bookstaber Blind perturbation encryption method for protecting financial position information while providing risk transparency
US9569797B1 (en) 2002-05-30 2017-02-14 Consumerinfo.Com, Inc. Systems and methods of presenting simulated credit score information
US7610229B1 (en) 2002-05-30 2009-10-27 Experian Information Solutions, Inc. System and method for interactively simulating a credit-worthiness score
US7593891B2 (en) 2003-05-30 2009-09-22 Experian Scorex Llc Credit score simulation
US7685051B2 (en) * 2002-05-31 2010-03-23 Intercontinentalexchange, Inc. System for settling over the counter trades
US20040019562A1 (en) * 2002-06-03 2004-01-29 Viberg Jon Jay Term allowance clearinghouse
US20030225655A1 (en) * 2002-06-05 2003-12-04 Hughes John T. Market participant interest dissemination process and method
AU2003237467A1 (en) * 2002-06-07 2003-12-22 Side By Side Trading, Llc Electronic trading system
US8078505B2 (en) 2002-06-10 2011-12-13 Ebay Inc. Method and system for automatically updating a seller application utilized in a network-based transaction facility
US8719041B2 (en) 2002-06-10 2014-05-06 Ebay Inc. Method and system for customizing a network-based transaction facility seller application
US7941348B2 (en) 2002-06-10 2011-05-10 Ebay Inc. Method and system for scheduling transaction listings at a network-based transaction facility
US8301540B2 (en) * 2004-09-28 2012-10-30 Bgc Partners, Inc. Neutral price improvement
AU2003243508A1 (en) * 2002-06-11 2003-12-22 Goldman, Sachs And Co. Systems and methods for managing risk associated with a geo-political area
AU2003243629A1 (en) * 2002-06-18 2003-12-31 Phil Kongtcheu Methods, systems and computer program products to facilitate the formation and trading of derivatives contracts
US9805417B2 (en) 2002-06-19 2017-10-31 Trading Technologies International, Inc. System and method for automated trading
WO2004001537A2 (en) * 2002-06-20 2003-12-31 Goldman, Sachs & Co. Proprietary risk management clearinghouse
US8108276B2 (en) * 2002-06-28 2012-01-31 Goldman Sachs & Co. Method and apparatus for reference data scrubbing
US7124110B1 (en) 2002-07-15 2006-10-17 Trading Technologies International Inc. Method and apparatus for message flow and transaction queue management
US7962399B2 (en) * 2002-07-25 2011-06-14 The Nasdaq Omx Group, Inc. Refreshing displayed quotes for automated market system
US20040019554A1 (en) * 2002-07-26 2004-01-29 Merold Michael S. Automated trading system
US8209254B2 (en) 2002-07-26 2012-06-26 Ebs Group Limited Automated trading system
US20040039673A1 (en) * 2002-08-19 2004-02-26 Matt Amberson Method, system, and computer program product for summarizing an implied volatility surface
US20040034587A1 (en) * 2002-08-19 2004-02-19 Amberson Matthew Gilbert System and method for calculating intra-period volatility
WO2004019255A1 (en) * 2002-08-23 2004-03-04 Turbeville Wallace C Risk measurement management and trade decisioning system
WO2004023244A2 (en) * 2002-09-03 2004-03-18 Electronic Broking Services Limited System and method for deriving data
US7596523B2 (en) * 2002-09-09 2009-09-29 Barra, Inc. Method and apparatus for network-based portfolio management and risk-analysis
US20040167828A1 (en) * 2002-09-17 2004-08-26 Bria Frank H. Business method of providing products or services to a client in a graduated manner to achieve an end result
US7366691B1 (en) 2002-09-25 2008-04-29 Trading Technologies International Inc. Method and interface for presenting last traded quantity information
US7813994B1 (en) 2002-09-30 2010-10-12 Trading Technologies International, Inc. System and method for displaying highest and lowest traded prices of tradable objects
US7752115B2 (en) 2002-10-02 2010-07-06 Trading Technologies International, Inc. Method and apparatus for a fair exchange
US7788154B1 (en) * 2002-10-02 2010-08-31 Goldman Sachs & Co. Methods, systems and securities for assuring a company an opportunity to sell stock after a specified time
US7805347B1 (en) 2002-10-07 2010-09-28 Goldman Sachs & Co. Methods, systems and securities for assuring a company an opportunity to sell stock after a specified time
US20040083157A1 (en) * 2002-10-25 2004-04-29 Sasser James E. User interface, system, and method for providing indirect access to construction services
US20040083136A1 (en) * 2002-10-25 2004-04-29 Sasser James E. User interface, system, and method for providing access to construction services
EP1579360A4 (en) 2002-10-29 2008-01-02 Ebs Group Ltd Anonymous trading system
US7983978B2 (en) 2002-10-31 2011-07-19 Chicago Mercantile Exchange Inc. Foreign currency index
EP2428872A1 (en) 2002-10-31 2012-03-14 eSpeed, Inc. Keyboard for trading system
US8566212B2 (en) 2002-10-31 2013-10-22 Bgc Partners, Inc. Electronic systems and methods for providing a trading interface with advanced features
US7426490B1 (en) 2002-10-31 2008-09-16 Trading Technologies International, Inc. System and method for automated order entry on short queues
US7536339B1 (en) 2002-10-31 2009-05-19 Trading Technologies International, Inc. Method and system for quantity entry
EP1567960A4 (en) * 2002-11-08 2007-06-13 Fx Alliance Llc Method and apparatus for trading assets
US7523064B2 (en) 2002-11-13 2009-04-21 Trading Technologies International, Inc. System and method for facilitating trading of multiple tradeable objects in an electronic trading environment
US7571134B1 (en) 2002-11-13 2009-08-04 Trading Technologies International, Inc. Trading interface for facilitating trading of multiple tradeable objects in an electronic trading environment
US7418422B2 (en) 2002-11-13 2008-08-26 Trading Technologies International, Inc. Method, apparatus and interface for trading multiple tradeable objects
US7702574B2 (en) * 2002-11-14 2010-04-20 Goldman Sachs & Co. Independent research consensus earnings estimates and methods of determining such
US7577602B2 (en) 2002-11-26 2009-08-18 Trading Technologies International Inc. Method and interface for consolidating price levels on a trading screen
US7603303B1 (en) 2002-11-26 2009-10-13 Trading Technologies International, Inc. System and method for risk management
US8041623B1 (en) 2002-11-26 2011-10-18 Trading Technologies International, Inc. Method and interface for historical display of market information
US7792735B1 (en) 2002-11-26 2010-09-07 Trading Technologies International, Inc. System and method for risk management using average expiration times
US20080033867A1 (en) * 2002-12-09 2008-02-07 Creditex Group, Inc. Centralized process for determining deltas for index tranches
US7716114B2 (en) * 2002-12-09 2010-05-11 Creditex Group, Inc. Systems and methods for an online credit derivative trading system
US7698208B2 (en) * 2002-12-09 2010-04-13 Creditex Group, Inc. Systems and methods for an online credit derivative trading system
US7587355B2 (en) * 2002-12-09 2009-09-08 Creditex Group, Inc. Systems and methods for an online credit derivative trading system
US20040111355A1 (en) * 2002-12-09 2004-06-10 Creditex, Inc. Systems and methods for tracking price information in an online credit derivative trading system
US8645258B2 (en) * 2002-12-09 2014-02-04 Creditex Group, Inc. Systems and methods for an online credit derivative trading system
US7970693B2 (en) * 2004-09-29 2011-06-28 Creditex Group, Inc. Systems and methods for market order volume clearing in online trading of credit derivatives
US7792734B1 (en) * 2002-12-27 2010-09-07 Trading Technologies International, Inc. Method, apparatus and interface for transaction toggling
US7574397B1 (en) 2003-01-08 2009-08-11 Trading Technologies Imternational Inc. System and method for creating a market map in an electronic trading environment
US7707097B1 (en) * 2003-01-14 2010-04-27 Bgc Partners, Inc. Fully transparent commission calculator and display system
US8306903B2 (en) 2010-04-23 2012-11-06 Bgc Partners, Inc. Commission calculator and display
US20040153375A1 (en) * 2003-01-25 2004-08-05 Mukunya Alfred Kariuki System for trading and hedging product and brand sales
US7752117B2 (en) * 2003-01-31 2010-07-06 Trading Technologies International, Inc. System and method for money management in electronic trading environment
WO2004070565A2 (en) * 2003-01-31 2004-08-19 Trading Technologies International, Inc. System and method for displaying information and using a plurality of profit levels for money management in an alectronic trading environment
US8566190B2 (en) * 2003-02-06 2013-10-22 Goldman, Sachs & Co. Method and apparatus for evaluating and monitoring collateralized debt obligations
US20040164961A1 (en) * 2003-02-21 2004-08-26 Debasis Bal Method, system and computer product for continuously monitoring data sources for an event of interest
GB2398895A (en) * 2003-02-28 2004-09-01 Swapstream Ltd Real time trading involving financial instruments
CA2517406C (en) 2003-02-28 2023-01-03 Trading Technologies International, Inc. A system and method for trading and displaying market information in an electronic trading environment
US10817937B1 (en) 2003-02-28 2020-10-27 Trading Technologies International, Inc. Method and system for internal matching
US7558754B1 (en) 2003-02-28 2009-07-07 Trading Technologies International, Inc. System and method for processing and displaying quantity information during user-configurable time periods
US8595121B2 (en) * 2003-03-24 2013-11-26 Bgc Partners, Inc. Midprice trading within a spread market
US7797223B1 (en) 2003-03-28 2010-09-14 Citigroup Global Markets, Inc. Method and system for efficiently matching long and short positions in securities trading and transacting a series of overnight trades for balance sheet netting
US10311412B1 (en) 2003-03-28 2019-06-04 Jpmorgan Chase Bank, N.A. Method and system for providing bundled electronic payment and remittance advice
US7904370B2 (en) 2003-03-31 2011-03-08 Trading Technologies International, Inc. System and method for variably regulating order entry in an electronic trading system
US7962400B2 (en) 2003-04-02 2011-06-14 Cfph, Llc System and method for wagering based on the movement of financial markets
US7233922B2 (en) * 2003-04-02 2007-06-19 Cantor Index Llc System and method for wagering-based transferable financial instruments
US20040199442A1 (en) * 2003-04-04 2004-10-07 Rainer Haberle Method and system for offering and selling a multi-purpose currency option
US20040199421A1 (en) * 2003-04-04 2004-10-07 Oda Lisa Maureen Method and system to discharge a liability associated with a proprietary currency
US7341517B2 (en) 2003-04-10 2008-03-11 Cantor Index, Llc Real-time interactive wagering on event outcomes
US9881308B2 (en) 2003-04-11 2018-01-30 Ebay Inc. Method and system to facilitate an online promotion relating to a network-based marketplace
US7653588B2 (en) * 2003-04-24 2010-01-26 Chicago Board Options Exchange, Incorporated Method and system for providing order routing to a virtual crowd in a hybrid trading system
US20060167788A1 (en) * 2003-04-24 2006-07-27 Tilly Edward T Method and system for broker trading in a hybrid trading system for concurrently trading securities or derivatives through both electronic and open-outcry trading mechanisms
US8346653B2 (en) 2003-04-24 2013-01-01 Chicago Board Options Exchange, Incorporated Automated trading system for routing and matching orders
US7676421B2 (en) 2003-04-24 2010-03-09 Chicago Board Options Exchange, Incorporated Method and system for providing an automated auction for internalization and complex orders in a hybrid trading system
US7552083B2 (en) 2003-04-24 2009-06-23 Chicago Board Options Exchange, Incorporated Hybrid trading system for concurrently trading through both electronic and open-outcry trading mechanisms
US7613650B2 (en) 2003-04-24 2009-11-03 Chicago Board Options Exchange, Incorporated Hybrid trading system for concurrently trading securities or derivatives through both electronic and open-outcry trading mechanisms
US20040220870A1 (en) * 2003-04-29 2004-11-04 Jonas Lundberg Method and system for improved automated trading of swap contracts
US8001039B2 (en) * 2003-05-15 2011-08-16 Cantor Index, Llc System and method for establishing and providing access to an online account
US8799121B2 (en) * 2003-05-15 2014-08-05 Cantor Index, Llc System and method for managing trading order requests
US7716113B2 (en) * 2003-05-15 2010-05-11 Cantor Index, Llc System and method for providing an intermediary for a transaction
US7996297B2 (en) * 2003-05-15 2011-08-09 Cantor Index, Llc System and method for providing access to and managing account activity for an online account
US7835974B2 (en) 2003-05-15 2010-11-16 Cantor Index, LLC. System and method for managing risk associated with product transactions
US7925577B2 (en) 2003-05-15 2011-04-12 Cantor Index Llc System and method for establishing and providing access to various types of online accounts
US7734529B1 (en) 2003-05-29 2010-06-08 Chicago Mercantile Exchange, Inc. Trader station user interface
US7809628B1 (en) 2003-05-30 2010-10-05 Trading Technologies International Inc. System and method for estimating order position
US6920653B2 (en) * 2003-06-11 2005-07-26 Masco Corporation Disinfectant delivery chamber for use in whirlpool bath
US7801797B2 (en) * 2003-06-17 2010-09-21 Omx Technology Ab Trading system supporting credit rating
US8429043B2 (en) * 2003-06-18 2013-04-23 Barclays Capital Inc. Financial data processor system and method for implementing equity-credit linked investment vehicles
US7742985B1 (en) 2003-06-26 2010-06-22 Paypal Inc. Multicurrency exchanges between participants of a network-based transaction facility
US7587357B1 (en) 2003-06-30 2009-09-08 Trading Technologies International Inc. Repositioning of market information on trading screens
US7512557B1 (en) * 2003-06-30 2009-03-31 Trading Technologies International, Inc. System and method for timed order entry and modification
US7774247B2 (en) * 2003-06-30 2010-08-10 Bloomberg L.P. Computer trading of interests
US8676679B2 (en) * 2003-06-30 2014-03-18 Bloomberg L.P. Counterparty credit limits in computerized trading
US7533054B2 (en) * 2003-06-30 2009-05-12 Bloomberg L.P. Central credit filtering in computerized trading
US7769652B1 (en) * 2003-08-29 2010-08-03 Trading Technologies International, Inc. System and method for changing order priority levels in an electronic trading environment
US20050055304A1 (en) * 2003-09-10 2005-03-10 Lutnick Howard W. Trading application program interface
US7702569B1 (en) 2003-09-22 2010-04-20 Trading Technologies International, Inc. System and method for icon oriented representation of trading strategies
US11100582B2 (en) 2003-09-22 2021-08-24 Trading Technologies International, Inc. System and method for dynamically determining quantity for risk management
US7861185B1 (en) 2003-12-30 2010-12-28 Trading Technologies International, Inc. System and method for dynamically determining quantity for risk management
US20050064900A1 (en) * 2003-09-24 2005-03-24 Agere Systems, Incorporated System and method for using a mobile telephone to retrieve information about an article
US7739164B1 (en) * 2003-10-07 2010-06-15 Trading Technologies International, Inc. System and method for displaying risk data in an electronic trading environment
US7761363B2 (en) 2003-10-08 2010-07-20 Fx Alliance, Llc Internal trade requirement order management and execution system
US8219487B2 (en) * 2003-10-15 2012-07-10 Blackrock, Inc. System and method for managing credit risk for investment portfolios
AU2004220731B2 (en) * 2003-10-17 2009-12-03 Bgc Partners, Inc. Systems and Methods for Providing Enhanced Volume-Weighted Average Price Trading
US8655755B2 (en) * 2003-10-22 2014-02-18 Scottrade, Inc. System and method for the automated brokerage of financial instruments
US20050097046A1 (en) 2003-10-30 2005-05-05 Singfield Joy S. Wireless electronic check deposit scanning and cashing machine with web-based online account cash management computer application system
US20050097027A1 (en) * 2003-11-05 2005-05-05 Sylvan Kavanaugh Computer-implemented method and electronic system for trading
US8131626B2 (en) 2003-11-17 2012-03-06 Bgc Partners, Inc. Customizable trading display of market data
US8131625B2 (en) 2003-11-17 2012-03-06 Bgc Partners, Inc. Customizable trading display of market data
EP1533732A1 (en) * 2003-11-19 2005-05-25 Deutsche Börse Ag Construct separation for the valuation of a futures contract
JP2008503794A (en) * 2003-11-26 2008-02-07 エフエックス アライアンス,エルエルシー Protocol-independent asset trading system and method
SG132684A1 (en) * 2003-11-26 2007-06-28 Fx Alliance Llc Latency-aware asset trading system
JP2007512630A (en) * 2003-11-26 2007-05-17 エフエックス アライアンス,エルエルシー Instant fulfillment customer asset trading system
US7814003B2 (en) * 2003-12-15 2010-10-12 Jp Morgan Chase Billing workflow system for crediting charges to entities creating derivatives exposure
JP3991030B2 (en) * 2003-12-24 2007-10-17 キヤノン株式会社 Image forming apparatus, operation history storage method, and computer program
US10304097B2 (en) * 2004-01-29 2019-05-28 Bgc Partners, Inc. System and method for controlling the disclosure of a trading order
US7835987B2 (en) * 2004-01-29 2010-11-16 Bgc Partners, Inc. System and method for routing a trading order according to price
US20050171890A1 (en) * 2004-01-29 2005-08-04 Daley Thomas J. System and method for matching trading orders
US20050171887A1 (en) * 2004-01-29 2005-08-04 Daley Thomas J. System and method for avoiding transaction costs associated with trading orders
US8738498B2 (en) * 2004-01-29 2014-05-27 Bgc Partners, Inc. System and method for routing a trading order
US8046289B2 (en) * 2004-01-29 2011-10-25 New York Mercantile Exchange, Inc. Electronic pitcard for wireless financial exchange
SI1564164T1 (en) * 2004-02-10 2006-12-31 Financ De Gestion Soc Troughed belt conveyor
US20050182725A1 (en) * 2004-02-13 2005-08-18 Michael Modica Check replenishment method and process
GB2411492B (en) * 2004-02-25 2006-06-07 Patsystems Electronic trading system
US7711628B2 (en) * 2004-03-05 2010-05-04 Cantor Index Llc System and method for offering intraday wagering in a financial market environment
US20050197938A1 (en) * 2004-03-05 2005-09-08 Cantor Index Llc System and method for determining odds for wagering in a financial market environment
US7835961B2 (en) 2004-03-05 2010-11-16 Cantor Index Llc System and method for wagering in a financial market environment
US8128474B2 (en) 2004-03-05 2012-03-06 Cantor Index, Llc Computer graphics processing methods and systems for presentation of graphics objects or text in a wagering environment
US20050216393A1 (en) * 2004-03-23 2005-09-29 Lutnick Howard W Systems and methods for allowing market-maker participation in transactions
US20050228739A1 (en) * 2004-04-08 2005-10-13 Hotspot Fx Inc. Financial instrument trading system, method and computer program product
US20050240504A1 (en) * 2004-04-23 2005-10-27 Springer Mark H Method and system for auctioning funds using a full-time public network
US20050245308A1 (en) * 2004-04-29 2005-11-03 Cfph, Llc System and method for wagering based on financial market indicators
US20050246263A1 (en) * 2004-04-29 2005-11-03 Lava Trading, Inc. Automated system for routing orders for foreign exchange transactions
US7566270B2 (en) 2004-04-29 2009-07-28 Cfph, Llc System and method for wagering based on multiple financial market indicators
US7637807B2 (en) * 2004-04-29 2009-12-29 Cfph, L.L.C. System and method for mapping results from sporting events to game inputs
US20050283426A1 (en) * 2004-05-11 2005-12-22 Ebs Group Limited Price display in an anonymous trading system
US20050256797A1 (en) * 2004-05-13 2005-11-17 Scottrade, Inc. Method and apparatus for user-interactive financial instrument trading
WO2005119534A1 (en) * 2004-06-01 2005-12-15 Transcon Securities Pty Ltd A system and method for analysing risk associated with an investment portfolio
US20090043637A1 (en) * 2004-06-01 2009-02-12 Eder Jeffrey Scott Extended value and risk management system
AU2005253141A1 (en) * 2004-06-07 2005-12-22 Cfph, Llc System and method for managing financial market information
US7890396B2 (en) 2005-06-07 2011-02-15 Cfph, Llc Enhanced system and method for managing financial market information
US8554673B2 (en) 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management
EP1782376A4 (en) * 2004-06-23 2009-06-24 Fx Alliance Llc Shareable quote streams
WO2006002171A2 (en) * 2004-06-23 2006-01-05 Fx Alliance, Llc Dynamic liquidity management system
US8121944B2 (en) 2004-06-24 2012-02-21 Jpmorgan Chase Bank, N.A. Method and system for facilitating network transaction processing
US20050289038A1 (en) * 2004-06-28 2005-12-29 Alexander Karapetian Method and system for voting for a future price of an asset
US8346593B2 (en) 2004-06-30 2013-01-01 Experian Marketing Solutions, Inc. System, method, and software for prediction of attitudinal and message responsiveness
US8510300B2 (en) 2004-07-02 2013-08-13 Goldman, Sachs & Co. Systems and methods for managing information associated with legal, compliance and regulatory risk
US8996481B2 (en) 2004-07-02 2015-03-31 Goldman, Sach & Co. Method, system, apparatus, program code and means for identifying and extracting information
US8762191B2 (en) 2004-07-02 2014-06-24 Goldman, Sachs & Co. Systems, methods, apparatus, and schema for storing, managing and retrieving information
US8442953B2 (en) 2004-07-02 2013-05-14 Goldman, Sachs & Co. Method, system, apparatus, program code and means for determining a redundancy of information
US7809634B1 (en) 2004-07-09 2010-10-05 Bierc Gary J Enterprise-wide total cost of risk management using ARQ
US20100076906A1 (en) * 2004-07-12 2010-03-25 Rosenthal Collins Group, L.L.C. Method and system for using quantitative analytics on a graphical user interface for electronic trading
US7571135B2 (en) * 2004-07-15 2009-08-04 New York Stock Exchange System and method for determining and applying parity in a hybrid auction market
US7672889B2 (en) 2004-07-15 2010-03-02 Brooks Kent F System and method for providing customizable investment tools
US20060085321A1 (en) * 2004-07-20 2006-04-20 Staib William E Simulation auction for public offering
US9342664B2 (en) * 2004-07-30 2016-05-17 Etrans L.C. Method to make payment or charge safe transactions using programmable mobile telephones
ES2263344B1 (en) * 2004-07-30 2007-11-16 Jose Ignacio Bas Bayod METHOD FOR PERFORMING SECURE PAYMENT OR COLLECTION TRANSACTIONS, USING PROGRAMMABLE MOBILE PHONES.
GB2417345A (en) * 2004-08-13 2006-02-22 Ebs Group Ltd Automated trading system
US7124011B2 (en) * 2004-08-20 2006-10-17 Dresser, Inc. Engine control module and method for use in engine system manufacture
US20060080222A1 (en) * 2004-08-27 2006-04-13 Lutnick Howard W Systems and methods for commission allocation
US20060080217A1 (en) * 2004-08-31 2006-04-13 Blackall Grenville W Clearing house for buying and selling short term liquidity
US7970672B2 (en) 2004-09-01 2011-06-28 Metareward, Inc. Real-time marketing of credit-based goods or services
US8255314B2 (en) 2004-09-13 2012-08-28 Bgc Partners, Inc. Electronic completion of cash versus futures basis trades
US8732004B1 (en) 2004-09-22 2014-05-20 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
JP2008515104A (en) * 2004-09-29 2008-05-08 クレディテックス インコーポレイティッド System and method for an online credit derivative trading system
EP1805656A4 (en) * 2004-10-27 2009-07-08 Itg Software Solutions Inc System and method for generating liquidity
AU2012200652B2 (en) * 2004-10-27 2015-06-04 Itg Software Solutions, Inc. System and method for generating liquidity
US7650309B2 (en) * 2004-10-28 2010-01-19 The Depository Trust and Clearing Corporation Methods and systems for netting of payments and collateral
WO2006063352A2 (en) * 2004-12-10 2006-06-15 Thomson Tradeweb Llc Method and system for tracking derivatives positions and monitoring credit limits
US8266042B2 (en) 2004-12-21 2012-09-11 Weather Risk Solutions, Llc Financial activity based on natural peril events
US7693766B2 (en) 2004-12-21 2010-04-06 Weather Risk Solutions Llc Financial activity based on natural events
US7783542B2 (en) 2004-12-21 2010-08-24 Weather Risk Solutions, Llc Financial activity with graphical user interface based on natural peril events
US7584134B2 (en) 2004-12-21 2009-09-01 Weather Risk Solutions, Llc Graphical user interface for financial activity concerning tropical weather events
US7783544B2 (en) 2004-12-21 2010-08-24 Weather Risk Solutions, Llc Financial activity concerning tropical weather events
US7783543B2 (en) 2004-12-21 2010-08-24 Weather Risk Solutions, Llc Financial activity based on natural peril events
US7584133B2 (en) 2004-12-21 2009-09-01 Weather Risk Solutions Llc Financial activity based on tropical weather events
US7634438B2 (en) * 2004-12-23 2009-12-15 Fx Alliance, Llc Dynamic account mapping system for computerized asset trading
US7827093B1 (en) * 2005-03-02 2010-11-02 Icap Services North America Llc Call for quote/price system and methods for use in a wholesale financial market
GB2425626A (en) 2005-03-24 2006-11-01 Espeed Inc System for protecting against erroneous price entries in the electronic trading of financial and other instruments
US20060233332A1 (en) * 2005-03-24 2006-10-19 Toms Alvin D Credit worthiness rating method
US20060218407A1 (en) * 2005-03-24 2006-09-28 Toms Alvin D Method of confirming the identity of a person
US20060218071A1 (en) * 2005-03-28 2006-09-28 Espeed, Inc. System and method for managing trading between related entities
US20060224491A1 (en) * 2005-04-01 2006-10-05 De Novo Markets Limited Trading and settling enhancements to the standard electronic futures exchange market model leading to novel derivatives including on exchange ISDA type credit derivatives and entirely new recovery products including novel options on these
US7809629B2 (en) 2005-04-07 2010-10-05 Chicago Board Options Exchange, Incorporated Market participant issue selection system and method
US20080082436A1 (en) * 2005-05-04 2008-04-03 Shalen Catherine T System And Method For Creating And Trading A Digital Derivative Investment Instrument
US8326715B2 (en) 2005-05-04 2012-12-04 Chicago Board Operations Exchange, Incorporated Method of creating and trading derivative investment products based on a statistical property reflecting the variance of an underlying asset
US8027904B2 (en) 2005-05-04 2011-09-27 Chicago Board Options Exchange, Incorporated Method and system for creating and trading corporate debt security derivative investment instruments
US8326716B2 (en) 2005-05-04 2012-12-04 Chicago Board Options Exchange, Incorporated Method and system for creating and trading derivative investment products based on a statistical property reflecting the variance of an underlying asset
US20060253369A1 (en) * 2005-05-04 2006-11-09 Chicago Board Options Exchange Method of creating and trading derivative investment products based on an average price of an underlying asset during a calculation period
US20060253368A1 (en) * 2005-05-04 2006-11-09 Chicago Board Options Exchange System and method for creating and trading credit rating derivative investment instruments
US8489489B2 (en) 2005-05-05 2013-07-16 Chicago Board Options Exchange, Incorporated System and method for trading derivatives in penny increments while disseminating quotes for derivatives in nickel/dime increments
US7822674B2 (en) * 2005-05-05 2010-10-26 Tumen Steven N Method and apparatus for display of data with respect to a portfolio of tradable interests
WO2006122171A2 (en) * 2005-05-10 2006-11-16 Sean Macguire System and method for accessing the maximum available funds in an electronic financial transaction
WO2006130650A2 (en) 2005-05-31 2006-12-07 Rosenthal Collins Group, Llc Method and system for electronically inputting, monitoring and trading spreads
US7840477B2 (en) * 2005-06-07 2010-11-23 Bgc Partners, Inc. System and method for routing a trading order based upon quantity
US20070043648A1 (en) * 2005-06-10 2007-02-22 Jonathan Chait Foreign exchange trading platform
WO2007002022A2 (en) * 2005-06-20 2007-01-04 Fx Alliance, Llc System and method for trading intruments using a data communications network
US7565318B2 (en) * 2005-06-28 2009-07-21 Trading Technologies International, Inc. System and method for calculating and displaying volume to identify buying and selling in an electronic trading environment
US10552908B2 (en) * 2005-07-21 2020-02-04 Yellowjacket, Inc. Virtual over-the-counter financial product exchange system
US20080215430A1 (en) * 2005-07-28 2008-09-04 Creditex Group, Inc. Credit derivative trading platform
US7805358B2 (en) * 2005-07-29 2010-09-28 Bgc Partners, Inc. System and method for limiting aggressive trading in a electronic trading system
US7805357B2 (en) * 2005-07-29 2010-09-28 Bgc Partners, Inc. System and method for routing trading orders in an electronic trading system using trader lists
EP1929438A4 (en) * 2005-08-04 2010-08-04 Espeed Inc System for submitting trading orders
US8484122B2 (en) 2005-08-04 2013-07-09 Bgc Partners, Inc. System and method for apportioning trading orders based on size of displayed quantities
US8494951B2 (en) 2005-08-05 2013-07-23 Bgc Partners, Inc. Matching of trading orders based on priority
US20070038562A1 (en) * 2005-08-09 2007-02-15 Hoerl Shervyn J V Contractual structure for delinking a bank rating from rating of a special purpose vehicle
US7716125B2 (en) * 2005-08-10 2010-05-11 Axcessnet Innovations Llc Networked loan market and lending management system
US7831501B2 (en) 2005-08-12 2010-11-09 Boulder Capital Trading Hidden book trading system
US7729977B2 (en) * 2005-08-17 2010-06-01 Quan Xiao Method and system for grouping merchandise, services and users and for trading merchandise and services
US8898080B1 (en) 2005-08-25 2014-11-25 Patshare Limited Counterparty credit in electronic trading systems
US8224738B2 (en) 2005-08-31 2012-07-17 Credit Market Analysis, Ltd. Methods, software, and systems for over-the-counter trading
US20100138362A1 (en) * 2005-09-06 2010-06-03 Deltanet Market Limited Methods and Systems For Commoditizing Interest Rate Swap Transfers
US20080167981A1 (en) * 2005-09-06 2008-07-10 Whitehurst Philip H Methods and systems for commoditizing interest rate swap risk transfers
US20070055609A1 (en) * 2005-09-06 2007-03-08 Whitehurst Philip H Methods and systems for commoditizing interest rate swap risk transfers
US7761364B2 (en) * 2005-09-07 2010-07-20 International Securities Exchange, Llc Midpoint matching system
US7774263B1 (en) 2005-09-07 2010-08-10 International Securities Exchange, Llc Linked displayed market and midpoint matching system
US10592930B2 (en) 2005-09-14 2020-03-17 Millenial Media, LLC Syndication of a behavioral profile using a monetization platform
US9201979B2 (en) 2005-09-14 2015-12-01 Millennial Media, Inc. Syndication of a behavioral profile associated with an availability condition using a monetization platform
US9076175B2 (en) 2005-09-14 2015-07-07 Millennial Media, Inc. Mobile comparison shopping
US7769764B2 (en) 2005-09-14 2010-08-03 Jumptap, Inc. Mobile advertisement syndication
US8433297B2 (en) 2005-11-05 2013-04-30 Jumptag, Inc. System for targeting advertising content to a plurality of mobile communication facilities
US7752209B2 (en) 2005-09-14 2010-07-06 Jumptap, Inc. Presenting sponsored content on a mobile communication facility
US7912458B2 (en) 2005-09-14 2011-03-22 Jumptap, Inc. Interaction analysis and prioritization of mobile content
US7676394B2 (en) 2005-09-14 2010-03-09 Jumptap, Inc. Dynamic bidding and expected value
US10911894B2 (en) 2005-09-14 2021-02-02 Verizon Media Inc. Use of dynamic content generation parameters based on previous performance of those parameters
US8812526B2 (en) * 2005-09-14 2014-08-19 Millennial Media, Inc. Mobile content cross-inventory yield optimization
US8989718B2 (en) 2005-09-14 2015-03-24 Millennial Media, Inc. Idle screen advertising
US7577665B2 (en) 2005-09-14 2009-08-18 Jumptap, Inc. User characteristic influenced search results
US8103545B2 (en) 2005-09-14 2012-01-24 Jumptap, Inc. Managing payment for sponsored content presented to mobile communication facilities
US9058406B2 (en) 2005-09-14 2015-06-16 Millennial Media, Inc. Management of multiple advertising inventories using a monetization platform
US9471925B2 (en) 2005-09-14 2016-10-18 Millennial Media Llc Increasing mobile interactivity
US9703892B2 (en) 2005-09-14 2017-07-11 Millennial Media Llc Predictive text completion for a mobile communication facility
US8503995B2 (en) 2005-09-14 2013-08-06 Jumptap, Inc. Mobile dynamic advertisement creation and placement
US7702318B2 (en) 2005-09-14 2010-04-20 Jumptap, Inc. Presentation of sponsored content based on mobile transaction event
US20110313853A1 (en) 2005-09-14 2011-12-22 Jorey Ramer System for targeting advertising content to a plurality of mobile communication facilities
US8688671B2 (en) 2005-09-14 2014-04-01 Millennial Media Managing sponsored content based on geographic region
US8832100B2 (en) 2005-09-14 2014-09-09 Millennial Media, Inc. User transaction history influenced search results
US10038756B2 (en) 2005-09-14 2018-07-31 Millenial Media LLC Managing sponsored content based on device characteristics
US20110145076A1 (en) * 2005-09-14 2011-06-16 Jorey Ramer Mobile Campaign Creation
US20070061241A1 (en) * 2005-09-15 2007-03-15 Jovanovic Vladan D Method for trading securities
US8073763B1 (en) 2005-09-20 2011-12-06 Liquidnet Holdings, Inc. Trade execution methods and systems
US20070073608A1 (en) * 2005-09-23 2007-03-29 Garcia Crisostomo B Cash only marketplace system for trading securities
US8046290B2 (en) * 2005-09-29 2011-10-25 Fitzpatrick Daniel R IOI-based block trading systems, methods, interfaces, and software
US20080033852A1 (en) * 2005-10-24 2008-02-07 Megdal Myles G Computer-based modeling of spending behaviors of entities
US7698187B2 (en) * 2005-10-28 2010-04-13 Liffe Administration And Management System and method for simultaneous trading of options
US8255315B1 (en) 2005-11-30 2012-08-28 Icap Services North America Llc User interfaces for efficient trade entry and management
US7925560B2 (en) * 2005-12-07 2011-04-12 Morgan Stanley Systems and methods for valuing a derivative involving a multiplicative index
US20070136180A1 (en) * 2005-12-14 2007-06-14 David Salomon System and methods for creating, trading, and settling currency futures contracts
CA2632935C (en) * 2005-12-19 2014-02-04 Commvault Systems, Inc. Systems and methods for performing data replication
US7711644B2 (en) 2005-12-20 2010-05-04 Bgc Partners, Inc. Apparatus and methods for processing composite trading orders
US20070174178A1 (en) * 2005-12-20 2007-07-26 Jonathan Chait Direct access bond trading platform
US7937299B1 (en) * 2005-12-29 2011-05-03 First Data Corporation Systems and methods for preauthorizing check transactions
US8121938B1 (en) 2005-12-30 2012-02-21 United Services Automobile Association (Usaa) Comprehensive online loan transaction
US8200576B1 (en) * 2005-12-30 2012-06-12 United Services Automobile Association (Usaa) Comprehensive online loan transaction
US8229832B2 (en) 2006-01-09 2012-07-24 Bgc Partners, Inc. Systems and methods for establishing first on the follow trading priority in electronic trading systems
US8768817B2 (en) * 2006-01-26 2014-07-01 Hitachi, Ltd. Transaction system
US20080065525A1 (en) * 2006-01-30 2008-03-13 Reynold Roeder Methods of pricing and allocating capacity
US8126746B2 (en) * 2006-03-02 2012-02-28 Hartford Fire Insurance Company System and method for processing and administering flexible guaranteed income payments
US7711636B2 (en) 2006-03-10 2010-05-04 Experian Information Solutions, Inc. Systems and methods for analyzing data
US7783560B2 (en) * 2006-03-17 2010-08-24 Creditex Group, Inc. Credit event fixings
US7725381B2 (en) 2006-04-04 2010-05-25 Omx Technology Ab Trader counterpart precondition in anonymous trading system
US7979339B2 (en) * 2006-04-04 2011-07-12 Bgc Partners, Inc. System and method for optimizing execution of trading orders
WO2007118232A2 (en) * 2006-04-07 2007-10-18 Bloomberg Finance L.P. System and method for facilitating foreign currency management
US7991683B2 (en) * 2006-04-11 2011-08-02 Fx Alliance, Llc Credit data processing system for controlling electronic trading based on credit arrangements
US20070255641A1 (en) * 2006-04-28 2007-11-01 Harrington Kevin F Computer interface for trading bonds
US8156036B1 (en) 2006-04-28 2012-04-10 Pipeline Financial Group, Inc. Methods and systems related to trading engines
US7904376B2 (en) 2006-04-28 2011-03-08 Pipeline Financial Group, Inc. Rich graphical control interface for algorithmic trading engine
US7882014B2 (en) * 2006-04-28 2011-02-01 Pipeline Financial Group, Inc. Display of market impact in algorithmic trading engine
US7870059B2 (en) * 2006-04-28 2011-01-11 Pipeline Financial Group, Inc. Display of selected items in visual context in algorithmic trading engine
US7882013B2 (en) * 2006-04-28 2011-02-01 Pipeline Financial Group, Inc. Drag-and-drop graphical control interface for algorithmic trading engine
US7908203B2 (en) 2006-04-28 2011-03-15 Pipeline Financial Group, Inc. Coordination of algorithms in algorithmic trading engine
US20110016037A1 (en) * 2006-05-05 2011-01-20 Tumen Steven N Method and apparatus for display of data with respect to certain tradable interests
EP2068278A3 (en) * 2006-05-08 2010-04-07 The Depository Trust&Clearing Corporation Data storage and processor for storing and processing data associated with derivative contracts and trades related to derivative contracts
US20070271200A1 (en) * 2006-05-18 2007-11-22 Timothy Buchanan Systems and methods to allocate relevancy of global asset peers
US8668146B1 (en) 2006-05-25 2014-03-11 Sean I. Mcghie Rewards program with payment artifact permitting conversion/transfer of non-negotiable credits to entity independent funds
US8684265B1 (en) 2006-05-25 2014-04-01 Sean I. Mcghie Rewards program website permitting conversion/transfer of non-negotiable credits to entity independent funds
US7703673B2 (en) 2006-05-25 2010-04-27 Buchheit Brian K Web based conversion of non-negotiable credits associated with an entity to entity independent negotiable funds
US9704174B1 (en) 2006-05-25 2017-07-11 Sean I. Mcghie Conversion of loyalty program points to commerce partner points per terms of a mutual agreement
US10062062B1 (en) 2006-05-25 2018-08-28 Jbshbm, Llc Automated teller machine (ATM) providing money for loyalty points
US20060282369A1 (en) * 2006-06-13 2006-12-14 White William P One touch hybrid trading model and interface
US8781944B2 (en) * 2006-06-15 2014-07-15 Omx Technology Ab Method of matching orders on an electronic trading system and an electronic trading system for matching orders
US8200569B1 (en) 2006-06-22 2012-06-12 Power Financial Group, Inc. Option search criteria testing
US7672898B1 (en) 2006-07-07 2010-03-02 Trading Technologies International Inc. Regulating order entry in an electronic trading environment to maintain an actual cost for a trading strategy
US20080235146A1 (en) * 2006-07-28 2008-09-25 Creditex Group, Inc. System and method for affirming over the counter derivative trades
US7899726B2 (en) * 2006-08-11 2011-03-01 Reuters Sa Method and apparatus for option filtering
GB0616489D0 (en) * 2006-08-18 2006-09-27 Latentzero Ltd Display of market information
US8639782B2 (en) 2006-08-23 2014-01-28 Ebay, Inc. Method and system for sharing metadata between interfaces
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface
US8799148B2 (en) 2006-08-31 2014-08-05 Rohan K. K. Chandran Systems and methods of ranking a plurality of credit card offers
US8027888B2 (en) * 2006-08-31 2011-09-27 Experian Interactive Innovation Center, Llc Online credit card prescreen systems and methods
US8341064B2 (en) * 2006-09-12 2012-12-25 Chicago Mercantile Exchange, Inc. Standardization and management of over-the-counter financial instruments
US8562422B2 (en) * 2006-09-28 2013-10-22 Cfph, Llc Products and processes for processing information related to weather and other events
US8036979B1 (en) 2006-10-05 2011-10-11 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US7873200B1 (en) 2006-10-31 2011-01-18 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US8799147B1 (en) 2006-10-31 2014-08-05 United Services Automobile Association (Usaa) Systems and methods for remote deposit of negotiable instruments with non-payee institutions
US7885451B1 (en) 2006-10-31 2011-02-08 United Services Automobile Association (Usaa) Systems and methods for displaying negotiable instruments derived from various sources
US8708227B1 (en) 2006-10-31 2014-04-29 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US8351677B1 (en) 2006-10-31 2013-01-08 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US7876949B1 (en) 2006-10-31 2011-01-25 United Services Automobile Association Systems and methods for remote deposit of checks
US20080103961A1 (en) * 2006-11-01 2008-05-01 Bank Of America Private Institutional Credit Derivative
US7716117B2 (en) * 2006-11-10 2010-05-11 Board Of Trade Of The City Of Chicago System and method for making positions held by a trader fungible
US8140425B2 (en) 2006-11-13 2012-03-20 Chicago Board Options Exchange, Incorporated Method and system for generating and trading derivative investment instruments based on a volatility arbitrage benchmark index
US20080120249A1 (en) * 2006-11-17 2008-05-22 Chicago Board Options Exchange, Incorporated Method of creating and trading derivative investment products based on a statistical property reflecting the volatility of an underlying asset
CA2709237A1 (en) 2006-12-11 2008-06-19 Joseph Peter Mac Innis Computer implemented finance management routing system
WO2008083383A2 (en) * 2006-12-30 2008-07-10 Cfph, Llc Methods and systems for managing and trading using a shared order book as internal exchange
US7716118B2 (en) * 2007-01-16 2010-05-11 Peter Bartko System and method for providing latency protection for trading orders
US20080172318A1 (en) * 2007-01-16 2008-07-17 Peter Bartko System and Method for Managing Trading Orders in Aggregated Order Books
US10185995B2 (en) 2007-01-16 2019-01-22 Bgc Partners, L.P. System and method for managing display of market data in an electronic trading system
WO2008093211A2 (en) * 2007-01-30 2008-08-07 Swapstream, Ltd. Management of standardized over-the-counter financial instruments
US8606666B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US8606626B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US8538795B2 (en) * 2007-02-12 2013-09-17 Pricelock, Inc. System and method of determining a retail commodity price within a geographic boundary
US8156022B2 (en) 2007-02-12 2012-04-10 Pricelock, Inc. Method and system for providing price protection for commodity purchasing through price protection contracts
US20080313067A1 (en) * 2007-02-12 2008-12-18 Pricelock, Inc. Management and decision making tool for commodity purchases with hedging scenarios
US7844539B2 (en) * 2007-03-02 2010-11-30 Chicago Board Options Exchange, Incorporated Hybrid trading system for concurrently trading combined orders for financial instruments through both electronic and open-outcry trading mechanisms
WO2008112109A2 (en) * 2007-03-13 2008-09-18 Creditex Group, Inc. System and method for affirming over the counter derivative trades
US10380559B1 (en) 2007-03-15 2019-08-13 United Services Automobile Association (Usaa) Systems and methods for check representment prevention
US8959033B1 (en) 2007-03-15 2015-02-17 United Services Automobile Association (Usaa) Systems and methods for verification of remotely deposited checks
US20080228621A1 (en) * 2007-03-16 2008-09-18 Johnson James C System And Method For Transfer Of Dispute Data In A Distributed Electronic Trading System
US7769675B2 (en) 2007-04-02 2010-08-03 Bgc Partners, Inc. Test trading
US7711633B2 (en) 2007-04-02 2010-05-04 Bgc Partners, Inc. Apparatus and methods to use test orders to determine locking preferences
US7747516B2 (en) * 2007-04-02 2010-06-29 Bgc Partners, Inc. Apparatus and methods for differentiating trading orders
US7716120B2 (en) * 2007-04-02 2010-05-11 Bgc Partners, Inc. Apparatus and methods for placing and transmitting trading orders
US20080249788A1 (en) * 2007-04-05 2008-10-09 Stephen Heller Method for developing an objective opinion
WO2008123870A1 (en) * 2007-04-06 2008-10-16 Chicago Mercantile Exchange, Inc. Factorization of interest rate swap variation
WO2008124712A1 (en) 2007-04-09 2008-10-16 Pricelock, Inc. System and method for constraining depletion amount in a defined time frame
US7945500B2 (en) 2007-04-09 2011-05-17 Pricelock, Inc. System and method for providing an insurance premium for price protection
WO2008124710A1 (en) * 2007-04-09 2008-10-16 Pricelock, Inc. System and method for risk acceptance in the provisioning of price protection products
US8117105B2 (en) * 2007-04-18 2012-02-14 Pulse Trading, Inc. Systems and methods for facilitating electronic securities transactions
US8521627B2 (en) * 2007-04-18 2013-08-27 Blockross Holdings, LLC Systems and methods for facilitating electronic securities transactions
AU2007201985B2 (en) * 2007-05-03 2012-03-01 Intercapital Management Services No. 2 Limited Method and system for offset matching
US8566216B1 (en) * 2007-05-03 2013-10-22 Jpmorgan Chase Bank, N.A. System and method for trading exposure clearing house
US8433127B1 (en) 2007-05-10 2013-04-30 United Services Automobile Association (Usaa) Systems and methods for real-time validation of check image quality
US8538124B1 (en) 2007-05-10 2013-09-17 United Services Auto Association (USAA) Systems and methods for real-time validation of check image quality
US8938397B2 (en) * 2007-07-23 2015-01-20 Icap Services North America Llc Systems and methods of facilitating trading of instruments
JP2010534893A (en) 2007-07-26 2010-11-11 パイプライン フィナンシャル グループ インコーポレイティッド Large transaction system and method for providing price improvements to aggressive orders
US8103579B1 (en) 2007-07-26 2012-01-24 Pipeline Financial Group, Inc. Systems and methods regarding targeted dissemination
US20090043686A1 (en) * 2007-08-10 2009-02-12 Archer-Daniels-Midland Company Processing arrangements for biomass byproducts and biomass derivative products
JP2010537277A (en) * 2007-08-14 2010-12-02 オーシャン トモ エルエルシー System and method for valuing and trading intangible assets and intangible legal documents
EP2191430A4 (en) * 2007-08-24 2012-08-01 Creditex Group Inc Systems and methods for volume clearing in online trading of credit derivatives
AU2008293580B2 (en) * 2007-08-24 2012-09-06 Bgc Partners, Inc. Methods and systems for trading options and other derivatives
US8165953B2 (en) 2007-09-04 2012-04-24 Chicago Board Options Exchange, Incorporated System and method for creating and trading a derivative investment instrument over a range of index values
US8494941B2 (en) * 2007-09-25 2013-07-23 Palantir Technologies, Inc. Feature-based similarity measure for market instruments
US9690820B1 (en) 2007-09-27 2017-06-27 Experian Information Solutions, Inc. Database system for triggering event notifications based on updates to database records
US9058512B1 (en) 2007-09-28 2015-06-16 United Services Automobile Association (Usaa) Systems and methods for digital signature detection
US8229833B2 (en) * 2007-09-28 2012-07-24 International Securities Exchange, Llc Simplified quote sharing calculation
US8370248B2 (en) * 2007-10-01 2013-02-05 Chicago Mercantile Exchange, Inc. TBA futures contracts and central counterparty clearing of TBA
US8484115B2 (en) 2007-10-03 2013-07-09 Palantir Technologies, Inc. Object-oriented time series generator
AU2008308630A1 (en) * 2007-10-05 2009-04-09 Pipeline Financial Group, Inc. Method and apparatus for improved electronic trading
WO2009049078A1 (en) * 2007-10-09 2009-04-16 Barclays Global Investors N.A. Investment fund for maximizing a risk-adjusted expected return while providing a defined minimum income at maturity
US8060421B1 (en) 2007-10-17 2011-11-15 The Mathworks, Inc. Object oriented financial analysis tool
US8358826B1 (en) 2007-10-23 2013-01-22 United Services Automobile Association (Usaa) Systems and methods for receiving and orienting an image of one or more checks
US9898778B1 (en) 2007-10-23 2018-02-20 United Services Automobile Association (Usaa) Systems and methods for obtaining an image of a check to be deposited
US9892454B1 (en) 2007-10-23 2018-02-13 United Services Automobile Association (Usaa) Systems and methods for obtaining an image of a check to be deposited
US9159101B1 (en) 2007-10-23 2015-10-13 United Services Automobile Association (Usaa) Image processing
US20090111594A1 (en) * 2007-10-29 2009-04-30 Spence Charles H Billiards practice device
US8046301B1 (en) 2007-10-30 2011-10-25 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US7996314B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US8001051B1 (en) 2007-10-30 2011-08-16 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US7996316B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association Systems and methods to modify a negotiable instrument
US7996315B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US8320657B1 (en) 2007-10-31 2012-11-27 United Services Automobile Association (Usaa) Systems and methods to use a digital camera to remotely deposit a negotiable instrument
US8290237B1 (en) 2007-10-31 2012-10-16 United Services Automobile Association (Usaa) Systems and methods to use a digital camera to remotely deposit a negotiable instrument
US7900822B1 (en) 2007-11-06 2011-03-08 United Services Automobile Association (Usaa) Systems, methods, and apparatus for receiving images of one or more checks
US7896232B1 (en) 2007-11-06 2011-03-01 United Services Automobile Association (Usaa) Systems, methods, and apparatus for receiving images of one or more checks
US20090204534A1 (en) * 2007-11-09 2009-08-13 Tilly Edward T Method and system for providing order routing to a virtual crowd in a hybrid trading system and executing an entire order
US8249972B2 (en) 2007-11-09 2012-08-21 Chicago Board Options Exchange, Incorporated Method and system for creating a volatility benchmark index
JP5139535B2 (en) * 2007-11-14 2013-02-06 クレディテックス グループ,インコーポレイティド Techniques to reduce the delta value of credit risk positions in online trading of credit derivatives
US7996521B2 (en) 2007-11-19 2011-08-09 Experian Marketing Solutions, Inc. Service for mapping IP addresses to user segments
US7991686B1 (en) 2007-11-20 2011-08-02 Dc Energy Llc Computer system for an auction exchange for financially settled contracts
US7676424B2 (en) 2007-11-20 2010-03-09 Dc Energy Llc Auction for financially settled contracts
SE532268C2 (en) * 2007-12-04 2009-11-24 Accumulate Ab Procedure for secure transactions
US20090150277A1 (en) * 2007-12-06 2009-06-11 Cinnober Financial Technology Ab Automated Trading System with Position Keeping
US8460085B2 (en) 2007-12-21 2013-06-11 Cfph, Llc System and method for providing a roulette game based on financial market indicators
US8535140B2 (en) 2007-12-21 2013-09-17 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US8758108B2 (en) * 2007-12-21 2014-06-24 Cfph, Llc System and method for slot machine game associated with market line wagers
US10332332B2 (en) * 2007-12-21 2019-06-25 Cfph, Llc System and method for slot machine game associated with financial market indicators
US8117110B2 (en) * 2007-12-27 2012-02-14 Chicago Mercantile Exchange Inc. Conversion of over-the-counter swaps to standardized forward swaps
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US7766244B1 (en) 2007-12-31 2010-08-03 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US20090177555A1 (en) * 2008-01-02 2009-07-09 Milgrom Paul R Assignment exchange and auction
US20090182658A1 (en) * 2008-01-14 2009-07-16 Lutnick Howard W Automatic financial instrument transaction system
EP2245587A4 (en) * 2008-01-09 2012-09-26 Bgc Partners Inc Automatic financial instrument transaction system
US10380562B1 (en) 2008-02-07 2019-08-13 United Services Automobile Association (Usaa) Systems and methods for mobile deposit of negotiable instruments
US8160952B1 (en) 2008-02-12 2012-04-17 Pricelock, Inc. Method and system for providing price protection related to the purchase of a commodity
US11257330B2 (en) 2008-02-15 2022-02-22 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US8255302B2 (en) * 2008-02-28 2012-08-28 Morgan Stanley System and methods for modeling a multiplicative index
WO2009126638A2 (en) * 2008-04-08 2009-10-15 Pipeline Financial Group, Inc. Block trading system and method providing price improvement to aggressive orders
US7974741B2 (en) * 2008-04-10 2011-07-05 Dresser, Inc. Managing information related to industrial equipment
US8224741B2 (en) 2008-04-28 2012-07-17 International Securities Exchange, Llc Complex order leg synchronization
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US8351678B1 (en) 2008-06-11 2013-01-08 United Services Automobile Association (Usaa) Duplicate check detection
US8566185B2 (en) * 2008-06-26 2013-10-22 Sap Ag Managing consistent interfaces for financial instrument business objects across heterogeneous systems
WO2010013018A1 (en) * 2008-08-01 2010-02-04 Icap Plc Clearing and settlement of trades in over the counter markets
US7970670B2 (en) * 2008-08-05 2011-06-28 Exchange Holdings Inc. Electronic credit default futures market
US8321328B2 (en) * 2008-08-05 2012-11-27 Exchange Holdings Inc. Electronic credit default futures market
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
KR20100085093A (en) * 2008-08-28 2010-07-28 가부시키가이샤 머니 스퀘어 재팬 Transaction management device and readable storage medium
US8972885B2 (en) * 2008-08-29 2015-03-03 8X8, Inc. Networked contact center user interface
US8422758B1 (en) 2008-09-02 2013-04-16 United Services Automobile Association (Usaa) Systems and methods of check re-presentment deterrent
US10504185B1 (en) * 2008-09-08 2019-12-10 United Services Automobile Association (Usaa) Systems and methods for live video financial deposit
US20100070426A1 (en) 2008-09-15 2010-03-18 Palantir Technologies, Inc. Object modeling for exploring large data sets
US10747952B2 (en) 2008-09-15 2020-08-18 Palantir Technologies, Inc. Automatic creation and server push of multiple distinct drafts
US7885880B1 (en) 2008-09-30 2011-02-08 United Services Automobile Association (Usaa) Atomic deposit transaction
US7962411B1 (en) 2008-09-30 2011-06-14 United Services Automobile Association (Usaa) Atomic deposit transaction
US7974899B1 (en) 2008-09-30 2011-07-05 United Services Automobile Association (Usaa) Atomic deposit transaction
US8275710B1 (en) 2008-09-30 2012-09-25 United Services Automobile Association (Usaa) Systems and methods for automatic bill pay enrollment
US8788381B2 (en) 2008-10-08 2014-07-22 Chicago Board Options Exchange, Incorporated System and method for creating and trading a digital derivative investment instrument
US20100094772A1 (en) * 2008-10-14 2010-04-15 Thomas Pechy Peterffy Computerized method and system for scale trading
US10311519B2 (en) 2008-10-14 2019-06-04 Interactive Brokers Llc Computerized method and system for accumulation and distribution of securities
US8391599B1 (en) 2008-10-17 2013-03-05 United Services Automobile Association (Usaa) Systems and methods for adaptive binarization of an image
US7949587B1 (en) 2008-10-24 2011-05-24 United States Automobile Association (USAA) Systems and methods for financial deposits by electronic message
US7970677B1 (en) 2008-10-24 2011-06-28 United Services Automobile Association (Usaa) Systems and methods for financial deposits by electronic message
US8271345B1 (en) * 2008-12-22 2012-09-18 Auctionomics Inc. Systems and method for incorporating bidder budgets in multi-item auctions
JP5194132B2 (en) * 2008-12-26 2013-05-08 株式会社マネースクウェア・ジャパン Transaction management apparatus and program
US20100174638A1 (en) 2009-01-06 2010-07-08 ConsumerInfo.com Report existence monitoring
US20110137785A1 (en) * 2009-12-04 2011-06-09 Lutnick Howard W Multicomputer distributed processing of trading information
US8452689B1 (en) 2009-02-18 2013-05-28 United Services Automobile Association (Usaa) Systems and methods of check detection
US10956728B1 (en) 2009-03-04 2021-03-23 United Services Automobile Association (Usaa) Systems and methods of check processing with background removal
CN102439868B (en) * 2009-03-16 2014-09-17 华为技术有限公司 Method, communication system and related equipments for data transmission
US20100287032A1 (en) * 2009-05-07 2010-11-11 Roy Wallace Systems and methods for matching desired purchases and sales of mis-matched items
US8639920B2 (en) 2009-05-11 2014-01-28 Experian Marketing Solutions, Inc. Systems and methods for providing anonymized user profile data
US8744945B2 (en) 2009-05-19 2014-06-03 Trading Technologies International, Inc. System and method for displaying trade information for electronic trading exchange
US20100312716A1 (en) * 2009-06-08 2010-12-09 Richard Lane System and Method for Conditional Modification of Buy and Sell Orders in Electronic Trading Exchange
US20110040667A1 (en) * 2009-07-16 2011-02-17 Anthony Montesano Exchange trading system and method having a modified participation entitlement
US8542921B1 (en) 2009-07-27 2013-09-24 United Services Automobile Association (Usaa) Systems and methods for remote deposit of negotiable instrument using brightness correction
US9779392B1 (en) 2009-08-19 2017-10-03 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a publishing and subscribing platform of depositing negotiable instruments
US8977571B1 (en) 2009-08-21 2015-03-10 United Services Automobile Association (Usaa) Systems and methods for image monitoring of check during mobile deposit
US20110046969A1 (en) * 2009-08-24 2011-02-24 Mark Carlson Alias hierarchy and data structure
US8699779B1 (en) 2009-08-28 2014-04-15 United Services Automobile Association (Usaa) Systems and methods for alignment of check during mobile deposit
US8321322B2 (en) 2009-09-28 2012-11-27 Chicago Board Options Exchange, Incorporated Method and system for creating a spot price tracker index
US9652803B2 (en) 2009-10-20 2017-05-16 Trading Technologies International, Inc. Virtualizing for user-defined algorithm electronic trading
US10853877B2 (en) 2009-10-26 2020-12-01 Trading Technologies International, Inc. Lean level support for trading strategies
WO2011058581A2 (en) * 2009-11-11 2011-05-19 Fidelity Business Services India Private Limited An improved performance testing tool for financial applications
US20110119190A1 (en) * 2009-11-18 2011-05-19 Magid Joseph Mina Anonymous transaction payment systems and methods
US20110145117A1 (en) * 2009-12-15 2011-06-16 Chicago Mercantile Exchange Inc. Clearing System That Determines Settlement Prices of Derivatives in Financial Portfolios
US10592902B2 (en) * 2010-01-22 2020-03-17 Verient Inc. Systems and methods for enhanced transaction processing
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8447641B1 (en) 2010-03-29 2013-05-21 Jpmorgan Chase Bank, N.A. System and method for automatically enrolling buyers into a network
US8577782B2 (en) 2010-04-08 2013-11-05 Christopher R. Petruzzi Trading with conditional offers for semi-anonymous participants
US8725613B1 (en) 2010-04-27 2014-05-13 Experian Information Solutions, Inc. Systems and methods for early account score and notification
US9129340B1 (en) 2010-06-08 2015-09-08 United Services Automobile Association (Usaa) Apparatuses, methods and systems for remote deposit capture with enhanced image detection
US20110320300A1 (en) * 2010-06-23 2011-12-29 Managed Audience Share Solutions LLC Methods, Systems, and Computer Program Products For Managing Organized Binary Advertising Asset Markets
US8510206B2 (en) 2010-07-26 2013-08-13 Trading Technologies International, Inc. Consolidated price level expansion
US8732065B1 (en) * 2010-07-27 2014-05-20 Finalta, Inc. Electronic trading system and method
US8370245B2 (en) * 2010-08-20 2013-02-05 Nicholas Langdon Gunther Electronic information and analysis system
US11100577B1 (en) 2010-08-20 2021-08-24 Nex Services North America Llc Anonymous trading system
US9152727B1 (en) 2010-08-23 2015-10-06 Experian Marketing Solutions, Inc. Systems and methods for processing consumer information for targeted marketing applications
US8589288B1 (en) 2010-10-01 2013-11-19 Jpmorgan Chase Bank, N.A. System and method for electronic remittance of funds
WO2012047988A2 (en) * 2010-10-05 2012-04-12 Tullett Prebon Americas Corp. Derivative fixing matching system and method with greater liquidity
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US8566220B2 (en) 2011-01-26 2013-10-22 Trading Technologies International, Inc. Block placing tool for building a user-defined algorithm for electronic trading
US9037637B2 (en) 2011-02-15 2015-05-19 J.D. Power And Associates Dual blind method and system for attributing activity to a user
US10453131B2 (en) * 2011-02-28 2019-10-22 Nyse Group, Inc. Apparatuses, methods and systems for a locked-in trade facilitation engine
US8543503B1 (en) 2011-03-30 2013-09-24 Jpmorgan Chase Bank, N.A. Systems and methods for automated invoice entry
US8543504B1 (en) 2011-03-30 2013-09-24 Jpmorgan Chase Bank, N.A. Systems and methods for automated invoice entry
US8407128B2 (en) * 2011-04-08 2013-03-26 Atlas Risk Advisory Ltd Systems and methods for foreign exchange risk management
US20120265666A1 (en) * 2011-04-13 2012-10-18 Trueex Group Llc Method and system for interest rate swaps
US20140040163A1 (en) * 2012-04-17 2014-02-06 Trueex Group Llc System and Method for Managing Derivative Instruments
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US10552929B2 (en) * 2011-06-17 2020-02-04 Chicago Mercantile Exchange Inc. Facilitation of accrual based payments between counterparties by a central counterparty
US8732574B2 (en) 2011-08-25 2014-05-20 Palantir Technologies, Inc. System and method for parameterizing documents for automatic workflow generation
US8862767B2 (en) 2011-09-02 2014-10-14 Ebay Inc. Secure elements broker (SEB) for application communication channel selector optimization
US8533104B2 (en) 2011-10-07 2013-09-10 Trading Technologies International, Inc Multi-broker order routing based on net position
US8442859B1 (en) * 2011-12-23 2013-05-14 Managed Audience Share Solutions LLC Methods, systems, and computer program products for optimizing liquidity and price discovery in advertising markets
US10380565B1 (en) 2012-01-05 2019-08-13 United Services Automobile Association (Usaa) System and method for storefront bank deposits
US20130297531A1 (en) * 2012-05-02 2013-11-07 Imageworks Interactive Device for modifying various types of assets
JP6082458B2 (en) 2012-05-09 2017-02-15 アップル インコーポレイテッド Device, method, and graphical user interface for providing tactile feedback of actions performed within a user interface
WO2013169843A1 (en) 2012-05-09 2013-11-14 Yknots Industries Llc Device, method, and graphical user interface for manipulating framed graphical objects
WO2013169851A2 (en) 2012-05-09 2013-11-14 Yknots Industries Llc Device, method, and graphical user interface for facilitating user interaction with controls in a user interface
WO2013169875A2 (en) 2012-05-09 2013-11-14 Yknots Industries Llc Device, method, and graphical user interface for displaying content associated with a corresponding affordance
JP6273263B2 (en) 2012-05-09 2018-01-31 アップル インコーポレイテッド Device, method, and graphical user interface for displaying additional information in response to user contact
WO2013169842A2 (en) 2012-05-09 2013-11-14 Yknots Industries Llc Device, method, and graphical user interface for selecting object within a group of objects
WO2013169865A2 (en) 2012-05-09 2013-11-14 Yknots Industries Llc Device, method, and graphical user interface for moving a user interface object based on an intensity of a press input
WO2013169845A1 (en) 2012-05-09 2013-11-14 Yknots Industries Llc Device, method, and graphical user interface for scrolling nested regions
WO2013169854A2 (en) 2012-05-09 2013-11-14 Yknots Industries Llc Device, method, and graphical user interface for providing feedback for changing activation states of a user interface object
WO2013169849A2 (en) 2012-05-09 2013-11-14 Industries Llc Yknots Device, method, and graphical user interface for displaying user interface objects corresponding to an application
KR101683868B1 (en) 2012-05-09 2016-12-07 애플 인크. Device, method, and graphical user interface for transitioning between display states in response to gesture
CN108052264B (en) 2012-05-09 2021-04-27 苹果公司 Device, method and graphical user interface for moving and placing user interface objects
CN109062488B (en) 2012-05-09 2022-05-27 苹果公司 Apparatus, method and graphical user interface for selecting user interface objects
US9348677B2 (en) 2012-10-22 2016-05-24 Palantir Technologies Inc. System and method for batch evaluation programs
US20140149148A1 (en) * 2012-11-27 2014-05-29 Terrance Luciani System and method for autonomous insurance selection
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US10552810B1 (en) 2012-12-19 2020-02-04 United Services Automobile Association (Usaa) System and method for remote deposit of financial instruments
JP6138274B2 (en) 2012-12-29 2017-05-31 アップル インコーポレイテッド Device, method and graphical user interface for navigating a user interface hierarchy
EP2939096B1 (en) 2012-12-29 2019-08-28 Apple Inc. Device, method, and graphical user interface for determining whether to scroll or select contents
AU2013368443B2 (en) 2012-12-29 2016-03-24 Apple Inc. Device, method, and graphical user interface for transitioning between touch input to display output relationships
CN105144057B (en) 2012-12-29 2019-05-17 苹果公司 For moving the equipment, method and graphic user interface of cursor according to the cosmetic variation of the control icon with simulation three-dimensional feature
AU2013368441B2 (en) 2012-12-29 2016-04-14 Apple Inc. Device, method, and graphical user interface for forgoing generation of tactile output for a multi-contact gesture
US20140249991A1 (en) * 2013-03-04 2014-09-04 Joseph Peter MacInnis Computer implemented finance management routing system
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US8868486B2 (en) 2013-03-15 2014-10-21 Palantir Technologies Inc. Time-sensitive cube
US8903717B2 (en) 2013-03-15 2014-12-02 Palantir Technologies Inc. Method and system for generating a parser and parsing complex data
US8909656B2 (en) 2013-03-15 2014-12-09 Palantir Technologies Inc. Filter chains with associated multipath views for exploring large data sets
US8930897B2 (en) 2013-03-15 2015-01-06 Palantir Technologies Inc. Data integration tool
US10410284B1 (en) * 2013-03-15 2019-09-10 Global Liquid Markets, LLC Trading money market instruments
US8855999B1 (en) 2013-03-15 2014-10-07 Palantir Technologies Inc. Method and system for generating a parser and parsing complex data
US10037530B2 (en) * 2013-06-13 2018-07-31 Paypal, Inc. Payment recipient verification
US20140372279A1 (en) * 2013-06-14 2014-12-18 Aquilon Energy Services, Inc. Energy collaboration platform
US10664548B2 (en) 2013-07-12 2020-05-26 Trading Technologies International, Inc. Tailored messaging
US11138578B1 (en) 2013-09-09 2021-10-05 United Services Automobile Association (Usaa) Systems and methods for remote deposit of currency
US8938686B1 (en) 2013-10-03 2015-01-20 Palantir Technologies Inc. Systems and methods for analyzing performance of an entity
US9286514B1 (en) 2013-10-17 2016-03-15 United Services Automobile Association (Usaa) Character count determination for a digital image
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage
US9105000B1 (en) 2013-12-10 2015-08-11 Palantir Technologies Inc. Aggregating data from a plurality of data sources
US9704170B2 (en) * 2014-01-01 2017-07-11 Bank Of America Corporation Method for tracking items using a fund processing device
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US10475123B2 (en) * 2014-03-17 2019-11-12 Chicago Mercantile Exchange Inc. Coupon blending of swap portfolio
US8924429B1 (en) 2014-03-18 2014-12-30 Palantir Technologies Inc. Determining and extracting changed data from a data source
WO2015142389A1 (en) * 2014-03-19 2015-09-24 Lch. Clearnte Limited Systems, methods, and media for reducing aggregate portfolio statistics
US10410142B1 (en) * 2014-05-06 2019-09-10 United Services Automobile Association (Usaa) Integrated risk analysis management
US10319032B2 (en) 2014-05-09 2019-06-11 Chicago Mercantile Exchange Inc. Coupon blending of a swap portfolio
US11257117B1 (en) 2014-06-25 2022-02-22 Experian Information Solutions, Inc. Mobile device sighting location analytics and profiling system
US10810671B2 (en) 2014-06-27 2020-10-20 Chicago Mercantile Exchange Inc. Interest rate swap compression
JP5951907B1 (en) * 2014-09-12 2016-07-13 エブリセンス インク Information brokerage system
EP3016058A1 (en) 2014-10-31 2016-05-04 Chicago Mercantile Exchange, Inc. Generating a blended fx portfolio
US10242019B1 (en) 2014-12-19 2019-03-26 Experian Information Solutions, Inc. User behavior segmentation using latent topic detection
US10048757B2 (en) 2015-03-08 2018-08-14 Apple Inc. Devices and methods for controlling media presentation
US10095396B2 (en) 2015-03-08 2018-10-09 Apple Inc. Devices, methods, and graphical user interfaces for interacting with a control object while dragging another object
US9645732B2 (en) 2015-03-08 2017-05-09 Apple Inc. Devices, methods, and graphical user interfaces for displaying and using menus
US9785305B2 (en) 2015-03-19 2017-10-10 Apple Inc. Touch input cursor manipulation
US20170045981A1 (en) 2015-08-10 2017-02-16 Apple Inc. Devices and Methods for Processing Touch Inputs Based on Their Intensities
US10402790B1 (en) 2015-05-28 2019-09-03 United Services Automobile Association (Usaa) Composing a focused document image from multiple image captures or portions of multiple image captures
US9674426B2 (en) 2015-06-07 2017-06-06 Apple Inc. Devices and methods for capturing and interacting with enhanced digital images
US9860451B2 (en) 2015-06-07 2018-01-02 Apple Inc. Devices and methods for capturing and interacting with enhanced digital images
US10565646B2 (en) 2015-08-05 2020-02-18 Trading Technologies International, Inc. Methods and apparatus to internalize trade orders
US10572939B1 (en) * 2015-08-28 2020-02-25 Chicago Mercantile Exchange Inc. API framework for clearing non-deliverable interest rate swaps
US11410230B1 (en) 2015-11-17 2022-08-09 Consumerinfo.Com, Inc. Realtime access and control of secure regulated data
US9767309B1 (en) 2015-11-23 2017-09-19 Experian Information Solutions, Inc. Access control system for implementing access restrictions of regulated database records while identifying and providing indicators of regulated database records matching validation criteria
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
JP7362251B2 (en) * 2016-07-01 2023-10-17 シーエフピーエイチ, エル.エル.シー. Interface for landing position options
US10678894B2 (en) 2016-08-24 2020-06-09 Experian Information Solutions, Inc. Disambiguation and authentication of device users
EP3340139A1 (en) * 2016-12-22 2018-06-27 Mastercard International Incorporated Amount confirmation for visually impaired users
US11082351B2 (en) 2017-01-05 2021-08-03 Chicago Mercantile Exchange Inc. Network congestion reduction based on routing and matching data packets
US20180218444A1 (en) * 2017-01-20 2018-08-02 Opendoor Securities, Llc Method And Platform For Matching Buy And Sell Orders
WO2018136089A1 (en) * 2017-01-20 2018-07-26 Opendoor Securities, Llc Method and platform for matching buying and selling orders
WO2018144612A1 (en) 2017-01-31 2018-08-09 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US10609172B1 (en) 2017-04-27 2020-03-31 Chicago Mercantile Exchange Inc. Adaptive compression of stored data
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US11042933B1 (en) 2017-10-17 2021-06-22 Chicago Mercantile Exchange Inc. System for processing withholding payments
US11030752B1 (en) 2018-04-27 2021-06-08 United Services Automobile Association (Usaa) System, computing device, and method for document detection
US10880313B2 (en) 2018-09-05 2020-12-29 Consumerinfo.Com, Inc. Database platform for realtime updating of user data from third party sources
US11556925B2 (en) * 2018-09-12 2023-01-17 International Business Machines Corporation Ensuring information fairness and input privacy using a blockchain in a competitive scenario governed by a smart contract
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
US10979306B2 (en) 2019-06-07 2021-04-13 Bank Of America Corporation System for backend resource management simulation and live deployment
CN112446578A (en) * 2019-09-04 2021-03-05 京东数字科技控股有限公司 Risk monitoring method and device
US11710181B1 (en) * 2020-01-10 2023-07-25 Cboe Exchange, Inc. Exchange risk controls
US11682041B1 (en) 2020-01-13 2023-06-20 Experian Marketing Solutions, Llc Systems and methods of a tracking analytics platform
US11900755B1 (en) 2020-11-30 2024-02-13 United Services Automobile Association (Usaa) System, computing device, and method for document detection and deposit processing
US11907207B1 (en) 2021-10-12 2024-02-20 Chicago Mercantile Exchange Inc. Compression of fluctuating data
US20230262032A1 (en) * 2022-02-11 2023-08-17 Refinitiv Us Organization Llc Obfuscation of input data values into observable data values using symbology-based encodings
US20230298096A1 (en) * 2022-03-18 2023-09-21 Mikael Tjarnberg Hedging scaling system for an investor equity portfolio using a trading platform and method of use thereof

Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3581072A (en) * 1968-03-28 1971-05-25 Frederick Nymeyer Auction market computation system
US4674044A (en) * 1985-01-30 1987-06-16 Merrill Lynch, Pierce, Fenner & Smith, Inc. Automated securities trading system
US4677552A (en) * 1984-10-05 1987-06-30 Sibley Jr H C International commodity trade exchange
US4903201A (en) * 1983-11-03 1990-02-20 World Energy Exchange Corporation Automated futures trading exchange
US4953085A (en) * 1987-04-15 1990-08-28 Proprietary Financial Products, Inc. System for the operation of a financial account
US4980826A (en) * 1983-11-03 1990-12-25 World Energy Exchange Corporation Voice actuated automated futures trading exchange
US5003473A (en) * 1988-10-24 1991-03-26 Reuters Limited Trading ticket output system
US5077665A (en) * 1989-05-25 1991-12-31 Reuters Limited Distributed matching system
US5126936A (en) * 1989-09-01 1992-06-30 Champion Securities Goal-directed financial asset management system
US5136501A (en) * 1989-05-26 1992-08-04 Reuters Limited Anonymous matching system
US5168446A (en) * 1989-05-23 1992-12-01 Telerate Systems Incorporated System for conducting and processing spot commodity transactions
US5193056A (en) * 1991-03-11 1993-03-09 Signature Financial Group Inc. Data processing system for hub and spoke financial services configuration
US5258908A (en) * 1990-11-02 1993-11-02 Foreign Exchange Transaction Services, Inc. Detection and prevention of duplicate trading transactions over a communications network
US5285383A (en) * 1990-09-14 1994-02-08 Plains Cotton Cooperative Association Method for carrying out transactions of goods using electronic title
US5297031A (en) * 1990-03-06 1994-03-22 Chicago Board Of Trade Method and apparatus for order management by market brokers
US5375055A (en) * 1992-02-03 1994-12-20 Foreign Exchange Transaction Services, Inc. Credit management for electronic brokerage system
US5396552A (en) * 1991-03-12 1995-03-07 Siemens Aktiengesellschaft Digital communication system with transmission servers
US5446885A (en) * 1992-05-15 1995-08-29 International Business Machines Corporation Event driven management information system with rule-based applications structure stored in a relational database
US5517406A (en) * 1994-09-01 1996-05-14 The Shareholder Services Group, Inc. Method and apparatus for data verification and position reporting in an automated trade transactions processing system
US5557517A (en) * 1994-07-29 1996-09-17 Daughterty, Iii; Vergil L. System and method for determining the price of an expirationless American option and issuing a buy or sell ticket on the current price and portfolio
US5732400A (en) * 1995-01-04 1998-03-24 Citibank N.A. System and method for a risk-based purchase of goods

Family Cites Families (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US411748A (en) * 1889-09-24 Thomas meikle
US524082A (en) * 1894-08-07 Spike-puller
US6A (en) * 1836-08-10 Thomas blanghard
US628521A (en) * 1898-03-19 1899-07-11 Malcolm Campbell Top roll.
US3573747A (en) 1969-02-24 1971-04-06 Institutional Networks Corp Instinet communication system for effectuating the sale or exchange of fungible properties between subscribers
US5270922A (en) 1984-06-29 1993-12-14 Merrill Lynch & Company, Inc. System for distributing, processing and displaying financial information
US4799156A (en) 1986-10-01 1989-01-17 Strategic Processing Corporation Interactive market management system
US5644727A (en) 1987-04-15 1997-07-01 Proprietary Financial Products, Inc. System for the operation and management of one or more financial accounts through the use of a digital communication and computation system for exchange, investment and borrowing
FR2613981B1 (en) 1987-04-15 1989-10-13 Swisscab E A Schoen Sa METHOD AND HEAD FOR EXTRUDING PROFILES IN SYNTHETIC MATERIAL HAVING COLORED STRIPS
US4904584A (en) * 1987-12-23 1990-02-27 Genetics Institute, Inc. Site-specific homogeneous modification of polypeptides
DE407026T1 (en) 1989-05-25 1991-06-13 Reuters Ltd., London, Gb DISTRIBUTED SYSTEM AND METHOD FOR CONNECTING BUYER AND SELLER.
US5101353A (en) 1989-05-31 1992-03-31 Lattice Investments, Inc. Automated system for providing liquidity to securities markets
EP0411748A3 (en) 1989-06-02 1991-11-21 Reuters Limited System for matching of buyers and sellers with risk minimization
GB9027249D0 (en) 1990-12-17 1991-02-06 Reuters Ltd Offer matching system
EP0512702A3 (en) * 1991-05-03 1993-09-15 Reuters Limited Automated currency trade matching system with integral credit checking
US6985883B1 (en) * 1992-02-03 2006-01-10 Ebs Dealing Resources, Inc. Credit management for electronic brokerage system
US5970479A (en) * 1992-05-29 1999-10-19 Swychco Infrastructure Services Pty. Ltd. Methods and apparatus relating to the formulation and trading of risk management contracts
US6134536A (en) 1992-05-29 2000-10-17 Swychco Infrastructure Services Pty Ltd. Methods and apparatus relating to the formulation and trading of risk management contracts
JPH0619920A (en) 1992-06-30 1994-01-28 Mitsui Eng & Shipbuild Co Ltd Instruction control module
US5794219A (en) 1996-02-20 1998-08-11 Health Hero Network, Inc. Method of conducting an on-line auction with bid pooling
US5794207A (en) 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
AU7671494A (en) 1993-08-23 1995-03-22 Mjt Holdings, Inc. Real-time automated trading system
IT1271484B (en) 1993-10-12 1997-05-28 Alcatel Cavi Spa MODULAR OPTICAL FIBER TAPE, SEPARABLE INTO A PLURALITY OF TAPES OR MODULES, PROCEDURE FOR MANUFACTURING SUCH TAPE AND OPTICAL CABLE USING THE SAME
US5812988A (en) 1993-12-06 1998-09-22 Investments Analytic, Inc. Method and system for jointly estimating cash flows, simulated returns, risk measures and present values for a plurality of assets
US5394324A (en) * 1993-12-08 1995-02-28 Xerox Corporation Auction-based control system for energy resource management in a building
EP0686926A3 (en) 1994-05-24 1996-06-12 Ron S Dembo Method and apparatus for optimal portfolio replication
US5940810A (en) 1994-08-04 1999-08-17 The Trustees Of Columbia University In The City Of New York Estimation method and system for complex securities using low-discrepancy deterministic sequences
GB9416673D0 (en) 1994-08-17 1994-10-12 Reuters Ltd Data exchange filtering system
DK0776505T3 (en) 1994-08-17 2000-09-18 Reuters Ltd System and approach for pooling potential trading partners based on negotiation
US5950175A (en) * 1994-10-14 1999-09-07 Merrill Lynch, Pierce, Fenner & Smith Incorporated System for managing real estate SWAP accounts
US5915209A (en) * 1994-11-21 1999-06-22 Lawrence; David Bond trading system
US6876309B1 (en) * 1994-11-21 2005-04-05 Espeed, Inc. Bond trading system
DE69637799D1 (en) 1995-02-13 2009-02-12 Intertrust Tech Corp Systems and procedures for secure transaction management and electronic legal protection
US5845266A (en) * 1995-12-12 1998-12-01 Optimark Technologies, Inc. Crossing network utilizing satisfaction density profile with price discovery features
IL117424A (en) 1995-04-27 1999-09-22 Optimark Tech Inc Crossing network utilizing satisfaction density profile
US5675637A (en) 1995-05-16 1997-10-07 Inventions, Inc. Method for automatically obtaining and presenting data from multiple data sources
CA2220903A1 (en) * 1995-07-07 1997-01-30 Ian Kenneth Shepherd Methods and apparatus relating to the formulation and trading of investment contracts
US5802499A (en) * 1995-07-13 1998-09-01 Cedel Bank Method and system for providing credit support to parties associated with derivative and other financial transactions
PT847561E (en) 1995-08-28 2004-03-31 Ebs Dealing Resources Inc ANONYMOUS BROKER SYSTEM WITH IMPROVED POSSIBILITIES OF INTRODUCTION OF COTACOES
US5819237A (en) 1996-02-13 1998-10-06 Financial Engineering Associates, Inc. System and method for determination of incremental value at risk for securities trading
US5950176A (en) 1996-03-25 1999-09-07 Hsx, Inc. Computer-implemented securities trading system with a virtual specialist function
US6505174B1 (en) * 1996-03-25 2003-01-07 Hsx, Inc. Computer-implemented securities trading system with a virtual specialist function
US5903695A (en) 1996-03-27 1999-05-11 Lumenyte International Corp. Linear light form with light diverting layer
US5835896A (en) 1996-03-29 1998-11-10 Onsale, Inc. Method and system for processing and transmitting electronic auction information
US5924083A (en) 1996-05-29 1999-07-13 Geneva Branch Of Reuters Transaction Services Limited Distributed matching system for displaying a book of credit filtered bids and offers
US5764896A (en) * 1996-06-28 1998-06-09 Compaq Computer Corporation Method and system for reducing transfer latency when transferring data from a network to a computer system
US6014643A (en) 1996-06-28 2000-01-11 Minton; Vernon F. Interactive securities trading system
US6134600A (en) 1996-07-01 2000-10-17 Sun Microsystems, Inc. Method and apparatus for dynamic derivatives desktops
US6061662A (en) * 1997-08-15 2000-05-09 Options Technology Company, Inc. Simulation method and system for the valuation of derivative financial instruments
US6029146A (en) 1996-08-21 2000-02-22 Crossmar, Inc. Method and apparatus for trading securities electronically
US6247000B1 (en) * 1996-08-21 2001-06-12 Crossmar, Inc. Method and system for confirmation and settlement for financial transactions matching
US6195647B1 (en) * 1996-09-26 2001-02-27 The Nasdaq Stock Market, Inc. On-line transaction processing system for security trading
US5963923A (en) 1996-11-12 1999-10-05 Garber; Howard B. System and method for trading having a principal market maker
US6850907B2 (en) 1996-12-13 2005-02-01 Cantor Fitzgerald, L.P. Automated price improvement protocol processor
US5905974A (en) 1996-12-13 1999-05-18 Cantor Fitzgerald Securities Automated auction protocol processor
US5873071A (en) * 1997-05-15 1999-02-16 Itg Inc. Computer method and system for intermediated exchange of commodities
US6161099A (en) 1997-05-29 2000-12-12 Muniauction, Inc. Process and apparatus for conducting auctions over electronic networks
US20060190383A1 (en) * 2003-03-24 2006-08-24 Blackbird Holdings, Inc. Systems for risk portfolio management
US20020138390A1 (en) * 1997-10-14 2002-09-26 R. Raymond May Systems, methods and computer program products for subject-based addressing in an electronic trading system
US6996540B1 (en) 1997-10-14 2006-02-07 Blackbird Holdings, Inc. Systems for switch auctions utilizing risk position portfolios of a plurality of traders
US5966700A (en) * 1997-12-23 1999-10-12 Federal Home Loan Bank Of Chicago Management system for risk sharing of mortgage pools
JP2000011408A (en) * 1998-06-24 2000-01-14 Pioneer Electron Corp Pickup device of disk player
EP1049037A3 (en) 1999-03-22 2002-07-24 Four Corporation Four Computer system
US6512504B1 (en) * 1999-04-27 2003-01-28 Semiconductor Energy Laborayory Co., Ltd. Electronic device and electronic apparatus
US6629082B1 (en) 1999-06-15 2003-09-30 W.R. Hambrecht & Co. Auction system and method for pricing and allocation during capital formation
US6241653B1 (en) * 1999-07-16 2001-06-05 Isovac Products Llc Isolation apparatus
US6321212B1 (en) 1999-07-21 2001-11-20 Longitude, Inc. Financial products having a demand-based, adjustable return, and trading exchange therefor
US7599877B1 (en) 1999-07-30 2009-10-06 Citibank, N.A. Methods and systems for collateral matching and mark to market reconcilement
US7233923B1 (en) 2000-01-14 2007-06-19 Espeed, Inc. Systems and methods for matching desired purchases and sales of mis-matched items
EP1285382A1 (en) * 2000-05-16 2003-02-26 Blackbird Holdings, Inc. Systems and methods for conducting derivative trades electronically
US20020116317A1 (en) * 2000-06-09 2002-08-22 Blackbird Holdings, Inc. Systems and methods for reverse auction of financial instruments
US7110972B1 (en) * 2000-09-19 2006-09-19 Icor Brokerage, Inc. Method and system of managing credit for the electronic trading of financial instruments
US7613640B2 (en) * 2001-08-29 2009-11-03 Ebs Group Limited Electronic trading system
JP4377655B2 (en) * 2003-11-06 2009-12-02 パナソニック株式会社 Communication job information providing apparatus and document data delivery confirmation method

Patent Citations (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3581072A (en) * 1968-03-28 1971-05-25 Frederick Nymeyer Auction market computation system
US4903201A (en) * 1983-11-03 1990-02-20 World Energy Exchange Corporation Automated futures trading exchange
US4980826A (en) * 1983-11-03 1990-12-25 World Energy Exchange Corporation Voice actuated automated futures trading exchange
US4677552A (en) * 1984-10-05 1987-06-30 Sibley Jr H C International commodity trade exchange
US4674044A (en) * 1985-01-30 1987-06-16 Merrill Lynch, Pierce, Fenner & Smith, Inc. Automated securities trading system
US4953085A (en) * 1987-04-15 1990-08-28 Proprietary Financial Products, Inc. System for the operation of a financial account
US5003473A (en) * 1988-10-24 1991-03-26 Reuters Limited Trading ticket output system
US5168446A (en) * 1989-05-23 1992-12-01 Telerate Systems Incorporated System for conducting and processing spot commodity transactions
US5077665A (en) * 1989-05-25 1991-12-31 Reuters Limited Distributed matching system
US5136501A (en) * 1989-05-26 1992-08-04 Reuters Limited Anonymous matching system
US5126936A (en) * 1989-09-01 1992-06-30 Champion Securities Goal-directed financial asset management system
US5297031A (en) * 1990-03-06 1994-03-22 Chicago Board Of Trade Method and apparatus for order management by market brokers
US5285383A (en) * 1990-09-14 1994-02-08 Plains Cotton Cooperative Association Method for carrying out transactions of goods using electronic title
US5258908A (en) * 1990-11-02 1993-11-02 Foreign Exchange Transaction Services, Inc. Detection and prevention of duplicate trading transactions over a communications network
US5193056A (en) * 1991-03-11 1993-03-09 Signature Financial Group Inc. Data processing system for hub and spoke financial services configuration
US5396552A (en) * 1991-03-12 1995-03-07 Siemens Aktiengesellschaft Digital communication system with transmission servers
US5375055A (en) * 1992-02-03 1994-12-20 Foreign Exchange Transaction Services, Inc. Credit management for electronic brokerage system
US5446885A (en) * 1992-05-15 1995-08-29 International Business Machines Corporation Event driven management information system with rule-based applications structure stored in a relational database
US5630127A (en) * 1992-05-15 1997-05-13 International Business Machines Corporation Program storage device and computer program product for managing an event driven management information system with rule-based application structure stored in a relational database
US5557517A (en) * 1994-07-29 1996-09-17 Daughterty, Iii; Vergil L. System and method for determining the price of an expirationless American option and issuing a buy or sell ticket on the current price and portfolio
US5517406A (en) * 1994-09-01 1996-05-14 The Shareholder Services Group, Inc. Method and apparatus for data verification and position reporting in an automated trade transactions processing system
US5732400A (en) * 1995-01-04 1998-03-24 Citibank N.A. System and method for a risk-based purchase of goods

Cited By (257)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080270290A1 (en) * 1997-05-29 2008-10-30 Muniauction, Inc. Process and apparatus for conducting auctions over electronic networks
US20080294544A1 (en) * 1997-05-29 2008-11-27 Muniauction, Inc. Process and apparatus for conducting auctions over electronic networks
US7523063B2 (en) 1997-05-29 2009-04-21 Muniauction, Inc. Process and apparatus for conducting auctions over electronic networks
US20100179902A1 (en) * 1997-10-14 2010-07-15 Blackbird Holdings, Inc. Systems and methods for performing two-way one-to-many and many-to-many auctions for financial instruments
US20070219882A1 (en) * 1997-10-14 2007-09-20 May R R Systems, methods and computer program products for electronic trading of financial instruments
US20070288346A1 (en) * 1997-10-14 2007-12-13 May R R Systems for risk portfolio management
US20060095363A1 (en) * 1997-10-14 2006-05-04 Blackbird Holdings, Inc. Systems and methods for performing two-way one-to-many and many-to-many auctions for financial instruments
US20100299239A1 (en) * 1997-10-14 2010-11-25 May R Raymond Systems for risk portfolio management
US7966234B1 (en) 1999-05-17 2011-06-21 Jpmorgan Chase Bank. N.A. Structured finance performance analytics system
US11568483B2 (en) 1999-06-14 2023-01-31 Integral Development Corporation System and method for conducting web-based financial transactions in capital markets
US8862507B2 (en) * 1999-06-14 2014-10-14 Integral Development Corporation System and method for conducting web-based financial transactions in capital markets
US11568486B2 (en) 1999-06-14 2023-01-31 Integral Development Corporation System and method for conducting web-based financial transactions in capital markets
US9412134B2 (en) * 1999-06-14 2016-08-09 Integral Development Corporation System and method for conducting web-based financial transactions in capital markets
US20030033212A1 (en) * 1999-06-14 2003-02-13 Sandhu Harpal S. System and method for conducting web-based financial transactions in capital markets
US20150161730A1 (en) * 1999-06-14 2015-06-11 Integral Development Corp. System and method for conducting web-based financial transactions in capital markets
US20070282733A1 (en) * 2000-05-16 2007-12-06 Blackbird Holdings, Inc. Systems and methods for conducting derivative trades electronically
US7761368B2 (en) 2000-05-16 2010-07-20 Blackbird Holdings, Inc. Systems and methods for conducting derivative trades electronically
US7680731B1 (en) 2000-06-07 2010-03-16 Jpmorgan Chase Bank, N.A. System and method for executing deposit transactions over the internet
US7680732B1 (en) 2000-06-07 2010-03-16 Jpmorgan Chase Bank, N.A. System and method for executing deposit transactions over the internet
US20070239591A1 (en) * 2000-06-09 2007-10-11 Blackbird Holdings, Inc. Systems and methods for reverse auction of financial instruments
US7409366B1 (en) * 2000-08-22 2008-08-05 Etp Holdings, Inc. Apparatus and method for adding liquidity to an ECN and improving executions of orders for securities
US7337140B2 (en) 2000-10-30 2008-02-26 Chicago Mercantile Exchange, Inc. Network and method for trading derivatives
US20080027851A1 (en) * 2000-10-30 2008-01-31 Chicago Mercantile Exchange Network and method for trading derivatives
US8484103B2 (en) 2000-10-30 2013-07-09 Chicago Mercantile Exchange Inc. Network and method for trading derivatives
US7818248B2 (en) 2000-10-30 2010-10-19 Chicago Mercantile Exchange Inc. Network and method for trading derivatives
US11526940B2 (en) 2000-10-31 2022-12-13 Integral Development Corporation System and method for conducting web-based financial transactions in capital markets
US6950806B2 (en) * 2000-11-02 2005-09-27 Cargill, Inc. Sales transactions for transfer of commodities
US6988083B2 (en) * 2000-11-02 2006-01-17 Cargill, Inc. Sales transactions for transfer of agricultural products
US7890407B2 (en) 2000-11-03 2011-02-15 Jpmorgan Chase Bank, N.A. System and method for estimating conduit liquidity requirements in asset backed commercial paper
US20020188553A1 (en) * 2001-04-16 2002-12-12 Blauvelt Joseph P. System and method for managing a series of overnight financing trades
US20020198833A1 (en) * 2001-05-03 2002-12-26 Jacob Wohlstadter Method and system of exchanging and deriving economic benefit from exchanging securities
US7409367B2 (en) 2001-05-04 2008-08-05 Delta Rangers Inc. Derivative securities and system for trading same
US20030009415A1 (en) * 2001-05-14 2003-01-09 Lutnick Howard W. Methods and systems for trading futures contracts for intangible assets
US20130132253A1 (en) * 2001-05-14 2013-05-23 Howard W. Lutnick Cf-30: methods and systems for trading of futures contracts for intangible assets
US20030088499A1 (en) * 2001-06-01 2003-05-08 Gilbert Andrew C. Systems and methods for electronic trading that permit principal/broker trading
US20140101019A1 (en) * 2001-06-01 2014-04-10 Bgc Partners, Inc. Systems and methods for electronic trading that permit principal/broker trading
US8886561B2 (en) * 2001-06-01 2014-11-11 Bgc Partners, Inc. Electronic trading among principals and brokers
US10438286B2 (en) * 2001-06-01 2019-10-08 Bgc Partners, Inc. System and methods for electronic trading that permit principal/broker trading
US20150066736A1 (en) * 2001-06-01 2015-03-05 Bgc Partners, Inc. System and methods for electronic trading that permit principal/broker trading
US8494949B2 (en) * 2001-06-01 2013-07-23 Bgc Partners, Inc. Electronic trading for principal/broker trading
US20040030632A1 (en) * 2002-03-22 2004-02-12 Andrew Hausman Variable pricing for and conditional availability of proposals for trading of financial interests
US8019665B2 (en) * 2002-03-22 2011-09-13 Bloomberg L.P. Variable pricing for and conditional availability of proposals for trading of financial interests
US20040111356A1 (en) * 2002-05-17 2004-06-10 Vikas Srivastava Method and system for executing foreign exchange transactions
US8548886B1 (en) 2002-05-31 2013-10-01 Jpmorgan Chase Bank, N.A. Account opening system, method and computer program product
US8756136B2 (en) 2002-08-02 2014-06-17 Jpmorgan Chase Bank, N.A. Synthetic funds having structured notes
US20090299893A1 (en) * 2002-10-15 2009-12-03 Chicago Mercantile Exchange, Inc. Method and system for providing option spread indicative quotes
US8799136B2 (en) 2002-10-15 2014-08-05 Chicago Mercantile Exchange Inc. Method and system for providing option spread indicative quotes
US7272580B2 (en) 2002-10-15 2007-09-18 Chicago Mercantile Exchange, Inc. Network and method for trading derivatives by providing enhanced RFQ visibility
US8494947B2 (en) 2002-10-15 2013-07-23 Chicago Mercantile Exchange Inc. Method and system for providing option spread indicative quotes
US20070118462A1 (en) * 2002-10-15 2007-05-24 Chicago Mercantile Exchange Network and method for trading derivatives by providing enhanced RFQ visibility
US8306902B2 (en) 2002-10-15 2012-11-06 Chicago Mercantile Exchange Inc. Method and system for providing option spread indicative quotes
US7197483B2 (en) 2002-10-15 2007-03-27 Chicago Mercantile Exchange Network and method for trading derivatives by providing enhanced RFQ visibility
US20050044033A1 (en) * 2003-01-10 2005-02-24 Gelson Andrew F. Like-kind exchange method
US20040148247A1 (en) * 2003-01-24 2004-07-29 Lawrence Miller Network-based systems, methods, and software for initiating or executing financial transactions
US8374942B2 (en) 2003-03-10 2013-02-12 Chicago Mercantile Exchange Inc. Order risk management for financial product processing
US8060431B2 (en) 2003-03-10 2011-11-15 Chicago Mercantile Exchange Inc. Hedging risks associated with variable priced orders for derivative financial products
US7152041B2 (en) 2003-03-10 2006-12-19 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price
US7778911B2 (en) 2003-03-10 2010-08-17 Chicago Mercantile Exchange, Inc. Order risk management for financial product processing
US7991684B2 (en) 2003-03-10 2011-08-02 Chicago Mercantile Exchange, Inc. Order risk management for derivative products
US20080052223A1 (en) * 2003-03-10 2008-02-28 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price and a hedge transaction
US20080086408A1 (en) * 2003-03-10 2008-04-10 Chicago Mercantile Exchange, Inc. Order Risk Management for Derivative Products
US20040199459A1 (en) * 2003-03-10 2004-10-07 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price and a hedge transaction
US8751361B2 (en) 2003-03-10 2014-06-10 Chicago Mercantile Exchange Inc. Hedging risks associated with variable priced orders for derivative financial products
US7571133B2 (en) 2003-03-10 2009-08-04 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price and a hedge transaction
US9911157B2 (en) 2003-03-10 2018-03-06 Chicago Mercantile Exchange Inc. Derivatives trading methods that use a variable order price
US20040199450A1 (en) * 2003-03-10 2004-10-07 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price
US7440917B2 (en) 2003-03-10 2008-10-21 Chicago Mercantile Exchange, Inc. Order risk management system
US7672899B2 (en) 2003-03-10 2010-03-02 Chicago Mercantile Exchange, Inc. Hedge transactions using variable order prices
US8738508B2 (en) 2003-03-10 2014-05-27 Chicago Mercantile Exchange Inc. Order risk management for financial product processing
US20100306133A1 (en) * 2003-03-10 2010-12-02 Chicago Mercantile Exchange, Inc. Order Risk Management for Financial Product Processing
US8160949B2 (en) 2003-03-10 2012-04-17 Chicago Mercantile Exchange, Inc. Order risk management for financial product processing
US8224737B2 (en) 2003-03-10 2012-07-17 Chicago Mercantile Exchange Inc. Hedging risks associated with variable priced orders for derivative financial products
US7567932B1 (en) 2003-03-10 2009-07-28 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price
US8688567B2 (en) 2003-03-10 2014-04-01 Chicago Mercantile Exchange Inc. Order risk management for derivative products
US8630941B2 (en) 2003-03-10 2014-01-14 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price and a hedge transaction
US10366454B2 (en) 2003-03-10 2019-07-30 Chicago Mercantile Exchange Inc. Order risk management for derivative products
US8326738B2 (en) 2003-03-10 2012-12-04 Chicago Mercantile Exchange Inc. Order risk management for derivative products
US8374947B2 (en) 2003-03-10 2013-02-12 Chicago Mercantile Exchange, Inc. Derivatives trading methods that use a variable order price and a hedge transaction
US9607338B2 (en) 2003-03-10 2017-03-28 Chicago Mercantile Exchange Inc. Order risk management for derivative products
US10217165B2 (en) 2003-03-10 2019-02-26 Chicago Mercantile Exchange Inc. Derivatives trading methods that use a variable order price
US20090265267A1 (en) * 2003-03-10 2009-10-22 Chicago Mercantile Exchange Inc. Derivatives trading methods that use a variable order price
US10147139B2 (en) 2003-03-10 2018-12-04 Chicago Mercantile Exchange Inc. Order risk management for derivative products
US7890418B2 (en) 2003-03-10 2011-02-15 Chicago Mercantile Exchange Inc. Hedging risks associated with variable priced orders for derivative financial products
US8447683B2 (en) 2003-03-10 2013-05-21 Chicago Mercantile Exchange, Inc. Hedging risks associated with variable priced orders for derivative financial products
US20050234807A1 (en) * 2003-03-25 2005-10-20 Toffey James W Method and system for effecting straight-through-processing of trades of various financial instruments
US20040236668A1 (en) * 2003-03-25 2004-11-25 Toffey James Warden Method and system for effecting straight-through-processing of trades of various financial instruments
US20100287091A1 (en) * 2003-03-25 2010-11-11 James Worden Toffey Method and System for Effecting Straight-Through-Processing of Trades of Various Financial Instruments
US7882019B2 (en) 2003-03-25 2011-02-01 Tradeweb Markets Llc Method and system for effecting straight-through-processing of trades of various financial instruments
US7433842B2 (en) 2003-03-25 2008-10-07 Tradeweb Markets Llc Method and system for effecting straight-through-processing of trades of various financial instruments
US7769678B2 (en) 2003-03-25 2010-08-03 Tradeweb Markets Llc Method and system for effecting straight-through-processing of trades of various financial instruments
US20080281750A1 (en) * 2003-03-25 2008-11-13 James Worden Toffey Method and system for administering prime brokerage
US7734518B2 (en) 2003-03-25 2010-06-08 Tradeweb Markets, Llc Method and system for effecting straight-through-processing of trades of various financial instruments
US7756777B2 (en) 2003-03-25 2010-07-13 Tradeweb Markets Llc Method and system for administering prime brokerage
US20040230507A1 (en) * 2003-05-13 2004-11-18 Jeffrey Davidovitch Diversified fixed income product and method for creating and marketing same
US20050188378A1 (en) * 2003-06-06 2005-08-25 Miller Lawrence R. Integrated trading platform architecture
US7770184B2 (en) 2003-06-06 2010-08-03 Jp Morgan Chase Bank Integrated trading platform architecture
US20050010481A1 (en) * 2003-07-08 2005-01-13 Lutnick Howard W. Systems and methods for improving the liquidity and distribution network for illiquid items
US20050015324A1 (en) * 2003-07-15 2005-01-20 Jacob Mathews Systems and methods for trading financial instruments across different types of trading platforms
US7970688B2 (en) 2003-07-29 2011-06-28 Jp Morgan Chase Bank Method for pricing a trade
US20050027658A1 (en) * 2003-07-29 2005-02-03 Moore Stephen G. Method for pricing a trade
US20050080734A1 (en) * 2003-08-06 2005-04-14 Deutsche Bank Ag Method, system, and computer program product for trading diversified credit risk derivatives
US7725373B2 (en) * 2003-09-02 2010-05-25 Icap Services North America Llc Timing mechanism and direct messaging for electronic trading platform
US20100179923A1 (en) * 2003-09-02 2010-07-15 Steven Cooper Timing mechanism and direct messaging for electronic trading platform
US20050097029A1 (en) * 2003-09-02 2005-05-05 Steven Cooper Timing mechanism and direct messaging for electronic trading platform
US20050060256A1 (en) * 2003-09-12 2005-03-17 Andrew Peterson Foreign exchange trading interface
US7584140B2 (en) 2003-10-15 2009-09-01 Chicago Mercantille Exchange, Inc. Method and system for providing option spread indicative quotes
US7890412B2 (en) 2003-11-04 2011-02-15 New York Mercantile Exchange, Inc. Distributed trading bus architecture
US20050097026A1 (en) * 2003-11-04 2005-05-05 Matt Morano Distributed trading bus architecture
US10510114B2 (en) 2003-11-04 2019-12-17 New York Mercantile Exchange, Inc. Distributed trading bus architecture
US20110087584A1 (en) * 2003-11-04 2011-04-14 New York Mercantile Exchange, Inc. Distributed trading bus architecture
US11823263B2 (en) 2003-12-12 2023-11-21 Gfi Group, Inc. Apparatus, method and system for providing an electronic marketplace for trading credit default swaps and other financial instruments, including a trade management service system
US10832321B2 (en) 2003-12-12 2020-11-10 Gfi Group, Inc. Apparatus, method and system for providing an electronic marketplace for trading credit default swaps and other financial instruments, including a trade management service system
US20050137955A1 (en) * 2003-12-17 2005-06-23 Downie Alan D. Systems and methods for using a dedicated controller to facilitate foreign exchange pricing
US20050222937A1 (en) * 2004-03-31 2005-10-06 Coad Edward J Automated customer exchange
US20050222938A1 (en) * 2004-03-31 2005-10-06 Treacy Paul A System and method for allocating nominal and cash amounts to trades in a netted trade
US8423447B2 (en) 2004-03-31 2013-04-16 Jp Morgan Chase Bank System and method for allocating nominal and cash amounts to trades in a netted trade
US20050240513A1 (en) * 2004-04-15 2005-10-27 Michael Merold Electronic trading systems
US8010440B2 (en) * 2004-04-15 2011-08-30 Ebs Group Limited Electronic trading systems
US20050251478A1 (en) * 2004-05-04 2005-11-10 Aura Yanavi Investment and method for hedging operational risk associated with business events of another
US8694418B2 (en) 2004-06-03 2014-04-08 Globalprivatequity.Com, Inc. Integrated trading information processing and transmission system for exempt securities
US20090182686A1 (en) * 2004-06-03 2009-07-16 Globalprivatequity.Com, Inc. Integrated trading information processing and transmission system for exempt securities
US7877319B2 (en) * 2004-06-03 2011-01-25 Globalprivatequity.Com, Inc. Integrated trading information processing and transmission system for exempt securities
US20050283417A1 (en) * 2004-06-03 2005-12-22 Douglas Miles Integrated trading information processing and transmission system for exempt securities
US7526444B2 (en) 2004-06-03 2009-04-28 Globalprivatequity.Com, Inc. Integrated trading information processing and transmission system for exempt securities
US20110196807A1 (en) * 2004-06-03 2011-08-11 Globalprivatequity.Com, Inc. Integrated trading information processing and transmission system for exempt securities
US8429059B2 (en) 2004-06-08 2013-04-23 Rosenthal Collins Group, Llc Method and system for providing electronic option trading bandwidth reduction and electronic option risk management and assessment for multi-market electronic trading
US20090276373A1 (en) * 2004-06-08 2009-11-05 Rosenthal Collins Group, L.L.C. Method and system for providing electronic information for risk assesement and management for multi-market electronic trading
US7555456B2 (en) 2004-06-08 2009-06-30 Rosenthal Collins Group, Llc Method and system for providing electronic information for multi-market electronic trading
US7912781B2 (en) 2004-06-08 2011-03-22 Rosenthal Collins Group, Llc Method and system for providing electronic information for risk assessment and management for multi-market electronic trading
US20060010066A1 (en) * 2004-07-12 2006-01-12 Rosenthal Collins Group, L.L.C. Method and system for providing a graphical user interface for electronic trading
US20080162378A1 (en) * 2004-07-12 2008-07-03 Rosenthal Collins Group, L.L.C. Method and system for displaying a current market depth position of an electronic trade on a graphical user interface
US20060031247A1 (en) * 2004-08-03 2006-02-09 Dharmesh Shah System and method for the secure processing of securities transactions
US8090639B2 (en) 2004-08-06 2012-01-03 Jpmorgan Chase Bank, N.A. Method and system for creating and marketing employee stock option mirror image warrants
US7620586B2 (en) 2004-09-08 2009-11-17 Rosenthal Collins Group, Llc Method and system for providing automatic execution of trading strategies for electronic trading
US20100094777A1 (en) * 2004-09-08 2010-04-15 Rosenthal Collins Group, Llc. Method and system for providing automatic execution of risk-controlled synthetic trading entities
US20060253373A1 (en) * 2004-11-01 2006-11-09 Rosenthal Collins Group, Llc. Method and system for providing multiple graphic user interfaces for electronic trading
US7624064B2 (en) 2004-11-01 2009-11-24 Rosenthal Collins Group, Llc Method and system for providing multiple graphic user interfaces for electronic trading
US20090164384A1 (en) * 2005-02-09 2009-06-25 Hellen Patrick J Investment structure and method for reducing risk associated with withdrawals from an investment
US8688569B1 (en) 2005-03-23 2014-04-01 Jpmorgan Chase Bank, N.A. System and method for post closing and custody services
US7801801B2 (en) 2005-05-04 2010-09-21 Rosenthal Collins Group, Llc Method and system for providing automatic execution of black box strategies for electonic trading
US8589280B2 (en) 2005-05-04 2013-11-19 Rosenthal Collins Group, Llc Method and system for providing automatic execution of gray box strategies for electronic trading
US8364575B2 (en) 2005-05-04 2013-01-29 Rosenthal Collins Group, Llc Method and system for providing automatic execution of black box strategies for electronic trading
US20080288391A1 (en) * 2005-05-31 2008-11-20 Rosenthal Collins Group, Llc. Method and system for automatically inputting, monitoring and trading spreads
US20090187512A1 (en) * 2005-05-31 2009-07-23 Jp Morgan Chase Bank Asset-backed investment instrument and related methods
WO2006133112A3 (en) * 2005-06-03 2007-04-05 Globalprivatequity Com Inc Integrated trading information processing and transmission system for exempt securities
US7822682B2 (en) 2005-06-08 2010-10-26 Jpmorgan Chase Bank, N.A. System and method for enhancing supply chain transactions
US20110035306A1 (en) * 2005-06-20 2011-02-10 Jpmorgan Chase Bank, N.A. System and method for buying and selling securities
US8650112B2 (en) 2005-09-12 2014-02-11 Jpmorgan Chase Bank, N.A. Total Fair Value Swap
US7567928B1 (en) 2005-09-12 2009-07-28 Jpmorgan Chase Bank, N.A. Total fair value swap
US20070088658A1 (en) * 2005-09-30 2007-04-19 Rosenthal Collins Group, L.L.C. Method and system for providing accounting for electronic trading
US7761365B2 (en) * 2005-10-03 2010-07-20 Icap Services North America Llc Multiple protocol trading system
US20090276348A1 (en) * 2005-10-03 2009-11-05 Deborah Kessler Multiple protocol trading system
US20100312685A1 (en) * 2005-10-03 2010-12-09 Icap Services North America Llc Multiple protocol trading system
US7844543B1 (en) * 2005-10-03 2010-11-30 Icap Services North America Llc Multiple protocol trading system
US20100312686A1 (en) * 2005-10-03 2010-12-09 Icap Services North America Llc Multiple protocol trading system
US20100211497A1 (en) * 2005-10-03 2010-08-19 Icap Services North America Llc Multiple Protocol Trading System
US8249979B2 (en) * 2005-10-03 2012-08-21 Icap Services North America Llc Multiple protocol trading system
US7844542B1 (en) * 2005-10-03 2010-11-30 Icap Services North America Llc Multiple protocol trading system
US7818238B1 (en) 2005-10-11 2010-10-19 Jpmorgan Chase Bank, N.A. Upside forward with early funding provision
US20070088648A1 (en) * 2005-10-17 2007-04-19 Cqg,Inc. System and Method for Determining Data Points for Financial Bar Charts and Their Presentation
US20070118452A1 (en) * 2005-10-17 2007-05-24 Cqgt, Inc. Financial Instrument Trading Interface with Dynamic Price Scale
WO2007048040A3 (en) * 2005-10-17 2007-10-04 Cqg Inc Financial instrument trading interface with dynamic price scale
WO2007048040A2 (en) * 2005-10-17 2007-04-26 Cqg, Inc. Financial instrument trading interface with dynamic price scale
US7849000B2 (en) 2005-11-13 2010-12-07 Rosenthal Collins Group, Llc Method and system for electronic trading via a yield curve
US11270379B2 (en) 2005-11-18 2022-03-08 Chicago Mercantile Exchange Inc. System and method for centralized clearing of over the counter foreign exchange instruments
US11348173B2 (en) 2005-11-18 2022-05-31 Chicago Mercantile Exchange Inc. Detection of intra-firm matching and response thereto
US8086527B2 (en) 2005-11-18 2011-12-27 Chicago Mercantile Exchange Inc. Multiple quote risk management
US10636088B2 (en) 2005-11-18 2020-04-28 Chicago Mercantile Exchange Inc. Hybrid cross-margining
US20070118453A1 (en) * 2005-11-18 2007-05-24 Bauerschmidt Paul A Multiple quote risk management
US7809631B2 (en) 2005-11-18 2010-10-05 Chicago Mercantile Exchange Inc. Cross-currency implied spreads
US20070118454A1 (en) * 2005-11-18 2007-05-24 Bauerschmidt Paul A Cross-currency implied spreads
US20070118455A1 (en) * 2005-11-18 2007-05-24 Albert William J System and method for directed request for quote
US7734538B2 (en) 2005-11-18 2010-06-08 Chicago Mercantile Exchange Inc. Multiple quote risk management
US7801810B2 (en) 2005-11-18 2010-09-21 Chicago Mercantile Exchange Inc. Hybrid cross-margining
US10719874B2 (en) 2005-11-18 2020-07-21 Chicago Mercantile Exchange Inc. Multiple quote risk management
US20110191235A1 (en) * 2005-11-18 2011-08-04 Dmitriy Glinberg Hybrid cross-margining
US20100312689A1 (en) * 2005-11-18 2010-12-09 Chicago Mercantile Exchange Inc. Cross-currency implied spreads
US20100312720A1 (en) * 2005-11-18 2010-12-09 Chicago Mercantile Exchange Inc. Hybrid cross-margining
US10628883B2 (en) 2005-11-18 2020-04-21 Chicago Mercantile Exchange Inc. Detection of intra-firm matching and response thereto
US11538109B2 (en) 2005-11-18 2022-12-27 Chicago Mercantile Exchange Inc. System and method for centralized clearing of over the counter foreign exchange instruments
US11694265B2 (en) 2005-11-18 2023-07-04 Chicago Mercantile Exchange Inc. System and method for centralized clearing of over the counter foreign exchange instruments
US7930245B2 (en) 2005-11-18 2011-04-19 Chicago Mercantile Exchange Inc. Hybrid cross-margining
US20100205113A1 (en) * 2005-11-18 2010-08-12 Chicago Mercantile Exchange Inc. Multiple quote risk management
US10726479B2 (en) 2005-11-18 2020-07-28 Chicago Mercantile Exchange Inc. System and method for centralized clearing of over the counter foreign exchange instruments
US8401955B2 (en) 2005-11-18 2013-03-19 Chicago Mercantile Exchange Cross-currency implied spreads
US11288742B2 (en) 2005-11-18 2022-03-29 Chicago Mercantile Exchange Inc. Hybrid cross-margining
US20070118459A1 (en) * 2005-11-18 2007-05-24 Bauerschmidt Paul A System and method for centralized clearing of over the counter foreign exchange instruments
US20070208650A1 (en) * 2005-12-12 2007-09-06 Mcgill Bradley J System and method for creating, listing, and clearing flexible short term interest rate derivative instruments
US8412607B2 (en) 2006-02-03 2013-04-02 Jpmorgan Chase Bank, National Association Price earnings derivative financial product
US7716107B1 (en) 2006-02-03 2010-05-11 Jpmorgan Chase Bank, N.A. Earnings derivative financial product
US8280794B1 (en) 2006-02-03 2012-10-02 Jpmorgan Chase Bank, National Association Price earnings derivative financial product
US20070265954A1 (en) * 2006-03-10 2007-11-15 Mather Timothy S graphical user interface trading widget for trading financial instruments
US20070255643A1 (en) * 2006-04-27 2007-11-01 John Capuano Systems and methods for maintaining anonymity in a gaming or other environment
US8355979B2 (en) * 2006-04-27 2013-01-15 Bgc Partners, Inc. Systems and methods for maintaining anonymity in a gaming or other environment
US20130150154A1 (en) * 2006-04-27 2013-06-13 John Capuano Systems and methods for maintaining anonymity in a gaming or other environment
US7620578B1 (en) 2006-05-01 2009-11-17 Jpmorgan Chase Bank, N.A. Volatility derivative financial product
US7647268B1 (en) 2006-05-04 2010-01-12 Jpmorgan Chase Bank, N.A. System and method for implementing a recurrent bidding process
US20070265953A1 (en) * 2006-05-09 2007-11-15 Cunningham William D Smooth scrolling for software application
US7606759B2 (en) * 2006-05-16 2009-10-20 Automated Trading Desk, Llc System and method for implementing an anonymous trading method
US20100023461A1 (en) * 2006-05-16 2010-01-28 Automated Trading Desk, Llc System and method for implementing an anonymous trading method
US20070271169A1 (en) * 2006-05-16 2007-11-22 Automated Trading Desk, Llc System and method for implementing an anonymous trading method
US20100057637A1 (en) * 2006-05-16 2010-03-04 Automated Trading Desk, Llc System and method for implementing an anonymous trading method
US8326734B2 (en) 2006-05-16 2012-12-04 Automated Trading Desk, Llc System and method for implementing an anonymous trading method
US8326733B2 (en) 2006-05-16 2012-12-04 Automated Trading Desk, Llc System and method for implementing an anonymous trading method
US20080086401A1 (en) * 2006-07-25 2008-04-10 Cqgt, Llc Charting with depth of market volume flow
US9811868B1 (en) 2006-08-29 2017-11-07 Jpmorgan Chase Bank, N.A. Systems and methods for integrating a deal process
US8626637B1 (en) * 2006-09-28 2014-01-07 Gfi Group, Inc. Apparatus, method and system for providing an electronic marketplace to join a trade for credit default swaps and other financial interests, and to deal-by-volume for the interests
US7827096B1 (en) 2006-11-03 2010-11-02 Jp Morgan Chase Bank, N.A. Special maturity ASR recalculated timing
US8577781B2 (en) 2007-01-17 2013-11-05 Cunningham Trading Systems, Llc Method for scheduling future orders on an electronic commodity trading system
US20100145844A1 (en) * 2007-01-17 2010-06-10 Steidlmayer Pete Method for scheduling future orders on an electronic commodity trading system
US20100049666A1 (en) * 2007-03-15 2010-02-25 James Tyler Trading analysis tools
US8781943B2 (en) 2007-05-04 2014-07-15 Icap Management Services Limited Method and system for offset matching
US20080275807A1 (en) * 2007-05-04 2008-11-06 Icap Management Services Limited Method and System for Offset Matching
US20080288419A1 (en) * 2007-05-18 2008-11-20 Globalprivatequity.Com, Inc. Integrated trading and information system for collection and dissemination of valuation data
US20080313027A1 (en) * 2007-06-12 2008-12-18 Microsoft Corporation Fair discounting auction
US7778869B2 (en) * 2007-06-12 2010-08-17 Microsoft Corporation Fair discounting auction
US20100223201A1 (en) * 2007-08-20 2010-09-02 Chicago Mercantile Exchange, Inc. Out of Band Credit Control
US8756146B2 (en) 2007-08-20 2014-06-17 Chicago Mercantile Exchange Inc. Out of band credit control
US7987135B2 (en) 2007-08-20 2011-07-26 Chicago Mercantile Exchange, Inc. Out of band credit control
US8762252B2 (en) 2007-08-20 2014-06-24 Chicago Mercantile Exchange Inc. Out of band credit control
US7996301B2 (en) 2007-08-20 2011-08-09 Chicago Mercantile Exchange, Inc. Out of band credit control
US8355980B2 (en) 2007-08-20 2013-01-15 Chicago Mercantile Exchange Inc. Out of band credit control
US8694415B2 (en) 2007-08-20 2014-04-08 Chicago Mercantile Exchange Inc. Out of band credit control
US20090055303A1 (en) * 2007-08-20 2009-02-26 Chicago Mercantile Exchange, Inc. Out of band credit control
US8781952B1 (en) * 2007-10-02 2014-07-15 Lucio Biase Systems, methods and computer software related to pooled credit risk and financial instrument allocation
US7840483B2 (en) * 2007-11-20 2010-11-23 Chicago Mercantile Exchange, Inc. Settling over-the-counter derivatives using synthetic spot benchmark rates
US8510209B2 (en) * 2007-11-20 2013-08-13 Chicago Mercantile Exchange, Inc. Settling over-the-counter derivatives using synthetic spot benchmark rates
US20090132402A1 (en) * 2007-11-20 2009-05-21 Chicago Mercantile Exchange, Inc. Settling Over-The-Counter Derivatives Using Synthetic Spot Benchmark Rates
US20110295737A1 (en) * 2007-11-20 2011-12-01 Chicago Mercantile Exchange Inc. Settling Over-The-Counter Derivatives Using Synthetic Spot Benchmark Rates
US20090171832A1 (en) * 2007-12-28 2009-07-02 Cunningham Trading Systems, Llc Method for displaying multiple markets
US10049405B2 (en) 2008-03-10 2018-08-14 Tradeweb Markets Llc System and method for specified pool trading
US20100010937A1 (en) * 2008-04-30 2010-01-14 Rosenthal Collins Group, L.L.C. Method and system for providing risk assessment management and reporting for multi-market electronic trading
US11216878B2 (en) 2009-01-08 2022-01-04 New York Mercantile Exchange, Inc. Determination of implied orders in a trade matching system
US10395316B2 (en) 2009-01-08 2019-08-27 Chicago Mercantile Exchange Inc. Determination of implied orders in a trade matching system
US11908010B2 (en) 2009-01-08 2024-02-20 New York Mercantile Exchange, Inc. Determination of implied orders in a trade matching system
US8442904B2 (en) 2009-01-08 2013-05-14 New York Mercantile Exchange, Inc. Determination of implied orders in a trade matching system
US8229835B2 (en) 2009-01-08 2012-07-24 New York Mercantile Exchange, Inc. Determination of implied orders in a trade matching system
US20100174633A1 (en) * 2009-01-08 2010-07-08 New York Mercantile Exchange, Inc. Determination of Implied Orders in a Trade Matching System
US20100241588A1 (en) * 2009-03-17 2010-09-23 Andrew Busby System and method for determining confidence levels for a market depth in a commodities market
US20110012357A1 (en) * 2009-07-15 2011-01-20 Hong Fu Jin Precision Industry(Shenzhen) Co., Ltd. Tidal power generator
US20110055067A1 (en) * 2009-09-03 2011-03-03 Chicago Mercantile Exchange, Inc. Utilizing a trigger order with multiple counterparties in implied market trading
US8417618B2 (en) 2009-09-03 2013-04-09 Chicago Mercantile Exchange Inc. Utilizing a trigger order with multiple counterparties in implied market trading
US8392322B2 (en) 2009-09-15 2013-03-05 Chicago Mercantile Exchange Inc. Transformation of a multi-leg security definition for calculation of implied orders in an electronic trading system
US8255305B2 (en) 2009-09-15 2012-08-28 Chicago Mercantile Exchange Inc. Ratio spreads for contracts of different sizes in implied market trading
US8577771B2 (en) 2009-09-15 2013-11-05 Chicago Mercantile Exchange Inc. Transformation of a multi-leg security definition for calculation of implied orders in an electronic trading system
US20110066568A1 (en) * 2009-09-15 2011-03-17 Andrew Milne Transformation of a multi-leg security definition for calculation of implied orders in an electronic trading system
US20110066536A1 (en) * 2009-09-15 2011-03-17 Andrew Milne Ratio spreads for contracts of different sizes in implied market trading
US8793180B2 (en) 2009-09-15 2014-07-29 Chicago Mercantile Exchange Inc. Ratio spreads for contracts of different sizes in implied market trading
US8266030B2 (en) 2009-09-15 2012-09-11 Chicago Mercantile Exchange Inc. Transformation of a multi-leg security definition for calculation of implied orders in an electronic trading system
US20110066537A1 (en) * 2009-09-15 2011-03-17 Andrew Milne Implied volume analyzer
US8229838B2 (en) 2009-10-14 2012-07-24 Chicago Mercantile Exchange, Inc. Leg pricer
US8484126B2 (en) 2009-10-14 2013-07-09 Chicago Mercantile Exchange Inc. Leg pricer
US8738514B2 (en) 2010-02-18 2014-05-27 Jpmorgan Chase Bank, N.A. System and method for providing borrow coverage services to short sell securities
US8352354B2 (en) 2010-02-23 2013-01-08 Jpmorgan Chase Bank, N.A. System and method for optimizing order execution
US10346912B2 (en) 2013-03-15 2019-07-09 Tradeweb Markets Llc System and method for financial matching
US11288739B2 (en) 2015-10-12 2022-03-29 Chicago Mercantile Exchange Inc. Central limit order book automatic triangulation system
US11823267B2 (en) 2015-10-12 2023-11-21 Chicago Mercantile Exchange Inc. Central limit order book automatic triangulation system

Also Published As

Publication number Publication date
AU1270399A (en) 1999-05-03
US6421653B1 (en) 2002-07-16
US20030220868A1 (en) 2003-11-27
US20040015431A1 (en) 2004-01-22
US20100179902A1 (en) 2010-07-15
CA2305736A1 (en) 1999-04-22
US20040015430A1 (en) 2004-01-22
US7571136B2 (en) 2009-08-04
EP1023684A1 (en) 2000-08-02
US20070011079A1 (en) 2007-01-11
AU762863B2 (en) 2003-07-10
US20020138390A1 (en) 2002-09-26
US6317727B1 (en) 2001-11-13
US20030229571A1 (en) 2003-12-11
US7689497B2 (en) 2010-03-30
US20060095363A1 (en) 2006-05-04
WO1999019821A1 (en) 1999-04-22
US20100185559A1 (en) 2010-07-22
US20020099651A1 (en) 2002-07-25
US20070219882A1 (en) 2007-09-20
JP2001520421A (en) 2001-10-30

Similar Documents

Publication Publication Date Title
US6421653B1 (en) Systems, methods and computer program products for electronic trading of financial instruments
US6996540B1 (en) Systems for switch auctions utilizing risk position portfolios of a plurality of traders
US20070288346A1 (en) Systems for risk portfolio management
US20070239591A1 (en) Systems and methods for reverse auction of financial instruments
CA2409413A1 (en) Systems and methods for conducting derivative trades electronically
US7035820B2 (en) Systems and methods for trading and originating financial products using a computer network
US7231363B1 (en) Method and system for rebrokering orders in a trading system
US20020007335A1 (en) Method and system for a network-based securities marketplace
US20050187858A1 (en) Fixed income security offerings management techniques and related applications
JP2008530638A (en) Transaction management system using warning messages for out-of-range trading orders
AU2001261727B8 (en) Systems and methods for conducting derivative trades electronically
AU2001261727A1 (en) Systems and methods for conducting derivative trades electronically
WO2002001316A2 (en) Network system for handling request for proposal relating to the selection of an investment advisor by an institutional investor

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION

AS Assignment

Owner name: GFINET, INC., NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BLACKBIRD HOLDINGS, INC.;REEL/FRAME:026708/0281

Effective date: 20110804

Owner name: BLACKBIRD HOLDINGS, INC., NORTH CAROLINA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:GFINET, INC.;REEL/FRAME:026708/0005

Effective date: 20110804