Method and system for providing credit support to parties associated with derivative and other financial transactions

Abstract

A computer-based information network for managing credit exposure between counterparties to a plurality of credit support agreements. The network comprises information storage and processing systems. The systems store various types of information including information representative of assets of counterparties to a plurality of credit support agreements for use in covering credit exposures therebetween over a specified time period, and the plurality of credit support agreements. The systems process the information representative of the assets in order to effectively reflect a movement of certain of the assets to cover the credit exposures over the specified time period. An asset movement optimization process is used for determining an optimal movement of certain of said assets to cover credit exposures over the specified time period.

Claims

What is claimed is:

1. A computer-based information network for use by a plurality of users located in remote locations around the globe in order to manage credit support agreements between parties engaged in financial transactions, said computer-based information network comprising:

(1) information storage means for recording various types of information including

(a) credit support agreement information representative of the terms of at least one credit support agreement between a pair of counterparties, wherein each said counterparty has assets providable as collateral to the other said counterparty for covering a credit exposure existing between said counterparties during a specified time period,

(b) asset specifying information representative of the amount and type of assets of each said counterparty during said specified time period, which can be provided by one said counterparty to the other said counterparty as a credit support amount to cover credit exposure existing therebetween in accordance with the terms of said credit exposure agreement,

(c) credit exposure information representative of credit exposure figures which may have been entered into said information storage means by said counterparties during said specified time period,

(d) credit support amount information representative of the amount of assets required to be provided by one said counterparty to the other said counterparty under said credit support agreement, based on the credit exposure figures that may have been entered into acid information storage means during said specified time period, and

(e) credit support asset information representative of the assets provided by one said counterparty to the other said counterparty as credit support assets to cover at least a portion or the credit exposure existing therebetween during said (predetermined) specified time period;

(2) information processing means for processing one or more of said various types of information items recorded in said information storage means in order to

(a) compute said credit support amount using said credit support agreement information, said credit exposure information and said credit support amount information, and

(b) update the status of said credit support asset information to reflect the amount and type of assets provided by one said counterparty to the other said counterparty to cover at least a portion of said computed credit support amount during said specified time period;

(3) information entry means for entering said information into said information storage means; and

(4) information display means for displaying said information to users of said computer-based information network.

2. The computer-based information network of claim 1, wherein said information storage means comprises a relational database having a plurality of interrelated information storage structures, each said information storage structure having a plurality of information fields for storage of information items of a prespecified type.

3. The computer-based information network of claim 1, wherein said information entry means comprises a plurality of remotely located computer-based systems, and said information storage means and said information processing means comprise at least one centrally-located computer-based system.

4. The computer-based information network of claim 1, wherein the credit exposure figures of each pair of said counterparties are entered into said information storage means expressed in the form of mark-to-market figures derived from the underlying transactions between said counterparties under said credit support agreement.

5. The computer-based information network of claim 4, wherein the mark-to-market figure entered into said information storage means by one slid counterparty is not displayed to paid other counterparty unless said other counterparty has entered its mark-to-market figure into said information storage means.

6. The computer-based information network of claim 1, wherein said credit support agreement information further comprises

information representative of a plurality of pairs of counterparties, each said pair of counterparties having at least one credit support agreement therebetween, and

information representative of said at least one said credit support agreement between each said pair of counterparties.

7. The computer-based information network of claim 6, wherein said credit support agreement information further comprises

information representative of a plurality of pairs of counterparties, each said pair of counterparties having at least one credit support agreement therebetween, and

information representative of said at least one said credit support agreement between each said pair of counterparties.

8. The computer-based information network of claim 7, wherein at least one of said information structures includes an information storage field which stores information items representative of a chain of asset movement with respect to one or more of said credit support assets, reflecting the re-use thereof among said plurality of counterparties.

9. A computer-based information network for managing credit exposure between counterparties to a plurality of credit support agreements, comprising:

(1) an information storage system for storing various types of information including information representative of

(a) assets of counterparties to a plurality of credit support agreements for use in covering credit exposures thereof over a specified time period, and

(b) said plurality of credit support agreements; and

(2) an information processing means for processing said information representative of said assets in order to effectively reflect a movement of certain of said assets to cover said credit exposures over said specified time period, wherein said information processing means further comprises asset movement optimization means for determining an optimal movement of certain of said assets to cover said credit exposures over said specified time period, and wherein said asset movement optimization means comprises a computational process which utilizes an objective function and a system of constraints related to the market value of said assets at about said specified time period, which are available for use in covering said credit exposures of said plurality of counterparties.

10. A computer-based information system for use by a plurality of users located in remote locations around the globe in order to manage credit support agreements between parties engaged in financial transactions, said computer-based information system comprising:

(1) information storage means for recording various types of information items including

(a) credit support agreement information representative of the terms of at least one credit support agreement between a pair of counterparties, wherein each said counterparty has assets providable as collateral to the other said counterparty for covering a credit exposure between said counterparties during a specified time period,

(b) asset specifying information representative of the amount and type of assets of each said counterparty during said specified time period, which can be provided by one said counterparty to the other said counterparty as a credit support amount to cover the credit exposure existing therebetween in accordance with the terms of said credit exposure agreement,

(c) credit exposure information representative of the credit exposure figures-s which may have been entered into said information storage means by said counterparties during said specified time period,

(d) credit support amount information representative of the amount of assets required to be provided by one said counterparty to the other said counterparty under said credit support agreement, based on the credit exposure figures that may have been entered into said information storage means during said specified time period, and

(e) credit support asset information representative of the assets provided by one said counterparty to the other said counterparty as credit support assets to cover at least a portion of the credit exposure existing therebetween during said specified time period;

(2) information processing means for processing one or more of said various types of information items recorded in said information storage means in order to

(a) compute said credit support amount using said credit support agreement information, said credit exposure information and said credit support amount information, and

(b) update the status of said credit support asset information representative to reflect the amount and type of assets provided by one said counterparty to the other said counterparty to cover at least a portion of said computed credit support amount during said specified time period;

(3) information entry means for entering said information into said information storage means; and

(4) information display means for displaying said information to users of said computer-based system.

Description

FIELD OF INVENTION

The present invention relates to a Global Credit Support (GCSS) system and method for facilitating and managing the movement of assets (i.e., securities and cash) between counterparties for collateralization of derivative and other financial market exposures.

BRIEF DESCRIPTION OF THE PRIOR ART

Market studies have determined that there has been a growing trend toward bilateral collateralization between major over-the-counter derivatives market participants. The reason for this trend is quite clear. Bilateral collateralization provides a means of reducing the risks associated with the credit exposure between counterparties. As credit support agreements are the means used to realize bilateral collateralization, an overview of such agreements, including their terms and considerations regarding their execution is in order.

The credit support agreements are governed by the jurisdiction of the country in which the agreements are situated. Unfortunately, however, there is little compatibility between countries, an array of security transfer mechanisms are used, seamless cross-border asset substitutions are extremely difficult, and most credit support agreements are based on U.S. assets. In general, most bilateral credit support agreements between major derivatives dealer-broker and banks are managed internally.

Credit support agreements in the derivatives industry are being standardized by the International Swaps and Derivatives Association (ISDA). However, because national laws provide which security arrangements will be respected in insolvency, there are presently three different standard credit support agreement types for ISDA. Parties choose the agreement which provides the greatest legal comfort according to the law likely to construe enforceability in an insolvency.

Under a typical credit support arrangement, a customer calculates periodically (e.g. daily) its credit exposure with the counterparty. The frequency of credit support asset valuation varies and is agreed between the counterparties. In the prior art systems, an individual must telephone each counterparty and negotiate a mutually agreed upon valuation for the asset portfolio. Depending upon the agreed mark-to-market value (MTM), a credit exposure is determined according to a series of calculations. Assets, in the form of securities and/or cash, are transferred to cover credit exposures. A typical large financial institution may have more than seventy-five counterparties and hundreds of underlying deals with each of those counterparties. As many as ten or more different computer-based systems may be required to calculate mark to market values (MTM) and a large staff to agree on MTMs and make deliveries of credit support assets. If an asset transfer is required, it must be accomplished manually via previously agreed upon mechanisms.

A credit support agreement between the counterparties typically stipulates terms under which credit exposures are calculated and assets transferred. Typically, a credit support agreement includes a minimum transfer amount, a tranche or minimum block size, eligible securities, valuation percentages (i.e., haircuts) for each class of securities, and conditions under which assets shall move, and in what direction among the parties. When negotiating cover for their credit exposures, each counterparty must take all these criteria into consideration.

As changes are negotiated outside the system, personnel must also handle renegotiation of credit support agreements and the negotiation of new agreements. This means tracking the various versions of credit support agreements for each pair of counterparties. This becomes a major task in situations where there may be a number of versions of an agreement, each having a different initiation date.

In short, prior art credit support systems are error prone and time-consuming in the negotiation and implementation of credit support arrangements, resulting in incremental costs to both counterparties.

Furthermore, as markets move towards collateralization deals as credit lines fill up, dealer-broker-dealers and banks must provide more efficient means of conducting their current business in order to maintain competitiveness, increase margins, and be able to effect additional business in the derivatives market.

Consequently, there is a great need in the art to provide an improved system and method of supporting bilateral collateralization between parties in a way that reduces the cost of implementing their bilateral credit support agreements, while reducing the amount of assets required to support their financial dealings.

OBJECTS AND SUMMARY OF THE PRESENT INVENTION

Accordingly, a primary object of the present invention is to provide a novel computer-based system and method of efficiently managing bilateral credit support agreements between parties engaged in derivatives and other financial markets, while avoiding the shortcomings and drawbacks of prior art methodologies.

Another object of the present invention is to provide such a system, which allows parties using the system to more efficiently manage their current business, reduce overhead, and support new business using the same system.

Another object of the present invention is to provide such a computer-based system that can be readily used by primary and secondary tier derivatives dealers and derivatives end-user banks that wish to reduce overhead costs involved in managing their credit exposures and assets used to collateralize their bilateral credit support agreements.

A further object of the present invention is to provide a computer-based credit support system which does not require information details regarding the underlying transactions for which the system provides credit support.

A further object of the present invention is to provide such a system in which credit support assets can be efficiently and inexpensively managed (e.g., moved) in an automated manner, while simultaneously providing a quicker and easier means for credit support asset valuation, position, administration, and more efficient use of eligible assets.

A further object of the present invention is to provide such a system which can be readily adapted to provide computer-based bilateral collateralization support for transactions involving FX and equity derivatives.

A further object of the present invention is to provide a computer-based credit support system in which the parties can record credit support agreements of various legal effect which will each be implemented by the system with regard to the legal requirements pertaining thereto.

A further object of the present invention is to provide a computer-based credit support system in which the parties to credit support agreements can provide internationally traded securities as credit support with less legal and operational risk.

