CA2239713A1 - System and method for performing on-line reviews and approvals of credit and liability applications - Google Patents

Abstract

An on-line computerized system that operates in real-time to process applications for products and services offered by a financial institution. The system automates the credit and liability review and approval process, performs background credit worthiness evaluations based on applicant's (10) credit score (28), financial information and new or existing relationship with the financial institution (52), recommends to those applicants (10) that exceed the initial criteria for credit consideration specific credit products with predetermined credit qualified offer amounts. The system immediately analyzes an applicant's (10) credit bureau history (30, 32, 34) and automated credit scoring (28), and provides these results to the LBR (12). The system can supply applicants with up-front conditional approval (based on systematic evaluation of credit bureau history, credit score, debt burden, and applicant's new or existing relationship deposits), subject to required verifications. The invention can also identify and communicate to the LBR (12) other services/products which the applicant may be credit worthy but has not requested. The LBR (12) can then offer a package of products, enhancements (tier pricing) and services to the applicant rather than simply the one requested. For those applicants (10) that exceed credit criteria, the system recommends specific credit products with predetermined credit qualified offer amounts. Processing may be interrupted and continued for the same applicant at a later point with the same or different LBR (12).

Description

W O 97/22073 PCT~US96/19228 SYSTEM AND METHOD FOR PERFOR~'IING ON-LINE REVIEWS AND
APPROVAT ~ OF CR~,nlT ~D T,~B~I,TTY APP~-ICATIONS

5 FIFT D OF THF TNVl~NTION
The present invention relates generally to systems and methods for performing reviews and approvals of credit and liability applications, and more particularly to a system and method for performing automated, real-time, on-line review of credit and liability applications.
R,ACKGROUND OF THF INVFNTION
The process of applying for credit or liability products usually begins with an applicant requesting either credit or liability products; and in the case of credit requests, usually the applicant requests credit on a single credit product. As used herein, an 15 applicant can be either an e~ tin~ customer or a potential customer, and can be either an individual, several individuals or an entity, such as a col~uldlion~ partnership or association. In any case, applicant merely refers to an individual(s) or entity submitting an application to a fin~nci~l in~tit~ltion for credit or liability products. When an applicant enters a fin~nci~l in~tihltion to apply for some credit or liability product offered by the 20 fin~nr.i~l in~ti11ltion, the local branch representative (LBR) requires the applicant to fill out an application and then typically rOI ~v~.ls the application to a back office, where the application is reviewed to ~ i..e whether or not to extend the requested credit or to open the requested liability account.
Most fin~nci~l in~ti~-tions apply some criteria to det~-rmin~ whether the applicant 25 is credit worthy for the particular credit product requested, and some financial institutions apply some criteria to ciel~ e which requests to open a ~lPm~n~l deposit account (a CA 02239713 1998-06-0~
W O 97/22073 PCT~US96/19228 bank liability) should be allowed. Usually the differentiation of criteria for each product is based on risk and acceptable levels of losses.
Unfortunately, a large segment of the population may fail this initial screeningcriteria for one reason or another. To make matters worse, the LBR cannot immediately 5 differentiate credit worthy applicants from the rest. This requires the LBR to spend a substantial amount of time with some applicants, only to ultimately d~le .lli..e that they do not meet the financial institution' s criteria. This creates an inefficiency in the lending process; those most deserving of credit or liabilitv products must wait longer to obtain the desired product while the LBR spends extensive sales time on all applicants, some of 10 which may not ~ualify for any credit or liability products. These inefficiencies result in customer service ~ s~ti~f~rtion and higher fees for all applicants.
The present invention is therefore directed to the problem of developing a method and system for ~,elru~ ing credit and liability reviews that: (1) identify a credit worthy applicant or provide an indication that an applicant is probably not credit worthy for the 15 particular product being requested (thus eli.n;..;~ the need to fulfill the entire sales session) to the LBR im meAi~tçly at the time of the application; (2) provide systematic verification requirements; (3) provide a liability screen (~em~nd deposit screen) for the financial inctitlltion; (4) provide pricing by tier for specified products; (5) provide an interface to service bankcard products; (6) enable m~ximllm debt burden offer logic; and 20 (7) provide application pending functionality.

SUMl~l~Y OF THF T~VFI~TION
The present invention solves this problem by providing a user-friendly on-line co~ ul~.ized system that stre~mline~ the proces~ing of applications for products and 25 services offered by a fin~nri~l institution, that automates many steps in the review and approval process, that pt;lr~,~-lls background credit wu~LLil~ess co~ ,~isons based upon an applicant's credit score, financial information and new or ç~ tin~ relationship with the financial institution, if any, that recommen-lq to those applicants who exceed the initial CA 022397l3 l998-06-0~

W O 97/22073 PCTrUS96/19228 criteria for credit consideration specific credit products with predetermined credit qualified offer amounts, and that ensures the required operating (credit/liability) policies are app~ iately completed.
According to the present invention, specifically for credit requests, the systemS irnmediately analyzes an applicant's credit bureau history, automated credit scoring, credit policies and the applicant' s new or existing relationship with the financial institution, if any, and provides these results to the LBR in a surnrnarized forrnat. This feature enables the LBR the ability to provide applicants with an up-front automated conditional approval, subject to required verifications.
The system and method of the present invention alleviate the loss of time problem for the lender by offering a capability of identifying applicants to whom the financial in~titlltion would like to extend credit and/or liability products, based on those requested, or to offer additional services or other credit and/or liability products. ~or example, by identifying an applicant as potentially credit worthy for a variety of other products that the applicant has not requested, the ~BR can offer a more attractive package of products to the applicant that will ~nh~nre the service and potentially the pricing being provided.
This feature enables the LBR to target his or her efforts to those applicants to which the financial institution can offer a full range of services and benefits, above and beyond those requested by the applicant.
Another advantageous implementation of the system and method of the present invention provide the capability of recomm~n-lin~ to those applicants who exceed the initial criteria for credit consideration specific products with predetermined credit ~ualified offer amounts.
Another advantageous implementation of the system and method of the present invention provide the capability to present applicants ~ ue~ling credit with the maximum allowable line of credit or loan atnount whose estim~ted payment would not exceed the product specification parameters. Thus, the system and method of the present invention provide the capability to incorporate into automated response processing resllltin~ up-CA 02239713 1998-06-0~
W O 97/22073 PCT~US96/19228 sells or counter-offers, as they relate to the applicant's credit request. As a result of the present invention this capability is now available at the local branch, which heretofore was not possible.
Another advantageous implement~tion of the system and method of the present S invention provides the capability to the financial institution to continue processing an application that was begun at an earlier point in time with potentially a different LBR.
Previously, each credit or liability application began anew. For example, prior to the present invention when an applicant first entered the financial institution to request a credit or liability product, and the applicant provided some initial information but then 10 left for one reason or another (due to time con~tr~int~, etc.), the incomplete application was discarded, and along with the discarded application went the LBR's time -- a value cornmodity in today's competitive environment. As a result of the present invention, any LBR can continue processing a previous application initi~t~l by himself or herself or any other LBR, thus making use of the time spent previously, as well as saving the applicant 15 from having to repeat all previously supplied data.
Traditionally, verification ~ h~,ments are created or generated ai~ter full review of the credit application and subsequent conditional approval. In another advantageous implement~tion of the present invention, systematically driven verifications categories based on the amount offered and the amount accepted are ~let~iied within the front-end 20 process, identifying to the LBR any and all verification requirements -- thus enabling fillm.?-lt of required verifications during the initial session, provided the applicant has the information available (e.g., identification, phone, employment, income, etc.~. This elimin~tes the standard "paper chase" b~lw~;ell the branch and the applicant, as well as helping to ensure compliance with verification reLlui,~ cnts and thus potentiallv avoiding 25 fraud issues.
The present invention provides an expeditious manner in which consumer retai i branches can provide an imm~liate credit evaluated response (conditional approval.
upsell and/or counter-offer pendtng required verifications) to qualified applicant ~:re~

CA 02239713 1998-06-0~

W O 97/22073 PCTAUS96tl9228 S
requests (e.g., unsecured and real estate secured), while ensuring that the financial institution's required credit policies are ap~ iately completed, limiting risk to the portfolio.
Yet another advantage of the present invention is that systematic completion of 5 required verifications enables on-site acceptance of credit requests and subsequent issuance of funds. In addition, the systematic presentation of required verifications to the ~BR elimin~tP~ the need for the LBR to continl-~lly calculate and re-calculate which specific verifications are required before an application may be completed, saving an enormous amount of time and ~a~ rk.
Another advantageous implementation of the present invention, is relationship pricing by tier. Relationship pricing by tier provides a new or existing customer requesting credit with the least expensive loan rate based upon the customer's total relationship (i.e., deposit b~l~ncec) with the financial in~tihltion. The automation of the selection of the a~p.opl;ate rate solves the problem of choosing the correct rate in an 15 environment that is complicated by many rate alternatives and by the depth and complexity of the customer's relationship with the financial in~tif~ltion.
According to an advantageous impl.oment~tion of the present invention, the present invention p.,rO..lls a systematic analysis of an applicant's social security number and a review of the applicant's çh~ ing account and credit bureau history to det~rmine 20 whether or not to offer the applicant a checking account (c~çm~n~ deposit account) type rel~tion~hip. This evaluation is systematic in nature and affords the financial in~titlltion an efficient method of screening potential checking account candidates while potentially holding fraud loss rates down.
Further, another advantageous implçment~tion of the present invention provides a25 systematic link to the bankcard acquisition process for on-line processing of branch sourced bankcard applications.
The foregoing objects of the invention are illustrative of what can be achieved by the present system and method, and the foregoing objects are not int~nrl~(l to be exhaustive or limiting of other possible objectives. Thus, these and other obiects of the invention will be appd-ent from the description set forth herein or can be learned from practicing the invention, both as embo~liment~ presented as modified in view of variations that may become ~arellt to those having ordinary skill in the art. The present invention resides in the novel system, method, arrangement, _nd combinations that are herein shown and described.
The foregoing and other obiects and advantages of the present invention will appear from the following description, wherein reference is made to the accompanying drawings figures that form a part thereof, and in which there is shown by way of10 illustration and not of limitation, a preferred embodiment of the invention.

R~TFF nFSC~TPTIQN OF THF DRAWIl~GS
FIG 1 shows a block diagram of the system and method of the present invention.
FIG 2 shows credit application status codes, credit score response codes and credit 15 decision messages used with the system and method of the present invention.
FIG 3 shows a credit product definition mAint~n~n,e screen used by the system and method of the present invention.
FIGs 4A-C each show credit decision processing data elements used by the system and method of the present invention.
FIG 5 shows a credit product defimition mA;.~ ce screen used with the system and method of the present invention.
FIGs 6A-E each show credit decision proc~in~ data elements used with the system and methr)d of the present invention.
FIG 7 shows a credit product definition mAintenAn~e screen used with the system 25 and method of the present invention.
FIG 8 shows a credit decision procPs~ing data elements used with the system and method of the present invention.

.
CA 02239713 1998-06-0~

W O 97/22073 PCTrUS96/19228 FIG 9 shows a credit product decision m~inten~n~e screen used with the system and method of the present invention.
FIGslOA-H each show credit decision proces~in~ data elements used with the system and method of the present invention.
S FIG 11 shows the rel~tiQn~hi~ pricing profile matrix used with the system and method of the present invention.
FIG 12 shows the relationship criteria codes and conç~t~n~tion rules used with the system and method of the present invention.
FIGs13A-B each show credit decision processin~ data elements used with the system and method of the present invention.
FIG 14 shows a product profile ~ e screen used with the system and method of the present invention.
FIG 15 shows a credit decision ~ucessil~g data elements used with the system andmethod of the present invention.
FIG 16 shows a credit decision procçs~in~ verifications requirements used with the system and method of the present invention.
FIGs 17A-E each show credit decision proces~in~ data elements used with the system and method of the present invention.
FIG 18 shows an applicant product and inillr~n-~e information screen used with 20the system and method of the present invention.
FIG 19 shows credit decision evaluation data elements used with the system and method of the present invention.
FIG 20 shows an applicant income information screen used with the system and method of the present invention.
25FIG 21 shows a credit decision evaluation data element~ screen used with the system and method of the present invention.
FIG 22 shows a credit product decision definition m~ P~. .ee screen used with the system and method of the present invention.

CA 02239713 1998-06-0~
W O 97/22073 PCTAJSg6/19228 FIG 23 shows data elt?rnente for the credit decision and credit qualifying process used with the system and method of the present invention.
~IG 24 shows data e1emente for the credit decision and credit qualifying processused with the system and method of the present invention.
5FIG 2~ shows the credit qualification panel by the system and method of the present invention.
FIGs 26-29 each show data elements for the credit decision and credit qualifyingprocess used with the system and method of the present invention.
FIG 30 shows the applicant information panel used by the system and method of 10the present invention.
FIGs 31-33 show data elements for the credit decision and credit qualified offerprocess used with the system and method of the present invention.
FIG 34 shows the calculation formula used in the system and method of the present invention.
15FIGs 35-38 each show the Maxhllulll Debt Burden Offer calculation used with the system and method of the present invention.
FIG 39 shows the application routing condition priority table used with the system and method of the present invention.
FIG 40 shows the system initi~1i7~tion diagram for the system and method of the 20present invention.
FIG 41 shows the pre-scleenillg and disaster sc~ hlg procedure used with the system and method of the present invention.
FIG 42 shows the first application score evaluations used with the system and method of the present invention.
25FIG 43 shows the proce~eing for a b~nke~rd application according to the systemand method of the present invention.
FIG 44 shows a diagram of the credit limit and ~imnnn Debt Burden Offer ~e~ignment used with the system and method of the present invention.

CA 022397l3 l998-06-05 W O 97/22073 PCTrUS96/19228 FIG 45 shows additional criteria evaluation used with the system and method of the present invention.
FIG 46 shows the applicant required verifications and automated response generation produced by the system and method of the present invention.
S FIG 47 shows special h~n-llin~ for a secured credit product according to the system and method of the present invention.
FIG 48 shows the applicant offer pl~st;~ ion and response evaluation process according to the system and method of the present invention.
FIG 49 shows counter offer down-sell offer for a lessor credit arnount process according to the system and method of the present invention.
FIG 50 shows up-sell offer or a larger credit of~er process according to the system and method of the present invention.
FIG 51 shows the common process for fini~hin~ according to the system and method of the present invention.

nF,TATr.F,I~ nF~cE~TpTIoN
- The system and method of the present invention (FIG 1 ) provide on-line processing of applications in real time, thus providing conditional approvals, pending required verifications. Many lenders process applications via on-line systems, however, 20 most do not offer the system capability of a front-end procee~ing system (blocks 14 and 16) that provides an imrnediate review of the results of analyzing an applicant's credit bureau history (blocks 28, 30, 32 and 34) and ~ltom~tecl credit scoring. The systcm and method of the present invention involves the unique proces~inp of a new or existing ~;u~lo~ . relationship (blocks 18, 20 and 22) into the credit decision request. This feasure 25 enables the ability to provide new or exi~tin~ customers (block 10) with an up-front conditional approval (based on systematic evaluation of credit bureau history, credis score, debt burden, credit policies and the customer's relationship with the financi~l institution), subject to required verifications.
.

CA 02239713 1998-06-0~
W O 97/22073 PCT~US96/19228 The present invention interfaces with the commercially available credit processing system ACAPS (block 26).
The processing according to the present invention streAmlin~s the credit and liability application/~ro~al process which results in more timely decisions. The process S enhances branch efficiencies and productivity by automating many steps in thecredit/liability application and approval process that are traditionally paper-intensive.
In addition to credit application procç~in~, this implementation also performs background credit worthiness evaluations for non-credit application processing (such as to open demand deposit accounts) based upon the applicant's credit bureau inforrnation, 10 financial information and new or existing relationship with the financial institution, if any. These evaluations may create a decision that results in an indication that the applicant 10 is credit qualified. These indications will show the LBR 12 which applicants exceed the initial criteria for credit approval, and may recommen~l specific credit products with pre-(leterrnined credit qualified offer amounts, as well as identifying those applicants 15 to which to offer more attractive credit product opportunities.

BUSINESS PROBLEM SOLVED
CREDIT RESPONSE
The present invention provides an expeditious manner in which conc--mer retail 20 branches can provide an imrnediate credit evaluated response (conditional approval, upsell and/or counter-offer pending required verifications) to qualified applicant credit requests (e.g., unsecured and real estate secured), while ensuring that the financial in~tihltion's required credit policies are ~ro~.lately completed, thereby potentially limiting risk to the portfolio.
All established product prograrn re~uirements (front-end screens, disaster screens, credit score, debt burden), as well as consideration of a new or existing customer's deposit balance, are ~ tiç~lly completed and ranked (A, B, C, D) within a matter of seconds. This enables the LBR 12 to imme~ tely convey credit evaluation status W O 97/22073 PCT~US96/19228 (leco------en~le~l approval, conditional approval, upsell, counter-offer, recommended turndown) to the applicant 10. The A, B, C, D status r~nkin~ indicate to the LBR 12 the direction to take during the sales session (i.e., the systematically provided r~nking~
identify high and low credit risks). For purposes of expeditious back of fice proce~sin~, S block 44, these r~nkin~ also delineate which requests for credit may be processed for irnmediate appeal, resulting in an immerliP~e booking or imrnediate adverse action. This enables the LBR 12 to immediately identify an applicant that is highly valuable to the financial institution.
Reference the following chart that details the actions associated with various 10 responses used in the system and method of the present invention:

