WO2001025997A2

WO2001025997A2 - Structured finance transaction analytic system and method

Info

Publication number: WO2001025997A2
Application number: PCT/US2000/026985
Authority: WO
Inventors: Michael Eggert; Bruce Boyd; Elaine M. Wong; Susan F. Williams
Original assignee: Jpmorgan Chase Bank
Priority date: 1999-10-01
Filing date: 2000-09-29
Publication date: 2001-04-12
Also published as: WO2001025997A8; AU7842300A

Abstract

An integrated system and method for assembling, tracking, managing and reporting on CDOs. The system includes databases for issuers, collateral, deals, countries, trust accounting, ratings, payments, receipts and all other data required to manage deals. Since all of the deals operate off of these common databases, as data changes, the change is instantaneously reflected in all the deals.The system further includes client service functions, client management, deal management and collateral administration, calculating agent management, paying agent management, trust accounting, collateral asset processing, custody, note and note holder management and payment, cash flow management, interfaces to various payment facilities (e.g., SWIFT) and interfaces to various other banking institutions. The system and method provides a user with the ability to formulate and execute hypothetical trades and view the resulting effects on the deal. The system and method further allows the user to perform compliance testing and cash flow management functions.

Description

STRUCTURED FINANCE TRANSACTION ANALYTIC SYSTEM

AND METHOD

FIELD OF THE INVENTION

The present invention generally relates to a system and method for tracking and analyzing structured financial transactions and more specifically to a system and method for tracking and analyzing Collateralized Bond Obligations and Collateralized Loan Obligations.

BACKGROUND OF THE INVENTION

Collateralized Bond Obligations (CBO) and Collateralized Loan Obligations (CLO) (collectively Collateralized Debt Obligations,

CDO) are financial instruments in which bonds or commercial loans are pooled and securitized and notes or participation certificates are sold to investors. A CBO/CLO is a structured securities transaction (or deal as is known in the art) in which the seller is typically denoted as the issuer (or originator) and the buyers are one or more investors. The notes or participation certificates are the liabilities of the CBO/CLO, while the assets of the deal are the securities that collateralize the CBO/CLO. Securities are the equity or debt (bond, loan, note) instruments that may be issued or owned by a deal. Debt securities consist primarily of bonds and loans that are purchased by a deal. The issuer is the legal entity that has the authority to offer its own bond, note or stock certificate for sale to investors. For instance, an issuer can issue bonds, be the borrower on a loan, and can be the business entity that sets up the special purpose vehicle referred to as the deal. Issuers of structured financial securities are those entities who generate financial assets in the normal course of their business. Such issuers include, but are not limited to, banks, thrifts, mortgage companies, manufacturers and distributors with a financing division, retailers with credit card or other finance operations, consumer finance companies, specialty finance companies, equipment lessors, asset aggregators, or any other business enterprise that generates substantial quantities of trade receivables.

Investors include, but are not limited to, insurance companies, banks, thrifts, mutual funds, and private investors. Other interested parties with respect to a deal include rating agencies, insurers, research firms, investment banks, and accounting firms.

The first structured transactions occurred in the late 1980s and provided an important means for troubled financial institutions to dispose of their high yield bond portfolios. Subsequent structured transactions have given investment managers another tool to increase their

"assets under management" and banks a means of moving assets off of their balance sheets and/or provide less expensive and stable funding sources. Figure 1 illustrates a simplified diagram of the structure and typical entities involved in a deal 100. The deal 100 is structured in accordance with one or more documents, such as an Indenture. This is the primary document that governs the deal, including the roles of a rating agency 105, a financial advisor 110, a sponsor or collateral manager 115, and a trustee or collateral administrator 120. The financial advisor 110 is typically an underwriter such as an investment bank (e.g., J.P. Morgan, Goldman Sachs...). The sponsor/collateral manager 115 often holds equity in the CLO/CBO 100.

The primary responsibility of the trustee/collateral administrator 120 is to represent the investors in the management of the CDO 100. This management responsibility includes cash management, making trades, making payments, processing assets, testing the deal 100 for compliance and administering the collateral, all in accordance with the Indenture agreement. In the context of a large structured finance, the trustee 120 is typically one out of four or five large financial institutions (e.g., Chase Manhattan Bank). Figure 1 also illustrates the portfolio assets

125 and the securities 130 involved in the deal.

One significant problem associated with the prior art is the difficulty experienced by trustees 120 and collateral manager 115 in assembling, tracking and managing a large number of complex deals. Historically, the management process has been very manually intensive, despite the use of computers and databases. In fact, the widespread use of computers has actually made the management of a CDO 100 more complex. Typically, the various information required for active CDO management is found on a variety of different systems with a variety of different formats and access requirements. The lack of interoperability of these various systems has made the management process that much more dependent on manual oversight. The manual process is costly and can lead to errors if the proper checks and balances are not incorporated into the systems and processes of the trustee 120 and the collateral manager 115. Furthermore, the manual nature of prior art process leads to redundant efforts as many of the issuers, assets, information sources, etc. are common to several deals.

Another significant drawback of the prior art is ability to generate reports reflecting the status of the CDO 100, including the performance of the underlying assets. Regular reporting requirements are typically imposed upon the trustee/collateral administrator 120 by the Indenture agreement. Investors are often interested in the performance of the underlying assets securitizing the CDO 100 because it could affect the timing and amount of income received on the security or the ability to be repaid the principal of the security. The Indenture agreement will typically require that the issuer prepare periodic reports concerning the status of the underlying pools of assets 125. This task is typically assigned by the issuer to the trustee 120 . For example, when a pool of assets 125 comprises a number of loans which underlie a security, the issuer may be bound to provide status to the investors on the underlying loans. The status may include, for example, principal collected, interest collected, foreclosures, prepayments, losses, delinquencies, whether trigger thresholds have been reached, etc. Due to the manually intensive nature of the systems and methods of the prior art, the conventional reports prepared by the trustee 120 are difficult to prepare and are often limited in the type and nature of the information contained in the report. Further, each report generated by the trustee 120 relates to only a single deal. It is not possible, therefore, for these reports to provide information as to the performance of a portfolio of underlying assets from more than one deal. For example, if an investor were interested in the asset performance of all assets originated by issuer X in the same year, then those assets would likely securitize obligations related to more than one deal. The conventional reports, therefore, would not provide the investor with the information desired.

