GB2354608A

GB2354608A - A financial risk and exposure management system

Info

Publication number: GB2354608A
Application number: GB9922589A
Authority: GB
Inventors: Gavin Bell
Original assignee: GE Information Services Ltd; Sungard Software Inc
Current assignee: GXS Ltd; Sungard Software Inc
Priority date: 1999-09-23
Filing date: 1999-09-23
Publication date: 2001-03-28
Also published as: WO2001022305A2; GB9922589D0; WO2001022305A8; AU7436700A

Abstract

In a financial risk and exposure management system (1) a server (2) receives pre-deal limit check, exposure update, and violation alert data in real time from remote dealing systems (4). A database (3) stores static tables of data including master agreement data. Dynamic tables of data including details of existing netting agreements are linked with the master tables. The server (2) executes a modelling engine to apply a series of validity tests for a proposal vis-a-vis a stored netting agreement. It then automatically calculates exposure.

Description

2354608 Financial Risk and Exposure Manaement Svstem"

INTRODUCTION

Field of the Invention

The invention relates to a system for management of financial risk or exposure.

Prior Art Discussion

In recent years, organisations such as financial institutions have increasingly entered into agreements with third parties in order to reduce exposure for deals such as derivatives deals. One example is ctose-out netting. A close-out nettina aoreement is made between a financial institution and a counterparty. It states that in the event of counterparty default, the total position with that counterparty will be treated as the result of close-out all qualifyino contracts. Thus, the financial institution exposure in the event of counterparty default is the netted sum of all trades covered by a close- out netting acyreement. Therefore, there is a single balancing amount to be paid by one party.

While such aareements are very important instru ments for financial institutions and other similar orcanisations, administration is particularly difficult. This is because of the financial and teoal complexities involved. For example. close-out nettina acTreements are Z C only legally allowable in a certain limited number of countries. Also, within these countries various constraints apply.

Obiects of the-Invention It is therefore an object of the invention to provide a financial risk or exposure manacTement svstem which manages the creation and maintenance of aareements in a 1 0 manner Ahlch is both effective and minimiseS user time input required.

SUMMARY OF THE INVENTION,

According to the invention, there is provided a financial risk and exposure management system comprising a user interface comprising means for receiving user data for a C, rn proposed transaction, and a modelling engine comprising means for determining In ZD ellgibility of the proposed transaction to an aureement with a counterparty.

Preferably, the modelling engine comprises means for accessing static tables storing eligibility data.

In one embodiment, the static tables comprise tables containing master agreement, elialble countries, elialble branches, and etialble product data.

11. ID In another embodiment, the modelling engine comprises means for accessing dynamic tables storing aareement data for existing agreements and counterparties.

In one embodiment, the modelling engine comprises means for accessing secondary dynamic tables storing data for groupings of correlated parameters.

Preferably, the engine comprises processing means for operating according to rules to access the static and dynamic tables in a controlled manner to generate a proposal response.

In another embodiment, the processing means comprises means for executing a controlled sequence of tests comparing the received user data with data in the static and 3 0 dynamic tables until an eligibility status flag is set to positive.

Preferably, the modelling engine comprises means for executing a test in both static and dynamic tables for each proposal attribute.

In one embodiment. the modelling engine comprises means for operating in a fixed sequence of tests, in which each test has an associated date access address for fast response times.

In another embodiment, the modelling engine comprises means for automatically performing an exposure calculation if the status flag is positive.

Preferably, the calculation Generates a set of projected exposure values for future deal 0 dates.

According to another aspect the invention provides a computer program product comprising software code for completing a system as defined above when loaded in a digital computer.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:

Fig. I is a schematic overview of a financial risk and exposure management system of the invention; FJ'cr. 2 is a dia-ram illustrating a part of the system for processing close-out nettina acyreements-I 1-1 t Flus 3)(a) and 3)(b) are together a flow diagram illustrating operation of the part of 0 zz the system shown in Fig. 2; and Figs. 4 to I') are sample display screens to illustrate operation of the system.

Description of the Embodiments

Refer-ring to Fig. 1, there is shown a risk and exposure management system 1. The system I comprises a central server 2 having a global exposure and limits database 3. This database is updated in real time by geographically spread dealing systems, indicated generally by the numeral 4. Each of these systems comprises a market risk engine and a reporting system which both interact in real time with the central server 2. In addition to real time financial data updating, the systems 4 also input parameter values such as predeal limit checks, exposure updating., and violation alerts.

1 The dealing systems and the server are programmed to manage exposures dynamically, rather than simply imposing limits. This is achieved by combining one or more contract attributes or derived values such as Counterparty, Country, Currency, or Product to form an exposure consolidation key. This key identifies an exposure consolidation category and associated rules process.

A major function performed by the server 2 is close-out netting management. This functionality is performed by a sub-system I I shown in Fig. 2.