W O 97/22073 PCTnUS96119228 RESPONSE CONDITION
A Recommended Approval The LBR has already completed the required verifications, and with the applicant's consent, accepts the credit request, which systematically initiates an interface to the booking system (i.e., servicing or billing system) for specified products.

Conditional Approval/Counter~Offer The LBR must complete all required verifications (e.g., identification, phone~
employment, income. etc.). Upon completion of required verifications and with the applicant's consent, the LBR may "Accept" the credit request, which systematically initi~tes an interface to the booking system (for specified products~.
B Recommen-iecl Turndown The system has identified that: (I ) the applicant is non-established, or a Non-Resident Alien (NRA); or (2) the applicant has limited or marginal credit; or (3) the applicant has credit bureau issues (derogatory trade) and high liability bal~n~Pc In all three cases, the LBR may contact the back office ~,vith an immP~i~te appeal.
C Recomm~n~led Turndown D Recommended Turndown The product profile requirement tables detail the parameters of the credit evaluating processes (e.g., front-end screens, disaster screens, credit score, debt burden CA 02239713 1998-06-0~

and liability balances) by product type within a region. These parameters are systematically evaluated at the time the application is tr~n~mitte~l via the front-end processing system (blocks 14 and 16) or entered into ACAPS 26.
Evaluation of previously established approval criteria is divided into two 5 segments (i.e., subcodes, which are credit decision and bank liability decision). Within risk evaluating components (e.g., front-end screens, disaster screen, credit score and debt burden) various conditions are allocated specific A, B, C, or D response code r~nking~
The worst (B is worse than A, C is worse than B, etc.) alpha ranking of all components - under consideration for the credit decision is selected as the credit decision subcode. The 10 credit decision subcode and the liability decision subcode are compared and the best (A is better than B, B is better than C, etc.) of the two subcodes is chosen to determine the response code to be transmitted back to the LBR 12 via the front-end platform (blocks 14 and 16). ~valuation and k~n~micsion on average take only a matter of seconds and are available 7 days a week, which enables the LBRs 12 almost in~t~nt~neous -- on the spot -15 - response to the applicant's request for credit. For unsecured products (e.g., in~tsl~ment loans) the ability to finalize the credit request at the branch also affords the LBR the opportunity to fulfill the request in the branch during the initial session.
The response logic of the present invention is region and product-specific enabling flexible credit evaluating criteria to be ~plo~,l;ately controlled to ensure an 20 acceptable credit risk exposure based on ch~n~ec in regional portfolio conditions, changes in economy, etc. As used herein, location refers to a defined region (i.e., state, etc.).

