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  
       [0001]     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  
       [0002]     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  
       [0003]     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  
       [0004]     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&#39;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.  
         [0005]     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&#39;s credit exposure and obligations. An organization&#39;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&#39;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  
       [0006]     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  
       [0007]     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:  
         [0008]      FIG. 1  shows a conceptual diagram of a software architecture in which a preferred embodiment of the prevent invention may be implemented.  
         [0009]      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.  
         [0010]      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.  
         [0011]      FIG. 4  shows an example scenario of a credit exposure calculation, in accordance with the preferred embodiment of the present invention.  
         [0012]      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.  
         [0013]      FIG. 6  shows a data flow diagram of calculation stages within the calculation engine, in accordance with a preferred embodiment of the present invention.  
         [0014]      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.  
         [0015]      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.  
         [0016]      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.  
         [0017]      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.  
         [0018]      FIG. 11  shows a screenshot of a web browser page of web-based user interfaces displaying a summary view of a counterparty&#39;s exposure or reverse exposure. The user gets to this page by selecting a counterparty.  
         [0019]      FIG. 12  shows a screenshot of a web browser page of web-based user interfaces displaying exposure/reverse exposure by limit category.  
         [0020]      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.  
         [0021]      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  
       [0022]     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 .  
         [0023]     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&#39;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&#39;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 .  
         [0024]     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 .  
         [0025]     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 .  
         [0026]     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.  
         [0027]     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.  
         [0028]     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.  
         [0029]     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.  
         [0030]     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.  
         [0031]     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 .  
         [0032]     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.  
         [0033]     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 .  
         [0034]     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.  
         [0035]     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.  
         [0036]     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.  
         [0037]     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.  
         [0038]     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.  
         [0039]     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.  
         [0040]     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.  
         [0041]     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&#39;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.  
         [0042]     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 .  
         [0043]     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.  
         [0044]     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 ).  
         [0045]     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.  
         [0046]     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.  
         [0047]     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.  
         [0048]     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.  
         [0049]     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.  
         [0050]     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.  
         [0051]      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.  
         [0052]     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&#39;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.  
         [0053]     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.  
         [0054]     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.  
         [0055]     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.  
         [0056]     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.  
         [0057]     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.  
         [0000]     CreditExposure Core  
         [0058]     Credit Exposure module  105  generates an enterprise view of an organization&#39;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.  
         [0059]     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.  
         [0060]     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.  
         [0061]     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 &amp; Reverse Exposure 
 
 Page Functionality 
 
         [0062]      FIG. 11  shows a screenshot of a web browser page of web-based user interfaces  103  displaying a summary view of a counterparty&#39;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).  
         [0000]     Limit Category—Exposure &amp; Reverse Exposure  
         [0000]     Page Functionality  
         [0063]      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&#39;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.  
         [0000]     Multiple Counterparty Rollup—Exposure &amp; Reverse Exposure  
         [0000]     Page Functionality  
         [0064]      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                    
         [0065]     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.  
         [0066]     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                  
 
         [0067]     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.  
         [0068]     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.  
         [0000]     Contracts Summary  
         [0000]     Page Functionality  
         [0069]      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 
         
         [0079]     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&#39;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&#39;s Date, Scheduled Payment Date, Transaction Date, Buy, Trade Area, Duration, and Deal Type.  
         [0000]     Calculation Engine  
         [0080]     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   c1 deal1     c2 deal1     c3 deal1     c4 deal1     c5 deal1     m1 deal1     m2 deal1     m3 deal1     m4 deal1     m5 deal1         Deal2   c1 deal2     c2 deal2     c3 deal2     c4 deal2     c5 deal2     m1 deal2     m2 deal2     m3 deal2     m4 deal2     m5 deal2         .   .   .   .   .   .   .   .   .   .   .       .   .   .   .   .   .   .   .   .   .   .       .   .   .   .   .   .   .   .   .   .   .       Dealn   c1 dealn     c2 dealn     c3 dealn     c4 dealn     c5 dealn     m1 dealn     m2 dealn     m3 dealn     m4 dealn     m5 dealn                    
 
         [0081]     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) 
 
         [0082]     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, c1 deal1  − c5 deal1 )   TFE(T, m1 deal1  − m5 deal1 )   (A) deal1  +                   (B) deal1         Deal2   TCE(T, c1 deal2  − c5 deal2 )   TFE(T, m1 deal2  − m5 deal2 )   (A) deal2  +                   (B) deal2         .   .   .   .       .   .   .   .       .   .   .   .       Dealn   TCE(T, c1 dealn  − c5 dealn )   TFE(T, m1 dealn  − m5 dealn )   (A) dealn  +                   (B) dealn                    
 
 MPSA 
 
         [0083]     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 
       
 
         [0088]     To aggregate deal exposure values (C 1 - 5 , M 1 - 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                  
 
         [0089]     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 
 
         [0090]     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 
 
         [0091]     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                  
 
         [0092]     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 
 
         [0093]     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&#39; 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 
 
         [0094]     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&#39; 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 
 
         [0095]     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&#39;s date is &gt;=the effective date of the collateral and&lt;=the end date of the collateral. 
 
         [0096]     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.  
         [0000]     MNSA  
         [0097]     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 
       
 
         [0103]     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                  
 
         [0104]     Total MNSA exposure is calculated as the sum of the positive total MNSA exposures.  
         [0000]     Closeout Setoff Exposure  
         [0105]     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 
 
         [0106]     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 
       
 
         [0110]     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.  
         [0000]     No Netting or Setoff (“High”) Exposure  
         [0111]     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 
 
         [0112]     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.  
         [0000]     All Possible Netting and Setoff (“Low”) Exposure  
         [0113]     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 
 
         [0114]     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 
 
         [0115]     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 
 
         [0116]     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 
       
 
         [0120]     A guarantee can be associated with only one MNSA. The available guarantee amount is applied to the MNSA&#39;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 
       
 
         [0126]     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.        
 
         [0131]     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 
       
 
         [0137]     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.  
         [0138]     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  
         [0139]     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.  
         [0000]     Closeout Setoff  
         [0140]     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.  
         [0141]     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  
         [0000]     Margining  
         [0142]     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.  
         [0143]     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  
         [0144]     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 
 
         [0145]     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.  
         [0000]     All Possible Netting and Setoff (“Low”)  
         [0146]     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 
 
         [0147]     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 
 
         [0148]     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 
 
         [0149]     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&#39; Exposure)*100% 
 
         [0150]     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.