Event driven management information system with rule-based applications structure stored in a relational database

Having thus described our invention, what we claim as new and desire to secure by Letters Patent is:

1. A computer system for performing risk and exposure calculations for an institution based upon stored rules and data, the computer system comprising:

a management information data base for storing management data;

a host computer;

program means for performing risk and exposure calculations using the on said host computer according to rules stored as objects in a relational data base, said program means including,

event processing means for responding to external and internal events, and

interfacing means having predetermined seminal keys for receiving said management information data from said management information data base and for receiving market information data from a market information data source for use in said risk and exposure calculations;

rule presentation means for displaying rules stored in said relational data base in a presentation format to a user, and for allowing the user to modify existing rules and create new rules using object operators; and

rule translation means for translating rules from the presentation format to a table form for storage in said relational data base as an object.

2. A computer system for performing risk and exposure calculations for an institution in accordance with rules stored as objects in a relational data base, the computer system comprising:

a relational data base for storing rules and data;

a host computer coupled to said relational data base;

display means coupled to said host computer;

rule presentation means for displaying rules to perform risk and exposure calculations in a presentation format on said display means and for allowing a user to modify existing rules in a presentation format and create new rules in a presentation format using arithmetic and logical expressions;

rule translation means for translating rules in a presentation format to rules in a table format, and for storing said rules in a table format as objects in said relational data base; and

application means for retrieving said rules in a table format stored as objects in said relational data base and for performing calculations according to said rules in a table format using said stored data, said application means including,

event processing means responsive to external and internal events, and

interfacing means having predetermined keys for retrieving said stored rules and data.

3. The computer system of claim 2, wherein said rules in a presentation format include variables and said rule translation means further includes means for decomposing each variable in said rules in a presentation format into one of a previously translated rule in a table format, a program for retrieving a primitive data value and a program for calculating a value.

4. The computer system of claim 3, wherein said application means further includes means for retrieving preselected ones of said rules in said table format from said data base and performing a calculation defined by said preselected ones of said rules in said table format.

5. The computer system of claim 4, further including what-if means for storing primitive data values retrieved by said program for retrieving a primitive data value, and for allowing a user to manipulate said primitive data values and re-perform calculations according to said rules in said table format using said manipulated primitive data values.

6. The computer system of claim 4, wherein said rules stored as tables in said relational data base can be retrieved as objects.

7. A computer system for performing risk and exposure calculations for an enterprise based upon stored rules and data, the computer system comprising:

means for inputting one of a mathematical and a logical rule which defines a risk and exposure calculation, said rule including variables;

means for convening said rule into a table which also defines said calculation;

means for storing said table as an object in said data base; and

an application program for retrieving said table from said data base and performing said calculations defined in said table using said stored data, said program including,

an event processing program responsive to external and internal events, and

an interfacing program having predetermined keys for retrieving said stored rules and data.

8. The computer system of claim 7 wherein said means for inputting includes interactive means for allowing a user to create new rules and modify existing rules.

9. The computer system of claim 7 wherein said predetermined keys include PRODUCT, MANAGEMENT UNIT, REGION, PARTICIPANT, CUSTOMER, CUSTOMER ACCOUNT, FIRM ACCOUNT, PORTFOLIO, MARKET SEGMENT., and USER DEFINED FACILITY.

10. Said computer system of claim 9, wherein said means for converting further includes means for decomposing said variables in said rule into a previously converted rule, one of a plurality of programs for retrieving a primitive data value and one of a plurality of programs for calculating a value.

11. The computer system of claim 10, further including what-if means for storing said primitive data values retrieved by said programs for retrieving a primitive data value, and for allowing a user to manipulate said primitive data values and re-perform said calculation according to said table using said manipulated primitive data values.

12. A computer-based method, triggered by external and internal events, for storing roles as objects in an object based computer data base, retrieving and executing the stored rules, and retrieving stored data for calculating risk and exposure variables for an institution, the method comprising the steps of:

(1) inputting a risk and exposure rule having variables, said rule defines a logical or a mathematical calculation;