MAXIMUM DEBT BURDEN OFFER
The M~ci~ Debt Burden Offer provides applicants requesting credit 25 (revolving or closed-end) with the m~ximllm allowable line of credit or loan amount, whose estim~t~cl payment for the requested product, in addition to all known debt payments (applicant provided debt, including rent or mortgage payments, and credit bureau derived payments), would not exceed the product specified parameters (line W O 97/22073 PCT~US96/19228 ~ignmPnt tables) up to the ~iesign~terl controlling debt burden table parameter such as 45%. The resl~ltin~ upsell or counter-offer, as it relates to the applicant's credit request, is incorporated within response processin~ of the present invention and is therefore available for the LBR ~block 12) to discuss with the applicant 10 within the session. "
S Maximum Debt Burden Offer is initiated when an applicant's request for credit exceeds a specified amount that can vary by location and product. ACAPS 26 systematically evaluates the following components to determine whether or not to upsell or counter-offer after evaluation of the following components:

REQUESTED 1) Applicant requested amount CREDIT 2) Maximum amount eligible (Applicant does not specify a specific amount, rather applicant re~uests the mzlximum amount for which the applicant is eligible.) 3) Product ~
MAXIMUM DEBT Maximum loan or line dollar amount whose associated monthly BURDEN OFFER payment, when added to the monthly payment amounts for the applicant's existing debts and rent or mortgage payment, divided by the customer's monthly income, creates a debt burden ratio (such as 45%) that is specified in the product parameters.

If the maximum debt burden amount is negative or not used because amount requested is less than ~leeign~tecl parameter (e.g., $2,500) the amount ~seign~cl to ~l~ximl-m Debt Burden Offer will default to product minimllm LINE Systemic Line ~eei~nmpnt Tables ASSIGNMLNT

