Method, system and program for credit risk management utilizing credit exposure

Abstract

Software aggregates and integrates credit exposure data across accounting, trading and operational systems within an energy trading organization. A comprehensive model of exposure to all counterparties, across all of their divisions and subsidiaries, is then assembled, enabling the creation of a hierarchical view of each counterparty that models its real-world parent-child relationships, and taking into account netting, setoff, and margin requirements, collateral requirements and contract terms, internal and external views of exposure and liquidity, and risk concentrations based on both system and user-defined risk categories. After aggregating the exposure information, credit, transactions, risk and other properties are determined at any level in the hierarchy and then the system presents a comprehensive, detailed, real-time, enterprise-wide view of current exposure, collateral requirements and outlays for both a company and its counterparties. Walkforward views of potential credit exposure taking into account current and future prices and volumes are also provided.

Description

PRIORITY CLAIM

The application claims the benefit of priority under 35 U.S.C. §119(e) from U.S. Provisional Application No. 60/503,429, entitled, “Method, System and Program for Credit Risk Management Utilizing Credit Exposure,” filed on Sep. 16, 2003, and U.S. Provisional Application No. 60/503,422, entitled, “Method, System and Program for Credit Risk Management Utilizing Credit Limits,” filed on Sep. 16, 2003, which disclosures are incorporated herein by reference.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to co-pending U.S. patent application Ser. No. 10/______, (ROME002US1), filed on even date herewith and assigned to the assignee hereof, and incorporated herein by reference in its entirety.

TECHNICAL FIELD

The present invention relates generally to methods, systems and programs for credit risk management. Still more particularly, the present invention relates to methods, systems and programs for credit risk management based on defined relationships and associated credit exposure.

BACKGROUND

Dramatic changes in industry have exposed the need for new processes and tools to measure, analyze and manage credit and liquidity. For example, energy companies have been reeling from corporate scandals, increased scrutiny and disclosure, and several well-publicized bankruptcies. As a result, companies are planning for contingent liquidity requirements and managing company-wide credit by requiring near-real-time profiles of the company's credit exposure and obligations. Some companies do business with hundreds of different counterparties and, therefore, have risk associated with hundreds of different legal entities based on a myriad of different commodities. The data about these counterparties and the transactions executed with them is spread across many different specialized commodity-trading systems.

Unfortunately, the commodity-based nature of enterprise resource planning, integration, trading and risk management software currently used in most industries revolve around accounts and transactions as opposed to customer relationships or counterparties and their associated contracts. This places the relevant data scattered across multiple, disparate systems and forces company executives to manually pull together necessary information and resort to spreadsheets and calculators to obtain the information they need to assess credit risk and make critical decisions regarding their company's credit exposure and obligations. An organization's financial stability depends on a timely, accurate and authoritative picture of credit exposure and liquidity obligations, so it may identify trouble spots, move quickly to mitigate counterparty credit risk, and improve the company's liquidity. This critical information must be made available to organizations by presenting a comprehensive, detailed, real-time picture of current exposure and collateral requirements for both the company and its counterparties. Yet, no current solution provides an effective method to track and analyze credit exposure and liquidity obligations across multiple systems. In addition to data aggregation limitations, the current offerings do not take advantage of contemporary technologies that allow for simplified adaptation of changing functional requirements and near-real-time processing. Accordingly, it would be desirable to provide a method, system and program to overcome these problems in the art.

SUMMARY OF THE INVENTION

In accordance with the present invention, improved methods, systems and articles of manufacture for managing credit exposure are disclosed. In one preferred embodiment of the present invention, a hierarchical model of legally associated counterparties and associated transactions with an organization is created, wherein the hierarchical model includes one or more counterparty levels containing the legally associated counterparties, and one or more master levels containing one or more master agreements, each master agreement being between one of the legally associated counterparties and the organization, and one or more transaction levels containing one or more transactions, wherein each master agreement provides one or more mechanisms for financial aggregation of associated transactions between one or more of the counterparties and the organization. Then, aggregate financial exposure for the organization at each level of the hierarchical model based on the one or more master agreements and their associated transactions is calculated. All objects, features, and advantages of the present invention will become apparent in the following detailed written description.

BRIEF DESCRIPTION OF DRAWINGS

This invention is described in a preferred embodiment in the following description with reference to the drawings, in which like numbers represent the same or similar elements and one or a plurality of such elements, as follows:

FIG. 1 shows a conceptual diagram of a software architecture in which a preferred embodiment of the prevent invention may be implemented.

FIG. 2 shows a block diagram of a conceptual dataflow diagram of the operation of the credit exposure application, in accordance with a preferred embodiment of the present invention.

FIG. 3 shows a hierarchical chart representing the organizational structure and legal relationships of a parent counterparty and its affiliated legal entities, as utilized in a preferred embodiment of the present invention.

FIG. 4 shows an example scenario of a credit exposure calculation, in accordance with the preferred embodiment of the present invention.

FIG. 5 shows a flow diagram of a process implemented by credit exposure module 105, in accordance with a preferred embodiment of the present invention.

FIG. 6 shows a data flow diagram of calculation stages within the calculation engine, in accordance with a preferred embodiment of the present invention.

FIG. 7 shows a flow diagram of a contractual view using the closeout setoff method of the credit exposure calculations, in accordance with a preferred embodiment of the present invention.

FIG. 8 shows a flow diagram of a view of the credit exposure calculations using a margining method, in accordance with a preferred embodiment of the present invention.

FIG. 9 shows a data table for configuring the exposure components and formulas to be used in calculating credit exposure for counterparties, in accordance with a preferred embodiment of the present invention.

FIG. 10 shows a high-level block diagram of a data processing system 10, which may be a high-level computer system, consistent with an embodiment of the invention with which the method, system and program of the present invention may advantageously be utilized.

FIG. 11 shows a screenshot of a web browser page of web-based user interfaces displaying a summary view of a counterparty's exposure or reverse exposure. The user gets to this page by selecting a counterparty.

FIG. 12 shows a screenshot of a web browser page of web-based user interfaces displaying exposure/reverse exposure by limit category.

FIG. 13 shows a screenshot of a web browser page of web-based user interfaces displaying multiple counterparty exposure/reverse exposure within the counterparty hierarchy. The page has the following important characteristics.

FIG. 14 shows a screenshot of a web browser page of web-based user interfaces displaying a summary list of the contracts that have been created for the counterparty.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

With reference now to FIG. 1, there is depicted a conceptual diagram of a software architecture in which a preferred embodiment of the prevent invention may be implemented. The software system 100 comprises application layers or objects, including presentation layer components 102, application business services 104, platform services 106 and data services 108 connected by a communication link 110. Each of the application layers 102-108 communicate with various other business applications 112 utilized within a line of business of an enterprise and a database 114 for storage of application data. Line of business applications 112 may be accounting software, trading software and other risk management applications, for example. Presentation layers 102-108 communicate over link 110. Presentation layers 102-108 also communicate with line-of-business applications 112 and universal database 114 over link 110 for storing and retrieving data accessed and generated by the software system 100.

Presentation layer components 102 contain a plurality of web-based user interfaces 103 to provide user display and interface to software system 100 and are built on Java Server Page. Application business services layer 104 includes a plurality of software applications to organize, analyze and manage an enterprise's credit risk, the modules including counterparty, credit ratings, credit limits, credit exposure and positions functionality providing various application services. Application business services 104 includes a credit exposure application 105 that provides an organization's enterprise view of their current and future financial exposure by contract, counterparty and credit limit categories. Platform services 106 contain service applications to provide general management of users and security, to issue thresholds and alerts, and to provide a workflow engine for communicating workflow between the various layers 102-108. Layers 104, 106 run on Enterprise JavaBeans (EJB). Data services 108 contains a message provider and database connection pool applications to provide data services among the other layers 102-106 and between line of business applications 112 and database 114.

With reference now to FIG. 2, there is shown a block diagram of a conceptual dataflow diagram of the operation of the credit exposure application 105, in accordance with a preferred embodiment of the present invention. The sum total of all transactions 202, sometimes called deals, entered into by the trading organization or one of its affiliated legal entities using software system 100 to determine its financial exposure on deals or contracts (hereinafter the “organization”)is made accessible to credit exposure application 105, for example from database 114 or line of business applications 112. Transactions 202 are a collection of data components on the financial exposure to the organization represented by each of the contractual transactions 202 entered into by the organization. Billed cash exposure components 204 represent the accounts receivable (AR) resulting from the billed amounts due from each of the counterparties to the organization in the transactions 202. Unbilled cash exposure components 206 represents each component of the transactions 202 that currently exist as a result of the contractual commitments of transactions 202. Forward exposure components 208 represents mark-to-market (MtM) data on future exposure represented by transactions 202.