A data capture interface 12 is programmed to interactively prompt user input of data for 3 1 proposed agreements and transactions and other query data. The sub-system 11 also comprises a modelling engine 13 which comprises a processor operating in response to 2=1 C rules to interrocrate various datasets and provide outputs to the user. The datasets Z:

comprise a current clataset 14 of user-inputted data for a particular query or proposal aoreement. It also comprises a set of dynamic tables 15 and a set of static tables 16.

The sub-system I I also comprises a modelling Output interface 17, and a sample output 18 is illustrated in Ficr 2 A table of Master Agreements is maintained containing:- The master agreement identification code The aureement name Indicators for additional constraints on the attributes. Branches of the parent bank Dealing product types Currencies If an additional constraint is required an associated table is constructed holding the authorised values for that attribute for this master aareement. An associated table holding the authorised list of Jurisdiction countries for this master agreement is maintained.

These tables change relatively infrequently and are therefore referred to in this speci ication as "static" tables 16.

A table of counterparty close-out agreements is maintained contaming:Counterparty identification code Agreement identification code Master agreement identification code Country of applicable law Effective date of agreement Collateral Annex Indicator Current Collateral Value Indicators for additional constraints on the attributes Currencies covered by this agreement Products covered by this agreement Branches of the parent bank covered by the agreement Branches of the counterparty covered by this agreement If any additional constraints are required an associated table is constructed holdincy the aUthorised values for that attribute for this specific agreement. These tables are amended frequently in response to generation of new agreements and modification of existing ones. The counterparty agreement table and these subsidiary tables are therefore referred to as "dynamic" tables 15. The dynamic tables are essentially subsets of the static master agreement table and its subsidiary static tables.

z:1 Referring to Figs. 3)(a) and 3)(b) a process comprising steps 25 to 39 is now described.

0 This process is carried out by the modelling engine operating 13 according to rules defining a controlled process and accessing the static and dynamic tables.

An important aspect of the modelling engine 13 is that it operates in a highly controlled manner to follow a test execution sequence such as that illustrated in Figs. 3 (a) and 3) (b).

Each rule which requires data access is coded with the address of the relevant table.

Because the datasets are in dynamic and static groups, and because the dynamic tables have subsidiary tables identified by parent dynamic table records there is very fast data access. Also, there are secondary tables which correlate groupings of related data. This minimises the number of accesses required. Thus, in most instances, a rule can access required data derived from a correlation of, for example, an agreement and a counterparty in a single access in which time is delayed only by a single index and table access cycle.

These features allow excellent real time performance of the system, even if there are thousands of counterpar-ties.

The data capture interface 12 receives user data for a proposed transaction. In step 25 the encyine checks if the proposal is eligible for close-out netting treatment under an existing agreement with the relevant counterparty. The data captured for this purpose is:- Counterparty Identification Code Counterparty HQ Country Product code Dealing branch code Dealing Branch Country Counterparty branch or location code Counterparty branch country Currency code or codes of the transaction or contract If no agreements are found then a Close-out Netting Status is set to NO, as indicated by step 26. If an agreement is located, the engine 1-3) then checks each agreement for this counterparty against the process steps below until it determines that the close-out status is YES. If the agreement list is exhausted before this condition is found then the close-out status is NO and a process exit is taken. If the close-out status for an agreement is set to YES the process exit is taken.

Location of an agreement is indicated in step 27, and in step 28 the current date is checked against the effective date. If the effective date is in the future the process returns to step 27.

The country of applicable law is checked in step 29 against the list of authorised jurisdictions for the designated master agreement. If the country is not included in the IM authorised list the process returns to step 27.

The COLintry of counterparty HQ is checked in step 30 against the list of authorised urisdictions for the desionated master agreement. If the country is not included in the Z.- authortsed list the process returns to step 27.

The product attribute constraint indicator is checked in step 3) 1. If a product constraint is in effect the product code is checked against the list of authorised products for this counterparty close-out acreement. If the product code is not found in this list the process returns to step 27. The product attribute constraint indicator for the associated Master Agreement is checked in step 32. If a product constraint is in effect the product code is checked a2ainst the list of authorised product for this master agreement. If the product code is not found in this list the process returns to step 27.

The dealing branch attribute constraint indicator is checked in step 33). If a dealing branch constraint is in effect the dealinc, branch code is checked acainst the list of authorised dealing branches for this counterparty close-out agreement. If the dealing 1.1 C, branch code is not found in this list the process returns to step 27.

The dealing, branch country code is checked in step 34 against the list of authorised jurisdiction countries for this master agreement. If the dealing branch country code is not t: C, 2) 0 found in this list the process returns to step 27.

The counterparty branch attribute constraint indictor is checked in step 35. If a COLinterparty branch constraint is in effect the counterparty branch code is checked against the list of authorlsed counterparty branches for this counterparty ctose-out agreement. If the counterparty branch code is not found in this list the process returns to step 27.