(2) converting said inputted rule of step (1) into a table;

(3) storing said table of step (2) as an object in said data base;

(4) retrieving said table of step (3) from the data base;

(5) obtaining data values corresponding to each said variable of said rule in said table; and

(6) performing said calculation defined by said rule of step (1).

13. The computer-based method of claim 12, wherein step (2) further includes the step of:

(a) decomposing each variable within said rule into a program for retrieving a primitive data value or a program for calculating a value or a rule which had been previously converted into a table.

14. The computer-based method of claim 13 further including the steps of:

(7) storing primitive data values retrieved by said programs for retrieving a primitive data value; and

(8) allowing a user to manipulate said primitive data values and re-perform calculations according to said rule using said manipulated primitive data values.

15. The computer-based method of claim 13, wherein step (1) further includes allowing a user to modify existing rules which are then treated as said inputted rule.

16. A computer-basal method for storing rules utilized by an externally and internally event driven application program for calculating risk and exposure variables for an institution, wherein the rules are stored as objects in a data base, the method comprising the steps of:

(1) converting a risk and exposure rule in the form of a mathematical or a logical formula having variables to a table format, wherein each of said variables in said rule is decomposed into a rule previously converted into said table format, a program for retrieving a primitive data value for each said variable or a program for calculating a value for each said variable; and

(2) storing said table as an object in said data base.

17. The computer-based method of claim 16, wherein step (1) is repeated for each of said variables which decomposes into a rule, until all rules have been decomposed into programs for retrieving primitive data values, programs for calculating a value or a rule previously converted into said table format.

Description Submit all comments and votes

DESCRIPTION

1. Technical Field

The present invention relates in general to rule-based management information systems and in particular to financial and banking management information systems for determining financial risk and exposure.

2. Related Art

There is a need for financial institutions to understand the effects of the ever changing domestic and global economic forces in order to maximize return on investments and assets. This means that the institutions must do an excellent job of managing risks across all of their lines of business and products. Financial institutions of all sizes use risk and exposure management information to make decisions about business transactions which affect their capital base and income.

Many of the formulas or rules which institutions use to calculate risk and exposure are among the most closely guarded secrets of those institutions. Also, the rules used for risk and exposure calculations are frequently modified and new rules are frequently created.

Typical management information (computer) systems which are utilized by institutions to perform risk and exposure calculations and analysis are complex software/hardware systems.

Though the actual rules (formulas) used to calculate risk are often mathematically (or logically) quite simple, they are ordinarily buried so deeply in the software that only a programming expert can locate a rule in the system, let alone modify a rule within the system. Further, because a typical management information system (MIS) is quite complex with many interdependencies among its software and hardware parts, any modifications are ordinarily left to software experts because an error in creating or changing a rule can affect an entire system. Because the rules are present in the software, only a software expert can confidently deal with them and, thus, minimize the possibility of an error being made.

There is a need for a system to perform risk and exposure calculations based upon rules which can be created and modified by business professionals (without software or extensive computer expertise) within a financial institution. In that way, a financial institution will consider itself more secure because an outsider (who may want to misappropriate the secret rules) will not be exposed to is highly confidential risk rules.

There is a further need that the risk and exposure rules within such a system be created and stored in a way such that a business professional, and not a software expert, can create and modify the rules.

DISCLOSURE OF INVENTION

SUMMARY OF THE INVENTION

The present invention, which overcomes the foregoing deficiencies, is a rule-based computer application structure which utilizes rules which are stored separately from the application program. Having the rules stored separately from the application program permits the user, a non-technical person, to easily modify existing rules and create new rules.

Though the invention can be applied to many types of rule-based (or even expert) systems for any type of industry or vertical market, a preferred embodiment encompasses a Risk Analysis System for a financial institution. The Risk Analysis System embodiment of the present invention performs risks and exposure calculations (both mathematical and logical) for the institution based upon the institution's risk and exposure rules, current market information, and other data stored in a Management Information Database (database). Preferably, the system is based upon International Business Machines' CMIM information architecture.

