Automated financial instrument exchange apparatus and systems

Deal information associated with a bond exchange is determined, the deal information including information associated with a plurality of eligible financial instruments and at least one new financial instrument. In addition, offer information is received from a plurality of remote client devices via a communication network. An exchange allocation is then automatically calculated based on the deal information and the offer information. Moreover, target information associated with at least one financial instrument may be determined and used to calculate the exchange allocation.

COPYRIGHT AUTHORIZATION

FIELD

The present invention relates to financial instrument exchanges. In particular, the present invention relates to automated financial instrument exchange apparatus and systems.

BACKGROUND

An issuer might have a number of different financial instruments outstanding at the same time. For example, an issuer could have five different bonds outstanding, each bond being due on a different date. The complex and unusual structure of such debt can sometimes lower the perceived worth of any future bonds that might be issued.

To address this problem, it is known that a bond exchange can be held to swap the old bonds with a newly issued bond.FIG. 1illustrates a known bond exchange100in which a client120provides “eligible issues” (i.e., the old bonds) to an issuer110in return for a “new issue” (i.e., the new bond). In this way, the issuer110can consolidate debt (e.g., by replacing ten outstanding bonds with a single new bond). The issuer110may also use the bond exchange as a way of extending debt.

Note that different clients120might have different opinions as to the worth of the new bonds as compared to the old bonds. As a result, clients120can submit offers, referred to as letters of transmittal, to the issuer110. For example, the bond exchange100might be structured as a “forward” exchange (in which clients120submit bids on the value of old bonds to be exchanged for a fixed amount of new bonds) or a “reverse” exchange (in which clients120submit bids on the value of new bonds to be exchanged for a fixed amount of old bonds). In either case, the client120might submit an offer that indicates, for example, a bid price (or a spread to a reference instrument) along with a number of bonds he or she is interested in exchanging. The issuer110then executes the exchange with the clients120who submitted the most appropriate bids.

The bond exchange process, however, can be difficult to perform. Consider two clients who both submit identical letters of transmittal to an issuer that wants to issue fifteen thousand new bonds. In this case, the issuer might allocate new bonds on a first-submitted, first-allocated basis. For example, if a first client submits an offer to exchange ten thousand bonds while a second client later submits an offer to exchange twenty thousand bonds (at the same price), the issuer would allocate ten thousand new bonds to the first client and five thousand new bonds to the second client.

As another approach, the issuer might allocate new bonds on a pro-rated basis in accordance with on the number of bonds associated with each offer. For example, if a first client submits an offer to exchange ten thousand bonds while a second client later submits an offer to exchange twenty thousand bonds (at the same price), the issuer would allocate five thousand bonds to the first client and ten thousand bonds to the second client (i.e., the second client would receive twice as many new bonds). The complexity of such allocations will grow as the number of eligible issues, new issues, and/or clients increases.

Moreover, even a small error in a letter of transmittal and/or the allocation process can have serious consequences, especially when a significant amount of value is associated with the bond exchange.

SUMMARY

To alleviate problems inherent in the prior art, the present invention introduces automated financial instrument exchange apparatus and systems.

According to one embodiment, deal information associated with a financial instrument exchange is determined, the deal information including information associated with a plurality of eligible financial instruments and at least one new financial instrument. In addition, offer information is received from a plurality of remote client devices via a communication network. An exchange allocation is then automatically calculated based on the deal information and the offer information. According to some embodiments, target information associated with at least one of the financial instruments (i.e., an eligible and/or a new financial instrument) is also determined and used to calculate the exchange allocation.

One embodiment comprises: means for determining deal information associated with a financial instrument exchange, the deal information including information associated with a plurality of eligible financial instruments and at least one new financial instrument; means for receiving offer information from a plurality of remote client devices via a communication network; and means for automatically calculating an exchange allocation based on the deal information and the offer information. Some embodiments also include means for determining target information associated with at least one of the financial instruments.