A further object of the present invention is to provide such a system, in which all information concerning such assets is maintained in a self-standing system, while the actual custody of such assets is maintained by an independent asset custody system, such as a conventional lending, settlement and clearing system.

A further object of the present invention is to provide such a system in which registered users (i.e., customers) enter and view their computed credit exposures (CES) and credit support assets on a real-time basis using personal computer workstations supporting a graphical use interface.(GUI).

A further object of the present invention is to provide such a system, in which credit support assets of counterparties to credit support agreement are optimally used (i.e., moved) to cover their credit exposures in an automated manner.

A further object of the present invention is to provide such a system, in which credit exposure requirements of counterparties to a credit support agreement can be processed on the same day or next day basis, by choosing a prescheduled Global Credit Support Processing Cycle carried out within the system.

A further object of the present invention is to provide such a system, in which system users are permitted to flexibility specify asset eligibility criteria, designate credit support assets, asset substitutions, asset repurchases, asset rehypothocations, and asset freezes, while maintaining responsibility for their bilateral credit support agreements.

A further object of the present invention is to provide such a system, in which users are provided a maximum amount of flexibility which cut overhead costs and improve margins through more efficient management of the assets used to support their bilateral credit support agreements.

A further object of the present invention is to provide such a system in which multiple information processing cycles are employed so that the system can be used simultaneously by hundreds of parties to credit support agreements who may be physically located anywhere around the globe (i.e., in Europe, America, and Asia alike) without being subject to prejudices or disadvantages.

A further object of the present invention is to provide such a system, in which the credit exposure (mark to market (MTM) positions) of parties can be entered into the database of the System by screen-entry or batch-entry processes.

A further object of the present invention is to provide such a system in which credit exposures entered into the system by the parties are automatically interpreted by rule-based interpretation procedures.

A further object of the present invention is to provide such a system, in which credit support assets are managed on a database having a hierarchical account structure.

A further object of the present invention is to provide a computer-based credit support system, in which party to a credit support agreement is not permitted to view the MTM value entered into the system by its counterparty until the party enters its MTM value.

A further object of the present invention is to provide a computer-based credit support system, in which the parties of credit support agreements recorded therein are provided with an optimal level of manual control with regard to the movement of the credit support assets they hold, up until a predetermined time at which its automated asset movement mode is automatically entered and assets are moved in an optimal manner using linear programming methods.

A further object of the present invention is to provide such a system, wherein customers, using a hierarchical account structure can act, optimally, as a custodian for some of their counterparties.

A further object of the present invention is to provide such a system, in which a wide range of currencies can be used in book-entry type systems.

These and other objects of the present invention will become apparent hereinafter and in the Claims to Invention.

SUMMARY OF INVENTION

According to one aspect of the present invention, a global credit support system (GCSS) is provided for the purpose of tying together customer sites (in the U.S., Europe, and elsewhere throughout the world) via a global communication network (WAN). In order to support customers located in different time zones, the GCSS of the illustrated embodiment provides at least two major information processing cycles which allows Europeans, Americans, and Asians alike to participate in the system in a substantially equal (i.e., fair) manner. The system can be used by primary and secondary tier derivatives dealers and derivatives end users who wish to reduce the overhead of managing their credit exposures and the assets used to collateralize their bilateral credit support agreements.

The GCSS of the illustrative embodiment supports the following functionalities: Screen and batch entry of credit exposures (MTMs); Daily valuation of assets; Automatic rule-based interpretation of credit exposures; Optimalization of asset movement among counterparties to optimally cover credit exposure; Re-use (i.e., rehypothocation) of assets; Automated transfer to/from clearing and settlement accounts; Manual asset movement among counterparties; Ability to remove assets for repo; Ability to re-use and/or block the re-use of assets; Ability to designate assets to counterparties; Ability to cover many counterparties with a single asset delivery instruction; Repo in cooperation with the Cedel Tripartite Repo Service; Secure, reliable, guaranteed, and encrypted communications; Uptime/Availability; Individual holiday calendars; Counterparty specific asset eligibility and haircuts; Multiple users and/or multiple locations; Hierarchical account structure; Automated processing of non-GCSS customers exposures for GCSS users' support; and Periodic (e.g., daily, weekly, monthly, quarterly) entry and coverage of credit exposures.

GCSS customers calculate their exposure to each of their counterparties using their current methods. At GCSS customer workstations, each customer then inputs its credit exposures (i.e., the MTM of all underlying deals) either in bulk or individually using GCSS input screens and/or GCSS file reading mechanisms. Bulk input of credit exposures is accomplished through the creation of a fixed format file by the user. Such a file can be created in most commercial spreadsheets. The customer then indicates to GCSS that the file is available by using a pop-up screen support on its workstation. Once GCSS has received an MTM value from each party, the GCSS publishes both values to each party. GCSS does not allow either party to view the other's credit exposure on its customer workstation until they have both been submitted. The values are accepted from GCSS customers only. GCSS customers may also enter values for their non-GCSS counterparties. However, non-GCSS counterparties are not allowed access to the system.

In the normal course of business, credit exposures may be input on any day that GCSS is operational (up to a defined cut-off time). Updates are sent at regular intervals as defined in the Credit Support Agreement (e.g., daily, weekly, monthly) and may be supplied in advance of a date. GCSS customers may block transfers of assets to a particular counterparty and decline transfers from a particular counterparty.

Based on the size of the exposure, the collateral previously transferred and the terms of the credit support agreement, and any asset-specific or counterparty specific instructions, the GCSS automatically calculates the Amount to Move, the difference between yesterdays and today's Basis, Gross Out, Gross In, Net Totals, Blocked Totals, and Total Exposure.

Assets are moved between the GCSS customer account and that of their counterparty in the direction indicated by the calculations (i.e., amount to move figures). GCSS may notify a customer of the need to bring more assets into the system to meet new, higher credit support requirements or to cover an adverse movement in the value of credit support assets. Customers may move assets to their GCSS account in several ways:

1. Transfers of eligible assets from a clearing and settlement account; these transfers are effected by book entry via the next available processing cycle (daytime or nighttime).

2. Provide GCSS with a power of attorney to draw assets from a clearing and settlement account and transfer them to the GCSS account.

3. Enter into a securities borrowing arrangement within a clearing and settlement account to obtain a loan of the required securities.

4. Move eligible securities over a cross border link into the system.

A customer may remove from GCSS securities not allocated as credit support if the customer deposited the assets to GCSS or received them from a counterparty with rights to re-use the assets. A customer is always able to remove cash balances from GCSS.

GCSS system will credit income from GCSS securities directly to the originator as long as the security remains in GCSS. This is achieved by maintaining for every security position a notation of its originator, regardless of actual position in the system as a result of transfers and on-transfers. This functionality makes it easier to satisfy the general requirement in credit support agreements that the secured party or transferee make payment to the pledgor, chargor, or transferor in amounts equal to any income received on securities.

Other advantages of the present invention will become apparent hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the objects of the Invention, the following Detailed Description of the Illustrative Embodiments should be read in conjunction with the accompanying Drawings, in which:

FIG. 1 is a schematic hardware diagram of the global credit support system of the present invention, shown realized as a plurality of client-server workstations in operable communication with each other through a wide area networks (WAN);

FIG. 2 is a schematic diagram of the physical architecture of the GCSS of the present invention, showing various processes carried out on the client-server workstations of the system;

FIG. 3 is a schematic representation (i.e., logical entity model) of the relational database used in the construction of the illustrative embodiment of the GCSS of the present invention, showing the five groups of data structures used in the realization of the diverse functionalities of the system of the present invention;

FIG. 4A is a schematic representation of the information structure entitled CUSTOMER ACCOUNT specifying the various information fields thereof and the type of information contained therein;

FIG. 4B is a schematic representation of the information structure entitled ACCESS RIGHTS PROFILE, specifying the various information fields thereof and the type of information contained therein;

FIG. 4C is a schematic representation of the information structure entitled CONTACT DETAIL, specifying the various information fields thereof and the type of information contained therein;

FIG. 4D is a schematic representation of the information structure entitled CUSTOMER ORIGINAL ASSET RULES, specifying the various information fields thereof and the type of information contained therein;

FIG. 4E is a schematic representation of the information structure entitled CUSTOMER PREFERENCE, specifying the various information fields thereof and the type of information contained therein;

FIG. 4F is a schematic representation of the information structure entitled CUSTOMER ELIGIBILITY, specifying the various information fields thereof and the type of information contained therein;

FIG. 4G is a schematic representation of the information structure entitled CUSTOMER CASH CORRESPONDENT, specifying the various information fields thereof and the type of information contained therein;

FIG. 4H is a schematic representation of the information structure entitled MASTER, specifying the various information fields thereof and the type of information contained therein;

FIG. 5A is a schematic representation of the information structure entitled CUSTOMER CREDIT AGREEMENT, specifying the various information fields thereof and the type of information contained therein;

FIG. 5B is a schematic representation of the information structure entitled AGREEMENT ELIGIBLE COLLATERAL, specifying the various information fields thereof and the type of information contained therein;

FIG. 5C is a schematic representation of the information structure entitled AGREEMENT PREFERENCE specifying the various information fields thereof and the type of information contained therein;

FIG. 5D is a schematic representation of the information structure entitled COMMON CREDIT AGREEMENT specifying the various information fields thereof and the type of information contained therein;

FIG. 6A is a schematic representation of the information structure entitled OMINIBUS POSITION, specifying the various information fields thereof and the type of information contained therein;

FIG. 6B is a schematic representation of the information structure entitled ASSET, specifying the various information fields thereof and the type of information contained therein;

FIG. 6C is a schematic representation of the information structure entitled ASSET, TYPE, specifying the various information fields thereof and the type of information contained therein;

FIG. 6D is a schematic representation of the information structure entitled SECURITY, specifying the various information fields thereof and the type of information contained therein;

FIG. 6E is a schematic representation of the information structure entitled CURRENCY, specifying the various information fields thereof and the type of information contained therein;

FIG. 6F is a schematic representation of the information structure entitled SECURITY PRICE, specifying the various information fields thereof and the type of information contained therein;

FIG. 6G is a schematic representation of the information structure entitled FX RATE, specifying the various information fields thereof and the type of information contained therein;

FIG. 6H is a schematic representation of the information structure entitled CORPORATE ACTION, specifying the various information fields thereof and the type of information contained therein;

FIG. 6I is a schematic representation of the information structure entitled CASH INTEREST BALANCE, specifying the various information fields thereof and the type of information contained therein;

FIG. 7A is a schematic representation of the information structure entitled ASSET PIECE, specifying the various information fields thereof and the type of information contained therein;

FIG. 7B is a schematic representation of the information structure entitled INTERNAL GCSS MOVEMENT, specifying the various information fields thereof and the type of information contained therein;

FIG. 7C is a schematic representation of the information structure entitled CUSTOMER ASSET POSITION, specifying the various information fields thereof and the type of information contained therein;

