CA 02312641 2000-06-23
-1 a-
System, Method, and Computer Program Product
For Providing User-Defined Customization in the
Evaluation of Credit Worthiness
Background of the Invention
Field of the Invention
The present invention relates generally to evaluating consumer and
business credit worthiness, and more particularly to greatly facilitate and
enhance
users' ability to rapidly modify, customize, and fine tune the consumer and
business credit worthiness evaluation process.
Related Art
Computer and software based credit evaluation and decisioning systems
are one of the many elements that are reshaping today's loan industry. Using
computer and software based systems to automate portions of the credit
decisioning process has been occurring since the 1970's, and has grown
increasingly move common over the past twenty years. While certain financial
institutions may continue even today to decision certain categories of credit
applications in a manual environment without the assistance of automated
computerized tools, today's computerized software credit evaluation and
decisioning systems are used widely by all but the smallest financial
institutions,
or other credit grantors, in industries such as credit card, auto lending, or
home
equity lending. Today's computer and software based credit evaluation and
decisioning systems automate some portion of the processes associated with the
workflow that the credit granting institution follows when it receives,
evaluates,
decisions, and records the ultimate outcome of credit applications. In
addition to
automation of the credit evaluation and decisioning workflow, the computer and
software based credit evaluation and decisioning systems incorporate the
business
CA 02312641 2000-06-23
-2-
logic utilized to evaluate and decision the application, and a database in
which
data elements utilized by the system during the credit evaluation and
decisioning
process are stored.
Generally, the business logic in today's credit decisioning engines is very
limited in terms of the extent to which users of the system can modify its
functionality without needing to modify the software code underlying the
system.
This means that the system is limited to business logic initially incorporated
in
the system. When it was designed, or to new business logic that can only be
implemented afterthe software code is modified. Both alternatives impose major
limitations on the, credit grantor's ability to quickly modify or fine tune
its credit
evaluation and decisioning process to respond to changing market conditions,
new competitive pressures, and/or new credit product introductions.
Additionally, because in today's computer and software based credit evaluation
and decisioning systems the credit decisioning engine typically is closely
1 S integrated with the work-flow and database components of the system, the
credit
decisioning engine generally cannot be modified without also requiring
corresponding modifications to be made to a system's workflow and database.
Credit granting institutions today are looking to credit decisioning engines
to enhance competitiveness and the ability to quickly respond to changing
market
conditions through, among other things, improving loan volumes by increasing
the percentage of credit applications that can be automatically decisioned
(i.e.,
decisioned without hwnan involvement in the decisioning process), facilitating
more effective pricing strategies, improving credit risk through user-
controlled
lending criteria, expanding business through cross-product approval, and
allowing
the credit decisioning engine to be independent from, and capable of
integration
with, various different workflow systems and databases. Credit decision
engines
today are limited in the extent to which they can address these objectives to
the
extent that they are, among other things, limited by the table structure, and
table
access and hierarchy which has been hard coded into the system, and integrated
as inextricable components from a credit evaluation and decisioning system's
workflow and database. What is needed is a method and system which allows
CA 02312641 2000-06-23
-3-
users, without the necessity for changing a credit decisioning engine's
software
code, to be able to manipulate and combine data elements in ways that permit
the
users to build rules, tables and matrices that support new business
strategies.
What is also needed is a way for users to be able to utilize credit
decisioning
engines as distinct and independent software modules, so that they can be
modified without necessarily requiring corresponding modifications in the
workflow and database components of the credit evaluation and decisioning
system, and so that the credit decisioning engines can be integrated with
different
workflow and database systems.
1 o Summary of the Invention
The present invention is a system, method, computer program product,
and combinations thereof, that allows for user-defined customization in the
evaluation of credit worthiness of both consumer and business applications.
The system for the evaluation of credit worthiness of the present invention
includes a credit evaluation customization system that acts as an analysis
engine,
where the analysis engine executes a request in the evaluation of consumer and
business credit worthiness. The system may also include a front end system
that
preferably provides a graphical user interface to the users of the present
invention
to access the customization system. In addition, a customization database
stores
both pre-defined and user-defined data that is used by the customization
system
in the evaluation of credit worthiness. This data is either passed in via the
front
end system, collected by the customization system, or derived by the
customization system. The front end system also preferably provides to the
users
of the present invention a graphical user interface to customize the data
stored in
customization database.
The method of the present invention preferably involves setting up a
customization database, where the data stored in the database is used for
evaluating the credit worthiness of an application; evaluating, with a
customization system, the credit worthiness of the application by executing a
CA 02312641 2000-06-23
-4-
request; allowing users of the present invention to customize the database
data
through a front end system; and allowing the users to access the customization
system through the front end system.
Another embodiment ofthe present invention provides for allowing users
to compare credit bureau scores to custom scores.
A further embodiment of the present invention provides for a way of
providing analytical capabilities that will facilitate cross selling of
different
products.
Further features and advantages of the invention, as well as the structure
and operation of various embodiments of the invention, are described in detail
below with reference to the accompanying drawings. In the drawings, like
reference numbers generally indicate identical, functionally similar, and/or
structurally similar elements. The drawing in which an element first appears
is
indicated by the leftmost digits) in the corresponding reference number.
Brief Description of the Figures
The present invention will be described with reference to the
accompanying drawings, wherein:
FIG. 1 is a block diagram representing an operating environment
according to an embodiment of the present invention;
FIG. 2 is a block diagram of the functional modules of the present
invention connected by a network according to an embodiment of the present
invention;
FIG. 3 is a block diagram of a computer system preferably used to
implement the present invention;
FIG. 4 illustrates the dynamic steps to establish communication between
a client and a server executing an object-oriented program. For illustration
purposes, FIG. 4 is broken into nine(9) figures including FIG. 4A, FIG. 4B,
FIG.
4C, FIG. 4D, FIG. 4E, FIG. 4F, FIG. 4G, FIG. 4H and FIG. 4I;
CA 02312641 2000-06-23
-5-
FIG. 5 is a flowchart illustrating how selection sets are executed according
to an embodiment of the present invention;
FIG. 6 illustrates the various collections of data stored in a customization
database according to an embodiment of the present invention;
FIG. 7 illustrates the modules of the background modules according to an
embodiment of the present invention;
FIG. 8 illustrates the modules of the application processing modules
according to an embodiment of the present invention;
FIG. 9 illustrates an exemplary request flow that includes all of the
features of the bureau module according to an embodiment of the present
invention;
FIG. 10 illustrates an exemplary request flow that includes all of the
features of the score module according to an embodiment of the present
invention;
FIG. 11 illustrates an exemplary request flow that includes all of the
features of the price module according to an embodiment of the present
invention;
FIG. 12 illustrates an exemplary request flow that includes all of the
features of the policy module according to an embodiment of the present
invention;
FIG. 13 illustrates an exemplary request flow that includes all of the
features of the product module according to an embodiment of the present
invention;
FIG. 14 illustrates the modules of the administration modules according
to an embodiment of the present invention;
FIG. 15 illustrates an exemplary administration GUI screen for allowing
the user to administer the database according to an embodiment of the present
invention;
FIG.16 illustrates an exemplary administration GUI screen displaying the
records for a rule set table according to an embodiment of the present
invention;
CA 02312641 2000-06-23
-6-
FIG.17 illustrates an exemplary administration GUI screen displaying the
records for a rule set list table according to an embodiment of the present
invention;
FIG.18 illustrates an exemplary administration GUI screen displaying the
records for a scorecard table according to an embodiment of the present
invention;
FIG.19 illustrates an exemplary administration GUI screen displaying the
records for a matrix table according to an embodiment of the present
invention;
FIG. 20 illustrates an exemplary expression builder GUI screen according
to an embodiment of the present invention;
FIG. 21 is an exemplary expression builder GUI screen illustrating
subfiles and a syntax checker according to an embodiment of the present
invention;
FIG. 22 is an exemplary expression builder GUI screen illustrating the
building elements of the operator folder according to an embodiment of the
present invention;
FIG. 23 is an exemplary expression builder GUI screen illustrating the
building elements of the constants folder according to an embodiment of the
present invention;
FIG. 24 is an exemplary expression builder GUI screen illustrating the
building elements of the functions folder according to an embodiment of the
present invention;
FIG. 25 is an exemplary expression builder GUI screen illustrating the
building elements of the expression folder according to an embodiment of the
present invention;
FIG. 26 is an exemplary expression builder GUI screen illustrating the
building elements of the characteristic folder according to an embodiment of
the
present invention;
FIG. 27 illustrates an exemplary rule set builder GUI screen according to
an embodiment of the present invention;
CA 02312641 2000-06-23
_7_
FIG. 28 illustrates an exemplary rule set list builder GUI screen according
to an embodiment of the present invention;
FIG. 29 illustrates an exemplary scorecard builder GUI screen according
to an embodiment of the present invention;
FIG. 30 is an exemplary scorecard builder GUI screen illustrating example
attributes of a characteristic according to an embodiment of the present
invention;
FIG. 31 is an exemplary scorecard builder GUI screen illustrating the
challenger input window according to an embodiment of the present invention;
FIG. 32 is an exemplary scorecard builder GUI screen illustrating the
usage input window according to an embodiment of the present invention;
FIG. 33 illustrates an exemplary matrix builder GUI screen according to
an embodiment of the present invention; and
FIG. 34 illustrates an exemplary request builder GUI screen according to
an embodiment of the present invention.
CA 02312641 2000-06-23
_g_
Detailed Description of the Preferred Embodiments
1. Overview of The Present Invention
If a user desires, based on its own present and anticipated future business
requirements, to automatically evaluate the credit worthiness of an
application,
the present offers a way to customize such evaluations. More specifically, the
present invention greatly facilitates and enhances the ability of users within
a
credit granting institution to rapidly modify, customize and fine tune the
business
logic embodied in computer and software based consumer and business credit
evaluation and decisioning systems. This business logic typically incorporates
some or all of the following five categories of functionality: (1) retrieving
and
analyzing a credit bureau report on a credit applicant from a credit data
repository
(e.g., Equifax, TransUnion or Experian), (2) scoring the credit bureau report
by
attributing a numerical value to it based on a scorecard utilized by the
credit
granting institution to predict all applicant's credit performance, (3)
applying
pricing criteria that determine the interest rate and term applicable to the
credit
application, (4) applying business and policy rules that guide the conditions
under
which a credit granting institution may approve or decline a credit
application,
and (5) applying rules and strategies that facilitate cross-selling of
additional or
alternative products to the product for which the application was originally
submitted (e.g., an application submitted for an automobile loan may also
return
an option for an automobile lease, and/or include an offer for the applicant
to
open a credit card account).
The business logic in a computer and software based credit evaluation and
decisioning system relating to the five functional areas of credit bureau
retrieval
and analysis, scoring, pricing, policies, and product is typically referred to
as a
system's credit decisioning engine. The present invention thus contemplates a
credit evaluation customization system 105, a front end system 110, and a
customization database as shown in FIG. 1 and described in detail below.
CA 02312641 2000-06-23
-9-
11. Terminology
Before further describing the present invention, the following terms used
herein below are first defined. These definitions are provided for
illustrative
purposes only, and to aid the reader in understanding the invention. The
definitions are not intended to be all-inclusive.
Application - An initial statement of personal and financial information
required to apply for a loan. An applicant can be either a consumer or a
business.
Credit Report - A report detailing the credit history of a prospective
borrower that is used to help determine borrower credit worthiness.
Lender - The bank, mortgage company, mortgage broker, or other credit
grantor, offering the loan. A lender is a typical user of the present
invention.
Attribute (weight) - A numeric value, positive or negative, that is
evaluated for a characteristic of a scorecard and added to an overall score.
The
following sample illustrates three attributes for a characteristic:
Value from Characteristic One~rato_r Parameter Points
X < 1 0
X <= 10 6
> 10 12
Grade - An overall indicator of an application's credit worthiness.
Decision Status - A status assigned to the application based on the grade.
Valid decision statures include Approve, Pending Approval, Pending, Pending
Decline, and Decline.
Loan to Value (LTV) - The ratio of the loan amount to the value of a
property. For example, a loan of $200,000 on a property valued at $400,000 is
at an LTV of 50%.
Score - Value that measures the relative degree of risk an applicant
represents to the lender.
Scorecard - Forecasts an applicant's credit performance on actual credit
data.
CA 02312641 2000-06-23
-10-
Rule - A calculation, database field, complex rule (combination of
existing rules), or scorecard. A rule can return any data type, except for
complex
rules which return an indication of "pass" or "fail."
Complex Rule - A rule created by combining existing rules. Each rule
in the combination uses its own evaluation logic, creating a component. "AND"
or "OR" must be assigned between each component. Components may be
grouped using parenthesis. An example is: (Rule 1 = "ABC" AND Rule2 < 10)
OR Rule3 in ("X,Y,Z"). Allowable operators are: _, <, <_, >, >_. The result of
a complex rule is an indication of "pass" or "fail."
Rule Set - A collection of rules. Each rule in the rule set is evaluated
against a parameter, returning a "pass" or "fail."
Rule Set List - A collection of rule sets.
Group - A collection of rule set lists.
Selection Rules - A rule or rule set used to select valid features, rule sets,
or rule set lists.
Characteristic - Component of a scorecard, and its logic (interpretation
of bureau or application data). A characteristic may return a positive number
or
a string. For example, the characteristic "Number of Bureau Trades" can return
a number. The characteristic "Type of Bank Accounts" can return the strings
"none," "checking," "savings," or "both." Other values returned by a
characteristic may include: "no bureau," "no hit," "no inquiries," and "no
trade
line." Characteristics may be derived from bureau or application data, and may
be provided by the present invention or designed by a user.
Policy - Guidelines of a particular user (e.g., lender) that states its review
and lending policies. An example of a particular user's lending policy may be
"Definitely decline an application with a 45% Debt to Income Ratio."
Product - Vehicle Loan, Vehicle Lease, Home Equity Loan, Credit Card,
etc.
Request - Both pre-defined by the present invention and customized by
the user. A request lists the option features (of a module) and the order in
which
CA 02312641 2000-06-23
-11-
to execute the features that will take part in the evaluation of the credit
worthiness
of an application.
Program - Provides a way of organizing fixed rate sheets, variable rates,
credit limits, and deposit amounts.
Ill. System Architecture
A. System Architecture Overview
FIG.1 is a block diagram representing an example operating environment
of the present invention. It should be understood that the example operating
environment in FIG. 1 is shown for illustrative purposes only and does not
limit
the invention. Other implementations of the operating environment described
herein will be apparent to persons skilled in the relevant arts) based on the
teachings contained herein, and the invention is directed to such other
implementations. Referring to FIG. 1, a credit evaluation customization system
105, a front end system 110, a customization database 115, the global Internet
120, credit bureaus 125, and dealerships 130 according to an embodiment of the
present invention, are shown.
An embodiment of the functional components of the present invention
includes customization system 105, front end system 110, and database 115.
Customization system 105 acts as an analysis engine for the present invention
in
the evaluation of consumer and business credit worthiness. Customization
system 105 is connected to front end system 110. Front end system 110 may
provide a graphical user interface (GUI) to users of customization system 105.
Although the embodiment of the present invention shown in FIG. 1 illustrates
customization system 105, front end system 110, and database 115 as separate
functional components, several (or all) components may be combined as long as
the functionality of each component still exists within the present invention
as
will be described below.
CA 02312641 2000-06-23
-12-
Data needed to perform all features of the present invention is either
passed in via front end system 110, collected by customization system 105, or
derived by customization system I 05. Requests can be made by front end system
I 10 to customization system 105 at any time as long as customization system
105
has the data to process the request. Thus, the various functions provided by
the
present invention are not dependent on the source of the data.
Front end system 110 may also operate as a Web server. A Web server
provides the GUI to users of customization system 105 in the form of Web pages
when access is made via the Internet 120. As is well-known in the relevant
art(s),
a Web server is a server process running at a Web site which sends out Web
pages in response to Hypertext Transfer Protocol (HTTP) requests from remote
browsers. An optional firewall (not shown) serves as the connection and
separation between front end system 110 and the global Internet 120. Generally
speaking, a firewall--which is well-known in the relevant art(s)--is a
dedicated
gateway machine with special security precaution software. It is typically
used,
for example, to service Internet 120 connections and dial-in lines, and
protects a
cluster of more loosely administered machines hidden behind it from an
external
invasion.
Customization system 105 is also connected to database 115. Database
115 stores collections of both predefined and user-defined data required by
customization system 105. Both the functions of the engine of customization
system 105 and the data stored in database 115 will be discussed in further
detail
below.
The global Internet 120 includes a plurality of external workstations that,
not only allow users of the Internet 120 to remotely access and use
customization
system 105, but also allows customization system 105 to access the external
workstations. In essence, both credit bureaus 125 and dealerships 130 may use
an external workstation to interact with customization system 105.
Customization system 105 and front end system 110 may interact with credit
bureaus 125 to receive actual credit data for both consumer and business
applicants. Customization system 105 and front end system 110 may interact
CA 02312641 2000-06-23
-13-
with dealerships 130 to indicate whether or not a loan has been approved for a
particular applicant. It is important to note that the present invention is
not
limited to interacting with credit bureaus 125 and dealerships 130. The
present
invention may also interact with realtor companies, and any other company that
S has an interest in obtaining loans for its customers. Also note that the
present
invention may communicate with credit bureaus 125, dealerships 130, and so
forth, via communication methods other than the Internet 120 (via TCP/IP),
including asynchronous dial up and asynchronous lease line. What is meant by
asynchronous dial up, asynchronous lease line, and TCP/IP communication is
explained next.
The term asynchronous is usually used to describe communications in
which data can be transmitted intermittently rather than in a steady stream.
For
example, a telephone conversation is asynchronous because both parties can
talk
whenever they like. If the communication were synchronous, each party would
be required to wait a specified interval before speaking. Asynchronous dial up
refers to connecting a device to a network via a modem and a public telephone
network. Asynchronous dial up access is really just like a phone connection,
except that the parties at the two ends are computer devices rather than
people.
Because asynchronous dial up access uses normal telephone lines, the quality
of
the connection is not always good and data rates are limited.
An alternative way to connect two computers is through an asynchronous
leased line, which is a permanent connection between two devices. Leased lines
provide faster throughput and better quality connections, but they are also
more
expensive.
TCP/IP is an acronym for Transmission Control Protocol/Internet
Protocol, the suite of communications protocols used to connect hosts on the
Internet 120. TCP/IP uses several protocols, the two main ones being TCP and
IP. TCP/IP is built into the UNIX operating system and is used by the Internet
120, making it the de facto standard for transmitting data over networks. Even
network operating systems that have their own protocols, such as Netware, also
support TCP/IP.
CA 02312641 2000-06-23
-14-
FIG. 2 is a block diagram of the functional modules of customization
system 1 OS preferably connected by a network according to an embodiment of
the
present invention. It should be understood that the particular customization
system 105 in FIG. 2 is shown for illustrative purposes only and does not
limit
the invention. Other implementations for performing the functions described
herein will be apparent to persons skilled in the relevant arts) based on the
teachings contained herein, and the invention is directed to such other
implementations. As will be apparent to one skilled in the relevant art(s),
all of
the modules "inside" of customization system 105 are preferably connected and
communicate via a communication medium such as a network 220.
The topology of network 220 as shown in FIG. 2 is called a bus topology.
In general, the topology of a network is the geometric arrangement of
functions
(i.e., computers) within the system. Other common types of network topologies
include star and ring topologies. Although the present invention is
illustrated in
FIG. 2 as incorporating a bus topology, the present invention can equally be
applied to other topologies.
Customization system 1 OS includes application processing modules 205,
administration modules 210, and background modules 215. Each module of
application processing modules 205 can be operated independently of the other
modules. Data needed by the present invention is either passed in via front
end
system 110, collected by customization system 1 OS, or derived by
customization
system 105. Requests can be made by front end system 110 to customization
system 105 at any time as long as customization system 105 has the data to
process the request. Thus, the various functions provided by the present
invention is not dependent on the source of the data. Connected to
customization
database 11 S is background modules 215 and administration modules 210.
Administration modules 210 is also connected to front end system 110. These
modules are described for illustrative purposes. The invention is not limited
to
these modules.
In an embodiment of the present invention, application processing
modules 205 contains five (5) modules. Each module performs a unique set of
CA 02312641 2000-06-23
-15-
processing features that are configured based on specific business
requirements
defined by the user. Such processing features include, among other features,
obtaining and evaluating credit bureau data for an application, determining a
score for the application based partly on the credit bureau data, determining
a
grade for the application based on the score, determining possible term loans
for
the application based on the grade, reviewing the application based on
specific
lender policies, and determining multiple products that the application could
qualify for. Each processing module operates in conjunction with front end
system 110 to form a complete automated credit processing solution. The
individual modules of application processing modules 205 will be described in
detail below with reference to FIG. 8.
In an embodiment of the present invention, administration modules 210
contains five (5) modules. Each module performs a unique set of administrative
features that are configured based on the specific business requirements
defined
by the user. Such administrative features include, among other features, an
interface to front end system 110, an interface to database 115, direct access
to
the various modules of customization system 105, and the ability for users to
customize system 1 OS for their particular business needs. The individual
modules
of administration modules 210 will be described in detail below with reference
to FIG. 14.
In an embodiment of the present invention, background modules 215
contains four (4) modules. Each module performs a unique set of background
features including, among other features, the evaluation of unique
circumstances,
the calculation of mathematical formulas, the requests for data from database
115,
and the ability to accept data in various formats, parse the data, and save
the data
in appropriate database tables. The individual modules of background modules
215 will be described in detail below with reference to FIG. 7.
CA 02312641 2000-06-23
-16-
B. Preferred Implementation of the Present Invention
The present invention (i.e., customization system 105, front end system
110, database 11 S, or any part thereof) may be implemented using hardware,
software or a combination thereof and may be implemented in one or more
computer systems or other processing systems. In fact, in one embodiment, the
invention is directed toward one or more computer systems capable of carrying
out the functionality described herein. An example of a computer system 300 is
shown in FIG. 3. The computer system 300 includes one or more processors,
such as processor 303. The processor 303 is connected to a communication bus
302. Various software embodiments are described in terms of this exemplary
computer system. After reading this description, it will be apparent to a
person
skilled in the relevant art how to implement the invention using other
computer
systems and/or computer architectures.
Computer system 300 also includes a main memory 305, preferably
random access memory (RAM), and may also include a secondary memory 310.
The secondary memory 310 may include, for example, a hard disk drive 312
and/or a removable storage drive 314, representing a floppy disk drive, a
magnetic tape drive, an optical disk drive, etc. The removable storage drive
314
reads from and/or writes to a removable storage unit 318 in a well known
manner.
Removable storage unit 318, represents a floppy disk, magnetic tape, optical
disk,
etc. which is read by and written to by removable storage drive 314. As will
be
appreciated, the removable storage unit 318 includes a computer usable storage
medium having stored therein computer software and/or data.
In alternative embodiments, secondary memory 310 may include other
similar means for allowing computer programs or other instructions to be
loaded
into computer system 300. Such means may include, for example, a removable
storage unit 322 and an interface 320. Examples of such may include a program
cartridge and cartridge interface {such as that found in video game devices),
a
removable memory chip (such as an EPROM, or PROM) and associated socket,
and other removable storage units 322 and interfaces 320 which allow software
CA 02312641 2000-06-23
-17-
and data to be transferred from the removable storage unit 322 to computer
system 300.
Computer system 300 may also include a communications interface 324.
Communications interface 324 allows software and data to be transferred
between
computer system 300 and external devices. Examples of communications
interface 324 may include a modem, a network interface (such as an Ethernet
card), a communications port, a PCMCIA slot and card, etc. Software and data
transferred via communications interface 324 are in the form of signals 328
which
may be electronic, electromagnetic, optical or other signals capable of being
received by communications interface 324. These signals 328 are provided to
communications interface 324 via a communications path (i.e., channel) 326.
This channel 326 carries signals 328 and may be implemented using wire or
cable, fiber optics, a phone line, a cellular phone link, an RF link and other
communications channels.
In this document, the term "computer program product" refers to
removable storage units 318, 322, and signals 328. These computer program
products are means for providing software to computer system 300. The
invention is directed to such computer program products.
Computer programs (also called computer control logic) are stored in
main memory 305, and/or secondary memory 310 and/or in computer program
products. Computer programs may also be received via communications
interface 324. Such computer programs, when executed, enable the computer
system 300 to perform the features of the present invention as discussed
herein.
In particular, the computer programs, when executed, enable the processor 303
to perform the features of the present invention. Accordingly, such computer
programs represent controllers of computer system 300.
In an embodiment where the invention is implemented using software, the
software may be stored in a computer program product and loaded into computer
system 300 using removable storage drive 314, hard drive 312 or communications
interface 324. The control logic (software), when executed by processor 303,
CA 02312641 2000-06-23
-1 g-
causes processor 303 to perform the functions of the invention as described
herein.
In another embodiment, the invention is implemented primarily in
hardware using, for example, hardware components such as application specific
integrated circuits (ASICs). Implementation of the hardware state machine so
as
to perform the functions described herein will be apparent to persons skilled
in
the relevant art(s).
In yet another embodiment, the invention is implemented using a
combination of both hardware and software.
C. A Preferred Software Programming Language and Network
Architecture
As discussed above, computer programs when executed, enable computer
300 to perform the functions of the present invention as discussed herein. In
a
preferred embodiment, the present invention is implemented using computer
programs written in an object-oriented programming language. Object-oriented
programming is a type of programming in which programmers define not only the
data type of a data structure, but also the types of operations (functions)
that can
be applied to the data structure. In this way, the data structure becomes an
object
that includes both data and functions. In addition, programmers can create
relationships between one object and another. For example, objects can inherit
characteristics from other objects.
One of the principal advantages of object-oriented programming
techniques over procedural programming techniques is that they enable
programmers to create modules that do not need to be changed when a new type
of object is added. A programmer can simply create a new object that inherits
many of its features from existing objects. This makes object-oriented
programs
easier to modify. To perform object-oriented programming, one needs an
object-oriented programming language (OOPL). C++ and Smalltalk are two of
the more popular languages, and there are also object-oriented versions of
Pascal.
CA 02312641 2000-06-23
-19-
While a preferred embodiment of the present invention is implemented
using computer programs written in an object-oriented programming language,
the present invention can also be implemented using procedural programming
languages, etc.
As discussed above, one or more of computers 300 is connected by a
network. A preferred embodiment of the present invention uses a type of
network
architecture called a peer-to-peer object architecture. Before peer-to-peer
object
architecture can be understood, a type of network architecture called
client/server
architecture must be described. Client/server architecture is a network
architecture in which each computer or process on the network is either a
client
or a server. Servers are computers or processes dedicated to managing disk
drives
(file servers), printers (print servers), applications/functions or network
traffic
(network servers ). In fact, a server is any computer or device that allocates
resources for an application. Clients are personal computers or workstations
on
which users run applications. Clients rely on servers for resources, such as
files,
devices, execution of functions and even processing power.
FIG. 4 illustrates the dynamic steps to establish communication that occur
between a client and a server executing an object-oriented program. In FIG.
4A,
the client has switchboard object 402 and listen object 404 waiting for a
request
from the server. In FIG. 4B, init object 406 determines that it needs to
perform
a specific task. In FIG. 4C, init object 406 creates comm object 408. Comm
object 408 is used to communicate with the client. Then, comm object 408 makes
a connection to listen object 404 in FIG. 4D. Once comm object 408 makes the
connection, listen object 404 creates comm object 410 and relocates comm
object
410 to switchboard object 402. Comm object 410 is used to communicate back
to the server (i.e., between the two piers), via comrn object 408.
At this point, as shown in FIG. 4F, there is two-way communication
between the client and the server (i.e., between the two piers) through comm
object 408 and comm object 410. Init object 406 knows which receiver object
needs to be created by the client (i.e., receiving pier) to perform the
specific task
required. Therefore, once this communication is established, init object 406
CA 02312641 2000-06-23
-20-
sends a request to the client (i.e., receiving pier) to create the specific
receiver
object. In FIG. 4G, switchboard object 402 receives the request, via comm
object
410, and creates receiver object 412. Once receiver object 412 is created,
comm
object 410 is relocated to receiver object 412 in FIG. 4H. Now, as shown in
FIG.
4I, init object 406 and receiver object 412, via comm object 408 and comm
object
410, can communicate back and forth until receiver object 412 completes the
task
requested by init object 406.
As stated above, a preferred embodiment of the present invention uses a
type of network architecture called a peer-to-peer object architecture. A peer-
to-
peer object architecture is when each computer in the network has equivalent
capabilities and responsibilities. This differs from client/server
architectures, in
which some computers are dedicated to serving the others. Therefore, in a
preferred embodiment of the present invention, all modules (e.g., computers
300)
can operate as either a server or a client with respect to all other modules.
For
example, application processing modules 205 has a score module that determines
a score for the application based partly on credit bureau data. Background
modules 215 has both an evaluator module and a calculator module. The
evaluator module evaluates unique circumstances (e.g., set of rules), whereas
the
calculation module calculates mathematical formulas. A possible scenario of
the
present invention is that the score module may ask the evaluator module to
execute a set of rules, which may request a calculation from the calculator
module. In this scenario the evaluator module is a server to the score module
and
a client to the calculator module.
As discussed above, one advantage of using an object-oriented
programming language is that it allows programmers to create modules that do
not need to be changed when a new type of object is added. In fact, each
module
of the present invention is a self contained object that can exist, evolve,
and
execute without the presence of any other module. Each module exposes its
services, which can be used by any other module.
In a preferred embodiment of the present invention, the modules (and the
features within) are built and packaged as Common Object Request Broker
CA 02312641 2000-06-23
-21-
Architecture (CORBA) compliant modules with CORBA Interface Definition
Language (IDL) used for interface specifications between the modules. The IDL
is used to define interfaces to objects. Remote objects view a CORBA object
purely in terms of its interface. IDL provides encapsulation of an object's
implementation behind a formal IDL interface that is independent of
implementation language, implementation algorithm, location, machine
architecture, operating system, and network technology. This separation of
interface and implementation allows CORBA to be viewed as a 'software bus,'
and is one of the most powerful aspects of CORBA.
In fact, when the modules of the present invention are built and packaged
as CORBA compliant modules, network 220 (FIG. 2) is implemented as an object
request broker (ORB). Here, network 220 is really an 'object bus' that handles
all communication between application processing modules 205, administration
modules 210, and background modules 215. It is the implementation of the
modules of the present invention as CORBA compliant modules that help to
provide ease of customization to users. It is possible to provide variations
of the
features through multiple interfaces of the modules. To the extent possible,
business functionality is separated from technical implementation. This
separation provides future maintainability, ease of enhancements, and
additions
of new features.
IY. Rule Driven Functionality of the Present Invention
Much of the functionality of the present invention is driven by rules. In
order to have an understanding of the present invention, it is necessary to
understand rules and how they are evaluated. As stated above, a rule is
defined
as a calculation, database field, complex rule (combination of existing rules)
or
a scorecard. A rule can return any data type, except for complex rules, which
return an indication of "pass" or "fail." Rules may be validated individually,
but
more commonly in rule sets. Therefore, a rule set is a collection of rules
where
CA 02312641 2000-06-23
-22-
each rule is evaluated against a parameter. A rule set list is a collection of
rule
sets, and a group is a collection of rule set lists.
All rule sets are evaluated the same way, and have the same output
(pass/fail). The present invention provides five different categories of
rules/rule
sets. The categories include pre-feature, selection, policy, scorecard, and
calculation. An explanation of each of these rule categories is discussed
next.
A. Pre-Feature Rule
A pre-feature rule determines whether a module of the present invention
should be run at all. As will be described later in reference to FIG. 8,
application
processing modules 205 include five modules. The five modules include a
bureau module, a score module, a price module, a policy module, and a product
module. An example of a pre-feature rule is a pre-bureau rule that determines
whether the bureau module should be executed. One example of a pre-bureau
rule may be to execute the bureau module only if the applicant's age is 18 or
older. A pre-pricing rule determines if the price module is required for the
particular application. Although the standard output for a rule is available,
the
only thing that is required of a pre-feature rule is an indication of "pass"
or "fail."
A scorecard may be used as a rule in a pre-feature rule set. In that way a
"pre-bureau" scorecard can be run, and the value that it returns can be
evaluated
against a parameter to determine if the bureau module should be executed. Pre-
feature rules will be described below in more detail in Section VI.
B. Selection Rule
Selection is used within a module for selection of valid rule sets, rule set
lists, scorecards, and so forth. Although the standard output for a rule is
available, the only output that is required of a selection rule is the ID of
what it
is selecting. A rule within a selection rule set can be a scorecard. In this
way
users can use the results of a pre-score scorecard to determine which decision
CA 02312641 2000-06-23
-23-
scorecard to use. FIG. 5 is a flowchart illustrating how selection rules work.
Note that if no rule set passes all of its rules, then no ID is chosen. Here,
the use
of a default rule set can assure that an ID is always selected.
The flowchart in FIG. 5 illustrates how selection sets work for selection
of a valid rule set. Note that each rule set has an ID attached to it. The
flowchart
begins at step 505 with control immediately passing to step 510.
In step 510, input is received that indicates whether the selection rule is
to be used within the particular module for selection of valid rule sets, rule
set
lists, scorecards, and so forth. Control then passes to step 515.
In step 515, the first rule set in the selection list is retrieved from
database
115. Control then passes to step 520.
In step 520, the first rule in the selection rule set is retrieved from
database
115. Control then passes to step 525.
In step 525, the rule is tested. Control then passes to step 530.
In step 530, it is determined whether the rule was the last rule in the rule
set. If the rule was not the last rule, then control passes to step 535. If
the rule
was the last rule, then control passes to step 540.
In step 535, the next rule in the selection rule set is retrieved and control
returns to step 525.
In step 540, it is determined whether all rules in the rule set have been
passed. If all rules have not been passed, then control passes to step 545. If
all
rules have been passed, then control passes to step 555.
In step 555, the ID to the rule set is written to database 115 and control
transfers to step 565, where the flowchart in FIG. 5 ends.
In step 545, it is determined whether the rule set was the last rule set in
the
list. If the rule set was not the last rule set in the list, then control
transfers to step
550. If the rule set was the last rule set in the list, then control transfers
to
step 560.
In step 550, the next rule set in the selection list is retrieved and control
returns to step 520.
CA 02312641 2000-06-23
-24-
In step 560, the default ID is written to database 115. Here, no rule set in
the selection rule list had all of its rules passed. Control then transfers to
step
565, where the flowchart in FIG. 5 ends.
C. Policy Rule
Review (above and below) and lending rules fall into this category. In
general, a review above rule is used by the present invention to prevent
automatic
approval of an application and to alert an analyst about problem areas in an
application. A typical review above rule is "look closely at an application
with
a 42% Debt to Income Ratio." A review below rule is used to prevent automatic
declines of an application and to alert an analyst about circumstances in an
application that warrant a closer look. A typical review below rule is "look
closely at an application where the applicant make over $ I 00,000 per month."
A lending rule of the present invention is used to prevent users from
approving
loans that are outside of the company's guidelines. A typical lending rule is
"definitely decline an application with a 45% Debt to Income Ratio."
D. Scorecard Rule
Scorecard characteristics are another example of a rule. They can be
database fields, calculations, or complex rules. They are evaluated in the
same
way as all rules, although one characteristic may return multiple data types.
The
results will be further processed to assign attributes (e.g., weights,
points).
E. Calculation Rule
This category of rule contains only calculations, the results of which may
be saved in database 115 for use later on. One application may have multiple
calculation rules and/or rule sets to be evaluated. For example, front end
system
110 may request that LTV and net down payment calculations are done before a
CA 02312641 2000-06-23
-25-
bureau is called. Typically when LTV is too high the application is
automatically
declined.
V. Customization Database
In general, a database is a collection of information organized in such a
way that a computer program can quickly select desired pieces of data. A
database is similar to an electronic filing system. To access information from
a
database, you need a database management system (DBMS). This is a collection
of programs that enables you to enter, modify, organize, and select data in a
database.
Traditional databases are organized by tables, fields, records, and files.
A field is a single piece of information; a record is one complete set of
fields; a
table is a collection of records; and a file is a collection of tables. For
example,
a telephone book is analogous to a file. It contains a list of records, each
of which
consists of three fields: name, address, and telephone number.
An alternative concept in database design is known as Hypertext. In a
Hypertext database, any object, whether it be a piece of text, a picture, or a
film,
can be linked to any other object. Hypertext databases are particularly useful
for
organizing large amounts of disparate information, but they are not designed
for
numerical analysis.
The present invention may also be implemented using a standard database
access method called Open DataBase Connectivity (ODBC). The goal of ODBC
is to make it possible to access any data from any application, regardless of
which
DBMS is handling the data. ODBC manages this by inserting a middle layer,
called a database driver, between an application and the DBMS. The purpose of
this layer is to translate the application's data queries into commands that
the
DBMS understands. For this to work, both the application and the DBMS must
be ODBC-compliant - that is, the application must be capable of issuing ODBC
commands and the DBMS must be capable of responding to them. The various
CA 02312641 2000-06-23
-26-
collections of data stored in database 115 are discussed next with reference
to
FIG. 6.
In FIG. 6, database 115 (FIG. l ) stores collections ofpre-feature rules 603,
scorecards 605, selection rules 610, calculation rules 615, policy rules 620
(including review and lending rules), matrix data 625, user related data 630,
historical data 635, bureau setup tables 640, and so forth. It should be
understood that the example collections of data shown in FIG. 6 is for
illustrative
purposes only and does not limit the invention. Other collections of data
stored
in database 115 described herein will be apparent to persons skilled in the
relevant arts) based on the teachings contained herein, and the invention is
directed to such other collections of data. Such collections of data not
illustrated
in FIG. 6 that may also be stored in database 115 include, but are not limited
to,
unique IDs for each item of data, characteristics, and so forth.
Pre-feature rules 603, scorecards 605, selection rules 610, calculation
rules 615, and policy rules 620 were introduced above. Matrix data 625
includes
data stored in the form of a two-dimensional array; that is, an array of rows
and
columns. It is important to note that the present invention is not limited to
matrices in the form of two-dimensional arrays. In fact, the present invention
contemplates matrices with any number of dimensions. In fact, this could
happen when one matrix references another matrix. Matrix data 625 can be
both customized by the user and pre-defined by the present invention. Matrix
data 625 is used by the present invention to compare one type of data to
another. An example of this is to compare credit bureau scores to custom
scores to receive a grade for a particular application. Table 1 illustrates an
example of matrix data 625.
CA 02312641 2000-06-23
-27-
Table 1
CUSTOM
SCORE
BUREAU
600
5~0
500
~D ~I00
SCORE
750' A1 A2 A3 B1 B2
700 A2 A2 A3 B3 B3
650 A3 A3 A3 B3 C1
600 B1 B1 B1 C1 C2
580 B2 B2 B2 C2 C3
The grades indicated in Table 1 are A1, A2, A3, and so forth. A1
indicates that the applicant has the strongest credit worthiness, while C3
indicates
the weakest credit worthiness.
User related data 630 relates to current credit evaluation results for each
application submitted to a credit bureau. Historical data 635 relates to
historical
credit evaluation results for applications submitted to a credit bureau at an
earlier
time. Storing both types of credit evaluation results allows the user to
request a
comparison of an applicant's current and historical credit evaluation results.
Bureau setup tables 640 contain data needed to call and process bureau
information. This information includes, but is not limited to, the name,
address,
city, state, zip code, reference phone number, password, and access phone
number
for each bureau that can be called.
Vl. General System Operation
The manner in which users may navigate through the functional modules
and features provided by customization system 105 will now be described.
Customization system 1 OS provides GUI front end system 1 l0 so that it may be
accessible and customizable by a user directly on a desktop computer, via a
World Wide Web page over the Internet (i.e., through on-line services), or
accessible via an Intranet. In an alternative embodiment, it may be accessible
via
CA 02312641 2000-06-23
-28-
telephone services or the like. It should be understood that the control flows
described are for example purposes only. Front end system 110 of the present
invention is sufficiently flexible and configurable such that users may
navigate
through customization system 105 in ways other than that described.
Referring again to FIG. 2, customization system 1 OS includes application
processing modules 205, administration modules 210, and background modules
215. Each of module 205, 210, and 215 contains multiple modules. Each module
of application processing modules 205 performs a unique set of processing
features that are co~gured based on specific business requirements defined by
the user. Each module of administration modules 210 performs a unique set of
administrative features that are also based on the specific business
requirements,
also defined by the user. Each module of background modules 21 S performs a
unique set of background functions required by both application processing
modules 205 and administration modules 210. Because the modules in
1 S background module 21 S are called upon by both application processing
modules
205 and administration modules 210, the modules in background modules 205
will be described first. Next, application processing modules 205 will be
described. Finally, administration modules 210 will be described.
A. Background Modules
Each module of background modules 215 performs a unique set of
background functions required by both application processing modules 205 and
administration modules 210. Referring to FIG. 7, background modules 215
provides an evaluator module 705, a calculator module 710, a data manager
module 715, and an external data parser module 720. Each of these modules is
described in detail below.
CA 02312641 2000-06-23
-29-
1. Evaluator Module
As stated above, much of the functionality of the present invention is
driven by rules. It is evaluator module 705 that is called upon by the other
modules of the present invention to evaluate rules and/or rule sets. Again,
the
five different categories of rules/rule sets include pre-feature, selection,
policy,
scorecard, and calculation.
For each rule processed by evaluator module 705 the following may be
returned: (1) Rule ID - the unique identifier for the rule; (2) Rule
Description -
a description of the rule; (3) Application Value - the value returned for this
rule;
(4) Rule Parameter - the parameter that the particular application is being
tested
against to determine a "pass" or "fail;" (5) Identity of Applicant - if rules
are
applicant specific, then return the identity of the applicant used in the
test; (6)
Pass/Fail - whether the rule passed or failed; and (7) Miscellaneous Code -
this
varies by the type of rule being evaluated. For example, for a review rule
type of
policy rules 620, the code may be an adverse action reason code. For a policy
rule type of policy rules 620, the code may be a lender level code.
For each rule set processed by evaluator module 705 the following may
be returned: ( 1 ) Rule Set ID - the unique identifier for the rule set; (2)
Rule Set
Description - a description of the rule set; (3) Pass/Fail - whether the rule
set
passed or failed (note that the failure of any rule within the rule set
triggers a
"fail" for the entire rule set); and (4) Miscellaneous Code - this varies by
the type
of rule set being evaluated. For example, for a selection rule set, the code
may
be the 1D of a scorecard 605, matrix data 625, program, and so forth.
2. Calculator Module
Calculator module 710 is called upon by evaluator module 705 to process
any mathematical calculations that are required. Calculator module 710 will
compute such things as LTV, debt to income ratio, payment to income ratio,
CA 02312641 2000-06-23
-30-
credit limit, deposit amount, and so forth. The present invention includes an
extensive library of calculation rules 615.
3. Data Manager Module
Data manager module 715 handles all requests for data from database 115.
Data manager module 71 S acts as an intermediary between database 115 and the
other modules of the present invention. One exception to this is shown in FIG.
2 where administration modules 210 may directly access database 115.
4. External Data Parser Module
As stated above, data needed to perform all modules/features of the
present invention is either passed in via front end system 110, collected by
customization system 105, or derived by customization system 1 O5. Therefore,
the present invention must be able to accept and/or process data in various
formats. Two types of data formats are fixed length and comma delimited. It is
external data parser module 720 that allows the present invention to accept
data
in various formats, parse the data, and then save the data in the appropriate
table
in database 115 (via data manager module 715).
A bureau OUT file is a credit data file received from a particular bureau
in response to a request for the evaluation of a credit application.
Therefore, it is
likely that different bureaus have different OUT file fonmats. The primary
function of external data parser module 720 is to allow different bureau OUT
file
formats to be defined in the present invention, and updated without changing
code. External data parser module 720 is also useful for processing credit
application files itself.
In an embodiment of the present invention, the definition of a particular
file format will be table driven. The goal is to allow electronic interfaces
without
having to write code. External data parser module 720 is able to handle both
fixed length or delimited files. Following, in Table 2, is an example of a
table
CA 02312641 2000-06-23
-31-
used by external data parser module 720 for reading fixed length bureau OUT
files.
Table 2
P'~tcketFleld Dlsplacemant.LenSthType ~ription Save In
HeaderType 0 4 Char Report Table
Type field
HeaderRefNo 4 20 AlphaNumRef. NumberTablefield
HeaderCustNo 24 10 AIphaNumCust. Tablefreld
Number
Table 3 is an example of a table used by external data parser module 720
for reading fixed length credit application files.
Table 3
Packet Fi~eW 'pbp~c,~mentLengthType AesctiptiooSave
. Ia
ApplicantLName 0 20 Char Last NameTablefield
ApplicantFName 20 20 Char First Tablefreld
Name
ApplicantMlnit 40 1 Char Middle Tablefield
Initial
AppEmpl Employer0 20 Char Employer Tablefield
AppEmpl Salary 20 10 Deci Salary Tablefreld
Table 4 is an example of a table used by external data parser module 720
for reading comma delimited credit application files.
Table 4
Packet Field Displacement! Length:TYPe 1)e:crip'tloaSn~s Io
ApplicantLName N/A 20 Char Last Name Tablefield
ApplicantFName N1A 20 Char First NameTablefreld
ApplicantMlnit N/A 1 Char Middle Tablefield
Initial
CA 02312641 2000-06-23
-32-
B. Application Processing Modules
Each module of application processing modules 205 performs a unique
set of processing features that are configured based on specific business
requirements defined by the user. Referring to FIG. 8, application processing
modules 205 provides a bureau module 805, a score module 810, a price module
815, a policy module 820, and a product module 825. Each module in processing
modules 205 includes various optional features to execute. The features are
optional because the user may decide to execute all or none, or any
combination,
of the features. These modules and features are described for illustrative
purposes. The invention is not limited to these modules and features.
1. Bureau Module
The present invention may call credit bureaus 125, or credit bureaus data
can be handed tv the present invention for evaluation and summarization. The
present invention supports at least the three major consumer bureaus 125,
including Experian, TransUnion, and Equifax. In addition, at least two
business
bureaus 125 including Dun and Bradstreet and Experian Business are supported
by the invention. The invention communicates with bureaus 125 with a variety
of methods including both on-line and batch mode. As explained above, bureau
module 805 may communicate with credit bureaus 125 via asynchronous dial up,
asynchronous lease line, and TCP/IP (via the Internet 120).
Referring to FIG. 9, the flow of an exemplary request that includes all of
the features of bureau module 805 is shown. It is important to note that the
present invention provides flexibility to the user in that the user may create
a
request that includes any number of these features and in any order that
logically
makes sense. How the present invention allows the user to create a request
(via
a GUI) will be described in detail below in Section VII.
The flowchart in FIG. 9 begins at step 905 with control passing
immediately to step 910. In step 910, the pre-bureau feature is executed. The
CA 02312641 2000-06-23
-33-
pre-bureau feature determines whether bureau module 805 should run based on
user-defined criteria. A rule set is identified by front end system 110 or is
chosen
based on selection rule sets as valid for the application. Each rule in the
rule set
is evaluated by evaluator module 705. If any rule fails, bureau 125 is not
called.
S A common pre-bureau rule would be "Applicant Age >= 18." Here, if the
applicant is less than 18 bureau 125 does not get called. The output of the
pre-
bureau feature is "yes" or "no." Control then passes to step 915.
In step 915, the bureau profile selection feature is executed. The bureau
profile selection feature utilizes bureau set-up tables 640 stored in database
115.
Bureau set-up tables 640 contain data needed to call and process bureau
information. The valid bureau profile ID may be passed in by front end system
110. If the valid bureau profile ID is not passed in by front end system 110,
a list
of rule sets will be evaluated by evaluator module 705 via selection rules.
Each
rule set will have a bureau profile ID attached to it. The ID attached to the
first
rule set that returns "Passed all Rules" becomes the selected (or valid)
bureau
profile ID. The output of the bureau profile selection feature is the bureau
profile
ID. Control then passes to step 920.
In step 920, the bureau setup feature is executed. As stated above, bureau
set-up tables 640 are stored in database 11 S. The tables 640 contain data
that
guide the rest of the features of bureau module 805. The bureau profile
(indicated by the bureau profile ID obtained from the bureau profile selection
feature in preceding step 915) indicates to the present invention which of the
bureau set-up tables 640 are to be referenced for the particular application.
Based
on tables 640 referenced in the bureau profile feature, the bureau setup
feature can
be completed. The output of the bureau setup feature includes: ( 1 ) which
bureaus) to call; (2) under which circumstances a second (or third) bureau is
to
be called; (3) the name address, city, state, zip code, reference phone
number,
password, and access phone numbers for each bureau to be called; (4) whether
bureau copies are allowed and for how many days; (5) whether each bureau 125
should be called for all applicants, primary applicants only, co-applicants
only,
and so forth; (6) which add on's are to be requested (score models, member
phone
CA 02312641 2000-06-23
-34-
and address, fraud, GEO Code, etc.); (7) whether the debugger is on or off;
(8)
whether to save statistical data; and (9) whether to save the OUT file.
Control
then passes to step 925.
In step 925, the bureau copy feature is executed. Here, based on if the
S bureau setup feature indicates that bureau copies are allowed, a bureau
record is
made available to copy. Bureau records can then be copied from one application
to another. A bureau record is considered valid to copy for a particular
applicant
if it has the same social security number, and was retrieved within a
specified
time frame (determined by the bureau setup feature). The bureau copy feature
works for any application, whether the applicant is a consumer or a business.
The output of the bureau copy feature is a copy of the bureau records. Control
then passes to step 930.
In step 930, the bureau call feature is executed. The bureau call feature
manages the communication with bureaus) 125, based on data determined in the
bureau setup feature. The goal of the communication is to send a request for a
credit evaluation of an application. The management includes placing the
request
in a queue, accomplishing the actual communication with bureau 125, and the
retrieval of the OUT file from bureau 125. The output of the bureau call
feature
includes: ( 1 ) the OUT file from bureau 125; and (2) statistical data related
to the
call itself. The statistical data includes the name of bureau 125 called, the
device
used to call bureau 125, the date of the call, the time of the call, the
length of
transmission for the call, the hit trades, the inquires, and any public
records.
Control then passes to step 935.
In step 935, the parse OUT file feature is executed. The parse OUT file
feature reads the OUT file and breaks its segments into fields via external
data
parser module 720. The fields can be used by the present invention for
analysis
and formatting of a TTY report. A TTY report is similar to a traditional
report
that might be faxed by a bureau to a lender if there were no computer to
computer
communications. The output of the parse OUT file feature is fields derived
from
OUT file segments. Control then passes to step 940.
CA 02312641 2000-06-23
-35-
In step 940, the feature that saves data from the OUT file is executed.
This feature saves the fields derived from the OUT file segments in database
115.
The fields can be either provided to the feature by front end system 110 or
may
be provided by the parse OUT file feature (explained above). Control then
passes
to step 945.
In step 945, the feature that saves trades, inquiries, and public records data
is executed. Here, based on the fields derived from the OUT file segments and
saved in database 115, records can be entered in database 115 regarding
trades,
inquires and public records (via data manager module 715). Some summary data
may also be saved. The rules of the present invention may depend on this
information. It is important to note that saving these records requires some
interpretation of the bureau data, but is independent of any bureau
interpretation
done for specific scorecard characteristics. The output of this feature is
entries
in database 115 for summary, trades, inquires and public records. Control then
1 S transfers to step 950.
In step 950, the feature that formats a TTY report is executed. As
mentioned above, a TTY report is similar to a traditional report that might be
faxed by bureau 125 to a lender if there were no computer to computer
communications. Many times users are most comfortable with this format when
very detailed analysis is required. Based on the bureau data saved in database
115, a standard TTY report (for the bureau) can be recreated and saved by this
feature. The output of this feature is a text file that mimics a bureau TTY
report.
Control then passes to step 955, where the flowchart in FIG. 9 ends.
There are three possible interfaces between the present invention and
credit bureaus 125. The first interface involves bureau module 805 directly
calling bureau 125. The second interface involves front end system 110 calling
bureau 125 and then handing the OUT file to bureau module 805. The final
interface involves front end system 110 calling bureau 125, parsing the
segments
into records (via external data parser module 720), and then handing the
record
data to bureau module 110 for storage in database 115 (via data manger module
715).
CA 02312641 2000-06-23
-36-
Example of Possible Bureau Module Requests
The present invention provides flexibility to the user in that the user may
create a request that includes any number of these features and in any order
that
logically makes sense. For example, if a user is not interested in saving a
bureau
copy for the particular application, then the user would not include the
bureau
copy feature in his or her request. Following in Table S is each possible
feature
of bureau module 805, including a unique ID, name, and output for each
feature.
Table 5
:.:4.-...-..a:::..::..-.f.,....:::a.? .?:?:a.::...a:..,.::........... .......
.
, .. ....:....::::::::::::.::.,..::::::..:::..:::.,.. ...... .. .. .
.........:..,:~~.:. ..................,.
..r..,.::::::::::-,T -'-'-.:~ . ... ~".~.~,...........
..........-.::.::: ::.....: .. ... .........
.:... ........ . . . .....:..:::.::.::~.::-;>..::-:::
.:. ., h r;;rr.. :..... . ..................
:.................... :. . .:........................... :.:.. .
.... :. .. ...::. :..: ..... ..............
.:. ?.:.... .:.. :.t:r..:.,?..;::::,.,:..:...:.:..................
. ;...,........:.a.w. ?.....:......:.........::.v,.t
...... ......, .2:..:......:...::.:.,:::::?... ..... .. ;.
.... ., . ......... .....: .:.::.?:::::::.....
. .............! ........t . ..........:.:.
:.:::.::.r...:.. . .;;,a,.. ::v.t.>..
;f, . ........ ..........:....:.,:...., :...::::: ...,.
. ..:;~; .
: t.
;.:.?v ,.,f::.x
.: . .::..k
. ?..?;.,,f;;?;..:.. :.,t;f.'.:::~:,:::::.:
i. ' '' . """' :;.,.:;:;':f:...:.::. ... . . . :: ,::.::
' f ;. .?:.?'.a:::::::%".::.?:::::::...
tttd: ; t: ::: ..$ ~ Y.....
v~ar.;i;~r'' '..:: ; v..t S .... ......~t. .....
:..~.n ....', : ......, ::.;::w..:.: ;;x
r.r .. .~~::::.:.. ,~':.:. ?::.-::.' a ;:'.
:.'.;. . . :::a.?
. ........ .':::.i.,,t :.::::: niitY~.?;
,. ..,.:::::'v~':. F .. : . '::". :::::
.3 ;:::::::.::: ... .....:: .... ..:....
...: :.::::::. : . :. r:. . :: .. .
...,:: t;..: , . :: : :... :: r: ::: :
. .;n:... ...... .....
: . :::::::.,:.: .
:, v: r: .?
.: ...x:.. t:: h.; ..:. :....
.; . ... ., :
. .
....:... : :
, :.:
i .~ . ...
.
:
:
~
?
~
:
~
. .~:.:~ : .
. ::. .. . .. . ... ,
. ..... . ..:...:: .
. ..........:..::.:,f,.,....
.....,..,.. ... ...............:..
...:,........... :w:::;; .
.:::.~:::.. ,:.
.????r....:,.t<.;,:. .>,.: .. . . ...::.
. .:::::.;::... .... t.......::..
.:::::.~::.:.:::...:
. .:.:..,..:.:"..:......
:.~ r.. :......... ..,....
.,:. :n::
.. :
...:;.;a::.: :v:
a:,.;..: ..............:,.. .. .....:.........:.........
?:::?:::.? .: :..::"?: ........
.. .
.>. .:...... .:.......,
.?;;., ..:.?,.,:, ..: : .,,.?~.;...,..
ft ,.:.,.::.v:.,.;:::::.t"t.:.;
,.......!., . .:::.:...~.~...;
K .:..:::.
x ::.;.. :::::.::.:...~
:.; :.;;:.:.b
:..
~.:f:::::.....,.::::::::.~,..,
"::
:f?? a:.
.::
:
YK
:
f
,
t. . ,
,,:.:: . ,
.....::. .
. . .
...... .... .... .
. .... .:... :p. .
.:.. . .n .
......,............:...., .
........................ .....:......:. ....
:..... ... . ,..:..:.:... . .
.............. ~:. ...
.. :.:::::....,..., .,;.~ :.::::::.,t.::.,:.,....
....:.,............:... ....t... ... ...... ,..::. ::..:,..,.,..
. ;.... :: .,... ..., .:..:,:,."
.. .. : r. ..... .:,?..";
............. .:....f. . .. ..... ............
. :....... :. :.. . .. .. ..:........
:. ...:. .....:. :. ,.. ......... ....:..
::..,.. s..:.t.,..:............:::
. . . : . ....... . :,t?..?.,....?... .....
.. :... ::.......:......'~... .. . : ,..,........
. ......... ........:.:.:..:.t,..::.... ..,.n..
: :t :........ ...? ..
..2;. .. ... . . . ...... ........:....:..
. .... :, . .... :. . n:...........,
..:..... ... . :..... .. ..... ..:.......
::. .:..:...... .. ......
......,.>...?. t;t.;?;,;. :.... .., ..... ..:....
:.,::.,a, :::::.,..:.....:.... :. ::.,.. .....
':: . . :. :.: ...:..... :...:....:...........t...:.,...
.: ,f,. ;;.;,.::: :.. ;,...
......v ::,..:. ... ...... :.... :.?
.,.:...,. :.: .:.::..~ ::..:::::.,...:
:.:........ .. ...~::
a ..:....t......,...t.?..::.
,. ..,. ....... . .:
. :.:::::.~?::.-t.t;,.,
......:.... ..,-..,..
........... ... .....:..t:...,.......:.,..:............
.. . ...
Bul Pre-Bureau Yes or No
Bu2 Bureau Profile SelectionBureau Profile 1D
Bu3 Bureau Setup Which bureaus) to call;
Circumstances
under which more than
one bureau
should be called; Name,
address, etc. of
bureau; Whether bureau
copies are
allowed and for how many
days; Which
applicants to call; Which
Add On's to
request; Whether debugger
is on or off;
Whether to save statistical
data;
Whether to save OUT file.
Bu4 Bureau Copy Copy of bureau records.
Bu5 Bureau Call OUT file and statistical
data related to
call.
Bu6 Parse OUT File Fields derived from OUT
file.
Bu7 Save Data From OUT Entries in database of
File fields derived
from OUT file.
Bu8 Save Trades, Inquiries,Entries in database of
Public Trades, Inquiries,
Records, and SummaryPublic Records, and Summary
Data Data.
Bu9 Format TTY Report Text file that mimics
the TTY report.
The purpose for Table 5 is to illustrate possible bureau module 805
requests shown in Table 6. Table 6 includes a unique number for the request,
what is passed in by front end system I 10 and supplied by other modules to
CA 02312641 2000-06-23
-37-
bureau module 805, and the request itself (the listing of the bureau module
805
features to execute). The requests shown in Table 6 may be both defined by the
present invention and/or defined by the user. It is important to note that the
present invention is not limited to the requests shown in Table 6.
Table 6
:: .... :,:::..:..:::::;:,....:::~...:.::....:::.::.::.::.:::::,..
.... ::..:...;:~;....::...: .: :..: ;.. :..........
. .; .:.;:..: ,.::.~ . . .....
. .. ~ ::.::::. ..::.::.:..:.<::
... ~t ~ :::,:.~:::;:;: . . .::..:::
. ~ .. ; ::;.....:,,:...:::::::::,,:,x >.:.,
~ : . . .. .. ... \>Y>.s..
' "~..:~ .. .
l :4...:
iYlYi ~
1
Bureau App l Bu 1
1 n 1 - Bu9
1111
cat~on Data
Bureau2 App Bu6 -
is Bu9
on
Data,
OUT
File
Bureau3 Application Bu7 -
Data, Bu9
parsed
OUT
i
a
Referring to Table 6 and the Bureaul request, only the application data
is passed to bureau module 805. Therefore, bureau module 805 must directly
interface with bureau 125. Here, the request involves executing features Bul
through Bu9.
With the Bureau2 request, both the application data and the OUT file are
passed to bureau module 805. Here, front end system 110 calls bureau 125 and
then hands the OUT file to bureau module 805. Because bureau module 805 is
not required to directly interface with bureau 125 itself, there is no need
for
features Bul through Bu5 to be executed. Therefore, the request involves
executing features Bu6 through Bu9 only.
Finally, with the Bureau3 request, the application data and the parsed
OUT file are passed to bureau module 805. Here, front end system 110 calls
bureau 125, parses the segments into records (via external data parser module
720), and then provides the parsed record data to bureau module 110. This
request involves executing features Bu7 through Bu9 only.
2. Score Module
Score module 810 of the present invention evaluates credit applications
using scorecards 605 (FIG. 6) and then provides a decision. Database 115
stores
a library of scoring characteristics licensed from a vender or defined by the
user.
Referring to FIG. 10, the flow of an exemplary request that includes all of
the
CA 02312641 2000-06-23
-3 8-
features of score module 810 is shown. As described with reference to bureau
module 805 above, the present invention provides flexibility to the user in
that the
user may create a request that includes any number of these features and in
any
order that logically makes sense.
The flowchart in FIG. 10 begins at step 1005 with control passing
immediately to step 1010. In step 1010, the pre-score feature is executed. The
pre-score feature determines whether score module 810 should run based on user-
defined criteria. A rule set is identified by front end system 110 or is
chosen
based on selection rules as valid for the application. Each rule in the rule
set is
evaluated by evaluator module 705. If any rule fails, scoring of the
application
is not done. A common pre-score rule would be "Applicant is NOT pre
approved." The output of the pre-score feature is an indication of "yes" or
"no."
Control then passes to step 101 S.
In step 1015, the score profile selection feature is executed. The score
profile selection feature utilizes a valid score profile ID that may be passed
in by
front end system 110. If the valid score profile ID is not passed in by front
end
system 110, a list of rule sets will be evaluated by evaluator module 705 via
selection rules. Each rule set will have a score profile ID attached to it.
The ID
attached to the first rule set that returns "Passed all Rules" becomes the
selected
(or valid) score profile ID. The output of the score profile selection feature
is the
score profile ID. Control then passes to step 1020.
In step 1020, the score profile feature is executed. The score profile
feature determines which scorecard 605 is to be used for the application.
Here,
the scorecard used may be either a champion scorecard or a challenger
scorecard.
A challenger scorecard is used a percentage of the time, where the percentage
of
the time is defined by the user. The general purpose of the challenger
scorecard
is to compare its results to those of the champion scorecard to determine if
it
provides a better evaluation of credit worthiness. The output of the score
profile
feature is the scorecard ID that is to be used for the application. Control
then
passes to step 1025.
CA 02312641 2000-06-23
-39-
In step 1025, the characteristic evaluation feature is executed. This
feature receives the valid scorecard ID that was either passed in by front end
system 110 or determined by the score profile feature above. 'The
characteristic
evaluation feature evaluates each characteristic in scorecard 605 that has the
valid
ID associated with it. Characteristics may be based on bureau data or
application
data. The output of this feature is a value for each characteristic evaluated.
Control then passes to step 1030.
In step 1030, the attribute evaluation feature is executed. The attribute
evaluation feature determines the weight or points that are assigned to each
characteristic in scorecard 605. The output of this feature is an attribute
(i.e.
weight). As mentioned above, an attribute/weight is a numeric value, positive
or
negative, that is added to an overall score. Control then passes to step 1035.
In step 1035, the grade matrix selection feature is executed. This feature
evaluates a list of rules to determine the grade matrix ID if the valid grade
matrix
ID is not passed in by front end system 110. Each rule set has a grade matrix
ID
attached to it. The ID attached to the first rule set that returns "Passed All
Rules"
becomes the selected grade matrix ID. The output of this feature is the grade
matrix ID. Control then passes to step 1040.
In step 1040, the grade assignment feature is executed. A grade is an
overall indicator of an application's credit worthiness. This feature utilizes
grade
matrix data 625 associated with the grade matrix ID that was either determined
by the grade matrix selection feature or passed in by front end system 110.
Matrix data 625 can be both customized by the user and pre-defined by the
present invention. Matrix data 625 is used by the present invention to compare
one type of data to another. Table 7 below illustrates a possible grade matrix
that compares values for a credit bureau score and values for LTV.
CA 02312641 2000-06-23
-40-
Table 7
LTV
BUREAU
70l6
?~/~o
$0/0
90l0
I00%
SCORE
730 A1 A2 A3 B1 B2
700 A2 A2 A3 B3 B3
650 A3 A3 A3 B3 C i
600' B1 B1 B1 C1 C2
:550 B2 B2 B2 C2 C3
The grades indicated in Table 7 are A1, A2, A3, and so forth. A1
indicates that the applicant has the strongest credit worthiness, while C3
indicates
the weakest credit worthiness. The output of this feature is the grade for the
application. For example, if the present invention determines that an
application
has a LTV of 75% and bureau data score of 750, the grade assignment feature
will
return a grade of A2. Control then passes to step 1045.
In step 1045, the decision feature is executed. Here a decision status is
assigned to the application based on the grade returned by the grade
assignment
feature. Valid decision statuses are Approve, Pending Approval, Pending,
Pending Decline, and Decline. Although front end system 110 can interpret each
status in its own way, typical interpretations are: Approve - no further
analysis
is required to approve the application; Pending Approval - the application is
in
a gray area and requires more analysis, but customization system 105
evaluation
is generally favorable; Pending - customization system 105 is not able to make
a determination regarding the application's credit worthiness; Pending Decline
-
the application is in a gray area and requires more analysis, but
customization
system 1 OS evaluation is generally unfavorable; and Decline - no further
analysis
is required to decline the application. The output of the decision feature is
the
decision status. Control then passes to step 1050.
CA 02312641 2000-06-23
_41 _
In step 1050, the retro score feature is executed. This feature provides the
capability to compare an applicant's historical credit evaluation results with
the
applicant's current credit evaluation results. Here, while current credit
evaluation
results use current user related data 630 and a current scorecard, historical
credit
evaluation results use historical data 635. A user must define a time period
for
the retro score (historical result,). If customization system 105 has called
bureau
125 on the applicant in the past, this information should be still stored in
database
115. In the event that bureau 125 information is not in database 115,
customization system 105 makes a bureau request. Customization system 105
then determines the retro score: using the bureau data for the applicant that
falls
within the specified time period. The output of the retro score feature is the
retro
score. Control then passes to step 1055, where the flowchart in FIG. 10 ends.
Example of Possible Score Module Requests
The present invention provides flexibility to the user in that the user may
create a request that includes any number of these features and in any order
that
logically makes sense. Following in Table 8 is each possible feature of score
module 810, including a unique ID, name, and output for each feature.
Table 8
,- . ~-.-~.. .. : ;: . .
:. : . .: . . :::::.: . ::: ...,.. ::::::
.. :::::.;. :. :::: :::: ,.. .. >::..::.::.T::::::.
:: .. . . .:..::..:.
:~!~!~!~>~!;:;::....:.:.:.::;:..::: . : ::: .....::::::::::::::::
:.. .. ~ctt*tva:.:......:::: :.::.....
;: ::.::. . .::::...:'......
.....;::...::::.:.<~~:::.;::.:::::.... ... .
.,::::. :.;:::.~::.. ~ ",_"".,
,.: .~ . . .:: :::::
:.:::::::::::::::::::.,..::.
. . . ..
. . .
. . ,_"
Sc l Pre-Score Yes or
No
Sc2 Score Pro ale Score Pr~le
Selection ID
Sc3 Score Profile Scorecard
ID
Sc4 Characteristic Values
Evaluation for each
Characteristic
Sc5 Amibute EvaluationWeight
for each
Characteristic,
Score
Sc6 Grade Matrix Grade Matrix
Selection ID
Sc7 Grade AssignmentGrade
Sc8 Decision ApplicationDecision
Status
The purpose for Table 8 is to illustrate possible score module 810 requests
shown in Table 9. Table 9 includes a unique number for the request, what is
passed in by front end system 110 and supplied by other modules to score
CA 02312641 2000-06-23
-42-
module 810, and the request itself (the listing of the features of score
module 810
to execute). The requests showm in Table 9 may be both defined by the present
invention and/or defined by the user. It is important to note that the present
invention is not limited to the requests shown in Table 9.
Table 9
~I<a
ScorelApplication Data Scl - S8 (If no bureau
characteristics
in Scorecard)
Score2Application Data, Scl - S8
Bureau Data
(Bu7)
Score3Application Data, Sc4 - Sc8
Bureau Data
(Bu7), Scorecard
ID
Score4Application Data, Sc5 - Sc8
Values for
Characteristics,
Scorecard ID
Refernng to Table 9 and the Score 1 request, only the application data is
passed to score module 810. Therefore, score module must execute without any
bureau data. Here, scorecard 605 can not be evaluated if it contains bureau
characteristics. The request involves executing features Sc 1 through ScB.
With the Score2 request, the application data and the bureau data are
passed to score module 810. Here, scorecard 605 can be evaluated if it
contains
bureau characteristics. The Score2 request involves executing features Scl
through ScB.
With the Score3 request, the application data, the bureau data, and. the
scorecard ID are passed to score module 810. Since the scorecard ID is
provided, there is no need for features Scl through Sc3 to be executed. The
Score3 request only executes features Sc5 through ScB.
Finally, with the Score4 request, the application data, the values; for
characteristics, and the scorecard ID are all passed to score module 810.
Here,
only features Sc5 through Sc8 are executed.
CA 02312641 2000-06-23
-43-
3. Price M~dule
Price module 815 of the present invention determines some of the "terms"
of the loan. Possible "terms" include a suggested interest rate, payment,
deposit
S amount, and credit limit. Database 1 I 5 stores a library of pre-defined and
user-
defined matrices and tables to assist in the determination of the "terms" of
the
loan. Referring to FIG. 11, the flow of an exemplary request that includes all
of
the features of price module 815 is shown. As described with reference to
bureau
module 805 and score module 810 above, the present invention provides
flexibility to the user in that tDie user may create a request that includes
any
number of these features and in any order that logically makes sense.
The flowchart in FIG. 11 begins at step 1105 with control passing
immediately to step 1110. In step I I 10, the pre-price feature is executed.
T'he
pre-price feature determines whether price module 815 should run based on user-
defined criteria. A rule set is ;identified by front end system 110 or is
chosen
based on selection rules as valid for the application. Each rule in the rule
sel: is
evaluated by evaluator module: 705. If any rule fails, pricing is not done. A
common pre-price rule would be "The application is NOT automatically
declined." The output of the pre-price feature is an indication of "yes" or
"no."
Control then passes to step 11 i 5.
In step 1115, the program selection feature is executed. A program is a
way of organizing fixed rate sheets, variable rates, credit limits, and
deposit
amounts. Programs can point to a rate matrix for a fixed rate, a variable rate
table
for a variable rate, or a matrix that returns a credit limit or deposit
amount, all of
which are stored in database 1 l5. For example, variable rate tables contain
an
index (such as prime rate), a margin (plus or minus), a floor, and a ceiling.
Programs also have effective dates and expiration dates. The effective date
indicates the first date a program may be used by the present invention, while
the
expiration date indicates the last date a program may be used.
The program selection feature utilizes a valid program ID that may be
passed in by front end system 110. If the valid program ID is not passed in by
CA 02312641 2000-06-23
-44-
front end system 110, a list of rule sets will be evaluated by evaluator
module
705 via selection rules. Each rule set will have a program ID attached to it.
T'he
ID attached to the first rule set that returns "Passed all Rules" becomes the
selected (or valid) program ID. The output of the program selection feature is
the
program ID. Control then passes to step 1120.
1n step 1120, the pricing feature is executed. The pricing feature
determines a price for the application. This feature receives the valid
program ID
that was either passed in by front end system 110 or determined by the program
selection feature above. The most common method of pricing would be returning
a rate from a rate matrix, whici~ is then used to calculate a payment. Table
10
illustrates an exemplary rate matrix that compares the amount financed by 'the
term.
Table 10
TERM
AMOUNT
I2 2A
36 48
60
FINANCED
25,000 7.5 8 8.25 8.5 8.5
20,000 8 8 8.25 7.75 8.'15
15,000 82.5 8.25 8.25 8.75 S>
10,000 8.5 8.5 8.5 8.75 S>
5,000 8.75 8.75 8.75 9 9
The output of the pricing features may include: ( 1 ) interest rate; (2)
credit
limit; or (3) deposit amount. Control then passes to step 1125.
In step 1125, the rate variance selection feature is executed. A rate
variance can be used to add or subtract from the suggested interest rate,
based on
user-defined criteria. For example, bank employees may get .25% subtracaed
from their rate. Whereas, high risk applicants may get .25% added to their
rate.
The rate selection feature utilizes a valid rate variance ID that may be
passed in
by front end system 110. If the valid rate variance ID is not passed in by
front
CA 02312641 2000-06-23
-45-
end system I I 0, a list of rule sets will be evaluated by evaluator module
705 via
selection rules. Each rule set will have a rate variance ID attached to it.
The ID
attached to the first rule set that returns "Passed all Rules" becomes the
selected
(or valid) rate variance ID. The output of the rate variance selection feature
is the
rate variance ID. Control then passes to step I 130.
In step 1130, the rate variance feature is executed. The rate; variance
feature determines the adjusted rate for the application. This feature
receives the
rate variance ID that was either passed in by front end system 110 or
determined
by the rate variance selection feature above. The output of the rate varimce
feature includes: (1) the rate ~~ariance; and (2) the adjusted rate. Control
then
passes to step 1135.
In step 1135, the payment calculation feature is executed. The payment
calculation feature determines the payment for the application. The payment is
partly based on the interest rate (either received from the pricing feature if
no rate
I S variance was required, or fron:~ the rate variance feature if an adjusted
rate was
required). The payment may also based on the credit limit and/or the deposit
amount (both determined by the pricing feature). If the credit limit or
deposit
amount requires a calculation, and is not just pulled from a matrix stored in
database 115 during the pricing feature, the calculation is done here by
calculator
module 710. The output of s.he payment calculation feature is the payment.
Control then passes to step I 140, where the flowchart in FIG. 11 ends.
Example oJPassible Pricing Module Requests
The present invention provides flexibility to the user in that the user may
create a request that includes my number of these features and in any order
that
logically makes sense. Following in Table 11 is each possible feature of
pricing
module 815, including a unique ID, name, and output for each feature.
CA 02312641 2000-06-23
-46-
Table 11
........:.:,..<. .:......:...I~t~re~ ::
.. .a~~ta~.. ..:........ .. . .. ..
.......................:.:..:..:.........:. ... . . ......................:
:: :.::::::::..:::.::..t~l~:..: !~..::.. .:. :..:..:.:. ..
~ . .... ...:.: .....
.::::.::.. :.::...:.:.:.......:................ ... . ....::
~.......... ... ::.:::. ::::....:::::..::.
......... :. ..: ..
'.............. ..
.......... ..... w
.......
...
Prl Pre-Price Yes or No
Pr2 Program SelectionProgram ID
Pr3 Pacing - Rate, Credit Limit, or
Deposit Account
Pr4 Rate Variance Rate Variance ID
Selection
Pr5 Rate Variance Rate Variance and Adjusted
Rate
Pr6 Payment CalculationPayment
The purpose for Tablc 11 is to illustrate possible price module 815
requests shown in Table 12. Table 12 includes a unique number for the request,
what is passed in by front end system 110 and supplied by other modules to
price
module 815, and the request itself (the listing of the features of price
module .B 15
to execute). The requests shown in Table I 2 may be both defined by the
present
invention and/or defined by the user. It is important to note that the present
invention is not limited to the requests shown in Table 12.
Table 12
;:a'f~~~::....: ' : .. ......
. ..
.
Pricel Apphcat~on Data Prl - Prb
Price2 Application Data, ProgramPrl, Pr3
ID (Pr2) - Pr6
Referring to Table 12 and the Pricel request, only the application data is
passed to price module 815. The request involves executing features Pr 1
through
Pr6.
With the Price2 request, the application data and the program ID are
passed to price module 815. since the program ID is provided, there is no need
for feature Pr2 to be executed. The Price2 request only executes features Prl
and
Pr3 through Pr6.
4. Policy :?Module
Policy module 820 of the present invention groups rules indicating
guidelines of a particular user (e.g., lender) that reflects its review and
lending
CA 02312641 2000-06-23
-47-
policies. An example of a particular bureau's lending policy may be
"Definitely
decline an application with a 45% Debt to Income Ratio." Referring to FIG.
'l2,
the flow of an exemplary request that includes all of the features of policy
module
820 is shown. As described with reference to modules 805, 8 I 0, and 815
above,
the present invention provides flexibility to the user in that the user rnay
create
a request that includes any number of these features and in any order that
logically makes sense.
The flowchart in FIG. 12 begins at step 1205 with control passing
immediately to step 1210. In step 1210, the pre-policy feature is executed.
'fhe
pre-policy feature determines whether policy module 820 should run based on
user-defined criteria. A rule set is identified by front end system 110 or is
chosen
based on selection rules as valid for the application. Each rule in the rule
set is
evaluated by evaluator module 705. If any rule fails, policy module .820 is
not
executed. The output of the pre-policy feature is an indication of "yes" or
"no."
Control then passes to step 121 S.
In step 1215, the calculation selection feature is executed. The calculation
selection feature utilizes a valid calculation set ID that may be passed in by
front
end system 110. If the valid calculation set ID is not passed in by front end
system 110, a list of rule sets will be evaluated by evaluator module 705 via
selection rules. Each rule set will have a calculation set ID attached to it.
They ID
attached to the first rule set that returns "Passed all Rules" becomes the
selected
(or valid) calculation set ID. The output of the calculation selection feature
is the
calculation set ID. Control then passes to step 1220.
In step 1220, the calculations feature is executed. The calculations to be
run by this feature may differ depending on user-defined criteria. Fo:r
example,
the LTV for a vehicle product may only consider the current loan, while the
L,TV
of a home equity product would typically want to consider all loans against
the
collateral. The present invention allows all of the applicable calculations to
be
placed into one set. This feature receives the calculation set ID that was
either
passed in by front end system 110 or determined by the calculation selection
feature above. The output of the calculations feature includes the results of
the
CA 02312641 2000-06-23
-48-
calculations (by calculator module 710). These results get stored in database
115
for use in policy rules 620. Control then passes to step 1225.
1n step 1225, the review above selection feature is executed. The review
above selection feature utilizes a valid review above rule set ID that may be
passed in by front end system l 10. If the valid review above rule set ID is
not
passed in by front end systerrv 110, a list of rule sets will be evaluated by
evaluator module 705 via selection rules. Each rule set will have a review
above
rule set ID attached to it. The ID attached to the first rule set that returns
"Passed
all Rules" becomes the selected (or valid) review above rule set ID. T'he
output
of the review above selection feature is the review above rule set ID. Control
then passes to step 1230.
In step 1230, the review above feature is executed. This feature receives
the review above rule set ID that was either passed in by front end system 11
C) or
determined by the review above: selection feature above. Review above rules
are
I S included in policy rules 620. In general, a review above rule is used by
this
feature to prevent automatic approval of an application and to alert an
analyst
about problem areas in an application. A typical review above rule is "Look
closely at an application with a 42% Debt to Income Ratio." If an application
has
an "Approve" decision status (see the decision application feature of score
module 810) and a review above rule has been triggered, then this feature will
change the decision status to "Pending Approval." Review above rules may <~lso
have codes attached to them that indicate the reason for the adverse action.
This
is useful for completely automated systems, where an analyst is not available
to
assign the reasons for the adverse action. These reasons could be listed in a
letter
to the applicant indicating that his or her application has been turned down.
'The
output of this feature is the result of each review above rule. Control then
passes
to step 1235.
In step 1235, the review below selection feature is executed. T he review
below selection feature utilizc;s a valid review below rule set ID that may be
passed in by front end system 110. If the valid review below rule set ID is
not
passed in by front end system 114, a list of rule sets will be evaluated. by
CA 02312641 2000-06-23
-49-
evaluator module 705 via selection rules. Each rule set will have a review
below
rule set ID attached to it. The II) attached to the first rule set that
returns "Passed
all Rules" becomes the selected (or valid) review below rule set ID. The
output
of the review below selection feature is the review below rule set ID,.
Control
then passes to step 1240.
In step 1240, the review below feature is executed. This feature receives
the review below rule set ID that was either passed in by front end system 110
or
determined by the review below selection feature above. Review below rules
.are
included in policy rules 620. In general, a review below rule is used by this
feature to prevent automatic declines of an application and to alert an
analyst
about circumstances in an application that warrant a closer look. A typical
review
below rule is "Look closely a~ an application where the applicant make over
$100,000 per month." Here, an analyst may want to consider approving the loan
even if some other policy rule, 620 have been violated. If an application has
a
"Decline" decision status (see the decision application feature of score
module
810) and a review below rule has been triggered, then this feature will change
the
decision status to "Pending Decline." Review below rules will only be
evaluated
by evaluator module 705 when an application has a decision status of
"Decline."
The output of this feature is the result of each review below rule. Control
then
passes to step 1245.
In step 1245, the policy selection feature is executed. The policy selection
feature utilizes a valid policy rule set ID that may be passed in by front end
system 110. If the valid policy rule set ID is not passed in by front end
system
110, a list of rule sets will be evaluated by evaluator module 705 via
selection
rules. Each rule set will have a policy rule set ID attached to it. The ID
attached
to the first rule set that returns 'Passed all Rules" becomes the selected (or
valid)
policy rule set ID. The output of the policy selection feature is the policy
rule: set
ID. Control then passes to step 1250.
In step 1250, the policy rules feature is executed. This feature receives the
policy rule set ID that was either passed in by front end system 110 or
determined
by the policy rule selection feature above. The rules used by this :feature
are
CA 02312641 2000-06-23
-50-
lending rules and are included in policy rules 620. A lending rule is used to
prevent users from approving leans that are outside of the company's
guidelines.
A typical lending rule is "Definitely decline an application with a 45"/o Debt
to
Income Ratio." Lending rules may also have codes attached to them that
S indicates the level of the lender. Different lender levels may be used by
front c:nd
system 110 to prevent some users from violating policies, while giving other
users the ability to override policy violations for an application. Note that
policy
module 820 may change the decision for the application based on policy roles
620. The output of this feature is the result of each lending rule. Control
then
passes to step 1255, where the flowchart in FIG. 12 ends.
Example of Passible Policy Module Requests
The present invention provides flexibility to the user in that the user may
create a request that includes any number of these features and in any order
that
logically makes sense. Following in Table 13 is each possible feature of
policy
module 820, including a unique ID, name, and output for each feature.
Table 13
. : . ' :~ '. ~tili~ ~ v .:. !>t ......
. :.: .:::.:::::: ....:.' ...
: ~.. . ..tl~~. , ~:...........~...... .
':::. . :. ........ . .... . .....
. ~~.... :.:: .::::.: : :.: :,r";;r;,~;,..-~;
... :. :. :. : ...: :.r,;,~;""".,
;...~ ..............
:: :.:: :... :.: :..
>: >: .::: :: ::..
>::.:.......-.-.
.::..::.
Pol Pre-Policy Yes or No
Po2 Calculaho-' n Calculation Set ID
Selection
Po3 Calculations Results o each Calculation
saved in Database
Po4 Review Above Review Above Rule Set ID
Selection
Po5 Review Above Results of each Review rule
Po6 Review Below Review Below Rule Set ID
Selection
Po7 Review Below Results of each Review rule
Po8 Policy Rule SelectionPolicy Rule Set ID
Po9 Policy Rules Results of each Policy rule
The purpose for Tablc~ 13 is to illustrate possible policy module 820
requests shown in Table 14. Table 14 includes a unique number for the request,
what is passed in by front end system 110 and by other modules to policy
module
820, and the request itself (the listing of the features of policy module 820
to
execute). The requests shown in Table 14 may be both defined by the present
CA 02312641 2000-06-23
-51-
invention andlor defined by the user. It is important to note that the present
invention is not limited to the requests shown in Table 14.
Table 14
:..:.:::::.:::::::.::::..:. . ................ ..
: :.::. :: ::........:...........<....... ...........~..:::.:
:::::::::::.:. . .... ... ....:: ...:.:.:: ...
..: .: . :.:
Po ~cyl Appncation Data Pol - Po9 n no o Fey
a~R ~ w
Rules depend on Bureau
data)
Policy Application Data, Pol - Po3, PoS, Po7-Po9
2 Review
Above Rule Set
ID, Review
Below RuGe Set
ID
Referring to Table 14 and the Policy 1 request, only the application data
is passed to policy module 820. Therefore, policy module 820 must execute
without any bureau data. The Policyl request can only operate if all lending
rules and review rules (both above and below) do not depend on bureau data.
The
request involves executing features Po 1 through Po9.
With the Policy2 request, the application data, review above rule set ID,
and the Review Below Rule Set ID are passed to policy module 820. Therefore,
features Po4 and Po6 are not executed. The request involves executing features
Po 1 through Po3, PoS, and Po7 through Po9.
5. Product Module
Product module 825 of the present invention is used to determine whether
an application is qualified for multiple products. Examples of a product
include
vehicle loans, vehicle leases, home equity loans, credit cards, and so forth.
For
example, an application may be for a vehicle loan. The user may also want to
qualify the application fox a vehicle lease to give the applicant an option.
Another
example is the situation where the applicant applies for a vehicle loan, and
the
user wants to qualify him or her for a credit card and a home equity line of
credit.
The user may then attempt to cross sell the other products if the applicant
qualifies. Referring to FIG. 13, the flow of an exemplary request that
includes
all of the features of product module 825 is Shawn. As described with
reference
to modules 805 - 820 above, the present invention provides flexibility to the
user
CA 02312641 2000-06-23
-52-
in that the user may create a request that includes any number of these
features
and in any order that logically makes sense.
The flowchart in FIG. 13 begins at step 1305 with control passing
immediately to step I 310. In step 1310, the pre-product feature is executed.
The
pre-product feature determines whether product module 825 should run based on
user-defined criteria. A mle set is identified by front end system 110 or is
chosen
based on selection rules as valid for the application. Each rule in the rule
set is
evaluated by evaluator module 705. If any rule fails, product module 825 is
not
executed. The output of the pre-product feature is an indication of "yes" or
"no."
Control then passes to step 1315.
In step 1315, the multiple product selection feature is executed. 'fhe
multiple product selection feature utilizes a valid multiple product rule set
ID that
may be passed in by front end system 110. If the valid multiple product rule
set
ID is not passed in by front end system 110, a list of rule sets will be
evaluated
I S by evaluator module 705 via selection rules. Each rule set will have a
multiple
product set ID attached to it. The ID attached to the first rule set that
returns
"Passed all Rules" becomes the selected (or valid) multiple product rule set
:fD.
The output of the this feature is the multiple product rule set ID. Control
then
passes to step 1320.
In step 1320, the multiple product qualification feature is executed. This
feature receives the multiple product rule set ID that was either passed in by
front
end system 110 or determined by the multiple product. selection feature above.
For application, market malysis, and cross selling purposes, users of the
present
invention may want to run an application through multiple scorecards 605,
policy
rules (both review and lending) 620, and suggest multiple decisions. The
additional scorecards 605, review rule sets, and policy rule sets to be run by
this
feature may be user-defined. Users may also enter via front end system 110
dollar amounts and terms (when applicable) for the additional products. '1('he
output of this feature is a request to the initiator feature (discussed below)
to
determine if the application can qualify for additional products. Control then
passes to step 1325, where the flowchart in FICJ. 13 ends.
CA 02312641 2000-06-23
-53-
Example of Possible Product Module bequests
The present invention provides flexibility to the user in that the user may
create a request that includes any number of these features and in any order
that
logically makes sense. Following in Table 15 is each possible feature of
product
module 825, including a unique ID, name, and output for each feature.
Tabte 15
'~~~!~yll~::;: .: : ~:'.::::.:.:, :.:....
,::.::.:..:.:.,w,..~ . ~~t~.~
.. ;....:...:::~~!.?~~:.: :
.. : '.:
.
P 1 Pre-Pro uct ..
Yes or o
Pd2 Multtp a Pro Multiple Product Set ID
uct
Selection
Pd3 Multiple Product Request Passed to Initiator
ualification
The purpose for Table 15 is to illustrate possible product module 825
requests shown in Table 16. Table 16 includes a unique ID for the request,
what
is passed in by front end system 110 and by other modules to product module
825, and the request itself (the listing of the features of product module 825
to
execute). 'the requests shown in Table 16 may be both defined by the present
invention and/or defined by the user. It is important to note that the present
invention is not limited to the requests shown in Table 16.
Table 16
.,;.,,., .,,:,:.:,:,: , ;~.~.:::::::: :,: ::....:
. !k::. :..: .:: :. .. .: ..:
~~!!.'.. ~~~'a: :::::::..:.: ::::::: :.::;.:
! ''. . ::.
~~ .
Productl App ~cahon Data Pdl-Pd3
Product2 Application Data, Multiple ProductPdl, Pd3
Rule Set ID l
Referring to 'Table 16 and the Productl request, only the application data
is passed to product module 825. Therefore, product module 825 must execute
without any bureau data. The request involves executing features Pdl through
Pd3.
With the Product2 request, the application data and multiple product rule
set ID are passed to product module 825. Therefore, feature Pd2 is not
executed.
The request involves executing features Pdl and Pd3.
CA 02312641 2000-06-23
-54-
6. Examples of Possible Application Reguests
As stated above, bureau module 805, score module 810, price module
815, policy module 820, and product module 825 can be operated independently
of each other. This is true: as long as each module has the needed data to
process
the request. The needed data to process a request may be either passed in via
front end system 110, collected by customization system 105, or derived by
customization system 105.
Just as Tables 6, 9, 12, 14, and 16 illustrated possible requests for bureau
module 805, score module 810, price module 81 S, policy module 820, and
product module 825, respectively, Table 17 illustrates possible application
requests. An application request combines one or more module request, as shown
below. Table 17 includes a unique ID for the request, what is passed in by
front
end system 110, and the request itself (the listing of the module requests to
execute). The requests shown in Table 17 may be both defined by the present
invention and/or defined by the user. The present invention is not limited to
the
requests shown in Table :17.
Table 17
a:l ~.:::>.~ : ;;:-~T.T.;:::::::::.:::.:.:.::
. ::
~~y .. ...~.......'.~ii:.::.
Appl Application Buresul, Score2, Pricey
Data Policyl,
Product 1
App2 Application Scorel, Pricel, Policyl,
Data Productl
App3 Application Bureau2, Score, Pricey,
Data, OUT Pohcy2,
File Product 1
App4 Application Bureau3, ScoreZ, Pricey,
Data, Policy2,
parsed OUT fileProduct 1
Apps Application Score4, Pricel, Policy
Data, 1
Values for
Characteristics
Refernng to Table 17 and the Appl request, only the application data is
passed in. With the Appl request, the Bureaul request will be executed first,
followed by the Score2 request, followed by the Price 1 request, followed by
the
Policyl request, and finally the Productl request will be executed.
CA 02312641 2000-06-23
-S$-
The Bureaul request is executed first. Referring to Table 6, the Bureaul
request involves executing all of the features of bureau module 805, including
executing features Bul through Bu9 (from Table S). Note that the Bureaul
request also only requires the application data to be passed to it from front
end
system 110.
The Score2 request is executed second. Refern'ng to Table 9, the Score2
request involves executing all of the features of score module 810, including
executing features Sc 1 through Sc8 (from Table 8). Note that the Score2
request
requires that the application data be passed in by front end system 110 and
the
bureau data to be supplied by the feature Bu7. The feature Bu7 is executed by
the
Bureaul request and thus available for the Score2 request.
The Price 1 request is executed third. Referring to Table 12, the Price 1
request involves executing all of the features of price module 815, including
executing features Prl through Pr6 (from Table 11). The Pricel request only
requires the application data to be passed in by front end system 110.
'the Policy 1 request is executed next. Referring to Table 14, the Policy 1
request involves executing all of the features of policy module 820, including
Po 1
through Po9 (from Table 13). The Policy 1 request only requires the
application
data to be passed in by front end system 110.
Finally, the Productl request is executed. Referring to Table 16, the
Product request involves executing all of the features of product module 825,
including Pdl through Pd3 (from Table 15). The Productl request only requires
the application data to be passed in by front end system 110.
The other application requests, App2 through Apps, are executed in a
similar manner as explained with reference to the App 1 request above.
C. Administration Modules
Each module of administration modules 210 performs a unique set of
administrative features that are also based on the specific business
requirements
defined by the user. As stated above, administration modules 210 is connected
CA 02312641 2000-06-23
-56-
to front end system 110 and database 115. The types of data stored in database
115 are partially determined through user-defined customization via front end
system I 10. Administration modules 210 are utilized by the user to customize
system 1 O5, perform overall management duties, to generate various reports,
and
to manipulate data stored in database 11 S. The reports may include a list of
different types of data stored in database 115 (e.g., a list of the currently
active
rules, rule sets, characteristics, and so forth). To assist the user in the
customization of system 105, the present invention provides a variety of GUIs
accessible via front end system 110. The GUIs will be briefly mentioned where
applicable in this Section and will be described below in detail in Section
VII.
Referring to FIG. 14, administration modules 210 provides a
rule/scorecard module 1405, a user/database module 141 S, an initiator module
1410, an object request broker (ORB) manager module 1420, and an
administration module 1425. These modules are described for illustrative
1 S purposes. The invention is not limited to these modules.
1. Administration Module
Administration module 1425 provides the front end for the administration
of both the user-defined data and database I 15. Administration module 1425
allows the user to create tables and views, maintain database 115, obtain
various
reports, and administer logon activities such as logon passwords. Front end
system 110 provides an administration GUI to facilitate the user in the
administration of database 11 S. This GUI will be described in detail below in
Section VII with reference to FIGs. 15-19.
2. RulelScorecard Module
Rule/scorecard module 1405 provides the user the ability to create and/or
update characteristics, calculation rules 61 S, scorecards 605, matrix data
625, rule
sets, rule set lists, pre-feature and selection rules, bureau set-up tables
640, and
CA 02312641 2000-06-23
-57-
so forth. Front end system 110 provides an expression builder GUI to
facilitate
the user in creating/updating characteristics, calculation rules 615, and pre-
feature
and selection rules. This expression builder GUI will be described in detail
below in Section VII with reference to FIGs. 20-26. Front end system 110 also
provides a rule set builder GUI to facilitate the user in creating/updating
rule sets.
This rule set builder GL11 will be described in detail below with reference to
FIG. 27. In addition, front end system 110 provides a rule list builder (lUI
to facilitate the user in creatinglupdating rule set lists. This rule list
builder CiUI
will be described in detail below with reference to FIG. 28. Front end system
110
also provides a scorecard builder GUI to facilitate the user in
creating/updating
scorecards. This scorecard builder GUI will be described with reference to
FIGs. 29-32. Front end system 110 provides a matrix builder GUI to facilitate
the
user in creating/updating matrix 625. This matrix builder GUI will be
described
with reference to FIG. 33.
3. Initiator Module
Initiator module 1410 is the interface to front end system 110. Initiator
module 1410 is also respansible for coordinating, prioritizing, and
arbitrating the
activities amongst the various modules of customization system 105. Initiator
module 1410 controls, via requests, which features of tlhe modules of the
present
invention are executed, and in what order the features are executed. Both user-
defined and pre-defined requests group the features. Various requests were
described in detail above in Section VI.
Initiator module 1410 is also responsible for accepting application data via
front end system 110, initiating the evaluation process, and returns results
via
front end system 110 back to the user. Front end system 110 provides a request
builder GUI to facilitate the user in creating user-defined requests. This
request
builder GUI will be described in detail below in Section VII with reference to
FIG. 34.
CA 02312641 2000-06-23
-5 8-
4. Object Request Broker (ORB) Manager Module
A preferred embodiment of the present invention, as described above. is
when the modules (and the features within) are built and packaged as CORBA
compliant modules with C'.ORBA IDL used for interface specifications between
the modules. In fact, when the modules of the present invention are built and
packaged as CORBA compliant modules, network 220 (FIG. 2) is implemented
as an ORB. Network 220 is really an 'object bus' that handles all
communication
between application processing modules 205, administration modules 210, and
background modules 215. It is the implementation of the modules of the present
invention as CORBA compliant modules that helps to provide ease of
customization to users. It is possible to provide variations of the features
through
multiple interfaces of the modules. To the extent possible, business
functionality
is separated from technical implementation. 'This separation provides future
maintainability, ease of enhancements, and additions of new features.
The present invention provides ORB manager module 1420 to manage
network 220 when it is implemented as an ORB. ORB manager module 1420
provides the following functions including notification of CORBA exceptions,
console viewing of diagnostic messages, activity viewing for ORB applications,
activity measurement for ORB applications, shutting down specified ORB
servers, notification of unexpected server termination, and assignment of
properties to ORB applications. For example, properties can be used to assign
application names and version numbers of ORB applications.
5. UserlDatabase Module
User/database madule 1415 provided by the present invention manages
user access (security) and database 11 ~ administration requirements.
User/database module 1415 controls user access by managing user passwords
needed to access various modules of the present invention. User access is
controlled on both an individual level and on a group level. User/database
1415
CA 02312641 2000-06-23
-59-
also facilitates database 115 administration. This includes performing backups
of database 115, controlling bureau calling and formatting processes,
displaying
variables relating to the environment of the present invention, displaying
cron
logs, performing miscellaneous operating system utilities, initializing
database
115 for multiple users, and controlling purging and archiving routines.
VII. Graphical User Interface (GUI) of the Present Invention
Front end system 110 provides the GUI to users of customization system
105. Examples of GUIs provided by the present invention include
administration,
expression builder, rule set builder, rule list builder, scorecard builder,
matrix
builder, and request builder GUIs.
A. Administration GUI
Front end system 110 provides an administration GUI to facilitate the user
in the administration of database 11 S. The administration of database 115 is
accomplished via administration module 1425. An exemplary administration
1 S GUI screen for allowing the user to administer database 115 is shown in
FIG. 15.
Referring to FIG. 15, the administration GUI represents some of the data
stored
in database 115. As described above, traditional databases are organized by
files,
tables, records, and fields. A field is a single piece of information; a
record is one
complete set of fields; a table is a collection of records;. and a file is a
collection
of tables. The administration GUI represents the data stored in database 115
as
organized by files, tables. records, and fields.
FIG. 1 S illustrates a file that contains seven (7) tables. These tables
include an expression table 1505, a rule set table 1510, a rule list table
1515, a
scorecard table 1520, a matrix table 1525, a request table 1530, and a log
table
1535. Note that expression table 1505 represents characteristics, calculation
rules
615, selection rules 610, etc. Log table 1535 represents a log of various
occurrences that happen in customization system 105.
CA 02312641 2000-06-23
-60-
1n FIG. 15, expression table 1505 is highlighted. This indicates that the
records for expression table 1505 are displayed. Some of these records include
an APR record 1565, an AmtFinance record 1570, and an AmtFinance record
1575. Each record has multiple fields including an ID field 1540, a
description
field 1545, an expression i:ield 1550, a misc code field 1555, and an
effective date
field 1560. In general, IL) field 1540 represents a unique expression ID for
the
particular record; description field 1545 gives a description of the
particular
record, expression field 1550 is the actual expression (e.g., characteristic,
calculation rule 615, ete.); misc code field 1555 represents a code that is
attached
to a rule indicating any number of things (e.g., Lending rules may have codes
attached to them that indicates the level of the lender); effective data field
1560
indicates the date the particular record is active. For example, AmtFinance
records 1570 and 1575 are exactly the same except for their effective dates.
Record 1570 became active on April 15, 1999. Record 1575 became active on
April 21, 1999. Therefore, once record 1575 becomes active, record 1570 is no
longer active.
An exemplary administration GUI screen displaying the records for rule
set table 1510 is shown in FIG. 16. Some of these records include a Policy
record 1625 and a ReviewAbove record 1630. Each record has multiple fields
including an ID field 1605, a description field 1610, and an effective date
field
1615. These fields represent similar data described above in reference to ID
field
1540, description field 1545, and effective date field 1.560, respectively.
An exemplary administration GUI screen displaying the records for rule
list table 1515 is shown ire FIG. 17. These records include a Policy record
1'120
and a PolicyRules record 1725. Each record has multiple fields including an ID
field 1705, a description field 1710, and an effective date field 1715. These
fields
represent similar data described above in reference to ID field 1540,
description
field 1545, and effective date field 1560, respectively.
An exemplary administration GLJI screen displaying the records for
scorecard table 1520 is shown in FIG. 18. These recards include a Scorecard)
record 1820 and a Score:cardl record 1825. Each record has multiple fields
CA 02312641 2000-06-23
-61-
including an ID field 1805, a description field 1810, and an effective date
field
1815. These fields represent similar data described above in reference to ID
field
1540, description field 1545, and effective date field 1560, respectively.
An exemplary administration GU l screen displaying the records for matrix
table 1525 is shown in FIG. 1 '~. These records include a GradeMatrix 1 record
1930 and a GradeMatrix2 record 1935. Each record has multiple fields including
an ID field 1905, a description field 1910, a row variable field 1915., a
column
variable 1920, and an effective date field 1925. ID field 1905, description
field
1910, and effective date field 1925 represent similar data described above in
reference to ID field 1540, description field 1545, and effective date held
1560,
respectively. In general, row variable field 1915 and column variable 1920 are
compared in some manner to produce the values stored in each matrix.
B. Expression Builder GUI
Front end system 110 provides an expression builder GUI to facilitate the
user in creating/updating characteristics, calculation rules 615, and pre-
feature
and selection rules. This creating/updating is accomplished via rule/scorecard
module 1405. The expression builder GUI is used to create/update records in
expression table 1505 (FIG. 15). An exemplary expression builder CiUI screen
is shown in FIG. 20.
Referring to FIG. 20, the expression builder GUI includes five (5) input
windows and seven (7) expression building folders. The five input windows
include an expression ID input window 2005, an effective date input window
2010, a description input window 201 S, a misc code input window 2020, and an
expression input window 2025. These input windows allow the user to specify
the data for the records in expression file 1505 in FIG. 15. In general,
expression
ID input window 2005 allows the user to specify the unique ID for the
expression. The data entered into this window becomes the data shown in ID
field 1540. Effective data input window 2010 allows the user to specify the
date
the expression is to be active. The data entered into this window becomes the
CA 02312641 2000-06-23
-62-
data shown in effective date field 1560. Description input window 2015 allows
the user to specify the description for the expression. The data entered into
this
window becomes the data shown in description field 1545. Misc code input
window 2020 allows the user to specify any codes that should be attached to
the
expression. The data entered into this window becomes the data shown in misc
code field 1555. Expression input window 2025 allows the user to create the
expression itself. The data entered into this window becomes the data shovv~,n
in
expression field 1550.
The seven expression building folders of the expression builder (sUI
includes an operator folder 2030, a constants folder 203 5, a functions folder
2(140,
an expression folder 2045, a scorecard folder 2050, a database folder 2055,
and
a characteristic folder 2060. By clicking on any one of these folders, the
user has
easy access to the available building elements for the expression.
An exemplary expression builder GUI screen illustrating subfiles and a
syntax checker is shown in FIG. 21. Database folder 2055 includes two (2)
subfiles, an apptables subfile 2105 and an app address subfile 2'110.
App address subfile 2110 has multiple building elements, including an
addresstype building element 2115, an appentity building element 2120, a
borough building element 2130, and a city building element 2135. These
building elements may be used to create the expression. The expression builder
GUI in FIG. 21 also illustrates the syntax checker of the present invention.
The
syntax checker tests the expression for syntax errors (such as syntax error
2125)
and indicates the error by a message (such as message 2140).
An exemplary expression builder GUI screen illustrating the building
elements of operator folder 2030 is shown in FIG. 22. The building elements of
operator folder 2030 include a "+" building element 2205, a "-" building
element
2210, a "*" building element 2215, a "/" building element 2220, a "~" building
element 2225, a "<_" building elements 2230, and a ">_" building element 2235.
An exemplary expression builder GUI screen illustrating the building
elements of constants folder 2035 is shown in FIG. 23. The building elements
of
CA 02312641 2000-06-23
-63-
constants folder 2035 include a "true" building element 2305 and a "false"
building element 2310.
An exemplary expression builder GUI screen illustrating the building
elements of functions folder 2040 is shown in FIG. 24. 'The building elements
of
functions folder 2040 include an "avg" building element 2405, a "count"
building
element 2410, a "date" building element 2415, a "lookup" building element
2420,
a "max" building element 2425, a "min" building element 2430, and a "sum"
building element 2435.
An exemplary expression builder GUI screen illustrating the building
elements of expression folder 2045 is shown in FIG. 25. The building elements
of expression folder 2045 include an APR building element 2505, an ArntFinance
building element 2510, a Balances building element 2515, a Bankruptcy building
element 2520, a BurScore500 building element 2525, a BurScore550 building
element 2530, and a CBBkrpt building element 2535.
An exemplary expression builder GUI screen illustrating the building
elements of characteristic folder 2060 is shown in FIG. 26. The building
elements of characteristic folder 2060 include a BankNatlTrades75Balance
building element 2605, a Char001 building element 2610, a Char002 building
element 2615, and a Collections building element 2620.
C. Rule Set Builder GUI
Front end system 1 I 0 provides a rule set builder GUI to facilitate the user
in creating/updating rule sets. This creating/updating of rule sets is
accomplished
via rule/scorecard module 1405. The rule set builder GUI is used to
create/update
records in rule set table 1510 (FIG. 16). An exemplary rule set builder CiUI
screen is shown in FIG. 27.
Referring to FIG. 27, the rule set builder GUI includes five (5) input
windows and a possible expressions window 2725. Possible expressions window
indicates the available expressions to include in the rule set. The five input
windows include a rule set ID input window 2705, a description input window
CA 02312641 2000-06-23
-64-
2710, an effective date input wi ndow 2715, a misc code input window :2720,
and
an included expressions input window 2730. These input windows allow the user
to specify the data for the records in rule set file 1510 in FIG. 16.
In general, rule set ID input window 2705 allows the user to specify the
unique ID for the rule set. The data entered into this window becomes the data
shown in ID field 1605. Description input window 2710 allows the user to
specify the description for the rule set. The data entered into this window
becomes the data shown in description field 1610. Effective date input window
2715 allows the user to specify the date the rule set is to be active. The
data
entered into this window becomes the data shown in effective date field 1615.
Misc code input window 2720 allows the user to specify any codes that should
be attached to the rule set. Included expressions input window 2730 allows
'the
user to determine the expressions that make up the rule set. The way the user
utilizes the rule set builder GUI to determine the expressions that make up
'the
rule set will be described next.
The rule set builder GtlI includes three buttons to facilitate the user in
determining the expressions to include in the rule set. These buttons include
add
button 2735, move up button '.740, and move down button 2745. The way in
which the user adds an expression from possible expressions 2725 to included
expressions 2730 is to highlight the desired expression in possible
expressions
2725 and click on add button 2735. This moves the desired expression from
possible expressions 2725 to included expressions 2730. A user can manipulate
the order of the expressions in included expressions 2730 by using move up
button 2740 and move down button 2745. To move an expression up one, the
user simply highlights the desired expression in included expressions 2730 and
clicks on move up button 2740. To move an expression down one, the user
simply highlights the desired expressions in included expressions 2730 and
clicks
on move down button 2745.
CA 02312641 2000-06-23
-65-
D. Rule List Builder GUI
Front end system 110 provides a rule list builder GUI to facilitate the user
in creating/updating rule set lists. This creating/updating of rule set list:.
is
accomplished via rule/scorecard module 1405. The rule list builder GUI is used
to create/update records in rule list table 1515 (FIG. 17). An exemplary rule
list
builder GUI screen is shown in FIG. 28.
Referring to FIG. 28, the rule list builder GUI includes four (4) input
windows and a possible rule sets window 2820. Possible rule set window 2820
indicates the available rule sets to include in the rule set list. The four
input
windows include a rule list ID input window 2805, a description input window
2810, an effective date input window 2815, and an included rule sets input
window 2825. These input windows allow the user to specify the data for the
records in rule list file 1 S 15 in FIG. 17.
In general, rule list ID input window 2805 allows the user to specify the
unique ID for the rule set list. The data entered into this window becomes the
data shown in ID field 1705. Description input window 2810 allows the user to
specify the description for the rule set list. The data entered into this
window
becomes the data shown in description field 1710. Effective date input window
2815 allows the user to specify the date the rule set list is to be active.
The data
entered into this window becames the data shown in effective date rield 1715.
Included rule sets input window 2825 allows the user to determine the rule
sets
that make up the rule set list. The way the user utilizes the rule list
builder GUI
to determine the rule sets that make up the rule set list will be described
neat.
As the rule set builder GUI, the rule list builder GUI includes three
buttons to facilitate the user in determining the expressions to include in
the rule
set. These buttons include add button 2830, move up button 2835, and move
down button 2840. The way in which the user adds a rule set to included rule
sets
2825 is to highlight the desired rule set in possible rule sets 2820 and click
on add
button 2830. This moves the. desired rule set from possible rule sets 2820 to
included rule sets 2825. The way in which a user can manipulate the ord<;r in
CA 02312641 2000-06-23
-66-
which the rule sets are executed in included rule sets 2825 is by using move
up
button 2830 and move down button 2835. To move a rule set up one, the user
simply highlights the desired rule set in included rule sets 2825 and clicks
on
move up button 2835. To move a rule set down one, the user simply highlights
the desired rule set in included rule sets 2825 and clicks on move down button
2840.
E. Scorecard Builder GUI
Front end system 110 provides a scorecard builder GUI to facilitate the
user in creating/updating scorecards 650. This creating/updating of
scorec~~rds
650 is accomplished via rule/scorecard module 1405. The scorecard builder GUI
is used to create/update records in scorecard table 1520 (FIG. 18). An
exemplary
scorecard builder GUI screen is shown in FIG. 29.
Refernng to FIG. 29, the scorecard builder GUI includes seven (7) input
windows and an available characteristics window 2930. Available
characteristics
window 2930 indicates the available characteristics to include in scorecard
fi50.
The available characteristics are located in expression folder 2045 and
characteristic folder 2060.
The seven input windows include a scorecard ID input window 2905, a
description input window 2910, an effective date input window 291 >, a
challenger input window 2920, a usage input window 2925, an included
characteristics input window 2935, and an attributes input window 2940. These
input windows allow the user to specify the data for the records in scorecards
file
1 S 15 in FIG. 18.
In general, scorecard ID input window 2905 allows the user to specie the
unique ID for scorecard 650. T he data entered into this window becomes the
data
shown in ID field 1805. Description input window 2910 allows the user to
specify the description for the scorecard. The data entered into this window
becomes the data shown in description field 1810. Effective date input window
2915 allows the user to specify the date the scorecard is to be active. The
data
CA 02312641 2000-06-23
-67-
entered into this window becomes the data shown in effective date field 1815.
Included characteristics input window 2935 allows the user to determine the
characteristics that make up scorecard 650. The characteristics included in
the
current scorecard are indicated by an ID 2945. Attributes input window 2940
allows the user to define the fields for each attribute record of each
characteristic.
In general, attributes are defined as a numeric value, positive or negative,
that is
evaluated for a characteristic of a scorecard and added to an overall score.
Attributes input window 2940 includes an operator field 2950, a value field
2955,
and a points field 2960.
As described above, the user may define the percentage of time the
scorecard (i.e., champion) is used to score the application versus a
Challenger
scorecard. The general purpose of the challenger scorecard is to compare its
results to those of the champion scorecard to determine if it provides a
better
evaluation of credit worthiness. Challenger input window 2920 allows the user
to determine which scorecard ~550 will be used as the challenger. Usage input
window 2925 allows the user to determine the percentage of time the challenger
will be used to score the application. The way the user utilizes the scorecard
builder GUI to determine the characteristics that make up the scorecard will
be
described next.
As the previously described builder GUIs, the scorecard builder C~UI
includes buttons to facilitate the user in determining the characteristics
(and
attributes) to include in scorecard 650. These buttons include an add/remove
button 2963, an add button 2965, and a remove button 2970. The way in which
the user adds a characteristic from available characteristics 2930 to included
characteristics 2935 is to highlight the desired characteristic in available
characteristics 2930 and click. on add button 2963. This moves the desired
characteristic from available characteristics 2930 to included characteristics
2935.
The way in which the user adds and removes an attribute from a characteristic
is
via add button 2965 and remove button 2970. To add an attribute, the user
simply highlights the desired attribute to add and clicks on add button 2965.
To
CA 02312641 2000-06-23
-68-
remove an attribute, the user simply highlights the desired attribute to
remove and
clicks on remove button 2970.
An exemplary scorecard builder GUI screen illustrating example attributes
of a characteristic is shown in 1~IG. 30. Attributes input window 2940
includes
S operator field 2950, value field 2955, and points field 2960. Referring to
FIG. 30,
the attributes for expr! Ch-Income characteristic 3005 is shown in attribute
records
3010. These attributes include 300, 15, 10, and 5.
An exemplary scorecard builder GUI screen illustrating challenger input
window 2920 is shown in FIG. 31. Here, the user clicks on the arrow down and
a pull down window 3105 is displayed. The user then clicks on the desired
scorecard 650 that is to be the challenger scorecard.
An exemplary scorecard builder GUI screen illustrating usage input
window 2925 is shown in FIG. 32. Here, the user clicks on the arrow down .and
a pull down window 3205 is displayed. The user then clicks on tlhe desired
number that is to be the percentage of usage for the challenger scorecard.
F. Matrix Builder GUI
Front end system 1 I 0 provides a matrix builder GUI to facilitate the user
in creating/updating one or more of matrix 625. This creating/updating of
matrix
625 is accomplished via rule/scorecard module 1405. The matrix builder GC1I is
used to create/update records in matrix table 1525 (FIG. 19). An exemplary
matrix builder GUI screen is shown in FIG. 33.
Referring to FIG. 33, the matrix builder GUI includes eight (8) input
windows and an available c;olumn/row variable window 3390. Available
column/row variable window 3390 indicates the available variables for a column
variable input window 3320 and a row variable input window 3330. Some ofthe
available variables are located in expression folder 2045, a calculation
folder, and
database folder 2055.
The eight input windows include a matrix ID input window 33CI5, a
description input window 33 i 0, an effective date input window 3315, column
CA 02312641 2000-06-23
-69-
variable input window 3320, a number of columns input window 3325, row
variable input window 3330, a number of rows input window 3335, and a matrix
input window 3340. These input windows allow the user to specify the data iEor
the records in matrix file 1525 shown in FIG. 19.
In general, matrix ID input window 3305 allows the user to specify the
unique ID for matrix 625. The data entered into this window becomes the data
shown in ID field 1905. Description input window 3310 allows the user to
specify the description for matrix 625. The data entered into this window
becomes the data shown in description field 1910. Effective date input window
3315 allows the user to specify the date matrix 625 (that is currently being
built)
is to be active. The data entert:d into this window becomes the data shown in
effective date field 1925.
Column variable input window 3 320 allows the user to specify the column
variable for matrix 625. Number of columns input window 3325 allows the user
to indicate the number of columns in matrix 625. Row variable input window
3330 allows the user to specify the row variable for matrix 625. Number of
rows
input window 3335 allows the user to indicate the number of rows in matrix
625.
Finally, matrix input window 3 340 provides the user with a way of defining
the
data in matrix 625. For example, in FIG. 33, matrix data includes the grades
A1,
A2, A3, B l, B2, and so forth. The way the user utilizes the matrix builder
CiUI
to determine the size, row, column, and matrix data that make up matrix 625
will
be described next.
The matrix builder GUI includes buttons to facilitate the user in
determining the size, row, column, and matrix data to include in matrix 625.
These buttons include a set as col button 3345, a set as row button 3350, a
re:>ize
table button 3355, an add column button 3370, a remove column button 3375, an
add row button 3380, and a remove row button 3385. The way in which the user
defines the column variable is to highlight the desired variable in available
column/row variable window 3390 and click on set as column button 3345. This
moves the desired variable to column variable window 3320. The way in which
the user defines the row variable is to highlight the desired variable in
available
CA 02312641 2000-06-23
-70-
column/row variable window _"~.390 and click on set as row button 3350. This
moves the desired variable to row variable window 3330.
The user defines the size of matrix 625 by entering a number in both
number of columns input window 3325 and number of rows input window 33:35,
and then clicking on resize table button 3355. This resizes matrix 625 to
include
the desired number of rows and columns.
'the present invention also allows the user to change the rows and/or
columns in matrix 625. To add or remove a desired column, the user simply
highlights the column and clicks on add column button 3370 or remove column
button 3375, respectively. To add or remove a desired row, the user simply
highlights the row and clicks on. add row button 3380 or remove row button
3385,
respectively.
G. Request Builder GUI
Front end system 110 provides a request builder GUI to facilitate the user
in creating/updating requests. 'Chis creating/updating of requests is
accomplished
via initiator module 1410. The request builder GUI is used to create/update
records in requests table 1530 (FIG. 15). An exemplary request builder CiUI
screen is shown in FIG. 34.
Referring to FIG. 34, the request builder GUI includes three (3) input
windows, a modules description window 341 S, and a features description window
3420. Modules description window 3415 indicates the available modules fiom
which the user can choose to create the request. These modules include (from
FICA. 8) bureau module 805, score module 810, policy module 8I5, product
module 820, and price module 825. Features description window 341 S indicates
the available features (for each module) from which the user can choose to
create
the request. These features may include one or more of the features described
abave in Section VI. Note that when a particular module in module description
window 3415 is highlighted, all of the available features for that highlighted
module are automatically displayed in feature description window.
CA 02312641 2000-06-23
-71-
The three input windows include a request ID input window 3405., a
description input window 3410, and a request input window 3425. Request input
window is organized like a file with records having three fields. The three
fields
include a module field 3430, a feature field 3435, and an arguments) field
3440.
These input windows allow the user to specify the data for the records in
request
file 1525.
In general, request ID input window 3405 allows the user to specify the
unique ID for the request. Description input window 3410 allows the user to
specify the description for the request. Module description window 3415 and
feature description window 3420 allows the user to determine the features of
modules that make up the request. The way the user utilizes the request
builder
GUI to determine the features of modules that make up the request will be
described next.
The request builder G11I includes four buttons to facilitate the user in
determining the features of modules that make up the request in request input
window 3425. These buttons include add button 3445, remove button 3450,
move up button 3455, and move down button 3460. The way in which the user
adds a desired feature of a module from module description window 3415 .and
feature description window 3420 is a three step process. First, the desired
module
must be highlighted in module description window 3415. As explained above,
once a particular module is highlighted, the available features for the
highlighted
module are automatically displayed in feature description window 3420. Next,
the user highlights the desired feature in feature description window 3420.
Finally, the user simply clicks on add button 3445 to add the feature (of the
module) to the request.
The user removes a desired feature (of a module) from the request by
highlighting the appropriate record in request input window 3425 and click ors
the
remove button 3450. The order in which the features are executed in the
request
can be defined by the user with move up and move down buttons 3455 and 3460.
The request executes the features in a top down fashion. For example, in FIG.
34,
the call feature of bureau module 805 will be executed first, followed by the
score
CA 02312641 2000-06-23
-72-
feature of score module 810, arid so forth. To move a feature up one, the user
simply highlights the desired feature and then clicks on move up button 3455.
'To
move a feature down one, the user simply highlights the desired feature and
clicks
on move down button 3460.
VIII. Conclusion
While various embodiments of the present invention have been described
above, it should be understood that they have been presented by way of
example,
and not limitation. It will be apparent to persons skilled in the relevant art
that
various changes in form and detail may be made therein without departing from
the spirit and scope of the invention. This is especially true in light of
technology
and terms within the relevant arts) that may be later developed. Thus, the
present invention should not be limited by any of the above-described
exemplary
embodiments, but should be defined only in accordance with the following
claims
and their equivalents.