An additional problem with the prior art systems is their inability to adapt to increasing complexity of CDO 100 due to the evolving structures of new CDOs 100 and the inclusion of more varied types of assets used as collateral such as derivatives, Real Estate Investment Trusts (REITs), commercial mortgages and annuity payments or other payment streams (e.g., tobacco settlements).

Accordingly, there is a need in the art for a new method and system for assembling, tracking, managing and reporting on a plurality of CDOs that are collectively associated with a huge number of assets and securities.

SUMMARY OF THE INVENTION

The present invention provides an integrated system and method for assembling, tracking, managing and reporting on CDOs. The present invention allows for global asset administration, includes multiple asset categories (including loans), has cashflow capabilities, provides interfaces to various financial information services and includes the capability for clients to access the system for retrieving and reviewing various information with respect to deals, proposed deals, and hypothetical trades.

The system includes databases for issuers, collateral, deals, countries, trust accounting, ratings, payments, receipts and all other data required to manage deals. Since all of the deals operate off of these common databases, as data changes, the change is instantaneously reflected in all the deals.

Some of the significant components of the system of the present invention include client service functions, client management, deal management and collateral administration, calculating agent management, paying agent management, trust accounting, collateral asset processing, custody, note and note holder management and payment, cash flow management and common data services. Some of the interfaces to the outside world from the system of the present invention include a client interface, an interface to rating services, interfaces to various payment facilities (e.g., SWIFT) and interfaces to various other banking institutions. A significant aspect of the present invention is the client interface. The system of the present invention allows clients (collateral managers, trustees, investors) to access the system either through the Internet or private value added networks or through direct dial lines. The system includes the appropriate security such that unauthorized access to the system is prevented. Furthermore, each user of the system is only able to view data which he/she had been authorized to view. The client interface further provides for export of reports such as hypothetical testing reports and compliance testing reports.

Another significant capability of the present invention is the ability to formulate and execute hypothetical trades. Using this function, collateral managers are able to propose hypothetical trades, hypothetically execute these trades, and view the resulting effects on the deal. Compliance testing during the hypothetical execution informs the collateral manager as to whether or not such a hypothetical trade would be allowed under the Indenture. Once the hypothetical trade data has been input and tested, the user is able to actualize (execute) the trade.

Using the cash flow management portion of the present invention, the user is able to quickly view the projected cash flow transaction, actualize cash flows, and compare the projected to actual cash flows. Actual payments and receipts are fed from other systems in order to update the databases of the system of the present invention.

Other objects, features, and advantages of the present invention will be apparent to one skilled in the art from the following description of the invention with reference to the accompanying drawing.

BRIEF DESCRIPTION OF THE DRAWING For the purposes of illustrating the present invention, there is shown in the drawings a form which is presently preferred, it being understood however, that the invention is not limited to the precise form shown by the drawing in which: Figure 1 is an illustration of the structure and various parties to a structured finance transaction;

Figure 2 illustrates the system of the present invention for assembling, tracking, managing and reporting on CDOs;

Figure 3A-3D illustrates the main user interface with respect to input, update and maintenance of issuer data;

Figure 4A-4H depicts the user interface with respect to securities;

Figure 5 A depicts the main deal interface;

Figure 5B illustrates the deal detail user interface; Figure 5C shows the user interface with respect to collateral;

Figure 5D depicts the note interface;

Figure 5E shows the interface associated with roles;

Figure 6 depicts the user interface for scenarios;

Figure 7 illustrates the cash flow transaction interface; Figures 8 illustrates the report interface;

Figures 9-12 illustrate sample pages from a typical report generated by the present invention;

DESCRIPTION OF THE PREFERRED EMBODIMENT

Figure 2 illustrates the system 150 of the present invention for assembling, tracking, managing and reporting on structured finance transactions. As seen in this Figure, the system 150 integrates several functions and databases into a single seamless system 150. The core functional components of the system 150 include: Client Management 160; Client Services 170; Deal Management and Collateral Administration 180; Calculating Agent Management 190; Paying Agent Management 200; and Trust Accounting 210. Support components of the system 150 include: Collateral Asset Processing 220; Custody 230; Note and Note-Holder Management and Payment 240; Cashflow Management 250; Common

Data Services 260; Messaging 270; and a Payment System 280. Further illustrated in Figure 2 are the interfaces to the external world including clients 295, other banks 272-278, payment transfer systems 282, and rating services 290. The Client Management component 160 performs the functions of Account Management 162, Query Resolution Tracking 164, Product Marketing 166, and Account Performance Tracking 168. These tools 162-168 are used by the Relationship Manager (RM) to manage the relationship with the clients. The Account Management Function 162 allows the RM to view the status of all of the deals in which a particular client is currently participating or has participated. To accomplish this function, Account Management 162 uses the data contained in the various databases of the system such as the Deal Data 184 and the consolidated Collateral Asset Data 186. Similarly, the Account Performance Tracking module 168 allows the RM to track the performance of the deal for any particular client. Client Management 160 further provides a function for Query Resolution Tracking 164 when clients have questions concerning their accounts. The Product Marketing component 166 allows the RM to generate marketing materials for presentation to existing or potential clients (e.g., performance data related to past deals, or the historical performance of a particular issuer).

Client Service Functions 170 include: Hypothetical Trade Input 172; Data/Report Export Facility 174; Hypothetical Testing and Reporting 176; and Compliance Testing and Reporting 178. The Client Service Functions 170 provide the main interface to system 150 for Client's 295. In a preferred embodiment of the present invention, clients access system 150 through the Internet using the appropriate security mechanisms such as encryption, password protection, firewalls, etc. (not shown). Alternatively, clients 295 can access system 150 through a direct dial line or other private network connection.