The rules are stored in a database as objects. When the system is to perform a risk calculation based upon a specific rule, the application program retrieves that rule from the database. The rule is stored in the database in the form of a table. The application program then performs a calculation based upon the retrieved rule. The primitive values used to process the rule are stored and can be modified by a user to run "what-if" scenarios. The table structure permits nested mathematical formulas using objects (including rules) as variables. More complex mathematical formulas can be stored as programs but accessed in the same manner as an object.

Another aspect of the system allows a user to modify existing rules and create new rules. The rule is presented to the user in an easily understandable table format. Using menu driven selections, the user can modify an existing rule or create a new rule. The system then converts that rule into the storage form so the rule can be stored, or restored, in the database for use by the application program.

Because the rules are stored as objects in the database, they are easy to locate and retrieve. Access to all objects is through a standard interface. The system utilizes common access programs for primitive objects. This is unlike a typical rule-based system where the rules are deeply buried in the application program and can only be located and recognized by a skilled programmer. Further, because the rules are separate from the application program, modifications to the rules are easier to accomplish. The rules can be complemented and modified by a user that has little or no programming or software expertise.

The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention, as illustrated in the accompanying drawings.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a computer system employing a preferred environment of the present invention.

FIG. 2 is a block diagram of the rule and object/program structure of a preferred embodiment of the present invention.

FIG. 3 is an object table.

FIG. 4 is an object instance table.

FIG. 5 is a pictorial representation of the presentation form of a rule utilized in a preferred embodiment of the present invention.

FIG. 6 is an overview of the functions supported by CMIM.

FIG. 7 is a diagrammatic representation of the data flow of a preferred embodiment of the present invention.

FIG. 8 shows the elements used in FIGS. 9-14.

FIG. 9-12 are process diagrams for a preferred embodiment of the present invention.

FIGS. 13 and 14 are data flow diagrams for a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In general, the present invention in a preferred embodiment is a rule-based computer-based application structure for the interpretation, calculation and/or presentation of information for a corporate management information system. The invention addresses the need to provide a dynamic environment to define rules to manage financial risk. It uniquely addresses this requirement by providing a structure whereby business professionals (without programming or software expertise) can define exposure and risk rules by creating an object-based reference system for financial data. The present invention solves the problem of rule logic being stored in a complex application programming which is not accessible by a business professional unless they have extensive software or programming expertise.

The preferred embodiment of the present invention is a MIS for financial applications. However, the present invention is not limited to financial applications, but can be employed in any industry or vertical market where a rule-based computer system finds application.

PREFERRED ENVIRONMENT

The present invention was developed for use in a Global Risk Management System (GRMS). GRMS is designed to provide financial institutions the functional and system capabilities to support a cross-enterprise view of risk management information. GRMS allows a financial institution to implement risk management in a consistent and timely manner, taking into account the dynamics of the marketplace.

GRMS interfaces with operational systems and management information systems. Operational systems provide GRMS with business event data in the form of transactions or balance updates. Management information systems provide GRMS with reference data such as: product, organization, and economic data. GRMS also interfaces with market data providers to obtain information such as, for example: foreign exchange rates, market prices and counter party ratings. All of this data is collected by the system in order to create the reports needed by management to make decisions.

GRMS was developed as a corporate management information system application based upon the data architecture outlined by the Corporate Management Information Model (CMIM) sold by the IBM Corporation of Armonk, N.Y., USA, under product identification No. 5799-T8W and described in IBM brochure No. D5206836.

A typical GRMS structure (architecture) is shown in block diagram form in FIG. 1. A system 100 contains a host processor 106 which accesses GRMS applications 108 and other operational systems in communications to support remote local area networks 120. GRMS 108 is intended to function on the same host system as other Corporate Management Information System (CMIS) applications, but it can be standalone if desired.

The specific hardware and line protocol for the typical GRMS configuration of the present invention is as follows (all components are IBM unless otherwise noted):

102 3390 Direct Access Storage Device

104 n/a