FIG. 7D is a schematic representation of the information structure entitled CREDIT EXPOSURE, specifying the various information fields thereof and the type of information contained therein;

FIG. 7E is a schematic representation of the information structure entitled SUBSTITUTION REQUEST, specifying the various information fields thereof and the type of information contained therein;

FIG. 8A is a schematic representation of the information structure entitled EXTERNAL MOVEMENT INSTRUCTION, specifying the various information fields thereof and the type of information contained therein;

FIG. 8B is a schematic representation of the information structure entitled CEDCOM MOVEMENT INSTRUCTION, specifying the various information fields thereof and the type of information contained therein;

FIG. 8C is a schematic representation of the information structure entitled FED MOVEMENT INSTRUCTION, specifying the various information fields thereof and the type of information contained therein;

FIG. 9 is a schematic diagram illustrating the various groups of information processes carried out by the GCSS of the present invention entitled AGREEMENT MANAGEMENT, CREDIT SUPPORT PROCESSING, ASSET MANAGEMENT, INFRASTRUCTURE, and GCSS FINANCIAL and also the hierarchical organization of the various information subprocesses thereof;

FIG. 10 is a schematic diagram illustrating the hierarchical arrangement among the various information subprocesses comprising the information process group entitled AGREEMENT MANAGEMENT;

FIG. 11 is a schematic diagram illustrating the hierarchical arrangement among the various information subprocesses comprising the information process group entitled CREDIT SUPPORT PROCESSING;

FIG. 11A is a schematic diagram representative of the Asset Movement Process of the present invention, showing the information items input to the process and optimization output therefrom for subsequent use by the GCSS in optimally allocating credit support assets of member parties to the system in order to cover the credit exposures thereof;

FIG. 12 is a schematic diagram illustrating the hierarchical arrangement among the various information subprocesses comprising the information process group entitled ASSET MANAGEMENT;

FIGS. 13A and 13B provide a schematic diagram of the user activity of the GCSS by different parties (i.e., customers) in different time-zones, during a 24 hour period of system operation, in which same day cover is provided by the GCSS;

FIGS. 14A and 14B are high-level process diagrams indicating the various processes that are carried out with the GCSS during a credit support processing cycle in the GCSS;

FIG. 15A is a graphical representation of a graphical display screen which is used by the administrators of the GCSS in order to enter new customers in the system, open customer accounts, and perform other administrative and custodial functions;

FIGS. 15B and 15C are graphical representations of two exemplary graphical display screens which are used by customers of the GCSS in order to create, modify, terminate and review Credit Support Agreements management within the GCSS of the present invention;

FIGS. 15D and 15E are graphical representations of two exemplary graphical display screens which are used by customers of the GCSS in order to enter credit exposures and instructions into the GCSS, as well as resolve issues regarding credit exposure between counter-parties (i.e., customers) and eligible credit support assets thereof;

FIGS. 15F and 15G are graphical representations of two exemplary graphical display screens which are used by the customers the GCSS in order to optionally transfer credit support assets to its counter-parties, by customer-designated (i.e., manual) movement operations, after notification of credit asset delivery and/or credit asset return instructions by the GCSS;

FIG. 15H is a graphical representations of a graphical display screen which is used by the GCSS in order to notify its customers of the results (i.e., asset movements effected) performed by the automated asset movement process of the GCSS; and

FIGS. 15I and 15J are graphical representations of a display screen used to notify GCSS customers of the results of the Asset Movement Optimization Process.

DETAILED DESCRIPTION OF THE BEST MODE EMBODIMENT OF THE PRESENT INVENTION

Referring to the figures of FIGS. 1 through 15J, the best mode embodiment of the present invention will be described in detail below.

In general, the global credit support system of the present invention (hereinafter GCSS ) may be realized in a variety ways depending on the enabling technology available at the time of realization, and particular application requirements at hand. In the illustrative embodiment, the GCSS is realized as network of client-server workstations spatially distributed about the planet Earth in order to provide service to the multitude of users that the system is designed to serve. It is understood, however, that the system can be realized in other ways using, for example, a main-frame computing platform with spatially distributed user-interface terminals, and the like.

As shown in FIG. 1, the GCSS of the illustrative embodiment comprises: a plurality of personal computers (e.g., realized as Sun Microsystems.RTM. computing platforms) providing an Database Server 2, an Optimization Server 3, an Authentication Server 4, a first GCSS Process Server (1) 5 and a second GCSS Process Server (2) 6, each interconnected to a Local Area Network (LAN) 7; a plurality of group of GCSS Customer Workstations (e.g., groups of desktop computer systems) 8 interconnected to the GCSS Servers by way of routers and communication support equipment of a Wide Area Network (WAN) 9; a Backup/Mirrored Database Server 10, a Backup Optimization Server 11, and a Backup GCSS Process Server 12 each interconnected to a Local Area Network (LAN) 13 and interconnected to LAN 7 site by bridges 14, in a conventional manner; a Pricing Workstation (e.g., realized as desktop computing system) 15 for providing asset valuation information, and connected to the LAN 7; a GCSS Operations Workstation 16 connected to LAN 7, for performing management operations pertaining to the GCSS; a custody clearing and settlement system (e.g., such as the LCS system operated by Cedel of Luxembourg) 17 for maintaining an Omnibus Account, in which all cash and securities in the GCSS are held and managed on behalf of GCSS customers by the GCSS Operator which, preferably functions legally as a fiduciare to each and every GCSS customer; and a SPEED Link Fedwire Terminal 18 connected to LAN 7, for transferring to the GCSS Server Workstations, information representative of U.S. federal electronic funds and securities transfer. Preferably, although not essential to the present invention, each GCSS Server described above is located at a central site where system managers are physically located. Also, each GCSS Customer Workstation is typically located at the customer site, although it is understood that each such Workstation within its customer group need not be physically located with all Workstations within the group, but may be networked together using conventional communication networking technology well known in the art.

In the illustrative embodiment, each GCSS Workstation 8 at the customer site supports a graphical user interface (GUI) using a GUI generator, such as PowerSoft's PowerBuilder. The particular character of the GUI may vary from embodiment to embodiment of the invention. However, it is preferred that each such GUI provides an array of display screens which facilities easy entry of information by the GCSS customer during the day, as well as display various types of reports and notifications produced by the GCSS. The personal computers used to realize each GCSS Customer Workstation can run virtually any type of operating system, such as the Microsoft Windows NT operating system, Microsoft Windows 3.1 operating system, Unix operating system, or the Macintosh.RTM. operating system. Each GCSS Server 2, 3, 4, 5, 6, 10, 11, and 12 is preferably realized as one or more Sun Microsystem SPARC computing platform running the Solaris operating system. As will described in greater detail hereinafter, the GUI process running on each GCSS Customer Workstation cooperates with central server processes operating on the GCSS Servers at the central site by way of a data-packet network communication protocol supported over WAN 9.

In the illustrative embodiment, the processes of the present invention are realized as client-server based processes, wherein a GCSS Server 5 or 6 supports the server portion of the process, while a GCSS Customer Workstation 8 supports the client portion thereof In order realize such client-server processes upon the GCSS, a data-packet network communication protocol is employed by the GCSS Customer Workstations and the GCSS Server Workstations thereof. A suitable network communication product for this system implementation is a Teknekron Information Bus (TIB) based communication product commercially available from Teknekron Software Systems, Inc. of Palo Alto, Calif. Notably, to ensure secure communications throughout the GCSS, all data transmissions between the GCSS Customer Workstations and central GCSS Server Workstations are encrypted using conventional data encryption technology.

The benefits of using the TIB-based architecture described above are numerous. Primarily, it provides flexibility in being able to change one process within the GCSS, without effecting other processes. Also, it provides for easier system maintenance and improved security. Moreover, the TIB architecture reinforces the design goals of GCSS, namely: modularity, abstraction, and encapsulation. These design features of the GCSS hereof will be briefly described below.

Encapsulation involves isolating the internal mechanisms of individual processes so that no part of the system is dependent on the internal details of any other part thereof. In contrast with a monolithic structure wherein a single large process is composed of interconnected and interdependent subprocesses, an encapsulated system has a series of independent communicating processes. Consequently, in the encapsulated system design of the present invention, the problem of developing, maintaining, and changing the system is simply reduced to exchanging modules rather than modifying a monolithic interdependent system.

Modularity is inherent in encapsulation and simplifies the design goal of engineering each process as a separate standalone entity realized by its own set of code. This makes it possible to alter the code of a process without affecting other processes. Because processes shall communicate via messages, changes to the way in which a process handles a message shall not affect another process within the system.

Abstraction is the isolation of data accessing operations from data processing operations. The primary advantage of this system design feature is that it makes possible for the relational database of the GCSS, which will be described in great detail hereinafter, to be changed without affecting the many processes that use it. Another advantage of this system design feature is that it minimizes the need for stored procedures and triggers, thus making even the database engine independent of data processing engine of the GCSS. This feature of the system permits the operator of the GCSS to change from one to another database programming language or another one, while only requiring the reengineering of a minimum number of processes. This system design feature ensures that the GCSS is easily updatable and maintainable system characterized by high performance, with maximum flexibility and extensibility.

All information items pertaining to GCSS customers, their accounts, credit support agreements, credit support assets, credit exposures, chains of asset transfers among counter-parties and the like, are maintained within a database maintained within the GCSS Database Server Workstation 2. In the preferred embodiment, this database is realized as a relational database using database management computer software, such as Oracle 7.x. Pro-C, or any other database management software. The construction of the relational database of the present invention will be described in great detail hereinafter with reference to FIGS. 3 through 8C.

Referring to FIG. 2, a functional overview of the GCSS of the present invention will be described below.

In general, GCSS is a globally distributed computer-based information network (i.e., system) for tying together customer sites in the U.S., Europe and Asia via a Wide Area Telecommunications Network (WAN). Typically, several hundred broker-dealers, banks, and end users can simultaneously use GCSS. In order to support the different time zones, GCSS provides two major processing cycles which allows Europeans, Americans, and Asians to participate in the system without handicaps or disadvantages owing to their geographical location on the Earth.

Each GCSS customer opens a GCSS account and transfers to the system assets which are available for use in providing collateral to counterparties providing credit to the GCSS customer. Such an account contains customer identification information, asset information, and various unilateral parameters unique to the preferences of the customer. Then using the GUI at its GCSS Customer Workstation, each customer (i.e., party) and its counterparty to a credit support agreement, creates a credit support agreement report with bilateral parameters typically found in ISDA credit support agreements. The parameters of each such credit support agreement report are jointly entered into the relational database of the GCSS by a pair of authorized GCSS customers. Once entered into the system, such credit support agreement reports can be modified by the parties by way of their GCSS Customer Workstations with the agreement of the relevant counterparty, or terminated by either counterparty unilaterally.

