WO2002031732A1

WO2002031732A1 - Credit support management system

Info

Publication number: WO2002031732A1
Application number: PCT/US2001/031529
Authority: WO
Inventors: Leslie K. Mcnew
Original assignee: Virtual Credit Services, Llc.
Priority date: 2000-10-11
Filing date: 2001-10-09
Publication date: 2002-04-18
Also published as: AU2002211556A1

Abstract

A method of managing credit support instruments used in credit supported transactions includes securing credit support by a credit management facility from credit support providing members of that facility. Each support providing member may identify a collection of permitted counterparties. The permitted counterparties receive credit support from the support providing member and can use that credit support to back transactions. Credit support from the support providing members is allocated among the permitted counterparties and is periodically reallocated among the permitted counterparties based on expected utilization of support amounts by each of the permitted counterparties. In some implementations, the support management facility can also allocate credit support received from a support providing member to any support using member (i.e., allocation of an amount from a particular support providing member is not restricted to allocation among counterparties of that support providing member).

Description

CREDIT SUPPORT MANAGEMENT SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Serial No. 09/686,432, filed October 11, 2000.

BACKGROUND OF THE INVENTION

Trades in assets such as commodities, stocks, bonds, and financial, are often backed by credit supports extended from one party (a "support provider") to another (a "supported party"). In a typical transaction, a credit support, in the form of a parental guarantee, is provided by a parent organization to a counterparty selling to one ofthe parent organization's subsidiaries. The parental guarantee ensures the counterparty (i.e., the supported party) of payment in the event that the subsidiary organization is unable to provide payment (e.g., due to a default).

Providing credit support entails risk to the support providing party due to default events. To limit risk, a support providing party may have self-imposed limits on the amount of credit support that can be extended and the manner in which said credit support may be extended.

Although credit support is a vital business resource, conventional credit support allocation procedures may not make economically efficient use of credit supports. This may result because allocations are done on a per-party basis and don't effectively consider the relationship between different party's uses of credit support. An example ofa conventional credit support procedure is for a corporate credit manager to provide a fixed parental guarantee (i.e., a fixed credit support amount) to a counterparty based on a somewhat arbitrary guess ofthe amount of purchases from that counterparty by a corporate subsidiary. Allocating a fixed credit support amount can result in a poor average utilization rate for the credit support. For example, the sale of home heating fuel to a subsidiary from a credit support using counterparty/supplier can vary significantly depending on the season. During peak usage seasons (i.e., during winter), credit support utilized in the sale of heating oil may approach 100 percent, while the average utilization over an entire year may be only 20 percent. As shown by this simple example, a fixed-amount credit support allocation process can result in significant under-utilized credit support over an extended time period. Other credit allocation processes can also entail economic inefficiencies. Consequently, improved credit allocation processes and systems are desired. SUMMARY OF THE INVENTION hi general, in one aspect, the invention features systems and method for managing credit support instruments used in credit supported transactions. The method includes securing credit support by a credit support management facility from credit support providing members of that facility. Each support providing member also may identify a collection of permitted counterparties. The permitted counterparties receive credit support from the support providing member and can use that credit support to back transactions. Credit support from the support providing members is allocated among the permitted counterparties and is periodically reallocated among the permitted counterparties based on expected utilization of support amounts by each ofthe permitted counterparties. In some implementations, the support management facility can also allocate credit support received from a support providing member to any support using member (i.e., allocation of an amount from a particular support providing member is not restricted to allocation among counterparties of that support providing member).

Implementations also may include one or more ofthe following features. An allocation floor and/or ceiling can be determined for each support using member and the allocated support amount will be an amount between (i.e., bounded by) the allocation floor amount and the ceiling amount. Each support providing member may be required to provide a credit support amount that covers a sum ofthe calculated credit floor amounts of all ofthe member's permitted counterparties and/or that cover a financial exposure amount associated with those permitted counterparties. The allocation floor can be determined, e.g., based on a value-at-risk, as a minimum amount needed to covers shoulder-month credit support usage, and/or based on a deseasonalized forward curve predicting support usage and adjusted by a risk factor. Other methods can also be used (e.g., a fixed default value, a best-guess value, or a value that is empirically determined to provide sufficient risk protection). Support providing members can be, e.g., a parent corporation or other organizational members that may be composed of a number of different business units. Credit support may be allocated by the management facility to particular support using members on behalf of particular business units. The credit management facility can track credit support utilization by particular business units. The credit management facility may also track and compute a return-on- capital metric to track, e.g., income, loss, and profits associated with particular uses of available credit. This metric may be computed as a function of credit risk associated with each support using member. The return-on-capital metric may be used to optimize allocation of credit support amounts to ensure, e.g., availability of credit support for the most profitable transactions. The periodic reallocations of credit may be performed to increase utilization ofa credit support amount provided by a first support providing member (i.e., to ensure that a high percentage ofthe support amount allocated is applied in supporting transactions).