106 ES/9000 or System 3090 Host Processor

108 ES/9000 or System 3090 Region

110 PS/2 workstation

112 4029 printer

114 LU6.2 Application to Application Program protocol

116 3745 Communication Controller

118 PS/2 workstation

112 IBM Token Ring

122 4029 printer

124 LU6.2 Application to Application Program protocol

124 ES/9000 or System 3090 Host Processor

126 IBM 6611 Network Processor

126 ES/9000 or System 3090 Host Processor

128 LU6.2 Application to Application Program protocol

In general, GRMS 108 is an event driven system. All significant inputs are treated as events that GRMS must process and analyze to produce information for exposure and risk management. Systems throughout an institution utilizing GRMS can generate transaction records and files that GRMS will receive and queue for analysis. The term "queu" means putting into a list where the items in the list are processed in a first in first out order.

Transactions will be placed in a queue and evaluated for event type. An event type is a type of business activity such as the repayment of a loan or an interest rate increase. When the event type is determined, the routing of the event is determined by GRMS 108. A business event may be analyzed multiple times for different scenarios. The scenario is the set of rules and data that must be acquired to perform an exposure and risk calculation. When the rules and data are acquired, the calculations are performed.

Files sent to GRMS from external sources will also be processed into discrete events. A file is a structural collection of information that is comprised of records. GRMS 108 will decompose the files into event messages that will be processed through the GRMS system. Each file can be recognized into this system of event messages following a set of rules established for the file type.

Data and rules will be stored in the GRMS database 102. The data will be stored as a relational database, preferably utilizing the IBM database DB2 or other comparable relational database, and are part of the CMIS database 102. Rules for GRMS will be stored as objects in the database. The term "object" is an abstraction (like a variable in mathematics) that represents a value that is returned by an associated retrieval program. The object concept of the present invention allows the rule to be reused for different data applicable to many types of events.

Once the calculation is performed in GRMS, the result of the calculation is passed to a result handler. The result handler will also have rules to follow for the disposition of the result. Results can cause an update to the CMIS database 102, a long report to be created and routed to one or many people of the organization, or no further action.

A business professional may also request an ad hoc report. This request is converted into an event that GRMS 108 will process in the same manner. The report request enters a queue and is recognized as a report event. The data and rules for the report are acquired and passed to the GRMS Processor. When the results are generated, the information (result) is handled accordingly to the rules for the report. Typically, the report is then sent to a distribution list in a prescribed format.

The GRMS work station (e.g. 118) allows the business professional to enter transactions for GRMS via graphical screens. The work station 118 has the ability to view and print through ports delivered to it. This work station 118 can also be used to analyze exposure and risk data locally using rules and work station analytical tools. The business professional can then add her own preferred tools such as spreadsheets, financial modelers, and graphic tools, and utilize the GRMS data generated in a query or report.

The GRMS calendar function has the ability to store event messages. Each message will have time and date parameters associated with it. When that time and date occurs, the calendar function will initiate at the event message. GRMS 108 will process the event message and utilize the rules that are stored for that event. The events triggered by such a message could include a mark-to-market activity after an exchange closing, generation of a report for the individual accounting, or an initiation of a query outside of the GRMS system 108 to a market information provider. These events will flow through the GRMS system 108 in the same manner as all other events and utilize the rule concept.

Rule-Based Concept

A key aspect of the present invention as implemented in the GRMS 108 is its ability to permit business professionals (without programming or software expertise) to specify rules which are translated into a system form for execution by application programs within the GRMS environment.

The selection of the rules is based on two criteria:

(1) elements that are unique or proprietary to the financial institutions (such as exposure and risk rules and behavior conditions); and

(2) elements that are necessary for GRMS growth in supporting new system feeds (using the information format mapping) in new products (specified by product-like life cycle definitions).

The rules concept permits the installed GRMS 108 solution to be altered and amended according to the business professional's specifications in these key areas without requiring massive modifications to the system.

