WO2001022305A2

WO2001022305A2 - A financial risk and exposure management system

Info

Publication number: WO2001022305A2
Application number: PCT/GB2000/003671
Authority: WO
Inventors: Gavin Bell
Original assignee: Sungard Software, Inc.
Priority date: 1999-09-23
Filing date: 2000-09-25
Publication date: 2001-03-29
Also published as: GB9922589D0; GB2354608A; 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 (13) to apply a series of validity tests for a proposal <i>vis-à-vis</i> a stored netting agreement. It then automatically calculates exposure.

Description

A FINANCIAL RISK AND EXPOSURE MANAGEMENT SYSTEM

BACKGROUND OF THE INVENTION

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

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 close-out netting. A close-out netting agreement 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 of all qualifying 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 agreement. Therefore, there is a single balancing amount to be paid by one party.

While such agreements are very important instruments for financial institutions and other similar organisations, administration is particularly difficult. This is because of the financial and legal complexities involved. For example, close-out netting agreements are only legally allowable in a certain limited number of countries. Also, within these countries various constraints apply.

It is therefore an object of the invention to provide a financial risk or exposure management system which manages the creation and maintenance of agreements in a manner which 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 database storing tables of netting agreement parameters;

a dealing system interface comprising means for receiving dealing data in real time and for writing said data to a database table; and

a modelling engine comprising means for receiving user inputted attributes for a proposed netting agreement with a counterparty, and for automatically carrying out a series of validity tests according to pre-set rules, said dealing data, and said netting agreement parameters to determine if the proposal is valid.

In one embodiment, the dealing system interface comprises means for receiving and storing pre-deal limit check, exposure update, and violation alert data.

In one embodiment, the modelling engine comprises means for combining received attributes to determine an exposure consolidation key, said key identifying an exposure consolidation category and an associated set of rules for validity tests. In one embodiment, the database stores dynamic tables which are frequently updated and static tables of infrequently updated data, and said netting agreement tables are dynamic.

In one embodiment, the static tables comprise a master agreement table of data associated with a static master agreement including data fields identifying allowed dealing product types and indicators for constraints on attributes. .

In one embodiment, the netting agreement tables are related to the master agreement table with an identification code, and the netting agreement tables are partially automatically populated by the master agreement table.

In one embodiment, the dynamic tables include parent tables, and subsidiary tables correlating groupings of related data for fast data access.

In one embodiment, the modelling engine comprises means for applying a series of validity tests for an agreement for a relevant counterparty located in the dynamic netting tables, and for re-initiating said tests with a fresh agreement if any of said tests fail.

In one embodiment, each test has an associated data access address embedded in the associated rules, for fast data access.

In one embodiment, the modelling engine comprises means for automatically calculating an exposure value upon determination that a proposal is valid. According to another aspect, there is provided a financial risk and exposure management system comprising:

a stored set of static tables storing close out netting parameter values which change infrequently,

a stored set of dynamic tables storing close out netting parameter values which change frequently, said dynamic tables being related to said static tables and including data for existing counterparty agreements,

a dealing system interface comprising means for receiving dealing data including violation alerts in real time from remote dealing systems:

a modelling engine comprising:

a user interface comprising means for receiving attributes for a proposal close out netting agreement;

means for searching the dynamic tables to locate an existing agreement for a relevant counterparty identified in said received attributes;

means for carrying out a series of validity tests on said attributes to check if they apply to the agreement and are compatible with the dealing data; means for rejecting said agreement and for locating a further agreement if said first agreement fails a validity test and for repeating said validity tests until all agreements for that counterparty have been exhausted; and

means for automatically calculating an exposure value for the attributes according to an agreement for which the tests are positive.

In one embodiment, said tests are carried out according to a set of rules retrieved according to an exposure consolidation key identifying an exposure consolidation category having an associated set of rules.

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. 1 is a schematic overview of a financial risk and exposure management system of the invention;

Fig. 2 is a diagram illustrating a part of the system for processing close-out netting agreements;