An applicant's good credit experience, monthly income and monthly debt payments (incorporating estim~t~-l monthly payment associated with the newly requested 5 debt) are systematically evaluated upon tr~nemieeion of credit request providing the LBR
12 and applicant 10 with knowledge of the m~ximllm exposure that the product prograrns will allow prior to judgmental review. This process primarily uses monthly credit bureau information, including mortgage payments, which allows a ~ximllm Debt Burden Offer without applicant 10 provided information. Overall, the process of the present invention 10 provides improvement in credit evaluation/proceseing time as well as a sl-~st~nti~l reduction in unit cost processing (i.e., 65% decrease) while providing an elegance in sales ~, W O 97/22073 PCTAUS96/~9228 conversation and expeditious decisions (in person or on the phone) for both approvals and turndowns.

SYSTEMIC VERIFICATIONS
Systemic verification provides an LBR 12 with systematic id~ntificHtion of verification categories required ~product program) based on the amount offered and accepted which is displayed on the front-end platforrn (blocks 14 and 16). The platforrn provides the required verifications in a picklist forrnat and enables the LBR 12 to select a methodology of completing required verifications, which is then transmitted to ACAPS
0 26. The system allows an LBR, when directed by the applicant, to accept an offered line or loan arnount at any time after the offer is made -- thus completing the application cycle of application, financial in~tit~ltion decision, offer to applicant, acceptance of offer, and in some cases, the issuance of funds, pending required verifications. However, in the presence of llns~ti~fiç~l verification requirements, the system will not allow the 15 subsequent new account opening functionalities (i.e., booking) to automatically be performed. The system requires an "acceptance" transaction to be performed (usually by the LBR) after all the verification requirements have been satisfied to allow the subsequent new account opening functionalities to be automatically ~ oln~ed, thus ensuring compliance with the verification re~uilcl~rc..l~ and potentially avoiding fraud 20 issues.
Syst~mHtic completion of required verifications enables on-site acc~pl~lce of credit requests and subsequent issuance of funds-for ~l~ci~nAt~l products, e.g., inst~llmçnt loans. The ACAPS 26 system has imbedded into each product classification a required verifications profile (FIGs 16 through 1 7E), which indicates which types of verifications 25 are required based on the arnount requested and, eventually, the amount accepted by the applicant 10. The systematicpLcs~ ~tHI i~nofrequiredverificationseliminHtestheneed for the LBR 12 to contim~HIly calculate and re ~calculate which specific verifications are required before an application may be completed. In addition to the ACAPS 26 W O 97/22073 PCTnJS96/19228 automated plesenlalion of the types of required verifications necessaly, it also provides to the front end processing system ~blocks 14 and 16) a listing of types of required verifications that may be performed to fulfill the verification requirements. This listing is converted into a picklist of required verifications options, which facilitates for the LBR
5 12 rapid completion of required verification procedures.
The ACAPS 26 m~int~ins verification requirements (which are table driven) by region and product, which identify by ~lesi~n~t~od offered and accepted amount of credit exactly which type of verifications (e.g., ic~entific~tion, phone, employment, income, etc.) are required before the system will enable the application for credit to be accepted.
10 Differentiation by product type enables ACAPS 26 to establish ~plo~.;ate verification requirements for branch or back-office generated requests and for different product types (e.g., unsecured/real estate secured, etc.). The branch front-end system (blocks 14 and 16) forces identification verification for proce~in~, whereas back office requests (block 44) require identification verification in a different manner.

RELATIONSHIP PRICING BY TIER
Via on-line real-time integration of the many systems (block ~2) involved in theprocess, all of the existing customer' s accounts are ~y~ ti- ~lly and autom~tic~l ly reviewed during the application session to det~rrnin~ the ag~ le balance amount,20 which gives rise to the best price being offered to the ~xi~ting customer 10 for the re~uested credit product. Price includes the h~ntll in~ of both fixed interest rate and variable rate (e.g., in~exe~ rates, such as prime rate plus margin) priced loan types.
Relationship pricing by tier provides the loan applicant 10, i.e., in this case, a new or existing customer, with the least expensive loan rate based upon the applicant's total 25 relationship (i.e., deposit b~l~nces) with the financial institution. It also provides the fin~nri~l in~tit~ltion employees with the aL~Lol -iate rate for the loan type considering the applicant's relationship with the financial institution. According to the present invention, the system automatically ex~min~ an applicant's existing accounts as well as newly CA 02239713 1998-06-0~
W O 97/22073 PCT~US96/19228 deposited funds. The automation of the selection of the ~plo~iate rate solves the problem of choosing the correct rate in an environment that is complicated by many rate alternatives and by the depth and complexity of the applicant's pre-existing or newly established relationship with the financial institution. Within a loan product type (such as S an unsecured revolving line of credit) there may be as many as four different rates being quoted to an applicant 10; across products, there are dozens of price points -- too many to be easily and accurately remembered by LBRs 12 and applicants 10. Furthermore, the price points are determin~l from several credit worthiness factors including the total arnount of money on deposit in the fin~nri~l institution (where the deposit amount is the 10 surn of the individual balance arnounts in potentially multiple accounts).
A series of tables in the application proce~ing system (ACAPS 26) contains the price points for each product that has multiple price points. The tables also provide the name of the characteristic (such as balance amount), the break point(s) ~such as less than $1500, greater than or equal to $1500, etc.), and the resulting price(s). Other table values 15 within ACAPS 26 determine whether the automated pricing routines should be used or not used. ~ lmin~ the routines are used, ACAPS 26 calls upon another bank system(block 52), which aggregates all of the customer's balances to obtain the aggregated balance amount to be used in conjunction with the pricing tables to deterrnine the price to be offered to the applicant 10. The price so ~let~rrnin~l, is also carried through to the 20 other bank systems, which eventually house the new loan.

FRONT-END PENDIN& PROCESS
The front-end pending process of the present invention provides a solution to the problem of the application submission session, which has been initi:ltt~fl but which cannot 25 be completed for one reason or another. For example, the applicant may be mi~ing key information or the applicant may decide that he or she no longer wishes to continue the session (due to time constraints, etc.). Prior to the present invention, the effort that went into initi~ting the application was wasted (discarded). The process was re~uired to be started all over when the applicant 10 returned. The pending process of the present invention creates a means to save whatever information had been data-entered when it was discovered that the application would not be completed. The saved data can easily be ~çcec~e~l to allow the application to be completed when the applicant 10 is plepa,~_d and 5 ready to complete it.
In addition, easy-to-use files and processes permit saving and allow reuse of data from partially completed applications. Additional processes are built surrounding the pending process to help LBRs 12 remember and follow up on incomplete applications.
Incomplete applications within the pending process are aged to insure ~I p~ ;ate follow-10 up (sales or regulatory compliance).
The pending process of the present invention allows an LBR 12 to merelyhi~hli~ht and select a menu option ("Save to Pending File"), which saves all of the data entered during the session. At this point, the data is saved within the front-end environment (blocks 1 4 and 16) awaiting a future point when the application can be 15 completed. When the applicant 10 returns, any LBR 12 within the financial institution can easily recall the incomplete application via a menu option ("Pending /Conditional"), add any mi~ing infonn~ti~n and then transmit the application to the application processing system (ACAPS 26).

20 DEMAND DEPOSIT ACCOUNT (DDA) The fin~nf i~l in~fitnti~ n utilizes a syst~m~tiC review of an applicant's credit bureau history (blocks 28, 30, 32 and 34) to ~let~nnin~ whether or not to offer them a ch~l~lrin~ account ((1em~n~1 deposit account) type relationship. This evaluation is sy~lel"~Lic in nature and affords the fin~n~i~l in~titlltil~n an efficient method of screening 25 potential çh~?ç~in~ account c~n~ tes while holding fraud loss rates down.
All requests for çh.oçl~in~ accounts (~l~nn~n~l deposit accounts) are submitte~lthrough a systemic Social Security Nurnber search, a combined fin~n~ l institueion t~h~e information search, and a disaster screen, which enables im mçt1i~tecredil CA 02239713 1998-06-0~