The GRMS system 108 is rule-enabled, in that its internal design and implementation structure supports the rule execution concept. The storage form of these rules is a relational database of the data and logic needed by the system 100 to execute the rules.

The enabling for calculation and-behavior rule has two levels.

There is a high-level relational data structure of objects and simple operations (object operators can be either logical (when . . . and . . . then . . .) or mathematical (+, .sub.-, *, /) depending on context) that are used to combine the values of the objects. At this level, objects can be defined in terms of other objects (which implements a nested expression concept) or can be linked directly to an associated program that is called to retrieve the object's value in rule execution.

The lower-level tier consists of these associated programs that derive the values for the data objects. These programs can be simple retrievals of data (e.g., attribute values from CMIM entities) or complex calculations such as an option pricing rule (which in turn may use the object structure to retrieve values for its calculation processing).

The GRMS architecture enables an object-based reference system for financial data. GRMS is a based on the IBM Corporate Management Information Model (CMIM) as the information architecture for the institution. An information architecture is a defined general structure for the institution's data. The structure consists of entities, relationships and attributes. Entities are items of data, such as "product" or "account". Within the actual database these entities have many representations; for example "product" could have representations "personal loan" "certificate of deposit" "checking account". Relationships are expressions about how the entities are related to one another.

For example, "product" would be related to multiple representations of "account". This would be known as a one to many relationship.

Attributes are individual factors that make up an entity. For example, "Product" could have attributes of "Product type", "Product Owner", etc.

In accessing the database, it is the values of the attributes of the entities that is the goal. A particular entity representation is located by navigating through the entities through the paths defined by the relationships of the information architecture.

GRMS 108 includes a general accessing program that uses as parameters the identifiers for the seminal entities of CMIM: PRODUCT, MANAGEMENT UNIT, GEOGRAPHIC REGION, LEGAL PARTICIPANT, CUSTOMER, CUSTOMER ACCOUNT, FIRM ACCOUNT, PORTFOLIO, MARKET SEGMENT, USER DEFINED FACILITY.

These entities are important because there is a path from one, multiple or a combination of them to each entity in a database modelled on CMIM. Thus a common accessing routine is used that uses as parameters, the entity identifier and attribute identifier desired along with the values of the seminal entities listed above. The accessing program returns the value of the attribute along with a return code signifying the result of the access processing (e.g. "successful", "entity representation does not exist", etc.). In this way, a standard accessing layer to the institution's data exists and, therefore, all the attributes of the database are available via this layer. This layer is shown in FIG. 2 in the boxes labeled "Retrieve Value" 220, 222, 232, and 234.

GRMs adds a table driven structure in front of these accessing programs so that the attribute representations can be referenced by name; these names can be thought of as variables that would appear in mathematical formulas. An example of this table is shown in FIG. 3. The names or "objects" are shown in the columns "OBJECT" 302, "OBJECT1" 304 and "OBJECT2" 308. These names or "objects" stand for a multitude of particular instances of the data, any of which can be retrieved by specifying the identifiers of the entities listed above which would focus the access on a particular representation value.

Also illustrated in the Table in FIG. 3 is the capturing of a complex formula as an object in the system. The processing of the object table 300 will result in a call to the program listed in the PROGRAM column 310. In the case of CMIM attributes, this program will be a generalized accessing program. However, the program could also be one that does a complex calculation; in the case of the one illustrated in FIG. 3, the program is named "Black.sub.-- Scholes.sub.-- Pgm" 312, which is a program that would use the standard Black-Scholes algorithm to calculate the value of the option at a point in time. Please note that the Black-Scholes Algorithm involves the use of integral calculus and therefore could not be represented in the Object table structure. However, its complex algorithm is encoded as a program and then referenced as an object through the normal mechanisms of the program.

FIG. 2 illustrates a sample rule 202 and shows the equivalent object structure in a tree-like representation 200. The high-level rule (option.sub.-- exposure=currency.sub.-- conv.sub.-- rate * option.sub.-- value 202) calculates the exposure of an option (option.sub.-- exposure 204) as the currency conversion rate (currency.sub.-- conv.sub.-- rate 210) multiplied ("*"206) by the value of the option (option.sub.-- value 208).