Thereafter, the customers calculate their or their counterparty net positions or credit exposure (i.e., "mark-to-market" values) with respect their counterparties, using their current methods and algorithms. Customers then input to their GCSS Customer Workstations, their credit exposures either individually or in bulk using GCSS input screens and/or GCSS file reading mechanisms. Bulk input of credit exposures can be accomplished through the creation of a fixed format file created by the customer using a commercially available spreadsheet program. Once created, the file can then be read by the GCSS Customer Workstation and then transmitted to the GCSS Database Workstation in which the relational database is realized.

Based on the size of the credit exposure entered into the GCSS, the collateral previously transferred to the GCSS by the respective parties, the daily valuation of credit support assets within the GCSS accounts thereof, and the terms listed in the credit support agreement, the GCSS interprets the entered credit exposure figures using rule-based semantics, and then calculates whether or not additional assets are required for credit support under the credit support agreement report. The amount of assets that must be provided by one party to its counterparty to cover its credit exposure, or returned to a party from its counterparty, is displayed to the customer on the display screen of its GCSS Customer Workstation. Then during an optional period, each customer may do any one or more of things, namely: instruct GCSS by manual-actuation, which particular assets are to be provided thereby to its counterparty in order to cover its credit exposure (i.e. designation); enter a refusal to accept instruction into the GCSS, enter a decline to receive instruction into the GCSS; enter an asset freeze instruction to the GCSS; enter a specific-asset return instruction to the GCSS; and/or enter an asset substitution instruction to the GCSS. If the customer who is required to provide assets to its counterparty does not hold sufficient assets with its GCSS account to cover it outstanding credit exposure, then it may either transfer assets into its GCSS customer account by an associated clearing and settlement account, or Fedwire service.

If the customer who is required to provide assets to its counterparty does not do so manually under his or her own control within the time period allotted to do so, then the GCSS automatically enters its asset movement optimization mode. Based on the size of the net exposure, the terms of the bilateral credit support agreement report therebetween, and the unexecuted asset movement instructions issued by the counterparties up until that time period, the GCSS in the mode of operation automatically computes (using linear programming techniques) optimal asset movements among the participating counterparties to cover the outstanding credit exposures thereamong, simultaneously executes and finalizes the same in an automated manner, and thereafter notifies the GCSS counterparties of the results of the asset transfers, including the positions of the counterparties, shortfalls, excesses, etc. A primary advantage of this system functionality is that, where counterparties permit each other reuse, it allows a single asset to be reused (i.e. rehypothocated) in order to cover the credit exposure of many counterparties, and thereby ensuring optimal utilization of assets in bilateral collateralization applications.

In the event that a party has insufficient assets within its GCSS account to provide to it a counterparty, and thus cover its credit exposure therewith, the GCSS Process Server 5 or 6 notifies both parties of a shortfall of credit support assets by way of a report displayed on its GCSS Customer Workstation 8. If on the other hand, a party has transferred an excess of assets to a counterparty to cover its credit exposure therewith, then GCSS Process Server 5 or 6 automatically notifies both parties of a credit asset excess by way of a report displayed on its GCSS Customer Workstation. Thereafter, each party is given a time period within which to cure any shortfall or excess by manually-actuated function buttons emulated on the GUI of the GCSS Customer Workstation.

In the event that a counterparty does not have a GCSS account, i.e., is not a GCSS member, a GCSS member may sponsor a nonmember by creating an account within its own account hierarchy. In such a case, the GCSS member shall be solely responsible and solely authorized to enter MTMs and agreement information for the non-customer counterparty. Only GCSS customers (i.e., members) are allowed access to GCSS and their own customer accounts.

The Legal Environment for the GCSS of the Illustrative Embodiment

In the preferred embodiment of the present invention, each GCSS customer contracts with the GCSS Operator to use GCSS services and operations. Where necessary, the GCSS Operator will exploit preexisting laws on securities custody, settlement and collateralization, and if necessary, seek changes therein to construct and operate the information, storage, and processing system and method of the present invention.

In the preferred embodiment, legal and equitable title of all of the assets within the GCSS are held by the GCSS Operator, subject to a single fiduciary agreement for each customer (i.e., "the GCSS Fiduciary or Operating Agreement"). The GCSS Fiduciary Agreement allows the GCSS Operator to efficiently allocate assets from one customer to another as needed in order to meet credit support obligations thereof, while ensuring that the differing terms of the security arrangements will be individually respected. The GCSS Fiduciary Agreement will incorporate instructions for disposition of assets which can be varied to reflect different legal requirements in the customer's credit support agreement reports with its various counterparties. For example, a customer may have some New York Law agreements which create pledges under Article 8 of the New York Uniform Commercial Code, some English Law agreements requiring a transfer of credit support assets, and some English law or other charge arrangements. Thus, interests of the counterparties in the assets in the GCSS can vary according to which instructions apply in respect of each counterparty. While this is a preferred way in which to practice the present invention, it is understood that there will be different legal solutions to such problems and that such solutions will depend in part on the particular embodiment of the present invention that one wishes to practice.

Specification Of The Information Structures Comprising The Relational Database Of The Gcss Of The Present Invention

Referring to FIG. 3, the structure of the relational database of the GCSS will now be described in detail below.

As shown in the information entity model of FIG. 3, the GCSS database of comprises a number of information structures, which are interrelated by the relational links shown. For pedagogical purposes, these information structures are shown associated within five information structure groups, namely: Accounts, Agreements, Assets, Credit Support Functions, and External Asset Movements. The information structures within the Accounts Group are identified by the following information structure titles: CUSTOMER ACCOUNT; ACCESS RIGHTS PROFILE; CONTACT DETAIL; CUSTOMER ORIGINAL ASSET RULES; CUSTOMER PREFERENCE (i.e., PREFERENCE TABLES); CUSTOMER ELIGIBILITY; CUSTOMER CASH CORRESPONDENT; and MASTER. The information structures within the Agreements Group are identified by the following information structure titles: CUSTOMER CREDIT AGREEMENT; AGREEMENT ELIGIBLE COLLATERAL; AGREEMENT PREFERENCE; and COMMON CREDIT AGREEMENT. The information structures within the Assets Group are identified by the following information structure titles: OMNIBUS POSITION; ASSET TYPE; SECURITY; CURRENCY; SECURITY PRICE; FX PRICE; CASH INTEREST BALANCE; and CORPORATE ACTION. The information structures within the Credit Support Functions Group are identified by the following information structure titles: ASSET PIECE (i.e., ASSET PLEDGE); INTERNAL GCSS MOVEMENT; CUSTOMER ASSET POSITION; CREDIT EXPOSURE; and SUBSTITUTION REQUEST. The information structures within the External Movements Group are identified by the following information structure titles: EXTERNAL MOVEMENT INSTRUCTIONS; CEDCOM (i.e., a proprietary digital telecommunication system) MOVEMENT INSTRUCTION; and FED MOVEMENT INSTRUCTIONS. Below, the substructure of each of these information structures will described in detail in the order set forth above.