Counterparties, contracts and credit information are collected by credit exposure module 105 to build and store counterparty information block 208. This counterparty information 208 represents a database of information regarding the counterparties and contractual relationships created by transactions 202. Counterparty hierarchy 210 provides a plurality of structural models defining interconnected corporate identities and contractual relationships for each counterparty. Contracts and netting agreements 212 provides a database of contractual agreements with each counterparty and their related rights and obligations comprising the transactions 202.

As will be appreciated, contracts and netting agreements 212 specify the critical rights and relationships between the parties and can be quite complex. This complexity is significantly pronounced in the energy industry to which the present embodiment has particular application. Most energy traders buy and sell commodities both in a physical sense, where actual delivery of a product will eventually take place, and in a financial sense, where only money will change hands based on future market value. They often trade these commodities with each other—exchanging different quantities of the same commodity several times during a given month, week or day. Because of this web of trading contracts, the financial exposure between two companies might be millions of dollars on any given day.

Trading companies use two simple techniques to reduce their credit risks: collateral and netting (also called set-off). Based on the financial strength of their trading partners, companies have required the posting of collateral prior to any trading. Generally, a security interest is granted in the collateral so that it can be applied to any unpaid obligations. Trading companies also have included the concept of netting in their trading agreements. Netting allows the parties to set-off any amounts they owe each other and only pay the “net” owed from one party to the other.

Master Netting, Setoff, Security and Collateral Agreements create a global view of the energy trading business, recognizing that most of the players are trading multiple commodities between multiple affiliates and subsidiaries. The master netting agreement links all underlying commodity-trading agreements between two companies into a single, integrated agreement. This integration is important because it prevents a bankrupt trading party from choosing and excluding commodity transactions based on whether or not the transactions are favorable to the bankrupt party. In addition, the agreement allows the parties to adopt a uniform definition of events that will constitute default under all trading agreements between the parties. The agreement also allows the parties to adopt a uniform method by which transactions under all trading agreements will be terminated and liquidated in the event of a default. These provisions bring consistency to this liquidation process, which might otherwise be chaotic as the non-defaulting party tries to apply different calculation provisions for different commodities. This consistency also is important because it prevents uncertainties in the liquidation process from delaying the final closeout of obligations between the parties. Further, the agreement encourages the parties to net monthly payments that they owe each other under all of the underlying trading agreements. Such “cross-product” and “cross-affiliate” netting reduces the cash demands on both parties and greatly reduces their overall credit exposure. Finally, the agreement establishes a single collateral-posting requirement between the parties to cover the total exposure under all of the underlying trading agreements. This provision reduces the total amount of collateral that each party is required to provide and in turn makes more of their “credit” available for trading activities with other companies.

Collateral and guarantees 214 represents contractual arrangements that provide collateral and guarantees against transactions 202 and contracts and netting agreements 212, whether provided by a counterparty or third party guarantor. Credit limits and ratings 216 represents credit rating information collected from various third party sources on each of the counterparties and includes credit limits set by the organization that triggers certain events if exceeded by a counterparty.

Also represented in FIG. 2 are the calculation formulas 218, which include an external exposure formula 220 and a reverse exposure formula 222. Exposure formula 220 represents a mathematical equation selected to model the financial exposure of the organization as a function of the deals 202 and counterparty information 208. Exposure is the amount of credit risk exposure all internal counterparties have to a specific external counterparty. Reverse exposure formula 222 represents an equation selected to model the reverse exposure the organization subjects on its counterparties. Reverse Exposure is the amount of credit risk exposure all external counterparties have to a specific internal counterparty.

Credit exposure module 105 contains a calculation engine 224 that receives as inputs the transactions 202, counterparty information 208 and calculation formulas 218. In particular, calculation engine 224 computes exposure formula 220 and reverse exposure formula 222 using, as inputs, the billed cash exposure components 204, unbilled cash exposure components 206, forward exposure components 208, counterparty hierarchy 210, contracts and netting agreements 212, collateral and guarantees 214 and credit limits and ratings 216. The outputs of calculation engine 224 are the calculation results 226. Calculation results 226 present an exposure and reverse exposure calculation 228, an available credit calculation 230, a collateral and posted calculation 232, a collateral due calculation 234 and a utilized guarantees determination 236.

With reference now to FIG. 3, there is shown a hierarchical chart 300 representing the organizational structure and legal relationships of a parent counterparty and its affiliated legal entities, as utilized in a preferred embodiment of the present invention. As seen in this example of a counterparty structure 300, there is shown a parent counterparty corporation 302 at a parent counterparties level 330. Two legal entity counterparties represented by the North American subsidiary 304 and European subsidiary 306 are at the legal entity counterparties level 332. As will be appreciated, while only a single level of counterparties 332 are shown in the example of FIG. 3, any number of levels of counterparties could be formed by the hierarchical structure, either below or above the counterparties level.

Parent counterparty corporation 302 and/or North America subsidiary 304 and European subsidiary 306 has entered into four master agreements 308-314 at master agreements level 334 with the organization or one of its legal entities. The power west master agreement 308 and power east master agreement 310 have been entered into with the North American subsidiary 304, while the gas master agreement 312 and power master agreement 314 have been entered into with the European subsidiary 306 of the parent corporation 302. As will be appreciated, while only a single level of master agreements 334 are shown in the example of FIG. 3, any number of levels of master agreements could be formed by the hierarchical structure, either below or above the master agreement level 334.

Last, the hierarchical tree structure 300 has a transaction level 336 that indicates the specific transactions 316-328, which have been entered into with each of the legal entity counterparties 304, 306 under the master agreements 308-314. Thus, the organizational structure 300 presents the diagram of the legal relationships between the transactions in which the organization has entered into with the parent counterparty corporation and/or each of its legal entity subsidiaries. As will be appreciated, transactions 316-328 can also be directly connected to parent counterparty 302 without being covered in a master agreement. Also shown in FIG. 3 is a non-trading guarantor 330 legally committed to guarantee one or more of the transactions 316-328 or master agreements 308-314 up to a predefined guaranteed limit.

With reference now to FIG. 4, there is shown an example scenario of a credit exposure calculation, in accordance with the preferred embodiment of the present invention. Within each circle representing an entity or agreement, a dollar amount of financial obligations the transaction represents is shown in millions. A positive number indicates the exposure to the organization represented by the cumulative financial exposure deriving from all of the obligations and netting/offsetting rights linked from lower levels in the hierarchy and at that node in the hierarchical tree 300. A negative number represents the reverse exposure or value of the transactions held by the organization and negatively impacts the counterparty in the event of default.

In this example, the organization and parent counterparty or legal entity counterparties have entered into a master netting and closeout setoff agreements 404, 402 to allow the parties to net collateral obligations and set off rights across transactions to achieve a single amount owed between the parties to the master agreements. When master netting agreements are utilized across affiliates, they permit affiliates to net their obligations to post collateral and thereby decrease the net amount each family of companies post to the other. Master netting agreements can provide similarly valuable rights in the context of closeout setoff. When a family of companies suffers an event of default, companies can net closeout amounts owed to the defaulting parties and their affiliates against closeout amounts owed by the non-defaulting parties and their affiliates. Moreover, master netting agreements enable entities to provide that all contracts share the same events of default, early termination and liquidation rights, and set off provisions.

In the example shown in FIG. 4, a closeout setoff 402 has been applied to the master agreements 308, 310 entered into by North American subsidiary 304. Also seen in FIG. 4 is settlement amount netting arrangement 404 between the counterparties and the organization.