The currency conversion rate (currency.sub.-- conv.sub.-- rate 210), in turn, is expressed as another rule: currency spot rate (currency.sub.-- spot.sub.-- rate 228) minus ("-"226) currency exchange rate (currency.sub.-- exch.sub.-- rate 230). Those two objects are obtained by direct retrieval programs 232 and 234 from the databases. The currency spot exchange is retrieved from a market information database 236, while the currency exchange rate is obtained from the CMIM database 224. The direct retrieval programs (220, 222, 232 and 234), preferably written in a structured query language (e.g. SQL), utilize the key structure defined by CMIM to access the requested values from the data base 224.

The value of the option (option.sub.-- value 208) illustrates an object that is a more complex program that utilizes objects within its logic. These objects, shown as the option's strike price (option-strike-price 216) and the option's duration (option-duration 218), are obtained by accessing the object table in the programs that are associated with those objects.

Turning to FIG. 3, the object table 300 for the rule of FIG. 2 is shown. The first line of the table 314 expresses the concept that the option exposure is composed of the currency conversion rate (object 1 304) multiplied (operator 306) by the option.sub.-- value (object 2 308). No program is involved at that level. The second line of the table 316 shows that the currency conversion rate decomposes into the sum of the currency spot rate minus the currency exchange rate. Again, no program is involved at that level. The third line of the table 318 shows that the currency spot rate is obtained by the program IMDCSE01 320.

Similarly, the fourth line of the table 322 shows that the currency exchange rate is obtained from the program IMDCEF10 324. The fifth line of the table 326 shows that the option value is obtained from a program called Black Scholes (Black.sub.-- Scholes.sub.-- Pgm) 312 (a well known complex financial calculation). The sixth line of the table 328 shows that the option duration is obtained by the program IMDCMI22 322. The last line 330 of the table shows that the option strike price is obtained by the program IMDCMI27 334.

Conceptually, the present invention can be divided into two parts:

(1) the definition environment, and

(2) the execution environment.

In the definition environment, rules can be created and modified. In the execution environment application programs utilize the rules to perform risk calculations.

In the definition environment, rules exist in three forms.

The presentation form of a rule is the form in which the rule, shown in FIG. 5, is presented to a user. This format is intended to provide a business professional, not a computer programmer, with an easy to understand expression of the rule. This is the format in which the business professional can modify existing rules or create new rules.