Figs 3(a) and 3(b) are together a flow diagram illustrating operation of the part of the system shown in Fig. 2; and Figs. 4 to 13 are sample display screens to illustrate operation of the system.

DETAILED DESCRIPTION OF THE INVENTION

Referring to Fig. 1, there is shown a risk and exposure management system 1. The system 1 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 5 and a reporting system 6 which both interact in real time with the central server 2 using XML protocol. In addition to real time financial data updating, the systems 4 also provide parameter values such as pre-deal limit checks, exposure updating, and violation alerts. This data is written by the server 2 to the database 3 as it is received.

The server 2 is programmed to manage exposures dynamically using data from the dealing systems 4 and tables in the database 3, 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 an associated rules process.

A major function performed by the server 2 is close-out netting management. This functionality is performed by a sub-system 11 shown in Fig. 2. A data capture interface 12 is programmed to interactively prompt user input of data for 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 rules to interrogate various datasets in the database 3 and provide outputs to the user. The rules are selected according to the exposure consolidation key. The datasets comprise a current dataset 14 of user-inputted data for a particular query or proposal agreement. It also comprises a set of dynamic tables 15 and a set of static tables 16.

The sub-system 11 also comprises a modelling output interface 17, and a sample output 18 is illustrated in Fig. 2.

The static tables include a table of Master Agreements containing:- The master agreement identification code

The agreement name

Indicators for additional constraints on the attributes.

Branches of the parent bank

Dealing product types (associated with received dealing data) Currencies

The following is an example of a table defining the scope of a master agreement.

— Table: MST_CLS_AGR Master Closeout Agreement create table MST_CLS_AGR

( MST_AGR_CD CHAR(8) not null, — master agreement type

MST_AGR_NM CHAR(28) not null, — master agreement name

STR DT DATE not null, — effective date END DT DATE not null, — termination date

ALL CUR FL CHAR(l) not null, -- all currencies flag

ALL PRD FL CHAR(l) not null, — all products flag

ALL BRN FL CHAR(l) not null, — all branches flag

ALL JUR FL CHAR(l) not null, — all jurisdictions flag

DEL ST CHAR(l) not null, — delete state

MOD TS DATE not null, — audit date/time

MOD BRN CD CHAR(8) not null, — audit branch code

MOD AGT CD CHAR(8) not null, -- audit agent code constraint PK MST CLS AGR primsiry ke (MST AGR CD)

Secondary tables specify the allowable values if any constraints are to be applied on Branches, Currencies, Legal Jurisdictions or Products under this agreement.

— Table: MST_CLS_BRN Master Closeout Agreement Branch create table MST CLS BRN

(

MST_AGR_CD CHAR (8) not null, — master agreement type

MST_BRN_CD CHAR (8) not null, — branch code constraint PK_MST_CLS_BRN primary key (MST_AGR_CD, MST_BRN_CD) using index tablespace RXM INDl

) /

— Table: MST_CLS_CUR Master Closeout Agreement Currency create table MST_CLS_CUR (

MST_AGR_CD CHAR (8) not null, — master agreement type MST_CUR_CD CHAR(3) not null, — currency code constraint PK_MST_CLS_CUR primary key (MST_AGR_CD, MST_CUR_CD) using index tablespace RXM_1ND1 ) /

— Table: MST_CLS_JUR Master Closeout Agreement Jurisdiction create table MST_CLS_JUR

(

MST AGR_CD CHAR (8) not null, — master agreement type MST JUR_CD CHAR (3) not null, — jurisdiction code constraint PK_MST_CLS_JTJR primary key (MST_AGR_CD, MST_JUR_CD) using index tablespace RXM_IND1

)

/ — Table: MST_CLS_PRD Master Closeout Agreement Product create table MST_CLS_PRD

(

MST_AGR_CD CHAR(8) not null, — master agreement type MST_PRD_CD CHAR (4) not null, — product code constraint PK_MST_CLS_PRD primary key (MST_AGR_CD, MST_PRD_CD) using index tablespace RXM INDl

)

If an additional constraint is required an associated table is constructed holding the authorised values for that attribute for this master agreement. 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 specification as "static" tables 16.

A table of counterparty close-out agreements is maintained containing:'

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 holding 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.

Linking of the dynamic tables and the static tables is achieved by the master agreement identification code key. This key is used to automatically populate dynamic tables including the netting agreement tables with valid data which is static. An example is an identifier for branches of the bank.

Referring to Figs. 3(a) and 3(b) a process comprising steps 25 to 39 is now described. This process is carried out by the modelling engine 13 operating according to rules defining a controlled process and accessing the static and dynamic tables and the dealing data. Because the dynamic tables are loaded in memory for faster access and because they are populated with some static data, most accesses are the dynamic tables to provide fast response times.

An important aspect of the modelling engine 13 is that it operates in a highly controlled manner to follow a test execution sequence 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 counterparties.

The data capture interface 12 receives user data for a proposed transaction. In step 25 the engine 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

Dealing data including violation alerts is also accessed.

The following is a sample of the code in the C language for locating a matching agreement.

// Search for the first matching agreement for { int i=0; i < numAgr; i++ ) { Rx ClsNetAgreement cstAgr; cstAgr = * (agrRecordList [i] ) ; agrCode = cstAgr . CloseoutNetAg Id () ; // Get the netting product if ( cstAgr.AllProductsFlagO == true ) {

II;

} else

