U.S. patent application number 10/942196 was filed with the patent office on 2005-06-09 for method, system and program for credit risk management utilizing credit exposure.
Invention is credited to Abassi, Misbah, Belshaw, Jarod, Farley, Samuel Jesse, Haynie, Cynthia, Heath, Corey, Hendricks, Colin, Kaisharis, Paul, Meche, Eddie, Miri, John, Reid, Dan, Silhavy, Mark.
Application Number | 20050125341 10/942196 |
Document ID | / |
Family ID | 34381071 |
Filed Date | 2005-06-09 |
United States Patent
Application |
20050125341 |
Kind Code |
A1 |
Miri, John ; et al. |
June 9, 2005 |
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.
Inventors: |
Miri, John; (Cedar Park,
TX) ; Belshaw, Jarod; (Austin, TX) ; Farley,
Samuel Jesse; (Austin, TX) ; Hendricks, Colin;
(Houston, TX) ; Kaisharis, Paul; (Missouri City,
TX) ; Heath, Corey; (Houston, TX) ; Silhavy,
Mark; (Richmond, TX) ; Abassi, Misbah;
(Houston, TX) ; Meche, Eddie; (Cypress, TX)
; Reid, Dan; (Houston, TX) ; Haynie, Cynthia;
(Houston, TX) |
Correspondence
Address: |
DILLON & YUDELL LLP
8911 NORTH CAPITAL OF TEXAS HWY
SUITE 2110
AUSTIN
TX
78759
US
|
Family ID: |
34381071 |
Appl. No.: |
10/942196 |
Filed: |
September 16, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60503429 |
Sep 16, 2003 |
|
|
|
60503422 |
Sep 16, 2003 |
|
|
|
Current U.S.
Class: |
705/39 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 10/06 20130101; G06Q 10/10 20130101; G06Q 20/4016 20130101;
Y10S 707/99943 20130101; G06Q 20/10 20130101; G06Q 40/08 20130101;
G06Q 40/025 20130101 |
Class at
Publication: |
705/039 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
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.
Description
PRIORITY CLAIM
[0001] The application claims the benefit of priority under 35
U.S.C. .sctn.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'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'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
[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'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'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.
[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'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.sub.deal) and all forward exposure (MtM) components from each of
the deals (M.sub.deal). The calculations in calculation block 614
take into account only the positive cash components of the deals
(C.sub.deal) and positive forward exposure (MtM) components from
each of the deals (M.sub.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.sub.deal) and
only the positive forward exposure (MtM) components from each of
the deals (M.sub.deal).
[0045] At the MNSA level 606, all positive cash components of the
deals (C.sub.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.sub.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'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.
[0058] CreditExposure Core
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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:
1 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.
[0063] Counterparty Summary--Exposure & Reverse Exposure
[0064] Page Functionality
[0065] 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).
[0066] Limit Category--Exposure & Reverse Exposure
[0067] Page Functionality
[0068] 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.
[0069] Multiple Counterparty Rollup--Exposure & Reverse
Exposure
[0070] Page Functionality
[0071] 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:
2 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
[0072] 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.
[0073] As a result, this page selects the correct set of numbers
from the results of the calculation engine 224, based on the
following rules:
3 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
[0074] 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.
[0075] 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.
[0076] Contracts Summary
[0077] Page Functionality
[0078] 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:
[0079] Contract id or MNSA id
[0080] Status
[0081] Commodity
[0082] Trade Area
[0083] Internal Counterparties
[0084] External Counterparties
[0085] Deal Category
[0086] Effective Date
[0087] End Date
[0088] Exposure Formula Configuration
[0089] 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.
[0090] Calculation Engine
[0091] 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).
4 C1 C2 C3 C4 C5 M1 M2 M3 M4 M5 Deal1 c1.sub.deal1 c2.sub.deal1
c3.sub.deal1 c4.sub.deal1 c5.sub.deal1 m1.sub.deal1 m2.sub.deal1
m3.sub.deal1 m4.sub.deal1 m5.sub.deal1 Deal2 c1.sub.deal2
c2.sub.deal2 c3.sub.deal2 c4.sub.deal2 c5.sub.deal2 m1.sub.deal2
m2.sub.deal2 m3.sub.deal2 m4.sub.deal2 m5.sub.deal2 . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . Dealn
c1.sub.dealn c2.sub.dealn c3.sub.dealn c4.sub.dealn c5.sub.dealn
m1.sub.dealn m2.sub.dealn m3.sub.dealn m4.sub.dealn
m5.sub.dealn
[0092] 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)
[0093] 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.
5 Total Total Cash Exposure Total Forward Exposure Exposure (A) (B)
(C) Deal1 TCE(T, c1.sub.deal1 - c5.sub.deal1) TFE(T, m1.sub.deal1 -
m5.sub.deal1) (A).sub.deal1 + (B).sub.deal1 Deal2 TCE(T,
c1.sub.deal2 - c5.sub.deal2) TFE(T, m1.sub.deal2 - m5.sub.deal2)
(A).sub.deal2 + (B).sub.deal2 . . . . . . . . . . . . Dealn TCE(T,
c1.sub.dealn - c5.sub.dealn) TFE(T, m1.sub.dealn - m5.sub.dealn)
(A).sub.dealn + (B).sub.dealn
[0094] MPSA
[0095] 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:
[0096] 1. Payment Netting (or "Accounting View")
[0097] 2. Closeout Setoff (or "Contract View")
[0098] 3. No Netting or Setoff (or "High")
[0099] 4. All Possible Netting and Setoff (or "Low")
[0100] Payment Netting ("Accounting View") Exposure
[0101] 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:
6 Allow invoice/ Forward payment netting? Cash Exposure Exposure
Total Exposure No .SIGMA. positive numbers .SIGMA. positive .SIGMA.
positive numbers numbers Yes .SIGMA. all numbers .SIGMA. positive
.SIGMA. positive numbers numbers
[0102] 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=.SIGMA. Positive Deal Total Exposure
[0103] To determine whether an MPSA allows invoice/payment netting,
use the value specified by:
7 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
[0104] Closeout Setoff ("Contract View") Exposure
[0105] 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:
8 Allow invoice/ Allow setoff of payment netting? settlement
amounts? Cash Exposure Forward Exposure Total Exposure No No
.SIGMA. positive numbers .SIGMA. positive numbers .SIGMA. positive
numbers Yes No .SIGMA. all numbers .SIGMA. positive numbers .SIGMA.
positive numbers X Yes .SIGMA. all numbers .SIGMA. all numbers
.SIGMA. all numbers
[0106] 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:
9 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
[0107] No Netting or Setoff Setoff ("High") Exposure
[0108] 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=.SIGMA. Positive Deal Total Exposures
[0109] All Possible Netting and Setoff ("Low") Exposure
[0110] 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=.SIGMA. All Deal Total Exposures
[0111] Collateral Held
[0112] 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=.SIGMA. (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.
[0113] 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.
[0114] MNSA
[0115] 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:
[0116] 1. Payment Netting (or "Accounting View")
[0117] 2. Closeout Setoff (or "Contract View")
[0118] 3. Margining
[0119] 4. No Netting or Setoff (or "High")
[0120] 5. All Possible Netting and Setoff (or "Low")
[0121] Payment Netting Exposure
[0122] 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.
10 Allow invoice/ Total payment netting? Cash Exposure Forward
Exposure Exposure No .SIGMA. positive numbers .SIGMA. positive
numbers .SIGMA. positive numbers Yes .SIGMA. all numbers .SIGMA.
positive numbers .SIGMA. positive numbers
[0123] Total MNSA exposure is calculated as the sum of the positive
total MNSA exposures.
[0124] Closeout Setoff Exposure
[0125] 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=.SIGMA. All MPSA Closeout Setoff
Numbers
Setoff is implied between all MPSAs associated with an MNSA.
[0126] Margining Exposure
[0127] 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:
[0128] The MNSA "Margining Required" is yes.
[0129] The MNSA "Margining Governed by this Contract" for the
specific MPSA is yes.
[0130] The MNSA "Setoff for Collateral Requirements" for the
specific MPSA is yes.
MNSA Margining Numbers=.SIGMA. Closeout Setoff Numbers for MPSAs
that meet the stated conditions
[0131] 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.
[0132] No Netting or Setoff ("High") Exposure
[0133] 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=.SIGMA. All MPSA Total High Exposures
[0134] 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.
[0135] All Possible Netting and Setoff ("Low") Exposure
[0136] 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=.SIGMA. All MPSA Total Low Exposures
[0137] Payment Netting
[0138] 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=.SIGMA. (Collateral
Amount*Valuation %) for all "taken" Collateral applied to that
MNSA+.SIGMA. (Collateral Amount*Valuation %) for "taken" Utilized
Collateral applied to MPSAs with Positive Payment Netting Total
Exposure
[0139] Closeout Setoff
[0140] 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=.SIGMA. (Collateral
Amount*Valuation %) for all "taken" Collateral applied to that
MNSA+.SIGMA. (Collateral Amount*Valuation %) for "taken" Utilized
Collateral applied to all MPSAs
[0141] Margining
[0142] 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:
[0143] 1. The MNSA "Margining Required" is yes.
[0144] 2. The MNSA "Margining Governed by this Contract" for the
specific MPSA is yes.
[0145] 3. The MNSA "Setoff for Collateral Requirements" for the
specific MPSA is yes.
Margining MNSA Collateral Held=.SIGMA. (Collateral Amount*Valuation
%) for all "taken" Collateral applied to that MNSA+.SIGMA.
(Collateral Amount*Valuation %) for "taken" Utilized Collateral
applied to MPSAs that meet the stated conditions
[0146] Guarantee Associated with MNSA
[0147] 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:
[0148] 1. Payment Netting (or "Accounting View")
[0149] 2. Closeout Setoff (or "Contract View")
[0150] 3. Margining
[0151] 4. No Netting or Setoff (or "High")
[0152] 5. All Possible Netting and Setoff (or "Low")
[0153] Counterparty
[0154] 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:
[0155] 1. MNSAs
[0156] 2. Virtual Netting Groups
[0157] 3. MPSAs that are not in MNSAs or Virtual Netting Groups
[0158] 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.
[0159] There are five different ways to aggregate exposure at the
counterparty level:
[0160] 1. Payment Netting (or "Accounting View")
[0161] 2. Closeout Setoff (or "Contract View")
[0162] 3. Margining
[0163] 4. No Netting or Setoff (or "High")
[0164] 5. All Possible Netting and Setoff (or "Low")
[0165] Payment Netting
[0166] 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.
[0167] Counterparty Payment Netting Numbers=.SIGMA. 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
[0168] 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.
[0169] Closeout Setoff
[0170] 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.
[0171] Counterparty Closeout Setoff Numbers=.SIGMA. 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
[0172] Margining
[0173] 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.
[0174] Counterparty Margining Numbers=.SIGMA. 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
[0175] To aggregate total high exposure at the counterparty level
using no netting or setoff, sum all total high exposure
numbers.
Counterparty Total High Exposure=.SIGMA. 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
[0176] 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.
[0177] All Possible Netting and Setoff ("Low")
[0178] 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=.SIGMA. 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
[0179] Collateral Held
[0180] 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=.SIGMA. All MNSA Collateral Held+All
MPSA (not in MNSA) Utilized Collateral Held
[0181] Counterparty Roll Up
[0182] 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+.SIGMA. All Children Exposure Numbers
[0183] 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/.SIGMA.
All Counterparties' Exposure)*100%
[0184] 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.
* * * * *