CA2312641A1 - System, method, and computer program product for providing user-defined customization in the evaluation of credit worthiness - Google Patents

Abstract

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 includes a credit evaluation customization system that executes a request to evaluate credit worthiness, a customization database that stores both pre-defined and user-defined data that is used by the customization system, and a front end system that preferably provides a graphical user interface to both access the customization system and to customize the data stored in customization database. The method of the present invention involves customizing data and evaluating the credit worthiness of the application by executing a request while utilizing the customized data.

Description

-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

-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

-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

-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;

-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;

-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;

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

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

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.

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

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

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

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

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

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

Table 1 CUSTOM
SCORE
BUREAU

5~0 ~D ~I00 SCORE

750' A1 A2 A3 B1 B2 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 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.

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

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

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 bureau module 805, and the request itself (the listing of the bureau module 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 ~

Bureau App l Bu 1 1 n 1 - Bu9 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 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.

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.

Table 7 LTV
BUREAU
70l6 ?~/~o $0/0 90l0 I00%
SCORE

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.

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

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 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 illustrates an exemplary rate matrix that compares the amount financed by 'the term.
Table 10 TERM
AMOUNT

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

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 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 calculations (by calculator module 710). These results get stored in database 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 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 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 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 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.

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.

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.

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

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

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

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

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

Claims (38)

What Is Claimed Is:

1. A system for evaluating credit worthiness of an application based on user-defined customization, comprising:
a customization database having stored therein data for evaluating credit worthiness, wherein said database data includes at least one rule;
a customization system, wherein said customization system executes a request for evaluating credit worthiness of the application by using said rule; and a front end system, wherein said front end system includes means for allowing the user to customize said database data and access said customization system.

2. The system of claim 1, wherein said database data is either passed in via said front end system, collected by said customization system, or derived by said customization system.

3. The system of claim 1, wherein said front end system is a web server.

4. The system of claim 1, wherein the application is a consumer or a business application.

5. The system of claim 1, wherein said rule is in one of the following categories:
pre-feature, selection, policy, scorecard, and calculation.

6. The system of claim 1, wherein said means for allowing the user to customize said database data comprises an expression builder graphical user interface, wherein said expression builder graphical user interface facilitates the user in creating and updating said rules.

7. The system of claim 1, wherein said means for allowing the user to customize said database data comprises a rule set builder graphical user interface, wherein said rule set builder graphical user interface facilitates the user in creating and updating a rule set, wherein said rule set is a collection of said rules.

8. The system of claim 7, wherein said means for allowing the user to customize said database data comprises a rule list builder graphical user interface, wherein said rule list builder graphical user interface facilitates the user in creating and updating a rule set list, wherein said rule set is a collection of said rule sets.

9. The system of claim 1, wherein said means for allowing the user to customize said database data comprises a scorecard builder graphical user interface, wherein said scorecard builder graphical user interface facilitates the user in creating and updating a scorecard, wherein said scorecard is a category of said rules.

10. The system of claim 1, wherein said means for allowing the user to customize said database data comprises a matrix builder graphical user interface, wherein said matrix builder graphical user interface facilitates the user in creating and updating a matrix.

11. The system of claim 1, wherein said means for allowing the user to customize said database data comprises a request builder graphical user interface, wherein said request builder graphical user interface facilitates the user in creating and updating said request.

12. The system of claim 1, wherein said customization system comprises:
application processing modules for providing processing features;
administration modules for interfacing with said database and said front end system; and background modules for performing background functions required by said application processing modules and said administration modules.

13. The system of claim 12, wherein said application processing modules comprise:
a bureau module for obtaining and evaluating credit bureau data for the application;
a score module for determining a score for the application using a scorecard, for determining a grade for the application based on said score, and for determining a decision for the application based on said grade;
a price module for determining possible loan terms for the application based on said grade;
a policy module for reviewing the application based on a policy rule, wherein said policy module may change said decision based on said policy rule; and a product module for determining whether the application is eligible for multiple products.

14. The system of claim 13, wherein said bureau module, said score module, said price module, said policy module, and said product module have a pre-bureau feature, a pre-score feature, a pre-price feature, a pre-policy feature, and a pre-product feature, respectively, for determining whether to execute its respective said module.

15. The system of claim 13, wherein said loan terms include a suggested interest rate, a payment, a deposit amount, and a credit limit.

16. The system of claim 13, wherein said products include vehicle loans, vehicle leases, home equity loans, and credit cards.

17. The system of claim 12, wherein said administration modules, comprise a rules/scorecard module for creating and modifying said rules;
a user/database module for managing the security of said customization system and administration of said database;
an administration module for providing an administration graphical user interface to said database; and an initiator module for executing said request.

18. The system of claim 17, wherein said administration modules further comprise an object request broker manager module.

19. The system of claim 12, wherein said background modules comprise:
an evaluator module for evaluating said rules;
a calculator module for performing mathematical calculations requested by said evaluator module when evaluating said rules;
a data manager module for handling interactions with said database data; and an external data parser module for accepting input data in various formats, parsing said input data, and saving said input data in said database.

20. The system of claim 19, wherein said formats include fixed length and comma delimited.

21. A method for evaluating credit worthiness of an application based on user-defined customization, comprising the steps of:
setting up a customization database, said database having stored therein data for evaluating credit worthiness, wherein said database data includes at least one rule;
evaluating, with a customization system, the credit worthiness of the application by executing a request, wherein said request includes said rule;
allowing the user to customize said database data through a front end system; and allowing the user to access said customization system through said front end system.

22. The method of claim 21, wherein said database data is either passed in via said front end system, collected by said customization system, or derived by said customization system.

23. The method of claim 21, wherein said front end system is a web server.

24. The method of claim 21, wherein the application is a consumer or a business application.

25. The method of claim 21, wherein said rule is in one of the following categories:
pre-feature, selection, policy, scorecard, and calculation.

26. The method of claim 21, wherein said step of allowing the user to customize comprises the steps of:
providing an expression builder graphical user interface;
allowing the user to create said rules via said expression builder graphical user interface; and allowing the user to update said rules via said expression builder graphical user interface.

27. The method of claim 21, wherein said step of allowing the user to customize comprises the steps of:
providing a rule set builder graphical user interface;
allowing the user to create a rule set via said rule set builder graphical user interface, wherein said rule set is a collection of said rules;
and allowing the user to update said rule set via said rule set builder graphical user interface.

28. The method of claim 27, wherein said step of allowing the user to customize comprises the steps of:
providing a rule list builder graphical user interface;
allowing the user to create a rule set list via said rule list builder graphical user interface, wherein said rule set list is a collection of said rule sets; and allowing the user to update said rule set list via said rule list builder graphical user interface.

29. The method of claim 21, wherein said step of allowing the user to customize comprises the steps of:
providing a scorecard builder graphical user interface;

allowing the user to create a scorecard via said scorecard builder graphical user interface, wherein said scorecard is a category of said rules;
and allowing the user to update said scorecard via said scorecard builder graphical user interface.

30. The method of claim 21, wherein said step of allowing the user to customize comprises the steps of:
providing a matrix builder graphical user interface;
allowing the user to create a matrix via said matrix builder graphical user interface; and allowing the user to update said matrix via said matrix builder graphical user interface.

31. The method of claim 21, wherein said step of allowing the user to customize comprises the steps of:
providing a request builder graphical user interface;
allowing the user to create said request via said request builder graphical user interface; and allowing the user to update said request via said request builder graphical user interface.

32. The method of claim 21, wherein said step of evaluating comprises the steps of:
providing processing features;
interfacing with said database and said front end system; and performing background functions required by said providing step and said interfacing step.

33. The method of claim 32, wherein said providing step comprises the steps of:
obtaining credit bureau data for the application;
evaluating said credit bureau data;

determining a score for the application using a scorecard;
determining a grade for the application based on said score;
determining a decision for the application based on said grade;
determining possible loan terms for the application based on said grade;
reviewing the application based on a policy rule;
determining whether to change said decision based on said policy rule; and determining whether the application is eligible for multiple products.

34. The method of claim 33, wherein said loan terms include a suggested interest rate, a payment, a deposit amount, and a credit limit.

35. The method of claim 33, wherein said products include vehicle loans, vehicle leases, home equity loans, and credit cards.

36. The method of claim 32, wherein said interfacing step comprises the steps of:
creating said rules;
modifying said rules;
managing the security of said customization system;
managing the administration of said database;
providing an administration graphical user interface to said database; and executing said request.

37. The method of claim 32, wherein said performing step comprises the steps of:
evaluating said rules;

performing mathematical calculations requested by said evaluating step;
handling interactions with said database data;
accepting input data in various formats;
parsing said input data; and saving said input data in said database.

38. The method of claim 37, wherein said formats include fixed length and comma delimited.