Credit exposure 105 calculates the impact to the organization of a default on one or more of the transactions 316-328. For this example, it is assumed that the legal entity counterparties 304 and 306 default on a total of $12M in obligations in transactions 324 and 328. As can been seen, the net exposure to North American subsidiary 304 was a reverse exposure of −$1M due to the closeout setoff 402 of the master agreements 308 and 310 (at a minus $10M and plus $9M, respectively). The settlement amount netting arrangement 404 results in a net exposure of +$1M from the gas master agreement 312. Also shown is a $3M guarantee agreement between the European subsidiary 306 and the non-trading guarantor 330. Thus, where the European subsidiary 306 defaults on $12M of obligations transactions 324 and 328, the credit exposure application 105 shows exposure of +$4M as a net exposure to the counterparty 306. This results because of the settlement amount netting 404 producing a net exposure of $1M from the gas master agreement 312 and the full exposure of $6M from power master agreement 314 because of a lack of a settlement amount netting agreement for that master agreement. The cumulative $7M in exposure from master agreements 312, 314 is offset by the offsetting protection of $3M from the non-trading guarantor 330, leaving an exposure calculation of $4M at the European subsidiary 306. Because the closeout setoff agreement insulates the reverse exposure from the North American subsidiary, the entire exposure at parent counterparty corporation 302 is $4M.

With reference now to FIG. 5, there is shown a flow diagram of a process implemented by credit exposure module 105, in accordance with a preferred embodiment of the present invention. Process 500 begins at step 502, where calculation engine 224 calculates the financial exposure the organization has to the specified transactions 202. Exposure and reverse exposure calculations 228 are computed by applying the exposure formula 220 and reverse exposure formulas 222 to the exposure components 204, 206 and 208 and deal attributes 208 in order to calculate a deal level (transactions 316-328) result of financial exposure to the deal.

At step 504, the exposure on Master Purchase and Sale Agreements (MPSAs) is calculated across all legal entity counterparties within the hierarchy of the parent counterparty hierarchy. The calculation at step 504 applies the netting and setoff rules within the MPSA level with respect to all deals that apply to a particular MPSA. This “rolls up” the exposure calculation from all deals to the MPSA level. This can be seen in FIG. 6 for the payment netting method at MPSA level 604. The calculation at step 504 further includes applying the collateral terms of the MPSA to the exposure calculation to determine the collateral due from the counterparty.

At step 506, the exposure numbers are modified based on the master netting and setoff agreements (MNSAs) with the counterparty. At this step, the netting and setoff rules resulting from the MNSA are applied when summing up exposures from the plurality of MPSA's with the counterparty. In addition, collateral terms are applied to the exposure calculation to determine collateral due of the MNSA governs collateral. As seen in FIG. 6, this step is performed at MNSA level 606, at the calculation shown at step 622, 624 and 626. The impact of guarantees on the exposure levels calculated based on MPSA and MNSA level results is calculated at step 508. At step 510, a counterparty “rollup” is created across the entire hierarchy of the counterparty by summing all calculated exposures at all levels of the counterparty hierarchy. This is seen in FIG. 6 at counterparty level 608, where steps 628, 630 and 632 are performed.

With reference now to FIG. 6, a data flow diagram of calculation stages within the calculation engine is shown, in accordance with a preferred embodiment of the present invention. The particular embodiment shown in FIG. 6 is a flow diagram of the exposure calculation using a payment netting method, in accordance with the preferred embodiment of the present invention. Data flow diagram 600 is split into multiple stages of calculation for calculation engine 224. Process 600 is staged (as indicated by dashed lines) into deal level 602, Master Purchase and Sale Agreement (MPSA) level 604, Master Netting and Setoff Agreements (MNSA) level 606 and counterparty level 608.

At deal level 602, the exposure for all transactions for given counterparty are calculated at step 610 for the deal level 602 in accordance with the exposure formula 220. As seen at MPSA level 604, the resulting data is fed to calculation blocks 612, 614 and 616. Calculation block 612 contains a calculation for determining a “low” estimate of the credit exposure based on the calculation 610 by summing all cash components of the deals (C_deal) and all forward exposure (MtM) components from each of the deals (M_deal). The calculations in calculation block 614 take into account only the positive cash components of the deals (C_deal) and positive forward exposure (MtM) components from each of the deals (M_deal), thereby giving a “high” estimate of the credit exposure to the counterparty.

At decision block 616, a determination is made whether payment netting is allowed for the given MPSA. Of not, calculation block 618 performs the same calculation as the “high” estimate of calculation block 614, but if so, the process proceeds to step 620, which summarizes all cash components of the deals (C_deal) and only the positive forward exposure (MtM) components from each of the deals (M_deal).

At the MNSA level 606, all positive cash components of the deals (C_deal) and positive forward exposure (MtM) components are summed for all MPSAs in the applicable MNSA at step 622. At step 624, all positive cash components of the deals (C_deal) and positive forward exposure (MtM) components are summed for all MPSAs in the applicable MNSA resulting from the high estimate exposure calculation 614. Similarly, at step 626, all MPSA cash and MtM exposure calculations resulting from the low estimate exposure calculation 612 for all MPSAs under the applicable MNSA are summed.

At the counterparty level 608, a calculation at step 628 is performed to generate a rollup of the entire counterparty credit exposure across the entire hierarchy of counterparty entities. The calculation at step 628 comprises a sum of all the positive cash and MtM exposure calculations at the MNSA level 606 and MPSA 604 in combination with the utilized guarantees of the counterparty. The calculation at step 630 determines a “high” estimate of the rollup credit exposure for the counterparty across all hierarchies. Similarly, at step 632, a “low” estimate of the credit exposure for the counterparty, rolled up across the entire hierarchy of legal entities of the counterparties, is calculated.

With reference now to FIG. 7, there is shown a flow diagram of a contractual view using the closeout setoff method of the credit exposure calculations, in accordance with a preferred embodiment of the present invention. Flow diagram 700 is a contractual view of the credit exposure calculations performed at deal level 602, MPSA level 604, MNSA level 606 and counterparty level 608. Process 700 begins at step 610, where the deal level credit exposure is calculated for all transactions with the counterparty. Thereafter, data flows from step 610 to steps 702, 704 and 706 to perform a “low” estimate of the credit exposure with the counterparty and its hierarchy of legal entities through the MPSA level 604, MNSA level 606 and counterparty level 608. Similarly, the data flow from step 610 through steps 710, 712 and 714 perform a “high” estimate of the credit exposure with the counterparty. Last, the data flow from step 610 runs to decision block 716, where it is determined if a settlement setoff is allowed under the MPSA (or potentially a MNSA). If so, the process proceeds to step 718, where a settlement setoff calculation is performed at the MPSA level 604 for each of the cash and MtM exposure calculations for each deal.

If settlement setoff is not permitted, the process proceeds to step 720, where it is determined if payment netting is allowed in the applicable MPSA. If not, a calculation of positive credit exposures are summed at step 724, and if so, all cash components are netted but only positive MtM components are summed at step 722. Thereafter, the process proceeds to at the MNSA level 606, where all components at the MNSA level are summed at step 726. Thereafter, a final credit exposure calculation is performed at step 728 to perform a counterparty rollup across the entire hierarchy of the counterparty.

With reference now to FIG. 8, there is shown a flow diagram of a view of the credit exposure calculations using a margining method, in accordance with a preferred embodiment of the present invention. Flow diagram 800 begins at deal level 602 where all deal level exposure is calculated at step 610. At MPSA level 604, credit exposure at the MPSA level is calculated in the same manner as shown in FIG. 7. At MNSA level 606, the high and low estimates of credit exposure are calculated in the same manner as shown in FIG. 7, but the credit exposure calculation flow proceeds to step 802, where all credit exposure components resulting from steps 718-724 are summed for all MPSAs in each MNSA with all collateral setoffs included in the summation. At counterparty level 608, the complete credit exposure calculation for the counterparty across the entire legal entity hierarchy is calculated as shown at step 804. At steps 806 and 808, the “high” and “low” estimates of credit exposure for this counterparty are calculated, respectively.

With reference now to FIG. 9, there is shown a data table for configuring the exposure components and formulas to be used in calculating credit exposure for counterparties, in accordance with a preferred embodiment of the present invention. Table 900 shows a row 902 for “company A” and a row 904 for “company B”. Each row 902, 904 have columns for exposure components 906, exposure formula 908 and reverse exposure formula 910. As shown by the examples in FIG. 9, the exposure components 906 describe the cash and forward components for the counterparties listed. Exposure formula column 908 lists the particular exposure formula used to calculate each of the cash exposure and forward exposure calculations implemented in each of the credit exposure calculation processes 600, 700 and 800. Reverse exposure formula 910 describes the methodology for calculating the reverse credit exposure with each identified counterparty.