In the execution environment the business professional (user) is presented with a menu-driven interface 500 to define exposure and risk rules. A set of primitive objects are defined within the system and appear as selecting choices for the business professional, as shown in FIG. 5. The operator choices are: curr.sub.-- conv.sub.-- rate, volume, unit, fut.sub.-- conv.sub.-- rate. The operand choices in this example are: arithmetic, (.sub.-- -/*). In this example, the rule defined is: option.sub.-- exp=currency.sub.-- conv.sub.-- rate * option.sub.-- value. The objects curr.sub.-- cony.sub.-- rate 516 and option.sub.-- value 514 were already defined in the object table 300. Currency.sub.-- Conv.sub.-- Rate is a complex object that decomposes into two primitive objects: Currency.sub.-- Spot.sub.-- Exch and Currency.sub.-- Exch.sub.-- fee. Option.sub.-- Value is a primitive object and is related to a complex program Black.sub.-- Scholes.sub.-- Pgm 312.

The storage form of a rule, shown in FIG. 3, is in the form of a table 300, which is the format in which the rule is stored in the database. This is the format which application programs obtain from the data base in the same manner other objects are obtained. The application program can then process the table to execute the rule it represents.

The language form of the rule 350 is an intermediary step between the presentation form and the storage form. The language form allows changes made in the presentation form to be quickly and easily mapped into the storage form.

The system 108 internally edits the business professional selection prior to transforming the rule from presentation to storage form. Two general types of editing are performed:

Rule Decomposition Editing: ensures the rules are decomposed into defined primitive objects (for example, data access programs or complex formulas.

Language Construct Editing: ensures the rule is constructed within the defined language formats. (for example, operator, operand, operator)

Once the business professional's rule is edited and accepted, the system 108 loads the database 102 based upon defined table structures.

The concept of presenting a user with an easily understandable form of a rule which can be easily modified and then converted into a self contained storage form of the rule allows for ease of change to the rules and ease of creation of new rules. No changes need to be made to the underlying application software. No particular expertise in programming is required to modify or create rules.

AN EXAMPLE OF THE OPERATION OF GRMS

A Business Professional (the user) would want to create a new formula for the calculation of the exposure value of an option. The formula is shown in FIG. 2 as 202. The eventual result of his creation is the table shown in FIG. 3. The table at the beginning of the operation would consist of only the five lower rows of the table 318, 322, 326, 328 and 330. The result of the operation would be the addition of the first two rows 314, 316.

The user would use the presentation form 500 shown in FIG. 5 to specify the formula. To do this, he would first create an object called "Option Exposure" 510. He would then choose that it is an expression, and would be given a screen 512 from which he would specify the two "object" (like mathematical variables) involved in the expression and the operator. In this case, he would create a new object, "Currency.sub.-- Conversion.sub.-- Rate" 516 as one object, select "X" 518 (multiplication) as the operator, and select an existing object, "Option.sub.-- Value" 514 as the second object of the expression. The data resulting from this is the first row of the table 314 in FIG. 3.

Since the user has specified a new object "Currency.sub.-- Conv.sub.-- Rate" 516 (an object not previously defined), in a similar way to the "Option.sub.-- Exposure" flow, the Business Professional would select one existing object "Currency.sub.-- Spot.sub.-- Rate" the operator "-" (minus) and a second object "Currency.sub.-- Exch.sub.-- Rate" in order to define the new object within the table 300. The result of this set of actions is the second row of the table 316. At this point, the formula is complete, because all objects in the formula exist in the object table. Note that the "Black.sub.-- Scholes.sub.-- Pgm" referenced in the table 300, will also want to access objects in the table 300 in the course of its execution.

At this point, the Business Professional would want to test the formula to see the values it produces in order to confirm that it produces the desired result. The user specifies a specific product identifier (such as FXYN10735) which could represent a Foreign Exchange Option in YEN for a specific customer by customer identifier (such as CUST003002 for John Smith). This is accomplished by the user via a graphic screen interface 500 entering the identifiers and the system 108 retrieves the values of the entities needed for accessing the database and processes the rule against that data. In this case, it could be (for example):

______________________________________ PRODUCT "FXYN10735" MANAGEMENT UNIT, "FX Trading" GEOGRAPHIC REGION, "Japan" LEGAL PARTICIPANT, null CUSTOMER, "CUST003002" CUSTOMER ACCOUNT, "GL00112" FIRM ACCOUNT, "Corp.XYZ" PORTFOLIO, "CUST003002" MARKET SEGMENT, "Yen" USER DEFINED FACILITY null ______________________________________

where FXYN10735 is the identifier foreign exchange option in yen and CUST003002 is the identifier for John Smith.

This would be used as the standard access list for the accessing program to use in obtaining the values of the various objects in the table 300.

At this point, the evaluation of OPTION.sub.-- EXPOSURE 300 for the specific option would begin. The GRMS processor 108 would start with the first row of the table in FIG. 3. Since the entries for the columns under OBJECT1 304 and OBJECT2 308 are not null, the processor would attempt to obtain the values for the objects in these columns ("CURRENCY.sub.-- CONV.sub.-- RATE" and "OPTION.sub.-- VALUE") before continuing with the evaluation of the expression. In a recursive way, the processor 108 would search for the first object, "CURRENCY CONV RATE", which is defined as another expression in row 2 of the table. The processor would again recursively call the table 300 to obtain the value for object "Currency.sub.-- Spot.sub.-- Exch", which is defined in row 3 of the table 300.

"Currency.sub.-- Spot.sub.-- Exch" has "