Implementations may provide one or more ofthe following advantages. The need for individual letters of credit and for multiple outstanding parental guarantees can be reduced, along with the associated implicit cost. Management of credit allocated by different business units can be improved. Credit issuance can be standardized resulting in reduced time to issue credit.

The details of one or more embodiments ofthe invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.

DESCRIPTION OF THE DRAWINGS

Fig. 1 is computer network architecture.

Fig. 2 is an organization chart.

Fig. 3 is a demand curve.

Fig. 4 is a flowchart

Figs. 5-13 are exemplary web page interfaces.

DETAILED DESCRIPTION OF THE INVENTION

A virtual credit service facility (VCS) can provide credit support management services to its member business organizations and to other users. The VCS services can include setting and dynamically updating credit support amounts provided by support providers to supported parties. For example, the VCS support management services can be used to set and update an amount of a parental guarantee provided to a supported party by a support provider. An application of this VCS service is to guarantee an obligation owed to a counterparty by a subsidiary, affiliate, or business related to the support provider.

The VCS also can dynamically perform risk analysis to ensure that the credit support amounts allocated and/or used by different parties are within acceptable boundaries. The VCS can consider a variety of risk factors to analyze risk. Risk factors can include, among other things, amounts of outstanding obligations, the length of time each obligation is outstanding, industrial classification of various parties, and other factors. The risk factors can vary depending on an implementation's underlying risk analysis model. For example, an implementation can use the CreditRisk+ risk analysis model developed by Credit Suisse Financial Products (and its corresponding risk analysis factors) instead of, or in addition to, risk analysis models and factors described herein.