The ability of clients 295 to access the system of the present invention and view data in real time is a significant advantage of the system 150 over the prior art. In the prior art, the primary method by which clients (e.g., investors) received any information regarding deals was either through paper or electronic reports (e.g., Excel™ spreadsheets). Using the present invention, clients 295 are able to sign onto the system and generate and view reports themselves. Although not illustrated in Figure 2, in addition to normal security procedures (firewalls, passwords...), the data of the present invention is protected by authorization methods. Data can only be accessed by a user, if the user has been granted access (authorization) to view the data. Similar protections exist for functional components of system 150. For example, a client 295 would not be able to access the payment system 280 for the transfer of funds. As will be further described below, the hypothetical trade input component 172 allows a client 295 to propose hypothetical trades with respect to a deal. This component 172 accepts the input data from the client 295 for the proposed hypothetical trade. The interface module 172 provides this hypothetical trade data from the client 295 to the hypothetical trade module 188 for the calculation of the results of the hypothetical trade.

The Data/Report Export facility 174 is responsible for generating and exporting various reports for clients 295. Reports can be run for a variety of reasons such as supplying information with respect to a client's trade portfolio. Reports are typically required by the Indenture agreement to provide investors with the status of deals. Reports in accordance with the present invention can provide historical data on trades in cash flow transactions as well as reports regarding hypothetical trades run with respect to a particular deal. The hypothetical testing and reporting module 176 operates on the data input via interface module 172. As further described below with respect to the Compliance Testing and Report Module 178, the hypothetical testing module 176 allows clients 295 and Portfolios Managers to test proposed trades to see how they affect the overall structure and performance of a deal with respect to the compliance rules required in the Indenture. The results of the hypothetical testing can be reported in the same manner as described below with respect to the actual compliance testing.

The Compliance Testing and Report Module 178 is used to ensure that a current deal is in compliance with the Indenture governing the deal. Compliance testing and the reports generated are discussed below in connection with Figures 8 and 9-12.

Deal Management and Collateral Administration 180 is the core component for the Deal Management aspect of the present invention. Module 182 is the module by which deals are initially established and subsequently maintained. The Deal Data database 184 contains all of the data specific to particular deals such as contact points, investors, assets contained in the deal and accounts associated with the deal. The Consolidated Collateral Assets Data Database 186 contains all of the data related to all of the assets contained in all of the deals maintained in the system. Element 188 is a database which contains temporary data which is used by hypothetical testing reporting module 176 to run hypothetical trade scenarios as more fully described below. Module 187, Actualize Hypothetical Trades, is used to execute the trades contained in a hypothetical scenario previously run by the Hypothetical Testing and Reporting module 176.

Element 190 is the Calculating Agent Management component. Module 192 provides for review and approval by the Relationship Manager of the results of any hypothetical testing and reporting 194 and compliance testing and reporting 196. Module 198 calculates the deal specific principal and interest with respect to the notes and securities contained in, and associated with a deal.

Paying Agent Management 200 is responsible for monitoring, payment and reception of payments associated with deals. Element 202,

Note and Note Holder Details Advising and Monitoring, determines when payments are required to be made with respect to the notes associated with the deals. Element 204, Payments and Receipts Processing, performs the actual payment and receipt management in conjunction with the cash flow management module 250 described below. Waterfall Calculation section

206 performs the traditional waterfall calculations known to those skilled in the art. The indenture sets forth the rules (priorities) as to how funds are to allocated (e.g., principal and interest payments). The waterfall calculation section 206 carries out, implements, these rules from the indenture. Element 210 performs all of the traditional trust accounting functions required of a trustee such as Financial Reporting 211, Tax Reporting 212, Trust Reporting 213, Account Reconcilement 214, Accounting 215, Account Setup and Maintenance 216, and Special Purpose Vehicle (SPV) accounting 217. The trust accounting functions are the traditional functions performed by a trustee but have been greatly facilitated by the integrated nature of the present system 150. For example, all of the data required for these function is now available in a single system 150. Collateral asset processing 220 provides a support function of gathering data with respect to the assets contained in the deals. This data is then fed to Consolidated Collateral Asset Data database 186. The raw data with respect to the collateral originates from agent or custody banks 272- 278 and is preferably transmitted to the system of the present invention using secure XML Messaging 270. The raw data from the agent banks 272-278 is then converted and loaded into the processing section dealing with the type of asset (see element 208, data converters/loader). There is a different processing section for each type of collateral, loans 202, bonds 204 and other types of assets 206.

Element 230 contains a custody module 232. Custody is a traditional trustee function in which the trustee holds the actual asset in trust. The custody module 232 tracks the custody of the collateral assets maintained in the system. Element 240 manages and processes payments on notes to note holders. Module 242 contains the details with respect to each note associated with the deals as well as details with respect to the note holders. Component 244 contains the specific payment instructions with respect to each note holder (e.g., payments in U.S. dollars to bank account XYZ). Cash Flow Management Section 250 manages the cash flows from the accounts associated with each of the deals. Module 252 projects cash flows that are to be realized by each of the deals. Component 254 compares the projected cash flows from a deal to the cash flows actually experienced by the deals. Component 256 executes the actual payments and receives the receipts with respect to the deals. These payments and receipts are typically processed through payment system 280 which has an interface with industry standard electronic funds transfer systems such as SWIFT or Fedwire 282. Element 260 provides common database services. Two of the databases contained in this component are Common Data (e.g., LIBOR, Country Holidays...) 262 and characteristics of the assets used as collateral 264. The characteristic data is retrieved from various rating services 290 such as Moody' s™ or Bloomberg™.

In initially establishing the system of the present invention, several of the databases of the system must be initially populated. One of the core databases includes all of the information related to issuers. As previously described, the term issuer refers to a legal entity that has the authority offer its own bond, note, or stock certificate for sale to investors.

For instance, an issuer can issue bonds, be the borrower of a loan, and can be the business entity that sets up the special purpose vehicle referred to as the deal. Figure 3 A illustrates a screen shot of the user interface to the system of the present invention with respect to issuers. The issuer window 300 is separated into four separate tabs: Search 302; Issuer Detail 304;

Affiliate 306; and Credit Rating 308.