FIG. 10 shows a high-level block diagram of a data processing system 10, which may be a high-level computer system, consistent with an embodiment of the invention with which the method, system and program of the present invention may advantageously be utilized. The present invention may be executed in a variety of systems, including a variety of computing systems and electronic devices under a number of different operating systems. In one embodiment of the present invention, the system is a portable computing system such as a notebook computer, a desktop computer, a network computer, a midrange computer, a server system or a mainframe computer. Therefore, in general, the present invention is preferably executed in a computer system that performs computing tasks such as manipulating data in storage that is accessible to the computer system. In addition, the computer system preferably includes at least one output device and at least one input device.

A computer system, for example computer system 10, can be considered as three major components: (1) the application programs, such as a spreadsheet or word processing or graphics presentation application, which are used by the user; (2) the operating system that transparently manages the application's interactions with other applications and the computer hardware; and (3) the computer hardware comprising the processor, the random access memories, the actual electronic components which manage the digital bits. The operating system has a kernel which, inter alia, controls the execution of applications, processes, and/or objects by allowing their creation, termination or suspension, and communication; schedules processes/objects of the same or different applications on the hardware, allocates memory for those objects, administers free space, controls access and retrieves programs and data for the user.

As seen in FIG. 10, data processing system or computer system 10 comprises a bus 22 or other communication device for communicating information within computer system 10, and at least one processing device such as processor 12, coupled to bus 22 for processing information. While a single CPU is shown in FIG. 10, it should be understood that computer systems having multiple CPUs could be used. Processor 12 may be a general-purpose processor that, during normal operation, processes data under the control of operating system and application software stored in a dynamic storage device such as random access memory (RAM) 14 and a static storage device such as Read Only Memory (ROM) 16 and mass storage device 18, all for storing data and programs. The system memory components are shown conceptually as single monolithic entities, but it is well known that system memory is often arranged in a hierarchy of caches and other memory devices. The operating system preferably provides a graphical user interface (GUI) to the user. In a preferred embodiment, application software contains machine executable instructions that when executed on processor 12 carry out the operations and processes of the preferred embodiment described herein. Alternatively, the steps of the present invention might be performed by specific hardware components that contain hardwire logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

Communication bus 22 supports transfer of data, commands and other information between different devices within computer system 10; while shown in simplified form as a single bus, it may be structured as multiple buses, and may be arranged in a hierarchical form. Further, multiple peripheral components may be attached to computer system 10 via communication bus 22. A display 24 such as a cathode-ray tube display, a flat panel display, or a touch panel is also attached to bus 22 for providing visual, tactile or other graphical representation formats. A keyboard 26 and cursor control device 30, such as a mouse, trackball, or cursor direction keys, are coupled to bus 22 as interfaces for user inputs to computer system 10. In alternate embodiments of the present invention, additional input and output peripheral components may be added. Communication bus 22 may connect a wide variety of other devices (not shown) to computer system 10 and to other adapters connected to other devices such as, but not limited to, audio and visual equipment, tape drives, optical drives, printers, disk controllers, other bus adapters, PCI adapters, workstations using one or more protocols including, but not limited to, Token Ring, Gigabyte Ethernet, Ethernet, Fibre Channel, SSA, Fiber Channel Arbitrated Loop (FCAL), Ultra3 SCSI, Infiniband, FDDI, ATM, ESCON, wireless relays, USB, Twinax, LAN connections, WAN connections, high performance graphics, etc., as is known in the art.

Communication interface 32 provides a physical interface to a network, such as the Internet 38, or to another network server via a local area network using an Ethernet, Token Ring, or other protocol, the second network server in turn being connected to the Internet or Local Area Network. Internet 38 may refer to the worldwide collection of networks and gateways that use a particular protocol, such as Transmission Control Protocol (TCP) and Internet Protocol (IP), to communicate with one another. The representation of FIG. 2 is intended as an exemplary simplified representation of a high-end computer system, it being understood that in other data processing systems 10, variations in system configuration are possible in addition to those mentioned here.

The present invention may be provided as a computer program product, included on a machine-readable medium having stored thereon the machine executable instructions used to program computer system 10 and/or to a peripheral device for installation on a connected adapter to perform a process according to the present invention. The term “machine-readable medium” as used herein includes any medium, signal-bearing media or computer readable storage media that participates in providing instructions to processor 12 or other components of computer system 10 for execution. Such a medium may take many forms including, but not limited to, non-volatile media, volatile media, and transmission media. Common forms of non-volatile media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape or any other magnetic medium, a compact disc ROM (CD-ROM) or any other optical medium, punch cards or any other physical medium with patters of holes, a programmable ROM (PROM), an erasable PROM (EPROM), electrically EPROM (EEPROM), a flash memory, any other memory chip or cartridge, or any other medium from which computer system 10 can read and which is suitable for storing instructions. In the present embodiment, an example of nonvolatile media is storage device 18. Volatile media includes dynamic memory such as RAM 14. Transmission media includes coaxial cables, copper wire or fiber optics, including the wires that comprise bus 22. Transmission media can also take the form of electromagnetic, acoustic or light waves, such as those generated during radio wave or infrared wireless data communications. Thus, the programs defining the functions of the preferred embodiment can be delivered to the data processing system 10 information on any machine-readable medium, which include, but are not limited to: (a) information permanently stored on non-write storage media, e.g., read only memory devices within either computer such as CD-ROM disks readable by CD-ROM; (b) alterable information stored on write-able storage media, e.g., floppy disks within a diskette drive or a hard-disk drive; or (c) information conveyed to a computer by a telephone or a cable media network, including wireless communications. Such signal-bearing media, when carrying instructions that may be read by an adapter or a computer to direct the functions of the present invention, represent alternative embodiments.

A more detailed description of various components of software system 100 will now be given. In particular, the operation of the web-based user interfaces 103 in conjunction with credit exposure module 105 will be given.

CreditExposure Core

Credit Exposure module 105 generates an enterprise view of an organization's current and future credit exposure by deal, contract, counterparty and credit limit categories. The credit exposure figures will contain the sum intelligence of the cash values and the forward values for every deal a trading organization has entered into. The total exposure will be calculated using all the known payment netting and settlement amount setoff rules as specified in the Master Purchase and Sales Agreements (MPSAs) and the Master Netting and Setoff Agreements (MNSAS) between the organization and its counterparties. Guarantees, collateral and credit limits are also factored into the calculations.

A filter on the “view” specified by web-based user interfaces 103 allows a user to change the limit allocation used to determine available credit and the calculation method used to calculate exposure and reverse exposure. The filter is used on all pages except deal level exposure and reverse exposure. Additionally, in the limit category page of web-based user interfaces 103, the filter does not include the calculation method parameter. The “limit allocation” drop down should get its values from the limit allocations that are defined on the limit template.

There are three options for calculation method: Accounting View, Contractual View, and Margining View. Each of these corresponds to a calculation method used by the exposure calculation engine 224. The “calculation method” drop down gets its values from the codes table. Each page that implements the filter should default to the first limit allocation that is defined and to the “Contractual” calculation method. The user is able to apply the filter on any combination of limit allocation and calculation method.

Selecting the filter options has the following implications, (1) selecting an alternative limit allocation will change the “credit limit” and “available credit” values that are displayed; and (2) selecting an alternative calculation method will change the exposure values that are displayed and, on the multiple counterparty editor, will change how contracts rollup to counterparties. In many cases, there is a simple mapping of exposure information that has been calculated by the calculation engine 224 and the corresponding views of that information in web-based user interfaces 103. The rules for field sources for exposure information (including information regarding collateral and guarantees) are as follows:

	Accounting View	Contractual View	Margining View
Deals	Only one calculation method is used for deal level information,
	since no netting or margining rules apply at that level.
MPSAs	Payment Netting Method	Closeout Setoff Method	Closeout Setoff Method
MNSAs	Payment Netting Method	Closeout Setoff Method	Margining Method
Virtual Netting	Payment Netting Method	Closeout Setoff Method	Closeout Setoff Method
Groups
Guarantees for	Payment Netting Method	Closeout Setoff Method	Closeout Setoff Method
MPSAs
Guarantees for	Payment Netting Method	Closeout Setoff Method	Margining Method
MNSAs
Counterparties	Payment Netting Method	Closeout Setoff Method	Margining Method
Limit Category	Only one calculation method is used for credit limit category level information.

Counterparty Summary—Exposure & Reverse Exposure
Page Functionality