W O 97/22073 PCT~US96/19228 worthiness evaluation. This feature provides an efficient methodology for LBRs 12 to identify those applicants 10 to which the LBRs should not offer checking accounts due to unmatched social security numbers or non-e~icting social security numbers, derogatory credit behavior, etc., unless the LBRs are ~lupliately entitled to override.
A message on the front-end system (blocks 14 and 16) indicates the results of the credit evaluation. For qualified applications, the LBR 12is allowed to open checking accounts imme~i~tely. For non-qualified applications, the ~BR 12 is presented with override screens with a~ l;ate entitlement or rejection options, based on systemic credit criteria.
ACAPS/BANKCARD PROCESSING
This feature of the present invention provides a systematic link to the bankcardacquisition process (block 40) for on-line proce~ing of branch sourced bankcard applications. As with the credit application processing rliec~se~l earlier, branch derived 15 bankcard applications are subject to response codes (A, B, C or D) reflecting the credit response, as well as Maximum Debt Burden Offer and verification lc~uhel~lents.
This process systPm~tic~ly interfaces with the b~nkr~rd acquisition system (block 40) to provide almost i~ ous response to a credit request (including standard disaster screen and automated credit score performed on ACAPS 26, as well as fraud 20 checks, duplicate name proces~ing, and çxi~tinp card member review ~lrolllled on the b~nkc~rd system 40). The result of systematic proces~ing enables much quicker turn around times and delivery of credit cards for applicant requests, and efficiency gains from the removal of previously paper-intensive bankcard application proce~in~;.
Sy~ lic proc~s~ing directs all branch sourced bankcard applications through 25 the required credit evaluating processes whether the process resides on the bankcard acquisition system (block 40) for ~?xi.cting card member, fraud, SSN search, and duplicate application, or on ACAPS 26, which houses the bankcard credit evaluation process (e.g., disaster screen, credit score, etc.). If a positive l~ onse is generated, the message back to W O 97/22073 PCT~US96/19228 the branch will include conditional approval, which would be fulfilled by the "acceptance" of specified amount of credit, which is then systematically conveyed to the bankcard servicing system (blocks 42, 62 and 40) for booking. Reject decisions send ~pro~.iate proces~ing information to the bankcard acquisition system 40 for i~su~nse of 5 decline letters. The system also enables the back-office (block 44) to intervene in appeal situations.