When the issuer window 300 is initially brought up, it displays an alphabetical listing of all of the issuers including bonds, loans and notes existing in the database in area 322 of window 300. In the example depicted in Figure 3 A, the database has already been populated with a plurality of issuers. During the initial set up of the system of the present invention, area 322 is blank since there are no issuers to display. In order to add an issuer, the user uses his or her input device (e.g., a mouse) to activate a pop-up menu 310. Pop-up menu 310 provides the user with the ability to add, delete, find issuers, to scroll the list of issuers or to retrieve or sort the issuer list. Following conventional windows standards, there are multiple ways to navigate and perform activities within the system of the present invention. Activities can be performed using mouse actions or keyboard actions, or a combination of both. Although only described in detail with respect to this interface 300, other interfaces of the system of the present invention provide the same or a similar pop-up window 310 to provide additional functionality.

When the user selects the add function from pop-up menu 310, the window 330 associated with the issuer details tab 304 is presented to the user as depicted in Figure 3B. In the issuer details window 330, the system prompts the user for the issuer name 312, the country of the issuer 314 and whether or not the issuer is a sovereignty 331. A sovereign issuer represents a government as opposed to a corporate issuer who represents a corporation. This distinction becomes important when running collateral quality tests. The percentage of sovereign issuers and non-sovereign issuers are typically part of the collateral debt service requirements. The user is further requested to provide the tax ID 332 of the issuer, the company name 316 and the first 318 and last name 320 of the contact at the issuer. As illustrated in Figure 3a, the directory listing of issuers includes the issuer name 312, the country of the issuer 314 the company name 316, and the first 318 and last name 320 of the issuer contact.

The affiliates tab 306 opens up a window 340 for entry of information related to affiliates of the issuer as depicted in Figure 3C. Affiliates are groups of companies, such as holding companies in which a corporate parent/subsidiary relationship exists, and in which the affiliates are financially related to each other. The issuer is the parent company while the affiliates are typically the subsidiaries. The affiliates window 340 displays a list of candidate affiliates 341 which can be established as affiliates of the issuer using conventional drag and drop methods on the affiliates window 340. The affiliate relationship is established when the issuer name 342, the effective date 343 and the discontinued data 344 are completed in window 340. The credit rating tab 308 opens up a user interface 345, as illustrated in Fig. 3D, that displays the selected issuer's credit rating. Prior to clicking on credit rating tab 308, the user must select one of the issuers displayed in area 322 (in window 300, Figure 3A). Using the input device (e.g., mouse), the credit rating for an issuer is obtained from one of several rating service sources (see 290 in Figure 2), such as Bloomberg™, Standard and Poors™ or Moody 's™. For a new issuer, the credit rating is added by selecting the information source 346, selecting a rating 347, and entering the effective date 348 when the rating is in effect and a discontinued date 349 (if applicable) which is the date the rating expires.

Credit ratings are used by many type of issuers such as bond issuers, borrowers of loans, and business entities that set up special purpose vehicles.

One of the elemental types of data contained in the system of the present invention is the security. Figure 4A illustrates the main window 350 with respect to securities. The information contained in the system regarding securities is separated into eight separate tabs in window 350: Search 352; Detail 354; Price 356; Interest Schedule 358; Credit Rating 360; Contacts 362; Default History 364; and CUSIP History 366. As with the issuer window 300 illustrated in Figure 3 A, activation of the search tab 352 on the security window 350 brings up a list of all of the securities contained in the databases of the system. As seen in Figure 4A, the securities are listed in alphabetical order. The securities are listed by the issuer name 370, the security name 371, the Committee on Uniform Securities Identification Procedures (CUSIP) 372, the International

Standard Identification Number (ISIN) 375 the Bloomberg™ number 375 and the security type 374.

In order to add a new security to the database, the user brings up a pop-up menu associated with the window and selects the Add fiinction. The Add function activates the window 380 associated with the Detail tab 354 as illustrated in Figure 4B. The security detail window 380 allows the user to input the issuer name 370(a borrower in the case of a loan), the type of security 374 (e.g.., bond, loan, note, etc.), the security name 371, the CUSIP 372, the ISIN 373, the Bloomberg™ identifier (if any) 375, the amount of the original principal 383, the settlement location 384, and the registration type 385 (or loan type, e.g., term, revolving). If the type of security selected is a loan, the user is prompted to enter Reference ID 381 and Facility ID 382. The security detail window for notes and contracts types of security are essentially the same as the window for loans, less the loan type and loan sub-type fields.

If the type of security selected is a bond, the user is prompted to check the Bloomberg report to see if the bond is prefunded, if the bond has warrants attached, if it is convertible and if it is callable 386. If the bond is callable, the user additionally needs to set up a call schedule in the database for the bond. The call schedule requires a beginning and ending date and the call price as shown in Figure 4C.

The price tab 356 Figure 4C opens a user interface 400 in which the user is able to indicate a market information source 401 and the price 402 of the security as well as an effective date 403 and a discontinue date 404 for the price. An example of a market information source is Bloomberg™.

The interest schedule tab 358 opens up a user interface window 410 as illustrated in Figure 4D that enables the user to input the interest schedule associated with the particular security being added or modified. The user is prompted to select either a floating interest rate or a fixed interest rate 411. If the fixed interest rate is selected, the user is prompted to enter the interest accrual date 412 (the first date the interest begins to accrue on the security) the 1^st coupon date 413, the maturity date 414, the payment frequency 415 and the convention used for day counting 416. If the rate type is floating, the user enters the index upon which the rate is calculated 417, the spread 418, the cap rate (the highest rate the security will adopt) 419, the floor rate (the lowest rate that the security will adopt) 420 and an override rate (if applicable) which is a rate that will be effective for a certain period of time and will override a previously entered rate for a specific security and calculate daily checkbox, 421. For both fixed and floating rates, the user enters a country name 422 which will determine the holidays observed with respect to the payments regarding the security. The country holidays are contained in the common data database

262 (see Figure 2).

Since all of the deals maintained in the system use a common database, any change made to the security interest schedule for a specific security will have a cascading effect on all deals that have an open position in that security. Any change affects projected transactions after the date of the latest actualized transaction with respect to that security.