FIG. 11 shows a screenshot of a web browser page of web-based user interfaces 103 displaying a summary view of a counterparty's exposure. The user gets to this page by selecting a counterparty. The exposure/reverse exposure overview chart display the values of the bars when a user hovers over them. The user should be able to click on the source name for scores and ratings and get to the detail page for the appropriate score or rating. If no scores or ratings have been created for the counterparty, the table should display the “no values” message. The following table shows the fields in the view that are calculated by the calculation engine 224 and the fields calculated by the view. Since only counterparty-level totals are shown on this view, then the following rules are applied to obtain the appropriate field sources. Note that this rule applies to both exposure numbers and collateral numbers. All calculation engine fields on this view should vary when the calculation method is changed (this includes guarantees and collateral).

Limit Category—Exposure & Reverse Exposure

Page Functionality

FIG. 12 shows a screenshot of a web browser page of web-based user interfaces 103 displaying exposure/reverse exposure by limit category. Only “high” and “low” exposure is displayed in this view. The user gets to this page by selecting the “By Limit Category” sub-navigation element. If a counterparty is already active, then that counterparty's information is shown. If no counterparty is active when the user gets to the page, a message should be presented that says “Select a counterparty from the list at left.” The user should be able to click on a limit category and be taken to the deals for that category. The link can display at all times regardless of if deals are associated to the limit category; however, the deals page should display a message that no deals exist for this limit category.

Multiple Counterparty Rollup—Exposure & Reverse Exposure

Page Functionality

FIG. 13 shows a screenshot of a web browser page of web-based user interfaces 103 displaying multiple counterparty exposure rollup within the counterparty hierarchy. The page displays exposure/reverse exposure for the active counterparty and one level of child counterparties after the active counterparty. The page consolidates counterparty, guarantee, and contract (both MPSA and MNSA) exposure/reverse exposure information. Guarantees are listed beneath the associated (guarantor) counterparty, MNSAs beneath the primary counterparty (internal for reverse exposure and external for exposure), and MPSAs beneath their associated MNSA. The following table shows the fields in the view that are calculated by the calculation engine and the fields calculated by the view:

	Calc
Column Name	Engine	View
Multiple Counterparty Rollup Table
Name		X
*C1-C5 (configurable cash components)	X
The wireframes show examples for “previous month
cash”, “current month cash”, and “prompt month cash”
*M1-M5 (configurable MtM components)	X
The wireframes do not show an example of this.
External/Internal Cash Subcomponent (result of	X
formula applied to the 5 cash components, C1-C5)
The wireframes show an example for “60-day cash
exposure/reverse cash exposure”.
*External/Internal MtM Subcomponent (result of	X
formula applied to the 5 MtM components, M1-M5)
The wireframes show an example for “forward exposure/
reverse exposure”.
Low Exposure/Reverse Exposure	X
Total Exposure/Reverse Exposure	X
High Exposure/Reverse Exposure	X
Collateral Held/Posted	X
Unsecured Exposure/Reverse Exposure	X
Credit/Trading Limit		X
Available Credit/Trading Limit		X
Collateral Threshold	X
Collateral Due	X

The page is subject to the following rules: (1) the active counterparty is shown on the first row of the grid; (2) immediately below each counterparty should appear a row for each guarantee for which that counterparty is the guarantor, with the utilized guarantee amount shown as a positive (addition to exposure). These appear indented one level, since this counterparty is the “parent” of the guarantee; and (3) after all guarantees for which this counterparty is the guarantor is shown, the next set of items shown should be MNSAs for which this counterparty is the primary counterparty. MNSAs are shown at the same level of indentation as guarantees.

As a result, this page selects the correct set of numbers from the results of the calculation engine 224, based on the following rules:

	Accounting View	Contractual View	Margining View
MPSAs	Payment Netting Method	Closeout Setoff Method	Closeout Setoff Method
MNSAs	Payment Netting Method	Closeout Setoff Method	Margining Method
Virtual Netting Groups	Payment Netting Method	Closeout Setoff Method	Closeout Setoff Method
Guarantees for MPSAs	Payment Netting Method	Closeout Setoff Method	Closeout Setoff Method
Guarantees for MNSAs	Payment Netting Method	Closeout Setoff Method	Margining Method
Counterparties	Payment Netting Method	Closeout Setoff Method	Margining Method

If an MPSA is part of an MNSA, then it appears below its MNSA (indented, since the MNSA is the parent) as well as appearing below the primary counterparty. When such an MPSA appears in its normal position below a counterparty, all number values should be replaced with “N/A”. Note that all affected MPSAs are listed in this case, even if the active counterparty is not the primary counterparty on all of those MPSAs. Note that the requirement for being “part of an MNSA” changes based on the calculation method specified for the view as shown below.

In the views Accounting and Contractual, all MPSAs that have been added as “affected contracts” for the MNSA are shown under the MNSA. A smaller subset of MPSAs are shown under the MNSA in the Margining view. Of the set of MPSAs listed as “affected contracts” for the MNSA, only those for which “setoff for margining” is set to true appears under the MNSA. If a virtual netting group was created because of closeout setoff across contracts (defined at the MPSA level), then the virtual netting group appears like an MNSA would appear. The same rules should apply, but the name of the virtual netting group should simply be “Setoff Group”. All MPSAs for which the counterparty is the primary counterparty should appear at the same level as MNSAs for this counterparty. As noted above, any MPSA that is part of a MNSA will appear twice (once in its normal position and once under the MNSA). Guarantees will appear several times in the rollup. They should appear once after the guarantor, in which their utilized guarantee amount appears as a positive contribution to exposure. They also appear below each set of affected MPSAs for a given counterparty with the utilized amount shown as a negative. If a guarantee in which this counterparty is the guaranteed counterparty appears, it is indented from the affected MPSA, since the MPSA is its “parent.” Counterparties are shown under their parent counterparties. The same rules described above apply to each level of counterparty that is shown on the page. Fields that have null values are shown as “N/A” in the view pages.

Contracts Summary

Page Functionality

FIG. 14 shows a screenshot of a web browser page of web-based user interfaces 103 displaying a summary list of the contracts (both MPSAs and MNSAs) that have been created for the counterparty. The user gets to this page by selecting the “Contracts” sub-navigational element within the Exposure tab. A counterparty does not need to be a primary counterparty for the contract to appear in this view. For the MPSA section of the page, the user can click on the “contract id” and be taken to the view page for the contract. For the MSNA section of the page, the user can select the “MNSA id” and be taken to the view page for that MNSA. If the user clicks on one of the “Affected MPSAs”, he or she will be taken to the view page for that MPSA contract. The following columns are shown in the view:

• • Contract id or MNSA id
  • Status
  • Commodity
  • Trade Area
  • Internal Counterparties
  • External Counterparties
  • Deal Category
  • Effective Date
  • End Date
    Exposure Formula Configuration

Credit exposure module 105 supports the ability to configure an exposure and reverse exposure formula and support the ability for the configured formula to be included into the code base. An exposure formula consists of both a cash formula and forward formula. The following are all the possible formula attributes for the cash portion of the formula: C1-C5, Deal Category, Commodity, Today's Date, Scheduled Payment Date, Transaction Date, Buy, Trade Area, Duration, and Deal Type. The following are all the possible formula attributes for the forward portion of the formula: F1-F5, Deal Category, Commodity, Today's Date, Scheduled Payment Date, Transaction Date, Buy, Trade Area, Duration, and Deal Type.

Calculation Engine

The following section outlines the algorithms and business rules used to calculate credit exposure. The deal is the most atomic data element in the credit exposure calculations—all exposure values are derived from the deal and its cash and forward subcomponents (C1-5 and M1-5, respectively).

	C1	C2	C3	C4	C5	M1	M2	M3	M4	M5
Deal1	c1deal1	c2deal1	c3deal1	c4deal1	c5deal1	m1deal1	m2deal1	m3deal1	m4deal1	m5deal1
Deal2	c1deal2	c2deal2	c3deal2	c4deal2	c5deal2	m1deal2	m2deal2	m3deal2	m4deal2	m5deal2
.	.	.	.	.	.	.	.	.	.	.
.	.	.	.	.	.	.	.	.	.	.
.	.	.	.	.	.	.	.	.	.	.
Dealn	c1dealn	c2dealn	c3dealn	c4dealn	c5dealn	m1dealn	m2dealn	m3dealn	m4dealn	m5dealn