NCS operations can be implemented using a computer-based system 100 (Fig. 1 that interacts with support providers, supported parties, deal counterparties, NCS personnel, and other users to automatically establish and manage credit support commitments. The system 100 includes a NCS server 120 that can provide hypertext markup language (HTML) pages and forms (e.g., the web pages 500-1300 of Figs. 5-13) to users at terminals 111-113. The data exchanged between the server 120 and terminals 110 can be used to display NCS service interfaces to the users and to collect data from the users. Other types of data, such as Java(tm) applets, executable software code, and multimedia files can also be exchanged between the server 120 and user terminals 110. The NCS server 120 may also interface, directly and/or indirectly, with a number of other systems 140-144. The other systems can include user databases and systems 141 trading systems 142, credit rating systems 143, transaction processing systems 144 and data services 145. The server database 125 is provisioned with data to track credit allocation and use by users ofthe NCS services.

The NCS system 100 can provide services to manage credit support allocations among users. These services can include setting credit support amounts, calculating support limits, tracking support obligations between parties, generating reports, and performing risk analysis. The system 100 can use world- wide- web client-server technologies (e.g., web servers and browsers) to gather data from users and to perform data processing and calculations. In some implementations, some or all ofthe functions performed by a computerized system 100 can be performed by non-computerized methods (e.g., using ledgers to manually track important information and to calculate relevant values), or using a different computer-based implementations.

The NCS server 120 includes a database 125 that stores user profiles. The user profiles include data identifying users. The database 125 also includes other data used for credit support management. The data in a user profile can differ depending on the user type(s). That is, different data may be in a user profile depending on whether the user is a support provider, a supported party, a transaction counterparty, and/or other user type. In addition, different data may be in a user profile depending on whether the user is a natural person (i.e., a human being) or a business organization (e.g., a corporation may be a NCS user). In some cases, a particular user may have multiple types (e.g., a support provider may also be a support using member and a counterparty depending on particular transactions in which the support provider engages). NCS operations with respect to a multiple-type user will differ depending on the user's role in a particular transaction. Data in a user profile can also differ depending on organizational structure of a user, the particular NCS services provided to the user, and transactions associated with the user. Typically, a user's profile will include data received during NCS membership enrollment, as well as data received from users and/or generated by the VCS at other times.

Enrollment data can be received at the VCS server 120 using a web page interface (i.e., a hypertext markup language (HTML) form transmitted over a network using the hypertext transfer protocol (HTTP)). A web page interface enables display of an enrollment form at a user's computer, collection of data from the user, and transmission ofthe collected data to the VCS server 120 where the data is stored in a database 125 and used for future transaction processing. Fig. 5 shows an example web page enrollment form 500. The form 500 can be formatted using conventional Hypertext Markup Language (HTML) techniques. Transmission ofthe form to the user's computer and of collected data back to the system 120 can be achieved using hypertext transfer protocol (HTTP) and/or other networking protocol.

The following is an example of enrollment data that can be collected from a user or other informational sources. This enrollment data includes both data identifying the user and credit information about the user:

1. User Name / Address / City / State / Zip / and Taxpayer ID Number

2. A control number uniquely identifying a corporate entity (e.g., a DUN number issued by Dunn and Bradstreet).

3. Standard Industrial Classification (SIC) Codes for user's primary businesses

4. Primary Contact Information (name, address, phone, e-mail, facsimile)

5. Credit Rating Agency Name and Credit Rating. This information can be used, to assess credit risk and to set credit support limits. For example, this information may specify that a support provider or supported party has a "AAA" credit rating as determined by the Standard and Poors rating agency

6. Ticker Symbol (i.e., an asset trade identifier).

7. Comments.

VCS users, such member corporations, can be composed of a number of separate divisions. These divisions can include, e.g., subsidiary and affiliate corporations and organizations, business units, and lines of business (LOBs). Fig. 2 shows an organizational hierarchy 200 for a support providing user "NewCo Corp" having a parent corporate entity 201 and a number of subsidiary corporations 202-204. In some implementations, the VCS will handle each subdivision 202-206 as a limited user under control ofa dominant user 201. Dominant users may also be referred to as "parent users" and their controlled subdivisions as "child users." A subdivision 204 can be a dominant user with respect to its subdivisions 205- 206. Each dominant user can set limits on the use of VCS services by its subdivisions. For example, user 204 may set credit support usage limits for users 205-206. Limits set by a user 204 on its child users 205-206 must be consistent with any limits on user 204 by its parent user 201. The most-dominant user (e.g., user 201) in the hierarchy 200 is referred to herein as the primary user.

A primary user 201 can enter data defining relationships among its business divisions (i.e., data hierarchically relating user 201 to divisions 202-206). The primary user 201 can define credit support limits associated with each division 202-206. These limits can be used to set the maximum amount of credit support that the VCS allocates to a supported party in a deal between the supported party and a division 202-206 ofthe primary user 201. The primary user 201 also can enter data to specify the relationship of users 202-206 to each other and to the primary user 201, and to specify the absolute maximum allocation ofthe user 201 provided credit support to counterparties of each user/division 202-206. For example, primary user 201 may commit a total of $100,000,000 in parental guarantees (i.e., credit support) to supported parties with allocation ofthe $100,000,000 controlled by the VCS. The user 201 can specify that the VCS is to allocate a maximum of $30,000,00 in credit support to counterparties of subsidiary 202; $37,500,000 in credit support to counterparties of subsidiary 203; and $32,500,000 in credit support to counterparties of subsidiary 204. When a proposed deal is submitted to the VCS, these sub-account limits can be checked by the VCS to determine whether to approve the proposed deal. For example, if the proposed deal require a credit allocation causing a credit support limit to be exceeded, the deal can be rejected by the VCS.

The VCS may receive separate user enrollment data for each business division in an organization. The enrollment data for the divisions may be entered by the primary user or, in some cases, any dominant user (i.e., any parent organization). The division enrollment data can be similar to the primary user enrollment data (i.e., name, address, city, state, zip, taxpayer ID, DUN number, SIC code, primary contact information, level of service, credit agency and credit rating, ticker symbol, etc.) and entered using, e.g., form 500. When enrolling a division, a dominant user can specify an administrator for the division. The administrator can login to the VCS system to administer information for the administered division and related subdivisions. For example, the primary user 201 can enroll subdivision 204 as a limited user and set up a division administrator for subsidiary 204. Subsidiary 204 's administrator (i.e., user 204) may enroll business units 205-206 as users. User 204, which was limited to a total credit allocation of $32,500,000 by user 201, may further limit the use of 204's $32,500,000 by setting allocation limits for each of divisions 205-206. Thus, a dominant user's rights may include the ability to lower the maximum credit support amount usable by a division and the ability to identify permitted transaction counterparties ofthe division; the VCS ensures that such actions are, in turn, consistent with limits set by any parent of that dominant user

Data records containing identification information and other counterparty data may be stored in the database 125 to track and identify sets of permitted counterparties and to associate counterparties with a particular users 201-206 in an organization. Fig. 6 shows a form 600 used to specify counterparties and Fig. 7 shows a form 700 used to enter details about counterparties including, e.g., details used to compute credit risk associated with each counterparty. An example counterparty data record can include the following information:

Counterparty Data Record:

1. Counterparty Name

2. VCS Internal Rating

3. LOB Industry Rating

4. LOB Defined Rating

5. Secured Physical/Financial Credit Ceiling

6. Unsecured Physical/Financial Credit Ceiling

7. Physical/Financial Credit Floor

8. Secured Credit Limit

9. Unsecured Credit Limit

10. Total Credit Limit

11. Recovery Rate %

12. Amendment Minimum

13. Virtual Guaranty Level

14. Below Virtual Guaranty Level % Cushion

15. Collateral (see collateral below)

16. LOB View Flag

17. Payable Net Flag

18. Termination Net Flag

19. Financial Deals Allowed Flag 20. Block Trading Restriction Flag

21. Physical or Financial Deposit Flag

22. Default rating

The VCS may require that each ofthe listed counterparties be enrolled with the VCS as a user. If a desired counterparty is not already enrolled, information about the counterparty (e.g., name and contact information) may be entered using a web-based form and VCS persom el may contact the counterparty to initiate enrollment procedures. A form 1100 (Fig. 11) may be used to enter a request that a new counterparty be added. The VCS also provides access to administrative functions to edit and maintain counterparty detail information entered by a user. Counterparty information may be specified on a per-division basis. For example, referring back to Fig. 2, the dominant user 201 may designate a set of permitted counterparties of limited user 204. User 204 may select from its set of permitted counterparties to further limit the counterparties of users 205-206.

Hierarchically related organizations can be specified by supported parties as well as by support providers. For example, a primary user of a supported party may specify the supported party's corporate organization and set limits on the amount of credit support that each division can receive. The VCS may process this information to control and/or assess credit risk associated with particular business divisions and for other reporting purposes.

Following enrollment, the different types of users maybe required to provide additional information or commitments to the VCS to enable VCS services for that user type. In the case of a support provider, the support providers interact with the VCS to identify available credit support and to commit those supports to the VCS for allocation by the VCS and for the VCS to provide other management functions with respect to those credit supports. Available credit support information enables the VCS to allocate and manage credit support for a support provider.

A support provider may identify credit support commitments by entering data using a web-based form. Figs. 8 and 9 show web pages 800, 900 used, respectively, to enter data specifying credit support commitments and to display information about all credit support commitments available from a support provider, hi some cases, on-line contracts may be created and digitally signed (or conventional paper-based contracts filed out and sent to the VCS by, e.g., mail or facsimile) to record a contractual obligation by a support provider to pay outstanding obligations owed to a supported party up to the amount ofthe credit support allocated to cover those obligations. The VCS can track multiple credit support commitments by a support provider. Each ofthe credit support commitments may be for a different amount, be of a different type, and can have different use restrictions and effective time periods. The VCS stores credit support commitment records in a VCS database to record key parameters of each credit support commitment. A credit support commitment record can include the following data items:

1. User ID - The user ID can be a VCS-generated identifier formed during user enrollment and used to uniquely identify the user providing the support commitment.

2. Credit Support Guarantor - This field contains data identifying the guarantor ofthe a credit support amount (e.g., Bank of America, etc.).

3. Support Use Type - This field identifies any restrictions on the credit support agreement (e.g., a deposit for credit exposure (DFCE) only).

4. Support Type - Identifies the type of credit support (e.g., Parental Guarantees, Letters of Credit, etc.).

5. Support Commitment Date - Date the credit support commitment data was submitted to the VCS system.

6. Support Quality - Investment grade ofthe credit support.

7. Support Term Start Date - The effective start date ofthe credit support (i.e., when the amount ofthe committed credit support is available for allocation by the VCS to supported parties).

8. Support Term End Date - The effective end date of the credit support commitment (i.e., when the amount ofthe committed credit support is no longer available for use by supported parties).

9. Credit support amount - The amount of a credit support commitment by the providing member.

10. Contract Number - Text field to capture associated contract number information (i.e. Letter of Credit contract information, etc.).

11. Comments - Miscellaneous information associated with the deposit, hi some cases, a support provider may indicate that particular credit support commitments can be used to guarantee obligations owed to a limited set of supported parties and/or between a limited set ofthe user's business divisions. In other words, particular credit support commitments may be dedicated to use with particular supported parties or divisions. For example, Fig. 10 shows an interface used to associate particular credit support facilities with particular lines of business. The VCS processes information about proposed deals (i.e., transactions) between counterparties to determine whether credit support should be allocated to particular support users. Credit supports may flow between the support providers and support users when a deal is approved by the VCS and the VCS determines the amount ofthe credit support. This "flow" of credit support may occur in the form of a contractual obligation with terms dynamically set and modified by the VCS. After allocating credit support for a particular deal, the VCS can track outstanding obligations to determine the amount ofthe credit support that remains in use (and, correspondingly, the amount ofthe credit support that can be allocated to another deal).

When a deal between counterparties is proposed, at least one ofthe counterparties submits details ofthe pending deal (i.e., the obligations to be created) to the VCS for approval. In some implementations, both counterparties may be required to submit details of the deal — this can help to ensure that deal details have been correctly entered and indicates a willingness by each party to transact the deal. For each proposed deal, the VCS performs a number of processes including: 1) Deal Entry (Data Capture), 2) Deal Evaluation and Analysis, 3) Deal Execution (Credit Approval), and 4) Deal Association.