In FIG. 4A, the substructure of the information structure entitled CUSTOMER ACCOUNT is represented. As shown, the CUSTOMER ACCOUNT information structure comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier for this structure is the GCSS CUSTOMER NUMBER field. These information fields and information types are specified as follows: the information field entitled CUSTOMER NUMBER, stores a unique GCSS account number; the information field entitled CUSTOMER LONG NAME stores an alphanumeric character string identifying the full name of the customer; the information field entitled CUSTOMER SHORT NAME stores an alphanumeric character string identifying the short name of the customer; the information field entitled ACCOUNT STATUS stores a GCSS account status code (e.g., open, closed, default, etc.; the information field entitled MAIN GCSS ACCOUNT NUMBER stores a main account number for customers the information field entitled SWIFT ADDRESS stores an alphanumeric character string identifying the address of the customers for the purpose of receiving electronic payments; the information field entitled PARENT ACCOUNT NUMBER stores a GCSS account number of any parent account within the GCSS; the information field entitled DATE OF MEMBERSHIP stores date of membership of the customer; the information field entitled GCSS OPERATING AGREEMENT REFERENCE stores an alphanumeric character string identifying the GCSS operating agreement under which the GCSS customer account will be operated (i.e., managed); the information field entitled GCSS AGREEMENT SIGNED DATE stores date on which the GCSS operating agreement was signed by the customer; the information field entitled ADDRESS stores an alphanumeric character string identifying the address of the customer; the information field entitled CITY stores alphanumeric character string identifying the city of the customer; the information field entitled STATE stores an alphanumeric character string identifying the state of the customer; the information field entitled COUNTRY stores an alphanumeric character string identifying; the information field entitled POSTAL CODE stores an alphanumeric character string identifying the postal code of the customer; the information field entitled TELEPHONE NUMBER stores an alphanumeric character string identifying the telephone of the customer; the information field entitled FAX NUMBER stores an alphanumeric character string identifying the fax number of the customer; the information field entitled BILLING ADDRESS stores an alphanumeric character string identifying the billing address of the customer; the information field entitled GEOGRAPHIC REGION stores a country code identifying the country of the customer; the information field entitled DEFAULT HOLIDAY CALENDAR stores a default holiday calendar code which specifies a holiday table which is used by the GCSS in connection with the referenced customer account; the information field entitled ALLOW AGREEMENTS FLAG stores a flag bit which indicates whether or not the customer is allowed to create a credit support agreement; the information field entitled OPENED TIMESTAMP stores the time when the GCSS account was originally set up; the information field entitled ACCOUNT OPENED BY stores the user code identifying the user who opened the customer account; the information field entitled PUBLISHED ACCOUNT FLAG stores an indicator flag indicating whether or not the referenced account will be viewed by the GCSS customer; and the information field entitled NON-GCSS CUSTOMER FLAG stores an flag indicating whether the account is managed for a non-GCSS customer. Notably, the information fields of the CUSTOMER ACCOUNT information structure are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the primary function of this information structure is to store static information associated with each particular GCSS customer account. Each GCSS customer account can be associated with another GCSS customer account by way of a parent-child relationship. While the GCSS system automatically assigns a unique internal account number to each GCSS customer account opened within the system, the GCSS operator may also manually assign a unique mnemonic code to the GCSS customer account in order to easily describe it. Billing information associated with maintaining and servicing each GCSS customer account will be stored within a separate accounting system which is operably connected, yet independent of the GCSS.

In FIG. 4B, the substructure of the information structure entitled ACCESS RIGHTS PROFILE is represented. As shown, the ACCESS RIGHTS PROFILE information structure comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier in this structure is the concatenation of CUSTOMER NUMBER and USER NUMBER field. These information fields and information types are specified as follows: the information field entitled USER REFERENCE, stores a unique user identification number associated with the system user about which the information structure contains information concerning specified access rights within the GCSS; the information field entitled CUSTOMER NUMBER, stores the GCSS customer account number associated with the referenced user; the information field entitled SUPER USER RIGHTS, stores an flag (i.e., yes or no) indicating whether or not the referenced user has super user right within the GCSS; the information field entitled NO ACCESS RIGHTS, stores an flag (i.e., yes or no) indicating whether or not the referenced user has access rights within the GCSS; the information field entitled ABILITY TO AUTHORIZE NEW USERS, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to authorize new users within the GCSS; the information field entitled ABILITY TO ADD SUB-ACCOUNTS, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to add sub-accounts within the GCSS; the information field entitled ABILITY TO VIEW ACCOUNT, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to view customer accounts within the GCSS; the information field entitled ABILITY TO VALUE CREDIT SUPPORT, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to value credit support assets within the GCSS; the information field entitled ABILITY TO UPGRADE AGREEMENTS, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to upgrade (e.g., modify) credit support agreements within the GCSS; the information field entitled ABILITY TO RELEASE COLLATERAL, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to release collateral (assets) within the GCSS; the information field entitled ABILITY TO SEND DELIVERY INSTRUCTIONS, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to send asset delivery instructions within the GCSS; the information field entitled ABILITY TO SET MASTER CUSTOMER DATA, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to set master customer information relationships within the GCSS; the information field entitled ABILITY TO FREEZE ASSETS, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to freeze assets within the GCSS; the information field entitled ABILITY TO DEFAULT (CREDIT SUPPORT) AGREEMENT, stores an flag (i.e., yes or no) indicating whether or not the referenced user has the right to place a credit support agreement in default notification status within the GCSS; the information field entitled ID SETUP DATE, stores the date that the user was set up within the GCSS; and the information field entitled AUTHORIZED BY, stores a user identification of the person who has authorized the access rights of the referenced user within the GCSS. Notably, the information fields of the CUSTOMER ACCOUNT information structure are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the primary function of this information structure is to store information specifying the access rights of each user of the GCSS. Whenever a user attempts to use the GCSS in any way possible (e.g., by way of a GCSS Customer Workstation 8 or GCSS Workstation Server 4, 5, or 6, etc.), the system automatically checks to determine the user has been previously authorized to carry out such operations within the GCSS. In general, each GCSS customer account can have an arbitrary number of authorized users who can access and operate the account. The primary function of the ACCESS RIGHTS PROFILE information structure then is to specify the specific actions that can be carried out by each registered user. Notably, such physically implemented security measures may be distributed between the GCSS Customer Workstation and the GCSS Workstation Servers.

In FIG. 4C, the substructure of the information structure entitled CONTACT DETAIL is represented. As shown, the CONTACT DETAIL information structure comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this structure is the USER REFERENCE field. These information fields and information types are specified as follows: the information field entitled USER REFERENCE, stores a user identification for each user within the GCSS; the information field entitled USER NAME, stores an alphanumeric character string specifying the full name of the referenced user; the information field entitled CUSTOMER FLAG stores a flag which indicates whether or not the named user is a GCSS customer rather than a GCSS operator in order to control the information that the user is authorized to access; the information field entitled TYPE stores an alphanumeric character string specifying the type of user (e.g., Customer user, GCSS operations user, or GCSS process user); the information field entitled FAX, stores an alphanumeric character string specifying the fax number of the referenced user; the information field entitled PHONE, stores an alphanumeric character string specifying the phone number of the referenced user; the information field entitled TITLE, stores an alphanumeric character string specifying the title of the user within the organization of the customer with which the user is associated; and the information field entitled TELEX, stores an alphanumeric character string specifying the telex number of the referenced user. Notably, the information fields of the CONTACT DETAIL information structure are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. Whereas the ACCESS RIGHTS PROFILE information structure stores information specifying which customer accounts a particular user may work with, and in what mode of operation, the CONTACT DETAIL information structure stores information concerning personal details of each authorized GCSS user. In addition, this information structure contains information specifying how each such user may be contacted by various communication mediums.

In FIG. 4D, the substructure of the information structure entitled CUSTOMER ORIGINAL ASSET RULES is represented. As shown, the information structure CUSTOMER ORIGINAL ASSET RULES comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this structure is the CUSTOMER ACCOUNT and ASSET TYPE fields. These information fields and information types are specified as follows: the information field entitled CUSTOMER ACCOUNT, stores a GCSS customer account number to which the below listed asset rules apply; the information field entitled ASSET TYPE, stores an asset type code indicative of the type of the referenced asset; the information field entitled STANDARD VALUATION PERCENTAGE (i.e., HAIRCUT), stores a numerical value indicative of the valuation percentage of the asset type; the information field entitled DELIVERY SYSTEM, stores a delivery system code indicative of the type of delivery system which will be used to deliver the original asset into the GCSS; the information field entitled CLEARING AND SETTLEMENT SYSTEM (e.g;., LCS) ACCOUNT NUMBER, stores the principle trading account number of the GCSS lending, clearing and settlement (LCS) system; the information field entitled FOR ACCOUNT OF, stores text identifying the custodian account (e.g., Cedel, LCS, or outside GCSS). The outgoing asset should be sent and is incorporated into the External Movement Instructions relating to that asset; the information field entitled IN FAVOR OF, stores text identifying the owner of the GCSS account; and is incorporated into the External Movement Instructions relating to that asset. Notably, the information fields of the information structure CUSTOMER ORIGINAL ASSET RULES are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the CUSTOMER ORIGINAL ASSET RULES information structure is used to provide two functions, namely: to specify, for each asset type, where outside of the GCSS the asset should be default delivered; and to specify an approximate valuation of the assets independent of credit support agreements. The asset rules for cash is specified in greater detail in the CUSTOMER CASH CORRESPONDENT information structure.

In FIG. 4E, the substructure of the information structure entitled CUSTOMER PREFERENCE is represented. As shown, the information structure CUSTOMER PREFERENCE comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this structure is the concatenation of the CUSTOMER NUMBER, ASSET IDENTIFIER, and ASSET TYPE fields. These information fields and information types are specified as follows: the information field entitled CUSTOMER NUMBER, stores the GCSS account number assigned to the identified customer; the information field entitled ASSET TYPE, stores an asset type code indicative of asset type; information field entitled ASSET IDENTIFIER, stores an asset identifier indicative of the identity of the asset; the information field entitled USAGE PRIORITY, stores a numerical value indicative of the usage priority assigned to the asset (e.g., U.S. Treasuries 6, Eurobonds 4, etc), used in the Asset Movement Optimization Process and the COVER NOW process C680; the information field entitled HOLD ASSET FLAG, stores an flag which indicates whether or not the customer has frozen any particularly identified asset. Notably, the information fields of the information structure CUSTOMER PREFERENCE are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the CUSTOMER PREFERENCE information structure allows the customer to specify for each asset class (i.e., security type), or at a lower level specific security, (i) the order in which the customer wants the security used to cover credit exposure, all things being equal, and (ii) the securities can be overridden by the Agreement Preference Parameters the customer would like to hold onto.

In FIG. 4F, the substructure of the information structure entitled CUSTOMER ELIGIBILITY is represented. As shown, the information structure CUSTOMER ELIGIBILITY comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this information structure is identified in the upper fields of this figure. These information fields and information types are specified as follows: the information field entitled CUSTOMER NUMBER stores the GCSS customer number assigned to the customer at the time of opening the account; the information field entitled ASSET TYPE CODE, stores the asset type code assigned to the referenced asset; the information field entitled ASSET IDENTIFIER, stores an asset identifier code; the information field entitled valuation percentage stores the valuation that will be applied when computing the value of the asset (e.g., 100 implies field market valuation of security; 95 implies a 5% haircut); the information field entitled ACCEPT ASSET FLAG, stores a flag (i.e., yes/no) which indicates which whether or not the customer will accept the referenced asset type as collateral; the information field entitled ACCEPT ON-TRANSFER FLAG, stores a flag (i.e., yes/no) which indicates which whether or not the customer will allow any acquired asset of the referenced asset type to be on-transferred (i.e., rehypothocated); the information field entitled ALLOW ON-TRANSFER ORIGINAL ONLY, stores a flag (i.e., yes/no) which indicates which whether or not the customer will allow only original assets of the referenced asset type to be rehypothocated; the information field entitled ALLOW ON-TRANSFER ALL, stores a flag (i.e., yes/no) which indicates which whether or not the customer will allow all assets, original or acquired, of the referenced asset type to be rehypothocated; the information field entitled ALLOW REPO ORIGINAL ONLY, stores a flag (i.e., yes/no) which indicates which whether or not the customer will allow only original assets of the referenced asset type to be repoed (i.e., repurchased); and the information field entitled ALLOW REPO ALL FLAG, stores a flag (i.e., yes/no) which indicates which whether or not the customer will allow all assets of the referenced asset type to be repoed. Notably, the information fields of the information structure CUSTOMER ELIGIBILITY are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the CUSTOMER ELIGIBILITY information structure allows the customer to determine which assets it is willing to accept as collateral by a counterparty covering its credit exposure. The information in this structure creates default eligibility tables are used in setting up new credit support agreement. Notably, while multiple flags used in the illustrative embodiment to control the re-use of an asset in a particular situation, it is possible to use a single flag for asset re-use control. Also, this customer eligibility table is used when setting up a new credit support agreement. When the agreement is modified, the agreement eligibility table will override the customer eligibility table.

In FIG. 4G, the substructure of the information structure entitled CUSTOMER CASH CORRESPONDENT is represented. As shown, the information structure CUSTOMER CASH CORRESPONDENT comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. These information fields and information types are specified as follows: the information field entitled CUSTOMER ACCOUNT stores the GCSS customer number assigned to the customer; the information field entitled CURRENCY CODE stores the currency code assigned to the referenced currency; the information field entitled PAY TO stores an alphanumeric character string indicative of the party to whom the cash should be paid; the information field entitled CASH ACCOUNT stores an alphanumeric character string indicative of the account to which the cash will be sent upon the cash being released using an external movement instruction (i.e., moved outside GCSS); the information field entitled PAYMENT IN FAVOR stores an alphanumeric character string indicative of the underlying customer. Notably, the information fields of the information structure CUSTOMER CASH CORRESPONDENT are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the CUSTOMER CASH CORRESPONDENT information structure defines per currency type, the cash correspondent and account that the customer wishes to use when moving excess (i.e., surplus) cash out of the GCSS. Notably, such excess cash need not be an original asset.

In FIG. 4H, the substructure of the information structure entitled MASTER is represented. As shown, the information structure MASTER comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this information structure is identified in the upper fields of this figure. These information fields and information types are specified as follows: the information field COMPANY FULL NAME stores an alphanumeric string indicative of the full name of the GCSS operator which will be displayed on display screen of GCSS display terminals whenever it is necessary to do so; the information field COMPANY SHORT NAME stores the information field SYSTEM DATE stores an alphanumeric string indicative of the short name of the company (i.e., customer; the information field OPTIMIZATION RUNNING FLAG stores a flag which indicates whether the Asset Movement Optimization Process of the present invention is running; the information field TIMEZONE INDICATOR stores a time zone indicative of the time zone code (e.g., America, Asia, Europe) currently being processed; the information field entitled SYSTEM DATE stores the date that GCSS is current operating in conformity with GCSS calendar table; the information field entitled OPTIMIZATION START TIMESTAMP stores the timestamp of when the optimization cycle of the GCSS begins; the information field OPTIMIZATION END TIMESTAMP stores the timestamp of when the optimization cycle of the GCSS ends; the information field OMNIBUS ACCOUNT stores the omnibus account number of the GCSS inside the LCS system. Notably, the information fields of the information structure MASTER are not interrelated with any information structures shown in the information entity model of FIG. 3. In general, the information contained in the MASTER information structure specifies system information that can apply. Thus this information structure could in theory stand by itself, or with any other information structure group indicated in the information entity model.

In FIG. 5A, the substructure of the information structure entitled CUSTOMER CREDIT AGREEMENT is represented. As shown, the information structure CUSTOMER CREDIT AGREEMENT comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this information structure is identified in the upper fields of this figure. These information fields and information types are specified as follows: the information field entitled GCSS AGREEMENT NUMBER stores the number automatically assigned by the GCSS to the credit support agreement report; the information field entitled CUSTOMER NUMBER stores the GCSS account numbers of the customer who is a counterparty to the credit support agreement report; the information field entitled VERSION NUMBER stores the version number of the credit support agreement; the information field entitled CUSTOMER ONE OR TWO stores a number indicative of the number assigned to the customer by both parties to the credit support agreement; the information field entitled CUSTOMER INTERNAL AGREEMENT NUMBER stores the internal agreement number assigned to the credit support agreement by the customer; the information field entitled INDEPENDENT AMOUNT stores an amount of credit support assets that one party must provide to a secured counterparty, independent of the Basic Amount and in addition to the computed Credit Support Amount; the information field entitled INDEPENDENT AMOUNT CURRENCY stores the currency code indicative of the currency in which the Independent Amount is valued; the information field entitled THRESHOLD AMOUNT stores the credit support amount below which no credit support assets are provided; the information field entitled THRESHOLD CURRENCY stores the currency code indicative of the currency in which the Threshold Amount is valued; the information field entitled MINIMUM TRANSFER AMOUNT stores the minimum amount of computed credit support assets which will necessitate the provision of a return or delivery which will trigger a delivery obligation; the information field entitled MINIMUM TRANSFER CURRENCY stores the currency code indicative of the currency in which the Minimum Transfer Amount is valued; the information field entitled ROUNDUP VALUE stores the amount by which Delivery Amounts and Return Amounts are rounded; the information field entitled ROUNDUP VALUE CURRENCY stores the currency code indicative of the currency in which the Roundup Value is valued; the information field entitled ROUNDUP AMOUNT stores the Roundup amount using in the rounding of the computed Delivery and Return Amounts; the information field entitled ROUNDUP AMOUNT CURRENCY stores the currency in which the Roundup Amount is valued; the information field entitled BASIC AMOUNT stores the Basic Amount with respect to a counterparty, representative of the value of Credit Support Assets which are required to be provided and constantly held from its counterparty, independent of the Credit Support Amount; the information field entitled BASIC AMOUNT CURRENCY stores the currency code indicative of the currency in which the Basic Amount is valued; the information field entitled ROUNDUP TYPE stores a choice of three methods of rounding computed Delivery and Return Amounts; the information field entitled HOLIDAY CALENDAR stores the choice of holiday calendar(s) applicable to the referenced credit support agreement; the information field entitled THRESHOLD CALCULATION METHOD stores a code which indicates the threshold calculation method (e.g., A or B disclosed herein) which by agreement is to be used to compute the Credit Support Amount for the referenced credit support agreement; the information field entitled ALLOW REPO FLAG stores a flag which indicates whether or not the assets held by the counterparties to the referenced credit support agreement can be repurchased (i.e., repoed); the information field entitled ALLOW ON-TRANSFER FLAG stores a flag which indicates whether or not the assets held by the counterparties to the referenced credit support agreement can be transferred on to other customers as collateral; the information field entitled INDEPENDENT AMOUNT NET FLAG stores a flag which indicates whether or not the Independent Amount will be netted within the credit exposures entered into the GCSS by the counterparties to the referenced credit support agreement; the information field entitled SUM INDEPENDENT AND BASIC AMOUNT FLAG stores a flag which indicates whether or not the Independent Amount and the Basic Amount are to be summed by the counterparties to the referenced credit support agreement when determining the Credit Support Amount; the information field entitled ENTRY DATE stores the date on which the referenced credit support agreement was entered into by the counterparties; the information field entitled ENTERED BY stores the identification of the GCSS users who entered the customers into the credit support agreement; the information field entitled LAST MODIFIED DATE stores the date on which the referenced credit support agreement was last modified; the information field entitled LAST MODIFIED BY stores identification of the GCSS user who has modified the referenced the last modified credit support agreement; the information field entitled APPROVED TIMESTAMP stores the date of the timestamp approving the referenced credit support agreement; the information field entitled APPROVED BY stores the identification of the GCSS user who approved the referenced credit support agreement; and the information field entitled ONE WAY COVERAGE FLAG stores a flag indicative of whether or not the referenced customer has instructed the GCSS not to deliver or return assets in its GCSS account to the counterparty. Notably, the information fields of the information structure CUSTOMER CREDIT AGREEMENT are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the CUSTOMER CREDIT AGREEMENT information structure stores information (i.e., bilaterally agreed upon parameters) which is specific to each of the two GCSS customers associated with a specific credit support agreement. As indicated above, counterparties to a credit support agreement may change or modify the agreement over the life of the agreement by generating a new version thereof. This can be accomplished using the GCSS Customer Workstations of the GCSS.

In FIG. 5B, the substructure of the information structure entitled AGREEMENT ELIGIBLE COLLATERAL is represented. As shown, the information structure AGREEMENT ELIGIBLE COLLATERAL, commonly referred to as the "Eligibility Table", comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this information structure is identified in the upper fields of this figure. These information fields and information types are specified as follows: the information field entitled CUSTOMER AGREEMENT NUMBER stores the customer agreement number assigned to the referenced customer credit agreement; the information field entitled CUSTOMER NUMBER stores the GCSS customer number assigned (by the GCSS) to the specified GCSS customer of the referenced customer credit support agreement; the information field entitled VERSION NUMBER stores the version number of the customer credit support agreement; the information field entitled ASSET TYPE CODE stores the asset type code of the asset referenced to the customer credit support agreement; the information field entitled ASSET IDENTIFIER stores the asset identifier (e.g., ISIN) which uniquely identifies the referenced asset; the information field entitled VALUATION PERCENTAGE stores the valuation that will be applied when computing the value of the asset (e.g., 100 implies full market value of security, 95 implies a 5% haircut) is received from the counterparty of the referenced agreement; the information field entitled ACCEPT ASSET FLAG stores a flag which indicates whether or not the referenced asset will accepted as collateral by the GCSS customer to the GCSS agreement; the information field entitled ACCEPT ON-TRANSFER FLAG stores a flag which indicates whether or not the specified GCSS customer will accept the transfer of the referenced asset from a counterparty to cover credit exposure therebetween; and the information field entitled ALLOW ON-TRANSFER ORIGINAL ONLY stores a flag which indicates whether or not the specified GCSS customer will only on-transfer its original asset to its counterparty to cover credit exposure therebetween; the information field entitled ALLOW ONTRANSFER ALL stores a flag which indicates whether or not the specified GCSS customer will on-transfer all of its assets (i.e., original and received assets) to its counterparty to cover credit exposure therebetween; the information field entitled ALLOW REPO ORIGINAL ONLY stores a flag which indicates whether or not the specified GCSS customer will only repo (i.e., repurchase) its original assets; and the information field entitled ALLOW REPO ALL FLAG stores a flag which indicates whether or not the specified GCSS customer will repo (i.e. repurchase) all of its assets. Notably, the information fields of the information structure AGREEMENT ELIGIBLE COLLATERAL are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the AGREEMENT ELIGIBLE COLLATERAL information structure overrides the customer-level eligible collateral, and applies to one credit support agreement with a counterparty. In essence, the information structure entitled AGREEMENT ELIGIBLE COLLATERAL specifies which assets a customer is willing to accept and at what valuation percentage (i.e., haircut). Collateral eligibility can be defined at either: a specific asset level, e.g., U.S. dollars, Gilt 8.5% Maturity 23 Jun. 1998, in which case this overrides asset type below if an asset is specifically mentioned; or asset type, e.g., U.S. treasury, Cash, etc. This information is used when covering a credit exposure (i.e., by manual or automated asset movement) and when calculating the value of coverage. Notably, in applications where a single re-use flag is employed, the corresponding on-transfer and repo-related flags will be replaced with a single re-use flag in this information structure.

In FIG. 5C, the substructure of the information structure entitled AGREEMENT PREFERENCE is represented. As shown, the information structure AGREEMENT PREFERENCE, commonly referred to as "Preference Table" comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this information structure is identified in the upper fields of this figure. These information fields and information types are specified as follows: the information field entitled VERSION NUMBER stores the version number of the credit support agreement being referenced; the information field entitled CUSTOMER CREDIT AGREEMENT NUMBER stores the credit support agreement number assigned to the referenced credit support agreement; the information field entitled CUSTOMER stores the GCSS account number of the GCSS customer to whom the Agreement Preferences apply; the information field entitled ASSET NUMBER stores an asset type code that corresponds to the credit support asset; the information field entitled ASSET TYPE stores the asset type code of the asset being referenced; the information field entitled ASSET IDENTIFIER stores an asset identifier indicative of the identity of the referenced asset; and the information field entitled USAGE PRIORITY stores a usage priority number assigned to the referenced asset. Notably, the information fields of the information structure AGREEMENT PREFERENCE are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the AGREEMENT PREFERENCE information structure allows a customer to control which assets are preferentially used to cover a credit exposure for a specific credit support agreement. Notably, the parameters in this agreement preference overrides any preference parameters set at the customer level in this table. Also, since it is not part of the contractual credit support agreement, these parameters can be changed at any time at the discretion of the GCSS customer. In the illustrative embodiment, the parameters in this structure are not viewable by one's counterparty as such parameters typically constitute confidential information.

In FIG. 5D, the substructure of the information structure entitled COMMON CREDIT AGREEMENT is represented. As shown, the information structure COMMON CREDIT AGREEMENT comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled GCSS CREDIT AGREEMENT REFERENCE NUMBER stores the GCSS Credit Agreement Number assigned to the agreement by the GCSS; the information field entitled VERSION NUMBER stores the version number of the credit support agreement; the information field entitled AGREEMENT STATUS CODE stores the status code indicative of the status of the agreement (e.g., open, closed, etc.); the information field entitled COUNTERPARTY 1 stores the name of the customer who is designated as Counterparty No. 1 for purposes of the agreement; the information field entitled COUNTERPARTY 2 stores the name of the customer who is designated as Counterparty No. 2 for purposes of the agreement; the information field entitled CREDIT AGREEMENT DATE stores the date on which the agreement was made effective; the information field entitled REVIEW DATE stores the date on which the credit support agreement to be reviewed by the counterparties; the information field entitled CALCULATION AGENT stores the GCSS account number of the counterparty who is responsible for calculating MTM figure for both computations in particular structure where single entry credit exposure is to occur pursuant to the underlying credit support agreement; the information field entitled FREQUENCY CREDIT EXPOSURE stores a frequency code indicative of the frequency (e.g., daily, weekly, monthly, etc.) of credit exposure processing that is to be carried out by the GCS Processing Cycle under the credit support agreement; the information field entitled DATE OF NEXT CREDIT EXPOSURE stores the date of the next GCS Processing Cycle in which the referenced credit support agreement will be involved; the information field entitled CURRENCY CREDIT EXPOSURE stores the currency code in which credit exposures are to be entered into and valued by the GCSS by the parties; the information field entitled VALUE BY AGREED AMOUNT FLAG stores a flag which indicates whether or not the counterparties have agreed upon an Agreed Amount in connection with credit support asset computations carried out by the GCSS; the information field entitled OPTIMIZATION TIME PERIOD stores the time-zone code identifying an optimization time period during which the Asset Movement Optimization Process hereof is to be carried out in order to cover credit exposures of the counterparties under the credit support agreement; the information field entitled UNDERLYING PORTFOLIO stores an underlying portfolio code which identifies the type of translation which the agreement will support (e.g., interest rate derivatives, equity derivatives, FX transactions, undisclosed, etc.); the information field entitled DELIVERY TIME DAYS stores a number which indicates the number of days in which a counterparty must deliver required assets to its counterparty as computed by the GCSS in order to cover outstanding credit exposures; the information field entitled RETURN TIME DAYS stores a number which indicates the number of days in which a party to the agreement must return required assets to its counterparty as computed by the GCSS; and the information field entitled EFFECTIVE DATE VERSION START stores the effective date on which the referenced version of the credit support agreement will begin. Notably, the information fields of the information structure COMMON CREDIT AGREEMENT are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the information contained in the COMMON CREDIT AGREEMENT information structure stores agreement information (e.g., bilateral parameters) common to both parties of the credit support agreement. As indicated above, this information storage structure contains information identifying the counterparties to the referenced agreement; processing parameters related to the Asset Movement Optimization Process, and control parameters relating to the identity of the user who last effected a change to the credit support agreement. Each version of a particular credit support agreement stored in the relational database of the GCSS, is referenced to the original agreement. While credit support agreement has two counterparties, and normally refers to many derivative transactions, it could, at the discretion of the parties, be structured for a single transaction. In the illustrative embodiment, the GCSS is designed to support credit support agreements where one of the counterparties is a full member (i.e., customer) of the GCSS, while the other counterparty is not. In this case, the non-member will be set up as a sub-account of the full member and the full member will set up the credit support agreement in its name. The agreement management mechanisms provided by the GCSS will operate as normal, although it is likely that the full member will set up the agreement so that all of the securities used to cover credit exposures between such counterparties, remain in his account. Notably, the GCSS requires information details of the underlying transactions which the GCSS supports.

In FIG. 6A, the substructure of the information structure entitled OMNIBUS POSITION is represented. As shown, the information structure OMNIBUS POSITION comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled DATE OF BALANCE stores date indicative of the balance of the assets maintained within the omnibus account; the information field entitled ASSET IDENTIFIER stores the asset identifiers of all of the assets maintained within the omnibus account; the information field entitled NOMINAL AMOUNT stores the nominal amount (i.e., value) of assets maintained within the omnibus account; the information field entitled BALANCE RECONCILED FLAG stores a flag which indicates whether or not the balance of assets in the Omnibus Account has been reconciled with the balance of assets in the LCS system, as of the referenced Date of Balance. Notably, the information fields of the information structure OMNIBUS POSITION are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the OMNIBUS POSITION information structure stores the aggregate balance of all of the assets maintained in the Omnibus Account customers. This information is updated periodically by (i) the LCS system using CEDCOM movement instructions and (ii) the result of corporate actions which are also implemented by CEDCOM Movement Instructions. In the illustrative embodiment, this Omnibus Account is managed by a sole fiduciary (i.e., GCSS operator). On a daily basis, the information structure entitled OMNIBUS POSITION is populated with "asset positions" which specifies information obtained directly from LCS system. As discussed above, the function of the LCS system is to maintain custody of all GCSS customer assets registered with the GCSS, whereas the GCSS manages the allocation of interests in such assets among its customers to cover credit exposure obligations as hereinbefore described. The OMNIBUS POSITION information structure stores both security balances and cash balances, as conventionally maintained in a normal customer account of an asset custody system, such as the Cedel LCS system. Using normal instructions employed in the LCS asset custody system, securities will be effectively moved to and from the GCSS Accounts in the GCSS. Notably, information regarding ownership of the assets accounted for in the OMNIBUS POSITION information structure, and thus the right to use the same to cover credit exposures, is maintained within the LCS (sub)system of the GCSS. Details regarding the movement of assets into and out of GCSS Accounts are described in the Information Processes Section hereof.

In FIG. 6B, the substructure of the information structure entitled ASSET is represented. As shown, the information structure ASSET comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled ASSET IDENTIFIER stores tile asset identifier (e.g., common code) of each eligible asset maintained delivered to the GCSS for use in covering credit exposure among parties to credit support agreements; and the information field entitled ASSET TYPE stores the asset type code for each such asset maintained within this GCSS. Notably, the information fields of the information structure ASSET are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, this information structure stores static information pertaining to each particular asset delivered to the GCSS either for use in credit support (i.e., recorded in the GCSS accounts) or likely to be used at some future date. The assets represented by the information within this structure can be either cash or securities. However, each asset must be eligible according to credit support agreements maintained within the system. As will become apparent hereinafter with reference to the information processes of the GCSS, the primary function of the ASSET information structure is to describe each of the potential individual asset lines that may be brought into the system.

In FIG. 6C, the substructure of the information structure entitled ASSET TYPE is represented. As shown, the information structure ASSET TYPE comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled ASSET TYPE stores the asset identifier (e.g., ISSN) of each eligible asset maintained in GCSS; the information field entitled LONG NAME stores the long name assigned to the referenced asset; the information field entitled PARENT ASSET TYPE CODE stores the asset type code assigned to the parent asset to which the referenced asset is related, if related to any such parent asset type; and the information field entitled SHORT NAME stores the short name assigned to the referenced asset type. Notably, the information fields of the information structure ASSET are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the primary function of the ASSET TYPE information structure is to classify the assets within the GCSS, and is used in combination with eligibility and preference parameters to construe credit support processing.

In FIG. 6D, the substructure of the information structure entitled SECURITY is represented. As shown, the information structure SECURITY comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled SECURITY CODE stores the security code (i.e., ISIN or CUSIP) of each eligible asset that will be or is expected to be used in the GCSS; the information field entitled ISIN CODE stores ISIN code of each eligible asset (i.e., security) that will be or is expected to be used in the GCSS; the information field entitled DOMESTIC SECURITY CODE stores domestic security code (i.e., CUSIP) of each eligible asset; the information field entitled SHORT DESCRIPTION stores the short name given to each eligible security; the information field entitled LONG DESCRIPTION stores the long name given to each eligible security; the information field entitled NOMINAL CURRENCY stores the currency code of the underlying security; the information field entitled MINIMUM DENOMINATION stores the minimum multiple of the referenced security that can be moved; the information field entitled COUPON RATE stores the rate at which interest or dividends are paid on each security; the information field entitled COUPON CURRENCY CODE stores the currency code in which the coupon is to be paid on the security; the information field entitled MATURITY DATE stores the maturity date of each security; the information field entitled MATURITY CURRENCY CODE stores the currency code of the currency in which the principal of the referenced security is redeemed; the information field entitled CUSTODY SYSTEM (i.e., CEDEL) DEPOSITORY CODE stores the depository code assigned to the depository (i.e., custodian) in which each referenced security is deposited in the LSC System; the information field entitled SECURITY CONVERTIBILITY CODE stores an internal classification code used by the GCSS operator to classify the referenced security; the information field entitled CLOSING DATE stores the closing date, which is the date that the security is initially available for trading after it is launched as a new issue; the information field entitled DISTRIBUTION DATE stores the date on which the security is allocated (i.e., distributed) to members of the syndication group that initially bought the security issue; the information field entitled DELIVERY CODE stores a user-invisible delivery code that is used to further classify the asset to which it refers as well as control how the asset can be settled; the information field entitled BRIDGE ELIGIBLE FLAG stores a flag indicating whether or not the security can be transferred across the settlement bridge with the Euroclear system; the information field entitled SECURITY ACTIVE FLAG stores a flag which indicates whether or not the security can be used in the GCSS; the information field entitled GCSS ASSET TYPE CODE stores the GCSS asset type code assigned to each security; the information field entitled GEOGRAPHICAL SECTOR stores a country reference to the issuer of the security; the information field entitled INDUSTRY CODE ISSUER stores the industry code, which indicates the professional sector that the issuer of the security is engaged in; the information field entitled RATING SP stores the security rating accorded to the referenced security by Standard and Poor; the information field entitled RATING MOODY stores security rating accorded to the referenced security by Moody; the information field entitled RATING MIKUNI stores security rating accorded to the referenced security by Mikuni; the information field entitled RATING CUSTODY/DEPOSITORY SYSTEM (i.e., CEDEL LCS SYSTEM) stores security rating accorded to the referenced security by the operator of the LCS System; the information field entitled GCSS ASSET RATING stores security rating accorded to the referenced security by GCSS; the information field entitled GCSS ASSET FLAG stores a flag which indicates whether or not the security will be used in the GCSS as a GCSS asset; and if yes, then it will be priced and made viewable by customers; and the information field entitled LAST UPDATED TIMESTAMP stores the time when the SECURITY information structure was last updated (i.e., maintained). Notably, the information fields of the information structure SECURITY are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the primary function of the SECURITY information structure is to define (i) the characteristics of the securities which may be used in the GCSS as credit support assets, and (ii) provide securific specific information which is required in credit support processing. On a daily basis, many information items in this structure will be synchronized with corresponding information in the latest updated version of LCS system.

In FIG. 6E, the substructure of the information structure entitled CURRENCY is represented. As shown, the information structure CURRENCY comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled ISO CURRENCY CODE stores the ISO currency code assigned to each referenced currency utilizable in the GCSS; the information field entitled DESCRIPTION stores a brief description of each of the referenced currencies utilizable in the GCSS; and the information field entitled HOME COUNTRY CODE stores the country code of each of the respective currencies in the GCSS. Notably, the information fields of the information structure CURRENCY are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the primary function of the CURRENCY information structure is to specify the various monetary currencies that the GCSS will accept. This information structure contains static information associated with these cash currencies, which specifies the characteristics thereof.

In FIG. 6F, the substructure of the information structure entitled SECURITY PRICE is represented. As shown, the information structure SECURITY PRICE comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled SECURITY CODE stores the security codes (i.e., ISIN) used to identify the various securities utilizable within the GCSS; the information field entitled VALUATION DATE stores the date on which the price of a security has been valuated; the information field entitled PRICE stores the valuated price of each security in the GCSS; the information field entitled PRICE TYPE CODE stores the price type code of each valuated security; the information field entitled CURRENCY stores the currency code of the currency in which the price of a particular security is evaluated; and the information field entitled SOURCE USER IDENTIFICATION stores the identification of the user who updated the referenced price. Notably, the information fields of the information structure SECURITY PRICE are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3. In general, the primary function of the SECURITY PRICE information structure is to store current price information of each security asset utilizable within the GCSS, as well as a price history thereof.

In FIG. 6G, the substructure of the information structure entitled FX RATE is represented. As shown, the information structure FX RATE comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled CURRENCY CODE stores the currency code for each FX rate (i.e., cross-exchange rate from a particular currency to U.S. dollars); the information field entitled DATE stores the date of each exchange rate; and the information field entitled EXCHANGE RATE TO USD stores the exchange rate for the referenced currency. Notably, the information fields of the information structure FX RATE are interrelated with the information structure entitled CURRENCY indicated by the relational link shown in the information entity model of FIG. 3. In general, the primary function of the FX RATE information structure is to store the daily FX rate for each currency utilizable as collateral within the GCSS. The FX rate is used to value assets within the GCSS by converting their value to U.S. dollars (i.e., USD).

In FIG. 6H, the substructure of the information structure entitled CORPORATE ACTION is represented. As shown, the information structure CORPORATE ACTION comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. These information fields and information types are specified as follows: the information field entitled CORPORATE ACTION IDENTIFICATION stores a token identifier to identify each particular corporate action detected by the GCSS; the information field entitled SECURITY CODE stores the security code which identifies the associated security to its respective corporate action; the information field entitled EVENT TYPE CODE stores the corporate action event type code which identifies the type of event that the corporate action represent (e.g., coupon, redemption, stock split, right to offering, etc.); the information field entitled EVENT STATUS CODE stores corporate action event status code assigned to referenced corporate action; the information field entitled RECORD DATE stores the record date of the corporate action; the information field entitled PAYMENT DATE stores the payment date associated corporate action; the information field entitled NOMINAL BASIS stores a numerical value used when calculating the proceeds of corporate action entitlements (i.e., the Amount Paid to customer equals ›Customer Position Balance!.times.›Amount Paid Per Nominal Basis! divided by ›Nominal Basis!); the information field entitled AMOUNT PAID PER NOMINAL BASIS stores the amount paid per Nominal Basis (see above); the information field entitled CURRENCY OF PAYMENT stores The currency code of the payment made; the information field entitled TOTAL AMOUNT PAID TO GCSS stores the amount paid to the GCSS by LCS for the referenced corporate action; the information field entitled TOTAL AMOUNT DISTRIBUTED BY GCSS stores the amount distributed by the GCSS to customer with respect to the referenced corporate action; the information field entitled INTERNAL COMMENTS stores the internal comments associated with the Corporate Action, which are not reviewable by customers; and the information field entitled EXTERNAL COMMENTS stores external comments associated with the corporate action, which are reviewable by customers. Notably, the information fields of the information structure CORPORATE ACTION are interrelated with the information structure entitled SECURITY indicated by the relational link shown in the information entity model of FIG. 3. In general, the function of the CORPORATE ACTION information structure is to monitor and record corporate actions in order to support the distribution of entitlements (e.g., voting rights) or proceeds (e.g., income) derived from or associated with any corporate action associated with an asset maintained within the GCSS. While an asset may be transferred from one party to another party in the GCSS, the proceeds are distributed to the original asset holder (i.e., the customer originally placing the asset in the GCSS). Typically, such proceeds are in the form of coupon payments, and redemptions, but may also be in the form of bond defaults, name changes, and other corporate events. In the illustrative embodiment, such proceeds are distributed to the customer who originally placed the asset within the GCSS. The balance information indicative of such proceeds is stored in the CUSTOMER ASSET POSITION information structure, which will be described in detail below.

In FIG. 6I, the substructure of the information structure entitled CASH INTEREST BALANCE is represented. As shown, the information structure CASH INTEREST BALANCE comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled CURRENCY CODE stores the currency code for each cash asset held by the respective customers as collateral to cover outstanding credit exposure between counterparties to a credit exposure agreement; the information field entitled BALANCE DATE stores the date of each cash interest balance maintained in the information structure; the information field entitled BALANCE AMOUNT stores the amount of each cash interest balance maintained in the information structure; the information field entitled CREDIT INTEREST RATE stores the rate at which interest is computed for cash credit balances; the information field entitled CREDIT INTEREST PAID stores the amount of cash interest paid to holder of cash debit balances in the referenced currency; the information field entitled DEBIT INTEREST RATE stores the rate at which cash interest is computed for cash overdrafts in the referenced currency; the information field entitled DEBIT INTEREST PAID stores the amount of cash interest due to GCSS by customers overdrawn in the referenced currency; and the information field entitled INTEREST DISTRIBUTED IN GCSS stores the amount of cash interest distributed in total to each GCSS customer. Notably, the information fields of the information structure CASH INTEREST BALANCE are interrelated with the information structure entitled CURRENCY indicated by the relational link shown in the information entity model of FIG. 3. In general, the function of the CASH INTEREST BALANCE information structure is to store interest payment information relating to cash balances in the Omnibus Account, and to subsequently distribute such interest payments to the cash holders indicated in the records of the GCSS Accounts, as deemed appropriate. In the illustrative embodiment, entries regarding cash interest produced from cash balances maintained in the Omnibus Account are computed in the respective currency and entered into the CASH INTEREST BALANCE information structure. Thereafter, the GCSS should pay such interest to those who hold cash (in their GCSS Accounts) as collateral after asset movement (e.g., pledging) as occurred, and not to the original customer who delivered the cash into the GCSS. Preferably, the interest is computed at the internal rate of the LCS system, and is distributed monthly by the GCSS according to the cash balances indicated in the CASH INTEREST BALANCE information structure. The information stored in this structure (i.e., table) is used to produce monthly statements affecting interest paid and received in a particular currency.

In FIG. 7A, the substructure of the information structure entitled ASSET PIECE is represented. As shown, the information structure ASSET PIECE, commonly called "Asset Piece Table", comprises a plurality of distinct information fields, each of which is specified by its information field title and the type of information which it contains. The Prime identifier of this information structure is identified in the upper field of this figure. These information fields and information types are specified as follows: the information field entitled PIECE IDENTIFICATION stores a token identifier for each asset piece in the GCSS; the information field entitled ASSET IDENTIFIER stores an asset identifier for the referenced asset piece; the information field entitled BALANCE CODE stores the balance code for each referenced asset piece which describes what the referenced asset piece is used for (e.g., original asset, pledged asset, repo'ed out, etc.); the information field entitled CONTROLLED NOMINAL AMOUNT stores the nominal amount of each referenced asset piece, which is used to compute its value by multiplying the current price (i.e., security price or FX Rate) by the valuation percentage (i.e., from applicable preference table); the information field entitled CURRENT NOMINAL AMOUNT stores the nominal amount of the referenced asset piece which is currently held (i.e., recorded) in the CONTROL GCSS ACCOUNT, described below; the information field entitled AGREEMENT REFERENCE stores the credit support agreement number to which each asset piece in the GCSS is referenced (i.e., if this field is empty, then the referenced asset piece refers to an original piece); the information field entitled CONTROL GCSS ACCOUNT stores the GCSS account number of the GCSS customer who holds the referenced asset piece as either an original asset, as collateral, etc.; the information field entitled PREVIOUS GCSS ACCOUNT stores the GCSS account number of the previous GCSS customer who held the referenced asset piece (i.e., if this field is empty, then the referenced asset piece is under full control of the CONTROL GCSS ACCOUNT); the information field entitled START DATE stores the date on which the referenced asset piece was transferred to cover a credit exposure; the information field entitled RETURN DATE stores the date on which the referenced asset piece should to be returned to the previous customer holding the asset piece (i.e., for a subsequent sale, or other use contemplated by its previous holder); the information field entitled ACTUAL END DATE stores the date on which the referenced asset piece was actually returned to the previous holder; the information field entitled ON TRANS FLAG stores a flag which indicates whether or not the referenced asset piece, when received as collateral from one counterparty can be subsequently transferred onto another (i.e., rehypothocated) counterparty to cover a credit exposure; and the information field entitled REPO FLAG stores a flag which indicates whether or not the referenced asset piece can be repoed. Notably, the information fields of the information structure ASSET PIECE are interrelated with the information structures indicated by the relational links shown in the information entity model of FIG. 3.

By definition, an "asset piece" is created when an asset originally placed into a GCSS customer account is transferred as collateral (e.g., pledged) from one party to a counterparty in order to cover a credit exposure. An asset piece can be created as a result of originally transferred assets, covering for credit support shortfalls, automated-initiation of asset transfer, or manual-initiation of asset transfer. The function of the ASSET PIECE information structure is to store detailed information on each piece of asset moved into a GCSS customer account, and also its current status (e.g., it may have been transferred-on in part or whole to another GCSS customer account). The information items stored in CONTROL GCSS ACCOUNT and the PREVIOUS GCSS ACCOUNT collectively represent a "pseudo-chain" of asset transfers among GCSS customer accounts in the GCSS. This functionality enables the customers to track the movements of assets into and out of his or her GCSS account for purposes of credit support processing. Should an asset piece be transferred by a party in order to cover a credit exposure of its counterparty, its corresponding information structure will then be modified to identify the current holder and to whom the asset piece has been transferred. In the illustrative embodiment, each asset piece is classified by its assigned Balance Code, which specifies (i.e., controls) how the asset is used in credit support processing. For example, as shown below different calculations are performed for asset pieces having different Balance Codes:

    ______________________________________
    Code         Calculating Excess
                                Original Asset
    ______________________________________
    ORIGINAL     positive       positive
    IN INTRANS   positive       zero
    OUT TRANS    negative       zero
    REPOOUT      negative       negative
    DEFAULT      negative       negative
    CLOSED       zero           zero
    ______________________________________