Credit exposure module 105 allows for customer configurable formulas for both total deal cash exposure and total deal forward exposure. Although other parameters or terms (T) may be used in each formula to define conditions, the resulting computed values are derived entirely from the deal subcomponents C1-5 and M1-5.
Total Cash Exposure=TCE(T, C1-5)
Total Forward Exposure=TFE(T, M1-5)

The total cash exposure and total forward exposure is then calculated for each deal based upon the stated formulas. The total exposure for each deal is defined as the sum of the total cash exposure and total forward exposure (TCE+TFE). The cash exposure, forward exposure and total exposure are now known for each deal, and subsequent groupings and calculations may now be performed.

			Total
	Total Cash Exposure	Total Forward Exposure	Exposure
	(A)	(B)	(C)
Deal1	TCE(T, c1deal1 − c5deal1)	TFE(T, m1deal1 − m5deal1)	(A)deal1 +
			(B)deal1
Deal2	TCE(T, c1deal2 − c5deal2)	TFE(T, m1deal2 − m5deal2)	(A)deal2 +
			(B)deal2
.	.	.	.
.	.	.	.
.	.	.	.
Dealn	TCE(T, c1dealn − c5dealn)	TFE(T, m1dealn − m5dealn)	(A)dealn +
			(B)dealn

MPSA

Deal-level exposure can be rolled up to the MPSA level. Every deal is associated with exactly one MPSA. There are four different ways to aggregate exposure at the MPSA level:

• • 1. Payment Netting (or “Accounting View”)
  • 2. Closeout Setoff (or “Contract View”)
  • 3. No Netting or Setoff (or “High”)
  • 4. All Possible Netting and Setoff (or “Low”)
    Payment Netting (“Accounting View”) Exposure

To aggregate deal exposure values (C1-5, M1-5, total cash exposure and total forward exposure) at the MPSA level using the payment netting calculation method use the following rules:

Allow invoice/		Forward
payment netting?	Cash Exposure	Exposure	Total Exposure
No	Σ positive numbers	Σ positive	Σ positive
		numbers	numbers
Yes	Σ all numbers	Σ positive	Σ positive
		numbers	numbers

Total exposure is calculated as the sum of the positive deal total exposures with no regard to the payment netting status. This must be done because negative cash exposures should not reduce positive forward exposures.
MPSA Total Exposure=Σ Positive Deal Total Exposure

To determine whether an MPSA allows invoice/payment netting, use the value specified by:

MPSA Associated	MNSA	Use payment netting
with MNSA?	payment netting allowed?	allowed from . . .
No	N/A	MPSA
Yes	No	MNSA
Yes	Yes	MNSA
Yes	Null	MPSA

Closeout Setoff (“Contract View”) Exposure

To aggregate deal exposure values (C1-5, M1-5, total cash exposure and total forward exposure) at the MPSA level using the closeout setoff calculation method use the following rules:

Allow invoice/	Allow setoff of
payment netting?	settlement amounts?	Cash Exposure	Forward Exposure	Total Exposure
No	No	Σ positive numbers	Σ positive numbers	Σ positive numbers
Yes	No	Σ all numbers	Σ positive numbers	Σ positive numbers
X	Yes	Σ all numbers	Σ all numbers	Σ all numbers

To determine whether an MPSA allows invoice/payment netting, see table in previous section. To determine whether an MPSA allows setoff of settlement amounts, use the value specified by:

	MNSA or Virtual Netting
MPSA Associated	Group closeout	Use closeout setoff
with MNSA?	setoff allowed?	allowed from . . .
No	N/A	MPSA
Yes	No	MNSA
Yes	Yes	MNSA
Yes	Null	MPSA

No Netting or Setoff Setoff (“High”) Exposure

To aggregate deal exposure values at the MPSA level using no netting or setoff, sum only positive numbers for total cash and total forward exposure. Note that “high” exposure is currently only calculated for total exposure. The “high” exposure for a given MPSA is defined as the sum of all its deals' positive total exposures. “High” exposure is currently not calculated for any of the cash or forward subcomponents.
MPSA Total High Exposure=Σ Positive Deal Total Exposures
All Possible Netting and Setoff (“Low”) Exposure

To aggregate deal exposure values at the MPSA level using all possible netting and setoff, sum all numbers for total cash and total forward exposure. The “low” exposure for a given MPSA is defined as the sum of all its deals' total exposures. “Low” exposure is currently not calculated for any of the cash or forward subcomponents.
MPSA Total Low Exposure=Σ All Deal Total Exposures
Collateral Held

Collateral can be applied to either one MNSA or one or more MPSAs. An MPSA may have zero or more collateral amounts applied to it. To determine the total collateral held for a given MPSA, sum all valuation-adjusted collateral amounts that are applied to that MPSA and are “taken”.
MPSA Collateral Held=Σ (Collateral Amount*Valuation %) for all “taken” Collateral applied to that MPSA and currently in effect. Being in effect means that today's date is >=the effective date of the collateral and<=the end date of the collateral.

Utilized collateral held is also determined at the MPSA level and is defined as MPSA collateral held up to but not exceeding the total exposure. If the amount of MPSA collateral held is greater than the total exposure, the utilized collateral held is equal to the total exposure. Note that utilized collateral held is calculated for payment netting and closeout setoff using the respective total exposures. Utilized collateral is set to 0 if MNSA level collateral is in effect.

MNSA

MPSA-level exposure can be rolled up to the MNSA level. Every MPSA is associated with zero or one MNSAs. An MPSA may only participate in one netting agreement (either MNSA or a virtual netting group). There are five different ways to aggregate exposure at the MNSA level:

• • 1. Payment Netting (or “Accounting View”)
  • 2. Closeout Setoff (or “Contract View”)
  • 3. Margining
  • 4. No Netting or Setoff (or “High”)
  • 5. All Possible Netting and Setoff (or “Low”)
    Payment Netting Exposure

To aggregate MPSA exposure values (C1-5, M1-5, total cash exposure, total forward exposure and total exposure) at the MNSA level using the payment netting calculation method, sum positive MPSA payment netting numbers for MPSAs associated with the MNSA if the allow payment netting flag (on the MNSA) is true for the given MPSA. If the flag is false only add the exposure for that MPSA if the exposure is positive.

Allow invoice/			Total
payment netting?	Cash Exposure	Forward Exposure	Exposure
No	Σ positive numbers	Σ positive numbers	Σ positive
			numbers
Yes	Σ all numbers	Σ positive numbers	Σ positive
			numbers

Total MNSA exposure is calculated as the sum of the positive total MNSA exposures.

Closeout Setoff Exposure

To aggregate MPSA exposure values (C1-5, M1-5, total cash exposure, total forward exposure and total exposure) at the MNSA level using the closeout setoff calculation method sum all MPSA closeout setoff numbers for all MPSAs associated with the MNSA.
MNSA Closeout Setoff Numbers=Σ All MPSA Closeout Setoff Numbers
Setoff is implied between all MPSAs associated with an MNSA.
Margining Exposure

To aggregate MPSA exposure values (C1-5, M1-5, total cash exposure, total forward exposure and total exposure) at the MNSA level using the margining calculation method sum all MPSA closeout setoff numbers for all MPSAs that meet the following conditions:

• • The MNSA “Margining Required” is yes.
  • The MNSA “Margining Governed by this Contract” for the specific MPSA is yes.
  • The MNSA “Setoff for Collateral Requirements” for the specific MPSA is yes.
    MNSA Margining Numbers=Σ Closeout Setoff Numbers for MPSAs that meet the stated conditions

If the MNSA “Margining Required” is no or no MPSAs exist for the MNSA where “Margining Governed by this Contract” is yes and “Setoff for Collateral Requirements” is yes, then the MNSA has no margining exposure.

No Netting or Setoff (“High”) Exposure

To aggregate MPSA total high exposure at the MNSA level using no netting or setoff, sum all MPSA total high exposure numbers.
MNSA Total High Exposure=Σ All MPSA Total High Exposures

Note that normally only positive numbers would be summed to enforce no netting or setoff. However, only positive numbers were summed at the MPSA level so it is not necessary to test for positive numbers at the MNSA level.

All Possible Netting and Setoff (“Low”) Exposure

To aggregate MPSA total high exposure at the MNSA level using all possible netting and setoff, sum all MPSA total low exposure numbers.
MNSA Total Low Exposure=Σ All MPSA Total Low Exposures
Payment Netting