Fig. 4, shows details of a deal submission process. The process 400 includes entry of a proposed deal by a member 401. The proposed deals can include proposed "borrows" entered by a support user and proposed "loans" entered by a support provider (or a division ofthe support provider). During deal entry, the VCS captures details that are used to evaluate the proposed deal and determine whether the deal should be executed. Deal details may be entered using a web page provided by the web server XX to capture deal details from users. Loans and borrows may be defined by a similar set of parameters. The following table shows example data elements that may be captured from a user to define a proposed deal:

Parameter: Description

Current Date: Default is the current date.

Customer Name: User identification. This field may be determined based on the user's login ID.

Deal Type: Designates a Lend or a Borrow deal.

Currency: Default to currency of member' s nation.

Amount: This is a user-defined value designating the lend or borrow amount.

Instrument Type: In some implementations, this is a user-selectable field displays the available credit support types for the given member (i.e. bond, parental guarantee, etc.) and allows selection of one ofthe available types. In other implementations, the VCS may automatically determine the support type.

Instrument Name: This is a user-selectable field that displays the deposited securities for the given member.

Term Start Date: This is the start date associated with the entered deal.

Term End Date: This is the end date associated with the entered deal.

Fixed Rate: This is a user-defined field. The initial default state is zero.

Fixed Rate Day Count Fraction: This is a user-selectable field that displays available fixed rate day counts available (i.e. actual/360, etc.).