The credit rating tab 360 opens a window 430 as illustrated in Figure 4E that allows the user to input a market information source 431 , a credit rating from the market information source 432 and an effective date 433 and a discontinue date 434 for the credit rating. Again, since the deals use a common database, any changes to the security credit ratings will have a global effect on all of the deals having an open position in that security. The credit rating interface 430 further allows the user to use an implied credit rating 435. In inputting an implied credit rating, the user identifies the security from which the current securities credit rating is implied, as well as a spread from the credit rating of the underlying security 436. In a preferred embodiment, an implied credit rating is used for informational purposes only. If a security has an implied credit rating, it is not necessarily automatically adjusted as the underlying securities credit rating changes.

The contacts tab 362 opens a window 440 as illustrated in Figure 4F in which the user can input the contacts for the security including the company name 441, the first and last name 443, 442 of the contact, the tax ID of the company 444 and Role type 445. The window 450 associated with the Default History tab 364 as shown in Figure 4G enables the user to input any history of default with respect to the selected security. The window prompts the user to enter the defaulted reason 451 and the effective 452 and discontinued dates 453 of the default.

The CUSIP history tab 366 opens a window 460 as shown in Figure 4H that allows a user to modify the CUSIP of a security. The user is prompted to enter the old CUSIP 465, the new CUSIP 461, user created 462 and the effective and discontinue dates 463, 464. As previously described, the main purpose of the system and methods of the present invention is the management of deals. Figure 5 A illustrates the main user interface 500 (the search window) with respect to deals. The search tab 502 is used to view this main window 500. As illustrated in Figure 5 A, the directory of deals includes the issuer name 520, the deal code 522, the deal name 524, the AMTrust account number

526, the closing date 528 and the sequence number 530. As described with respect to the previous windows, the user employs an input device in order to activate the pop-up menu 532. The user then selects the add function in order to add a new deal. As illustrated in Figure 5B, activating the add button brings up the user interface 550 associated with the deal detail button 504. The first piece of information required in adding a new deal is the issuer name. By selecting the issuer name button 520 on window 550, the directory of issuers previously described with respect to illustrated Figure 3A is brought up for review by the user. The user can select one of the issuers from this directory for inclusion in the deal. It should be noted that an issuer can be the issuer of a deal as well as the issuer of a security contained in a deal.

In area 524, the user provides a name for the deal and in area 552 inputs the type of deal (e.g., CBO, CLO). The deal type refers to the majority of assets held by the deal. For instance, a collateralized bond obligation (CBO) would hold mostly bonds as its assets while a collateralized loan obligation (CLO) would hold mostly loans as its assets . Collateralized debt obligations (CDO) deals can be made up of mostly bonds or loans. The user inputs the AMTrust account 526 established for the deal. The user further inputs the earliest mature date 554, the latest mature date 556, the effective date 558 and the closing date 528.

As further illustrated in Figure 5B, the deal has a single AMTrust account 526 but is able to have many sub accounts (560). Sub accounts are used to track cash transactions posted to or transferred from one account to another. Sub accounts are also used to record cash flow items such as purchases, sales and principal and interest payments. Sub accounts must be linked to transactions in order to default to the correct sub account when a cash transaction is created. The accounts/transaction relationship must be set up before any transactions are created for the deal.

Typically, the required sub accounts are provided in the Indenture governing the deal.

Such accounts typically include a custodial account, a collection account, a payment account, and an unused proceeds account. For each account associated with the deal, window 550 depicts the sub account type 562, the sub account AMTrust number 564 and the balances 566 contained in each account. Using a separate window (not illustrated) the user is able to transfer money between accounts. The user is able to add in additional deal information to the records associated with the deal. This information includes: an abstract that summarizes the deal points (monthly report date, due period and payment date); the account transactions rules that maps allowable transactions to specific accounts and designates cash in/cash out and principle/interest; the asset categories which are set up as identified in the Indenture (additional asset categories can be added as necessary). The Indenture outlines the number of categories that are included in the deal defines the types of collateral to be assigned to each category, and defines the classification in which the notes (obligations) for the deal are assigned to an advanced rate matrix. The obligations are entered according to the terms of the Indenture for the purpose of building the advance rates table and determining the advance amount. The advance amount is calculated by multiplying the calculated amounts by the advance rates and totaling each column. This function is performed in a report section described below.

The advanced rates are entered into the matrix as identified in the Indenture. The purposed of the matrix is to: calculate the advance amounts and determine the discounted collateral value; identify the information sources such as a Bloomberg™ feed of Moody' s™ and S & P™ ratings; identify the permitted classifications which defines the industries and regions as used in the diversity test (described below); identify the permitted values that are used for identification of other characteristics of each security; identify the security type; and identify the trade groups associated with the deal. Transactions are events that occur against a deal such as the purchase or sale of a security or an interest projection. In setting up a deal, the user is prompted to enter account transaction rules that are used to set up which account 560 (e.g., collection account, payment account) against which the transaction will be credited (cash- in) or debited (cash-out). The system includes a list of default transactions which can be selected to be applied to a deal. Each transaction has a name, a type, a cash type, a cash flow and the account associated with the transaction. An example of a transaction is a collateral principle payment. This transaction would have the type collateral, the cash type principle, a cash flow of cash- in and a default account of the collection account. As transactions occur with respect to the deal, the user is able to select from the transactions allowed for the deal to define the transaction, and more importantly the account which the transaction will impact. Figure 5C illustrates the window 600 associated with the collateral tab 506. This window 600 depicts all of the securities 602 currently maintained in the deal as well as all of the actual and projected transactions 616 related to the deal. With respect to collateral 602, for each security, window 600 lists the settlement location 604, the security type 606 (e.g., bonds, loans, etc.); the security name 608; the CUSIP 610; the

Aggregate Original PAR 612 owned by the deal; and the Aggregate Current PAR 614 owned by the deal.

For each actual or proposed transaction 616 associated with the deal, window 600 depicts the transaction name 618, the cash flow 620 (e.g. cash in or cash out) the transaction date 622, the amount of the transaction 624, the type of transaction 626 (projected or actual), the principle 628, the interest rate 630, and the number of days in the accrual period 632 as well as the accrual begin and end dates 634, 636.

