System and method to performing on-line credit reviews and approvals6088686Abstract A user-friendly on-line computerized system operates in real-time thus streamlining the processing of applications for products and services offered by a financial institution. The system automates many steps in the credit and liability review and approval process, performs background credit worthiness evaluations based upon a applicant's credit score, financial information and new or existing relationship with the financial institution, recommends to those applicants who exceed the initial criteria for credit consideration specific credit products with predetermined credit qualified offer amounts, and ensures the required operating (credit/liability) policies are appropriately completed. The system immediately analyzes an applicant's credit bureau history and automated credit scoring, and provides these results to the LBR. The system also takes into account information relating to the applicant's new or existing relationship with the financial institution, if any, into the credit decision request. This enables the system to provide applicants with an 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. Claims What is claimed is: Description FIELD OF THE INVENTION
______________________________________
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 initiates an interface to the
booking system (for specified products).
B Recommended Turndown
The system has identified that: (1) 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
balances. In all three cases, the LBR may contact the back
office with an immediate appeal.
C Recommended 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 and liability balances) by product type within a region. These parameters are systematically evaluated at the time the application is transmitted 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 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 rankings. 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 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). Evaluation and transmission on average take only a matter of seconds and are available 7 days a week, which enables the LBRs 12 almost instantaneous--on the spot--response to the applicant's request for credit. For unsecured products (e.g., installment 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 appropriately controlled to ensure an acceptable credit risk exposure based on changes 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 Maximum Debt Burden Offer provides applicants requesting credit (revolving or closed-end) with the maximum allowable line of credit or loan amount, whose estimated 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 assignment tables) up to the designated controlling debt burden table parameter such as 45%. The resulting upsell or counter-offer, as it relates to the applicant's credit request, is incorporated within response processing of the present invention and is therefore available for the LBR (block 12 ) to discuss with the applicant 10 within the session. 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 requests the
maximum amount for which the applicant is eligible.)
3) Product Maximum
MAXIMUM Maximum loan or line dollar amount whose associated
DEBT monthly payment, when added to the monthly payment
BURDEN amounts for the applicant's existing debts and rent or
OFFER 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 designated
parameter (e.g., $2,500) the amount assigned to
Maximum Debt Burden Offer will default to product
minimum.
LINE Systemic Line Assignment Tables
ASSIGNMENT
______________________________________
An applicant's good credit experience, monthly income and monthly debt payments (incorporating estimated monthly payment associated with the newly requested debt) are systematically evaluated upon transmission of credit request providing the LBR 12 and applicant 10 with knowledge of the maximum exposure that the product programs will allow prior to judgmental review. This process primarily uses monthly credit bureau information, including mortgage payments, which allows a Maximum Debt Burden Offer without applicant 10 provided information. Overall, the process of the present invention provides improvement in credit evaluation/processing time as well as a substantial reduction in unit cost processing (i.e., 65% decrease) while providing an elegance in sales 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 identification of verification categories required (product program) based on the amount offered and accepted which is displayed on the front-end platform (blocks 14 and 16). The platform provides the required verifications in a picklist format and enables the LBR 12 to select a methodology of completing required verifications, which is then transmitted to ACAPS 26. The system allows an LBR, when directed by the applicant, to accept an offered line or loan amount at any time after the offer is made--thus completing the application cycle of application, financial institution decision, offer to applicant, acceptance of offer, and in some cases, the issuance of funds, pending required verifications. However, in the presence of unsatisfied verification requirements, the system will not allow the 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 performed, thus ensuring compliance with the verification requirements and potentially avoiding fraud issues. Systematic completion of required verifications enables on-site acceptance of credit requests and subsequent issuance of funds for designated products, e.g., installment loans. The ACAPS 26 system has imbedded into each product classification a required verifications profile (FIGS. 16 through 17E), which indicates which types of verifications are required based on the amount requested and, eventually, the amount accepted by the applicant 10. The systematic presentation of required verifications eliminates the need for the LBR 12 to continually calculate and re-calculate which specific verifications are required before an application may be completed. In addition to the ACAPS 26 automated presentation of the types of required verifications necessary, 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 12 rapid completion of required verification procedures. The ACAPS 26 maintains verification requirements (which are table driven) by region and product, which identify by designated offered and accepted amount of credit exactly which type of verifications (e.g., identification, phone, employment, income, etc.) are required before the system will enable the application for credit to be accepted. Differentiation by product type enables ACAPS 26 to establish appropriate 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 processing, 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 52) involved in the process, all of the existing customer's accounts are systematically and automatically reviewed during the application session to determine the aggregate balance amount, which gives rise to the best price being offered to the existing customer 10 for the requested credit product. Price includes the handling of both fixed interest rate and variable rate (e.g., indexed 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 relationship (i.e., deposit balances) with the financial institution. It also provides the financial institution employees with the appropriate rate for the loan type considering the applicant's relationship with the financial institution. According to the present invention, the system automatically examines an applicant's existing accounts as well as newly deposited funds. The automation of the selection of the appropriate 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 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 determined from several credit worthiness factors including the total amount of money on deposit in the financial institution (where the deposit amount is the sum of the individual balance amounts in potentially multiple accounts). A series of tables in the application processing 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 within ACAPS 26 determine whether the automated pricing routines should be used or not used. Assuming 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 determine the price to be offered to the applicant 10. The price so determined, is also carried through to the other bank systems, which eventually house the new loan. Front-end Pending Process The front-end pending process of the present invention provides a solution to the problem of the application submission session, which has been initiated but which cannot be completed for one reason or another. For example, the applicant may be missing 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 initiating the application was wasted (discarded). The process was required 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 accessed to allow the application to be completed when the applicant 10 is prepared and 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 appropriate follow-up (sales or regulatory compliance). The pending process of the present invention allows an LBR 12 to merely highlight 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 14 and 16) awaiting a future point when the application can be 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 missing information and then transmit the application to the application processing system (ACAPS 26). Demand Deposit Account (DDA) The financial institution utilizes a systematic review of an applicant's credit bureau history (blocks 28, 30, 32 and 34) to determine whether or not to offer them a checking account (demand deposit account) type relationship. This evaluation is systematic in nature and affords the financial institution an efficient method of screening potential checking account candidates while holding fraud loss rates down. All requests for checking accounts (demand deposit accounts) are submitted through a systemic Social Security Number search, a combined financial institution database information search, and a disaster screen, which enables immediate credit 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-existing social security numbers, derogatory credit behavior, etc., unless the LBRs are appropriately 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 12 is allowed to open checking accounts immediately. For non-qualified applications, the LBR 12 is presented with override screens with appropriate entitlement or rejection options, based on systemic credit criteria. ACAPS/Bankcard Processing This feature of the present invention provides a systematic link to the bankcard acquisition process (block 40) for on-line processing of branch sourced bankcard applications. As with the credit application processing discussed earlier, branch derived 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 requirements. This process systematically interfaces with the bankcard acquisition system (block 40) to provide almost instantaneous response to a credit request (including standard disaster screen and automated credit score performed on ACAPS 26, as well as fraud checks, duplicate name processing, and existing card member review performed on the bankcard system 40). The result of systematic processing 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 processing. Systematic processing directs all branch sourced bankcard applications through the required credit evaluating processes whether the process resides on the bankcard acquisition system (block 40) for existing 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 response is generated, the message back to 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 appropriate processing information to the bankcard acquisition system 40 for issuance of decline letters. The system also enables the back-office (block 44) to intervene in appeal situations. Credit Qualified This feature provides systematic processing of "credit qualified" that enables an 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 automatically invoked even if the applicant is not applying for a credit product. Thus, an applicant who has come into the financial institution to open a deposit account will be evaluated by the "credit qualified" process to enable the LBR to recognize a credit qualified prospect. Systemic credit evaluation via an ACAPS link to the front-end processing system rapidly identifies "credit qualified" applicants, enabling the LBR 12 to immediately identify those applicants 10 that exceed initial credit criteria. The LBR 12 may then maximize cross-sell opportunities with those applicants. Credit qualification criteria (e.g., disaster screens, credit scores, etc.) will systematically evaluate an applicant's credit worthiness and then determine whether or not a "credit qualified" marker will be displayed on front-end system. This marker may indicate an amount of "credit qualification" or simply indicate to the LBR 12 that the applicant 10 has surpassed the initial credit criteria screens indicating whether or not a lengthy sales session pertaining to credit products is required. The system may also make a specific product recommendation based upon information 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 them in a "credit qualified" manner. Systemic switch to a "credit request" re-labels requests and invokes all necessary credit evaluation criteria associated with a standard credit request (e.g., disaster screens, credit scores, debt burden, etc.) and appropriate identification of adverse action reasons if the applicant 10 does not meet the credit request criteria. Nearest Competitor Credit processing 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 an on-line processing to LBRs 12 and their applicants 10 to input their unsecured liability and credit requests directly on the system without the need for a paper application. Secured applications may receive conditional approval (contingent on required verifications and approvals) prior to receipt of paperwork. Combined with the one step relationship account opening, applicants 10 can immediately open an entire bank relationship including installment loans, revolving line of credit, and check over-draft protection. System Overview The system of the present invention includes a financial network terminal 14 coupled to a front-end processing and communications system 16, which can access a database 17 containing information regarding all existing customers. The front-end processing and communications system 16 is connected to a financial institution external social security number and check writing behavior database (known as Chexsystems), and to the ACAPS Processing System 26, which in turn accesses several other systems. These include the on-line bank data access system 24, the credit bureau system 28, the data access system 36, the bankcard account fulfillment system 40, and the applicants routing/information posting systems 42. The credit bureau system includes a link to at least the three major credit databases--Equifax 30, Trans Union 32 and TRW 34. The ACAPS Processing System 26 includes a database 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 performed by the application routing/information posting system in conjunction with manual back office reviews. The bankcard account fulfillment system 40 is used for processing bankcard applications. The data access system 36 is used for obtaining existing bankcard data when processing bankcard applications. The on-line bank data access system 24 is used to obtain information regarding existing customers. It includes four databases, the global customer information files 17, the real time account transaction/current balance data storage 18, the customer information demographics database 20 and the additional banking transactions database 22. The system and method to perform on-line credit reviews and approvals are symbolically flow charted beginning with FIG. 40 at block 2000. The front-end processing system (FIG. 1 blocks 14 and 16) is accessed to fill data entry screens with: (1) the applicant's 10 requested credit product information; (2) an in-process (pending) application; or (3) a credit qualified offer for an applicant 10, which may be activated from the ACAPS customer information file storage (FIG. 1 block 27) for credit decision processing (block 2002). The entered data (block 2002) is transferred to the enhanced ACAPS 26 (block 2004). This transfer initiates the on-line review and approval decision processing. The system will perform a background matching process to identify an applicant's additional credit worthiness for assignment of credit qualified offers (block 2005). Using the applicant's 10 information, a look up (as defined by the relationship profile parameter on Product Maintenance 4 screen (FIG. 7 element 20 ), is performed 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 database (block 20) and additional transactions database (block 22). The retrieval access to these existing bank data systems is provided by an on-line access system (block 24). Additional and more complete existing customer relationship data is also retrieved from the global customer information file (block 17). The information 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 amount of asset accounts and the total number and dollar amount of liability accounts. If a customer relationship exists (YES branch from block 2008 ), relationship criteria codes are generated (block 2010) from the customer relationship data using the concatenation rules outlined in FIG. 12. The relationship codes are then used as look up keys within the product assigned relationship pricing profile (shown in FIG. 11) to determine the product profile table (shown in FIG. 14) to be accessed in providing price offers based on an individual customer's existing financial institution relationship. If no relationship exists (NO branch from block 2008), the assigned default product profile (FIG. 14) is accessed to provide price offers (block 2014). After entry of all data, front-end pre-screening is performed (FIG. 41 block 2020) for minimum age, minimum income, fraud and duplicate application as configured on the Product Maintenance-1 (PM1) Table (shown in FIG. 3). If the application fails the pre-screening parameters (YES branch from block 2022), it is routed to the back office for additional review (block 2024) using the assigned route state of the highest priority from the CCH priority table (shown in FIG. 39). During back office review, screens showing product and insurance information (PII) (FIG. 18) and income information (INC) (FIG. 20) may be accessed by an underwriter or review personnel as informational displays 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 processing 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 LBR 12 may now discuss them with the applicant 10 (FIG. 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 on-line credit processing for final decision assignment (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 finished, the ACAPS Customer 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 information are illustrated on the Credit Qualification Panel (QUA) (FIG. 25) and the Customer Information Panel (CIF) (FIG. 30). Use of this information and access to the qualification offers will remain available up to the assigned expiration time limits as defined by the Product Maintenance-9 (PM9) screen (FIG. 22). After the update is complete, processing now ends (block 2260). Upon passing the pre-screening (NO branch from 2022), the configured fraud verification is performed (block 2030). If the application fails this verification requirement (YES branch from block 2030), the application routing and applicant notification are performed as described above (blocks 2024 and 2026) and processing now branches to the finish session process as illustrated in FIG. 51, described above (block 2028). If the fraud verification requirement passes (NO branch from block 2030), credit bureau reports are gathered (block 2032) as illustrated in FIG. 1 blocks 28, 30, 32 and 34. If configured disaster/policy screening fails (YES branch 55 from block 2034), the application status is changed 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 process as illustrated in FIG. 51, described above (block 2028). Upon passing the disaster/policy screening (NO branch from block 2034), a disaster response code is determined and assigned 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 back office review (block 2048) as previously described; then review processing branches 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 code is determined and assigned to the application (block 2044). Using parameters and rules configured on Product Maintenance-8 (PM8) (shown in FIG. 9), a scoring response code is assigned 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 application status is changed to "RT"--Recommend Turndown (block 2062) and is then 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 processing 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 branch from block 2056), an Investigate 2 Routing is assigned to the application (block 2064), the application status is changed to "RT"--Recommend Turndown (block 2062) and is then 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 processing branches to the finish session process as illustrated in FIG. 51, described above (block 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"--Recommend 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 processing 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 determined to be greater than or equal to the approve cutoff value (block 2060). If the product is a secured product (YES branch from block 2078), the application status is changed to "CA"--Conditional Approval (block 2080 ); otherwise (NO branch from block 2078) the application status is changed to "RA"--Recommend Approval (block 2082). If the product is a bankcard (YES branch from block 2084), the batch data repository (FIG. 1 block 56) is accessed to retrieve addition bankcard information for the applicant 10 (FIG. 43 block 2092). All data entered and electronically gathered applicant and requested product information is transferred to the bankcard account fulfillment system (shown in block 40 FIG. 1) for bankcard processing system approval (block 2094). If the application does not receive a "PASS" indication from the bankcard account fulfillment system 40 (NO branch from block 2096), the application status is changed to "BA"--Bankcard Referral (block 2100), is assigned an approval routing state (block 2102) and is then routed to back office review (block 2104) as previously described; then the applicant 10 is notified that a review is in process (block 2106) and processing branches to the finish session process as illustrated in FIG. 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 amount and income, if any, (FIG. 44 block 2112). If the recommended line assignment amount is in the range indicated on Product Maintenance-3 (PM3, FIG. 5) for debt burden review (YES branch from block 2114), a Maximum Debt Burden Offer (MDBO) is calculated (block 2116) as documented in FIG. 34 with examples of usage in FIGS. 35, 36, 37 and 38. If the Use Assign Limit parameter of PM1 (FIG. 3) is set to "Y" (YES branch from block 2118), the final line assignment is the lesser of the recommended credit limit and the MDBO amount (block 2120). If the Use Assign Limit parameter of PM1 (FIG. 3) is set to "N" (YES branch from block 2122), the final line assignment is the lesser of the requested loan amount and the MDBO amount (block 2124). If the Use Assign Limit parameter of PM1 (FIG. 3) is set to "X" (YES branch from block 2126), the final line assignment is the lesser of the product's maximum allowed amount and the MDBO amount (block 2128). If the applicant 10 is a student, a non-resident alien or self-employed and meets the exception parameters on PM 3 (FIG. 5) (YES branch from FIG. 45 block 2136), the application status is not updated (block 2140), is assigned an exception review routing state (block 2142) and is then routed to back office review (block 2144) as previously described; then the applicant 10 is notified that a review is in process (block 2146) and processing branches 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 processing will continue. Existing customer verification data (stored in the ACAPS Customer Information File as shown in the Customer Information Panel, FIG. 30) are retrieved and validated for use by comparison of expiration time limits set in the Product Maintenance-9 screen (PM9, FIG. 22). The final line assignment/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 assigned (block 2154). Next, the worst of the credit response codes is selected (block 2156). The final response code is assigned 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 automated review of applicant 10 data and the assigned 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"--Recommend Turndown or "CA" Conditional Approval (pending required verifications and paperwork) may be assigned. If the product is unsecured, the following decisions may be assigned: "RT"--Recommend Turndown, "RA"--Recommend 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 processing of the application is in progress (block 2170). If the status is "RT" (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 processing and review (block 2174). Processing 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 "RT" (YES branch from block 2182), the application is routed to back office review (block 2184) as previously described. The applicant 10 is notified that a review is in process (block 2186). Processing now branches to the finish session process as illustrated in FIG. 51, described above (block 2188). If the status is "RA" (YES branch from block 2190), the applicant 10 is presented with 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 status is updated to "AW"--Application Withdrawn (block 2196). Processing 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 notified of the counter offer down-sell smaller credit amount (FIG. 49 block 2208). If applicant 10 accepts the down-sell loan amount (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 updated 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 verifications) (block 2216). If the applicant 10 rejects the offer (NO branch from block 2210), 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 2222 ); then the application is routed to the back office for applicant 10 requested review (block 2224). Processing now branches to the finish session process as illustrated in FIG. 51, described above (block 2226). The application status is determined (block 2202) to be "CA" (NO branch from blocks 2182, 2190 and 2198). The applicant 10 is notified of the conditional approval (FIG. 50 block 2230). If an up-sell larger credit offer exists (YES 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 amount in the range from the original request to the approved offer (block 2236). If the applicant 10 accepts the 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 Booking (block 2242). If required verifications are incomplete (NO branch from block 2240), the application status remains "CA"--Conditional Approval (pending required verifications) (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 preferred embodiment thereof, it should be readily understood that the invention may be capable of other and different tasks. As is readily apparent to persons having ordinary skill in the art, variation and modifications can be made while remaining within the spirit and scope of the invention. Therefore, the foregoing disclosure and drawing figures are for illustrative purposes only, and do not in any way limit the invention, which is defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||