Fixed Payment Dates: This is a user-selectable field that displays available payment date types (i.e. quarterly, annual, etc.).

Deal Expiration Date: Deal expiration data is a user-defined field identifying the date ofthe deal's expiration. Once the deal expiration date has been passed the (i.e. current date is greater than the deal expiration date) deal will not longer be available. A member placing a proposed loan will be warned if the amount exceeds the associated underlying security.

After the deal parameters are submitted to the VCS (step 401), the deal parameters can be reviewed by VCS personnel and/or by computer-based validation software to evaluate whether the proposed deal is acceptable (steps 402-404). Evaluation includes deteπnining whether the proposed loan or borrow amount would exceed the credit support limits for a particular party and/or whether the proposed loan or borrow amount would entail an unacceptable level or risk to a support provider. Evaluation by the VCS can be used to rank pending deals and to identify preferred uses ofthe available credits.

To evaluate a proposed deal, the VCS examines credit support allocations associated with each party to the proposed deal to determine whether the proposed support allocation would exceed any allocation limits. As an example, the parties to a deal may include a support user (or division thereof) and a business division e.g., 204, of a particular support provider e.g., 201. Typically, the business division 204 is seeking to purchase an asset from a counterparty and the counterparty seeks a guarantee ofthe division's obligations from the support provider 201 (thus, the counterparty is a supported party with respect to the sale to division 204).

In evaluating a proposed deal, the VCS determines whether the credit support amount that proposed for allocation to the supported user will violate any credit support allocation limits associated with the supported user, the business division 204, or the support provider 201. With respect to the supported user, this determination includes determining whether the proposed amount, together with previously allocated support amounts covering outstanding (i.e., unsatisfied) obligations, would exceed credit support ceilings set for the supported user by the support provider (or division thereof). This determination include examining the aggregate credit support amounts allocated to the supported user (and divisions thereof) that is used to support outstanding obligations. With respect to division 240, the VCS performs analogous processing to determine whether the proposed allocation exceeds limits set by parent divisions (i.e., the primary user 201) on allocable amounts. With respect to the support provider, the VCS determines whether the amount ofthe proposed allocation, together with previously allocated amounts covering outstanding obligations would exceed the total credit support committed by the support provider.