Figure 5D illustrates the window 650 associated with the note (obligations) tab 510. Displayed in this window 650 are all of the notes

652 associated with the deal. For each note, the following is described: the pay down priority 654; the CUSIP 656; the security name 658; the investor type 660; and the original principal amount 662. As with the collateral screen 600 depicted in Figure 5C, the note window 650 displays all of the transactions 664 of the deal with respect to the outstanding notes. The information for each transaction is the same as has been described above with respect to the transactions 616 in the collateral window 600 (see Figure 5C). Figure 5E depicts the user interface 670 associated with the role assignment tab 612. Each of the roles in the deal 672 are listed in this window. For each role, the following information is provided: the role type 674 (each of the role types for the deal is listed in the Indenture); the company name 676; the first and last names of the person fulfilling the role 678, 680; the effective date of responsibility 682; and the discontinue date

684. Area 686 on window 670 contains potential candidates for each of the roles. These potential candidates are maintained in the database of the system.

Once the database of the system of the present invention has been populated (issuers, securities, deals) one of the significant features and advantages of the present invention is thus enabled. Namely, executing real and hypothetical trades. In order to execute real or hypothetical trades, the user generates a scenario for the trade which contains the details of the trade. The main screen for scenarios 700 is illustrated in Figure 6. Before entering this scenario screen 700, the user was presented with a list of securities to buy or sell. In the particular example illustrated in Figure 6, the right hand portion of the window 700, known as a trade ticket, has already been populated with the name of the security 702 selected for the transaction by the user, the CUSIP 704 for the security and the ISIN number 706 for the security (in this particular example, the security did not have an ISIN number). The user is then prompted to fill in the trade date 708 and the date of settlement for the trade 710. The user further selects whether the trade is a hypothetical trade 712 or a real trade 714. The user then indicates in area 716 whether or not the trade is a buy or a sell of the security. In area 718, the user is able to indicate whether or not this trade is grouped together with other similar trades in a trade group if making a purchase. For example, an initial purchase of a security maybe grouped with initial purchases of other securities into one trade group. When selling, the system prompts the user for a reason for the sale in order to verify that the sale is one permitted by the rules of the indenture.

If the trade relates to the purchase of a bond security, the user enters the value to be purchased in the original PAR value field 720. For such a purchase, the current PAR value field 722 will default to the original

PAR value. The user can override this default. The user then enters the price in field 724. The principal cost 726 and the premium/discount fields 728 are automatically calculated and filled in by the system of the present invention. The user then fills in the account 730, 732 to be debited for a premium or credited for a discount.

Real trades affect the balances of the accounts associated with the deal (see 560 in Figure 5B). Hypothetical trades are used for "what if testing. The results of the hypothetical trade can be viewed using the reporting feature of the present invention as further described below. Once all of the data related to the trade has been entered, the user can save the data in the database. As previously described, if the trade is a real trade, the appropriate databases and balances in the system are updated while if the trade is a hypothetical trade, the data will be stored in a separate database (see 188 in Figure 2). As seen on the left hand portion of window 700, each of the scenarios 734 for the chosen deal are displayed.

Another significant advantage of the present invention is the ability to perform cash flow transactions. The main screen 750 for cash flow transactions is illustrated in Figure 7. Cash flow transactions include the purchase or sale of securities, receipt of interest and principal, receipt of reinvestment income, payment of notes and payment of fees and borrowings on loans. The present invention allows the user to more readily discover input errors because it eliminates the use of multiple reconciliation points. The cash flow management window 750 illustrated in Figure

7 can be accessed from many different areas. The user can be directed to this window 750 from a selected deal, sub account, note or role assignment (see Figures 5A-5E). Each of the projected and actualized transactions 752 are displayed in the cash flow management window 750. For each transaction, the following information is displayed: the book date 752 (the date of the posting of the transaction); the account 754 from which the transaction flows (cash out) or into which the transaction flows (cash in); the transaction type 756 (e.g., collateral interest) the type of cash flow 758 (cash in or cash out); the type of transaction 760 (projected or actual) the projected amount 762 of the transaction scheduled to be received or paid; the actual amount 764 of a transaction which has been actualized (received or paid); the actual total 766 (the sum of the transactions that have been actualized against a projected transaction); the actual date 768 (defaults to the present date) and the actual amount 770 (the amount of the transaction that is being actualized.)

Area 772 illustrates the account balances as of the book date for a selected transaction. These amounts include the balance of the principal that has already been actualized 774, the amount of interest 776 that has been actualized, the cash due in from principal 778 according to the projections, the cash due in from interest from projections 780, the cash due out of principal 782 (including the total projected and actualized principle amounts due out by the last book date) and the same for interest amounts 784, the due balance of principal 786 (the amount of the unreceived principal) and the amount of the unreceived interest 788. In area 790, the user is able to select different variables which can be used to tailor the search criteria for performing cash flow transactions, e.g., filtering. The filtering functions allows the user to select all sources of data for the cash transaction screen 750 (notes, collateral, and role types for the deal) or filter only one of collateral, note or role. The user can further define a beginning date and an end date for transactions to be displayed in window 750. The user can further filter using a transaction name, the account name or the transaction type. The selected filter criteria will determine which transactions are displayed in area 752 on window 750.

The user is able to actualize a projected transaction using the cash flow management window 750. To actualize a projected transaction, the user selects the transaction in area 752. The actual date 768 must match the book date 752. If the actual date does not match the book date, the user can alter the actual date. Once the dates match and the projected amount 762 is equal to the amount the user wishes to actualize, the user clicks on the actualize button 792 and clicks on the Save button 794 to complete the actualization of the transaction. If the user wishes to actualize a different amount from the projected transaction amount 762, the user types in the actual amount desired to be actualized in field 764 and clicks on save.