The counterparty branch country code is checked in step 336 against the listed of authorised jurisdiction countries for this master agreement. If the counterparty branch 3 country code is not found in this list the process returns to step 27.

The currency attribute constraint indicator is checked in step 37. If a currency constraint Is in effect the currency code is checked against the list of authorised currencies for this counterparty close-OUt agreement. If the currency code is not found in this list the process returns to step 27.

The currency attribute constraint indicator for the associated Master Agreement is checked in step 38. If a currency constraint is in effect the currency code is checked against the list of authorised currencies for this master agreement. If the currency code is not found in this list the process returns to step 27.

The close-out netting status is then set to YES and the process returns to step 27.

The engine I') then proceeds to calculate the counterparty credit value of transactions in a Z:, 1 proposed agreement provided the status is YES. The data capture interface 12 captures the following data:

Counterparty code Close-out Netting agreement identifier Transaction Mark to Market value (MtM) Transaction Potential Future Exposure value (PFE) Transaction exposure maturity date For all transactions with the same counterparty code and close-out netting agreement identifier code the encyine calculates:

The sum of all the MtM values and the sum of all positive AM values.

A mitigating, factor (MF) is calculated using the formula 0.4 + 0.6 sum of all MtM values divided by the sum of all positive values.

The COUnterparty credit risk of all transactions included in the closeOUt netting agreement is calculated from the formula:- Maximum (SUM of all MtM values or Zero) +surn of all PFE values Multiplied by the mitigating factor.

The counterparty credit risk value of all transactions which are still active o any future date is calculated by summing the MtM values and PFE values for all transactions on that date where the transaction exposure maturity date is later than the selected date. A sample output is shown in Egg. 22.

Referring now to Figs. 4 to I') system display screens are shown to assist in understanding the composition of the tables and the manner in which the modelling ZD ZD engine operates. Editing of a closeout agreement table is shown in Fig. 4. This table includes markers or flacys for related tables for currencies (Fig. 5), products (Fla. 6) branches (Fig. 7), and locations (Fig. 8). These tables are all dynamic. There are also secondary dynamic tables for groupings or correlations of data such as a grouping of a particular counterparty and a particular agreement.

The primary static table is a master agreement table, editing of which is shown in Fla. 9.

Figs. 10 to I illustrate related tables as follows:

Fig. 10: currencies, F 1 Cy. 11: products.

0 Fig. 12: branches, and Ficy. 13: jurisdiction.

C) These tables are updated relatively infrequently. no It will be appreciated that the invention provides for comprehensive agreement processing for risk and exposure management. This has been achieved with very fast response times to allow real time operation where workstations are widely spread geographically.

The invention is not limited to the embodiments described, but may be varied in construction and detail within the scope of the claims. For example, the invention may be applied to processing of agreements between counter-parties other than close out netting agreements, such as general netting agreements.

Claims

Claims

I A financial risk and exposure management system comprising a user interface comprising means for receiving user data for a proposed transaction, and a I C) modellinc, enaine comprising means for determining eligibility of the proposed 0 t transaction to an agreement with a counterparty.
A system as claimed in claim 1, wherein the modelling engine comprises means for accessing static tables storing eligibility data.
C, A system as claimed in claim 2, wherein the static tables comprise tables containing master agreement, eligible countries, eligible branches, and eligible product data.
4. A system as claimed in any preceding claim, wherein the modelling engine comprises means for accessing dynamic tables storing agreement data for existing tD agreements and counterparties.
5. A system as claimed in claim 4, wherein the modelling engine comprises means for accessing secondary dynamic tables storing data for groupings of correlated t:l C) 0 parameters.
6. A system as claimed in any preceding claim, wherein the engine comprises processing means for operating according to rules to access the static and dynamic 1-1 0 tables in a controlled manner to generate a proposal response.
7. A system as claimed in claim 6, wherein the processing means comprises means for executing a controlled sequence of tests comparing the received user data with Z.7 data in the static and dynamic tables until an eligibility status flag is set to positive.
S. A system as claimed in claim 7. wherein the modellinc, en-Ine comprises means "Z> n for eXeCUtina a test in both static and dynamic tables for each proposal attribute.
9. A system as claimed in any of claims 6 to 8, wherein the modelling engine comprises means for operating in a fixed sequence of tests, in which each test has 0 an associated date access address for fast response times.
10. A system as claimed in any preceding claim, wherein the modelling engine comprises means for automatically performing an exposure calculation if the status flag is positive.

C:I
11. A system as claimed in claim 10, wherein the calculation (Yenerates a set of projected exposure values for future deal dates.
12. A system substantially as described herein with reference to the drawings.

11 A computer program product comprising software code for completing a system t:I z:' as claimed in any preceding claim when loaded in a digital computer.