For payment netting, sum the “taken” collateral held at the MNSA level with the utilized “taken” collateral held applied to MPSAs associated with the MNSA if the MPSA has positive total exposure calculated with the payment netting method:
Payment Netting MNSA Collateral Held=Σ (Collateral Amount*Valuation %) for all “taken” Collateral applied to that MNSA+Σ (Collateral Amount*Valuation %) for “taken” Utilized Collateral applied to MPSAs with Positive Payment Netting Total Exposure
Closeout Setoff

For closeout setoff, sum the “taken” collateral held at the MNSA level with the utilized “taken” collateral held applied to all MPSAs associated with the MNSA:
Closeout Setoff MNSA Collateral Held=Σ (Collateral Amount*Valuation %) for all “taken” Collateral applied to that MNSA+Σ (Collateral Amount*Valuation %) for “taken” Utilized Collateral applied to all MPSAs
Margining

For margining, sum the “taken” collateral held at the MNSA level with the utilized “taken” collateral held applied to MPSAs associated with the MNSA if the following conditions are met:

• • 1. The MNSA “Margining Required” is yes.
  • 2. The MNSA “Margining Governed by this Contract” for the specific MPSA is yes.
  • 3. The MNSA “Setoff for Collateral Requirements” for the specific MPSA is yes.
    Margining MNSA Collateral Held=Σ (Collateral Amount*Valuation %) for all “taken” Collateral applied to that MNSA+Σ (Collateral Amount*Valuation %) for “taken” Utilized Collateral applied to MPSAs that meet the stated conditions
    Guarantee Associated with MNSA

A guarantee can be associated with only one MNSA. The available guarantee amount is applied to the MNSA's total exposure until the total amount of the guarantee has been applied. For a guarantee that is associated with an MNSA, there are five ways to calculate utilized amount:

• • 1. Payment Netting (or “Accounting View”)
  • 2. Closeout Setoff (or “Contract View”)
  • 3. Margining
  • 4. No Netting or Setoff (or “High”)
  • 5. All Possible Netting and Setoff (or “Low”)
    Counterparty

Exposure can be rolled up to the counterparty level for external counterparties. Counterparty-level exposure is comprised of exposure from the following elements in which the counterparty is specified as the external (and primary, where applicable) counterparty:

• • 1. MNSAs
  • 2. Virtual Netting Groups
  • 3. MPSAs that are not in MNSAs or Virtual Netting Groups
  • 4. Guarantees (both given and received). Guarantees are only applied to total exposure and unsecured exposure. They are not applied to collateral numbers or cash and forward component numbers.

There are five different ways to aggregate exposure at the counterparty level:

• • 1. Payment Netting (or “Accounting View”)
  • 2. Closeout Setoff (or “Contract View”)
  • 3. Margining
  • 4. No Netting or Setoff (or “High”)
  • 5. All Possible Netting and Setoff (or “Low”)
    Payment Netting

To aggregate exposure values (C1-5, M1-5, total cash exposure, total forward exposure and total exposure) at the counterparty level using the payment netting calculation method sum positive MPSA payment netting numbers for all MPSAs where the counterparty is the primary and the MPSA is not in an MNSA, all MNSA payment netting numbers where the counterparty is the primary, and all guarantees associated with the counterparty.

Counterparty Payment Netting Numbers=Σ All MNSA Payment Netting Numbers +All Virtual Netting Group Payment Netting Numbers+All Positive MPSA Payment Netting Numbers (not in MNSA or VNG)+All Payment Netting Utilized Guarantees in which this CP is the Guarantor−All Payment Netting Utilized Guarantees in which this CP is the primary CP for the MPSA or MNSA

There is no payment netting between MPSAs and the payment netting within each MPSA was already taken into account when the MPSA payment netting numbers were calculated.

Closeout Setoff

To aggregate exposure values (C1-5, M1-5, total cash exposure, total forward exposure and total exposure) at the counterparty level using the closeout setoff calculation method sum all closeout setoff numbers for all MNSAs, Virtual Netting Groups, MPSAs (not in MNSAs or Virtual Netting Groups) and Guarantees associated with the counterparty.

Counterparty Closeout Setoff Numbers=Σ All MNSA Closeout Setoff Numbers+All Virtual Netting Group Closeout Setoff Numbers+All MPSA (not in MNSAs or Virtual Netting Groups) Closeout Setoff Numbers+All Closeout Setoff Utilized Guarantees in which this CP is the Guarantor−All Closeout Setoff Utilized Guarantees in which this CP is the primary CP for the MPSA or MNSA

Margining

To aggregate exposure values (C1-5, M1-5, total cash exposure, total forward exposure and total exposure) at the counterparty level using the margining calculation method sum all margining numbers for all MNSAs, Virtual Netting Groups, MPSAs (not in MNSAs or Virtual Netting Groups) and Guarantees associated with the counterparty.

Counterparty Margining Numbers=Σ All MNSA Margining Numbers+All Virtual Netting Group Margining Numbers+All MPSA (not in MNSA or VNG or whose MNSA “setoff for collateral requirements” is “No”)Closeout Setoff Numbers+All Margining Utilized Guarantees in which this CP is the Guarantor−All Margining Utilized Guarantees in which this CP is the primary CP for the MPSA or MNSA

To aggregate total high exposure at the counterparty level using no netting or setoff, sum all total high exposure numbers.
Counterparty Total High Exposure=Σ All MNSA Total High Exposures+All Virtual Netting Group Total High Exposures+All MPSA (not in MNSAs or Virtual Netting Groups) Total High Exposures+All High Utilized Guarantees in which this CP is the Guarantor−All High Utilized Guarantees in which this CP is the primary CP for the MPSA or MNSA

Note that normally only positive numbers would be summed to enforce no netting or setoff. However, positive numbers were summed at the MPSA level so it is not necessary to test for positive numbers at the MNSA level.

All Possible Netting and Setoff (“Low”)

To aggregate total low exposure at the counterparty level using all possible netting and setoff, sum all total low exposure numbers.
Counterparty Total Low Exposure=Σ All MNSA Total Low Exposures+All Virtual Netting Group Total Low Exposures+All MPSA (not in MNSAs or Virtual Netting Groups) Total Low Exposures+All Low Utilized Guarantees in which this CP is the Guarantor−All Low Utilized Guarantees in which this CP is the primary CP for the MPSA or MNSA
Collateral Held

Collateral held is determined at the counterparty level using the payment netting, closeout setoff and margining methods. For all three methods, the total collateral held for the counterparty is determined by summing the respective collateral held for all MNSAs and utilized collateral held for MPSAs not in MNSAs.
Counterparty Collateral Held=Σ All MNSA Collateral Held+All MPSA (not in MNSA) Utilized Collateral Held
Counterparty Roll Up

Counterparty exposure is also rolled up between counterparties using the Halo, or “moral responsibility”, method. Using the Halo method, every parent counterparty accepts not only exposure from the MPSA, MNSA, VNG and guarantees that it directly participates in but also accepts the sum exposure of all of its children.
Halo Counterparty Exposure Numbers=Counterparty Exposure Numbers+Σ All Children Exposure Numbers