CREDIT QUALIFIED
This feature provides ~y~(e~ tic processing of "credit qualified" that enables an 10 LBR 12 to recognize (either by flag/light/offered amount) which applicants 10 surpass initial credit evaluation screens (e.g., disaster screen, credit score, etc.) encouraging them to optimize sales energy toward cross-selling additional credit products since initial systematic evaluation has indicated that the applicant 10 is credit qualified, although still subject to the required verifications. This systematic "credit qualified" process is 15 autom~tic~lly invoked even if the applicant is not applying for a credit product. Thus, an applicant who has come into the fin~nri~l institution to open a deposit account will be evaluated by the "credit qualified" process to enable the LBR to recognize a credit qll~lifie(l prospect.
Systemic credit evaluation via an ACAPS link to the front-end proces~ing system 20 rapidly identifies "credit qualified" applicants, enabling the LBR 12 to irnn~ t~ly identify those applicants 10 that exceed initial credit criteria. The LBR 12 may then m~xi.~ cross-sell ~pu~ ilies with those applicants.
Credit qll~lifir~fion criteria (e.g., disaster screens, credit scores, etc.) will systematically evaluate an applicant~s credit worthiness and then determine whether or 25 not a "credit qualified" marker will be displayed on front-end system. This marker may indicate an amount of "credit qualification" or simply in~ te to the LBR 12 that the applicant 10 has surpassed the initial credit criteria screens indicating whether or not a lengthy sales session ~ lg to credit products is required. The system may also make W O 97/22~73 PCTrUS96/19228 a specific product reCommen~l~tion based upon in~llnalion elements obtained from the applicant during the application session and upon tables that contain products chosen by management. The system has been designed to allow a "credit qualified" offer to be converted to a "credit request" if the applicant 10 desires more credit than that offered to 5 them in a "credit qu~lifie~" manner. Systemic switch to a "credit request" re-labels requests and invokes all necessaly credit evaluation criteria associated with a standard credit request (e.g., disaster screens, credit scores, debt burden, etc.) and app.u~liate identification of adverse action reasons if the applicant 10 does not meet the credit request criteria.
NEAREST COMPETITOR
C redit proceCcinP of the present invention is a unique point of differentiation. The financial institution's liability and credit review/approval process is more comprehensive and provides faster service than other on-line processes. The present invention provides l S an on-line proceesin~ to LBRs 12 and their applicants 10 to input their unsecured liability and credit recluests directly on the system without the need for a paper application.
Secured applications may receive conditional approval (conting~nt on required verifications and approvals) prior to receipt of pa~ h.
Combined with the one step relationship account opening, applicants 10 can im m~ tely open an entire bank relationship inclu-ling inst~llment loans, revolving line of credit, and check over-draft protection.
System Overview The system of the present invention in~hlrles a fin~nci~l network termins3l 14 coupled to a front-end proc~scin~ and co.. l.. ic?ltions system 16, which can access a 25 ~i~t~b~ce 17 co..~ g information regarding all exictin~ customers. The front-end procec~in~ and communications system 16 is conn~ct~r1 to a financial institution external social security number and check writing behavior ~l~t~b~ce (known as Chexsystems), and to the ACAPS Processing System 26, which in turn ~ccess~c several other systems.

W O 97/22073 PCT~US96tl9228 These include the on-line bank data access system 24, the credit bureau system 28, the data access system 36, the bankcard account fulfillmen1 system 40, and the applicants routing/inforrnation posting systems 42.
The credit bureau system includes a link to at least the three ma3Or credit d~t~b~es -- Equifax 30, Trans Union 32 and TRW 34.
The ACAPS Proct~in~ System 26 includes a ~iA~AhA~e 27 that stores existing customer information, such as applications in process, completed verifications requirements, and pending credit qualified offers.
Post on-line credit decision processing is p~-rolllled by the application l O routing/information posting system in conjunction with manual ~ack office reviews.
The bAnk~Ard account fulfillment system 40 is used for procf~in~ bankcard applications.
The data access system 36 is used for obtaining ~xi.ctin~ bankcard data when processing bankcard applications.
The on-line bank data access system 24 is used to obtain information regarding exi~ting customers. It includes four databases, the global customer infoImation files 17, the real time account transaction/current balance data storage 18, the customer inforrnation demographics ~lAtAba~e 20 and the additional bzlnking transactions ~lAt~h~e 22.
The system and method to pt;lrc ~ on-line credit reviews and approvals are symbolically flow charted bc~;.~..;..~ with FIG 40 at block 2000. The front-end proce~in~ system (l:;IG 1 blocks 14 and 16) is Arce~e~i to fill data entry screens with: (I) the applicant's 10 requested credit product information; (2) an in-process (pending) application; or (3) a credit qualified offer for an applicant lO, which may be activated 25 from the ACAPS cll~tom~r information file storage (FIG I block 27) for credit decision proce~ing (block 2002).
The entered data (block 2002) is l~ ,d to the enhanced ACAPS 26 (block 2004). This transfer initiAtes the on-line review and approval decision processing The ,~

W O 97/22073 PCT~US96/19228 system will perform a background m~tching process to identify an applicant's additional credit worthiness for ~c~ignment of credit qualified offers (block 2005).
Using the applicant's 10 infor nation, a look up ~as defined by the relationshipprofile pararneter on Product M~ ce 4 screen (FIG 7 element 20), is perforrned within the bank's on-line data systems (block 2006). The bank's on-line systems consist of real time account transaction and current balance storage (FIG 1 block 18), existing customer demographics ~t~b~e (block 20) and additional tr~n~ctions ~t~h~e (block22). The retrieval access to these ÇXi-Ctin~ bank data systems is provided by an on-line access system (block 24). Additional and more complete existing customer relationship 10 data is also retrieved from the global customer hlro~ lion file (block 17). The inforrnation gathered from these systems will include the length, in months, of the existing customer's relationship with the financial institution, the total number and dollar arnount of asset accounts and the total nurnber and dollar arnount of liability accounts. If a customer relationship exists (YES branch from block 2008), relationship criteria codes 15 are generated (block 2010) from the customer relationship data using the cont~terl~tion rules outlined in FIG 12. The relationship codes are then used as look up keys within the product ae~iPnPcl relationship pricing profile (shown in FIG 11) to determine the product profile table (shown in FIG 14) to be ~ccesse~ in providing price offers based on an individual cusLo~.le.'s çltj.cting financial in~tit~ltion relationship.
If no relationship exists (NO branch from block 2008), the ~ign.o~l default product profile (FIG 14) is ~cee~e-l to provide price offers (block 2014).
After entry of all data, front-end pre-screening is ~ rolllled (FIG 41 block '0 ~0~
for minimllm age, ~ l income, fraud and duplicate application as configured on the Product ~ t~ e - 1 (PM1) Table (shown in FIG 3). If the application fails the 25 pre-screening parameters (YES branch from block 2022), it is routed to the back otfice for additional review (block 2024) using the 7~ign~l route state of the highest priorit~
from the CCH priority table (shown in FIG 39). During back office review, screens showing product and insurance information (PII) (FIG 18) and income inforrnation ( l~ ) (FIG 20) may be a~cec~ecl by an underwriter or review personnel as informationaldisplays to assist in the back office credit decision process. The application retains a status of "EN" -- In Process, and the applicant 10 is notified that a review is being performed (block 2026). The procescing according to the present invention now branches to the finish session process (block 2028).
The system presents any credit qualified offers that were generated for the applicant 10 and the l,BR 12 may now discuss them with the applicant 10 (~IG 51 block 2252). If the applicant wants to accept any of the offers (Yes branch from block 2252), the credit qualified offer will be converted into a request for credit and will then require 10 on-line credit processing for final decision ~ nment (block 2256) . If the applicant decides not to proceed on an offer (NO branch from block 2254) or after the offer conversion to a request is finich~, the ACAPS (:~ustomer Information File (FIG 1 block 27) is updated to store all credit applications, the credit qualified offers, and entered applicant verification information (block 2258). The storage and access to this 15 in~.lllalion are illustrated on the Credit Qualification Panel~QUA) (FIG 25) and the Customer Information Panel (CIF) (FIG 30). Use of this inforrnation and access to the qualification offers will remain available up to the ~c~i~n.o~l expiration time limits as defined by the Product ~int~n~nce - 9 (PM9) screen (FIG 22). After the update iscomplete, processing now ends (block 2260).
Upon passing the pre-screening (NO branch from 2022), the configured fraud verification is pe~ru~ ed (block 2030). If the application fails this verification ui~lllent (YES branch from block 2030), the application routing and applicant notification are ~lrol,ned as described above (blocks 2024 and 2026) and procec~ing now branches to the finish session process as ill--ctrate~ in FIG ~ 1, described above 25 (block 2028).
~f the fraud verification requirement passes (NO branch from block 2030), creditbureau reports are gathered (block 2032) as illuskated in FIG 1 blocks 28, 30, 32 and 34.

CA 02239713 1998-06-0~

W O 97/22073 PCT~US96/19228 If configured ~ ct~r/policy screening fails (YES branch 55 from block 2034), theapplieation status is ehanged to "RT" -- Recommend Turndown (block 2036) and is then routed to back office review (block 2048) as previously described; then processing branches to the finish session proeess as illustrated in FIG 51, described above (block 20283. Upon passing the ~liC~ct~r/policy screening (NO branch from block 2034), a disaster response code is determin~d and ~cci~n~tl to the application (block 2038).
If configured debt burden verification requirement fails (YES branch from block 2040), the application status is changed to "DB" -- Debt Burden Review (block 2042) and is then routed to baek office review (block 2048) as previously described; then review processing branehes to the finish session process as illustrated in FIG 51, described above (block 2028). Upon passing the debt burden verification requirement (NO branch from block 2040), a debt burden response eode is deter~nined and ~ccign~-i to the applieation (block 2044).
Using pararneters and rules eonfigured on Product ~l~int~n~nce - 8 (PM8) (sho~vn.15 in FIG 9), a scoring response code is ~ccign~cl to the application (FIG 42 block 2052). If this score is less than or equal to the turndown cutoff value (YES branch from block 2054), the applieation status is changed to 'LRT" -- Reeornrnend Turndown (block 2062) and is then routed to baek office review (block 2072) as previously described, then the applieant ~0 is notified that a review is in process (bloek 2074) and proeescin~ branches to the finish session process as illustrated in FIG 51, described above (block 2076).
If the application score is greater than turndown cutoff and less than investigate value (YES braneh from block 2056), an Invtosti~te 2 Routing is ~cciEn~l to the application (block 2064), the application status is changed to "Rr' -- Recornmend Turndown (bloek 2062) and is then routed to baek offiee review (bloek 2072) as previously deseribed; then the applieant 10 is notified that a review is in proeess (block 2074) and procescinE branehes to the finish session proeess as illl-ctr~ted in FIG 51, described above (bloek 2076).
-If the application score is greater than or equal to the investigate value and less than the approve cutoff value (YES branch from block 2058), an Investigate 1 Routing is assigned to the application (block 2064). If the product is a secured product (YES branch from block 2068), the application status is changed to "CA" -- Conditional Approval (block 2070); otherwise (NO branch from block 2068) the application status is changed to "RT" -- Recommen(l Turndown (block 2062).The application is now routed to back office review (block 2072~ as previously described; then the applicant 10 is notified that a review is in process (block 2074) and proces.cin~ branches to the finish session process as illustrated in FIG 51, described above (block 2076).
If the above three tests fail (NO branch from blocks 2054,2056 and 2058), the application score is ~leterrnint~l to be greater than or e~ual to the approve cutoff value (block 2060). If the product is a secured product (YES branch from block 207~), the application status is changed to "CA" -- Conditional Approval (block 2080); otherwise (NO branch from block 2078) the application status is changed to "RA" -- Recomrnend 15 Approval (block 2082).
If the product is a bankcard (YES branch from block 2084), the batch data repository (FIG 1 block 56)is ~ccesse~1 to retrieve addition bankcard inforrnation for the applicant 10 (FIG 43 block 2092). All data entered and electronically gathered applicant and requested product inforrnation is transferred to the b~nk~rd account fillfillment 20 system (shown in block 40 FIG 1) for bankcard procescin~ system ~ l (block 2094).
If the application does not receive a "PASS" indication from the bankcard account fillfillment system 40 (NO branch from block 2096), the application status is changed to "BA" -- Bankcard Referral ~block 2100),is ~.ci~necl an approval routing state (block 2102) and is then routed to back office review (block 2104) as previously described; then 25 the applicant 10 is notified that a review is in process (block 2106) and proce~.cing branches to the finish session process as illustrated in ~IG 51, described above (block 2108).

For applications still active in the review and approval process, the requested product is assigned a credit limit amount based upon either the application credit score and applicant income or the applicant's bank relationship arnount and income, if any, (FIG 44 block 2112).
S If the recommen~ cl line ~ignm~nt amount is in the range indicated on Product Maintenance - 3 (PM3, FIG S) for debt burden review (YES branch from block 2114), a M~rimum Debt Burden Offer (MDBO) is calculated ~block 2116) as documçntecl in FIG
34 with exarnples of usage in FIGs 35, 36, 37 and 38. If the Use Assign Limit pararneter of PM 1 (FIG 3) is set to "Y" (YES branch from block 2118), the final line assignment is 10 the lesser of the recommended credit limit and the MDBO arnount (block 2120). If the Use Assign ~imit parameter of PM1 (FIG 3) is set to "N" (YES branch from block 2122), the final line ~ nm~nt is the lesser of the requested loan arnount and the MDBO
amount (block 2124). If the Use Assign Limit pararneter of PM1 (FIG 3) is set to "X"
(YES branch from block 2126), the final line ~csjgnment is the lesser of the product's 15 m~ximllm allowed amount and the MDBO arnount (block 2128).
If the applicant 10 is a stll-lent a non-resident alien or self-employed and meets the exception parameters on PM3 (FIG 5) (YES branch from FIG 45 block 2136), theapplication status is not updated (block 2140), is ~ neC~ an exception review routing state (block 2142) and is then routed to back office review (block 2144) as previously 20 described; then the applicant 10 is notified that a review is in process (block 2146) and proc.o~in~ lclles to the finish session process as illustrated in FIG 51, described above (block 2148).
If the applicant 10 does not match the above parameters (NO branch from block 2136), application procçs.cing will continue. Existing customer verification data (stored in 25 the ACAPS Customer Infor nation File as shown in the Customer Information Panel, FIG
30) are retrieved and v~ t~1 for use by comparison of expiration time limits set in the Product M~ e - 9 screen (PM9, FIG 22). The final line ~q.si~nm~nt/credit offer and , the product assigned verification profile (shown in FIG 16) are used to determine the required verifications (FIG 46 block 2152).
Next, a bank liability balance response code is ~ ne~l (block 2154). Next, the worst of the credit response codes is selected (block 2156). The final response code is 5~esi~nPd to the application (block 2158) by selecting the better of the liability balance code and the credit response code.
Based upon the application score, the ~tc-m~t~d review o~applicant 10 data and the ~.cj~n~cl response code, an automated credit offer decision is presented (block 2160).
This credit offer decision is a table driven response from the Decision and Ranking Codes chart as illustrated in FIG 2. If the product is secured, a decision of "RT" -- Recornmend Turndown or "CAl' Conditional Approval (pending required verifications and pa~ vulk) may be ~e~i~n~-l If the product is unsecured, the following decisions may be ~ n~cl "RT" -- Recommend Turndown, "RA" -- Recornmend Approval, "CA" -- Conditional Approval, or "CO" -- Counter Offer.
If the product is secured (YES branch from FIG 47 block 2166), the assigned status is tested (block 2168). If the application status is set to "CA" (YES branch from - block 2168), the applicant 10 is notified of the conditional approval and that final proces.cin~ of the application is in progress (block 2170). If the status is ~Rr~ (NO branch from block 2168), the applicant 10 is notified that further review of the application is required and is in progress (block 2172). The application is now routed to the back office for final proce~ein~ and review ~block 2174). Proces~in~ now branches to the finish session process as illustrated in FIG 51, described above (block 2176).
If the product is unsecured (NO branch from block 2166), the application status is tested (FIG 48 blocks 2182, 2190, 2198 and 2202). If the status is ~Rr~ (YES branch from block 2182), the application is routed to back office review (block 2184) ~s previously described. The applicant 10 is notified that a review is in process (blocl; ~ 186).
Proces~in~ now branches to the finish session process as illu~trztte~3 in FIG 51. descri~d above (block 2188).

CA 02239713 1998-06-0~
W O 97/22073 PCT~US96/19228 If the status is "RA" (YES branch from block 2190), the applicant 10 is presented w;th the loan offer and asked to accept or reject the offer (block 2192). If the applicant 10 accepts the loan (YES branch from block 2192), the application status is updated to "AP"
-- Approved Pending Booking (block 2194); otherwise (NO branch from block 2192), the S status is updated to "AW" -- Application Withdrawn (block 2196). Proces~ g now branches to the finish session process as illustrated in FIG 51, described above (block 2188).
If the status is "CO" (YES branch from block 2198), the applicant 10 is notifiedof the counter offer down-sell smaller credit amount (FIG 49 block 2208). If applicant 10 10 accepts the down-sell loan arnount (YES branch from block 2210), required verifications are tested for completeness (block 2212). If verifications requirements are complete (YES
branch from block 2212), the application status is llp~ tecl to "AP" -- Approval Pending Booking (block 2214). If required verifications are incomplete (NO branch from block 2212), the application status is updated to "CO" -- Counter Offer (pending required 15 verifications) (block 2216). If the applicant 10 rejects the offer (NO branch from block 22103, the applicant may ask for a referral review (block 2218). If they do not want a review (NO branch from block 2218), the application status is updated to "NO" --Rejected Downsell Offer (block 2220). If they do want a review (Yes branch from block 2218), the application status remains "CO" -- Counter Offer (pending review) (block 20 2222), then the application is routed to the back office for applicant 10 requested review (block 2224). ProcPeein~ now l~ s to the finish session process as illllstr~t~d in FIG
51, described above (block 2226).
The application status is ~let~rrnin~l (block 2202) to be "CA" (NO branch from blocks 2182, 2190 and 2198). The applicant 10 is notified of the con-iitinnal approval 25 (FIG 50 block 2230). If an up-sell larger credit offer exists (Y~S branch from block 2232), the applicant 10 is presented with the larger amount offer (block 2234). The applicant 10 is now asked if they accept the loan offer for an arnount in the range from the original request to the approved offer (block 2236). If the applicant 10 accepts the W O 97/22073 PCT~US96/19228 offer (YES branch from block 2236), required verifications are tested for completeness (block 2240). If required verifications are complete (YES branch from block 2240), the application status is updated to "AP" -- Approval Pending ~ooking (block 2242). If required verifications are incomplete (NO branch from block 2240), the application status S remains "CA" -- Conditional Approval (pending required verifi~tions~ (block 2244). If the applicant 10 rejects the offer (NO branch from block 2236), the application status is updated to "AW" -- Application Withdrawn ~block 2238). Processing now branches to the finish session process as illustrated in FIG 51, described above (block 2248).
Although the invention has been described in detail with particular reference to a 10 preferred embodiment thereof, it should be readily understood that the invention may be capable of other and different tasks. As is readily ~ .ll to persons having ordinary skill in the art, variation and modifications can be made while rçm~ining within the spirit and scope of the invention. Therefore, the folegoing disclosure and drawing figures are for illustrative purposes only, and do not in any way limit the invention, which is defined 15 by the appended claims.

Claims (25)

WHAT IS CLAIMED IS:

1. A method for performing an automatic on-line review of an applicant's application for a product or service offered by a financial institution, in real-time, comprising the steps of:
a) inputting a first set of data into a data processing and communication system, said data relating to information provided by said applicant;
b) inputting a second set of data into said data processing and communication system, said second set of data relating to the product or service requested by said applicant; and c) using said first data to identify on a real time basis a relationship profile with said applicant, said relationship profile being based upon an amount of assets and liabilities said applicant has with the financial institution.

2. The method according to claim 1, further comprising the steps of:
d) generating a category representing said relationship profile; and e) using said category to extract a pricing scheme based on category from a product profile table, said table containing information regarding prices for products or services offered by the financial institution.