Deal parameters also may be displayed at a computer terminal for review by VCS personnel 402-x403 and for evaluation 404. In some implementations, deal evaluation may include using an computer application, such as a Microsoft Excel™ spreadsheet, to analyze the proposed deal and to compare the proposed deal to other proposed deals. Following deal evaluation x404, the VCS may determine that the proposed deal is not immediately acceptable and may propose a counter deal 405 altering parameters ofthe proposed deal. For example, the VCS may determine that the requested current support amount exceeds set limits and may propose a counter deal with a reduced credit support amount. If a counter deal is proposed, its terms can be evaluated by the applicable users 406-407 (i.e., support providers, support users, and counterparties) and may then be accepted or rejected. If the counter deal is accepted, the deal is "made" 408 (i.e., a credit support allocation occurs). Alternatively, a user may further modify the counter deal 409, and the modified counter deal is then submitted for review and evaluation by the VCS 403-404. The process of proposing deals and counter deals may be repeated until an acceptable deal is determined x410 (or, alternatively, until all proposals are finally rejected). Figs. 12 shows a web page form 1200 used to enter a proposed deal amendment. Fig. 13 shows a form 1300 that can be used to present proposed amendments to a party and from which the party can accept or reject particular amended deals. An amendment may be entered, e.g., by a parent corporation on form 1200 and approved by a subsidiary on form 1300.

If an acceptable deal is determined, the VCS then proceeds to execute the deal. To execute a deal, the VCS must identify unused credit support commitments that meet the parameters ofthe deal and then allocates those unused commitments to the particular deal. To do so, the VCS analyzes credit support commitment records which identify, among other things, the contractual parameters of each credit support commitment. As previously described, these contractual parameters can include amounts, start dates, end dates, support type, etc. Deal association is the process by which the VCS identifies available credit support that can satisfy a desired allocation. For example, a deal requiring credit support for the period of January 1, 2000 - February 15, 2000 in the amount of $10,000,000 can be executed if an unallocated credit support commitments covering at least the allocated amount of $10,000,000 and the period of January 1, 2000 - February 15, 2000 is available. The VCS tracks credit support committed to a particular deal and prevents that credit support from being allocated to additional deals until the underlying obligation is satisfied.

In some cases, credit support allocations may be covered by a collection of credit support commitments. Similarly, a particular support commitment may be used to cover multiple allocations. For example, a January 1, 2000 - February 15, 2000 allocation of $10,000,000 to a support user may be covered by combining (i) a January 1 - January 15 commitment of $10,000,000 from a support provider and (ii) a $20,000,000 January 16, 2000 - March 15, 2000 commitment from the support provider, hi this case, neither support commitment, by itself, is sufficient to cover the entire allocation period that is required. However, by combining the two support commitments (i) and (ii), sufficient coverage is obtained. In this case, the entire commitment from the first support provider is associated with the deal and, consequently, cannot be associated with other deals (unless the underlying obligation is satisfied prior to the January 15 termination date). However, $10,000,000 ofthe second support provider's commitment is unused for the period of January 16, 2000 - February 15, 2000 and $20,000,000 ofthe second support provider's commitment is unused for the period of February 16, 2000 - March 15, 2000. This unused commitment amount can be allocated to other deals and/or other support users.

The VCS can track outstanding obligations for each deal. As the outstanding obligations are satisfied, the VCS may de-allocate the credit support associated with the satisfied obligations. For example, consider a deal in which a credit support of $10 million is allocated to a deal. Initially, to execute the deal, the VCS identifies $10 million in support commitments from a support provider and mark those commitments as in-use. This $10 million in credit support commitments is then unavailable for use with other deals. Sometime after the deal has been transacted, the supported party will, in the absence of defaults, receive payments from the deal counterparty satisfying all or part ofthe supported obligations. For example, the supported party may receive a $6 million payment ten days after the deal is executed. At this time, the outstanding obligation has been reduced from $10 million to $4 million. Because the outstanding obligation has been reduced by $6 million, the VCS may reclaim $6 million in credit support for re-allocation to other parties.

The VCS can track, outstanding obligations based on a periodic input data received from each user. When a supported party receives a payment due on an obligation, that party can access the VCS and input data to indicate the satisfied obligation. The deal counterparty may similarly access the VCS to report payments to the supported party. In some cases, reporting by the supported party, deal counterparty, or other users may not be synchronized. Thus, a deal counterparty may report that a payment has been made, but the supported party may not have reported the satisfaction of an obligation. In such cases, the VCS may provide a warning to each party to update information and/or to correct improper inputs.