With these and other advantages and features of the invention that will become hereinafter apparent, the invention may be more clearly understood by reference to the following detailed description of the invention, the appended claims, and the drawings attached herein.

DETAILED DESCRIPTION

Some embodiments described herein are associated with a “financial instrument” exchange. As used herein, the phrase “financial instrument” may refer to, for example, any type of security. One example of a financial instrument is a bond, or any other debt instrument, in which an issuer promises to pay to bondholders principal and interest according to the terms and conditions of the bond. The bonds may be, for example, floating or fixed coupon instruments. The issuer may be, for example, a corporation. The issuer could instead be a government entity, such as a foreign government, a local government, the United States (US) Federal Home Loan Mortgage Corporation (FHLMC or “Freddie Mac”) or the US Federal National Mortgage Association (FNMA or “Fannie Mae”).

Automated Bond Exchange System

FIG. 2is a block diagram overview of an automated bond exchange system200including a bond exchange controller210according to some embodiments of the present invention. The bond exchange controller210may, for example, communicate with an issuer device220via a communication network230. Similarly, the bond exchange controller210may exchange information with client devices240, a settlement agent device250, and/or a clearing agent device260via the communication network230.

The bond exchange controller210, issuer device220, client devices240, settlement agent device250, and/or clearing agent device260may be any devices capable of performing the various functions described herein. For example, a client device240might be a Personal Computer (PC) associated with a “client.” As used herein, the term “client” may refer to, for example, an individual or entity that owns, buys, and/or sells bonds.

The bond exchange controller210may be, for example, a Web server adapted to exchange information via an Internet Protocol (IP) network (e.g., the Internet). Note that the communication network230might comprise one or more other networks, including an intranet, a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, a Public Switched Telephone Network (PSTN), and/or a wireless network.

According to some embodiments, the bond exchange controller210communicates with other devices via a temporary computer communication channel (e.g., a path through which information can be exchanged). In other words, the communication channel between the bond exchange controller210and another device may be established and discontinued as appropriate. Note that an established communication channel does not need to be associated with a particular physical path. For example, the bond exchange controller210may exchange information with a remote issuer device220via a Web site, in which case packets of information may be transmitted via various physical paths.

According to other embodiments, the bond exchange controller210communicates with other devices via a public computer communication network. That is, at least a portion of the communication network230may be accessed by devices other than the devices described herein. Note, however, that the information exchanged by the bond exchange controller210could be encrypted or otherwise protected to prevent a third party from accessing (i.e., understanding) the information.

According to still other embodiments, the bond exchange controller210communicates with devices via a computer communication channel that is potentially accessible by a plurality of unrelated devices. For example, a single port or line associated with the bond exchange controller210might communicate with a first client device240for a period of time and then with a second, unrelated client device240(i.e., the first and second client devices240may be associated with different traders or clients).

Although a single bond exchange controller210is shown inFIG. 2, any number of these devices may be included in the automated bond exchange system200. Similarly, any number of other device described herein may be included according to embodiments of the present invention. Note that some of devices illustrated inFIG. 2may actually be incorporated in a single device. For example, the bond exchange controller210might also act as a settlement agent device250.

FIG. 3is a flow chart of a method that might be performed, for example, by the bond exchange controller210according to some embodiments of the present invention. The flow charts described herein do not imply a fixed order to the steps, and embodiments of the present invention may be practiced in any order that is practicable.

At302, deal information associated with a bond exchange is determined, the deal information including information associated with at least one “eligible issue” (e.g., an old bond that the issuer wants to remove from circulation) and at least one “new issue” (e.g., a new bond that the issuer wants to introduce). Note that the deal information might include information about a number of different eligible issues and/or new issues.

The deal information might be determined by receiving the information from an issuer device220(e.g., via a Web page). The deal information might also be determined by retrieving the information from a database (e.g., after an operator enters the information into the database).