3. The method according to claim 2, further comprising the step of:
f) comparing said first data and said relationship profile against a pre-screening criteria to determine whether or not said prescreening criteria has been met, said prescreening criteria including said customer's income; and g) routing an applicant's application that fails to meet said prescreening criteria to a manual review.

4. The method according to claim 1, further comprising the steps of:
d) performing a fraud verification on said first set of data;
e) gathering credit reports from at least one credit bureau using said first set of data, and comparing said credit reports against a minimum diaster/policy criteria.

5. The method according to claim 1, further comprising the steps of:
d) accessing a social security database to perform a social security number screen using information from the first set;
e) accessing a credit bureau using said first set of data; and f) applying a minimum diaster/policy screen against the first and second set of data.

6. The method according to claim 4, further comprising the step of:
f) routing an applicant's application that fails to meet said disaster/policy criteria to a manual review.

7. The method according to claim 4, further comprising the steps of:
e) assigning a disaster response code to said first set of data;
f) preparing a debt burden value based upon said credit report and said first set of data; and g) comparing said debt burden value against a debt burden table parameter.

8. The method according to claim 4, further comprising the steps of:
e) determining a debt burden code and assigning said code to said applicant's application and assigning a scoring response code to said applicant's application; and f) comparing said scoring response code to a turndown cutoff value.