The VCS can also optimize the commitment of credit support by support providers. Optimization may be done, e.g., by estimating future credit support needs of supported parties and periodically adjusting credit ceilings for each supported party to meet those needs, hi the energy trading industry, for example, forward demand curves are used to predict seasonal energy use by customers. Fig. 3 shows example forward demand curves of yearly demand for heating fuel 301 and electricity 302 in the northern hemisphere. The demand for heating fuel 301 increases in winter months and decreases during summer months and, conversely, the demand for electricity 302 increases in summer months and decrease in the winter months. The demand curves 301 and 302 show a recurring seasonal behavior that can be used to predict future purchase and sale of heating fuel and electricity. Correspondingly, the curves 301-302 can be used to predict credit support amounts needed to support heating fuel and electricity sales transactions. The VCS can use predictive data, such as the forward demand curves 301-302, to dynamically set, update, and optimize credit support allocation ceilings.

Dynamically setting and optimizing credit support ceilings can be used, for example, to reduce the total amount of credit support commitments needed from a support provider. Consider, for example, a parent corporation (a support provider) having a subsidiary that buys heating fuel and a subsidiary that buys generated electricity. If the parent corporation allocates fixed credit support amounts to counterparties of those subsidiaries (and assuming that the in-use credit support corresponds to the monthly purchase amounts shown in fig. 3), the parent corporation would need to allocate $120 million in credit support to the trading fuel counterparties and $80 million in credit support to the electricity trading counterparties. Thus the parent corporation would need to commit a total of $200 million in allocable credit support to those counterparties. However, because the peak demand periods ofthe heating fuel and electricity trading counterparties differ, the combined in-use credit support allocated to the heating and electricity trading counterparties has a peak of approximately $140 million.

The VCS can dynamically adjust credit support ceilings associated with supported parties based on actual outstanding obligations due to those parties (which can be determined, e.g., based on deal data and outstanding obligation data tracked by the VCS), and the forward demand curves or other predictive data. For example, if a electricity trading counterparty (a supported party) is owed an outstanding obligation of $90 million in June, the VCS may set a credit ceiling for that party of $100 million for the July time period. This new credit ceiling is set based on demand curve 302 which indicates that the credit support need in July for electricity trading is approximately the same as the need in June (note that an additional amount of $10 million was added to the June in-use credit amount to account for variations from the curve 302). During the same time period, the heating fuel trading counterparties may be owed an outstanding obligation of $20 million and the VCS may set their credit allocation ceilings at $25 million. Thus, the parent corporation (the support provider) needs to commit $125 million to the counterparties during the June- July time period.

The invention may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Apparatus ofthe invention may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor; and method steps ofthe invention may be performed by a programmable processor executing a program of instructions to perform functions ofthe invention by operating on input data and generating output. The invention may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any ofthe foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits).

A number of embodiments ofthe present invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope ofthe invention. Accordingly, other embodiments are within the scope ofthe following claims.

Claims

What is claimed is:

1. A method of managing credit support amounts used in credit supported transactions, the method comprising: setting by a credit support management facility an amount of a credit support securing obligations due to a first party by a second party, said credit support being assured to the first party by a credit support providing member; receiving by the credit support management facility deal data identifying an obligation due to the first party by the second party; and periodically adjusting the amount ofthe credit support based on a model reflecting support utilization and obligations due to the first party by the second party.

2. The method of claim 1 further comprising receiving obligation update data identifying satisfaction of an amount ofthe obligations due to the first party by the second party.

3. The method ofclaim 1 wherein the first party is organizationally related to the support providing member.

4. The method of claim 3 the obligation due to the first party by the second party comprises an obligation resulting from a change in a mark-to-market value of an commitment due to the first party by the second party.

5. The method of claim 4 wherein the commitment comprises a contract whereby an asset is provided to the second party and the change in mark-to-market value comprises a change in the market value ofthe asset during a term ofthe contract.

6. The method of claim 1 wherein the second party is organizationally related to the support providing member.

7. The method of claim 6 wherein the first party and the second party are transaction counterparties.

8. The method of claim 7 wherein periodically adjusting based on obligations due further comprises periodically adjusting based on an expected utilization ofthe credit support to secure obligations due to the first party.

9. The method of claim 8 wherein adjusting based on an expected utilization comprises adjusting based on a forward demand curve, the forward curve comprising data predicting an amount of a purchase transaction between the first party and the second party.

10. The method of claim 9 wherein the purchase transaction comprises a transaction whereby the first party purchases an energy commodity from the second party.

11 The method ofclaim 1 wherein setting, receiving, and periodically adjusting comprises setting, receiving, and periodically adjusting by a server computer based on data received from users at terminal computers.

12. A method of managing credit support instruments used in credit supported transactions, the method comprising: securing credit support by a credit support management facility, the credit support being provided by a plurality of credit support providing members ofthe management facility; allocating by the credit support management facility to a first one of a plurality of credit support using members a first amount ofthe secured credit support, the allocated first amount being usable in support of a transaction with a counterparty; and periodically adjusting the allocated first support amount based on expected utilization ofthe first support amount by the first credit support using member.