The deal information may include information about the issuer, such as an issuer identifier, name, address, and/or contact information (e.g., a phone number or email address). The deal information might also include information about the bonds associated with the exchange, such as a bond identifier and name, reference bond information, a minimum price (e.g., as a percentage of face value), a maximum price, a price increment (e.g., a minimum increment by which a client can adjust a price), yield information (e.g., the rate of return associated with the bond), target information, and coupon information (e.g., the stated interest rate for the bond).

Other deal information might include an “open” date and time (e.g., indicating when offers will first be accepted from clients), a “close” date and time (e.g., indicating when offers will no longer be accepted), a settlement date, and a deal status (e.g., indicating whether the deal is pending, in process, or complete). Supplemental deal information might also be determined by the bond exchange controller210, such as the text of an invitation announcement and/or a press release associated with the exchange.

At304, offer information is received from a plurality of remote client devices240. For example, a remote client device240might transmit offer information to the bond exchange controller210via a Web page. The offer information might include information about the client who is submitting the offer, such as a client identifier, name, address, and/or contact information. The offer information might further identify the particular bond exchange associated with the offer.

The offer information may also identify a particular bond (e.g., an eligible issue), along with a bond amount, a bid type (e.g., indicating whether or not the bid is non-competitive), clearing agent information, a bond price, and/or a bond spread. According to some embodiments, the received offer information comprises an electronic letter of transmittal.

At306, a bond exchange allocation is automatically calculated based on the deal information and the offer information. For example, the bond exchange controller210might calculate which clients will receive a new bond and/or how many bonds each client will receive (e.g., based on offer dates, offer times, and an optimization of issuer benefit). Note that deal information is “automatically” calculated in that at least some of the calculations are performed by an automated process (although some operator action might be involved, such as initiating the process).

According to some embodiments, the bond exchange controller210also determines “target information” associated with at least one of the issues (i.e., an eligible and/or a new issue). For example, the issuer device220might transmit the target information to the bond exchange controller210via a Web site. The bond exchange controller210can then optimize exchange allocation results based on the target information. In this way, the exchange can be priced based on an issuer's specific goals. The target information might include, for example, a bond price, a bond quantity, and/or present value savings information.

Issuer Information

FIG. 4illustrates a display400that provides information about an issuer and/or a bond exchange according to some embodiments of the present invention. In particular, the display400comprises a Graphical User Interface (GUI) that can be used by an issuer or client to exchange information with the bond exchange controller210(e.g., by accessing a Web site via a remote issuer device220or client device240).

As can be seen inFIG. 4, the display400provides information about the bond exchange, including the name of the new issue (i.e., “DemoNew due Oct. 1, 2012”), eligible issues (i.e., “reference notes due October 2005 through October 2015”), the open date and time, the close date and time, and the settlement date. According to some embodiments, an issuer can use this display400to provide such information to the bond exchange controller210.

FIG. 5illustrates another display500that provides information about an issuer and/or a bond exchange. In particular, the display500identifies a reference bond (e.g., a US Treasury bond) and provides detailed information about the eligible issues (i.e., DemoBond Old A though E), including a minimum price, a maximum price, and a price increment. Note that the issuer can also use this display500to provide such information to the bond exchange controller210.

Client Information

FIG. 6illustrates a client display600according to some embodiments of the present invention. In particular, the client can use the display600to access information about a bond exchange (e.g., an exchange supplement, an offering circular, and/or a hypothetical example associated with the exchange). The client might also provide an indication that he or she agrees to the receive this information electronically (e.g., by clicking on the “Agree” icon).

FIG. 7illustrates a display700that a client can use to submit offer information to the bond exchange controller210according to some embodiments of the present invention. In particular, the client can view information about eligible securities, such as minimum, maximum, and increment spread values associated with each bond. Similarly, the client can view minimum, maximum,. and increment face values associated with each bond.