9. The method according to claim 4, further comprising the steps of:

e) comparing said applicant's application score against an approved cutoff value;
and f) referring an applicant's application that fails to meet said approval cutoff value to a manual review.

10. The method according to claim 1, further comprising the steps of:
d) assigning a credit limit amount to said applicant, e) determining if requested loan amount is within the limits of the product maintenance file; and then f) approving disbursement of funds to said applicant

11. A computer system for processing an application by an applicant for a product or service offered by a financial institution, comprising programming to perform the following processes:
a) evaluating the application according to predetermined operating policies, ranking the application according to a predetermined scoring and immediately conveying an evaluation status to a local branch representative;
b) providing to the local branch representative a maximum allowable amount of credit for the application in response to a request for a particular product, wherein an estimated payment for the particular product, in addition to all known debt of the applicant, including applicant provided debt and credit bureau provided debt, would not exceed stored product specified parameters up to a designated controlling debt burden;
c) providing the local branch representative with a systematic identification ofverification categories required based on an amount offered and accepted, and enabling the local branch representative to select a methodology of completing the required verifications, and preventing booking of the application unless all required verifications are completed;

d) automatically reviewing all of the applicant's accounts when reviewing the credit to determine an aggregate balance amount that gives rise to a best price for offering to the applicant for the requested product, wherein said computer includes a series of tables that contain a plurality of price points for each product to perform saiddetermination; and e) maintaining an incomplete application on the system in a format that permits completion of the application at a later date by any local branch representative, and providing a prompt to the local branch representative to encourage follow up of an incomplete application based on an automatic aging of an incomplete application.

12. The system according to claim 11, wherein the programming further comprises the additional process of:
f) performing a review of an applicant's credit history to determine whether or not to offer the applicant a demand deposit account type relationship.

13. The system according to claim 11, wherein the programming further comprises the additional process of:
f) providing a link to a bankcard acquisition process for on-line processing of bankcard applications.

14. The system according to claim 11, wherein the programming further comprises the additional process of:
f) identifying credit qualified applicants to the local branch representative, wherein credit qualified applicants are those applicants that surpass initial credit evaluation screens.

15. The system according to claim 11, wherein said verification categories include at least one selected from the group consisting of: identification, telephone number, employment, and income.

16. The system according to claim 11, wherein said verification categories includes information about an applicant relating to the applicant's capacity, character, collateral and credit.

17. An apparatus for processing applications for products or services offered by a financial institution, comprising:
a) a processing system including a plurality of first data links, accessing a plurality of on-line credit bureaus external to the financial institution via one of the plurality of first data links, accessing a bankcard processing system external to the financial institution via one of the first plurality of data links, accessing a bankcard data access system external to the financial institution storing information regarding existing bankcards via one of said plurality of first data links, and storing credit applications in process, completed and verified credit applications, and pending credit qualified offers, and;
b) a front-end processing and communications system including a terminal for inputting data regarding an applicant, being linked with said credit processing system via one of said plurality of first data links, and having a first dedicated data link;
c) an on-line data access system being linked with said processing system via one of said plurality of first data links, being linked with said front-end processing and communications system via said first dedicated data link, and including a plurality of databases storing information regarding all applicants of the financial institution, account information, applicant demographic information and banking transactions; and d) a decision application processing system being linked with said processing system via one of said plurality of first data links, including a second dedicated data link for accessing the bankcard processing system, and routing credit applications to manual review upon rejection of the application by the apparatus.

18. The apparatus according to claim 17, wherein said processing system evaluates the application according to predetermined credit policies, ranks the application according to a predetermined scoring and immediately conveys a credit evaluation status to the front-end processing and communications system for display on the terminal to a local branch representative.

19. The apparatus according to claim 17, wherein said processing system provides the front-end processing system for display on the terminal to a local branch representative with a maximum allowable amount of credit for the application in response to a request for a particular product, and wherein an estimated payment for the particular product, in addition to all known debt of the applicant does not exceed stored product specified parameters up to a designated controlling debt burden.

20. The apparatus according to claim 17, wherein said processing system providesthe front-end processing system for display on the terminal to a local branch representative with a systematic identification of verification categories required based on an amount offered and accepted, and enabling the local branch representative to select a methodology of completing the required verifications, and preventing booking of the application unless all required verification are completed.

21. The apparatus according to claim 20, wherein said required verifications include at least one selected from the group consisting of: identification, telephone number, employment, and income.

22. The apparatus according to claim 20, wherein said required verifications include information about a credit applicant relating to the credit applicant's capacity, character, collateral and credit.

23. The apparatus according to claim 19, wherein said processing system automatically reviews all of the applicant's accounts, including both existing and newly established accounts, when reviewing the application to determine an aggregate balance amount which gives rise to a best price for offering to the applicant for the requested product, and during said review accesses a series of tables that contain a plurality of price points for each product to perform said determination, and provide said front-end processing and communications system with said best price for display on said terminal to a local branch representative.

24. The apparatus according to claim 19, wherein said processing system maintains an incomplete application in a format that permits completion of the application at a later date, and provides said incomplete application to said front-end processing and communications system in response to a request from the front-endprocessing and communications system.

25. The apparatus according to claim 24, wherein said processing system provides a prompt to the front-end processing and communications system for display on the terminal to a local branch representative to encourage follow up of an incomplete application based on an automatic aging of an incomplete application.