13. The method ofclaim 12 wherein periodically adjusting further comprises periodically adjusting the allocated first support amount based on a model reflecting support utilization and based on obligations due.

14. The method of claim 12 wherein the transaction with a counterparty comprises a transaction for a purchase of a first product type and wherein periodically allocating further comprises allocating based on expected seasonal purchases ofthe first product type.

15. The method of claim 14 wherein the specific product type is an energy commodity.

16. The method of claim 12 wherein: allocating further comprises allocating to a second one ofthe credit support using members a second amount ofthe secured credit support; and periodically adjusting further comprises periodically adjusting the second support amount.

17. The method of claim 16 further comprising: restricting use ofthe first and ofthe second support amounts to support of transactions with a counterparty organizationally related to a same support providing member.

18. A method of managing credit support amounts used in credit supported transactions, the method comprising: securing credit support by a credit support management facility from each one of a plurality of credit support providing members; receiving data from each one ofthe plurality of credit support providing members identifying a collection of permitted counterparties, the permitted counterparties comprising support using members; allocating credit support provided by each one ofthe credit support providing members among the credit support providing member's collection of permitted counterparties; and periodically reallocating credit support secured from each one ofthe credit support providing members among the credit support providing member's collection of permitted counterparties based on expected utilization of support amounts by each permitted counterparty in said collection.

19. The method of claim 18 wherein: securing credit support comprises receiving data at a computer system each one ofthe plurality of credit support providing members to specifying amounts of credit support secured from said support providing members; receiving the data identifying the collection of permitted counterparties comprises receiving at the computer system; and allocating credit support comprises automatically allocating by the computer system.

20. The method of claim 18 wherein periodically reallocating based on expected utilization comprises reallocating based on a model reflecting support utilization.

21. The method of claim 18 further comprising: determining an allocation ceiling for each support using member in each collection; and wherein: allocating comprises allocating to each support using member an amount not exceeding said support using member's allocation ceiling.

22. The method of claim 18 further comprising: determining an allocation floor for each support using member in each collection; and wherein: allocating comprises allocating to each support using member a credit support amount covering said support using member's allocation floor.

23. The method ofclaim 22 wherein securing credit support comprises securing from each support providing member an amount of credit support covering a sum of each allocation floors of support using members in said support providing member's collection of permitted counterparties.

24. The method of claim 18 further comprising securing an amount of credit support from each one of a plurality of credit support providing members to cover a financial exposure associated with each providing member's collection of permitted counterparties.

25. The method of claim 18 further wherein a first one of the support providing members comprises a plurality of business units and credit support allocated to support using members in the first providing member's collection is associated with one ofthe plurality of business units.

26. The method of claim 25 further comprising computing a return-on-capital metric as a function of credit risk associated with each support using members.

27. The method of claim 18 further comprising: optimizing allocation of credit support amounts to support using members based on a return- on-capital metric.

28. The method of claim 18 wherein periodically reallocating comprises allocating to increase utilization of a credit support amount provided by a first support providing member.

29. A data processing system for the management of credits support amounts used in credit supported transactions, the system comprising: a network interface operatively coupling the system to a plurality of user terminals; a processor software coupled to the network interface to exchange data with the user terminals and to a database storing instructions to configure the processor to: set an amount of a credit support securing obligations due to a first party by a second party, said credit support being assured to the first party by a credit support providing member; receive deal data identifying an obligation due to the first party by the second party; and periodically adjust the amount ofthe credit support based on a model reflecting support utilization and obligations due to the first party by the second party.

30. The system of claim 29 wherein the instructions to periodically adjust based on a model comprises instructions to process a forward demand curve modeling amounts of expected transactions between the first party and the second party.

31. A data processing system for the management of credits support amounts used in credit supported transactions, the system comprising: a network interface operatively coupling the system to a plurality of user terminals; a processor software coupled to the network interface to exchange data with the user terminals and to a database storing instructions to configure the processor to: store data records representing credit supports secured from each one of a plurality of credit support providing members; receive data from each one ofthe plurality of credit support providing members identifying a collection of permitted counterparties, the permitted counterparties comprising support using members; allocate credit support provided by each one ofthe credit support providing members among the credit support providing member's collection of permitted counterparties; and, periodically reallocate credit support secured from each one ofthe credit support providing members among the credit support providing member's collection of permitted counterparties based on expected utilization of support amounts by each permitted counterparty in said collection.