Once the Halo numbers are calculated, each counterparty is ranked in descending order according to total exposure. Additionally, the share of corporate exposure is calculated.
Share of Corporate Exposure=(Total Counterparty Exposure/Σ All Counterparties' Exposure)*100%

While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. For example, the present invention may be implemented using any combination of computer programming software, firmware or hardware. As a preparatory step to practicing the invention or constructing an apparatus according to the invention, the computer programming code (whether software or firmware) according to the invention will typically be stored in one or more machine readable storage mediums such as fixed (hard) drives, diskettes, optical disks, magnetic tape, semiconductor memories such as ROMs, PROMs, etc., thereby making an article of manufacture in accordance with the invention. The article of manufacture containing the computer programming code is used by either executing the code directly from the storage device, by copying the code from the storage device into another storage device such as a hard disk, RAM, etc. or by transmitting the code for remote execution. The method form of the invention may be practiced by combining one or more machine-readable storage devices containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing the invention could be one or more computers and storage systems containing or having network access to computer program(s) coded in accordance with the invention.

Claims

1. A method comprising:

creating a hierarchical model of legally associated counterparties and associated transactions with an organization, wherein the hierarchical model includes one or more counterparty levels containing the legally associated counterparties, and one or more master levels containing one or more master agreements, each master agreement being between one of the legally associated counterparties and the organization, and one or more transaction levels containing one or more transactions, wherein each master agreement provides one or more mechanisms for financial aggregation of associated transactions between one or more of the counterparties and the organization; and

calculating aggregate financial exposure for the organization at each level of the hierarchical model based on the one or more master agreements and their associated transactions.

2. A method according to claim 1, wherein creating a hierarchical model further comprises creating a hierarchical model having:

a root node representing a parent counterparty;

one or more counterparty levels in the hierarchical model structured by parent-child relationships between one or more counterparties legally associated with the parent counterparty, each counterparty of the one or more counterparties being represented at a node of the counterparty levels, wherein one or more of the counterparty levels is linked to the root node;

one or more master levels in the hierarchical model representing parent-child relationships between one or more agreements, wherein each node in the one or more master levels represents an agreement with one or more of the one or more counterparties that provides one or more mechanisms for financial aggregation of transactions at a lower level in the hierarchical model, and wherein one of the master levels is linked to one of the counterparty levels; and

a plurality of leaf nodes, each representing a transaction with the one or more of the one or more counterparties, each leaf node of the plurality of leaf nodes being linked to one or more nodes of the one or more master levels or one or more nodes of the one or more counterparty levels.

3. A method according to claim 1, wherein calculating aggregate financial exposure includes:

calculating transactional financial exposure at each leaf node resulting from each of the one or more transactions;

calculating master-level financial exposure at each node of the one or more master levels of the hierarchical model, wherein master-level financial exposure at a given master-level node is calculated as a function of the financial exposure of nodes at a lower level of the hierarchical model linked to the given master-level node;

calculating counterparty-level financial exposure at each node of the one or more counterparty levels of the hierarchical model, wherein counterparty-level financial exposure at a given counterparty-level node is calculated as a function of the financial exposure of nodes at a lower level of the hierarchical model linked to the given counterparty-level node; and

generating an aggregate financial exposure for the organization based on an aggregation of the counterparty-level financial exposure.

4. A method according to claim 1, wherein aggregate financial exposure is calculated using a payment netting method.

5. A method according to claim 1, wherein aggregate financial exposure is calculated using a closeout setoff method.

6. A method according to claim 1, wherein aggregate financial exposure is calculated using a margining method.

7. A method according to claim 1, wherein aggregate financial exposure is calculated using a method using all possible netting and setoff.

8. A method according to claim 1, further comprising calculating financial exposure for each master agreement in a master agreement level.

9. A method according to claim 1, further comprising calculating financial exposure for each counterparty in a counterparty level.

10. A method according to claim 1, further comprising calculating financial exposure based on netting, setoff, margin, and collateral requirements.

11. An article of manufacture comprising machine-readable medium including program logic embedded therein that causes control circuitry in a data processing system to perform the steps of:

creating a hierarchical model of legally associated counterparties and associated transactions with an organization, wherein the hierarchical model includes one or more counterparty levels containing the legally associated counterparties, and one or more master levels containing one or more master agreements, each master agreement being between one of the legally associated counterparties and the organization, and one or more transaction levels containing one or more transactions, wherein each master agreement provides one or more mechanisms for financial aggregation of associated transactions between one or more of the counterparties and the organization; and

calculating aggregate financial exposure for the organization at each level of the hierarchical model based on the one or more master agreements and their associated transactions.

12. An article of manufacture according to claim 11, wherein creating a hierarchical model further comprises creating a hierarchical model having:

a root node representing a parent counterparty;

one or more counterparty levels in the hierarchical model structured by parent-child relationships between one or more counterparties legally associated with the parent counterparty, each counterparty of the one or more counterparties being represented at a node of the counterparty levels, wherein one or more of the counterparty levels is linked to the root node;

one or more master levels in the hierarchical model representing parent-child relationships between one or more agreements, wherein each node in the one or more master levels represents an agreement with one or more of the one or more counterparties that provides one or more mechanisms for financial aggregation of transactions at a lower level in the hierarchical model, and wherein one of the master levels is linked to one of the counterparty levels; and

a plurality of leaf nodes, each representing a transaction with the one or more of the one or more counterparties, each leaf node of the plurality of leaf nodes being linked to one or more nodes of the one or more master levels or one or more nodes of the one or more counterparty levels.

13. An article of manufacture according to claim 11, wherein calculating aggregate financial exposure includes:

calculating transactional financial exposure at each leaf node resulting from each of the one or more transactions;

calculating master-level financial exposure at each node of the one or more master levels of the hierarchical model, wherein master-level financial exposure at a given master-level node is calculated as a function of the financial exposure of nodes at a lower level of the hierarchical model linked to the given master-level node;

calculating counterparty-level financial exposure at each node of the one or more counterparty levels of the hierarchical model, wherein counterparty-level financial exposure at a given counterparty-level node is calculated as a function of the financial exposure of nodes at a lower level of the hierarchical model linked to the given counterparty-level node; and

generating an aggregate financial exposure for the organization based on an aggregation of the counterparty-level financial exposure.

14. An article of manufacture according to claim 11, wherein aggregate financial exposure is calculated using a payment netting method.

15. An article of manufacture according to claim 11, wherein aggregate financial exposure is calculated using a closeout setoff method.

16. An article of manufacture according to claim 11, wherein aggregate financial exposure is calculated using a margining method.

17. An article of manufacture according to claim 11, wherein aggregate financial exposure is calculated using a method using all possible netting and setoff.

18. An article of manufacture according to claim 11, further comprising calculating financial exposure for each master agreement in a master agreement level.

19. An article of manufacture according to claim 11, further comprising calculating financial exposure for each counterparty in a counterparty level.

20. An article of manufacture according to claim 11, further comprising calculating financial exposure based on netting, setoff, margin, and collateral requirements.

21. A system comprising:

means for creating a hierarchical model of legally associated counterparties and associated transactions with an organization, wherein the hierarchical model includes one or more counterparty levels containing the legally associated counterparties, and one or more master levels containing one or more master agreements, each master agreement being between one of the legally associated counterparties and the organization, and one or more transaction levels containing one or more transactions, wherein each master agreement provides one or more mechanisms for financial aggregation of associated transactions between one or more of the counterparties and the organization; and

means for calculating aggregate financial exposure for the organization at each level of the hierarchical model based on the one or more master agreements and their associated transactions.

22. A system according to claim 21, wherein the hierarchical model further comprises:

a root node representing a parent counterparty;

one or more counterparty levels in the hierarchical model structured by parent-child relationships between one or more counterparties legally associated with the parent counterparty, each counterparty of the one or more counterparties being represented at a node of the counterparty levels, wherein one or more of the counterparty levels is linked to the root node;

one or more master levels in the hierarchical model representing parent-child relationships between one or more agreements, wherein each node in the one or more master levels represents an agreement with one or more of the one or more counterparties that provides one or more mechanisms for financial aggregation of transactions at a lower level in the hierarchical model, and wherein one of the master levels is linked to one of the counterparty levels; and

a plurality of leaf nodes, each representing a transaction with the one or more of the one or more counterparties, each leaf node of the plurality of leaf nodes being linked to one or more nodes of the one or more master levels or one or more nodes of the one or more counterparty levels.

23. A system according to claim 21, wherein calculating aggregate financial exposure includes:

means for calculating transactional financial exposure at each leaf node resulting from each of the one or more transactions;

means for calculating master-level financial exposure at each node of the one or more master levels of the hierarchical model, wherein master-level financial exposure at a given master-level node is calculated as a function of the financial exposure of nodes at a lower level of the hierarchical model linked to the given master-level node;

means for calculating counterparty-level financial exposure at each node of the one or more counterparty levels of the hierarchical model, wherein counterparty-level financial exposure at a given counterparty-level node is calculated as a function of the financial exposure of nodes at a lower level of the hierarchical model linked to the given counterparty-level node; and

means for generating an aggregate financial exposure for the organization based on an aggregation of the counterparty-level financial exposure.

24. A system according to claim 21, wherein aggregate financial exposure is calculated using a payment netting method.

25. A system according to claim 21, wherein aggregate financial exposure is calculated using a closeout setoff method.

26. A system according to claim 21, wherein aggregate financial exposure is calculated using a margining method.

27. A system according to claim 21, wherein aggregate financial exposure is calculated using a method using all possible netting and setoff.

28. A system according to claim 21, further comprising means for calculating financial exposure for each master agreement in a master agreement level.

29. A system according to claim 21, further comprising means for calculating financial exposure for each counterparty in a counterparty level.

30. A system according to claim 21, further comprising means for calculating financial exposure based on netting, setoff, margin, and collateral requirements.