The user is also able to add unscheduled cash flows to the list of transactions 752. In order to add such an unscheduled cash flow, the user brings up the previously described pop-up window and selects add. The user is then able to fill in the book date 752, select an account 754, select a transaction 756, and the cash flow 758, select "actual" and the type 760. The user then enters the amount in the actual field 764 and clicks the Save button 794 to add the unscheduled cash flow. A further significant feature of the present invention is its ability to generate and export reports regarding deals, securities, transactions, hypothetical trades, projected and actual cash flows and a variety of other information. The deal descriptor tab 508 on window 500 5 (see Figure 5A) enables the user to input further descriptive information with respect to each piece of collateral contained in the deal. One of the descriptions which the user can input is reporting requirements including the report beginning and ending dates and the report due period beginning and ending dates. Typically, the Indenture requires at least monthly o reports. The user can additionally define interim reports that can be run at any time to include a reporting period of a specific length greater or less than an month in duration.

On the menu bar on the user interface (not shown) the user clicks a report button in order to bring up the initial report interface 800 5 illustrated in Figure 8. On window 800, the user either types in the desired deal name in area 808 or selects a deal from a drop down menu (not shown). Each of the scenarios for the deal are listed in area 810 of window 800. The scenarios were previously defined by the user for performing trades (see Figure 6 and its associated discussion). The scenarios also 0 include a monthly report 812 and an interim report 814 as previously described with respect to the deal descriptors added by the user. As previously described with respect to Figure 5E, each scenario for a user's hypothetical trade is listed in area 810. Hypothetical reports can be run against the hypothetical scenarios in order to test the viability of the 5 proposed trade. The reports include all real trades currently in the system and additionally include all hypothetical trades included in the selected scenario.

In order to run and view a report, the user selects run and view button 816 to begin a report of the most current data contained in the database, based on the scenario selected. The report, once completed, is presented for viewing by the user. Alternatively, clicking on the run button 818 alone begins a report of the most current data in the database. Clicking on the view button 820 will view the last report that was created. The present invention runs an exception report before any report. An exception report provides the user with a list of missing fields and if there is any missing data, an error message displays in the title of the report. If the user wishes to only run an exception report, checkbox 826 is activated. If the user wishes to suppress the running of the exception report, checkbox 828 is checked. Once a report has been generated, it can be included an email to send to interested parties (e.g., investors)by using checkbox 830. In an alternative embodiment, the report can be posted on a secure website for access, viewing and/or downloading by the interested party. The report can also be exported to a disk file suing button 824 and the options in box 832.

Figures 9-12 illustrates sample pages from a typical report. Page 950 in Figure 9 illustrates a summary page. Typically, the summary page 950 is the first of all reports and contains a summary of all the tests 952 required by the Indenture. The summary page 950 also contains asset information, cash balances, information on liabilities, and portfolio information 954. The notes statistics section 956 of the summary page 950 includes note name, outstanding balance and interest rate with respect to the selected deal.

Figure 10 illustrates an index page 960 of the report. As can be seen in this Figure, the report run in this example contains 113 separate pages. In a preferred embodiment of the present invention, each of the entries on the index page is a hyperlink to the detailed page that supports the particular entry. In this manner, the user is able to drill down to the detailed information contained on any particular page of the report. In the example report illustrated in this Figure 10, eleven different tests were run as part of this scenario including overcollateralization tests, interest coverage tests, a diversity test, a maximum rating distribution test, a security sold test, a cumulative maturity profile test, an issuer rating distribution test, and a minimum average recovery rate test. The remainder of the report pages provide various information with respect to the scenario selected.

Figures 11 and 12 illustrate pages associated with an interest coverage test. Window 970 in Figure 11 is an interest test page. This interest test page 970 contains the summary of the test that was performed against the scenario. The detailed results of the test are contained in a detailed schedule 980 as illustrated in Figure 12. In a preferred embodiment of the present invention, each of the tests will include the test page 970 and the detailed pages 980. Any report that is generated by the system of the present invention can be printed and additionally exported as an electronic file. This exporting feature is particularly advantageous as a relationship manager is able to electronically generate these reports and export them to all required and interested parties. Standard security techniques such as encryption are used to protect the confidentiality of any exported financial information.

Although the present invention has been described in relation to particular embodiments thereof, many other variations and other uses will be apparent to those skilled in the art. It is preferred, therefore, that the present invention be limited not by the specific disclosure herein, but only by the appended claims.

Claims

We claim: 1. A system for managing Collateral Debt Obligations comprising: a user interface; a deal database, the deal database storing at least first deal data describing a first deal; a collateral asset database, the collateral asset database storing at least first collateral asset data describing a first collateral asset, wherein the first deal data is logically related to the first collateral asset data; and at least one processor coupled to the user interface, the deal database and the collateral asset database.

2. The system as recited in claim 1, further comprising: second deal data describing a second deal and stored in the deal database, wherein the second deal data is logically related to the first collateral asset data.

3. The system as recited in claim 2, wherein changes in the first collateral asset data is automatically reflected in any processing by the processor of the first deal data and the second deal data.

4. The system as recited in claim 1, further comprising: a trade module, wherein a user is able to input, through the user interface, a trade with respect the first deal.

5. The system as recited in claim 4, wherein the trade involves the purchase or sale of a target collateral asset, the target collateral asset being described by target collateral asset data stored in the collateral asset database.

6. The system as recited in claim 5, wherein if the target collateral asset is being purchased, the first deal data is updated to be logically related to the target collateral asset data.

7. The system as recited in claim 5, wherein if the target collateral asset is being sold, the first deal data is updated to indicate the sale of the target collateral asset.

8. The system as recited in claim 4, wherein the trade is a hypothetical trade described by hypothetical trade data, the system further comprising: a hypothetical trade database, the hypothetical trade database storing the hypothetical trade data.

9. The system as recited in claim 8, further comprising: a hypothetical trade testing module, wherein the hypothetical trade testing module determines the effect of the hypothetical trade on the first deal.

10. The system as recited in claim 9, wherein the hypothetical trade testing module further generates a report describing the determined effect of the hypothetical trade on the first deal.

11. The system as recited in claim 8, wherein the hypothetical trade data describes a purchase or sale of a proposed collateral asset, the system further comprising: an actualization module, the actualization module actualizing the hypothetical trade by executing the purchase or sale of the proposed collateral asset.

