 |
Claims  |
|
|
Having thus described our invention, what we claim as new and desire to
secure by Letters Patent is:
1. A computer program product for use with a relational database for
storing rules and data and for use with a display, said computer program
product comprising:
a computer usable medium having a computer readable program code means
embodied in said medium for enabling a computer to perform risk and
exposure calculations in accordance with rules stored as objects in the
relational database, said computer readable program code means comprising:
computer readable first program code means for enabling said computer to
display rules to perform risk and exposure calculations in a presentation
format on the display 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;
computer readable second program code means to enable said computer to
translate rules in a presentation format to rules in a table format, and
for storing said rules in a table format as objects in the relational
database; and
computer readable third program code means for enabling said computer to
retrieve said rules in a table format stored as objects in the relational
database and to perform calculations according to said rules in a table
format using said stored data, said computer readable third program code
means including,
computer readable fourth program code means for enabling said computer to
respond to external and internal events, and
computer readable fifth program code means for enabling said computer to
retrieve said stored rules and data with predetermined keys.
2. The computer program product of claim 1, wherein said rules in a
presentation format include variables and said computer readable second
program code 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.
3. The computer program product of claim 2, wherein said computer readable
third program code means further includes means for retrieving preselected
ones of said rules in said table format for the relational database and
performing a calculation defined by said preselected ones of said rules in
said table format.
4. The computer program product of claim 3, further including what-if means
for storing primitive data values retrieving a primitive data value, for
allowing a user to manipulate said primitive data values re-perform
calculations according to said rules in said table format using said
manipulated primitive data values.
5. The computer program product of claim 3, wherein said rules stored as
tables in the relational database can be retrieved as objects.
6. A computer program product for use with a relational database for
storing rules, said computer program product comprising:
a computer usable medium having a computer readable program code means
embodied in said medium for enabling a computer to perform calculations in
accordance with rules stored as objects in the relational database, said
computer readable program code means comprising:
computer readable first program code means for causing said computer to
input one of a mathematical and a logical rule which defines a
calculation, said rule including variables;
computer readable second program code means for causing said computer to
convert said rule into a table which also defines said calculation;
computer readable third program code means for causing said computer to
store said table as an object in the relational database; and
an application program for retrieving said table from the relational
database: and performing said calculations defined in said table using
said stored data, said application 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.
7. The computer program product of claim 6, wherein said computer readable
first program code means includes interactive means for allowing a user to
create new rules and modify exiting rules.
8. The computer program product of claim 7, wherein including a program for
retrieving said table from the relational database and performing said
calculation defined by said table.
9. The computer program product of claim 8, wherein said computer readable
second program code means 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.
10. The computer program product of claim 9, 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.
11. A program storage device readable by a computer system, tangibly
embodying a program of instructions executable by said computer system to
perform method steps for enabling said computer system to respond to
external and internal events, to store rules as objects in an object based
computer database, to retrieve and execute the stored rules, and retrieve
stored data to calculate risk and exposure variables, said method steps
comprising:
(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 database;
(4) retrieving said table of step (3) from the database;
(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).
12. The program storage device of claim 11, 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.
13. The program storage device of claim 12, 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.
14. The program storage device of claim 12, wherein step (1) further
includes allowing a user to modify existing rules which are then treated
as said inputted rule.
15. A program storage device readable by a computer system, tangibly
embodying a program of instructions executable by said computer system to
perform method steps for enabling said computer system, to store rules
utilized by application programs, wherein the rules are stored as objects
in a database, said method steps comprising:
(1) converting a 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 database.
16. The program storage device of claim 15, 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. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
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 FIGURE 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.-- conv.sub.-- rate 516 and option.sub.-- value 514 were already
defined in the object table 300. Currency.sub.-- Cony.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):
___________________ | | |