The client can also select one of the eligible securities via a drop down menu (which may help avoid incorrect or ambiguous entries). The client may then enter a spread and/or offer type for that bond, such as by entering the number of basis points associated with his or her bid (each basis point representing 1/100th of one percent). Note that a bid might include a specific value (e.g., a spread or a price) or may instead be “non-competitive.” Similarly, the client can enter a number of bonds associated with the bid.

According to some embodiments, this information comprises an electronic letter of transmittal for the bond exchange. Note that a single letter of transmittal might include bids for a number of different eligible securities.

The client may then submit the offer information to the remote bond exchange controller210(e.g., by clicking the “Submit LOT” icon). According to some embodiments, the client can instead choose to store the offer information (e.g., by clicking the “Store LOT” icon). In this case, the client can retrieve the potential offer information at a later time (e.g., to edit and/or submit the information). In this way, the client can prepare the offer information in advance and submit the offer near the close of the bond exchange (in case financial conditions change near the close). According to some embodiments, the client can also copy a subset of the offer information from a one letter of transmittal to another (e.g., general client information might be automatically copied to the new letter of transmittal).

Other information that might be submitted by the client includes beneficial owner information and client contact information (e.g., the client's name and address). According to some embodiments, the client can view a list of each letter of transmittal that he or she has submitted to the bond exchange controller210(but not letters of transmittal submitted by other clients). After the close of the bond exchange, allocation information might also be transmitted to the client device240(e.g., via a Web page or email message).

Current Bond Exchange Information

FIG. 8illustrates a current bond exchange information display800that might be transmitted, for example, to a remote issuer device220according to some embodiments of the present invention. In particular, the display800indicates the cumulative face amount of the offers that have been received for each of the eligible issues (both as a number of bonds and as a percentage). If available, target information might also be displayed (e.g., representing the issuer's target for each of the eligible issues).

The display800also lists each offer that has been submitted, including the client's identifier, the date and time of the submission, the eligible issue, the bid amount, the face amount, and the clearing agent associated with the offer. The clearing agent may be, for example, the FED WIRE system that connects the US Federal Reserve offices, depository institutions, the Treasury, and other government agencies. In this way, the issuer can review all of the letters of transmittal that have been submitted during the exchange.

The issuer may also request that the display800be updated (e.g., by clicking on the “Refresh” icon). According to some embodiments, the issuer can define when the display800should be updated (e.g., once every five minutes or upon any change in the display's information). According to some embodiments, the issuer can also ask to have the information re-formatted (e.g., by clicking on the “Export” icon). For example, the issuer might request that the information be formatted as a MICROSOFT EXCEL® spreadsheet. According to still other embodiments, the information may be used to generate a demand curve that is then displayed to the issuer.

Hypothetical Analysis Information

FIGS. 9 and 10illustrate hypothetical analysis displays that might be transmitted, for example, to a remote issuer device220according to some embodiments of the present invention. That is, the bond exchange controller210might calculate hypothetical analysis information (e.g., a “what if” analysis) based on real time information, such as a current value of a reference bond.

In particular,FIG. 9illustrates a display900that can be used to input analysis information, such as benchmark information, spread information, coupon information, clearance levels (including locking levels), and pro-rationing information. After the appropriate information has been entered, the issuer can request that the calculations be performed (e.g., by clicking the “Run” icon). In this way, the issuer can determine preliminary allocations (e.g., to review the information before clients see the results). According to some embodiments, the issuer can also store the scenario information (e.g., by clicking the “Save-Hypo” icon).

The issuer can also ask to have the results optimized (e.g., by clicking the “Optimize” icon). For example, the bond exchange controller210might optimize clearing levels (e.g., by bringing down the level if there are no bids at the input level) and/or optimize clearance by determining levels based on target levels.

The issuer can also request that the scenario be executed as the final bond exchange (e.g., by clicking the “Execute” icon). In this case, the bond exchange controller210may automatically transmit an email message to client devices240(both for bonds that have been accepted and those that have not).

FIG. 10illustrates a display1000that can be used to provide analysis information to the issuer, including assumptions associated with the hypothetical analysis. The display also includes the results for the new issue (e.g., a benchmark rate, coupon information, spread information, price information, and yield information) and each eligible issue (e.g., yield and price information). Other information that might be provided on the display include an eligible face amount, pro-rationing information, an accepted face amount, accepted bid information, a new bond amount, cash information, accrued interest information, a new issue percentage, and present value savings information.

Note that the hypothetical analysis might let a party view a potential bond allocation using fixed values. For example, the party might be able to view what would happen if a non-competitive bid for one thousand old bonds was submitted (e.g., the party might be provided with a new bond and cash allocation). Moreover, the analysis may be updated in substantially real time to market (e.g., when values are based on spreads to a reference bond that changes value to market conditions).

System Information

FIGS. 11 through 13illustrate system displays according to some embodiments of the present invention. In particular,FIG. 11illustrates a system progress display1100that lists all of the offer information that has been received by the bond exchange controller210(e.g., letters of transmittal that have been submitted, stored, or deleted). In this way the entire bid history can be examined.FIG. 12illustrates a system administrator display1200that lists the administrative users along with their identifier, role, manager, and manager type (e.g., coordinator or lead manager).

FIG. 13illustrates a bank information display1300that can be used to enter an American Banking Association (ABA) number and address. The display1300also lists existing ABA entries by user identifier. According to some embodiments, the information is validated by the bond exchange controller210and/or pre-populated where appropriate.

Settlement Agent Information

FIG. 14illustrates a settlement agent display1400according to some embodiments of the present invention. In particular, the information on the display1400may be transmitted from the bond exchange controller210to a remote settlement agent device250and may include, for example, a settlement report, settlement instructions, acceptance blocking information, settlement blocking information, participant information, contact information, and/or refresh frequency information. Note that the bond exchange might be configured to only accept bonds having proper blocking instructions. For example, a bank might be allowed to vouch for blocking status in connection with the EUROCLEAR centralized clearing system for eurobonds and/or the CLEARSTREAM international clearing and settlement organization. The display1400may be used to review blocking status, to review bids (by bid number or account number), and/or to generate reports (e.g., including settlement instructions and blocking status reports).

Clearing Agent Information

FIG. 15illustrates a clearing agent display1500according to some embodiments of the present invention. In particular, the information on the display1500may be transmitted from the bond exchange controller210to a remote clearing agent device260and may include, for example, a clearing status, preliminary allocations, final allocations, participant information, contact information, and/or refresh frequency information. Note that the clearing agent display1500may be similar to the settlement agent display1400, but will include only the information that is appropriate for that particular clearing agent.

Bond Exchange Controller

FIG. 16is a block diagram of a bond exchange controller1600that is descriptive of the device shown, for example, inFIG. 1according to an embodiment of the present invention. The bond exchange controller1600comprises a processor1610, such as one or more INTEL® Pentium® processors, coupled to a communication device1620configured to communicate via a communication network. The communication device1620may be used to communicate, for example, with one or more issuer devices220, client devices240, settlement agent devices250, and/or clearing agent devices260. The bond exchange controller1600may further include an input device1640(e.g., a mouse and/or keyboard to input bond exchange information) and an output device1650(e.g., a computer monitor to output bond exchange information).

The processor1610is also in communication with a storage device1630. The storage device1630may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices.

The storage device1630stores a program1615for controlling the processor1610. The processor1610performs instructions of the program1615, and thereby operates in accordance with the present invention. For example, the processor1610may automatically calculate a bond exchange allocation.

As used herein, information may be “received” by or “transmitted” to, for example: (i) the bond exchange controller1600from another device; or (ii) a software application or module within the bond exchange controller1600from another software application, module, or any other source.

As shown inFIG. 16, the storage device1630also stores: an issuer database1700(described with respect toFIG. 17); a bond exchange database1800(described with respect toFIG. 18); a client database1900(described with respect toFIG. 19); a letter of transmittal database2000(described with respect toFIG. 20); and an allocation database2100(described with respect toFIG. 21). Examples of databases that may be used in connection with the bond exchange controller1600will now be described in detail with respect toFIGS. 17 through 21. The illustrations and accompanying descriptions of the databases presented herein are exemplary, and any number of other database arrangements could be employed besides those suggested by the figures.

Bond Exchange Databases

Referring toFIG. 17, a table represents the issuer database1700that may be stored at the bond exchange controller1600according to an embodiment of the present invention. The table includes entries identifying issuers that may be associated with bond exchanges. The table also defines fields1702,1704,1706,1708,1710for each of the entries. The fields specify: an issuer identifier1702, an issuer name1704, bond exchanges1706, a contact name1708, and contact information1710. The information in the issuer database1700may be created and updated, for example, based on information received from a remote issuer device220or an operator associated with the bond exchange controller210.

The issuer identifier1702and issuer name1704may represent a particular issuer. The bond exchanges1706may be identifiers representing the bond exchanges that are associated with that issuer. The contact name1708and contact information1710may represent, for example, a person that may be contacted in connection with the bond exchange.

Referring toFIG. 18, a table represents the bond exchange database1800that may be stored at the bond exchange controller1600according to an embodiment of the present invention. The table includes entries identifying bond exchanges. The table also defines fields1802,1804,1806,1808,1810for each of the entries. The fields specify: an exchange identifier1802, one or more new issue identifiers1804, one or more eligible issue identifiers1806, an open date and time1808, and a close date and time1810. The information in the bond exchange database1800may be created and updated, for example, based on information received from a remote issuer device220or an operator associated with the bond exchange controller210.

The exchange identifier1802may be an alphanumeric code associated with a particular bond exchange and may be based on, or associated with, the bond exchanges1706stored in the issuer database1700. The new issue identifiers1804and eligible issue identifiers1806may represent bonds that associated with the exchange. The open date and time1808and close date and time1810may define when letters of transmittal will be accepted for the bond exchange.

Referring toFIG. 19, a table represents the client database1900that may be stored at the bond exchange controller1600according to an embodiment of the present invention. The table includes entries identifying clients that may be associated with bond exchanges. The table also defines fields1902,1904,1906,1908for each of the entries. The fields specify: a client identifier1902, a client name1904, a contact name1906, and contact information1908. The information in the client database1900may be created and updated, for example, based on information received from a remote client device240.

The client identifier1902and client name1904represent a particular client. The contact name1906and contact information1908may represent, for example, a person that may be contacted in connection with the bond exchange.

Referring toFIG. 20, a table represents the letter of transmittal database2000that may be stored at the bond exchange controller1600according to an embodiment of the present invention. The table includes entries identifying letters of transmittal that have been received in connection with bond exchanges. The table also defines fields2002,2004,2006,2008,2010,2012,2014for each of the entries. The fields specify: an offer identifier2002, a submission date and time2004, an exchange identifier2006, an eligible issue identifier2008, an amount2010, a price2012, and a status2014. The information in the letter of transmittal database2000may be created and updated, for example, based on information received from a remote client device240.

The offer identifier2002may be an alphanumeric code associated with a particular letter of transmittal. The submission date and time2004may indicate when the letter of transmittal was received. The exchange identifier2006may be an alphanumeric code associated with a particular bond exchange and may be based on, or associated with, the bond exchanges1706stored in the issuer database1700and/or the exchange identifiers1802stored in the bond exchange database1800. The eligible issue identifier2008may be an alphanumeric code associated with a particular bond and may be based on, or associated with, the eligible issue identifiers1806stored in the bond exchange database1800. The amount2010and price2012define the terms of the bid. The status2014might indicate, for example, whether the letter of transmittal has been submitted, saved, accepted, or deleted.

Referring toFIG. 21, a table represents the allocation database2100that may be stored at the bond exchange controller1600according to an embodiment of the present invention. The table includes entries define how bonds will be distributed after the close of the exchange. The table also defines fields2102,2104,2106,2108,2110,2112for each of the entries. The fields specify: an exchange identifier2102, a new issue identifier2104, a client identifier2106, an amount2108, a price2110, and a status2112. The information in the allocation database2100may be created and updated, for example, based on calculations performed by the bond exchange controller210. Note that the status2112might indicate whether a particular allocation has been blocked, settled, and/or cleared.

Web Server Example

FIG. 22illustrates an example of a bond exchange Web server2200according to one embodiment of the present invention. The Web server includes a database2210that may, for example, include any of the information described with respect toFIGS. 17 through 21. Note that the database2210might include information about a plurality of bond exchanges and/or a plurality of issuers. The database2210also receives information from an exchange setup unit2220(e.g., to provide basic information about the bond exchange) and a price/yield populator2230(e.g., to allow for any security in an exchange).

The database2210also provides information to exchange Common Gateway Interface (CGI) scripts2240that generate Web pages2260to display the information. According to some embodiments, a JavaPlot server2250is used to generate demand curves for the Web pages2260. The JavaPlot server2250may, for example, generate graphs based on a data set. The Web pages2260may also be used to store information into the database2210via the exchange CGI scripts2240.

FIG. 23is a flow chart of a bond exchange Web server2200method according to some embodiments of the present invention. At2302, a request for information is received from a remote device. If the remote device is associated with a client at2304(e.g., based on a user identifier and password associated with the request), information associated with that client is transmitted at2306. For example, a Web page listing that client's letters of transmittal might be transmitted to a remote client device240.

If the remote device is associated with an issuer at2308(e.g., based on a user identifier and password associated with the request), information associated with a number of different clients is transmitted at2310. For example, a Web page listing letters of transmittal received from a number of different client might be transmitted to a remote client issuer220.

If the remote device is associated with settlement agent at2312, the Web server2200transmits settlement agent information at2314(e.g., to a settlement agent device250). Similarly, if the remote device is associated with clearing agent at2316, the Web server2200transmits clearing agent information at2318(e.g., to a clearing agent device260). Finally, the Web server2200might transmit system user information if appropriate at2320(e.g., when the request for information was received from a system administrator).

FIG. 24is a flow chart of an issuer device220method according to some embodiments of the present invention. In particular, deal information associated with a bond exchange is transmitted to a remote bond exchange controller210at2402, the deal information including information associated with at least one eligible issue and at least one new issue. At2404, bond exchange allocation information is received from the bond exchange controller210(e.g., via a Web page or email message), the bond exchange allocation information being automatically calculated based on the deal information and offer information provided from a client device.

FIG. 25is a flow chart of a client device240method according to some embodiments of the present invention. In particular, offer information is transmitted to a remote bond exchange controller210via a communication network at2502. At2504, bond exchange allocation information is received from the bond exchange controller210, the bond exchange allocation information being automatically calculated based on the offer information and deal information associated with a bond exchange, the deal information including information associated with at least one eligible issue and at least one new issue.

Additional Embodiments

Although embodiments of the present invention have been described with respect to storing potential letters of transmittal at the bond exchange controller1600, according to other embodiments some or all of this information is instead stored at the client device210.

Moreover, although some embodiments have been described with respect to a bond exchange, the present invention can be used in exchanges associated with any type of financial instrument. For example, embodiments may be used to exchange old and new instruments where a fixed value is assigned to one instrument and a bided value is assigned to the other instrument. Moreover, the term “instrument” could actual refer to a set of individual instruments. For example, an exchange might involve collecting old bonds and providing new bonds along with warrants having separate expiration dates.