12. The system as recited in claim 1, further comprising: a collateral asset data source interface, the collateral asset data source interface providing access to external sources of information related to collateral assets; and a collateral asset manager coupled to the a collateral asset data source interface and coupled to the collateral asset database, the collateral asset manager retrieving updated collateral asset data from the collateral asset data source interface and updating the collateral asset database using the updated collateral asset data.

13. The system as recited in claim 12, wherein the updated collateral asset data is related to the first collateral asset, and wherein the collateral asset manager updates the first collateral asset data using the updated collateral asset data.

14. The system as recited in claim 12, wherein the updated collateral asset data is related to a second collateral asset, and wherein the collateral asset manager adds the second collateral asset data to the collateral asset database using the updated collateral asset data.

15. The system as recited in claim 1 , wherein the first deal data includes compliance rules governing the first deal, the system further comprising: a compliance testing module coupled to the deal database and the collateral asset database, wherein the compliance testing module performs a compliance test using the compliance rules and the collateral asset data contained in the collateral asset database.

16. The system as recited in claim 15, wherein compliance testing module further generates a compliance test report describing results of the compliance test.

17. The system as recited in claim 16, wherein compliance test report includes a summary section and a detail section.

18. The system as recited in claim 1, further comprising: a calculating module coupled to the deal database and the collateral asset database, wherein the calculating module calculates principal and interest payments with respect to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

19. The system as recited in claim 1, further comprising: a payment module coupled to the deal database and the collateral asset database, wherein the payment module receive and makes payments with respect to collateral assets related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

20. The system as recited in claim 1, further comprising: a cashflow management module coupled to the deal database and the collateral asset database, wherein the cashflow management module processes cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

21. The system as recited in claim 20, wherein the cashflow management module generates projected cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

22. The system as recited in claim 20, wherein the cashflow management module processes actual cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

23. The system as recited in claim 20, wherein the cashflow management module generates projected cashflows and processes actual cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database and wherein the cashflow management module further compares the projected cashflows to the actual cashflows.

24. The system as recited in claim 1, further comprising: a rating service interface, the rating service interface providing an interface to rating services that provide collateral asset ratings, wherein collateral asset ratings retrieved through the rating service interface are used to update the collateral asset data stored in the collateral asset database.

25. The system as recited in claim 1, further comprising: a country database, the country database storing country data including at least country holiday data describing holidays observed by a plurality of countries, wherein the country holiday data is used by the processor when executing financial processing related to deals contained in the deal database.

26. The system as recited in claim 1, wherein the first collateral asset is a note.

27. The system as recited in claim 1, wherein the first collateral asset is a bond.

28. The system as recited in claim 1 , wherein the first collateral asset is a loan.

29. The system as recited in claim 1, wherein the first collateral asset is an equity.

30. A method for managing Collateral Debt Obligations comprising: storing, in a deal database, at least first deal data describing a first deal; storing, in a collateral asset database, at least first collateral asset data describing a first collateral asset; and logically relating the first collateral asset data to the first deal data.

31. The method as recited in claim 30, further comprising: storing, in the deal database, second deal data describing a second deal; and logically relating the first collateral asset data to the second deal data .

32. The method as recited in claim 31 , further comprising: reflecting changes in the first collateral asset data in any processing of the first deal data and the second deal data.

33. The method as recited in claim 30, further comprising inputting a trade with respect the first deal.

34. The method as recited in claim 33, wherein the trade involves the purchase or sale of a target collateral asset, the target collateral asset being described by target collateral asset data stored in the collateral asset database.

35. The method as recited in claim 34, wherein if the target collateral asset is being purchased: updating the first deal data to be logically related to the target collateral asset data.

36. The method as recited in claim 34, wherein if the target collateral asset is being sold: updating the first deal data to indicate the sale of the target collateral asset.

37. The method as recited in claim 33, wherein the trade is a hypothetical trade described by hypothetical trade data, the method further comprising: storing the hypothetical trade data in a hypothetical trade database.

38. The method as recited in claim 37, further comprising determining the effect of the hypothetical trade on the first deal.

39. The method as recited in claim 38, further comprising generating a report describing the determined effect of the hypothetical trade on the first deal.

40. The method as recited in claim 37, wherein the hypothetical trade data describes a purchase or sale of a proposed collateral asset, the method further comprising actualizing the hypothetical trade by executing the purchase or sale of the proposed collateral asset.

41. The method as recited in claim 30, further comprising: providing access to external sources of information related to collateral assets; and retrieving updated collateral asset data from the external sources of information; and updating the collateral asset database using the updated collateral asset data.

42. The method as recited in claim 41, wherein the updated collateral asset data is related to the first collateral asset, the method further comprising updating the first collateral asset data using the updated collateral asset data.

43. The method as recited in claim 41 , wherein the updated collateral asset data is related to a second collateral asset, the method further comprising adding the second collateral asset data to the collateral asset database using the updated collateral asset data.

44. The method as recited in claim 30, wherein the first deal data includes compliance rules governing the first deal, the method further comprising: performing a compliance test using the compliance rules and the collateral asset data contained in the collateral asset database.

45. The method as recited in claim 44, further comprising generating a compliance test report describing results of the compliance test.

46. The method as recited in claim 45, wherein compliance test report includes a summary section and a detail section.

47. The method as recited in claim 30, further comprising: calculating principal and interest payments with respect to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

48. The method as recited in claim 30, further comprising: receiving and making payments with respect to collateral assets related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

49. The method as recited in claim 30, further comprising: processing cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

50. The method as recited in claim 49, further comprising generating projected cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

51. The method as recited in claim 49, further comprising processing actual cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database.

52. The method as recited in claim 49, further comprising: generating projected cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database; processing actual cashflows related to deals contained in the deal database using the collateral asset data contained in the collateral asset database; and comparing the projected cashflows to the actual cashflows.

53. The method as recited in claim 30, further comprising: providing access to rating services that supply collateral asset ratings; retrieving collateral asset ratings from the rating services; and updating the collateral asset data stored in the collateral asset database with the retrieved collateral asset ratings.

54. The method as recited in claim 30, further comprising: storing, in a country database, country data including at least country holiday data describing holidays observed by a plurality of countries; and employing the country holiday data when executing financial processing related to deals contained in the deal database.