{

// RxmClsNetProduct clsNetProduct; if ( ! RxmClsNetProduct: .-Find (cstCode, agrCode , prdCode) ) {

// Get next agreement for the customer continue; } }

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 13_. 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 authorised list the process returns to step 27. The country of counterparty HQ is checked in step 30 against the list of authorised jurisdictions for the designated master agreement. If the country is not included in the authorised list the process returns to step 27. A sample of the code in the C language is given below.

// Check the urisdiction in the master agreement if ( mstAgr.AllJurisdictionsFlagO == false )

{ // Check Agreement country of governing law if ( i RxmClsNetMstJurisdiction:: ind(mstAgrCode, countryOfGovnLaw) ) {

// Get next agreement for the customer continue ; } // Check customer ultimate risk country if ( • RxmClsNetMstJurisdiction :: ind (mstAgrCode, ultimateRiskCountry) )

{

// Get next agreement for the customer continue ;

}

The product attribute constraint indicator is checked in step 31. If a product constraint is in effect the product code is checked against the list of authorised products for this counterparty close-out agreement. 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 against 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 dealing branch code is checked against the list of authorised dealing branches for this counterparty close- out agreement. If the dealing 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 found in this list the process returns to step 27.

The counterparty branch attribute constraint indictor is checked in step 35. If a counterparty branch constraint is in effect the counterparty branch code is checked against the list of authorised counterparty branches for this counterparty close-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 36 against the listed of authorised jurisdiction countries for this master agreement. If the counterparty branch 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 13 then updates a CLS_NET_SET table in the dynamic tables 15, as follows.

// Now this contract is a closeout nettable contract, // update the CLS_NET_SET table if it is a Deal. RxmStrmg clsNetUnqld; if ( iRxmClsNetSet: : Find (cstCode, agrCode, clsNetϋnqld) )

^{ // if not found and it is not aDeal , consider it as non_nettable if ( titsADeal )

{

// return false; It is OK to create a new ID. }

// Using the contract internal Number as the ClsNetUmqueld // clsNetUnqld = IntRefNumO; // Get ClsNetSet Sequence Number as ClsNetUmqueld // RxmStrmg clsNetUnqld; if ( i xmContrac : :NextClsNetSetSeqNum (clsNetUnqld) ) {

RXML0G1 (RxmLog: : critical) « " ' ' Error m getting next ClsNetSet sequence number i i »

« endlog; retStatus = false; return false;.

The engine 13 then proceeds to calculate the counterparty credit value of transactions in a 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 engine calculates:-

The sum of all the MtM values and the sum of all positive MtM 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 close-out netting agreement is calculated from the formula:-

Maximum (sum of all MtM values or Zero) +sum of all PFE values multiplied by the mitigating factor.

The counterparty credit risk value of all transactions which are still active for 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 18 is shown in Fig. 2.

The closeout netting agreement definitions are linked to the customer by a data table field CST_ID which uniquely identifies the customer within the system 1. A primary table of the dynamic tables 16 identifies the characteristics of the agreement, and the following are the main fields.

CST_CD CHAR (12) not null, — customer code

CLS_AGR_CD CHAR (8) not null, — agreement code (id)

MST_AGR_CD CHAR (8) not null, — master agreement type — key to master agreement LGL_ENT_CD CHA (6) not null, — legal entity code

GOV_LA _CTY_CD CHAR (6) not null, — country of governing law

EFF_DT DATE not null, — effective date (start date)

ALL_CUR_FL CHAR(l) not null, — all currencies flag

ALL_PRD_FL CHAR(l) not null, -- all products flag

ALL_BRN_FL CHAR(l) not null, -- all branches flag

ALL_PLC_FL CHAR(l) not null, -- all jurisdictions flag

CLT_AL _FL CHAR(l) not null, — collateral allowed flag

DEL_ST CHAR(l) not null, -- delete state

MOD_TS DATE not null, — audit date/time

MOD_BRN_CD CHAR (8) not null, — audit branch code

MOD _AGT_CD CHAR (8) not null, — audit agent code constraint PK_CLS_AGR primary key (CST CD, CLS AGR CD) using index tablespace RXM IND1

Secondary tables specify allowable values for constraints applied to branches, currencies, places, or products under the agreement. The following are examples.

— Table: CLS BRN Closeout Agreement Branches create table CLS_BRN

(

CST_CD CHAR(12) not null, — customer code

CLS_AGR_CD CHAR (8) not null, — els netting agreement id CLS_BRN_CD CHA (8) not null, — branch code constraint PK_CLS_BRN primary key (CST_CD, CLS_AGR_CD, CLS_BRN_CD) using index tablespace RXM_IND1

)

/

Table: CLS CUR Closeout Agreement Currencies create table CLS_CUR

(

CST_CD CHAR (12) not null, — customer code

CLS_AGR_CD CHAR (8) not null, — els netting agreement id

CLS_CUR_CD CHAR (3) not null, — currency code constraint PK_CLS_CUR primary key (CST_CD, CLS AGR CD, CLS CUR CD) using index tablespace RXM_IND1

)

/

— Table: CLS PLC Closeout Agreement Places create table CLS_PLC (

CST_CD CHAR (12) not null, — customer code CLS_AGR_CD CHAR(8) not null, — els netting agreement id CLS PLC CD CHAR(6) not null, — place code constraint PK_CLS_PLC primary key (CST_CD, CLS_AGR_CD, CLS PLC CD) using index tablespace RXM_IND1 ) /

— Table: CLS_PRD Closeout Agreement Products create table CLS PRD (

CST_CD CHAR (12) not null, — customer code

CLS_AGR_CD CHAR (8) not null, — els netting agreement id

CLS_PRD_CD CHAR(4) not null, — product code constraint PK_CLS_PRD primary key (CST_CD, CLS_AGR_CD, CLS_PRD_CD) using index tablespace RXM_IND1 )

A dynamic table is updated for each deal included in a uniquely identified closeout netting set to calculate the "mitigating factor" used to generate the credit risk exposure value assigned to the set of netted deals. The mitigating factor is a measure of the reduction in credit risk exposure achieved by the use of the closeout netting technique.

— Table: CLS NET SET Closeout Netting Set create table CLS NET _SET (

CST_CD CHARU2) not null, — customer code

C CLLSS_AAGGRR_CCDD CCHHAARR((88)) not null, -- closeout agreement code agreement with customer

CLS_NET_UNQ_ID CHAR(16) not null, — unique els net set id SUM POS_MTM_VL FLOAT not null, — sum of positive risks for contracts in net set

S SUUMM AALLLL_MMTTMM_VVLL F FLLOOAATT not null, -- sum of all risks for contracts in net set

NGR VL FLOAT not null, — computed multiplier for add-on value constraint PK_CLS_NET_SET primary key (CST_CD , CLS_AGR_CD) using index tablespace RXM IND1

Referring now to Figs. 4 to 13 system display screens are shown to assist in understanding the composition of the tables and the manner in which the modelling engine operates. Editing of a closeout agreement table is shown i Fig. 4. This table includes markers or flags for related tables for currencies (Fig. 5), products (Fig. 6), branches (Fig. 7), and locations (Fig. 8) as described in more detail above. 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 screen of Fig. 5 illustrates entry of currency data, Fig. 6 shows entry of codes for netting products, Fig. 7 shows entry of branch codes, and Fig. 8 shows entry of locations.

The primary static table is a master agreement table, editing of which is shown in Fig. 9. Figs. 10 to 13 illustrate related tables as follows:

^"Tig. 10: currencies,

Fig. 11: products,

Fig. 12: branches, and

Fig. 13: jurisdiction.

These tables are updated relatively infrequently.

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 counterparties other than close out netting agreements, such as general netting agreements.

Claims

WHAT IS CLAIMED IS:

1. A financial risk and exposure management system (1) comprising;

a database (3) storing tables of netting agreement parameters;

a dealing system interface (2, 4) comprising means for receiving dealing data in real time and for writing said data to a database table; and

a modelling engine (13) comprising means for receiving user inputted attributes for a proposed netting agreement with a counterparty, ancTfor automatically carrying out a series of validity tests according to pre-set rules, said dealing data, and said netting agreement parameters to determine if the proposal is valid.

2. A financial risk and exposure management system as claimed in claim 1, wherein the dealing system interface (2, 4) comprises means for receiving and storing pre-deal limit check, exposure update, and violation alert data.

3. A financial risk and exposure management system as claimed in claims 1 or 2, wherein the modelling engine (13) comprises means for combining received attributes to determine an exposure consolidation key, said key identifying an exposure consolidation category and an associated set of rules for validity tests.

4. A financial risk and exposure management system as claimed in any preceding claim, wherein the database stores dynamic tables which are frequently updated and static tables of infrequently updated data, and said netting agreement tables are dynamic.

5. A financial risk and exposure management system as claimed in claim 4, wherein the static tables comprise a master agreement table of data associated with a static master agreement including data fields identifying allowed dealing product types and indicators for constraints on attributes.

6. A financial risk and exposure management system as claimed in claim 5, wherein the netting agreement tables are related to the master agreement table with an identification code, and the netting agreement tables are partially automatically populated by the master agreement table.

7. A financial risk and exposure management system as claimed in claim 6, wherein the dynamic tables include parent tables, and subsidiary tables correlating groupings of related data for fast data access.

8. A financial risk and exposure management system as claimed in any preceding claim, wherein the modelling engine comprises means for applying a series of validity tests for an agreement for a relevant counterparty located in the dynamic netting tables, and for re-initiating said tests with a fresh agreement if any of said tests fail.

9. A financial risk and exposure management system as claimed in claim 8, wherein each test has an associated data access address embedded in the associated rules, for fast data access.

10. A financial risk and exposure management system as claimed in any preceding claim, wherein the modelling engine comprises means for automatically calculating an exposure value upon determination that a proposal is valid.

11. A financial risk and exposure management system comprising:

a modelling engine comprising:

a user interface comprising means for receiving attributes for a proposal close out netting agreement; means for searching the dynamic tables to locate an existing agreement for a relevant counterparty identified in said received attributes;

means for carrying out a series of validity tests on said attributes to check if they apply to the agreement and are compatible with the dealing data;

means for rejecting said agreement and for locating a further agreement if said first agreement fails a validity test and for repeating said validity tests until all agreements for that counterparty have been exhausted; and

12. A financial risk and exposure management systeπTas claimed in claim 11, wherein said tests are carried out according to a set of rules retrieved according to an exposure consolidation key identifying an exposure consolidation category having an associated set of rules.